Open Stack

On 03/20/2017 05:39 PM, Hongbin Lu wrote:
> 
> 
>> -----Original Message-----
>> From: Dean Troyer [mailto:dtroyer at gmail.com]
>> 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 <adrian.otto at rackspace.com>
>> 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
>> dtroyer at gmail.com
>>
>> _______________________________________________________________________
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>