Open Stack

On 08/07/2014 07:57 AM, Mathieu Gagné wrote:
> On 2014-08-06 7:58 PM, Robert Collins wrote:
>>
>> I'm astounded by this proposal - it doesn't remove the garbage
>> collection complexity at all - it transfers it from our code - Nova -
>> onto end users. So rather than one tested and consolidated
>> implementation, we'll have one implementation in saltstack, one
>> implementation in heat, one implementation in Juju, one implementation
>> in foreman etc.
>>
>> In what possible way is that an improvement ?
>>
>
> I agree with Robert. It is not an improvement.
>
> For various reasons, in some parts of our systems, we have to manually 
> create ports beforehand and it has always been a mess.
>
> Instance creation often fails for all sort of reasons and it's really 
> annoying to have to garbage collect orphan ports once in a while. The 
> typically user does not use the API and does not care about the 
> underlying details.
>
> In other parts of our systems, we do rely on port auto-creation. It 
> might has its flaws but when we use it, it works like a charm and we 
> like it. We really appreciate the orchestration and automation made by 
> Nova.
>
> 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.  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.  And if there is a failure you can make on-the-fly decisions 
about how to handle that.

Also, when Nova is creating a resource on a users behalf it does not 
provide any feedback on the progress of that operation.  But if those 
are created outside of Nova than the user is exposed to the feedback and 
progress reporting provided by Neutron/Cinder.