Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Folks, you are welcome to review a spec: https://review.openstack.org/254796


Aleksey Kasatkin


On Fri, Nov 6, 2015 at 6:03 PM, Aleksey Kasatkin 
wrote:

> Mike, Vladimir,
>
> Yes,
> 1. We need to add IPs on-the-fly (need to add POST functionality) ,
> otherwise it will be VIP-like way (change network roles in plugin or
> release).
> 2. We should allow to leave fields 'network_role', 'node_roles', 'namespace'
> empty. So, validation should be changed.
>
> So, answer here
>
>> Q. Any allocated IP could be accessible via these handlers, so now we can
>> restrict user to access VIPs only
>> and answer with some error to other ip_addrs ids.
>>
> should be "Any allocated IP is accessible via these handlers", so URLs can
> be changed to
> /clusters//network_configuration/ips/
> /clusters//network_configuration/ips//
> Nodes IPs maybe the different story though.
>
> Alex,
>
> 'node_roles' determines in what node group to allocate IP. So, it will be
> group with controller nodes for our base VIPs
> (they all have node_roles=['controller'] which is default setting).
> It can be some other node group for nodes with different role. E.g. ceph
> nodes use some ceph/vip network role and VIP is defined
> for this network role (with 'network_role'='ceph/vip' and 
> 'node_roles'=['ceph/osd']).
> This VIP will be allocated
> in the network that 'ceph/vip' is mapped to and in the node group where
> ceph nodes are located. ceph nodes cannot be located
> in more than one node group then (as VIP cannot migrate between node groups
> now).
>
>
>
> Aleksey Kasatkin
>
>
> On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin 
> wrote:
>
>> +1 to Mike
>>
>> It would be awesome to get an API handler that allows one to actually add
>> an ip address to IP_addrs table. As well as an IP range to ip_ranges table.
>>
>> On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov > > wrote:
>>
>>> Is there a way to make it more generic, not "VIP" specific? Let's say I
>>> want to reserve address(-es) for something for whatever reason, and then I
>>> want to use them by some tricky way.
>>> More specifically, can we reserve IP address(-es) with some codename,
>>> and use it later?
>>> 12.12.12.12 - my-shared-ip
>>> 240.0.0.2 - my-multicast
>>> and then use them in puppet / whatever deployment code by $my-shared-ip,
>>> $my-multicast?
>>>
>>> Thanks,
>>>
>>> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin 
>>> wrote:
>>>
 Folks,

 Here is a resume of our recent discussion:

 1. Add new URLs for processing VIPs:

 /clusters//network_configuration/vips/ (GET)
 /clusters//network_configuration/vips// (GET, PUT)

 where  is the id in ip_addrs table.
 So, user can get all VIPS, get one VIP by id, change parameters (IP
 address) for one VIP by its id.
 More possibilities can be added later.

 Q. Any allocated IP could be accessible via these handlers, so now we
 can restrict user to access VIPs only
 and answer with some error to other ip_addrs ids.

 2. Add current VIP meta into ip_addrs table.

 Create new field in ip_addrs table for placing VIP metadata there.
 Current set of ip_addrs fields:
 id (int),
 network (FK),
 node (FK),
 ip_addr (string),
 vip_type (string),
 network_data (relation),
 node_data (relation)

 Q. We could replace vip_type (it contains VIP name now) with vip_info.

 3. Allocate VIPs on cluster creation and seek VIPs at all network
 changes.

 So, VIPs will be checked (via network roles descriptions) and
 re-allocated in ip_addrs table
 at these points:
 a. create cluster
 b. modify networks configuration
 c. modify one network
 d. modify network template
 e. change nodes set for cluster
 f. change node roles set on nodes
 g. modify cluster attributes (change set of plugins)
 h. modify release

 4. Add 'manual' field into VIP meta to indicate whether it is
 auto-allocated or not.

 So, whole VIP description may look like:
 {
 'name': 'management'
 'network_role': 'mgmt/vip',
 'namespace': 'haproxy',
 'node_roles': ['controller'],
 'alias': 'management_vip',
 'manual': True,
 }

 Example of current VIP description:

 https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207

 Nailgun will re-allocate VIP address if 'manual' == False.

 5. Q. 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?

 Use '--force' parameter to change it. PUT will fail otherwise.


 Guys, please review this and share your comments here,

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksandr Didenko]

Hi,

Mike, that's exactly how you can use this VIPs allocation functionality.
Nailgun will save that VIP so it's not going to be auto-assigned to any
node and serialize it into astute.yaml (vip_name: IP). After that you can
get your VIP via Hiera and use it in your deployment scripts.

Guys, could you please clarify what's the purpose of 'node_roles' in VIP
description?

Regards,
Alex

On Fri, Nov 6, 2015 at 5:15 AM, Mike Scherbakov 
wrote:

> Is there a way to make it more generic, not "VIP" specific? Let's say I
> want to reserve address(-es) for something for whatever reason, and then I
> want to use them by some tricky way.
> More specifically, can we reserve IP address(-es) with some codename, and
> use it later?
> 12.12.12.12 - my-shared-ip
> 240.0.0.2 - my-multicast
> and then use them in puppet / whatever deployment code by $my-shared-ip,
> $my-multicast?
>
> Thanks,
>
> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin 
> wrote:
>
>> Folks,
>>
>> Here is a resume of our recent discussion:
>>
>> 1. Add new URLs for processing VIPs:
>>
>> /clusters//network_configuration/vips/ (GET)
>> /clusters//network_configuration/vips// (GET, PUT)
>>
>> where  is the id in ip_addrs table.
>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>> address) for one VIP by its id.
>> More possibilities can be added later.
>>
>> Q. Any allocated IP could be accessible via these handlers, so now we can
>> restrict user to access VIPs only
>> and answer with some error to other ip_addrs ids.
>>
>> 2. Add current VIP meta into ip_addrs table.
>>
>> Create new field in ip_addrs table for placing VIP metadata there.
>> Current set of ip_addrs fields:
>> id (int),
>> network (FK),
>> node (FK),
>> ip_addr (string),
>> vip_type (string),
>> network_data (relation),
>> node_data (relation)
>>
>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>
>> 3. Allocate VIPs on cluster creation and seek VIPs at all network changes.
>>
>> So, VIPs will be checked (via network roles descriptions) and
>> re-allocated in ip_addrs table
>> at these points:
>> a. create cluster
>> b. modify networks configuration
>> c. modify one network
>> d. modify network template
>> e. change nodes set for cluster
>> f. change node roles set on nodes
>> g. modify cluster attributes (change set of plugins)
>> h. modify release
>>
>> 4. Add 'manual' field into VIP meta to indicate whether it is
>> auto-allocated or not.
>>
>> So, whole VIP description may look like:
>> {
>> 'name': 'management'
>> 'network_role': 'mgmt/vip',
>> 'namespace': 'haproxy',
>> 'node_roles': ['controller'],
>> 'alias': 'management_vip',
>> 'manual': True,
>> }
>>
>> Example of current VIP description:
>>
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>>
>> Nailgun will re-allocate VIP address if 'manual' == False.
>>
>> 5. Q. 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?
>>
>> Use '--force' parameter to change it. PUT will fail otherwise.
>>
>>
>> Guys, please review this and share your comments here,
>>
>> Thanks,
>>
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin > > wrote:
>>
>>> 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 

Re: [openstack-dev] [Fuel] Change VIP address via API

[Vladimir Kuklin]

+1 to Mike

It would be awesome to get an API handler that allows one to actually add
an ip address to IP_addrs table. As well as an IP range to ip_ranges table.

On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov 
wrote:

