Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-21 Thread Clay Gerrard
On Tue, Dec 20, 2016 at 2:11 PM, Dean Troyer  wrote:
>
> This is exactly how it should work.  I do want to make an additional
> important but subtle point:  while it looks like those are namespaced
> commands, we used 'server' not 'compute' because it is not a
> compute-namespaced, but a server-specific resource.

I *think* I understood this - the server command is representative of a
server resource, not a service.  It's somewhat circumstantial that often
times when you think about the top level base primitive resources OpenStack
provides cloud users - that they occasionally align with a single service
API endpoint.  But a big design goal for a unified client seems like it
might hopefully help abstract the services away so the user can focus on
their "stuff" ;)

>'object store container' would be consistent, 'object store object' is
awful.

Fully agree, would suggest:

"object "
"object container "
"object account "

I think this follows closely where the other resource commands are going?

>
> Notice that in the command list lined above the 'backup' resource has
> been deprecated and renamed as 'volume backup'.  We could possibly
> also do this with 'object' and 'container' from Swift, we will be
> doing this with other resources (flavor -> server flavor comes to
> mind).

I had not noticed the backup command, or flavor, thank you for pointing
those out.  This is excellent news!

>
> Backward compatibility is very important to us though, so renaming
> these resources takes a long time to complete.  Freeing up the
> top-level bare container resource would be three cycles out at best.
>

Seems reasonable to me!  AIUI the top level "object" resource would stay,
it would grow "container" & "account" sub resources, and the "object store
account" and "container" top-level commands would be deprecated.  Then
during the development of the release after a release which includes those
changes you could start to remove the deprecated interfaces.

-Clay
__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-21 Thread gordon chung


On 20/12/16 05:09 PM, Steve Martinelli wrote:
> This was my initial thought when discussing the problem with Hongbin
> last night.
>
> We have three main "swift" resources in OSC -- "object store account",
> "container" and "object". I think renaming "container" to "object store
> container" is totally acceptable. The issue of deprecation comes into
> play, we'll need to deprecate it and give it at least one cycle.
> Luckily, the zun team isn't ready to publish a CLI just yet.
>
> Alternatively, I don't mind "appcontainer".

leverage/extend CADF taxonomy[1]?

[1] 
https://wiki.openstack.org/w/images/e/e1/Introduction_to_Cloud_Auditing_using_CADF_Event_Model_and_Taxonomy_2013-10-22.pdf
 
slide 13

-- 
gord

__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Hongbin Lu


From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: December-20-16 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [osc][openstackclient][zun] Collision on the 
keyword 'container'

On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard 
<clay.gerr...@gmail.com<mailto:clay.gerr...@gmail.com>> wrote:

On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:

$ openstack objectstore container  
$ openstack container container  
$ openstack secret container  

Thoughts?

This is the closest thing I can see that's somewhat reasonable - with the 
obvious exception of "container container " - which is pretty gross.

Here's the best list I could find of what's going on now:

http://docs.openstack.org/developer/python-openstackclient/command-list.html

The collision of top-level resource names is not new.  You see stuff like 
"volume create" & "server create" - but also "volume backup create" & "server 
backup create"- which is an obvious pattern to replicate for disambiguating top 
level name conflicts with similarly named (sub?)-resources between services - 
except apparently in an effort to keep things flat no one saw it coming with a 
name like "container".

But IMHO an object-store "container" is not a top level OpenStack resource, is 
it?  I would think users would be happy to dump stuff into the object store 
using "object create" - and reasonably expect to use "object container create" 
to create a container *for their objects*?  This isn't a generic OpenStack 
"container" - you can't use this generic "container" for anything except 
objects?  Oddly, this pattern is already in use with the pre-existing "object 
store account" command?!

This was my initial thought when discussing the problem with Hongbin last night.

We have three main "swift" resources in OSC -- "object store account", 
"container" and "object". I think renaming "container" to "object store 
container" is totally acceptable. The issue of deprecation comes into play, 
we'll need to deprecate it and give it at least one cycle. Luckily, the zun 
team isn't ready to publish a CLI just yet.

