<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12.02.2016 15:01, Ihar Hrachyshka
wrote:<br>
</div>
<blockquote
cite="mid:C3C84071-2080-4A31-9FE3-9096CD8D029D@redhat.com"
type="cite">Salvatore Orlando <a class="moz-txt-link-rfc2396E" href="mailto:salv.orlando@gmail.com"><salv.orlando@gmail.com></a>
wrote:
<br>
<br>
<blockquote type="cite">On 11 February 2016 at 20:17, John
Belamaric <a class="moz-txt-link-rfc2396E" href="mailto:jbelamaric@infoblox.com"><jbelamaric@infoblox.com></a> wrote:
<br>
<br>
<blockquote type="cite">On Feb 11, 2016, at 12:04 PM, Armando M.
<a class="moz-txt-link-rfc2396E" href="mailto:armamig@gmail.com"><armamig@gmail.com></a> wrote:
<br>
<br>
<br>
<br>
On 11 February 2016 at 07:01, John Belamaric
<a class="moz-txt-link-rfc2396E" href="mailto:jbelamaric@infoblox.com"><jbelamaric@infoblox.com></a> wrote:
<br>
<br>
<br>
<br>
It is only internal implementation changes.
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
If we were to remove the non-pluggable version altogether, then
the default for ipam_driver would switch from None to internal.
Therefore, there would be no config file changes needed.
<br>
<br>
I think this is correct.
<br>
Assuming the migration path to Neutron will include the data
transformation from built-in to pluggable IPAM, do we just
remove the old code and models?
<br>
On the other hand do you think it might make sense to give
operators a chance to rollback - perhaps just in case some nasty
bug pops up?
<br>
</blockquote>
<br>
They can always revert to a previous release. And if we enable the
new implementation start of Newton, we’ll have enough time to fix
bugs that will pop up in gate.
<br>
<br>
</blockquote>
We are now in early Newton, so it is good time to discuss plan for
pluggable ipam for this release cycle.<br>
<br>
Kevin Benton commented on review page for current migration to
pluggable approach [1]:<br>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; white-space: pre-wrap; color: rgb(0, 0, 0); font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);">IMO this cannot be optional. It's going to be a nightmare to try to support two IPAM systems that people may have switched between at various points in time. I would much rather go all-in on the upgrade by making it automatic with alembic and removing the option to use the legacy IPAM code completely.</p>
<p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; white-space: pre-wrap; color: rgb(0, 0, 0); font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);">I've already been bitten by testing the new IPAM code with the config option and switching back which resulted in undeletable subnets. Now we can always yell at anyone that changes the config option like I did, but it takes a lot of energy to yell at users and they don't care for it much. :)</p>
<p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; white-space: pre-wrap; color: rgb(0, 0, 0); font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);">Even ignoring the support issue, consider schema changes. This migration script will have to be constantly updated to work with whatever the current state of the schema is on both sets of ipam tables. Without constant in-tree testing enforcing that, we are one schema change away from this script breaking.</p>
<p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; white-space: pre-wrap; color: rgb(0, 0, 0); font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);">So let's bite the bullet and make this a normal contract migration. Either the new ipam system is stable enough for us to commit to supporting it and fix whatever bugs it may have, or we need to remove it from the tree. Supporting both systems is unsustainable.</p>
</blockquote>
This sound reasonable to me. It simplify support and testing
(testing both implementations in gate with full coverage is not
easy).<br>
From user prospective there should be no visible changes between
pluggable ipam and non-pluggable.<br>
And making switch early in release cycle gives us enough time to fix
any bug we will find in pluggable implementation.<br>
<br>
Right now we have some open bugs for pluggable code [2], but they
are still possible to fix.<br>
<br>
Does it make sense to you?<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/277767/">https://review.openstack.org/#/c/277767/</a><br>
[2] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/neutron/+bug/1543094">https://bugs.launchpad.net/neutron/+bug/1543094</a><br>
<blockquote
cite="mid:C3C84071-2080-4A31-9FE3-9096CD8D029D@redhat.com"
type="cite">
<blockquote type="cite">What's the team level of confidence in the
robustness of the reference IPAM driver?
<br>
<br>
Salvatore
<br>
<br>
<br>
<br>
<br>
John
<br>
<br>
<br>
<br>
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage questions)
<br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
<br>
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage questions)
<br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
</blockquote>
<br>
<br>
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage questions)
<br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
</blockquote>
<br>
</body>
</html>