>From a jclouds code perspective, it's certainly possible to have multiple >versions in a module. I'm sure you've noticed the version identifier in the >package hierarchy.
The tricky bit will be when an OpenStack provider actually exposes multiple versions of an API to give its users time to migrate from one to the other. I haven't actually encountered this situation yet. AFAICT version isn't an explicit property of a service in the service catalog [1]. I *think* we'd have to create a EndpointToSupplierURI that would pick the appropriate API version for the jclouds code. There's probably more to it than that but that's what's off the top of my head. The devil's in the details. Do you have an OpenStack deployment running multiple versions of the Glance API? Everett [1] http://docs.openstack.org/trunk/openstack-compute/install/yum/content/keystone-service-endpoint-create.html On Nov 13, 2013, at 3:48 AM, Ignacio Mulas Viela wrote: > Thank you Everett for the welcome and the given hints! :) I will create a > JIRA issue and put my code as soon as I have something working so you guys > can see it asap. > > I would like to ask you something more about the version handling in > Jclouds. I was wondering if for example it is possible to have modules with > different versions (for example glance v1 and v2) or once a module is > upgraded the old version is only available in the previous built JClouds > versions (maven releases). Is this the case? > > Best regards, > Ignacio > > > 2013/11/12 Everett Toews <[email protected]> > >> This is great news Ignacio. Thanks for contributing! >> >> I see you already created a JIRA issue for adding PATCH [1]. Could you >> please also add a JIRA issue for the OpenStack Glance work you're doing? >> >> Something similar to the JIRA issue I created for OpenStack Marconi [2]. >> I've also added you to the contributors list in JIRA so you can work with >> it a bit easier. I assigned JCLOUDS-376 directly to you. >> >> Also another important bit of advice. Please do an initial PR for the >> Glance code you have as soon as possible. It should contain the absolute >> smallest amount of code that does something useful/testable. The earlier we >> can see some code the smoother everything will go. >> >> Take for example my initial PR for OpenStack Marconi [3] (you can ignore >> the Rackspace stuff). I only implemented the create(String) method of the >> Queue API. That's it, just one method but it still has all of the unit/live >> tests, metadata, and everything else around it. Which makes for a pretty >> good sized PR as it is. My next PR finished off the Queue API. Then the >> next PR was the Message API. Finally I'll do the Claims API. I think you >> get the idea. >> >> After the initial PR with just one method, subsequent PRs can be done for >> each API. >> >> Also, because this is OpenStack we have the ability to run the live tests >> via DevStack [4]. Please include a localrc that we can use to test your >> code against OpenStack Havana. See the work that Kris from Alcatel-Lucent >> has done for adding an API to OpenStack Neutron [5]. >> >> If you need help with any of this stuff, please don't hesitate to find us >> on IRC at #jclouds on freenode. >> >> Cheers, >> Everett >> >> [1] https://issues.apache.org/jira/browse/JCLOUDS-376 >> [2] https://issues.apache.org/jira/browse/JCLOUDS-340 >> [3] https://github.com/jclouds/jclouds-labs-openstack/pull/42 >> [4] http://devstack.org/ >> [5] https://github.com/jclouds/jclouds-labs-openstack/pull/47 >> >> >> On Nov 11, 2013, at 6:35 AM, Ignacio Mulas Viela wrote: >> >>> Hi everyone! >>> I am currently working in updating the glance v1 to v2 and I came across >>> with an API method (update an image) that requires a PATCH HTTP request. >> I >>> could not find the annotation PATCH as the other common HTTP requests are >>> implemented on the API methods. >>> >>> I would like to ask here what is the best place to implement a new type >> of >>> HTTP request so I can use it in the glance afterwards? Any suggestion? >>> >>> Thanks in advance! >>> Ignacio >> >>