Alternatively, I don't mind "appcontainer".

[Hongbin Lu] I am going to propose ‘appcontainer’ to Zun team. It looks like a 
good alternative to me.

__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Dean Troyer
On Tue, Dec 20, 2016 at 3:39 PM, Clay Gerrard  wrote:
> http://docs.openstack.org/developer/python-openstackclient/command-list.html


> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".

This is exactly how it should work.  I do want to make an additional
important but subtle point:  while it looks like those are namespaced
commands, we used 'server' not 'compute' because it is not a
compute-namespaced, but a server-specific resource.

> But IMHO an object-store "container" is not a top level OpenStack resource,
> is it?  I would think users would be happy to dump stuff into the object
> store using "object create" - and reasonably expect to use "object container
> create" to create a container *for their objects*?  This isn't a generic
> OpenStack "container" - you can't use this generic "container" for anything
> except objects?  Oddly, this pattern is already in use with the pre-existing
> "object store account" command?!

'object store account' is a hack that I still hate, but due to Swift's
unique ability to not use Keystone we had to do something.  'object
store container' would be consistent, 'object store object' is awful.

> Is it really already too late to apply some sane organization to the object
> store commands in the openstack-cli and make room in the command namespace
> for a top level OpenStack resource to manage a linux-containers' service?
> Because of backwards compatibility issues?

Notice that in the command list lined above the 'backup' resource has
been deprecated and renamed as 'volume backup'.  We could possibly
also do this with 'object' and 'container' from Swift, we will be
doing this with other resources (flavor -> server flavor comes to
mind).

Backward compatibility is very important to us though, so renaming
these resources takes a long time to complete.  Freeing up the
top-level bare container resource would be three cycles out at best.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Steve Martinelli
On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard 
wrote:

>
> On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu  wrote:
>
>>
>>
>> $ openstack objectstore container  
>>
>> $ openstack container container  
>>
>> $ openstack secret container  
>>
>>
>>
>> Thoughts?
>>
>
> This is the closest thing I can see that's somewhat reasonable - with the
> obvious exception of "container container " - which is pretty gross.
>
> Here's the best list I could find of what's going on now:
>
> http://docs.openstack.org/developer/python-openstackclient/command-list.
> html
>
> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".
>
> But IMHO an object-store "container" is not a top level OpenStack
> resource, is it?  I would think users would be happy to dump stuff into the
> object store using "object create" - and reasonably expect to use "object
> container create" to create a container *for their objects*?  This isn't a
> generic OpenStack "container" - you can't use this generic "container" for
> anything except objects?  Oddly, this pattern is already in use with the
> pre-existing "object store account" command?!
>

This was my initial thought when discussing the problem with Hongbin last
night.

We have three main "swift" resources in OSC -- "object store account",
"container" and "object". I think renaming "container" to "object store
container" is totally acceptable. The issue of deprecation comes into play,
we'll need to deprecate it and give it at least one cycle. Luckily, the zun
team isn't ready to publish a CLI just yet.

Alternatively, I don't mind "appcontainer".
__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Clay Gerrard
On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu  wrote:

>
>
> $ openstack objectstore container  
>
> $ openstack container container  
>
> $ openstack secret container  
>
>
>
> Thoughts?
>

This is the closest thing I can see that's somewhat reasonable - with the
obvious exception of "container container " - which is pretty gross.

Here's the best list I could find of what's going on now:

http://docs.openstack.org/developer/python-openstackclient/command-list.html

The collision of top-level resource names is not new.  You see stuff like
"volume create" & "server create" - but also "volume backup create" &
"server backup create"- which is an obvious pattern to replicate for
disambiguating top level name conflicts with similarly named
(sub?)-resources between services - except apparently in an effort to keep
things flat no one saw it coming with a name like "container".

But IMHO an object-store "container" is not a top level OpenStack resource,
is it?  I would think users would be happy to dump stuff into the object
store using "object create" - and reasonably expect to use "object
container create" to create a container *for their objects*?  This isn't a
generic OpenStack "container" - you can't use this generic "container" for
anything except objects?  Oddly, this pattern is already in use with the
pre-existing "object store account" command?!

