Attribute's convert_kvp_list_to_dict cannot convert single pair

[Filipe Manco]

I'm developing extensions to quantum and I noticed that the method convert_kvp_list_to_dict isn't able to convert a single key/value pair.

I have an attribute with 'convert_to': attributes.convert_kvp_list_to_dict

I'm able to execute

quantum operation --myproperty key1=value1 key2=value2

but I'm not able to execute

quantum operation --myproperty key1=value1

[Amir Sadoughi (amir-sadoughi)]

Have you considered the following pattern?

quantum operation --myproperty=value1

[Salvatore Orlando (salvatore-orlando)]

At a first glance, it seems you can do what you are trying to achieve with type:dict or type:dict_or_empty validators.

For an example of how these validators are used, see: https://github.com/openstack/quantum/blob/master/quantum/extensions/loadbalancer.py#L106

Adding more information on the extension you are trying to add, and the rational for this changes in validator, might be really helpful. Arguably, claiming that a method called kvp_list_to_dict should also accept non-lists in input, is a bit strange...

[Filipe Manco (fmanco)]

About my extension, I'm developing a provider router extension. I will submit a blueprint when it is properly defined.

The provider router will have a config attribute that can hold 0 or more key/value pairs according to the users' needs. So, all of the following will be valid calls (only examples):

quantum router-create [options]
quantum router-create [options] --provider:config user=admin
quantum router-create [options] --provider:config user=admin password=admin

The reason I submitted this is because I saw this as a bug. convert_kvp_list_to_dict is supposed to convert a list of key/value pairs to a dicitonary, and a single element list still a list. The problem is that for the second example, quantumclient don't know that is a single element list and obviously will submit a string.

But I agree with salvatore that having convert_kvp_list_to_dict converting something that is not a list might be counterintuitive. What is the correct way of handling this?

Also, I saw this code:

    if kvp_list == ['True']:
        # No values were provided (i.e. '--flag-name')
        return {}

When will the method receive ['True']. I think that when you supply '--flag-name' the method will receive true and not ['True'].

[Nachi Ueno (nati-ueno)]

Could you try this one?

quantum router-create [options] --provider:config list=true user=admin

[Filipe Manco (fmanco)]

Just to make it even more clear I have this:

CONFIGURATION: {
    'allow_post': True, 'allow_put': False,
    'default': attributes.ATTR_NOT_SPECIFIED,
    'convert_to': attributes.convert_kvp_list_to_dict,
    'validate': {'type:dict_or_empty': None},
    'is_visible': True
}

Nachi's solution does work. Thanks.

I have two more questions:

If I do "quantum router-create [options ] --provider:config" (without values) it fails with internal server error. Shouldn't the converter handle this? (check the end of my previous comment please).

In the method docstring it says that q_exc.InvalidInput is raised "if any of the keys appear more than once". But in fact the method returns a list of values instead of a single value per key. Which one is wrong? Should it in fact check for duplicates?

[Ben Nemec (bnemec)]

This seems to be a similar problem to bug 1161078. I still think it would be good for Quantum to handle the case where a client sends a bare string for a parameter that should be a list of strings (especially since quantumclient does so by default), but I suppose that's a significant change since it would affect the API.

In that bug a change to the client was used to fix the usability problem of having to specify list=true. Is something like that an option here? Or could a change on the quantum side to allow this behavior be investigated? I'm new to this so maybe there's a reason that isn't allowed.

[Cedric Brandily (cbrandily)]

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]