Orchestration abort stack creation uppon signals/

[lion24]

Hello guys,

Is there any API to abort the stack creation, for example when the user press ctrl-c or the jobs receives a signal from the pipeline ? We are currently facing some issues when our jobs is getting abort but the stack still keeps being created.

Or is that simple as registering a signal handler and issue DeleteStack when a signal is received ?

Thanks for your replies.

[github-actions[bot]]

Thank you for reporting your first issue! Be sure that we will be looking at it, but keep in mind this sometimes takes a while. Please let the maintainers know if your issue has not got enough attention after a few days. If any doubt, please consult our issue tutorial.

[pierreprinetti]

The handling of interrupts is very much something that should be handled at the application level. What I mean by this, is that your code should listen for the signal, and act upon it.

The problem here is that Gophercloud does not expose a cancellation capability; you're required to handle cancellation on the caller side, by interrupting your chain of calls to Gophercloud functions.

I think that this should change and Gophercloud should expose DoStuffWithContext(ctx, ...) functions. This is on the roadmap, with no current ETA.

[lion24]

Thanks for your reply @pierreprinetti

We already have the machinery in place on the caller side to intercept signals are do stuff when they occur. So yes basically signaling we should stop the stack creation when such signal are received using a DeleteStack should be enough for now..

I just wanted to be sure I was not missing something.

[pierreprinetti]

I just wanted to be sure I was not missing something.

Unfortunately, to the best of my knowledge you aren't.

[pierreprinetti]

Update: you can. The API is weird, but you can set a Context on the Service provider, and that will be injected in Gophercloud's HTTP call.

It's suboptimal (why scoping cancellation on the whole Provider instead of just the call?) and it's a bit confusing (I think you can replace the Context after use) and more importantly, it's not concurrent-safe (all the requests sent with that Service provider will share the same cancellation), but maybe it can fit your use-case.

To be honest I think I will do my best to replace that with a call-scoped Context.

[lion24]

It's suboptimal (why scoping cancellation on the whole Provider instead of just the call?) and it's a bit confusing (I think you can replace the Context after use) and more importantly, it's not concurrent-safe (all the requests sent with that Service provider will share the same cancellation), but maybe it can fit your use-case.

Ok I'll check thanks :)