On Tue, Jul 05, 2016 at 12:22:33PM +0200, Dmitry Tantsur wrote: > On 07/04/2016 01:42 PM, Steven Hardy 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. > > > <snip> > > > > 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? > > Hi, and thanks for the great question. > > As I've already responded on the patch, this term is settled in our OSC > plugin spec [1], and we feel like it reflects the reality pretty well. But I > clearly understand that naming things is really hard, and what feels obvious > to me does not feel obvious to the others. Anyway, I'd prefer if we stay > consistent with how Ironic names things now. > > [1] > http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironicclient-osc-plugin.html
Thanks, this is the context I was missing - If the term is already accepted by the ironic community then I agree, let's keep things consistent. Thanks! Steve __________________________________________________________________________ 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