Hello, Thx for clarifications and closing this bug.
-- Best regards / Pozdrawiam Sławek Kapłoński sla...@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 <sla...@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 > > sla...@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 <d...@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 > > > 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 > > > > __________________________________________________________________________ > > 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 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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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