Open Stack

On 10/13/2015 05:15 PM, Dean Troyer wrote:
> On Tue, Oct 13, 2015 at 3:58 PM, Shifali Agrawal
> <shaifali.agrawal09 at gmail.com <mailto:shaifali.agrawal09 at gmail.com>> wrote:
>
>     All above make sense, just one thing, how about using word "zaqar"
>       instead of messaging? That is what all other projects are doing,
>     for example:
>
>
> These are the old project-specific CLIs, note that the 'keystone'
> command only supports v2 auth today and will be removed entirely in the
> keystoneclient 2.0 release.
>
>     $ keystone user-create
>     $ heat event-list
>
>     This will create a separate namespace for the project and also will
>     solve the issue of `openstack messaging message post`.
>
>
> One of the things I have tried very hard to do is make it so users do
> NOT need to know which API handles a given command.  For higher-layer
> projects that is less of a concern I suppose, and that was done long
> before anyone thought that 20+ APIs would be handled in a single command
> set.

I agree very strongly with this goal. We've done the same thing with the 
new ansible modules. (os_server vs. nova_compute) It becomes especially 
important when there are things that are the same but handled by 
different services. Should the user know/care that in cloud A they get a 
floating IP from nova but in cloud B they get it from neutron? Nope. 
That's a mess in our yard - the user shouldn't need to know.

> Namespacing has come up and is something we need to discuss further,
> either within the 'openstack' command itself or by using additional
> top-level command names.  This is one of the topics for discussion in
> Tokyo, but has already started on the ML for those that will not be present.
>
> No matter how we end up handling the namespacing issue, I will still
> strongly insist that project code names not be used.  I know some
> plugins already do this today and we can't stop anyone else from doing
> it, but it leads to the same sort of inconsistency for users that the
> original project CLIs had. It reduces the value of a single (or small
> set of) CLI for the user to deal with.

FWIW - in the ansible modules we adopted a general naming policy of 
non-service names for things that end-users want to interact with 
(server, floating-ip) because they are not deployers and they should care.

For admin things "create keystone domain" "create nova flavor" we have 
the service name in - partially because of the namespacing problem, but 
also because an _admin_ is administering a service called "nova" - they 
are not consuming a service that might be provided by nova ... they can 
be expected to know.

So we have: os_nova_flavor and will soon have os_keystone_domain but 
os_image and os_subnet.