Open Stack

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 <ihrachys at 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 <majopela at 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 <mestery at mestery.com> wrote:
>
>   On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka <ihrachys at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>  --
>  Kevin Benton
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>  --
>  Kevin Benton
>   _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150108/4a4941f3/attachment.html>