On 05/25/2017 11:38 AM, Zhenguo Niu wrote:
On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtant...@redhat.com
<mailto:dtant...@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.
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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
