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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
