Open Stack

In LBaaS with going with two distinct endpoints we were sort of skirting the backwards compatibility problem, e.g. People need to go full V2 with their infrastructure or stay at V1. This was informed by our understanding that nobody in his right mind would run V1… but believe me people are crazy :-)

IN LBaaS we also didn’t allow to run V1 and V2 side-by-side aka you had to choose only one for your installation. I think we could technically achieve that (especially if we have a new DB for V2) but I am not sure if it’s worth the hassle...

For LBaaS doing the hard break had side effects: Despite the API being around for two cycles we still don’t have Horizon support in LBaaS V2 (which is changing) - so if we can avoid the hard break in FWaaS and invest in some API compatibility layer all those things like Horizon, Heat, etc. can update at their leisure while still working with V2. That is the first thing which needs to be decided.

Secondly, if we decide that we allow the use of both versions side-by-side that will ask for a different design than if we would just do a hard breaK. So let’s assume we have an API compatibility layer than I would think the [3] would work with the new stuff using the custom header and the old stuff would not. 

German



On 1/2/16, 4:03 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM> wrote:

>On Sat, 2016-01-02 at 22:23 +0000, Sean M. Collins wrote:
>> I was on Twitter and got linked to this blog post[1], and then got
>> linked over to Terraform's docs, and of course I went and checked out
>> its support for OpenStack.
>> 
>> Well, what do you know? It has support for Firewall[2]! Yay!
>> 
>> Based on the fact that we have a spec for a v2 API - the question
>> becomes - how do we not break all this?
>> 
>> I see that LBaaS went the route of
>> 
>> v1 api = "/lb"
>> v2 api = "/lbaas"
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancer.py#L32
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancerv2.py#L34
>> 
>
>Yeah, this was kind of a best bad option at the time.
>
>> So - I guess we take the same route with FwaaS - maybe have the endpoint
>> at "/fwaas" and then hopefully we can implement microversioning[3]? That
>> way, we never have to make another endpoint like "/firewall" if we come up with a v3 API in the 2020s.
>
>I hope too that microversioning will fix this as well, but I'm not so
>sure it will as it is proposed.  I might be overlooking something but I
>can't seem how a neutron microversion can handle both neutron's api and
>a fwaas/lbaas/vpnaas api that may or may not be enabled.
>
>Definitely needs more discussion though, because it would be nice if it
>does solve this problem.
>
>> 
>> [1]: http://tech.paulcz.net/2016/01/openstacks-and-ecosystems/
>> 
>> [2]: https://terraform.io/docs/providers/openstack/r/fw_firewall_v1.html
>> 
>> [3]: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
>> 
>
>Thanks,
>Brandon
>__________________________________________________________________________
>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