Open Stack

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