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.agrawa...@gmail.com <mailto:shaifali.agrawa...@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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
