On 03/20/2017 05:39 PM, Hongbin Lu wrote: > > >> -----Original Message----- >> From: Dean Troyer [mailto:[email protected]] >> Sent: March-20-17 5:19 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [magnum][osc] What name to use for magnum >> commands in osc? >> >> On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto <[email protected]> >> wrote: >>> the <command> argument is actually the service name, such as “ec2”. >> This is the same way the openstack cli works. Perhaps there is another >> tool that you are referring to. Have I misunderstood something? >> >> I am going to jump in here and clarify one thing. OSC does not do >> project namespacing, or any other sort of namespacing for its resource >> names. It uses qualified resource names (fully-qualified even?). In >> some cases this results in something that looks a lot like namespacing, >> but it isn't. The Volume API commands are one example of this, nearly >> every resource there includes the word 'volume' but not because that is >> the API name, it is because that is the correct name for those >> resources ('volume backup', etc). > > [Hongbin Lu] I might provide a minority point of view here. What confused me > is inconsistent style of the resource name. For example, there is a > "container" resource for a swift container, and there is "secret container" > resource a barbican container. I just found it odd to have both un-qualified > resource (i.e. container) and qualified resource name (i.e. secret container) > in the same CLI. It appears to me that some resources are namespaced and > others are not, and this kind of style provides a suboptimal user experiences > from my point of view. > > I think the style would be more consistent if all the resources are qualified > or un-qualified, not the mix of both.
Yes - if we had been more forward thinking a while back, I think we could do that. However, some things are already done and changing them would be an incredible amount of churn. In my happy world, we would all consider the resource names that exist across the openstack projects before we make new ones. So - swift got here first, it wins, it gets container. The fine folks in barbican, rather than calling a thing a container and then needing to call it a secret-container - maybe could call their thing a vault or a locker or a safe or a lockbox or an oubliette. (for instance) I do not have any suggestions for things that actually return a resource that are a single "linux container" - since swift called their thing a container before docker was written and popularized the word to mean something different. We might just get to be fun and different - sort of like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs user, you "kill" text into the kill ring and then you "yank" from the ring into the current document. OTOH, I think Dean has talked about more verbose terms and then aliases for backwards compat. So maybe a swift container is always an "object_container" - but because of history it gets to also be unqualified "container" - but then we could have "object container" and "secret container" and "linux container" ... similarly we could have "server flavor" and "volume flavor" ... etc. (fwiw, shade just picks winners - so "create_container" gets you a swift container. No clue what we'll do when we add barbican or zun yet ... mabye the same thing?) >> >>> We could so the same thing and use the text “container_infra”, but we >> felt that might be burdensome for interactive use and wanted to find >> something shorter that would still make sense. >> >> Naming resources is hard to get right. Here's my throught process: >> >> For OSC, start with how to describe the specific 'thing' being >> manipulated. In this case, it is some kind of cluster. In the list >> you posted in the first email, 'coe cluster' seems to be the best >> option. I think 'coe' is acceptable as an abbreviation (we usually do >> not use them) because that is a specific term used in the field and >> satisfies the 'what kind of cluster?' question. No underscores please, >> and in fact no dash here, resource names have spaces in them. >> >> dt >> >> -- >> >> Dean Troyer >> [email protected] >> >> _______________________________________________________________________ >> ___ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev- >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
