Hello all, We now have a work-in-progress patch up for review:
https://review.openstack.org/#/c/158697/ Feedback on our approach is much appreciated. Many thanks, John Davidge OpenStack@Cisco On 20/02/2015 18:28, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote: >-----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-pr >>e >> >> >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 __________________________________________________________________________ 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
