Open Stack

On 26/08/15 07:46, Paul Michali wrote:
> Previous post only went to dev list. Ensuring both and adding a bit more...
> 
> 
> 
> On Tue, Aug 25, 2015 at 8:37 AM Paul Michali <pc at michali.net> wrote:
> 
>> Xav,
>>
>> The discussion is very important, and hence why both Kyle and I have been
>> posting these questions on the operator (and dev) lists. Unfortunately, I
>> wasn't subscribed to the operator's list and missed some responses to
>> Kyle's message, which were posted only to that list.
>>
>> As a result, I had an incomplete picture and posted this thread to see if
>> it was OK to do this without backward compatibility, based on the
>> (incorrect) assumption that there was no production use. That is corrected
>> now, and I'm getting all the messages and thanks to everyone, have input on
>> messages I missed.
>>
>> So given that, let's try a reset on the discussion, so that I can better
>> understand the issues...
>>
>> Do you feel that not having backward compatibility (but having a migration
>> path) would seriously affect you or would it be manageable?
>>
>> Is there pain for the customers beyond learning about the new API changes
>> and capabilities (something that would apply whether there is backward
>> compatibility or not)?
>>
> 
> Another implication of not having backwards compatibility would be that
> end-users would need to immediately switch to using the new API, once the
> migration occurs, versus doing so on their own time frame.  Would this be a
> concern for you (customers not having the convenience of delaying their
> switch to the new API)?
> 
> 
>> I was thinking that backward incompatible changes would adversely affect
>> people who were using client scripts/apps to configure (a large number of)
>> IPsec connections, where they'd have to have client scripts/apps in-place
>> to support the new API.
>>
> 
> Which is more of a logistics issue, and could be managed, IMHO.
> 
> 
> 
>>
>> Would there be customers that would fall into that category, or are
>> customers manually configuring IPSec connections in that they could just
>> use the new API?
>>
>>
> Are there other adverse effects of not having backward compatibility that
>> need to be considered?
>>
> 
> So far, I'm identifying one effect that is more of a convenience (although
> nice one at that), and one effect that can be avoided by planning for the
> upgrade.  I'd like to know if I'm missing something more important to
> operators.
> 
> I'd also like to know if we thing there is a user base large enough (and
> how large is large?0 that would warrant going through the complexity and
> risk to support both API versions simultaneously?
> 
> Regards,
> 
> Paul Michali (pc_m)
> 
> 
>> Specifically, we're talking about the VPN service create API no longer
>> taking a subnet ID (instead an endpoint group is create that contains the
>> subnet ID), and the IPSec site-to-site connection create API would no
>> longer take a list of peer CIDRs, but instead would take a pair of endpoint
>> group IDs (one for the local subnet(s) formally specified by the service
>> API, and one for peer CIDRs).
>>
> 
> 
>>
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>>
>> On Mon, Aug 24, 2015 at 5:32 PM Xav Paice <xavpaice at gmail.com> wrote:
>>
>>> I'm sure I'm not the only one that finds the vast amount of traffic in
>>> the dev list to be completely unmanageable to catch the important messages
>>> - the ops list is much lower traffic, and as an operator I pay a bunch more
>>> attention to it.  The discussion of deprecating an API is something that
>>> HAS to be discussed with operators, on the operators list or highlighted
>>> somehow so that people get attention drawn to the message.
>>>
>>> Let's be clear - I fully appreciate the extra effort that would be
>>> required in supporting both the new and the old APIs, and also would
>>> absolutely love to see the new feature.  I do think we need to be able to
>>> support our customers in the transition, and extra pain for them results in
>>> lower uptake of the services we provide.
>>>
>>> On 25 August 2015 at 09:27, Xav Paice <xavpaice at gmail.com> wrote:
>>>
>>>> Also:
>>>>
>>>>
>>>> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007928.html
>>>>
>>>> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007891.html
>>>>
>>>>
>>>> On 25 August 2015 at 09:09, Kevin Benton <blak111 at gmail.com> wrote:
>>>>
>>>>> It sounds like you might have missed a couple responses:
>>>>>
>>>>>
>>>>> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html
>>>>>
>>>>> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html
>>>>>
>>>>>
>>>>> On Mon, Aug 24, 2015 at 1:53 PM, Paul Michali <pc at michali.net> wrote:
>>>>>
>>>>>> Xav,
>>>>>>
>>>>>> In the email, there were no responses of anyone using VPNaaS *in a
>>>>>> production environment*. Summary from responders:
>>>>>>
>>>>>> Erik M - Tried in Juno with no success. Will retry.
>>>>>> Edgar M - said no reports from operators about VPNaaS code
>>>>>> Sam S - Using VPN in VMs and not VPNaaS
>>>>>> Kevin B - Not used. Use VMs instead
>>>>>> Sriram S - Indicating not used.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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).
>>>>>>
>>>>>> I hope that clarifies the discussion.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Paul Michali (pc_m)
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 24, 2015 at 3:50 PM Xav Paice <xavpaice at gmail.com> wrote:
>>>>>>
>>>>>>> On 25/08/15 06:32, Paul Michali wrote:
>>>>>>>
>>>>>>> As part of the effort to provide support for multiple local subnets
>>>>>>> for VPNaaS IPSec connections, there are three API changes planned [1].
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>> As a result, we'd like to propose making this change as a
>>>>>>> non-backward compatible change, which greatly reduces the effort.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Paul Michali (IRC pc_m)
>>>>>>> VPNaaS Core
>>>>>>>
>>>>>>> Ref: https://review.openstack.org/#/c/191944/
>>>>>>>
>>>>>>>
>>>>>>> __________________________________________________________________________
>>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> __________________________________________________________________________
>>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>>> Unsubscribe:
>>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kevin Benton
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
James Dempsey
Senior Cloud Engineer
Catalyst IT Limited
+64 4 803 2264
--