Open Stack

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
>>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.

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.

Cheers,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151014/e1e75fab/attachment.pgp>