Open Stack

Hello,

Thx for clarifications and closing this bug.

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl

On Thu, 17 Nov 2016, Akihiro Motoki wrote:

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

> __________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161117/fbc5172d/attachment.pgp>