Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On Sep 1, 2015, at 8:36 PM, Dolph Mathews wrote: > Does anyone have an example of an API outside of OpenStack that would return > 400 in this situation (arbitrary query string parameters)? Based on my past > experience, I'd expect them to be ignored, but I can't think

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

(not for usage questions) Subject: Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering Does anyone have an example of an API outside of OpenStack that would return 400 in this situation (arbitrary query string parameters)? Based on my past

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Does anyone have an example of an API outside of OpenStack that would return 400 in this situation (arbitrary query string parameters)? Based on my past experience, I'd expect them to be ignored, but I can't think of a reason why a 400 would be a bad idea (but I suspect there's some prior art /

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On 08/27/2015 11:28 PM, Chen, Wei D wrote: > > I agree that return 400 is good idea, thus client user would know what > happened. > +1, I think a 400 is the sensible choice here. It'd be much more likely to help devs catch their errors . -- Ryan Brown / Software Engineer, Openstack / Red

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Hi Henry in principle I think it is a good idea to have a user friendly name attribute for every entity. The name should be unique amongst the same set of entities (though not between entities since context should imply what entity you are referring to), otherwise the name would have to be

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote: Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a ‘name’ attribute (which is

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On Thu, Aug 27, 2015 at 11:47 AM, Everett Toews everett.to...@rackspace.com wrote: On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote: Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote: Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a 'name' attribute

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a ‘name’ attribute (which is how the openstack show command works). Turns out, that not all keystone

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a ‘name’ attribute (which is how the openstack show command works). Turns out, that not all

[openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the entities it can show - namely that is assumes all entries have a ‘name’ attribute (which is how the openstack show command works). Turns out, that not all keystone