Open Stack

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