Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-04-20 Thread Ihar Hrachyshka
-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 

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-03-12 Thread John Davidge (jodavidg)
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:

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

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-24 Thread John Davidge (jodavidg)
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:

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

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-20 Thread Ihar Hrachyshka
-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 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
 

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-19 Thread Robert Li (baoli)
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 
mest...@mestery.commailto:mest...@mestery.com wrote:

On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg) 
jodav...@cisco.commailto: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.commailto:ihrac...@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.
 

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-13 Thread Ihar Hrachyshka
-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 

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-13 Thread John Davidge (jodavidg)
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.

John Davidge
OpenStack@Cisco




On 13/02/2015 16:01, Ihar Hrachyshka ihrac...@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 

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

2015-02-13 Thread Kyle Mestery
On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg) 
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 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