<div dir="ltr">Thanks for the links and thoughtful comments James!<div><br></div><div>In the Heat documentation, is the subnet ID being treated as optional (or is the documentation not correct)? I think it is a required argument in the REST API. <span style="line-height:1.5;font-size:13.1999998092651px">Ref: <a href="http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::VPNService">http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::VPNService</a></span></div><div><br></div><div>It really sounds like we need to support both versions simultaneously, to avoid some of the complexity that you are mentioning (I didn't know about the Heat aspects).</div><div><br></div><div>We (development) should focus on formulating a plan for supporting both versions. Hopefully my proposal in <a href="https://review.openstack.org/#/c/191944/">https://review.openstack.org/#/c/191944/</a> is a good starting point.  I'll respond to comments on that today.</div><div><br></div><div>Regards,</div><div><br></div><div>Paul Michali (pc_m)</div><div><br></div><div>P.S. BTW: No offense taken in comments - email is such an imprecise communication medium.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 7:11 PM James Dempsey <<a href="mailto:jamesd@catalyst.net.nz">jamesd@catalyst.net.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 26/08/15 23:43, Paul Michali wrote:<br>
> James,<br>
><br>
> Great stuff! Please see @PCM in-line...<br>
><br>
> On Tue, Aug 25, 2015 at 6:26 PM James Dempsey <<a href="mailto:jamesd@catalyst.net.nz" target="_blank">jamesd@catalyst.net.nz</a>><br>
<br>
<SNIP><br>
<br>
>> 1) Horizon compatibility<br>
>><br>
>> We run a newer version of horizon than we do neutron.  If Horizon<br>
>> version X doesn't work with Neutron version X-1, this is a very big<br>
>> problem for us.<br>
>><br>
><br>
> @PCM Interesting. I always thought that Horizon updates lagged Neutron<br>
> changes, and this wouldn't be a concern.<br>
><br>
<br>
@JPD<br>
Our Installed Neutron typically lags Horizon by zero or one release.  My<br>
concern is how will Horizon version X cope with a point-in-time API<br>
change?  Worded slightly differently: We rarely update Horizon and<br>
Neutron at the same time so there would need to be a version(or<br>
versions) of Horizon that could detect a Neutron upgrade and start using<br>
the new API.  (I'm fine if there is a Horizon config option to select<br>
old/new VPN API usage.)<br>
<br>
><br>
><br>
>><br>
>> 2) Service interruption<br>
>><br>
>> How much of a service interruption would the 'migration path' cause?<br>
><br>
><br>
> @PCM The expectation of the proposal is that the migration would occur as<br>
> part of the normal OpenStack upgrade process (new services installed,<br>
> current services stopped, database migration occurs, new services are<br>
> started).<br>
><br>
> It would have the same impact as what would happen today, if you update<br>
> from one release to another. I'm sure you folks have a much better handle<br>
> on that impact and how to handle it (maintenance windows, scheduled<br>
> updates, etc).<br>
><br>
<br>
@JPD This seems fine.<br>
<br>
><br>
> We<br>
>> all know that IPsec VPNs can be fragile...  How much of a guarantee will<br>
>> we have that migration doesn't break a bunch of VPNs all at the same<br>
>> time because of some slight difference in the way configurations are<br>
>> generated?<br>
>><br>
><br>
> @PCM I see the risk as extremely low. With the migration, the end result is<br>
> really just moving/copying fields from one table to another. The underlying<br>
> configuration done to *Swan would be the same.<br>
><br>
> For example, the subnet ID, which is specified in the VPN service API and<br>
> stored in the vpnservices table, would be stored in a new vpn_endpoints<br>
> table, and the ipsec_site_connections table would reference that entry<br>
> (rather than looking up the subnet in the vpnservices table).<br>
><br>
<br>
@JPD This makes me feel more comfortable; thanks for explaining.<br>
<br>
><br>
><br>
>> 3) Heat compatibility<br>
>><br>
>> We don't always run the same version of Heat and Neutron.<br>
>><br>
><br>
> @PCM I must admit, I've never used Heat, and am woefully ignorant about it.<br>
> Can you elaborate on Heat concerns as may be related to VPN API differences?<br>
><br>
> Is Heat being used to setup VPN connections, as part of orchestration?<br>
><br>
<br>
@JPD<br>
My concerns are two-fold:<br>
<br>
1) Because Heat makes use of the VPNaaS API, it seems like the same<br>
situation exists as with Horizon.  Some version or versions of Heat will<br>
need to be able to make use of both old and new VPNaaS APIs in order to<br>
cope with a Neutron upgrade.<br>
<br>
2) Because we use Heat resource types like<br>
OS::Neutron::IPsecSiteConnection [1], we may lose the ability to<br>
orchestrate VPNs if endpoint groups are not added to Heat at the same time.<br>
<br>
<br>
Number 1 seems like a real problem that needs a fix.  Number 2 is a fact<br>
of life that I am not excited about, but am prepared to deal with.<br>
<br>
Yes, Heat is being used to build VPNs, but I am prepared to make the<br>
decision on behalf of my users... VPN creation via Heat is probably less<br>
important than the new VPNaaS features, but it would be really great if<br>
we could work on the updated heat resource types in parallel.<br>
<br>
[1]<br>
<a href="http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::IPsecSiteConnection" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::IPsecSiteConnection</a><br>
<br>
><br>
><br>
>><br>
>>>><br>
>>>> Is there pain for the customers beyond learning about the new API<br>
>> changes<br>
>>>> and capabilities (something that would apply whether there is backward<br>
>>>> compatibility or not)?<br>
>>>><br>
>><br>
>> See points 1,2, and 3 above.<br>
>><br>
><br>
>>><br>
>>> Another implication of not having backwards compatibility would be that<br>
>>> end-users would need to immediately switch to using the new API, once the<br>
>>> migration occurs, versus doing so on their own time frame.  Would this<br>
>> be a<br>
>>> concern for you (customers not having the convenience of delaying their<br>
>>> switch to the new API)?<br>
>>><br>
>>><br>
>>>> I was thinking that backward incompatible changes would adversely affect<br>
>>>> people who were using client scripts/apps to configure (a large number<br>
>> of)<br>
>>>> IPsec connections, where they'd have to have client scripts/apps<br>
>> in-place<br>
>>>> to support the new API.<br>
>>>><br>
>><br>
>> This is actually less of a concern.  We have found that VPN creation is<br>
>> mostly done manually and anyone who is clever enough to make IPsec go is<br>
>> clever enough to learn a new API/horizon interface.<br>
>><br>
><br>
> @PCM Do you see much reliance on tooling to setup VPN (such that having to<br>
> update the tooling would be a concern for end-users), or is this something<br>
> that could be managed through process/preparation?<br>
><br>
<br>
@JPD  I see very little reliance on tooling to setup VPNs.  We could<br>
manage this through preparation.<br>
<br>
><br>
><br>
>><br>
>>><br>
>>> Which is more of a logistics issue, and could be managed, IMHO.<br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>> Would there be customers that would fall into that category, or are<br>
>>>> customers manually configuring IPSec connections in that they could just<br>
>>>> use the new API?<br>
>>>><br>
>><br>
>> Most customers could easily adapt to a new API.<br>
>><br>
>>>><br>
>>> Are there other adverse effects of not having backward compatibility that<br>
>>>> need to be considered?<br>
>>>><br>
>><br>
>> As with the dashboard, heat also needs a bit of consideration.  How<br>
>> would Heat deal with the API changes?<br>
>><br>
><br>
> @PCM I don't know and will try to learn more. Is Heat used to configure VPN<br>
> connections? I need to understand more about the relationship there.<br>
><br>
<br>
@JPD I've emailed Heat/Horizon devs to ask about the impact.<br>
<br>
The issue I see is that Heat contains information about the structure of<br>
Neutron Resources (see: [2]).  This would force a coupling of neutron<br>
and heat versions in a way that previously was not required, if we want<br>
to maintain support for VPNs in Heat.<br>
<br>
[2]<br>
<a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/vpnservice.py" rel="noreferrer" target="_blank">https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/vpnservice.py</a><br>
<br>
<br>
><br>
><br>
>>><br>
>>> So far, I'm identifying one effect that is more of a convenience<br>
>> (although<br>
>>> nice one at that), and one effect that can be avoided by planning for the<br>
>>> upgrade.  I'd like to know if I'm missing something more important to<br>
>>> operators.<br>
>>><br>
>>> I'd also like to know if we thing there is a user base large enough (and<br>
>>> how large is large?0 that would warrant going through the complexity and<br>
>>> risk to support both API versions simultaneously?<br>
>><br>
>> This is a bit frustrating...  It implies that only large clouds matter.<br>
>><br>
><br>
> @PCM Sorry. That's not the intent of the statement that I was trying to get<br>
> across.<br>
><br>
> At the time I made the statement, my only knowledge of a need for<br>
> supporting multiple simultaneous versions was to accommodate client tools<br>
> (which could be handled via proper planning,IMHO) and end-users who would<br>
> like to switch to the newer API on their own schedule, versus when the<br>
> cloud is upgraded.<br>
><br>
> If there aren't many people who need that flexibility, then I'm asking<br>
> whether it makes sense to assume the effort and risk in getting this right,<br>
> as it is not easy.<br>
><br>
> I was "assuming" that if there is a large number of end-users wanting this<br>
> flexibility, that an operator would feel compelled to insist on this<br>
> capability.<br>
><br>
> From your case, it doesn't sound like that aspect is a concern at all (end<br>
> users would just adapt to the new version immediately).  It sounds like<br>
> Horizon and Heat are more of a concern for you.<br>
><br>
<br>
@JPD Correct.  Essentially, we don't really mind if we have to change<br>
our tooling, but we would *really* like to avoid being forced to upgrade<br>
Heat, Horizon, and Neutron all at the same time and to the same<br>
versions.  This would be a step backwards on the path to painless<br>
rolling upgrades.<br>
<br>
><br>
><br>
>  There is a further tacit implication the API is not really a contract<br>
>> that can be relied upon.<br>
>><br>
><br>
> @PCM Not sure I follow that statement. Can you elaborate on what you mean?<br>
<br>
@JPD I suppose it was an expression of frustration at feeling like<br>
backwards-incompatible API changes are being made lightly.  Possibly not<br>
the most productive thing to say.  I hope it wasn't offensive.<br>
<br>
><br>
> I'm not talking about not supporting an API version in some cases. I'm<br>
> talking about not supporting two API versions *simultaneously.*<br>
><br>
<br>
@JPD Yeah, I'm just worried about that point where support switches<br>
over.  I suspect that there be dragons.<br>
<br>
><br>
><br>
>> We are operating a multi-region cloud with many clients who depend upon<br>
>> VPNaaS for business-critical production workloads.<br>
>><br>
>> Of course, this is a two-way road!  We all want what is best for<br>
>> OpenStack, so we should talk about the complexity and risk on your end.<br>
>>  Can you tell us more about that?<br>
><br>
><br>
> @PCM Sure. I updated the developer reference document on this design, which<br>
> is under review. Check out <a href="https://review.openstack.org/#/c/191944/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/191944/</a>,<br>
> especially towards the bottom, where there is a section added with my<br>
> initial thoughts on how to handle backward compatibility. I'd appreciate<br>
> feedback in the review for any comments, questions, concerns you may have.<br>
><br>
<br>
@JPD Thanks.  Looks good after a quick first pass(just added a couple of<br>
small questions.)  I'll take a more critical look later(hopefully today?)<br>
<br>
<br>
><br>
><br>
>> I really have no interest in being an<br>
>> operator who demands the world from developers, but I am worried about<br>
>> what all this means for my cloud.<br>
>><br>
><br>
> @PCM Understood completely, and is why I appreciate the discussion on this.<br>
> As a developer, I'm trying to provide a (great? :) feature, without<br>
> over-engineering things. I'm trying to strike a balance between risk,<br>
> effort, and capability.<br>
><br>
<br>
@JPD Let me be clear: my users are *VERY* excited about this.  Thanks<br>
and keep up the great work!<br>
<br>
> Regards,<br>
><br>
> Paul Michali (pc_m)<br>
><br>
><br>
><br>
><br>
>><br>
>> Cheers,<br>
>> James Dempsey<br>
>><br>
>> --<br>
>> James Dempsey<br>
>> Senior Cloud Engineer<br>
>> Catalyst IT Limited<br>
>> +64 4 803 2264<br>
>> --<br>
>><br>
>><br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Paul Michali (pc_m)<br>
>>><br>
>>><br>
>>>> Specifically, we're talking about the VPN service create API no longer<br>
>>>> taking a subnet ID (instead an endpoint group is create that contains<br>
>> the<br>
>>>> subnet ID), and the IPSec site-to-site connection create API would no<br>
>>>> longer take a list of peer CIDRs, but instead would take a pair of<br>
>> endpoint<br>
>>>> group IDs (one for the local subnet(s) formally specified by the service<br>
>>>> API, and one for peer CIDRs).<br>
>>>><br>
>>><br>
>>><br>
>>>><br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Paul Michali (pc_m)<br>
>>>><br>
>>>><br>
>>>> On Mon, Aug 24, 2015 at 5:32 PM Xav Paice <<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>> wrote:<br>
>>>><br>
>>>>> I'm sure I'm not the only one that finds the vast amount of traffic in<br>
>>>>> the dev list to be completely unmanageable to catch the important<br>
>> messages<br>
>>>>> - the ops list is much lower traffic, and as an operator I pay a bunch<br>
>> more<br>
>>>>> attention to it.  The discussion of deprecating an API is something<br>
>> that<br>
>>>>> HAS to be discussed with operators, on the operators list or<br>
>> highlighted<br>
>>>>> somehow so that people get attention drawn to the message.<br>
>>>>><br>
>>>>> Let's be clear - I fully appreciate the extra effort that would be<br>
>>>>> required in supporting both the new and the old APIs, and also would<br>
>>>>> absolutely love to see the new feature.  I do think we need to be able<br>
>> to<br>
>>>>> support our customers in the transition, and extra pain for them<br>
>> results in<br>
>>>>> lower uptake of the services we provide.<br>
>>>>><br>
>>>>> On 25 August 2015 at 09:27, Xav Paice <<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>>> Also:<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007928.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007928.html</a><br>
>>>>>><br>
>>>>>><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007891.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007891.html</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> On 25 August 2015 at 09:09, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>>> It sounds like you might have missed a couple responses:<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html</a><br>
>>>>>>><br>
>>>>>>><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Mon, Aug 24, 2015 at 1:53 PM, Paul Michali <<a href="mailto:pc@michali.net" target="_blank">pc@michali.net</a>><br>
>> wrote:<br>
>>>>>>><br>
>>>>>>>> Xav,<br>
>>>>>>>><br>
>>>>>>>> In the email, there were no responses of anyone using VPNaaS *in a<br>
>>>>>>>> production environment*. Summary from responders:<br>
>>>>>>>><br>
>>>>>>>> Erik M - Tried in Juno with no success. Will retry.<br>
>>>>>>>> Edgar M - said no reports from operators about VPNaaS code<br>
>>>>>>>> Sam S - Using VPN in VMs and not VPNaaS<br>
>>>>>>>> Kevin B - Not used. Use VMs instead<br>
>>>>>>>> Sriram S - Indicating not used.<br>
>>>>>>>><br>
>>>>>>>> If I misread the responses, or if someone has not spoken up, right<br>
>> now<br>
>>>>>>>> is the time to let us know of your situation and the impact this<br>
>> proposal<br>
>>>>>>>> would have on your use of VPNaaS IPSec site-to-site connections.<br>
>>>>>>>><br>
>>>>>>>> The request here, is that if operators are not using this in a<br>
>>>>>>>> production deployment where they need backward compatibility, then<br>
>> we'd<br>
>>>>>>>> like to avoid having to provide the complexity needed to support<br>
>> backward<br>
>>>>>>>> compatibility.<br>
>>>>>>>><br>
>>>>>>>> In the proposal, there are two APIs that would be changed with this<br>
>>>>>>>> enhancement. It's detailed in reference [1], and I can elaborate,<br>
>> if needed.<br>
>>>>>>>><br>
>>>>>>>> Please keep in mind, that users/operators using previous versions,<br>
>> can<br>
>>>>>>>> upgrade to the new version, and any existing VPNaaS configuration<br>
>> will be<br>
>>>>>>>> automatically migrated to the new table structures, so that<br>
>> existing IPSec<br>
>>>>>>>> connections would continue to operate with the new release.<br>
>>>>>>>><br>
>>>>>>>> The proposal would not support using the older APIs, once the new<br>
>> APIs<br>
>>>>>>>> are available. Client apps/scripts would need to be updated to use<br>
>> the new<br>
>>>>>>>> API (neutron client and the Horizon dashboard will be updated as<br>
>> part of<br>
>>>>>>>> the overall effort).<br>
>>>>>>>><br>
>>>>>>>> I hope that clarifies the discussion.<br>
>>>>>>>><br>
>>>>>>>> Regards,<br>
>>>>>>>><br>
>>>>>>>> Paul Michali (pc_m)<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On Mon, Aug 24, 2015 at 3:50 PM Xav Paice <<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>><br>
>> wrote:<br>
>>>>>>>><br>
>>>>>>>>> On 25/08/15 06:32, Paul Michali wrote:<br>
>>>>>>>>><br>
>>>>>>>>> As part of the effort to provide support for multiple local subnets<br>
>>>>>>>>> for VPNaaS IPSec connections, there are three API changes planned<br>
>> [1].<br>
>>>>>>>>><br>
>>>>>>>>> One is to add a new "endpoint groups" API that will describe what<br>
>> is<br>
>>>>>>>>> being connected. This is the place were local and peer subnets<br>
>> will be<br>
>>>>>>>>> specified. It will allow future VPN flavors to reuse this API for<br>
>> other<br>
>>>>>>>>> types of VPN endpoints.<br>
>>>>>>>>><br>
>>>>>>>>> The second is to modify the IPSec site connection API to make use<br>
>> of<br>
>>>>>>>>> this new endpoint groups API and no longer use the peer CIDRs<br>
>> arguments.<br>
>>>>>>>>><br>
>>>>>>>>> The third is to remove the subnet ID from the VPN service API, and<br>
>>>>>>>>> again, use the new endpoint groups API for this information (and<br>
>> to allow<br>
>>>>>>>>>> 1).<br>
>>>>>>>>><br>
>>>>>>>>> A previous email send out from Kyle Mestery, asking about the<br>
>>>>>>>>> production usage of VPNaaS, did not indicate that this service was<br>
>> used in<br>
>>>>>>>>> production by operators.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Not true.  There were replies indicating that it is indeed in use,<br>
>>>>>>>>> but perhaps not from operators of installations deemed significant<br>
>> enough -<br>
>>>>>>>>> what's the criteria here?<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> As a result, we'd like to propose making this change as a<br>
>>>>>>>>> non-backward compatible change, which greatly reduces the effort.<br>
>>>>>>>>><br>
>>>>>>>>> The change WILL support migration, so older databases can be<br>
>> migrated<br>
>>>>>>>>> to the new schema and continue to operate, with future changes<br>
>> using the<br>
>>>>>>>>> new API. This gives a smooth upgrade path to the new capability.<br>
>>>>>>>>><br>
>>>>>>>>> The change would NOT support the older API in parallel with the new<br>
>>>>>>>>> API, so users upgrading would need to also update any client<br>
>> scripts/tools<br>
>>>>>>>>> to use the revised/new VPN API.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> How will this integrate with Horizon?  The majority of our users<br>
>>>>>>>>> don't use the API directly, but use Horizon for the config, does<br>
>> this mean<br>
>>>>>>>>> we'll be tied in to using a particular version of Horizon to match<br>
>> Neutron?<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> If this is acceptable to operators, we'd like to go forward with<br>
>>>>>>>>> these plans. Please respond within 7 days of this email, if you<br>
>> have<br>
>>>>>>>>> concerns about the proposal.<br>
>>>>>>>>><br>
>>>>>>>>> Regards,<br>
>>>>>>>>><br>
>>>>>>>>> Paul Michali (IRC pc_m)<br>
>>>>>>>>> VPNaaS Core<br>
>>>>>>>>><br>
>>>>>>>>> Ref: <a href="https://review.openstack.org/#/c/191944/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/191944/</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
</blockquote></div>