On Thu, Feb 11, 2016 at 10:04 AM, Armando M. <arma...@gmail.com> wrote: > I believe we have more recovery options out a potentially fatal situation. > In fact the offline script can provide a dry-run option that can just > validate that the migration will succeed before it is even actually > performed; I think that the size and the amount of tables involved in the > data migration justifies this course of action rather than the other. Think > about what Sean said, bugs are always lurking in the dark and as much as we > can strive for correctness, things might go bad. This is not a routine > migration and some operators may not be in a rush to embrace pluggable IPAM, > hence I don't think we are in the position to make the decision on their > behalf and go through the usual fast-path deprecation process.
I had a long discussion with Armando about this. I was pretty stubborn but there was one point that came up that got through and got me thinking. Basically, it is that having the ability to migrate to pluggable IPAM in Mitaka could be a key component to giving users a path to migrate to a 3rd party pluggable implementation. Without it, 3rd parties will have to support two kinds of migration: one for each of the drivers currently available. The only way to get something in to Mitaka is do to an offline migration. I agree that we shouldn't do the full automatic switch this late in the cycle. So, is this worth getting in to Mitaka to help this use case? If it is a significantly important component of migrating to 3rd party IPAM then maybe the answer should be yes. If it is just to help get people to the pluggable internal implementation in Mitaka then I'd say no because it it doesn't provide any user visible advantage and it doesn't yet have the gate testing miles on it that the old implementation has. Carl __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
