[openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor
flavio at redhat.com
Wed Oct 14 07:13:04 UTC 2015
On 13/10/15 18:27 -0400, Monty Taylor wrote:
>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
>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
>>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
>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.
This is great feedback and I think it actually hits the problem we're
having. The problem is not really related to the user facing API but
the admins one.
I fully agree with the suggestion of not using project names, which is
why I originally recomended to use the catalog service type. That
said, I think this can be worked out better and we chould follow
sometihng similar to what Monty mentioned.
I guess my remaining concern here is that this standard assumes that
there's just 1 messaging service that could be used and whenever
someone calls `openstack message post...` is talking to Zaqar.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev