Open Stack

To summarize. I believe we have 3 decisions from my original email but I
have also uncovered some more problems.

1. "replication controller" instead of "rc"

Adrian, regarding "rc" and "replication controller".  The OSC uses verbose
commands including multi words. This includes "availability zone", "volume
type" and "security group role".  As this precedent is set, "replication
controller" rather then "rc" is inline with current syntax.   While I
personally am not for verbose operations in general or multi word options,
given the breath of commands already available you may not intrinsically
know what "rc" was, e.g. a OSC user that does not work with containers.

I believe "replication controller" is the appropriate choice here.

2. "execute" or "exec"

This is clearly a new type of action that requires OSC to provide
recommended guidance on. I am 50/50 here.

3. "set" or "update"

While I consider the word "set" to be more an attribute specific term,
"update" implies a change of multiple attributes. If I just looked at the
usage I would say "update".  However, looking at the actual usage openstack
client set syntax uses named parameters to set multiple parameters.

$ openstack help quota set
usage: openstack quota set [-h] [--class] [--properties <properties>]
                           [--ram <ram>] [--secgroup-rules <secgroup-rules>]
                           [--instances <instances>] [--key-pairs
<key-pairs>]
                           [--fixed-ips <fixed-ips>] [--secgroups
<secgroups>]
                           [--injected-file-size <injected-file-size>]
                           [--floating-ips <floating-ips>]
                           [--injected-files <injected-files>]
                           [--cores <cores>]
                           [--injected-path-size <injected-path-size>]
                           [--gigabytes <gigabytes>] [--volumes <volumes>]
                           [--snapshots <snapshots>]
                           [--volume-type <volume-type>]
                           <project/class>


Looking into the help syntax of a Magnum "update" option, I find it
supports "add", "replace" and "remove" operations.  This complicates
matters.

$ magnum help bay-update
usage: magnum bay-update <bay> <op> <path=value> [<path=value> ...]

Update information about the given bay.

Positional arguments:
  <bay>         UUID or name of bay
  <op>          Operations: 'add', 'replace' or 'remove'
  <path=value>  Attributes to add/replace or remove (only PATH is necessary
on
                remove)

I see the name specific parameters as a lot of work, I would be a fan of
more general name=value attributes.

Does "update" really then become  "set" and "unset"? Opinions.

4. "service" is already used by Identity. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html

5. "container" is already used by Swift. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html


I have no suggestions on 4. and 5.
Given these last 2 entanglements the OSC will quickly become unusable as
more clients which it integrate.

Regards

Ronald

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:    @RonaldBradford <http://twitter.com/ronaldbradford>
Skype:     RonaldBradford
GTalk:     Ronald.Bradford
IRC:         rbradfor


On Mon, May 25, 2015 at 1:30 AM, Steve Martinelli <stevemar at ca.ibm.com>
wrote:

> Hey Ronald,
>
> Thanks for asking first, as more folks are adopting OSC plugins for their
> respective clients we should probably streamline this a bit, but the ML
> works for now.
>
> Just 2 remarks...
>
> I'd actually prefer 'replication controller' (which you prefer) instead
> of 'rc' (as adrian suggested). The reason for this is that in OSC we try
> not to abbreviate when possible.
>
> Also, instead of 'update', is this analogous to user update or volume
> update? We've been using the key term 'set' instead wherever possible.
>
> For a complete list of current commands in vanilla OSC:
> http://docs.openstack.org/developer/python-openstackclient/command-list.html
> (see the lack of update :))
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> Adrian Otto <adrian.otto at rackspace.com> wrote on 05/24/2015 10:35:12 PM:
>
> > From: Adrian Otto <adrian.otto at rackspace.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Date: 05/24/2015 10:35 PM
> > Subject: Re: [openstack-dev] [openstackclient] [magnum] Review of
> > object and actions for magnumclient implementation
> >
> > Thanks for taking the initiative on this! Remarks in-line...
>
> >
> > On May 24, 2015, at 11:20 AM, Ronald Bradford <me at ronaldbradford.com>
> wrote:
>
> > I have outlined in the blueprint  (https://blueprints.launchpad.net/
> > python-openstackclient/+spec/magnum-support) the object and actions
> > mappings that are currently available in the magnumclient.
> > I have separated the list of actions that are presently used and
> > actions that are not for review and discussion. Specifically These
> > actions DO NOT match.
> > bay [ update ]
> > Ok.
> > container [ execute | start | stop ]
> > Consider using exec instead of execute. This would more closely
> > match the docker CLI, and improves usability. Consider patching this
> > in the API and python-magnumclient to keep it consistent. This will
> > tighten up the user experience for those using both Magnum through
> > OSC and Docker natively on Docker Swarm bays.
> >
> > Start and stop are ok.
> > pod [ update ]
> > Ok.
> > replication controller [ update ]
> > Use "rc" here so we do not have a two word noun.
> > service [ update ]
> > Ok.
> >
> > Thanks,
> >
> > Adrian
> > I would appreciate feedback on if these actions "update", "execute",
> > "start" and "stop" are appropriate to use.
> > Regards
> > Ronald
> >
> __________________________________________________________________________
> > 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150525/37ee5cb1/attachment.html>