Comment 2 for bug 1704444

An option other than the queue would be to make the API call that invoked
the power action blocking (at least optionally). As it stands, API
consumers have to poll, or sleep and retry.

On Fri, Jul 14, 2017 at 12:35 PM, Andres Rodriguez <email address hidden>
wrote:

> FWIW, MAAS performs a power action (e.g. on) and then it checks for the
> machine to power on, or power off in an specific interval. If you
> attempt to do another power action at the time, MAAS will surface the
> error you see in the regiond.log.
>
> While a queue is desirable, it could also be catastrophic and we prove
> this to be the case when we used celery and rabbitmq. As such, MAAS will
> prevent you doing that while another power action is running for the
> time being.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1704444
>
> Title:
> [2.2] MAAS API returns 500 internal server error instead of raising
> actual error
>
> Status in MAAS:
> Triaged
> Status in MAAS 2.2 series:
> Triaged
>
> Bug description:
> I have some code that creates a VM via pods, aborts commissioning,
> edits the VM's settings via virsh, then restarts commissioning.
>
> It failed to restart commissioning in one case, giving a 500 error:
> http://paste.ubuntu.com/25090134/
>
> From regiond.log:
> http://paste.ubuntu.com/25090102/
>
> The API should at least give me a useful error message (and http
> status code?) if it can't handle this internally via queuing or
> blocking.
>
> This is with 2.2.1.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1704444/+subscriptions
>