`no_proxy` BayModel attr type

[Jamie Hannaford]

Why is the `no_proxy` attr a comma-separated string?

It is defined here:

https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L113

And here is an example:

https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/baymodel.py#L182

Surely an array of strings would be a better and more appropriate JSON data structure?

[wangqun (bjwqun)]

I think that the comma-separated string can be easier when dealing with the backend of magnum. So I don't suggest to change the type of "no_proxy".

[Jamie Hannaford (jamie-hannaford)]

I'm not sure that API decisions should work in the favour of internal developers.

The type *is* a collection of strings, not one big concatenated one. I don't see a good reason to confuse the clarity of the types here.

[Thomas Maddox (thomas-maddox)]

Updating link to `no_proxy` to reference commit: https://github.com/openstack/magnum/blob/4ffa1d538f34bf0c93a9ae5b318a3958e7e6f4bc/magnum/api/controllers/v1/baymodel.py#L110-L112

[Thomas Maddox (thomas-maddox)]

I agree with Jamie here. Why use a special format for a list when that type already exists? If there's some special case where the backend requires it be a comma-separated string, then a `no_proxy.join(",")` can handle that at a conversion layer before the backend receives it. There it can be cleanly separated and documented as to why the backend needs it this way.

[Kyle Kelley (rgbkrk)]

If it's a publicly exposed interface, we need to rely on JSON for consumption by SDKs, clients, and other tooling that will use Magnum.