Is it really already too late to apply some sane organization to the object
store commands in the openstack-cli and make room in the command namespace
for a top level OpenStack resource to manage a linux-containers' service?
Because of backwards compatibility issues?

-Clay
__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Dean Troyer
On Tue, Dec 20, 2016 at 3:00 PM, Hongbin Lu  wrote:
> In the long-term, I am going to propose to follow the style of AWS CLI, that
> is prefixing each command with a project name. For example:

We have been down this particular path multiple times, and this is not
how the OSC commands work.  Some plugins have already chosen to
'namespace' their commands, which I think is a bad idea, rather than
use specific descriptive names for their resources.  The vast majority
of plugins have managed to find specific descriptive names.

You should also please keep in mind that resources should be named
from the point of view of the OSC user, not an OpenStack developer.
The implementation of the service often has no meaning to CLI users so
you want to consider what they will be looking for first.

Honestly I think the word 'container' is already so overused, and has
at least two specific and distinct meanings in OpenStack to only add
confusion for yet another use at all.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Ian Cordasco
-Original Message-
From: Hongbin Lu <hongbin...@huawei.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 20, 2016 at 15:01:33
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [osc][openstackclient][zun] Collision on the
keyword 'container'

> Hi OpenStackClients Team,
>
> I am from the Zun team, and my team encountered a name collision issue when 
> implementing
> a OSC plugin [1]. We wanted to use the keyword 'container' to represent a 
> linux container
> used to host a containerized application. In particular, the commands our 
> contributor
> wanted to implement was listed in the etherpad [2]. Unfortunately, this 
> keyword has
> already been taken in OSC, so we need to figure out a short-term walk round 
> and a long-term
> solution. Below are the short-term solution I can think of:
>
> * openstack appcontainer
> * openstack linuxcontainer
> * openstack zun container
> * openstack containerservice container
> * openstack containermgmt container
>
> In the long-term, I am going to propose to follow the style of AWS CLI, that 
> is prefixing
> each command with a project name. For example:
>
> $ openstack swift container
> $ openstack zun container
> $ openstack barbican container

I would be strongly opposed to using project names (which are already
confusing enough to users) in the openstackcli. That's just taking
good UX and throwing it out.

> Or
>
> $ openstack objectstore container

$ openstack object container

That could work, but forcing users to have to learn a new path to the
same functionality is incredibly bad.

> $ openstack container container

And this explains to me, rather well, why this would be a bad idea.
"container container" is terrible UX.

> $ openstack secret container

I don't think using service names is going to work better either,
especially provided that to retrofit that would be a *severe* breaking
change.

> Thoughts?
>
> [1] https://review.openstack.org/#/c/411786/
> [2] https://etherpad.openstack.org/p/zunclient_openstack-client-cli
>
> Best regards,
> Hongbin
> __
> 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
>

--
Ian Cordasco

__
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


[openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Hongbin Lu
Hi OpenStackClients Team,

I am from the Zun team, and my team encountered a name collision issue when 
implementing a OSC plugin [1]. We wanted to use the keyword 'container' to 
represent a linux container used to host a containerized application. In 
particular, the commands our contributor wanted to implement was listed in the 
etherpad [2]. Unfortunately, this keyword has already been taken in OSC, so we 
need to figure out a short-term walk round and a long-term solution. Below are 
the short-term solution I can think of:

* openstack appcontainer  
* openstack linuxcontainer  
* openstack zun container  
* openstack containerservice container  
* openstack containermgmt container  

In the long-term, I am going to propose to follow the style of AWS CLI, that is 
prefixing each command with a project name. For example:

$ openstack swift container  
$ openstack zun container  
$ openstack barbican container  

Or

$ openstack objectstore container  
$ openstack container container  
$ openstack secret container  

Thoughts?

[1] https://review.openstack.org/#/c/411786/
[2] https://etherpad.openstack.org/p/zunclient_openstack-client-cli

Best regards,
Hongbin
__
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