-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 UPD: dibbler packages are now available in all Fedora updates repositories, starting from Fedora 20, plus EPEL7.
Packages are called: dibbler-[client|docs|requestor|relay|server]. Specifically, you can locate them at: http://download.eng.brq.redhat.com/pub/fedora/linux/updates/21/x86_64/d/ Please report any bugs with the package at bugzilla.redhat.com. /Ihar On 03/11/2015 05:29 PM, John Davidge (jodavidg) wrote: > I am pleased to say that we are now in a good position with this > patch. The necessary DHCPv6 client changes have been made available > in the latest release of Dibbler (1.0.1) and we’re getting some > much appreciated assistance from Ihar and Thomas in having this new > version packaged for wide availability - thanks guys. > > We’ve updated the patch to include tests and it's been brought > up-to-date with the latest L3 agent refactoring changes. It is no > longer WIP and we would very much appreciate your reviews and > feedback. > > https://review.openstack.org/#/c/158697/ > > > Cheers, > > John > > > > > On 24/02/2015 17:40, "John Davidge (jodavidg)" <jodav...@cisco.com> > wrote: > >> 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: >> > 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-75 144912 >>>>> >>>>> . >>>>> 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-p >>>>> >>>>> r >>>>> 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 >>>>> >>> >>> ____________________________________________________________________ _____ >>> >>> _ >>> 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 > >> > ______________________________________________________________________ ____ > > 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 v2 iQEcBAEBCAAGBQJVNMTIAAoJEC5aWaUY1u57cUQH+QE2YUC3ki1dvspkzNavh4JS 3usKmLPS0vAXOjpYRN4MOJ1Y2FGblMqMvH5dN8Y2jGrimRy1G9zHR1C8J8n3H1X+ BZXd3wbqxCpfbgl95HA22oz4oZeRbm1i7WILxrLDmVFhwoNuLwuumpj/JqsK3LwZ HH9DZuWjaHaL7zOTcpGe1OhqVC1jEPRFokd8Yvz9rjrVqkrYinfuZV8OK8ZgDuO7 RBzl/dXMAKd9LFRfQUCaRmB/ePeO12Mhhv4JsXDeurHB2zWRF4MpVFzeK+GK8N5q UL/ikT2nb94zBg32L+IoFxVxo0HVFiFb5pBvZ5yurw8S9hvXvewr8mYDatzI/qI= =JD/s -----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