Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Kevin Benton
Thanks for the insight.

On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com
wrote:

 Correct, that’s the problem, what Kevin said should be the ideal case, but
 distros have
 proven to fail satisfying this kind of requirements earlier.

 So at least a warning to the user may be good to have IMHO.

 Miguel Ángel Ajo

 On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:

  The problem is probably due to the fact that some operators may run
 neutron from git and manage their dependencies in some other way; or
 distributions may suck sometimes, so packagers may miss the release note
 and fail to upgrade dnsmasq; or distributions may have their specific
 concerns on upgrading dnsmasq version, and would just backport the needed
 fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat world).

 On 01/08/2015 05:25 AM, Kevin Benton wrote:

 If the new requirement is expressed in the neutron packages for the
 distro, wouldn't it be transparent to the operators?

 On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com wrote:

  On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 Hi all,

 I've found out that dnsmasq  2.67 does not work properly for IPv6 clients
 when it comes to MAC address matching (it fails to match, and so clients
 get 'no addresses available' response). I've requested version bump to 2.67
 in: https://review.openstack.org/145482

  Good catch, thanks for finding this Ihar!


 Now, since we've already released Juno with IPv6 DHCP stateful support,
 and DHCP agent still has minimal version set to 2.63 there, we have a
 dilemma on how to manage it from stable perspective.

 Obviously, we should communicate the revealed version dependency to
 deployers via next release notes.

 Should we also backport the minimal version bump to Juno? This will result
 in DHCP agent failing to start in case packagers don't bump dnsmasq version
 with the next Juno release. If we don't bump the version, we may leave
 deployers uninformed about the fact that their IPv6 stateful instances
 won't get any IPv6 address assigned.

 An alternative is to add a special check just for Juno that would WARN
 administrators instead of failing to start DHCP agent.

 Comments?

  Personally, I think the WARN may be the best route to go. Backporting a
 change which bumps the required dnsmasq version seems like it may be harder
 for operators to handle.

 Kyle


 /Ihar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  --
  Kevin Benton


 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Miguel Ángel Ajo
Now that I re-read the patch.
Shouldn't the version checking  need to be converted into a sanity check?

Miguel Ángel Ajo


On Thursday, 8 de January de 2015 at 12:51, Kevin Benton wrote:

 Thanks for the insight.
  
 On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com 
 (mailto:majop...@redhat.com) wrote:
  Correct, that’s the problem, what Kevin said should be the ideal case, but 
  distros have
  proven to fail satisfying this kind of requirements earlier.
   
  So at least a warning to the user may be good to have IMHO.  
   
  Miguel Ángel Ajo
   
   
  On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:
   
   The problem is probably due to the fact that some operators may run 
   neutron from git and manage their dependencies in some other way; or 
   distributions may suck sometimes, so packagers may miss the release note 
   and fail to upgrade dnsmasq; or distributions may have their specific 
   concerns on upgrading dnsmasq version, and would just backport the needed 
   fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat world).

   On 01/08/2015 05:25 AM, Kevin Benton wrote:
If the new requirement is expressed in the neutron packages for the 
distro, wouldn't it be transparent to the operators?  
 
On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com 
(mailto:mest...@mestery.com) wrote:
 On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com 
 (mailto:ihrac...@redhat.com) wrote:
  Hi all,
   
  I've found out that dnsmasq  2.67 does not work properly for IPv6 
  clients when it comes to MAC address matching (it fails to match, 
  and so clients get 'no addresses available' response). I've 
  requested version bump to 2.67 in: 
  https://review.openstack.org/145482
   
 Good catch, thanks for finding this Ihar!
   
  Now, since we've already released Juno with IPv6 DHCP stateful 
  support, and DHCP agent still has minimal version set to 2.63 
  there, we have a dilemma on how to manage it from stable 
  perspective.
   
  Obviously, we should communicate the revealed version dependency to 
  deployers via next release notes.
   
  Should we also backport the minimal version bump to Juno? This will 
  result in DHCP agent failing to start in case packagers don't bump 
  dnsmasq version with the next Juno release. If we don't bump the 
  version, we may leave deployers uninformed about the fact that 
  their IPv6 stateful instances won't get any IPv6 address assigned.
   
  An alternative is to add a special check just for Juno that would 
  WARN administrators instead of failing to start DHCP agent.
   
  Comments?
   
 Personally, I think the WARN may be the best route to go. Backporting 
 a change which bumps the required dnsmasq version seems like it may 
 be harder for operators to handle.
  
 Kyle
   
  /Ihar
   
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org 
  (mailto:OpenStack-dev@lists.openstack.org)
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org 
 (mailto:OpenStack-dev@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 
 
--  
Kevin Benton  
 
___ OpenStack-dev mailing 
list OpenStack-dev@lists.openstack.org 
(mailto:OpenStack-dev@lists.openstack.org) 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org 
   (mailto:OpenStack-dev@lists.openstack.org)
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



   
   
   
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   
  
  
  
 --  
 Kevin Benton  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka

I agree, that is one thing we should not check in runtime.

In ideal world, it wouldn't even check version number, but capabilities. 
I's not clear though whether we can be any smarter than that (we would 
need to run dnsmasq and real dhcp clients to check actual capabilities).


/Ihar

On 01/08/2015 12:55 PM, Miguel Ángel Ajo wrote:

Now that I re-read the patch.
Shouldn't the version checking  need to be converted into a sanity check?

Miguel Ángel Ajo

On Thursday, 8 de January de 2015 at 12:51, Kevin Benton wrote:


Thanks for the insight.

On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com 
mailto:majop...@redhat.com wrote:
Correct, that’s the problem, what Kevin said should be the ideal 
case, but distros have

proven to fail satisfying this kind of requirements earlier.

So at least a warning to the user may be good to have IMHO.

Miguel Ángel Ajo

On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:

The problem is probably due to the fact that some operators may run 
neutron from git and manage their dependencies in some other way; 
or distributions may suck sometimes, so packagers may miss the 
release note and fail to upgrade dnsmasq; or distributions may have 
their specific concerns on upgrading dnsmasq version, and would 
just backport the needed fix to their 'claimed to 2.66' dnsmasq 
(common story in Red Hat world).


On 01/08/2015 05:25 AM, Kevin Benton wrote:
If the new requirement is expressed in the neutron packages for 
the distro, wouldn't it be transparent to the operators?


On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com 
mailto:mest...@mestery.com wrote:
On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka 
ihrac...@redhat.com mailto:ihrac...@redhat.com wrote:

Hi all,

I've found out that dnsmasq  2.67 does not work properly for 
IPv6 clients when it comes to MAC address matching (it fails to 
match, and so clients get 'no addresses available' response). 
I've requested version bump to 2.67 in: 
https://review.openstack.org/145482



Good catch, thanks for finding this Ihar!

Now, since we've already released Juno with IPv6 DHCP stateful 
support, and DHCP agent still has minimal version set to 2.63 
there, we have a dilemma on how to manage it from stable 
perspective.


Obviously, we should communicate the revealed version dependency 
to deployers via next release notes.


Should we also backport the minimal version bump to Juno? This 
will result in DHCP agent failing to start in case packagers 
don't bump dnsmasq version with the next Juno release. If we 
don't bump the version, we may leave deployers uninformed about 
the fact that their IPv6 stateful instances won't get any IPv6 
address assigned.


An alternative is to add a special check just for Juno that 
would WARN administrators instead of failing to start DHCP agent.


Comments?

Personally, I think the WARN may be the best route to go. 
Backporting a change which bumps the required dnsmasq version 
seems like it may be harder for operators to handle.


Kyle


/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Kevin Benton


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org  mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
mailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka
The problem is probably due to the fact that some operators may run 
neutron from git and manage their dependencies in some other way; or 
distributions may suck sometimes, so packagers may miss the release note 
and fail to upgrade dnsmasq; or distributions may have their specific 
concerns on upgrading dnsmasq version, and would just backport the 
needed fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat 
world).


On 01/08/2015 05:25 AM, Kevin Benton wrote:
If the new requirement is expressed in the neutron packages for the 
distro, wouldn't it be transparent to the operators?


On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com 
mailto:mest...@mestery.com wrote:


On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka
ihrac...@redhat.com mailto:ihrac...@redhat.com wrote:

Hi all,

I've found out that dnsmasq  2.67 does not work properly for
IPv6 clients when it comes to MAC address matching (it fails
to match, and so clients get 'no addresses available'
response). I've requested version bump to 2.67 in:
https://review.openstack.org/145482

Good catch, thanks for finding this Ihar!

Now, since we've already released Juno with IPv6 DHCP stateful
support, and DHCP agent still has minimal version set to 2.63
there, we have a dilemma on how to manage it from stable
perspective.

Obviously, we should communicate the revealed version
dependency to deployers via next release notes.

Should we also backport the minimal version bump to Juno? This
will result in DHCP agent failing to start in case packagers
don't bump dnsmasq version with the next Juno release. If we
don't bump the version, we may leave deployers uninformed
about the fact that their IPv6 stateful instances won't get
any IPv6 address assigned.

An alternative is to add a special check just for Juno that
would WARN administrators instead of failing to start DHCP agent.

Comments?

Personally, I think the WARN may be the best route to go.
Backporting a change which bumps the required dnsmasq version
seems like it may be harder for operators to handle.

Kyle

/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Miguel Ángel Ajo
Correct, that’s the problem, what Kevin said should be the ideal case, but 
distros have
proven to fail satisfying this kind of requirements earlier.

So at least a warning to the user may be good to have IMHO.  

Miguel Ángel Ajo


On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:

 The problem is probably due to the fact that some operators may run neutron 
 from git and manage their dependencies in some other way; or distributions 
 may suck sometimes, so packagers may miss the release note and fail to 
 upgrade dnsmasq; or distributions may have their specific concerns on 
 upgrading dnsmasq version, and would just backport the needed fix to their 
 'claimed to 2.66' dnsmasq (common story in Red Hat world).
  
 On 01/08/2015 05:25 AM, Kevin Benton wrote:
  If the new requirement is expressed in the neutron packages for the distro, 
  wouldn't it be transparent to the operators?  
   
  On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com 
  (mailto:mest...@mestery.com) wrote:
   On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com 
   (mailto:ihrac...@redhat.com) wrote:
Hi all,
 
I've found out that dnsmasq  2.67 does not work properly for IPv6 
clients when it comes to MAC address matching (it fails to match, and 
so clients get 'no addresses available' response). I've requested 
version bump to 2.67 in: https://review.openstack.org/145482
 
   Good catch, thanks for finding this Ihar!
 
Now, since we've already released Juno with IPv6 DHCP stateful support, 
and DHCP agent still has minimal version set to 2.63 there, we have a 
dilemma on how to manage it from stable perspective.
 
Obviously, we should communicate the revealed version dependency to 
deployers via next release notes.
 
Should we also backport the minimal version bump to Juno? This will 
result in DHCP agent failing to start in case packagers don't bump 
dnsmasq version with the next Juno release. If we don't bump the 
version, we may leave deployers uninformed about the fact that their 
IPv6 stateful instances won't get any IPv6 address assigned.
 
An alternative is to add a special check just for Juno that would WARN 
administrators instead of failing to start DHCP agent.
 
Comments?
 
   Personally, I think the WARN may be the best route to go. Backporting a 
   change which bumps the required dnsmasq version seems like it may be 
   harder for operators to handle.

   Kyle
 
/Ihar
 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 
(mailto:OpenStack-dev@lists.openstack.org)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org 
   (mailto:OpenStack-dev@lists.openstack.org)
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

   
   
   
  --  
  Kevin Benton  
   
  ___ OpenStack-dev mailing list 
  OpenStack-dev@lists.openstack.org 
  (mailto:OpenStack-dev@lists.openstack.org) 
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Salvatore Orlando
I think it should be possible to have a sanity check like the following:
 2.63 - sorry, that's not going to work
=2.63, 2.67 - it kind of works but ipv6 is going to be messed up
2.67 - we're all right

The runtime check on the dhcp agent is a startup check. Personally I think
agents should run sanity checks at startup, but if there are concerns
against that then let's separate runtime operations and sanity checks. In
any case the logic for the dnsmasq version checks should not be duplicated
- so if it's moved into sanity checks either the dhcp agent runs these
checks at startup, or they would be not run at all by the agent.

Salvatore

On 8 January 2015 at 13:17, Ihar Hrachyshka ihrac...@redhat.com wrote:

  I agree, that is one thing we should not check in runtime.

 In ideal world, it wouldn't even check version number, but capabilities.
 I's not clear though whether we can be any smarter than that (we would need
 to run dnsmasq and real dhcp clients to check actual capabilities).

 /Ihar


 On 01/08/2015 12:55 PM, Miguel Ángel Ajo wrote:

  Now that I re-read the patch.
 Shouldn't the version checking  need to be converted into a sanity check?

  Miguel Ángel Ajo

  On Thursday, 8 de January de 2015 at 12:51, Kevin Benton wrote:

   Thanks for the insight.

 On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com
 wrote:

  Correct, that’s the problem, what Kevin said should be the ideal case,
 but distros have
 proven to fail satisfying this kind of requirements earlier.

  So at least a warning to the user may be good to have IMHO.

  Miguel Ángel Ajo

On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:

   The problem is probably due to the fact that some operators may run
 neutron from git and manage their dependencies in some other way; or
 distributions may suck sometimes, so packagers may miss the release note
 and fail to upgrade dnsmasq; or distributions may have their specific
 concerns on upgrading dnsmasq version, and would just backport the needed
 fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat world).

 On 01/08/2015 05:25 AM, Kevin Benton wrote:

  If the new requirement is expressed in the neutron packages for the
 distro, wouldn't it be transparent to the operators?

 On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com wrote:

   On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 Hi all,

 I've found out that dnsmasq  2.67 does not work properly for IPv6 clients
 when it comes to MAC address matching (it fails to match, and so clients
 get 'no addresses available' response). I've requested version bump to 2.67
 in: https://review.openstack.org/145482

   Good catch, thanks for finding this Ihar!


  Now, since we've already released Juno with IPv6 DHCP stateful support,
 and DHCP agent still has minimal version set to 2.63 there, we have a
 dilemma on how to manage it from stable perspective.

 Obviously, we should communicate the revealed version dependency to
 deployers via next release notes.

 Should we also backport the minimal version bump to Juno? This will result
 in DHCP agent failing to start in case packagers don't bump dnsmasq version
 with the next Juno release. If we don't bump the version, we may leave
 deployers uninformed about the fact that their IPv6 stateful instances
 won't get any IPv6 address assigned.

 An alternative is to add a special check just for Juno that would WARN
 administrators instead of failing to start DHCP agent.

 Comments?

   Personally, I think the WARN may be the best route to go. Backporting a
 change which bumps the required dnsmasq version seems like it may be harder
 for operators to handle.

 Kyle


  /Ihar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  --
  Kevin Benton


 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  --
  Kevin Benton
   ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing 
 

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka

On 01/07/2015 03:21 PM, Ihar Hrachyshka wrote:

Hi all,

I've found out that dnsmasq  2.67 does not work properly for IPv6 
clients when it comes to MAC address matching (it fails to match, and 
so clients get 'no addresses available' response). I've requested 
version bump to 2.67 in: https://review.openstack.org/145482


Now, since we've already released Juno with IPv6 DHCP stateful 
support, and DHCP agent still has minimal version set to 2.63 there, 
we have a dilemma on how to manage it from stable perspective.


Obviously, we should communicate the revealed version dependency to 
deployers via next release notes.


Should we also backport the minimal version bump to Juno? This will 
result in DHCP agent failing to start in case packagers don't bump 
dnsmasq version with the next Juno release. If we don't bump the 
version, we may leave deployers uninformed about the fact that their 
IPv6 stateful instances won't get any IPv6 address assigned.


An alternative is to add a special check just for Juno that would WARN 
administrators instead of failing to start DHCP agent.


Sent Juno fix for review: https://review.openstack.org/145784



Comments?

/Ihar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Carl Baldwin
On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton blak...@gmail.com wrote:
 If the new requirement is expressed in the neutron packages for the distro,
 wouldn't it be transparent to the operators?

I think the difficulty first lies with the distros.  If the required
new version isn't in an older version of the distro (e.g. Ubuntu
12.04) it may not be possible to update the new distro packages with
the new dependency.

If the distros are unable to provide the upgrade nicely to the
operators this is where it becomes difficult on operators because they
would have to go out of band to upgrade.

Carl

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Sean M. Collins
On Thu, Jan 08, 2015 at 11:53:24AM EST, Carl Baldwin wrote:
 On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton blak...@gmail.com wrote:
  If the new requirement is expressed in the neutron packages for the distro,
  wouldn't it be transparent to the operators?
 
 I think the difficulty first lies with the distros.  If the required
 new version isn't in an older version of the distro (e.g. Ubuntu
 12.04) it may not be possible to update the new distro packages with
 the new dependency.

+1 - I know for the Icehouse release when we bumped it to the current
minimum version we were concerned about 12.04 LTS. I think we settled on
2.63 since that was what was available in the main release channel,
or possibly what was being shipped in the cloud-archive repos.

-- 
Sean M. Collins

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-07 Thread Kevin Benton
If the new requirement is expressed in the neutron packages for the distro,
wouldn't it be transparent to the operators?

On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com wrote:

 On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 Hi all,

 I've found out that dnsmasq  2.67 does not work properly for IPv6
 clients when it comes to MAC address matching (it fails to match, and so
 clients get 'no addresses available' response). I've requested version bump
 to 2.67 in: https://review.openstack.org/145482

 Good catch, thanks for finding this Ihar!


 Now, since we've already released Juno with IPv6 DHCP stateful support,
 and DHCP agent still has minimal version set to 2.63 there, we have a
 dilemma on how to manage it from stable perspective.

 Obviously, we should communicate the revealed version dependency to
 deployers via next release notes.

 Should we also backport the minimal version bump to Juno? This will
 result in DHCP agent failing to start in case packagers don't bump dnsmasq
 version with the next Juno release. If we don't bump the version, we may
 leave deployers uninformed about the fact that their IPv6 stateful
 instances won't get any IPv6 address assigned.

 An alternative is to add a special check just for Juno that would WARN
 administrators instead of failing to start DHCP agent.

 Comments?

 Personally, I think the WARN may be the best route to go. Backporting a
 change which bumps the required dnsmasq version seems like it may be harder
 for operators to handle.

 Kyle


 /Ihar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-07 Thread Kyle Mestery
On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 Hi all,

 I've found out that dnsmasq  2.67 does not work properly for IPv6 clients
 when it comes to MAC address matching (it fails to match, and so clients
 get 'no addresses available' response). I've requested version bump to 2.67
 in: https://review.openstack.org/145482

 Good catch, thanks for finding this Ihar!


 Now, since we've already released Juno with IPv6 DHCP stateful support,
 and DHCP agent still has minimal version set to 2.63 there, we have a
 dilemma on how to manage it from stable perspective.

 Obviously, we should communicate the revealed version dependency to
 deployers via next release notes.

 Should we also backport the minimal version bump to Juno? This will result
 in DHCP agent failing to start in case packagers don't bump dnsmasq version
 with the next Juno release. If we don't bump the version, we may leave
 deployers uninformed about the fact that their IPv6 stateful instances
 won't get any IPv6 address assigned.

 An alternative is to add a special check just for Juno that would WARN
 administrators instead of failing to start DHCP agent.

 Comments?

 Personally, I think the WARN may be the best route to go. Backporting a
change which bumps the required dnsmasq version seems like it may be harder
for operators to handle.

Kyle


 /Ihar

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev