Open Stack

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)" <jodavidg at 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 at Cisco
>
>
>
>
>On 20/02/2015 18:28, "Ihar Hrachyshka" <ihrachys at 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" <mestery at mestery.com
>>> <mailto:mestery at mestery.com>> wrote:
>>> 
>>> On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg)
>>> <jodavidg at cisco.com <mailto:jodavidg at 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 at Cisco
>>> 
>>> 
>>> 
>>> 
>>> On 13/02/2015 16:01, "Ihar Hrachyshka" <ihrachys at redhat.com
>>> <mailto:ihrachys at 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-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev