On 2014-08-08 8:54 AM, Andrew Laski wrote:
On 08/07/2014 07:57 AM, Mathieu Gagné wrote:
IMO, moving the burden of such orchestration (and garbage collection)
to the end users would be a mistake. It's not a good UX at all.
I could say that removing auto-creation is like having to create your
volume (from an image) before booting on it. Before BDMv2, that's what
we had to do and it wasn't cool at all. We had to implement a logic
waiting for the volume to be 'available' before booting on it
otherwise Nova would complain about the volume not being available.
Now that we have BDMv2, it's a much better UX.
I want to be able to run this command and not worry about pre-steps:
nova boot --num-instances=50 [...] app.example.org
I think the suggestion being made by the 'do not autocreate' camp is to
allow that, but have the logic for it wrapped into the client. That does
mean that multiple SDKs might need to implement that logic, but in
return you are provided with control.
With control comes responsibilities.
We went down that path and it didn't go well.
One part of our systems isn't written in Python and we had to rewrite
part of python-novaclient. For various reasons, we also had to create
ports/volumes first and orchestrate steps ourselves.
Writing a good bullet-proof orchestration logic (and rollback) takes
time and experience. I stopped counting the number of bugs we internally
opened due to bad logic, orchestration, fallback, retries, etc.
If OpenStack can provide a server-side logic, the better we will be. We
wish to fire-and-forget a "nova boot" and not have to orchestrate stuff
on the client-side.
When stuff are done on the client-side, anything can go wrong: your
script can get killed/stopped for a lot of reasons. And when it happens,
you have to have a logic to either fallback, garbage collect or restart
from where you left. This is suboptimal and error prone.
If people wish to orchestrate those steps themselves, they already can
by providing a port-id instead of a net-id. Same with volumes and BDM.
OpenStack has to be easy to use to attract people, not the other way
around where the argument of "control" is used to avoid implementing a
good logic on the server-side (and push this burden to the end users).
> A deployer is going to set a
specific timeout that they've decided on, but as a user you can
determine how long you're willing to wait for ports/volumes to be
created.
Our type of users do not care about such details. They wish to boot an
instance and have all those details handled for them. You might feel
greater control is better but not in our case.
> And if there is a failure you can make on-the-fly decisions
> about how to handle that.
Why can't OpenStack make those decisions?
Also, when Nova is creating a resource on a users behalf it does not
provide any feedback on the progress of that operation.
This is something Nova could easily handle with task states. It's
already the case with block device mapping.
--
Mathieu
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
