You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ignacio Mulas Viela <im...@gmail.com> on 2014/01/21 17:49:18 UTC
Glance implementation
Hi All,
I have some of the Glance v2 working already. Initially I created it as a
separate module but now I was trying to merge both version (v1 and v2) into
the same glance module so both implentations can be available and it is up
to the application to use v1 or v2.
I have a question here, the modules are using the service loader. This
means that there is a META-INF/services/org.jclouds.apis.ApiMetadata file
under the src/main/resources [1] which is hardcoded to the version of the
metadata class that you are using.
As the v1 and v2 contains a different metadata classes, is it possible to
give support to both versions at the same time in a module? Is there any
way of overriding the default value of the service file? Any suggestions
here?
Thanks in advance!
Ignacio
[1]
https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-glance/src/main/resources/META-INF/services/org.jclouds.apis.ApiMetadata
RE: Glance implementation
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
I wanted it to go on the record - I like this idea, if it can be done?
________________________________________
From: Andrew Phillips [aphillips@qrmedia.com]
Sent: Tuesday, January 21, 2014 11:00 AM
To: dev@jclouds.apache.org
Subject: Re: Glance implementation
> As the v1 and v2 contains a different metadata classes, is it possible to
> give support to both versions at the same time in a module? Is there any
> way of overriding the default value of the service file? Any suggestions
> here?
Even though the ServiceLoader spec *does* allow multiple
implementation classes in a META-INF/services file (see [1]), I'm not
sure the jclouds code is written to handle that (although it never
hurts to try ;-)).
How hard would it be to make a "glance-common" module and then create
two providers, "glance-v1" and "glance-v2" (or something like that)
which simply configure the appropriate metadata correctly?
That way, users could also choose to use one, or both of the versions
explicitly.
ap
[1] http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html
Re: Glance implementation
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Jan 21, 2014, at 11:14 AM, Ignasi Barrera wrote:
> As long as you have two ApiMetadata implementations **with different ids**,
> you can put both in the ServiceLoader file and jclouds will load them
> without problems, despite being in the same project.
>
> I don't know how much code is common or changes, but we already have some
> common openstack code in a separate project [1], so it could be good to
> have the common glance code there too, and have one project per glance
> version, to allow users to include only the specific version dependency in
> their pom.xml.
>
> [1] https://github.com/jclouds/jclouds/tree/master/common
Please don't do this. The openstack-common project is effectively deprecated.
All of the recent OpenStack common code has been going into openstack-keystone since all OpenStack services depend on Keystone anyway. Adrian started this effort years ago and I agree with this direction.
Everett
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
As long as you have two ApiMetadata implementations **with different ids**,
you can put both in the ServiceLoader file and jclouds will load them
without problems, despite being in the same project.
I don't know how much code is common or changes, but we already have some
common openstack code in a separate project [1], so it could be good to
have the common glance code there too, and have one project per glance
version, to allow users to include only the specific version dependency in
their pom.xml.
[1] https://github.com/jclouds/jclouds/tree/master/common
El 21/01/2014 18:01, "Andrew Phillips" <ap...@qrmedia.com> escribió:
> As the v1 and v2 contains a different metadata classes, is it possible to
>> give support to both versions at the same time in a module? Is there any
>> way of overriding the default value of the service file? Any suggestions
>> here?
>>
>
> Even though the ServiceLoader spec *does* allow multiple implementation
> classes in a META-INF/services file (see [1]), I'm not sure the jclouds
> code is written to handle that (although it never hurts to try ;-)).
>
> How hard would it be to make a "glance-common" module and then create two
> providers, "glance-v1" and "glance-v2" (or something like that) which
> simply configure the appropriate metadata correctly?
>
> That way, users could also choose to use one, or both of the versions
> explicitly.
>
> ap
>
> [1] http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html
>
Re: Glance implementation
Posted by Andrew Phillips <ap...@qrmedia.com>.
> As the v1 and v2 contains a different metadata classes, is it possible to
> give support to both versions at the same time in a module? Is there any
> way of overriding the default value of the service file? Any suggestions
> here?
Even though the ServiceLoader spec *does* allow multiple
implementation classes in a META-INF/services file (see [1]), I'm not
sure the jclouds code is written to handle that (although it never
hurts to try ;-)).
How hard would it be to make a "glance-common" module and then create
two providers, "glance-v1" and "glance-v2" (or something like that)
which simply configure the appropriate metadata correctly?
That way, users could also choose to use one, or both of the versions
explicitly.
ap
[1] http://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
Didn't know it was deprecated, and agree with Everett then :) If all common
code is now just the Keystone stuff and the openstack-common is deprecated
I'm also keen on having it all in the Glance repo.
El 21/01/2014 18:24, "Everett Toews" <ev...@rackspace.com> escribió:
> On Jan 21, 2014, at 10:49 AM, Ignacio Mulas Viela wrote:
>
> > Hi All,
> > I have some of the Glance v2 working already. Initially I created it as a
> > separate module but now I was trying to merge both version (v1 and v2)
> into
> > the same glance module so both implentations can be available and it is
> up
> > to the application to use v1 or v2.
>
> I think since you've already done the work to merge them, it's worthwhile
> to continue to see how it works out. My preference is to have fewer modules
> and fewer dependencies.
>
> If we start going down the path of breaking it out into glance-v1,
> glance-v2, and glance-common, we're going to see an explosion of OpenStack
> modules in jclouds as new versions of APIs are released in OpenStack land.
>
> > I have a question here, the modules are using the service loader. This
> > means that there is a META-INF/services/org.jclouds.apis.ApiMetadata file
> > under the src/main/resources [1] which is hardcoded to the version of the
> > metadata class that you are using.
> >
> > As the v1 and v2 contains a different metadata classes, is it possible to
> > give support to both versions at the same time in a module? Is there any
> > way of overriding the default value of the service file? Any suggestions
> > here?
>
> I think Ignassi answered this one. And I think the default should be for
> v2.
>
> Thanks for taking this on Ignacio!
>
> Everett
Re: Glance implementation
Posted by Jeremy Daggett <je...@gmail.com>.
This is awesome work Ignacio, and thanks again for the contribution!
I noticed the PR comments flying by here this afternoon from @nacx and
wanted to quickly point something out regarding OpenStack API versioning.
My experience has been that when there is an updated "v1" API, i.e. "v1.1"
or "v1.2", then it's *still* the "v1" API. For example, the "current" v2
Glance API is v2.2 [1], and the v1 API is v1.1. To my knowledge, nothing
has ever been removed from an dot version of an API, but I could definitely
be wrong. ;)
My opinion here is that going forward we should move away from package
names that use the "v1_0" or "v2_0" nomenclature. I propose that all
OpenStack APIs move to the more modern "vX" form, like "v1" or "v2".
Please take a look at the newer OpenStack Marconi [2] and OpenStack Swift
[3] APIs for additional reference.
Since the Glance APIs have not been promoted up and out of the
jclouds/jclouds-labs-openstack repo into jclouds/jclouds, this would be an
opportune time to address this. Its a small refactor of the code, however
it would give us additional momentum in standardizing the OpenStack package
version names across the codebase.
The OpenStack Neutron API still uses the "v2_0" [4] package naming, and I
submit that we would also change it before promotion to jclouds/jclouds. As
far as the Nova and Keystone API package names, we can discuss changing
them in a future jclouds release.
Thoughts? Does this warrant a JIRA?
/jd
[1]
https://github.com/openstack/glance/blob/master/glance/api/versions.py#L47
[2]
https://github.com/jclouds/jclouds-labs-openstack/tree/master/openstack-marconi/src/main/java/org/jclouds/openstack/marconi/v1
[3]
https://github.com/jclouds/jclouds-labs-openstack/tree/master/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1
[4]
https://github.com/jclouds/jclouds-labs-openstack/tree/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2_0
On Wed, Jan 22, 2014 at 1:45 AM, Ignacio Mulas Viela <immulasviela@gmail.com
> wrote:
> Nice! It worked perfectly. Seems that all the tests of v1 and v2 are
> running fine now :) Thanks!
>
> @Ignasi The problem was in the ID as you mentioned, thanks for pointing to
> the classes that handle the service loading part that part was a bit blurry
> for me.
>
> I will clean a bit the code and upload everything to github so you guys can
> have a look to the code :)
>
> Cheers!
> Ignacio
>
>
> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>
> > Just to add more information, here is where the ServiceLoader takes
> > place [1]. It actually loads all the implementations, but when looking
> > for an Api or Provider with a given id, the first one with that id is
> > returned [2, 3].
> >
> > That's why if you want to have different ApiMetadata classes you need
> > two different ids for them (regardless of if they are in the same
> > Maven project or are in separated ones). This also implies that you
> > will need to create two different Contexts if you want to access both
> > versions of a Glance Api, as one context is tied to just one
> > Api/Provider metadata.
> >
> >
> > Hope this clarifies a bit how it works!
> >
> >
> > [1]
> >
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/ContextBuilder.java#L163-L177
> > [2]
> >
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/providers/Providers.java#L89-L102
> > [3]
> >
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/apis/Apis.java#L77-L90
> >
> > On 21 January 2014 22:58, Everett Toews <ev...@rackspace.com>
> > wrote:
> > > A pastie or gist would be fine but in this case a pull request would be
> > even better. Just a work-in-progress PR for us to look at. It's not like
> we
> > would necessarily merge it either. It's just to share code and comment on
> > it.
> > >
> > > Everett
> > >
> > >
> > > On Jan 21, 2014, at 3:48 PM, Ignasi Barrera wrote:
> > >
> > >> Can you paste in a gist or pastie the GlanceApiMetadata classes?
> > >> Have you assigned a different ID to each, like "glance-v1" and
> > "glance-v2"?
> > >>
> > >> On 21 January 2014 22:27, Ignacio Mulas Viela <immulasviela@gmail.com
> >
> > wrote:
> > >>> I tried having in the ServiceLoader file the two APiMetadata, run the
> > tests
> > >>> and it only takes the first class that it is in the serviceLoader
> > file. If
> > >>> I put first the v2 ApiMetadata then the v1 tests fails due to a cast
> > >>> conversion problem. And viceversa if the first class is the v1. The
> > error
> > >>> is the following (in case v2 is first):
> > >>>
> > >>> Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52
> cannot
> > be
> > >>> cast to org.jclouds.openstack.glance.v1_0.GlanceApi
> > >>>
> > >>> The configuration file contains:
> > >>> org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
> > >>> org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
> > >>>
> > >>> Any clue about what I am missing here?
> > >>>
> > >>>
> > >>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
> > >>>
> > >>>> By default you don't have to do nothing apart from having the two
> > >>>> ApiMetadata classes and have them declared in the ServiceLoader
> file.
> > >>>> It will work :)
> > >>>>
> > >>>> Feel free to join the #jclouds IRC channel @Freenode if you want to
> > >>>> discuss it live!
> > >>>>
> > >>>> On 21 January 2014 21:58, Ignacio Mulas Viela <
> immulasviela@gmail.com
> > >
> > >>>> wrote:
> > >>>>> Thanks everyone for the discussion and the hints! I think I will
> try
> > to
> > >>>>> maintain everything inside one glance module and see where it goes,
> > If I
> > >>>>> can achieve the correct loading of the two services I think it will
> > be
> > >>>>> better than having the code divided in different projects as Glance
> > only
> > >>>>> contains one API (imageAPI).
> > >>>>>
> > >>>>> @Ignasi thanks for the implementation hints, I will try to
> > investigate
> > >>>> how
> > >>>>> I can implement the two contexts depending on the versions.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
> > >>>>>
> > >>>>>> With the described approach you'll need two contexts, one to use
> > each
> > >>>>>> version (as the ServiceLoader will create one instance of the
> > service
> > >>>> for
> > >>>>>> each).
> > >>>>>>
> > >>>>>> Depending on the complexity of the differences, perhaps it can be
> > >>>>>> configured with a single ApiMetadata and let Guice *provide* the
> > right
> > >>>>>> classes depending on the *apiVersion* (it can be configured when
> > >>>> creating
> > >>>>>> the context). jclouds-chef already does this to handle the
> > >>>> deserialization
> > >>>>>> of objects in different versions of the api [1] (see the peoviders
> > at
> > >>>> the
> > >>>>>> end of the file).
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>>>>
> > >>>>
> >
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
> > >>>>>> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
> > >>>> escribió:
> > >>>>>>
> > >>>>>>> If we start going down the path of breaking it out into
> glance-v1,
> > >>>>>>>> glance-v2, and glance-common, we're going to see an explosion of
> > >>>>>>>> OpenStack modules in jclouds as new versions of APIs are
> released
> > in
> > >>>>>>>> OpenStack land.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I wasn't very clear in my original answer: I was under the
> > impression
> > >>>>>> that
> > >>>>>>> the two versions cannot coexist simultaneously in the same
> > context. If
> > >>>>>>> there's no problem to have both of these loaded at the same time,
> > then
> > >>>>>>> let's definitely try to do that in one dependency!
> > >>>>>>>
> > >>>>>>> ap
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >
> >
>
Re: Glance implementation
Posted by Ignacio Mulas Viela <im...@gmail.com>.
Nice! It worked perfectly. Seems that all the tests of v1 and v2 are
running fine now :) Thanks!
@Ignasi The problem was in the ID as you mentioned, thanks for pointing to
the classes that handle the service loading part that part was a bit blurry
for me.
I will clean a bit the code and upload everything to github so you guys can
have a look to the code :)
Cheers!
Ignacio
2014/1/21 Ignasi Barrera <ig...@gmail.com>
> Just to add more information, here is where the ServiceLoader takes
> place [1]. It actually loads all the implementations, but when looking
> for an Api or Provider with a given id, the first one with that id is
> returned [2, 3].
>
> That's why if you want to have different ApiMetadata classes you need
> two different ids for them (regardless of if they are in the same
> Maven project or are in separated ones). This also implies that you
> will need to create two different Contexts if you want to access both
> versions of a Glance Api, as one context is tied to just one
> Api/Provider metadata.
>
>
> Hope this clarifies a bit how it works!
>
>
> [1]
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/ContextBuilder.java#L163-L177
> [2]
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/providers/Providers.java#L89-L102
> [3]
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/apis/Apis.java#L77-L90
>
> On 21 January 2014 22:58, Everett Toews <ev...@rackspace.com>
> wrote:
> > A pastie or gist would be fine but in this case a pull request would be
> even better. Just a work-in-progress PR for us to look at. It's not like we
> would necessarily merge it either. It's just to share code and comment on
> it.
> >
> > Everett
> >
> >
> > On Jan 21, 2014, at 3:48 PM, Ignasi Barrera wrote:
> >
> >> Can you paste in a gist or pastie the GlanceApiMetadata classes?
> >> Have you assigned a different ID to each, like "glance-v1" and
> "glance-v2"?
> >>
> >> On 21 January 2014 22:27, Ignacio Mulas Viela <im...@gmail.com>
> wrote:
> >>> I tried having in the ServiceLoader file the two APiMetadata, run the
> tests
> >>> and it only takes the first class that it is in the serviceLoader
> file. If
> >>> I put first the v2 ApiMetadata then the v1 tests fails due to a cast
> >>> conversion problem. And viceversa if the first class is the v1. The
> error
> >>> is the following (in case v2 is first):
> >>>
> >>> Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52 cannot
> be
> >>> cast to org.jclouds.openstack.glance.v1_0.GlanceApi
> >>>
> >>> The configuration file contains:
> >>> org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
> >>> org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
> >>>
> >>> Any clue about what I am missing here?
> >>>
> >>>
> >>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
> >>>
> >>>> By default you don't have to do nothing apart from having the two
> >>>> ApiMetadata classes and have them declared in the ServiceLoader file.
> >>>> It will work :)
> >>>>
> >>>> Feel free to join the #jclouds IRC channel @Freenode if you want to
> >>>> discuss it live!
> >>>>
> >>>> On 21 January 2014 21:58, Ignacio Mulas Viela <immulasviela@gmail.com
> >
> >>>> wrote:
> >>>>> Thanks everyone for the discussion and the hints! I think I will try
> to
> >>>>> maintain everything inside one glance module and see where it goes,
> If I
> >>>>> can achieve the correct loading of the two services I think it will
> be
> >>>>> better than having the code divided in different projects as Glance
> only
> >>>>> contains one API (imageAPI).
> >>>>>
> >>>>> @Ignasi thanks for the implementation hints, I will try to
> investigate
> >>>> how
> >>>>> I can implement the two contexts depending on the versions.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
> >>>>>
> >>>>>> With the described approach you'll need two contexts, one to use
> each
> >>>>>> version (as the ServiceLoader will create one instance of the
> service
> >>>> for
> >>>>>> each).
> >>>>>>
> >>>>>> Depending on the complexity of the differences, perhaps it can be
> >>>>>> configured with a single ApiMetadata and let Guice *provide* the
> right
> >>>>>> classes depending on the *apiVersion* (it can be configured when
> >>>> creating
> >>>>>> the context). jclouds-chef already does this to handle the
> >>>> deserialization
> >>>>>> of objects in different versions of the api [1] (see the peoviders
> at
> >>>> the
> >>>>>> end of the file).
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>>>
> >>>>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
> >>>>>> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
> >>>> escribió:
> >>>>>>
> >>>>>>> If we start going down the path of breaking it out into glance-v1,
> >>>>>>>> glance-v2, and glance-common, we're going to see an explosion of
> >>>>>>>> OpenStack modules in jclouds as new versions of APIs are released
> in
> >>>>>>>> OpenStack land.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I wasn't very clear in my original answer: I was under the
> impression
> >>>>>> that
> >>>>>>> the two versions cannot coexist simultaneously in the same
> context. If
> >>>>>>> there's no problem to have both of these loaded at the same time,
> then
> >>>>>>> let's definitely try to do that in one dependency!
> >>>>>>>
> >>>>>>> ap
> >>>>>>>
> >>>>>>
> >>>>
> >
>
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
Just to add more information, here is where the ServiceLoader takes
place [1]. It actually loads all the implementations, but when looking
for an Api or Provider with a given id, the first one with that id is
returned [2, 3].
That's why if you want to have different ApiMetadata classes you need
two different ids for them (regardless of if they are in the same
Maven project or are in separated ones). This also implies that you
will need to create two different Contexts if you want to access both
versions of a Glance Api, as one context is tied to just one
Api/Provider metadata.
Hope this clarifies a bit how it works!
[1] https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/ContextBuilder.java#L163-L177
[2] https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/providers/Providers.java#L89-L102
[3] https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/apis/Apis.java#L77-L90
On 21 January 2014 22:58, Everett Toews <ev...@rackspace.com> wrote:
> A pastie or gist would be fine but in this case a pull request would be even better. Just a work-in-progress PR for us to look at. It's not like we would necessarily merge it either. It's just to share code and comment on it.
>
> Everett
>
>
> On Jan 21, 2014, at 3:48 PM, Ignasi Barrera wrote:
>
>> Can you paste in a gist or pastie the GlanceApiMetadata classes?
>> Have you assigned a different ID to each, like "glance-v1" and "glance-v2"?
>>
>> On 21 January 2014 22:27, Ignacio Mulas Viela <im...@gmail.com> wrote:
>>> I tried having in the ServiceLoader file the two APiMetadata, run the tests
>>> and it only takes the first class that it is in the serviceLoader file. If
>>> I put first the v2 ApiMetadata then the v1 tests fails due to a cast
>>> conversion problem. And viceversa if the first class is the v1. The error
>>> is the following (in case v2 is first):
>>>
>>> Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52 cannot be
>>> cast to org.jclouds.openstack.glance.v1_0.GlanceApi
>>>
>>> The configuration file contains:
>>> org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
>>> org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
>>>
>>> Any clue about what I am missing here?
>>>
>>>
>>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>>>
>>>> By default you don't have to do nothing apart from having the two
>>>> ApiMetadata classes and have them declared in the ServiceLoader file.
>>>> It will work :)
>>>>
>>>> Feel free to join the #jclouds IRC channel @Freenode if you want to
>>>> discuss it live!
>>>>
>>>> On 21 January 2014 21:58, Ignacio Mulas Viela <im...@gmail.com>
>>>> wrote:
>>>>> Thanks everyone for the discussion and the hints! I think I will try to
>>>>> maintain everything inside one glance module and see where it goes, If I
>>>>> can achieve the correct loading of the two services I think it will be
>>>>> better than having the code divided in different projects as Glance only
>>>>> contains one API (imageAPI).
>>>>>
>>>>> @Ignasi thanks for the implementation hints, I will try to investigate
>>>> how
>>>>> I can implement the two contexts depending on the versions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>>>>>
>>>>>> With the described approach you'll need two contexts, one to use each
>>>>>> version (as the ServiceLoader will create one instance of the service
>>>> for
>>>>>> each).
>>>>>>
>>>>>> Depending on the complexity of the differences, perhaps it can be
>>>>>> configured with a single ApiMetadata and let Guice *provide* the right
>>>>>> classes depending on the *apiVersion* (it can be configured when
>>>> creating
>>>>>> the context). jclouds-chef already does this to handle the
>>>> deserialization
>>>>>> of objects in different versions of the api [1] (see the peoviders at
>>>> the
>>>>>> end of the file).
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
>>>>>> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
>>>> escribió:
>>>>>>
>>>>>>> If we start going down the path of breaking it out into glance-v1,
>>>>>>>> glance-v2, and glance-common, we're going to see an explosion of
>>>>>>>> OpenStack modules in jclouds as new versions of APIs are released in
>>>>>>>> OpenStack land.
>>>>>>>>
>>>>>>>
>>>>>>> I wasn't very clear in my original answer: I was under the impression
>>>>>> that
>>>>>>> the two versions cannot coexist simultaneously in the same context. If
>>>>>>> there's no problem to have both of these loaded at the same time, then
>>>>>>> let's definitely try to do that in one dependency!
>>>>>>>
>>>>>>> ap
>>>>>>>
>>>>>>
>>>>
>
Re: Glance implementation
Posted by Everett Toews <ev...@RACKSPACE.COM>.
A pastie or gist would be fine but in this case a pull request would be even better. Just a work-in-progress PR for us to look at. It's not like we would necessarily merge it either. It's just to share code and comment on it.
Everett
On Jan 21, 2014, at 3:48 PM, Ignasi Barrera wrote:
> Can you paste in a gist or pastie the GlanceApiMetadata classes?
> Have you assigned a different ID to each, like "glance-v1" and "glance-v2"?
>
> On 21 January 2014 22:27, Ignacio Mulas Viela <im...@gmail.com> wrote:
>> I tried having in the ServiceLoader file the two APiMetadata, run the tests
>> and it only takes the first class that it is in the serviceLoader file. If
>> I put first the v2 ApiMetadata then the v1 tests fails due to a cast
>> conversion problem. And viceversa if the first class is the v1. The error
>> is the following (in case v2 is first):
>>
>> Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52 cannot be
>> cast to org.jclouds.openstack.glance.v1_0.GlanceApi
>>
>> The configuration file contains:
>> org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
>> org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
>>
>> Any clue about what I am missing here?
>>
>>
>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>>
>>> By default you don't have to do nothing apart from having the two
>>> ApiMetadata classes and have them declared in the ServiceLoader file.
>>> It will work :)
>>>
>>> Feel free to join the #jclouds IRC channel @Freenode if you want to
>>> discuss it live!
>>>
>>> On 21 January 2014 21:58, Ignacio Mulas Viela <im...@gmail.com>
>>> wrote:
>>>> Thanks everyone for the discussion and the hints! I think I will try to
>>>> maintain everything inside one glance module and see where it goes, If I
>>>> can achieve the correct loading of the two services I think it will be
>>>> better than having the code divided in different projects as Glance only
>>>> contains one API (imageAPI).
>>>>
>>>> @Ignasi thanks for the implementation hints, I will try to investigate
>>> how
>>>> I can implement the two contexts depending on the versions.
>>>>
>>>>
>>>>
>>>>
>>>> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>>>>
>>>>> With the described approach you'll need two contexts, one to use each
>>>>> version (as the ServiceLoader will create one instance of the service
>>> for
>>>>> each).
>>>>>
>>>>> Depending on the complexity of the differences, perhaps it can be
>>>>> configured with a single ApiMetadata and let Guice *provide* the right
>>>>> classes depending on the *apiVersion* (it can be configured when
>>> creating
>>>>> the context). jclouds-chef already does this to handle the
>>> deserialization
>>>>> of objects in different versions of the api [1] (see the peoviders at
>>> the
>>>>> end of the file).
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
>>>>> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
>>> escribió:
>>>>>
>>>>>> If we start going down the path of breaking it out into glance-v1,
>>>>>>> glance-v2, and glance-common, we're going to see an explosion of
>>>>>>> OpenStack modules in jclouds as new versions of APIs are released in
>>>>>>> OpenStack land.
>>>>>>>
>>>>>>
>>>>>> I wasn't very clear in my original answer: I was under the impression
>>>>> that
>>>>>> the two versions cannot coexist simultaneously in the same context. If
>>>>>> there's no problem to have both of these loaded at the same time, then
>>>>>> let's definitely try to do that in one dependency!
>>>>>>
>>>>>> ap
>>>>>>
>>>>>
>>>
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
Can you paste in a gist or pastie the GlanceApiMetadata classes?
Have you assigned a different ID to each, like "glance-v1" and "glance-v2"?
On 21 January 2014 22:27, Ignacio Mulas Viela <im...@gmail.com> wrote:
> I tried having in the ServiceLoader file the two APiMetadata, run the tests
> and it only takes the first class that it is in the serviceLoader file. If
> I put first the v2 ApiMetadata then the v1 tests fails due to a cast
> conversion problem. And viceversa if the first class is the v1. The error
> is the following (in case v2 is first):
>
> Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52 cannot be
> cast to org.jclouds.openstack.glance.v1_0.GlanceApi
>
> The configuration file contains:
> org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
> org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
>
> Any clue about what I am missing here?
>
>
> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>
>> By default you don't have to do nothing apart from having the two
>> ApiMetadata classes and have them declared in the ServiceLoader file.
>> It will work :)
>>
>> Feel free to join the #jclouds IRC channel @Freenode if you want to
>> discuss it live!
>>
>> On 21 January 2014 21:58, Ignacio Mulas Viela <im...@gmail.com>
>> wrote:
>> > Thanks everyone for the discussion and the hints! I think I will try to
>> > maintain everything inside one glance module and see where it goes, If I
>> > can achieve the correct loading of the two services I think it will be
>> > better than having the code divided in different projects as Glance only
>> > contains one API (imageAPI).
>> >
>> > @Ignasi thanks for the implementation hints, I will try to investigate
>> how
>> > I can implement the two contexts depending on the versions.
>> >
>> >
>> >
>> >
>> > 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>> >
>> >> With the described approach you'll need two contexts, one to use each
>> >> version (as the ServiceLoader will create one instance of the service
>> for
>> >> each).
>> >>
>> >> Depending on the complexity of the differences, perhaps it can be
>> >> configured with a single ApiMetadata and let Guice *provide* the right
>> >> classes depending on the *apiVersion* (it can be configured when
>> creating
>> >> the context). jclouds-chef already does this to handle the
>> deserialization
>> >> of objects in different versions of the api [1] (see the peoviders at
>> the
>> >> end of the file).
>> >>
>> >> [1]
>> >>
>> >>
>> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
>> >> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
>> escribió:
>> >>
>> >> > If we start going down the path of breaking it out into glance-v1,
>> >> >> glance-v2, and glance-common, we're going to see an explosion of
>> >> >> OpenStack modules in jclouds as new versions of APIs are released in
>> >> >> OpenStack land.
>> >> >>
>> >> >
>> >> > I wasn't very clear in my original answer: I was under the impression
>> >> that
>> >> > the two versions cannot coexist simultaneously in the same context. If
>> >> > there's no problem to have both of these loaded at the same time, then
>> >> > let's definitely try to do that in one dependency!
>> >> >
>> >> > ap
>> >> >
>> >>
>>
Re: Glance implementation
Posted by Ignacio Mulas Viela <im...@gmail.com>.
I tried having in the ServiceLoader file the two APiMetadata, run the tests
and it only takes the first class that it is in the serviceLoader file. If
I put first the v2 ApiMetadata then the v1 tests fails due to a cast
conversion problem. And viceversa if the first class is the v1. The error
is the following (in case v2 is first):
Caused by: java.lang.ClassCastException: com.sun.proxy.$Proxy52 cannot be
cast to org.jclouds.openstack.glance.v1_0.GlanceApi
The configuration file contains:
org.jclouds.openstack.glance.v2_0.GlanceApiMetadata
org.jclouds.openstack.glance.v1_0.GlanceApiMetadata
Any clue about what I am missing here?
2014/1/21 Ignasi Barrera <ig...@gmail.com>
> By default you don't have to do nothing apart from having the two
> ApiMetadata classes and have them declared in the ServiceLoader file.
> It will work :)
>
> Feel free to join the #jclouds IRC channel @Freenode if you want to
> discuss it live!
>
> On 21 January 2014 21:58, Ignacio Mulas Viela <im...@gmail.com>
> wrote:
> > Thanks everyone for the discussion and the hints! I think I will try to
> > maintain everything inside one glance module and see where it goes, If I
> > can achieve the correct loading of the two services I think it will be
> > better than having the code divided in different projects as Glance only
> > contains one API (imageAPI).
> >
> > @Ignasi thanks for the implementation hints, I will try to investigate
> how
> > I can implement the two contexts depending on the versions.
> >
> >
> >
> >
> > 2014/1/21 Ignasi Barrera <ig...@gmail.com>
> >
> >> With the described approach you'll need two contexts, one to use each
> >> version (as the ServiceLoader will create one instance of the service
> for
> >> each).
> >>
> >> Depending on the complexity of the differences, perhaps it can be
> >> configured with a single ApiMetadata and let Guice *provide* the right
> >> classes depending on the *apiVersion* (it can be configured when
> creating
> >> the context). jclouds-chef already does this to handle the
> deserialization
> >> of objects in different versions of the api [1] (see the peoviders at
> the
> >> end of the file).
> >>
> >> [1]
> >>
> >>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
> >> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com>
> escribió:
> >>
> >> > If we start going down the path of breaking it out into glance-v1,
> >> >> glance-v2, and glance-common, we're going to see an explosion of
> >> >> OpenStack modules in jclouds as new versions of APIs are released in
> >> >> OpenStack land.
> >> >>
> >> >
> >> > I wasn't very clear in my original answer: I was under the impression
> >> that
> >> > the two versions cannot coexist simultaneously in the same context. If
> >> > there's no problem to have both of these loaded at the same time, then
> >> > let's definitely try to do that in one dependency!
> >> >
> >> > ap
> >> >
> >>
>
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
By default you don't have to do nothing apart from having the two
ApiMetadata classes and have them declared in the ServiceLoader file.
It will work :)
Feel free to join the #jclouds IRC channel @Freenode if you want to
discuss it live!
On 21 January 2014 21:58, Ignacio Mulas Viela <im...@gmail.com> wrote:
> Thanks everyone for the discussion and the hints! I think I will try to
> maintain everything inside one glance module and see where it goes, If I
> can achieve the correct loading of the two services I think it will be
> better than having the code divided in different projects as Glance only
> contains one API (imageAPI).
>
> @Ignasi thanks for the implementation hints, I will try to investigate how
> I can implement the two contexts depending on the versions.
>
>
>
>
> 2014/1/21 Ignasi Barrera <ig...@gmail.com>
>
>> With the described approach you'll need two contexts, one to use each
>> version (as the ServiceLoader will create one instance of the service for
>> each).
>>
>> Depending on the complexity of the differences, perhaps it can be
>> configured with a single ApiMetadata and let Guice *provide* the right
>> classes depending on the *apiVersion* (it can be configured when creating
>> the context). jclouds-chef already does this to handle the deserialization
>> of objects in different versions of the api [1] (see the peoviders at the
>> end of the file).
>>
>> [1]
>>
>> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
>> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com> escribió:
>>
>> > If we start going down the path of breaking it out into glance-v1,
>> >> glance-v2, and glance-common, we're going to see an explosion of
>> >> OpenStack modules in jclouds as new versions of APIs are released in
>> >> OpenStack land.
>> >>
>> >
>> > I wasn't very clear in my original answer: I was under the impression
>> that
>> > the two versions cannot coexist simultaneously in the same context. If
>> > there's no problem to have both of these loaded at the same time, then
>> > let's definitely try to do that in one dependency!
>> >
>> > ap
>> >
>>
Re: Glance implementation
Posted by Ignacio Mulas Viela <im...@gmail.com>.
Thanks everyone for the discussion and the hints! I think I will try to
maintain everything inside one glance module and see where it goes, If I
can achieve the correct loading of the two services I think it will be
better than having the code divided in different projects as Glance only
contains one API (imageAPI).
@Ignasi thanks for the implementation hints, I will try to investigate how
I can implement the two contexts depending on the versions.
2014/1/21 Ignasi Barrera <ig...@gmail.com>
> With the described approach you'll need two contexts, one to use each
> version (as the ServiceLoader will create one instance of the service for
> each).
>
> Depending on the complexity of the differences, perhaps it can be
> configured with a single ApiMetadata and let Guice *provide* the right
> classes depending on the *apiVersion* (it can be configured when creating
> the context). jclouds-chef already does this to handle the deserialization
> of objects in different versions of the api [1] (see the peoviders at the
> end of the file).
>
> [1]
>
> https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
> El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com> escribió:
>
> > If we start going down the path of breaking it out into glance-v1,
> >> glance-v2, and glance-common, we're going to see an explosion of
> >> OpenStack modules in jclouds as new versions of APIs are released in
> >> OpenStack land.
> >>
> >
> > I wasn't very clear in my original answer: I was under the impression
> that
> > the two versions cannot coexist simultaneously in the same context. If
> > there's no problem to have both of these loaded at the same time, then
> > let's definitely try to do that in one dependency!
> >
> > ap
> >
>
Re: Glance implementation
Posted by Ignasi Barrera <ig...@gmail.com>.
With the described approach you'll need two contexts, one to use each
version (as the ServiceLoader will create one instance of the service for
each).
Depending on the complexity of the differences, perhaps it can be
configured with a single ApiMetadata and let Guice *provide* the right
classes depending on the *apiVersion* (it can be configured when creating
the context). jclouds-chef already does this to handle the deserialization
of objects in different versions of the api [1] (see the peoviders at the
end of the file).
[1]
https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/config/ChefParserModule.java
El 21/01/2014 19:13, "Andrew Phillips" <ap...@qrmedia.com> escribió:
> If we start going down the path of breaking it out into glance-v1,
>> glance-v2, and glance-common, we're going to see an explosion of
>> OpenStack modules in jclouds as new versions of APIs are released in
>> OpenStack land.
>>
>
> I wasn't very clear in my original answer: I was under the impression that
> the two versions cannot coexist simultaneously in the same context. If
> there's no problem to have both of these loaded at the same time, then
> let's definitely try to do that in one dependency!
>
> ap
>
Re: Glance implementation
Posted by Andrew Phillips <ap...@qrmedia.com>.
> If we start going down the path of breaking it out into glance-v1,
> glance-v2, and glance-common, we're going to see an explosion of
> OpenStack modules in jclouds as new versions of APIs are released in
> OpenStack land.
I wasn't very clear in my original answer: I was under the impression
that the two versions cannot coexist simultaneously in the same
context. If there's no problem to have both of these loaded at the
same time, then let's definitely try to do that in one dependency!
ap
Re: Glance implementation
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Jan 21, 2014, at 10:49 AM, Ignacio Mulas Viela wrote:
> Hi All,
> I have some of the Glance v2 working already. Initially I created it as a
> separate module but now I was trying to merge both version (v1 and v2) into
> the same glance module so both implentations can be available and it is up
> to the application to use v1 or v2.
I think since you've already done the work to merge them, it's worthwhile to continue to see how it works out. My preference is to have fewer modules and fewer dependencies.
If we start going down the path of breaking it out into glance-v1, glance-v2, and glance-common, we're going to see an explosion of OpenStack modules in jclouds as new versions of APIs are released in OpenStack land.
> I have a question here, the modules are using the service loader. This
> means that there is a META-INF/services/org.jclouds.apis.ApiMetadata file
> under the src/main/resources [1] which is hardcoded to the version of the
> metadata class that you are using.
>
> As the v1 and v2 contains a different metadata classes, is it possible to
> give support to both versions at the same time in a module? Is there any
> way of overriding the default value of the service file? Any suggestions
> here?
I think Ignassi answered this one. And I think the default should be for v2.
Thanks for taking this on Ignacio!
Everett