<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 06.02.2016 00:03, Salvatore Orlando
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP0B2WOA56=uw3SEXp3EW-t11nBfnxbx8jhYodR2g0Q=Y81xQA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 5 February 2016 at 17:58, Neil
            Jerram <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class="">On 05/02/16 16:31, Pavel Bondar wrote:<br>
                > On 05.02.2016 12:28, Salvatore Orlando wrote:<br>
                >><br>
                >><br>
                >> On 5 February 2016 at 04:12, Armando M. <<a
                  moz-do-not-send="true" href="mailto:armamig@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:armamig@gmail.com">armamig@gmail.com</a></a><br>
              </span><span class="">>> <mailto:<a
                  moz-do-not-send="true" href="mailto:armamig@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:armamig@gmail.com">armamig@gmail.com</a></a>>>
                wrote:<br>
                >><br>
                >><br>
                >><br>
                >>     On 4 February 2016 at 08:22, John Belamaric<br>
              </span>>>     <<mailto:<a
                moz-do-not-send="true"
                href="mailto:jbelamaric@infoblox.com"><a class="moz-txt-link-abbreviated" href="mailto:jbelamaric@infoblox.com">jbelamaric@infoblox.com</a></a>><a
                moz-do-not-send="true"
                href="mailto:jbelamaric@infoblox.com"><a class="moz-txt-link-abbreviated" href="mailto:jbelamaric@infoblox.com">jbelamaric@infoblox.com</a></a>>
              wrote:<br>
              >><br>
              >><br>
              >>         > On Feb 4, 2016, at 11:09 AM, Carl
              Baldwin <<a moz-do-not-send="true"
                href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>
              <mailto:<a moz-do-not-send="true"
                href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>>>
              wrote:<br>
              <span class="">>>         ><br>
                >>         > On Thu, Feb 4, 2016 at 7:23 AM,
                Pavel Bondar <<a moz-do-not-send="true"
                  href="mailto:pbondar@infoblox.com">pbondar@infoblox.com</a>
                <mailto:<a moz-do-not-send="true"
                  href="mailto:pbondar@infoblox.com">pbondar@infoblox.com</a>>>
                wrote:<br>
                >>         >> I am trying to bring more
                attention to [1] to make final decision on<br>
                >>         >> approach to use.<br>
                >>         >> There are a few point that are
                not 100% clear for me at this point.<br>
                >>         >><br>
                >>         >> 1) Do we plan to switch all
                current clouds to pluggable ipam<br>
                >>         >> implementation in Mitaka?<br>
                <br>
              </span>I possibly shouldn't comment at all, as I don't
              know the history, and<br>
              wasn't around when the fundamental design decisions here
              were being made.<br>
              <br>
              However, it seems a shame to me that this was done in a
              way that needs a<br>
              DB migration at all.  (And I would have thought it
              possible for the<br>
              default pluggable IPAM driver to use the same DB state as
              the<br>
              non-pluggable IPAM backend, given that it is delivering
              the same<br>
              semantics.)  Without that, I believe it should be a
              no-brainer to switch<br>
              unconditionally to the pluggable IPAM backend.<br>
            </blockquote>
            <div><br>
            </div>
            <div>This was indeed the first implementation attempt that
              we made, but it failed spectacularly as we wrestled with
              different foreign key relationships in the original and
              new model.</div>
            <div>Pavel has all the details, but after careful
              considerations we decided to adopt a specular model with
              different db tables.</div>
          </div>
        </div>
      </div>
    </blockquote>
    Yeah, we had this chicken and egg problem on subnet creation.<br>
    <br>
    On the one hand, ipam driver create_subnet has to be called *before*
    creating neutron subnet.<br>
    Because for AnySubnetRequest ipam driver is responsible for
    selecting cidr for subnet.<br>
    <br>
    On the other hand, during ipam driver create_subnet call
    availability ranges has to be created,<br>
    but they are linked with neutron subnet using foreign key (with
    allocation pools in the middle).<br>
    So availability ranges could not be created before neutron subnet
    due to FK constraint in old tables.<br>
    <br>
    To solve this chicken and egg problem it was decided to use tables
    for reference driver that have no FK to neutron subnet.<br>
    And it allowed to call ipam driver create_subnet (and create
    availability ranges) before creating neutron subnet.<br>
    <blockquote
cite="mid:CAP0B2WOA56=uw3SEXp3EW-t11nBfnxbx8jhYodR2g0Q=Y81xQA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              Sorry if that's unhelpful...<br>
              <span class="HOEnZb"><font color="#888888"><br>
                          Neil<br>
                </font></span>
              <div class="HOEnZb">
                <div class="h5"><br>
                  <br>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                    rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                  <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
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>
<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>
</pre>
    </blockquote>
    <br>
  </body>
</html>