<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 4, 2016 at 5:12 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dmitry,<br>
<br>
I wanted to revisit this thread, as I see some of these interfaces<br>
are now posted for review, and I have a couple of questions around<br>
the naming (specifically for the "provide" action):<br>
<span class=""><br>
On Thu, May 19, 2016 at 03:31:36PM +0200, Dmitry Tantsur wrote:<br>
<snip><br>
</span><span class="">> The last step before the deployment it to make nodes "available" using the<br>
> "provide" provisioning action. Such nodes are exposed to nova, and can be<br>
> deployed to at any moment. No long-running configuration actions should be<br>
> run in this state. The "manage" action can be used to bring nodes back to<br>
> "manageable" state for configuration (e.g. reintrospection).<br>
<br>
</span>So, I've been reviewing <a href="https://review.openstack.org/#/c/334411/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334411/</a> which<br>
implements support for "openstack overcloud node provide"<br>
<br>
I really hate to be the one nitpicking over openstackclient verbiage, but<br>
I'm a little unsure if the literal translation of this results in an<br>
intuitive understanding of what happens to the nodes as a result of this<br>
action. So I wanted to have a broaded discussion before we land the code<br>
and commit to this interface.<br>
<br>
More info below:<br>
<snip><br>
<span class="">> what do you propose?<br>
> --------------------<br>
><br>
> I would like the new TripleO mistral workflows to start following the ironic<br>
> state machine closer. Imagine the following workflows:<br>
><br>
> 1. register: take JSON, create nodes in "manageable" state. I do believe we<br>
> can automate the enroll->manageable transition, as it serves the purpose of<br>
> validation (and discovery, but lets put it aside).<br>
><br>
> 2. provide: take a list of nodes or all "managable" nodes and move them to<br>
> "available". By using this workflow an operator will make a *conscious*<br>
> decision to add some nodes to the cloud.<br>
<br>
</span>Here, I think the problem is that while the dictionary definition of<br>
"provide" is "make available for use, supply" (according to google), it<br>
implies obtaining the node, not just activating it.<br>
<br>
So, to me "provide node" implies going and physically getting the node that<br>
does not yet exist, but AFAICT what this action actually does is takes an<br>
existing node, and activates it (sets it to "available" state)<br>
<br>
I'm worried this could be a source of operator confusion - has this<br>
discussion already happened in the Ironic community, or is this a TripleO<br>
specific term?<br>
<br>
To me, something like "openstack overcloud node enable" or maybe "node<br>
activate" would be more intuitive, as it implies taking an existing node<br>
from the inventory and making it active/available in the context of the<br>
overcloud deployment?<br></blockquote><div><br></div><div><br></div><div>My 2 cents, as a operator, the part wherein a node is enrolled, manageable, available is a bit confusing to first timers. </div><div>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).</div><div><br></div><div>I do not know if there is a deployed state :)</div><div>regards</div><div>/sanjay</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, not a huge issue, but given that this is a new step in our nodes<br>
workflow, I wanted to ensure folks are comfortable with the terminology<br>
before we commit to it in code.<br>
<br>
Thanks!<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>