<div dir="ltr">It sounds like you might have missed a couple responses:<div><br></div><div><a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html</a><br></div><div><a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 1:53 PM, Paul Michali <span dir="ltr"><<a href="mailto:pc@michali.net" target="_blank">pc@michali.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Xav,<div><br></div><div>In the email, there were no responses of anyone using VPNaaS <b>in a production environment</b>. Summary from responders:<br></div><div><br></div><div>Erik M - Tried in Juno with no success. Will retry.</div><div>Edgar M - said no reports from operators about VPNaaS code</div><div dir="ltr"><div>Sam S - Using VPN in VMs and not VPNaaS</div><div>Kevin B - Not used. Use VMs instead</div><div>Sriram S - Indicating not used.</div><div><br></div><div>If I misread the responses, or if someone has not spoken up, right now is the time to let us know of your situation and the impact this proposal would have on your use of VPNaaS IPSec site-to-site connections.</div><div><br></div><div>The request here, is that if operators are not using this in a production deployment where they need backward compatibility, then we'd like to avoid having to provide the complexity needed to support backward compatibility.</div><div><br></div><div>In the proposal, there are two APIs that would be changed with this enhancement. It's detailed in reference [1], and I can elaborate, if needed.<br></div><div><br></div><div>Please keep in mind, that users/operators using previous versions, can upgrade to the new version, and any existing VPNaaS configuration will be automatically migrated to the new table structures, so that existing IPSec connections would continue to operate with the new release.</div><div><br></div><div>The proposal would not support using the older APIs, once the new APIs are available. Client apps/scripts would need to be updated to use the new API (neutron client and the Horizon dashboard will be updated as part of the overall effort).</div></div><div dir="ltr"><div dir="ltr"><div><br>I hope that clarifies the discussion.</div><div><br></div><div>Regards,</div><div><br></div><div>Paul Michali (pc_m)</div><div><div class="h5"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 24, 2015 at 3:50 PM Xav Paice <<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div>On 25/08/15 06:32, Paul Michali wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">As part of the effort to provide support for
        multiple local subnets for VPNaaS IPSec connections, there are
        three API changes planned [1].
        <div><br>
        </div>
        <div>One is to add a new "endpoint groups" API that will
          describe what is being connected. This is the place were local
          and peer subnets will be specified. It will allow future VPN
          flavors to reuse this API for other types of VPN endpoints.</div>
        <div><br>
        </div>
        <div>The second is to modify the IPSec site connection API to
          make use of this new endpoint groups API and no longer use the
          peer CIDRs arguments.</div>
        <div><br>
        </div>
        <div>The third is to remove the subnet ID from the VPN service
          API, and again, use the new endpoint groups API for this
          information (and to allow >1).</div>
        <div><br>
        </div>
        <div>A previous email send out from Kyle Mestery, asking about
          the production usage of VPNaaS, did not indicate that this
          service was used in production by operators.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    Not true.  There were replies indicating that it is indeed in use,
    but perhaps not from operators of installations deemed significant
    enough - what's the criteria here?</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>As a result, we'd like to propose making this change as a
          non-backward compatible change, which greatly reduces the
          effort.</div>
        <div><br>
        </div>
        <div>The change WILL support migration, so older databases can
          be migrated to the new schema and continue to operate, with
          future changes using the new API. This gives a smooth upgrade
          path to the new capability.</div>
        <div><br>
        </div>
        <div>The change would NOT support the older API in parallel with
          the new API, so users upgrading would need to also update any
          client scripts/tools to use the revised/new VPN API.</div>
      </div>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    How will this integrate with Horizon?  The majority of our users
    don't use the API directly, but use Horizon for the config, does
    this mean we'll be tied in to using a particular version of Horizon
    to match Neutron?<br>
    <br>
    <blockquote type="cite"></blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>If this is acceptable to operators, we'd like to go forward
          with these plans. Please respond within 7 days of this email,
          if you have concerns about the proposal.</div>
        <div><br>
        </div>
        <div>Regards,</div>
        <div><br>
        </div>
        <div>Paul Michali (IRC pc_m)</div>
        <div>VPNaaS Core</div>
        <div><br>
        </div>
        <div>Ref: <a href="https://review.openstack.org/#/c/191944/" target="_blank">https://review.openstack.org/#/c/191944/</a></div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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>
</blockquote></div></div></div></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>