Open Stack

Igor,

> For VIP allocation we should use POST request. It's ok to use PUT for
setting (changing) IP address.

My proposal is about setting IP addresses for VIPs only (auto and manual).
No any other allocations.
Do you propose to use POST for first-time IP allocation and PUT for IP
re-allocation?
Or use POST for adding entries to some new 'vips' table (so that all VIPs
descriptions
will be added there from network roles)?

> We don't store network_role, namespace and node_roles within VIPs.
> They are belonged to network roles. So how are you going to retrieve
> them? Did you plan to make some changes to our data model? You know,
> it's not a good idea to make connections between network roles and
> VIPs each time your make a GET request to list them.

It's our current format we use in API when VIPs are being retrieved.
Do you propose to use different one for address allocation?

> Should we return VIPs that aren't allocated, and if so - why? If they
> would be just, you know, fetched from network roles - that's a bad
> design. Each VIP should have an explicit entry in VIPs database table.

I propose to return VIPs even w/o IP addresses to show user what VIPs he has
so he can assign IP addresses to them. Yes, I supposed that the information
will be retrieved from network roles as it is done now. Do you propose to
create
separate table for VIPs or extend ip_addrs table to store VIPs information?

> We definitely should handle `null` this way, but I think from API POV
> it would be more clearer just do not pass `ipaddr` value if user wants
> it to be auto allocated. I mean, let's keep `null` as implementation
> details ans force API users just do not pass this key if they don't
> want to.

Oh, I didn't write it here, I thought about keeping IP addresses as is when
corresponding key is skipped by the user.

>The thing is that there's no way to *warn* users through API. You
> could either reject or accept request. So all we can do is to
> introduce some `force` flag, and if it's passed - ignore overlapping.

It is now done for network verification that it can pass with warning
message.
But I like your proposal better.

> overlaps with the network of current environment which does not
> match the network role of the VIP?

So, when IP address of the VIP matches some IP range that corresponds
to the network which is different from the one that network role bound to
the VIP has.
E.g. IP address matches the 'public' network but VIP is bound to
'management/vip' role
which is mapped to 'management' network.


Thanks,



Aleksey Kasatkin


On Mon, Nov 2, 2015 at 7:06 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
wrote:

> Hey Aleksey,
>
> I agree that we need a separate API call for VIP allocation, thought I
> don't agree on some points you have proposed. See my comments below.
>
> > use PUT to change VIPs addresses (set them manually or request
> > to allocate them automatically)
>
> PUT requests SHOULD NOT be used for VIP allocation, by RESTful API
> notation the PUT request should be used for changing (editing)
> entities, not for creating new ones. For VIP allocation we should use
> POST request. It's ok to use PUT for setting (changing) IP address.
>
> > vips: [
> >     {
> >         'network_role': 'management',
> >         'namespace': 'haproxy',
> >         'ipaddr': '10.10.10.10',
> >         'node_roles': ['controller']
> >     },...
> > ]
>
> There I have two comments:
>
> * We don't need the "vips" word in API output - let's return a JSON
> list with VIPs and that's it.
> * We don't store network_role, namespace and node_roles within VIPs.
> They are belonged to network roles. So how are you going to retrieve
> them? Did you plan to make some changes to our data model? You know,
> it's not a good idea to make connections between network roles and
> VIPs each time your make a GET request to list them.
>
> > When it is set to None, IP address will be allocated automatically
>
> We definitely should handle `null` this way, but I think from API POV
> it would be more clearer just do not pass `ipaddr` value if user wants
> it to be auto allocated. I mean, let's keep `null` as implementation
> details ans force API users just do not pass this key if they don't
> want to.
>
> > When the user runs GET request for the first time, all 'ipaddr'
> > fields are equal to None.
>
> Should we return VIPs that aren't allocated, and if so - why? If they
> would be just, you know, fetched from network roles - that's a bad
> design. Each VIP should have an explicit entry in VIPs database table.
>
> > There is a question, what to do when the given address overlaps
> > with the network from another environment? My opinion that those
> > should pass with a warning message.
>
> The thing is that there's no way to *warn* users through API. You
> could either reject or accept request. So all we can do is to
> introduce some `force` flag, and if it's passed - ignore overlapping.
>
> I didn't get what do you mean by:
>
> > overlaps with the network of current environment which does not
> > match the network role of the VIP?
>
> Could you please explain?
>
> Thanks,
> Igor
>
> P.S: I see this API call somehow this way http://xsnippet.org/361113/raw/
>
> On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin <akasatkin at mirantis.com>
> wrote:
> > Hi folks,
> >
> > I'm working on the following story [1][2]:
> > API must allow VIP to be manually set to ANY valid IP address. If the IP
> on
> > update API is a member of any network in this environment then the
> address
> > should be put in the assignments table so that it can not be used in any
> > other
> > automatic assignment. (This allows the user to override if the automatic
> > allocation doesn't match their needs or in the case that they want to use
> > external LB).
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1482399
> > [2] https://review.openstack.org/230943
> >
> > So, I have the following proposal for now:
> > Add new url (e.g. /clusters/<cluster_id>/network_configuration/vips/ ),
> use
> > GET
> > to query current VIPs info, use PUT to change VIPs addresses (set them
> > manually
> > or request to allocate them automatically).
> > Now VIPs have the following format in API requests data:
> > vips: [
> >     {
> >         'network_role': 'management',
> >         'namespace': 'haproxy',
> >         'ipaddr': '10.10.10.10',
> >         'node_roles': ['controller']
> >     },...
> > ]
> > So, 'ipaddr' field can be set to any (almost any) user-defined value or
> to
> > None (null in YAML).
> > When it is set to None, IP address will be allocated automatically. When
> the
> > user runs GET
> > request for the first time, all 'ipaddr' fields are equal to None. So,
> user
> > can set some (or all)
> > of them to desired values and run PUT. When the GET is run after PUT, all
> > addresses will be
> > filled with values. User can reset some of them to None or change to
> other
> > IP when required.
> > So, addresses will be re-allocated on the next PUT requests.
> > If address given by user overlaps with some of the allocated IPs, PUT
> > request will be rejected.
> > There is a question, what to do when the given address overlaps with the
> > network from another
> > environment? overlaps with the network of current environment which does
> not
> > match the
> > network role of the VIP?
> > My opinion that those should pass with a warning message.
> >
> > Please share your proposals and comments on this,
> >
> > Thanks,
> >
> >
> > Aleksey Kasatkin
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151103/cba768e3/attachment.html>