Open Stack

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