Open Stack

On 09/24/15 at 12:16pm, Mathieu Gagné wrote:
>On 2015-09-24 11:53 AM, Walter A. Boring IV wrote:
>> The good thing about the Nova and Cinder clients/APIs is that
>> anyone can write a quick python script to do the orchestration
>> themselves, if we want to deprecate this.  I'm all for deprecating this.
>
>I don't like this kind of reasoning which can justify close to anything.
>It's easy to make those suggestions when you know Python. Please
>consider non-technical/non-developers users when suggesting deprecating
>features or proposing alternative solutions.
>
>I could also say (in bad faith, I know): why have Heat when you can
>write your own Python script. And yet, I don't think we would appreciate
>anyone making such a controversial statement.
>
>Our users don't know Python, use 3rd party tools (which don't often
>perform/support orchestration) or the Horizon dashboard. They don't want
>to have to learn Heat or Python so they can orchestrate volume creation
>in place of Nova for a single instance. You don't write CloudFormation
>templates on AWS just to boot an instance on volume. That's not the UX I
>want to offer to my users.

The issues that I've seen with having this happen in Nova are that there 
are many different ways for this process to fail and the user is 
provided no control or visibility.

As an example we have some images that should convert to volumes quickly 
so failure would be defined as taking longer than x amount of time, but 
for another set of images that are expected to take longer failure would 
be 3x amount of time.  Nova shouldn't be the place to decide how long 
volume creation should take, and I wouldn't expect to ask users to pass 
this in during an API request.

When volume creation does take a decent amount of time there is no 
indication of progress in the Nova API.  When monitoring it via the 
Cinder API you can get a rough approximation of progress.  I don't 
expect Nova to expose volume creation progress as part of the feedback 
during an instance boot request.

At the moment the volume creation request happens from the computes 
themselves.  This means that a failure presents itself as a build 
failure leading to a reschedule and ultimately the user is given a 
NoValidHost.  This is unhelpful and as an operator tracking down the 
root cause is time consuming.

When there is a failure to build an instance while Cinder is creating a 
volume it's possible to end up with the volume left around while the 
instance is deleted.  This is not at all made visible to users in the 
Nova API unless they query the list of volumes and see one they don't 
expect, though it's often immediately clear in the DELETE request sent 
to Cinder.

In short, it ends up being much nicer for users to control the process 
themselves.  Alternatively it would be nice if there was an 
orchestration system that could handle it for them.  But Nova is not 
designed to do that very well.


>
>-- 
>Mathieu
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev