-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Those are good news!
I commented on the pull request. Briefly, we can fetch from git, but would prefer an official release. Thanks, /Ihar On 02/19/2015 11:26 PM, Robert Li (baoli) wrote: > Hi Kyle, Ihar, > > It looks promising to have our patch upstreamed. Please take a look > at this pull request > https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75144912. > Most importantly, Tomek asked if it’s sufficient to have the code > up in his master branch. I guess you guys may be able to help > answer that question since I’m not familiar with openstack release > process. > > Cheers, Robert > > On 2/13/15, 12:16 PM, "Kyle Mestery" <mest...@mestery.com > <mailto:mest...@mestery.com>> wrote: > > On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg) > <jodav...@cisco.com <mailto:jodav...@cisco.com>> wrote: > > Hi Ihar, > > To answer your questions in order: > > 1. Yes, you are understanding the intention correctly. Dibbler > doesn¹t currently support client restart, as doing so causes all > existing delegated prefixes to be released back to the PD server. > All subnets belonging to the router would potentially receive a new > cidr every time a subnet is added/removed. > > 2. Option 2 cannot be implemented using the current version of > dibbler, but it can be done using the version we have modified. > Option 3 could possibly be done with the current version of > dibbler, but with some major limitations - only one single router > namespace would be supported. > > Once the dibbler changes linked below are reviewed and finalised we > will only need to merge a single patch into the upstream dibbler > repo. No further patches are anticipated. > > Yes, you are correct that dibbler is not needed unless prefix > delegation is enabled by the deployer. It is intended as an > optional feature that can be easily disabled (and probably will be > by default). A test to check for the correct dibbler version would > certainly be necessary. > > Testing in the gate will be an issue until the new version of > dibbler is merged and packaged in the various distros. I¹m not sure > if there is a way to avoid this problem, unless we have devstack > install from our updated repo while we wait. > > To me, this seems like a pretty huge problem. We can't expect > distributions to package side-changes to upstream projects. The > correct way to solve this problem is to work to get the changes > required in the dependent packages upstream into those projects > first (dibbler, in this case), and then propose the changes into > Neutron to make use of those changes. I don't see how we can > proceed with this work until the issues around dibbler has been > resolved. > > > John Davidge OpenStack@Cisco > > > > > On 13/02/2015 16:01, "Ihar Hrachyshka" <ihrac...@redhat.com > <mailto:ihrac...@redhat.com>> wrote: > > Thanks for the write-up! See inline. > > On 02/13/2015 04:34 PM, Robert Li (baoli) wrote: >> Hi, > >> while trying to integrate dibbler client with neutron to support >> PD, we countered a few issues with the dibbler client (and >> server). With a neutron router, we have the qg-xxx interface that >> is connected to the public network, on which a dhcp server is >> running on the delegating router. For each subnet with PD >> enabled, a router port will be created in the neutron router. As >> a result, a new PD request will be sent that asks for a prefix >> from the delegating router. Keep in mind that the subnet is added >> into the router dynamically. > >> We thought about the following options: > >> 1. use a single dibbler client to support the above requirement. >> This means, the client should be able to accept new requests on >> the fly either through configuration reload or other interfaces. >> Unfortunately, dibbler client doesn¹t support it. > > Sorry for my ignorance on PD implementation (I will definitely look > at it the next week), but what does this entry above mean? Do you > want a single dibbler instance running per router serving all > subnets plugged into it? And you want to get configuration updates > when a new subnet is plugged in, or removed from the router? > > If that's the case, why not just restarting the client? > >> 2. start a dibbler client per subnet. All of the dibbler clients >> will be using the same outgoing interface (which is the qg-xxx >> interface). Unfortunately, dibbler client uses /etc/dibbler and >> /var/lib/dibbler for its state (in which it saves duid file, pid >> file, and other internal states). This means it can only support >> one client per network node. 3. run a single dibbler client that >> requests a smaller prefix (say /56) and splits it among the >> subnets with PD enabled (neutron subnet requires /64). Depending >> on the neutron router setup, this may result in significant waste >> of prefixes. > > Just to understand all options at the table: can we implement ^^ > option with stock dibbler? > > >> Given the significant drawback with 3, we are left with 1 and 2. >> After looking at the dibbler source code, we found that 2 is >> easier to achieve for now by making some small changes in the >> dibbler code. In the long run, we think option 1 is better. > >> The changes we made to the linux dibbler client code, and the >> dibbler server code can be found in here: >> https://github.com/johndavidge/dibbler/tree/cloud-dibbler. >> Basically it does a few things: ‹ create a unique working area >> per dibbler client ‹ since all the clients use the same outgoing >> interface, we¹d like each dibbler client to use a unique LLA as >> its source address when sending messages. This would avoid >> clients to receive server messages that are not intended for >> them. ‹ we found that dibbler server uses transaction ID alone to >> identify a match between a request and an answer. This would >> require that unique transaction IDs be used among all the >> existing clients. We found that clients could use the same >> transaction IDs in our environment. Therefore, a little change is >> made in the server code so that it will take the request sender >> into consideration while looking up a match. > > >> Option 1 requires better understanding of the dibbler code, and >> we think that it may not be possible to make it happen in the >> kilo timeframe. But we think it has significant advantages over >> option 2. Regardless, changes made for 2 is also needed since we >> need to run one dibbler client per neutron router. > >> Now the issue is how to make those changes (possible with >> further revision) into an official dibbler release ASAP so that >> we can use them for kilo release. John Davidge has contacted the >> dibbler authors, and hasn¹t received response so far. > > That's disturbing from packager point of view. > > - From Red Hat side, we miss dibbler packaged in Fedora, but that's > a minor issue, we can easily put some effort and do it. > > As for shipping side patches with it, it's a major problem. > Especially considering the fact that those patches were not > reviewed or accepted by dibbler upstream. > > I think it is critical to reach dibbler authors ASAP and see what > they have to say about these patches. Remember, we're in Kilo-3 > mode already. > > Reading thru the spec [1], it seems to me that dibbler won't be > involved at all unless users explicitly omit prefix info when > creating subnets. Is it correct? If so, can we somehow provide an > easy way for distributions and deployers out of using custom > patched dibbler by disabling the feature completely if/when they > see shipping this version of dibbler unacceptable? I think we could > introduce a new config option that would forbid prefix delegated > subnets (?). > > Speaking of deployers, have you also considered providing a patch > for sanity_check tool that would test local dibbler installation > on whether it supports the needed features? > > Also, on a relevant note, how do you test the feature in gate? > Distro packages probably don't ship the patched version of the > client. Do you have any functional tests that utilize the client? > > [1]: > https://github.com/openstack/neutron-specs/blob/master/specs/kilo/ipv6-pre > > fix-delegation.rst > > /Ihar >> >> __________________________________________________________________________ > >> > OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU53y7AAoJEC5aWaUY1u57Nx0IALCHzBPNpcyAy2VIRaeek7Q1 Ol9RuwDRomqpKKsLRPAhatgwq9WDnDLK8MO3bt5yZfW0xqDfwwXYq0jSNoxJWjXE L2JBAXgrTRnffPH4rA4kf7cUjLdJBFwMBpwslQZ4UgVC/B6TMjj0cYDu7BOSN2FD A4YcBD1qPu5Kqar05R6jo+SH0qsM2g+gHS38UEGRCxnQAsZhk6QMT7NtCbzgE+dY n8ntfBV9sEduM4URrrEbhJAblK5gswQJvEV5VxHznLdj+2vgtVUUgSYDKnUk/F66 CqvVpyGyocAqPoFkyYsoTdq9d6fJil4Oy/gp9gJL22kKsluBOCd1UKnmT7QHOxk= =rBo9 -----END PGP SIGNATURE----- __________________________________________________________________________ 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