[openstack-dev] [neutron][osc] Openstack client, Openstack SDK and neutronclient consistency

Akihiro Motoki amotoki at gmail.com
Thu Nov 17 13:09:08 UTC 2016


I totally agree with the direction of OSC and shade.
The similar discussion happens in neutronclient side before too.

>From user perspective, 'name' is really useful to identify resources,
even though admin usually use ID to identify resources.
In the past neutronclient discussion, requiring at least one parameter is
useful
to avoid issuing a command line by mistake. It is another feedback from
user experience.

The neutronclient bug should be closed with Won't Fix.

Akihiro


2016-11-17 19:55 GMT+09:00 Sławek Kapłoński <slawek at kaplonski.pl>:

> Hello,
>
> Thx all of You for explanations. So I think that [1] can be closed as
> "Won't fix" now. Am I right?
>
> [1] https://bugs.launchpad.net/neutron/+bug/1640767
>
> --
> Best regards / Pozdrawiam
> Sławek Kapłoński
> slawek at kaplonski.pl
>
> On Wed, 16 Nov 2016, Dean Troyer wrote:
>
> > > Excerpts from Sławek Kapłoński's message of 2016-11-16 22:36:41 +0100:
> > >> Hello,
> > >> So I want to ask all of You how in Your opinion it should be solved.
> > >> Currently there is inconsistency between CLI clients and
> > >> API/Horizon/Openstack SDK (I checked that it is possible to create
> > >> resource without name via SDK).
> >
> > There are a number of intentional inconsistencies between OSC and the
> > various REST APIs, precisely because many of the the APIs themselves
> > are very inconsistent not only between projects but even within each
> > project.  When those APIs are directly reflected in the CLI, like
> > happens with many of the project-specific CLIs, the users suffer due
> > to the inconsistencies.
> >
> >
> > On Wed, Nov 16, 2016 at 4:03 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> > > The OpenStackClient team made the decision to always require names
> > > for newly created resources. Perhaps Dean or Steve can fill in more
> > > of the background, but my understanding is that this is a design
> > > decision for the user interface implemented by OSC, and not is not
> > > considered a bug.
> >
> > Doug is correct here, we (OpenStackClient) made a specific decision in
> > the command structure to always use the resource name as the
> > positional argument of a create command.  In this case I believe the
> > consistency is worth what pain it may cause to invent a name for a new
> > policy.
> >
> > We have done UX surveys with OSC at the last two summits and the
> > number one favorable comment from the users (varying from cloud
> > consumers to operators to OpenStack developers) has been regarding how
> > much they appreciate the command consistency.  This is our biggest
> > feature.
> >
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161117/42a03b03/attachment.html>


More information about the OpenStack-dev mailing list