Open Stack

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:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQEbBAEBAgAGBQJU3h/vAAoJEC5aWaUY1u57f4gH8wWTMvYdIVwjJL9QjF9YTjMd
>AMEJZcBN7nAYcjsI8Oxx5rxYs4uKV8QA/RD0Cy2JhweQV0GdjtZMxxh2gt2rRF5E
>pV/kRsiQsyJFlaWgsnWccZ1IxXHHLufUbcqkW7+XMzLQ+T+xZfUllwxUBsWzZcR2
>nzedsSsF3wdIU7yw9iYp8iXiVLtHD0Ryq6dAJXiX15amWg46f1cDCcxhnIMJflCR
>AET+QR9QYzUSFgpMKmmab0VrGzyeWpqJ+lvVpFhhO+y5Iap7HsOZpAGwaUBihlui
>lnOD7223Ueqw9UQVo8JFSDh3tlwC8dP7mfEHK45DAvfkFdVJkk+w7PKzauUXhQ==
>=WdfD
>-----END PGP SIGNATURE-----
>
>__________________________________________________________________________
>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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150219/6f5237ea/attachment.html>