> Is there a way to make it more generic, not "VIP" specific? Let's say I
> want to reserve address(-es) for something for whatever reason, and then I
> want to use them by some tricky way.
> More specifically, can we reserve IP address(-es) with some codename, and
> use it later?
> 12.12.12.12 - my-shared-ip
> 240.0.0.2 - my-multicast
> and then use them in puppet / whatever deployment code by $my-shared-ip,
> $my-multicast?
>
> Thanks,
>
> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin 
> wrote:
>
>> Folks,
>>
>> Here is a resume of our recent discussion:
>>
>> 1. Add new URLs for processing VIPs:
>>
>> /clusters//network_configuration/vips/ (GET)
>> /clusters//network_configuration/vips// (GET, PUT)
>>
>> where  is the id in ip_addrs table.
>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>> address) for one VIP by its id.
>> More possibilities can be added later.
>>
>> Q. Any allocated IP could be accessible via these handlers, so now we can
>> restrict user to access VIPs only
>> and answer with some error to other ip_addrs ids.
>>
>> 2. Add current VIP meta into ip_addrs table.
>>
>> Create new field in ip_addrs table for placing VIP metadata there.
>> Current set of ip_addrs fields:
>> id (int),
>> network (FK),
>> node (FK),
>> ip_addr (string),
>> vip_type (string),
>> network_data (relation),
>> node_data (relation)
>>
>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>
>> 3. Allocate VIPs on cluster creation and seek VIPs at all network changes.
>>
>> So, VIPs will be checked (via network roles descriptions) and
>> re-allocated in ip_addrs table
>> at these points:
>> a. create cluster
>> b. modify networks configuration
>> c. modify one network
>> d. modify network template
>> e. change nodes set for cluster
>> f. change node roles set on nodes
>> g. modify cluster attributes (change set of plugins)
>> h. modify release
>>
>> 4. Add 'manual' field into VIP meta to indicate whether it is
>> auto-allocated or not.
>>
>> So, whole VIP description may look like:
>> {
>> 'name': 'management'
>> 'network_role': 'mgmt/vip',
>> 'namespace': 'haproxy',
>> 'node_roles': ['controller'],
>> 'alias': 'management_vip',
>> 'manual': True,
>> }
>>
>> Example of current VIP description:
>>
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>>
>> Nailgun will re-allocate VIP address if 'manual' == False.
>>
>> 5. Q. 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?
>>
>> Use '--force' parameter to change it. PUT will fail otherwise.
>>
>>
>> Guys, please review this and share your comments here,
>>
>> Thanks,
>>
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin > > wrote:
>>
>>> 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 

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Mike, Vladimir,

Yes,
1. We need to add IPs on-the-fly (need to add POST functionality) ,
otherwise it will be VIP-like way (change network roles in plugin or
release).
2. We should allow to leave fields 'network_role', 'node_roles', 'namespace'
empty. So, validation should be changed.

So, answer here

> Q. Any allocated IP could be accessible via these handlers, so now we can
> restrict user to access VIPs only
> and answer with some error to other ip_addrs ids.
>
should be "Any allocated IP is accessible via these handlers", so URLs can
be changed to
/clusters//network_configuration/ips/
/clusters//network_configuration/ips//
Nodes IPs maybe the different story though.

Alex,

'node_roles' determines in what node group to allocate IP. So, it will be
group with controller nodes for our base VIPs
(they all have node_roles=['controller'] which is default setting).
It can be some other node group for nodes with different role. E.g. ceph
nodes use some ceph/vip network role and VIP is defined
for this network role (with 'network_role'='ceph/vip' and
'node_roles'=['ceph/osd']).
This VIP will be allocated
in the network that 'ceph/vip' is mapped to and in the node group where
ceph nodes are located. ceph nodes cannot be located
in more than one node group then (as VIP cannot migrate between node groups
now).



Aleksey Kasatkin


On Fri, Nov 6, 2015 at 10:20 AM, Vladimir Kuklin 
wrote:

> +1 to Mike
>
> It would be awesome to get an API handler that allows one to actually add
> an ip address to IP_addrs table. As well as an IP range to ip_ranges table.
>
> On Fri, Nov 6, 2015 at 6:15 AM, Mike Scherbakov 
> wrote:
>
>> Is there a way to make it more generic, not "VIP" specific? Let's say I
>> want to reserve address(-es) for something for whatever reason, and then I
>> want to use them by some tricky way.
>> More specifically, can we reserve IP address(-es) with some codename, and
>> use it later?
>> 12.12.12.12 - my-shared-ip
>> 240.0.0.2 - my-multicast
>> and then use them in puppet / whatever deployment code by $my-shared-ip,
>> $my-multicast?
>>
>> Thanks,
>>
>> On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin 
>> wrote:
>>
>>> Folks,
>>>
>>> Here is a resume of our recent discussion:
>>>
>>> 1. Add new URLs for processing VIPs:
>>>
>>> /clusters//network_configuration/vips/ (GET)
>>> /clusters//network_configuration/vips// (GET, PUT)
>>>
>>> where  is the id in ip_addrs table.
>>> So, user can get all VIPS, get one VIP by id, change parameters (IP
>>> address) for one VIP by its id.
>>> More possibilities can be added later.
>>>
>>> Q. Any allocated IP could be accessible via these handlers, so now we
>>> can restrict user to access VIPs only
>>> and answer with some error to other ip_addrs ids.
>>>
>>> 2. Add current VIP meta into ip_addrs table.
>>>
>>> Create new field in ip_addrs table for placing VIP metadata there.
>>> Current set of ip_addrs fields:
>>> id (int),
>>> network (FK),
>>> node (FK),
>>> ip_addr (string),
>>> vip_type (string),
>>> network_data (relation),
>>> node_data (relation)
>>>
>>> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>>>
>>> 3. Allocate VIPs on cluster creation and seek VIPs at all network
>>> changes.
>>>
>>> So, VIPs will be checked (via network roles descriptions) and
>>> re-allocated in ip_addrs table
>>> at these points:
>>> a. create cluster
>>> b. modify networks configuration
>>> c. modify one network
>>> d. modify network template
>>> e. change nodes set for cluster
>>> f. change node roles set on nodes
>>> g. modify cluster attributes (change set of plugins)
>>> h. modify release
>>>
>>> 4. Add 'manual' field into VIP meta to indicate whether it is
>>> auto-allocated or not.
>>>
>>> So, whole VIP description may look like:
>>> {
>>> 'name': 'management'
>>> 'network_role': 'mgmt/vip',
>>> 'namespace': 'haproxy',
>>> 'node_roles': ['controller'],
>>> 'alias': 'management_vip',
>>> 'manual': True,
>>> }
>>>
>>> Example of current VIP description:
>>>
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>>>
>>> Nailgun will re-allocate VIP address if 'manual' == False.
>>>
>>> 5. Q. 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?
>>>
>>> Use '--force' parameter to change it. PUT will fail otherwise.
>>>
>>>
>>> Guys, please review this and share your comments here,
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin <
>>> akasat...@mirantis.com> wrote:
>>>
 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

Re: [openstack-dev] [Fuel] Change VIP address via API

[Mike Scherbakov]

Is there a way to make it more generic, not "VIP" specific? Let's say I
want to reserve address(-es) for something for whatever reason, and then I
want to use them by some tricky way.
More specifically, can we reserve IP address(-es) with some codename, and
use it later?
12.12.12.12 - my-shared-ip
240.0.0.2 - my-multicast
and then use them in puppet / whatever deployment code by $my-shared-ip,
$my-multicast?

Thanks,

On Tue, Nov 3, 2015 at 8:49 AM Aleksey Kasatkin 
wrote:

> Folks,
>
> Here is a resume of our recent discussion:
>
> 1. Add new URLs for processing VIPs:
>
> /clusters//network_configuration/vips/ (GET)
> /clusters//network_configuration/vips// (GET, PUT)
>
> where  is the id in ip_addrs table.
> So, user can get all VIPS, get one VIP by id, change parameters (IP
> address) for one VIP by its id.
> More possibilities can be added later.
>
> Q. Any allocated IP could be accessible via these handlers, so now we can
> restrict user to access VIPs only
> and answer with some error to other ip_addrs ids.
>
> 2. Add current VIP meta into ip_addrs table.
>
> Create new field in ip_addrs table for placing VIP metadata there.
> Current set of ip_addrs fields:
> id (int),
> network (FK),
> node (FK),
> ip_addr (string),
> vip_type (string),
> network_data (relation),
> node_data (relation)
>
> Q. We could replace vip_type (it contains VIP name now) with vip_info.
>
> 3. Allocate VIPs on cluster creation and seek VIPs at all network changes.
>
> So, VIPs will be checked (via network roles descriptions) and re-allocated
> in ip_addrs table
> at these points:
> a. create cluster
> b. modify networks configuration
> c. modify one network
> d. modify network template
> e. change nodes set for cluster
> f. change node roles set on nodes
> g. modify cluster attributes (change set of plugins)
> h. modify release
>
> 4. Add 'manual' field into VIP meta to indicate whether it is
> auto-allocated or not.
>
> So, whole VIP description may look like:
> {
> 'name': 'management'
> 'network_role': 'mgmt/vip',
> 'namespace': 'haproxy',
> 'node_roles': ['controller'],
> 'alias': 'management_vip',
> 'manual': True,
> }
>
> Example of current VIP description:
>
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207
>
> Nailgun will re-allocate VIP address if 'manual' == False.
>
> 5. Q. 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?
>
> Use '--force' parameter to change it. PUT will fail otherwise.
>
>
> Guys, please review this and share your comments here,
>
> Thanks,
>
>
>
> Aleksey Kasatkin
>
>
> On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin 
> wrote:
>
>> 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
>> > 

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

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 
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 

Re: [openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

Folks,

Here is a resume of our recent discussion:

1. Add new URLs for processing VIPs:

/clusters//network_configuration/vips/ (GET)
/clusters//network_configuration/vips// (GET, PUT)

where  is the id in ip_addrs table.
So, user can get all VIPS, get one VIP by id, change parameters (IP
address) for one VIP by its id.
More possibilities can be added later.

Q. Any allocated IP could be accessible via these handlers, so now we can
restrict user to access VIPs only
and answer with some error to other ip_addrs ids.

2. Add current VIP meta into ip_addrs table.

Create new field in ip_addrs table for placing VIP metadata there.
Current set of ip_addrs fields:
id (int),
network (FK),
node (FK),
ip_addr (string),
vip_type (string),
network_data (relation),
node_data (relation)

Q. We could replace vip_type (it contains VIP name now) with vip_info.

3. Allocate VIPs on cluster creation and seek VIPs at all network changes.

So, VIPs will be checked (via network roles descriptions) and re-allocated
in ip_addrs table
at these points:
a. create cluster
b. modify networks configuration
c. modify one network
d. modify network template
e. change nodes set for cluster
f. change node roles set on nodes
g. modify cluster attributes (change set of plugins)
h. modify release

4. Add 'manual' field into VIP meta to indicate whether it is
auto-allocated or not.

So, whole VIP description may look like:
{
'name': 'management'
'network_role': 'mgmt/vip',
'namespace': 'haproxy',
'node_roles': ['controller'],
'alias': 'management_vip',
'manual': True,
}

Example of current VIP description:
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L207

Nailgun will re-allocate VIP address if 'manual' == False.

5. Q. 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?

Use '--force' parameter to change it. PUT will fail otherwise.


Guys, please review this and share your comments here,

Thanks,



Aleksey Kasatkin


On Tue, Nov 3, 2015 at 10:47 AM, Aleksey Kasatkin 
wrote:

> 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 

Re: [openstack-dev] [Fuel] Change VIP address via API

[Igor Kalnitsky]

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  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//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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List 

[openstack-dev] [Fuel] Change VIP address via API

[Aleksey Kasatkin]

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//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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev