Very interesting! Thanks Ignasi
On Mon, Feb 13, 2017 at 12:44 PM, Ignasi Barrera <ignasi.barr...@gmail.com> wrote: > For example, in old versions of our Chef API, when we supported Chef > 10, we injected the right cookbook parsers depending on the api > version (see [1]). The same concept could be used in the Keystone > module to return the v2 or v3 API depending on the api version > configured when creating the context. > > > [1] https://github.com/jclouds/jclouds-chef/blob/1.7.x/core/ > src/main/java/org/jclouds/chef/config/ChefParserModule.java#L305-L319 > > On 13 February 2017 at 12:40, Ignasi Barrera <ignasi.barr...@gmail.com> > wrote: > > I think we can have a smart Guice module that returns the right > > Keystone API depending on the value of the ApiVersion, so we can keep > > both implementations, each one with heir own packages. > > > > On 13 February 2017 at 12:29, Andrea Turli <andrea.tu...@gmail.com> > wrote: > >> Thanks Ignasi, > >> > >> just wondering what does it mean for jclouds to support multiple > versions > >> of the same API at the same time? For example, Keystone v3 may have > >> different API calls with different domain objects, so changing API > version > >> property could be not enough. Do we need to inject the right objects > using > >> Guice depending on the version? > >> > >> On Mon, Feb 13, 2017 at 12:09 PM, Ignasi Barrera <n...@apache.org> > wrote: > >> > >>> HI! > >>> > >>> We definitely want to support the new versions of the OpenStack APIs, > >>> and would love to have some help writing them :) Any contribution in > >>> that direction is very welcome, and we'll be happy to provide advice > >>> and guidance. > >>> > >>> In order to do that and support recent OpenStack versions, though, we > >>> might need to first implement Keystone v3, which is missing too, but > >>> we haven't had yet the time and hands to tackle this. I'd be pleased > >>> to help making this happen too! > >>> > >>> > >>> > >>> > >>> On 10 February 2017 at 18:36, Valentin Aitken > >>> <valentin.ait...@cloudsoftcorp.com> wrote: > >>> > Hi, > >>> > > >>> > Currently you can use org.jclouds.openstack.nova.v2_0.NovaApi > against > >>> v3 but > >>> > there are some differences which I wonder how to tackle. > >>> > > >>> > Basically I have two questions. > >>> > > >>> > 1. I'd like to check community's opinion regarding writing code for > >>> > OpenStack Nova v3 [1]. > >>> > What are people's thoughts, do you intend to drop v2 support and > >>> > move classes from org.jclouds.openstack.nova.v2_0 to > >>> > org.jclouds.openstack.nova.v3_0 or you want to support both? > >>> > > >>> > 2. My 1st question comes from a problem I hit with destroying > security > >>> > groups in v3 on destroyNode. > >>> > It is that Createserverext ( os-create-server-ext API call) has > been > >>> > removed from OpenStack v3 [2]. > >>> > Security groups are now available in NodeMetadata and for v3 that > >>> > extension is not needed. > >>> > > >>> > > >>> > Regards, > >>> > Valentin Aitken! > >>> > > >>> > [1] > >>> > https://github.com/jclouds/jclouds/blob/master/apis/ > >>> openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_ > >>> 0/NovaApi.java#L53 > >>> > [2] https://wiki.openstack.org/wiki/NovaAPIv2tov3 > >>> >
