Open Stack

On Thu, May 25, 2017 at 9:29 PM, Mark Goddard <mark at stackhpc.com> wrote:

> On 25 May 2017 at 11:03, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
>> On 05/25/2017 11:38 AM, Zhenguo Niu wrote:
>>
>>>
>>> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtantsur at redhat.com
>>> <mailto: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.
>>>
>>
>> I don't share this understanding, depends on a situation. A user of a
>> purely baremetal cloud, or an installer like TripleO, may use the baremetal
>> commands all the time.
>>
>>
>>>
>>>         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.
>>>
>>
> When using the openstack CLI I'm often in a 'discovery' mode, particularly
> if I'm interacting with a service that I don't often interact with. I often
> use the tab autocomplete and fuzzy match features of OSC as I explore.
> Having command prefix match multiple services could be confusing,
> particularly if I have python-moganclient installed but no mogan service
> exists.
>
> If there were an additional command prefix for mogan as is used for ironic
> inspector (openstack baremetal introspection ...), this would at least
> group the mogan commands.
>
>         * openstack baremetal foo server <action> <args>
>         * openstack baremetal foo flavor <action> <args>
>         * openstack baremetal foo keypair <action> <args>
>         * openstack baremetal foo availability zone <action> <args>
>
>
In fact, at first we used an additional prefix for mogan (openstack
baremetal compute) like ironic inspector to group our commands, but then we
find there's no collision with the existing commands if we remove the
prefix and
only using 'baremetal'makes users type less. But seems we make this change
from the point of view of an OpenStack developer instead of the OSC users.

We can change to use 'openstack baremetal compute' if it makes less
confusing, It looks like a good alternative to me :)


>
>>>     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.
>>>
>>
>> It's not obvious from a command name, though. They'll just get 403 when
>> trying to use them.
>>
>>
>>>
>>>         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
>>>         <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://OpenStack-dev-request@lists.openstack.org?subject:un
>>> subscribe>
>>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>> k-dev
>>>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
>>> ck-dev>
>>>
>>>
>>>
>>>     ____________________________________________________________
>>> ______________
>>>     OpenStack Development Mailing List (not for usage questions)
>>>     Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>>     <http://OpenStack-dev-request@lists.openstack.org?subject:un
>>> subscribe>
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>     <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.op
>>> enstack.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:unsubscrib
>> e
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170526/718ec009/attachment.html>