Open Stack

-----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-pre
>
> 
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-----