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 <[email protected]> wrote: > Folks, > > Here is a resume of our recent discussion: > > 1. Add new URLs for processing VIPs: > > /clusters/<cluster_id>/network_configuration/vips/ (GET) > /clusters/<cluster_id>/network_configuration/vips/<id>/ (GET, PUT) > > where <id> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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: >>> [email protected]?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Mike Scherbakov #mihgen
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
