Open Stack

-----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)" <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:
>> 
> 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" <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
>>>>> 
>>> 
>>> ____________________________________________________________________
_____
>>>
>>> 
_
>>> 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
>
>> 
> ______________________________________________________________________
____
>
> 
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 v2

iQEcBAEBCAAGBQJVNMTIAAoJEC5aWaUY1u57cUQH+QE2YUC3ki1dvspkzNavh4JS
3usKmLPS0vAXOjpYRN4MOJ1Y2FGblMqMvH5dN8Y2jGrimRy1G9zHR1C8J8n3H1X+
BZXd3wbqxCpfbgl95HA22oz4oZeRbm1i7WILxrLDmVFhwoNuLwuumpj/JqsK3LwZ
HH9DZuWjaHaL7zOTcpGe1OhqVC1jEPRFokd8Yvz9rjrVqkrYinfuZV8OK8ZgDuO7
RBzl/dXMAKd9LFRfQUCaRmB/ePeO12Mhhv4JsXDeurHB2zWRF4MpVFzeK+GK8N5q
UL/ikT2nb94zBg32L+IoFxVxo0HVFiFb5pBvZ5yurw8S9hvXvewr8mYDatzI/qI=
=JD/s
-----END PGP SIGNATURE-----