You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Maurice van Ree <ma...@luminis.eu> on 2015/01/05 10:45:01 UTC
Deploying applications to Azure locations needs support for jclouds
2.0? Is this on the roadmap?
Hi All,
I'm investigating both Brooklyn and Azure to see whether this would be a
possible/good solution to deploy OSGi applications when an Azure deployment
is one of the requirements.
However Brooklyn currently seems to only support jclouds 1.7.2, which only
provides Azure Blob Service support if I'm correct?
There is upcoming support for azurecompute (
https://github.com/jclouds/jclouds-labs/tree/master/azurecompute/src/main/java/org/jclouds/azurecompute/compute)
But this seems to be based on the jclouds 2.0 trunk/snapshot, which makes
it hard to add to Brooklyn without updating jclouds support entirely in
Brooklyn.
I've tried adding the azurecompute library to the brooklyn 0.7.0-m1 sample
libs as well as the the azure-cli to the pom.xml, and then configured a
location as follows:
*brooklyn.location.named.Azure\ Azure\ (west-eu) = jclouds:azurecompute*
*brooklyn.location.jclouds.azurecompute.name
<http://brooklyn.location.jclouds.azurecompute.name> = Microsoft Azure
Service Management Service API*
*brooklyn.location.jclouds.azurecompute.version = 2014-06-01*
*brooklyn.location.jclouds.azurecompute.identityName = azure.p12*
*brooklyn.location.jclouds.azurecompute.credentialName = mypassword*
*brooklyn.location.jclouds.azurecompute.defaultEndpoint =
https://management.core.windows.net/mysubscriptionid
<https://management.core.windows.net/mysubscriptionid>*
*brooklyn.location.jclouds.azurecompute.endpointName =
https://manage.windowsazure.com/mysubscriptionid
<https://manage.windowsazure.com/mysubscriptionid>*
I'm running into the following problem at this point:
*Failure running task invoking start[locations] on 2 nodes (phErXWpZ)
<http://127.0.0.1:8081/#/v1/applications/slSh0W9J/entities/slSh0W9J/activities/subtask/phErXWpZ>:
*api
{id=azurecompute, name=Microsoft Azure Service Management Service API,
views=[], endpointName=Service Management Endpoint ending in your
Subscription Id, identityName=Path to Management Certificate .p12 file, or
PEM string, credentialName=Optional.of(Password to Management Certificate),
documentation=http://msdn.microsoft.com/en-us/library/ee460799,
api=interface org.jclouds.azurecompute.AzureComputeApi} not wrappable as
org.jclouds.compute.ComputeServiceContext; context:
org.jclouds.rest.ApiContext<org.jclouds.azurecompute.AzureComputeApi>,
views: []
1. Is there any work being done to support jclouds 2.0?
2. Is there some sort of lead or overview on what exactly needs to be done
to update jclouds to 2.0 in Brooklyn?
3. Perhaps most important: am I overlooking something else entirely which
already provides support to add Azure locations to deploy applications to
Azure?
Best Regards,
Maurice van Ree
Re: Deploying applications to Azure locations needs support for
jclouds 2.0? Is this on the roadmap?
Posted by Andrea Turli <an...@cloudsoftcorp.com>.
Hi Maurice,
On 5 January 2015 at 10:45, Maurice van Ree <ma...@luminis.eu>
wrote:
> Hi All,
>
> I'm investigating both Brooklyn and Azure to see whether this would be a
> possible/good solution to deploy OSGi applications when an Azure deployment
> is one of the requirements.
>
> However Brooklyn currently seems to only support jclouds 1.7.2, which only
> provides Azure Blob Service support if I'm correct?
>
To be more precise, brooklyn depends on jclouds 1.8.1 currently, but this
doesn't make a big difference for azurecompute.
In fact, as you noticed, jclouds only supports azure blob service currently.
There is upcoming support for azurecompute (
>
> https://github.com/jclouds/jclouds-labs/tree/master/azurecompute/src/main/java/org/jclouds/azurecompute/compute
> )
> But this seems to be based on the jclouds 2.0 trunk/snapshot, which makes
> it hard to add to Brooklyn without updating jclouds support entirely in
> Brooklyn.
>
Correct, there is an ongoing effort to add azurecompute to jclouds. This
work is tracked at https://issues.apache.org/jira/browse/JCLOUDS-664
As you may know, in order to add a new provider, developers first add it to
jclouds-labs and then to jclouds official repository. Currently
jclouds-azurecompute is on jclouds-labs.
> I've tried adding the azurecompute library to the brooklyn 0.7.0-m1 sample
> libs as well as the the azure-cli to the pom.xml, and then configured a
> location as follows:
>
>
> *brooklyn.location.named.Azure\ Azure\ (west-eu) = jclouds:azurecompute*
> *brooklyn.location.jclouds.azurecompute.name
> <http://brooklyn.location.jclouds.azurecompute.name> = Microsoft Azure
> Service Management Service API*
> *brooklyn.location.jclouds.azurecompute.version = 2014-06-01*
> *brooklyn.location.jclouds.azurecompute.identityName = azure.p12*
> *brooklyn.location.jclouds.azurecompute.credentialName = mypassword*
> *brooklyn.location.jclouds.azurecompute.defaultEndpoint =
> https://management.core.windows.net/mysubscriptionid
> <https://management.core.windows.net/mysubscriptionid>*
> *brooklyn.location.jclouds.azurecompute.endpointName =
> https://manage.windowsazure.com/mysubscriptionid
> <https://manage.windowsazure.com/mysubscriptionid>*
>
> I'm running into the following problem at this point:
>
> *Failure running task invoking start[locations] on 2 nodes (phErXWpZ)
> <
> http://127.0.0.1:8081/#/v1/applications/slSh0W9J/entities/slSh0W9J/activities/subtask/phErXWpZ
> >:
> *api
> {id=azurecompute, name=Microsoft Azure Service Management Service API,
> views=[], endpointName=Service Management Endpoint ending in your
> Subscription Id, identityName=Path to Management Certificate .p12 file, or
> PEM string, credentialName=Optional.of(Password to Management Certificate),
> documentation=http://msdn.microsoft.com/en-us/library/ee460799,
> api=interface org.jclouds.azurecompute.AzureComputeApi} not wrappable as
> org.jclouds.compute.ComputeServiceContext; context:
> org.jclouds.rest.ApiContext<org.jclouds.azurecompute.AzureComputeApi>,
> views: []
>
> unfortunately this won't work as jclouds-azurecompute currently misses the
ComputeServiceAdapter implementation among others.
>
> 1. Is there any work being done to support jclouds 2.0?
>
As I said before, that wouldn't be enough untill jclouds-azurecompute will
be completed.
> 2. Is there some sort of lead or overview on what exactly needs to be done
> to update jclouds to 2.0 in Brooklyn?
>
https://issues.apache.org/jira/browse/JCLOUDS-664
> 3. Perhaps most important: am I overlooking something else entirely which
> already provides support to add Azure locations to deploy applications to
> Azure?
>
While we wait for jclouds community to catch-up you can have a look at
https://github.com/brooklyncentral/brooklyn-location-azure-cli: it
implements a brooklyn location (not based on jclouds) built on the azure
cli.
Hope this could help you,
Andrea
If you need more support, feel free to join channel #brooklyncentral on the
Freenode (https://freenode.net) IRC network.
Re: Deploying applications to Azure locations needs support for jclouds
2.0? Is this on the roadmap?
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Hi Maurice,
Try the latest snapshot / master branch of Brooklyn which uses much more
recent jclouds. If needed you could change the location/jclouds/pom.xml
to point at this version.
We tend to track the latest release version of jclouds as soon as it is
available, and sometimes we take interim cuts of jclouds where new
features are needed.
I think folks have looked at jclouds 2.0 and concluded it is not a
significant jump. There are others using Azure but not via jclouds,
just using a CLI adapter layer into Brooklyn. azurecompute might be
useful for them.
Maybe supporting an interim jclouds 2.0-alpha (is that the final jclouds
numbering scheme?) would be a good idea?
Best
Alex
On 05/01/2015 09:45, Maurice van Ree wrote:
> Hi All,
>
> I'm investigating both Brooklyn and Azure to see whether this would be a
> possible/good solution to deploy OSGi applications when an Azure deployment
> is one of the requirements.
>
> However Brooklyn currently seems to only support jclouds 1.7.2, which only
> provides Azure Blob Service support if I'm correct?
> There is upcoming support for azurecompute (
> https://github.com/jclouds/jclouds-labs/tree/master/azurecompute/src/main/java/org/jclouds/azurecompute/compute)
> But this seems to be based on the jclouds 2.0 trunk/snapshot, which makes
> it hard to add to Brooklyn without updating jclouds support entirely in
> Brooklyn.
>
> I've tried adding the azurecompute library to the brooklyn 0.7.0-m1 sample
> libs as well as the the azure-cli to the pom.xml, and then configured a
> location as follows:
>
>
> *brooklyn.location.named.Azure\ Azure\ (west-eu) = jclouds:azurecompute*
> *brooklyn.location.jclouds.azurecompute.name
> <http://brooklyn.location.jclouds.azurecompute.name> = Microsoft Azure
> Service Management Service API*
> *brooklyn.location.jclouds.azurecompute.version = 2014-06-01*
> *brooklyn.location.jclouds.azurecompute.identityName = azure.p12*
> *brooklyn.location.jclouds.azurecompute.credentialName = mypassword*
> *brooklyn.location.jclouds.azurecompute.defaultEndpoint =
> https://management.core.windows.net/mysubscriptionid
> <https://management.core.windows.net/mysubscriptionid>*
> *brooklyn.location.jclouds.azurecompute.endpointName =
> https://manage.windowsazure.com/mysubscriptionid
> <https://manage.windowsazure.com/mysubscriptionid>*
>
> I'm running into the following problem at this point:
>
> *Failure running task invoking start[locations] on 2 nodes (phErXWpZ)
> <http://127.0.0.1:8081/#/v1/applications/slSh0W9J/entities/slSh0W9J/activities/subtask/phErXWpZ>:
> *api
> {id=azurecompute, name=Microsoft Azure Service Management Service API,
> views=[], endpointName=Service Management Endpoint ending in your
> Subscription Id, identityName=Path to Management Certificate .p12 file, or
> PEM string, credentialName=Optional.of(Password to Management Certificate),
> documentation=http://msdn.microsoft.com/en-us/library/ee460799,
> api=interface org.jclouds.azurecompute.AzureComputeApi} not wrappable as
> org.jclouds.compute.ComputeServiceContext; context:
> org.jclouds.rest.ApiContext<org.jclouds.azurecompute.AzureComputeApi>,
> views: []
>
>
> 1. Is there any work being done to support jclouds 2.0?
> 2. Is there some sort of lead or overview on what exactly needs to be done
> to update jclouds to 2.0 in Brooklyn?
> 3. Perhaps most important: am I overlooking something else entirely which
> already provides support to add Azure locations to deploy applications to
> Azure?
>
>
> Best Regards,
>
> Maurice van Ree
>
Re: Deploying applications to Azure locations needs support for
jclouds 2.0? Is this on the roadmap?
Posted by Maurice van Ree <ma...@luminis.eu>.
Hi Alex and Andrea,
Thanks for your responses!
Nice to hear Brooklyn tracks the latest jclouds releases relatively
quickly, I saw the trunk uses the latest release indeed.
I was just typing up that azurecompute isn't included in jclouds 2.0 at
this point when Andrea responded. My plan was to take a look on seeing
where azurecompute stood at this point, by possibly adding jclouds 2.0
support to Brooklyn, and then adding in azurecompute. However, I saw your
comments on jclouds-664, and you seem to be right on top of it already
Andrea :-). That and your response saved me a lot of time investigating on
where azurecompute stands at this point, as you've just told me.
Following this closely for the time being, you guys seem to be doing the
right things!
I'll have a go at leveraging the azure-cli in the meantime. I also found
that link, but as I've done some things with jclouds before (using AWS),
and the "We hope as jclouds Azure support matures, that will replace this
library!" note on that page, I chose to investigate the jclouds route
mostly.
Best Regards,
Maurice
On Mon, Jan 5, 2015 at 10:56 AM, Alex Heneveld <
alex.heneveld@cloudsoftcorp.com> wrote:
>
> Hi Maurice,
>
> Try the latest snapshot / master branch of Brooklyn which uses much more
> recent jclouds. If needed you could change the location/jclouds/pom.xml
> to point at this version.
>
> We tend to track the latest release version of jclouds as soon as it is
> available, and sometimes we take interim cuts of jclouds where new
> features are needed.
>
> I think folks have looked at jclouds 2.0 and concluded it is not a
> significant jump. There are others using Azure but not via jclouds,
> just using a CLI adapter layer into Brooklyn. azurecompute might be
> useful for them.
>
> Maybe supporting an interim jclouds 2.0-alpha (is that the final jclouds
> numbering scheme?) would be a good idea?
>
> Best
> Alex
>
>
> On 05/01/2015 09:45, Maurice van Ree wrote:
> > Hi All,
> >
> > I'm investigating both Brooklyn and Azure to see whether this would be a
> > possible/good solution to deploy OSGi applications when an Azure
> deployment
> > is one of the requirements.
> >
> > However Brooklyn currently seems to only support jclouds 1.7.2, which
> only
> > provides Azure Blob Service support if I'm correct?
> > There is upcoming support for azurecompute (
> >
> https://github.com/jclouds/jclouds-labs/tree/master/azurecompute/src/main/java/org/jclouds/azurecompute/compute
> )
> > But this seems to be based on the jclouds 2.0 trunk/snapshot, which makes
> > it hard to add to Brooklyn without updating jclouds support entirely in
> > Brooklyn.
> >
> > I've tried adding the azurecompute library to the brooklyn 0.7.0-m1
> sample
> > libs as well as the the azure-cli to the pom.xml, and then configured a
> > location as follows:
> >
> >
> > *brooklyn.location.named.Azure\ Azure\ (west-eu) = jclouds:azurecompute*
> > *brooklyn.location.jclouds.azurecompute.name
> > <http://brooklyn.location.jclouds.azurecompute.name> = Microsoft Azure
> > Service Management Service API*
> > *brooklyn.location.jclouds.azurecompute.version = 2014-06-01*
> > *brooklyn.location.jclouds.azurecompute.identityName = azure.p12*
> > *brooklyn.location.jclouds.azurecompute.credentialName = mypassword*
> > *brooklyn.location.jclouds.azurecompute.defaultEndpoint =
> > https://management.core.windows.net/mysubscriptionid
> > <https://management.core.windows.net/mysubscriptionid>*
> > *brooklyn.location.jclouds.azurecompute.endpointName =
> > https://manage.windowsazure.com/mysubscriptionid
> > <https://manage.windowsazure.com/mysubscriptionid>*
> >
> > I'm running into the following problem at this point:
> >
> > *Failure running task invoking start[locations] on 2 nodes (phErXWpZ)
> > <
> http://127.0.0.1:8081/#/v1/applications/slSh0W9J/entities/slSh0W9J/activities/subtask/phErXWpZ
> >:
> > *api
> > {id=azurecompute, name=Microsoft Azure Service Management Service API,
> > views=[], endpointName=Service Management Endpoint ending in your
> > Subscription Id, identityName=Path to Management Certificate .p12 file,
> or
> > PEM string, credentialName=Optional.of(Password to Management
> Certificate),
> > documentation=http://msdn.microsoft.com/en-us/library/ee460799,
> > api=interface org.jclouds.azurecompute.AzureComputeApi} not wrappable as
> > org.jclouds.compute.ComputeServiceContext; context:
> > org.jclouds.rest.ApiContext<org.jclouds.azurecompute.AzureComputeApi>,
> > views: []
> >
> >
> > 1. Is there any work being done to support jclouds 2.0?
> > 2. Is there some sort of lead or overview on what exactly needs to be
> done
> > to update jclouds to 2.0 in Brooklyn?
> > 3. Perhaps most important: am I overlooking something else entirely which
> > already provides support to add Azure locations to deploy applications to
> > Azure?
> >
> >
> > Best Regards,
> >
> > Maurice van Ree
> >
>
>