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 <[email protected]> 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/<cluster_id>/network_configuration/ips/ > /clusters/<cluster_id>/network_configuration/ips/<id>/ > 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 <[email protected]> > 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 <[email protected] >> > 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 <[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 >>> >>> >> >> >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com <http://www.mirantis.ru/> >> www.mirantis.ru >> [email protected] >> >> __________________________________________________________________________ >> 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
