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 <p...@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 <xavpa...@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 <xavpa...@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 <blak...@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 <p...@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 <xavpa...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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 -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
