openstack team mailing list archive

[Rafael Rosa <rafaelrosafu@xxxxxxxxx>]

Hi,

In our OpenStack installation we have an issue when creating new instances,
we need to execute some long running processes before calling "nova boot"
and the call blocks for the end user for a while. We would like to return
"immediately" to the caller with a final instance UUID and do the work on
the background, but it's only generated when during actual instance
creation, which is a no go in our situation.

I read the proposed
https://blueprints.launchpad.net/nova/+spec/launch-instances-async blueprint,
and I agree with Vish's take, the cleanest way would be to create the job
construct and return a 202+URI, but it would not solve our situation, the
calling system has some restrictions on pooling for updates and even
creating callbacks that we could use to update them once the instance was
created.

With all these restrictions in mind, one solution would be to allow a
"--custom-instance-uuid=abc123" option. According to our spikes, we would
only need to make sure that the param value would find its way into
base_options (
https://github.com/openstack/nova/blob/a17d03c43f1f118c4a1e16e092cd0a570f0f1694/nova/compute/api.py#L570)
as "uuid=<param_uuid>" to make it work, there would be no need to change
code after this point. To prevent misuse we could add a configuration
option to allow/deny this parameter, perhaps restricting it to admin users,
but once https://blueprints.launchpad.net/nova/+spec/db-enforce-unique-keys is
implemented I don't believe this would be a big issue.

I would like to have some opinions on this before spending time
implementing it, feedback on how to improve it, overlooked issues and
alternatives are super welcome.

Thanks,
Rafael Rosa Fu
grokpodcast.com <http://www.grokpodcast.com/>