Open Stack

On Mon, Jul 4, 2016 at 5:12 PM, Steven Hardy <shardy at redhat.com> wrote:

> Hi Dmitry,
>
> I wanted to revisit this thread, as I see some of these interfaces
> are now posted for review, and I have a couple of questions around
> the naming (specifically for the "provide" action):
>
> On Thu, May 19, 2016 at 03:31:36PM +0200, Dmitry Tantsur wrote:
> <snip>
> > The last step before the deployment it to make nodes "available" using
> the
> > "provide" provisioning action. Such nodes are exposed to nova, and can be
> > deployed to at any moment. No long-running configuration actions should
> be
> > run in this state. The "manage" action can be used to bring nodes back to
> > "manageable" state for configuration (e.g. reintrospection).
>
> So, I've been reviewing https://review.openstack.org/#/c/334411/ which
> implements support for "openstack overcloud node provide"
>
> I really hate to be the one nitpicking over openstackclient verbiage, but
> I'm a little unsure if the literal translation of this results in an
> intuitive understanding of what happens to the nodes as a result of this
> action. So I wanted to have a broaded discussion before we land the code
> and commit to this interface.
>
> More info below:
> <snip>
> > what do you propose?
> > --------------------
> >
> > I would like the new TripleO mistral workflows to start following the
> ironic
> > state machine closer. Imagine the following workflows:
> >
> > 1. register: take JSON, create nodes in "manageable" state. I do believe
> we
> > can automate the enroll->manageable transition, as it serves the purpose
> of
> > validation (and discovery, but lets put it aside).
> >
> > 2. provide: take a list of nodes or all "managable" nodes and move them
> to
> > "available". By using this workflow an operator will make a *conscious*
> > decision to add some nodes to the cloud.
>
> Here, I think the problem is that while the dictionary definition of
> "provide" is "make available for use, supply" (according to google), it
> implies obtaining the node, not just activating it.
>
> So, to me "provide node" implies going and physically getting the node that
> does not yet exist, but AFAICT what this action actually does is takes an
> existing node, and activates it (sets it to "available" state)
>
> I'm worried this could be a source of operator confusion - has this
> discussion already happened in the Ironic community, or is this a TripleO
> specific term?
>
> To me, something like "openstack overcloud node enable" or maybe "node
> activate" would be more intuitive, as it implies taking an existing node
> from the inventory and making it active/available in the context of the
> overcloud deployment?
>


My 2 cents, as a operator, the part wherein a node is enrolled, manageable,
available is a bit confusing to first timers.
If we have something more simple ie all baremetal nodes (baremetal nodes
are the nodes enrolled or manageable states), all cluster nodes (are either
available or deployed states).

I do not know if there is a deployed state :)
regards
/sanjay


>
> Anyway, not a huge issue, but given that this is a new step in our nodes
> workflow, I wanted to ensure folks are comfortable with the terminology
> before we commit to it in code.
>
> Thanks!
>
> Steve
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/811faac7/attachment.html>