Open Stack

On Thu, May 25, 2017 at 9:37 PM, Loo, Ruby <ruby.loo at intel.com> wrote:

> Hi Zhenguo,
>
>
>
> Thanks for bringing this up. Naming is hard :-(
>
>
>
> Maybe this is a dumb question but your phrase "We copied nova's server
> resource concept here, so users may easily to accept the 'baremetal
> server'" made me wonder. I'm not a user of Mogan so I don't know if this
> would work, but OSC already has
>
>     openstack server <action> <args>
>
>     openstack flavor <action> <args>
>
>     openstack keypair <action> <args>
>
>
>
> Why can't we use the existing OSC commands, and add an option eg '--bm' to
> indicate that the server is baremetal, not a VM?
>
>
>

Not sure if it's possible to achieve this by two different OSC plugins, and
as we use different options/parameters with nova when creating a baremetal
server, so I think it's hard to control by only a '--bm' option to
distinguish.
And compared with vm servers, baremetal servers have different
capabilities, it will make more confusing if you use 'openstack server
create' to create a baremetal instance, but you can't apply below commands
to it.

openstack server --bm pause/unpause
openstack server --bm shelve/unshelve
openstack server --bm migrate


> Of course, having asked this, how does the user know/distinguish between
> getting a baremetal instance via mogan or via nova... (and should the end
> user actually know that there is a difference...) But I suspect I am
> digressing.
>
>
>
As I understand, baremetal instance in nova is a 'specical virtual
machine'(raw performance). Users claim the instance by specifying a flavor
with 'vcpus', 'memory', "root_gb" instead of real hardware specs like (cpu
model/cores, hard drives type/amount, nics type/amount), then he get an
instance with properties like 'vm_state' and other 'virtual' stuff. As
baremetal in nova use the same model and same set of API that designed for
vms, so even for end users, it's not that easy to know which instance is a
baremetal server, so maybe it's good to call that baremetal server a
special vm instance.

So, yes the end user actually know that there is a difference between
getting a bremetal instance via mogan or via nova :)


> --ruby
>
>
>
> *From: *Zhenguo Niu <niu.zglinux at gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Thursday, May 25, 2017 at 5:38 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> *Subject: *Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same
> keyword 'baremetal'?
>
>
>
>
>
> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtantsur at redhat.com>
> wrote:
>
> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>
> hi all,
>
>
> Hi!
>
>
> I'm from the Mogan team, we chose the same keyward 'baremetal' when
> implementing a OSC plugin [1]. As we think the baremetal command is
> representative of a baremetal resource, not a service, so it makes sense
> for different projects to share the top level resource name that OpenStack
> can provide.
>
>
> We do not "own" the word "baremetal", so nothing prevents you from using
> it. However, in my experience:
> 1. This does confuse users, as they expect "openstack baremetal" to be a
> prefix belonging to Ironic.
> 2. Collisions may happen. We had two collisions with TripleO already, one
> resulted in us killing a TripleO command abruptly.
>
>
>
> Alternatively, I don't mind to change this to 'bm' or something like that
> for Mogan, but some operators told me that it will confuse users more to
> have both 'baremetal' and 'bm' in there CLI.
>
> And as I understand, ironic commands are not used frequently, and it's
> even less if ironic inspector can help to automatically enroll nodes/ports.
>
>
>
>
>
>
> The commands we have implemented are listed below, seems there's no
> collision with Ironic presently, and Ironic doesn't manage such resources.
>
> * openstack baremetal server <action> <args>
> * openstack bareemtal flavor <action> <args>
> * openstack baremetal keypair <action> <args>
> * openstack baremetal availability zone <action> <args>
>
>
> Ironic does not have any notion of either of these, so it should be fine.
>
> I'm still a bit on a -1 side because of potential users confusion. I
> wonder how can we send a message across that prefixes do not designate a
> specific project, but are rather just part of a "sentence". I'm
> specifically worried about confusing "baremetal server" of Mogan with
> "baremetal node" of Ironic. For many people these can be synonyms.
>
>
>
> We copied nova's server resource concept here, so users may easily to
> accept the 'baremetal server'. For 'baremetal node', seems only
> operators/administrators may use such commands, so seems the synonyms is
> not a big problem as they are for different roles.
>
>
>
>
> So, we'd like to ask if our CLI pattern is allowed before we release the
> client.
>
> Thanks in advance!
>
>
> [1] https://github.com/openstack/python-moganclient
>
> --
> Best Regards,
> Zhenguo Niu
>
>
> __________________________________________________________________________
> 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
>
>
>
> __________________________________________________________________________
> 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
>
>
>
>
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>
> __________________________________________________________________________
> 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
>
>


-- 
Best Regards,
Zhenguo Niu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170526/043dba30/attachment.html>