Open Stack

On 11 February 2016 at 07:01, John Belamaric <jbelamaric at infoblox.com>
wrote:

>
>
> ---
> John Belamaric
> (240) 383-6963
>
> > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
> >
> > What’s the user visible change in behaviour after the switch? If it’s
> only internal implementation change, I don’t see why we want to leave the
> choice to operators.
> >
>
> It is only internal implementation changes.
>

That's not entirely true, is it? There are config variables to change and
it opens up the possibility of a scenario that the operator may not care
about.


>
>
> >> The other aspect is the deprecation process. If you add the switch into
> the DB migration path then the whole deprecation becomes superseded as the
> old IPAM logic should be abandoned immediately after that. But perhaps the
> other way of looking at it is that we should make an exception in the
> deprecation process.
> >>
> >> Salvatore
> >>
> >> On 11 February 2016 at 00:19, Carl Baldwin <carl at ecbaldwin.net> wrote:
> >> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <armamig at gmail.com> wrote:
> >> > Technically we can make this as sophisticated and seamless as we
> want, but
> >> > this is a one-off, once it's done the pain goes away, and we won't be
> doing
> >> > another migration like this ever again. So I wouldn't over engineer
> it.
> >>
> >> Frankly, I was worried that going the other way was over-engineering
> >> it.  It will be more difficult for us to manage this transition.
> >>
> >> I'm still struggling to see what makes this particular migration
> >> different than other cases where we change the database schema and the
> >> code a bit and we automatically migrate everyone to it as part of the
> >> routine migration.  What is it about this case that necessitates
> >> giving the operator the option?
> >>
> >> Carl
> >>
> >>
> __________________________________________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/9ab83cef/attachment.html>