[openstack-dev] [neutron][osc] Openstack client, Openstack SDK and neutronclient consistency
mordred at inaugust.com
Wed Nov 16 23:05:59 UTC 2016
On 11/16/2016 04:03 PM, Doug Hellmann wrote:
> Excerpts from Sławek Kapłoński's message of 2016-11-16 22:36:41 +0100:
>> Few days ago someone reported bug  and I started checking it. I found
>> that when I'm trying to create QoS policy with neutronclient or OSC then
>> name parameter is neccessary.
>> But this parameter is not neccessary in Neutron API - I can create
>> policy without name when calling API directly (e.g. with curl).
>> For me it is bug on neutronclient and openstack client side and it
>> should be IMHO fixed to allow creating QoS policy without name (so
>> without any parameter given in fact: "neutron qos-policy-create").
>> But today on QoS IRC meeting we were talking about it and reedip point
>> us another bug  (and his patch ) which concerns same problem but with
>> different parameter.
>> And in this patchset amotoki said that it can't be fixed in way that
>> allows to create resource without any parameter given in
>> openstack/neutron client.
>> 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).
>> I checked it for QoS policy (and network in SDK) but I think that it
>> might be more generic issue.
>>  https://bugs.launchpad.net/neutron/+bug/1640767
>>  https://launchpad.net/bugs/1520055
>>  https://review.openstack.org/#/c/250587/
> 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.
I'll say that in shade we made the same decision, even though we don't
have QoS support. We also mostly enforce uniqueness just about
everywhere in names even if the REST API doesn't - for similar reasons.
More information about the OpenStack-dev