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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
