You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by MANIE Irmo <ir...@leonteq.com> on 2015/08/26 18:02:46 UTC
[1.9.1] - CloudStack - userMetaData vs userData
Hi,
In the compute service api there is a template option 'userMetaData', but this data is merged with the tags in the CloudStack adapter. [1]
In the CloudStack specific options there is also a 'userData' property [2] . Is there plan to be able to populate this via the general template options and embed this in the CloudStackTemplateOptions?
That specific property is very useful for our provisioning because it becomes available via a simple VM local REST api [3]. This way we can figure out what to install on the VM without having to consult CloudStack for the tags, since these are not available via that local api.
This is for me the only reason I now have to use the CloudStack specific compute api so I don't benefit from all the high level goodies.
- Irmo
[1] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java#L256
[2] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptions.java
[3] http://cloudstack-administration.readthedocs.org/en/latest/api.html
=========== The Leonteq Mail Gateway made the following annotation ===========
This e-mail is confidential. If you are not the intended recipient, you should
not copy it, re-transmit it, use it or disclose its contents, but should
return it to the sender immediately and delete the copy from your system.
Leonteq Securities is not responsible for, nor endorses, any opinion,
recommendation, conclusion, solicitation, offer or agreement or any
information contained in this communication.
Leonteq Securities cannot accept any responsibility for the accuracy or
completeness of this message as it has been transmitted over a public network.
If you suspect that the message may have been intercepted or amended, please
call the sender. Should you require any further information, please contact
the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
==============================================================================
Re: [1.9.1] - CloudStack - userMetaData vs userData
Posted by Ignasi Barrera <na...@apache.org>.
You're right. We try to release a bugfix version every 6 weeks, but it
is unlikely that we release another 1.9.x. We'd like to release
jclouds 2.0 sooner than later and focus on it.
Don't worry about the target branch. I'll take care of merging it to
master. Thanks for the patches!
On 1 September 2015 at 13:43, MANIE Irmo <ir...@leonteq.com> wrote:
> I made both pull requests [1] [2], but I've made them against the 1.9.x branch. Is that ok?
> Didn’t know if you guys really go for a new major version next release, since the master is on 2.0.0-SNAPSHOT.
>
> I read somewhere you do a minor release every 6 weeks right?
>
> [1] https://github.com/jclouds/jclouds/pull/852
> [2] https://github.com/jclouds/jclouds/pull/853
>
>
> -----Original Message-----
> From: Ignasi Barrera [mailto:nacx@apache.org]
> Sent: Dienstag, 1. September 2015 11:30
> To: dev@jclouds.apache.org
> Subject: RE: [1.9.1] - CloudStack - userMetaData vs userData
>
> Absolutely. Thanks for taking care of this!
> El 1/9/2015 11:18, "MANIE Irmo" <ir...@leonteq.com> escribió:
>
>> In terms of using the portable key/value userMetaData and encode this
>> as the binary CloudStack userData there is still the case that
>> CloudStack tags (where the userMetaData currently goes) is actual
>> key/value so it makes most sense to keep it there (merged with the
>> portable tags). I don’t think we want to duplicate userMetaData into both tags and userData.
>>
>> I'll just add the userData to the CloudStackTemplateOptions only, so
>> you have to be specific when using the portable api, and then you guys
>> can decide later on whether it's valuable to also add this as a
>> portable feature and use it for other providers too.
>> Sounds like a plan?
>>
>> -----Original Message-----
>> From: Ignasi Barrera [mailto:nacx@apache.org]
>> Sent: Dienstag, 1. September 2015 10:06
>> To: dev@jclouds.apache.org
>> Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>>
>> I agree that it limits us to key/value, but it also makes sense, as it
>> is a format easy to consume once deserialised. Anyway, what you say is
>> correct. The better way to address the issue in this case is to
>> directly populate the option in the provider specific options.
>>
>> If you go through the CloudStackTemplateOptions path, I wouldn't
>> populate it to the portable options, although some other providers
>> (AWS and Azure for example) already support that kind of user data. We
>> can open a JIRA issue to study if it makes sense to expose such a
>> binary property in the portable model. That option is often used to
>> provide bootstrap scripts, and other initialisation stuff, so we'd
>> better understand first how people is using it in the different
>> providers and then make room for such a feature in the portable options.
>>
>> On 1 September 2015 at 09:39, MANIE Irmo <ir...@leonteq.com> wrote:
>> > The CloudStack userData is more of a free format entry, so using the
>> userMetaData for it is not such a good idea because it limits you to
>> key/value.
>> > Also considering that the generic userMetaData is now added as
>> CloudStack tags (which are actually key-value tags), it might get
>> confusing what is used where.
>> >
>> > I reckon we just need to add it as a new property in
>> CloudStackTemplateOptions first, then map it down into the adapter.
>> > But I guess we can't push the property up to TemplateOptions, since
>> that's the generic one that should apply to all implementations right?
>> >
>> > - Irmo
>> >
>> > -----Original Message-----
>> > From: Ignasi Barrera [mailto:nacx@apache.org]
>> > Sent: Dienstag, 1. September 2015 09:18
>> > To: dev@jclouds.apache.org
>> > Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>> >
>> >> and the vast variety of repos used in the various pom files makes
>> getting the project in a compiling state a living hell.
>> >
>> > A general advice I give is to just import the project for the
>> > provider
>> you're going to work with. There is no need to import the entire
>> jclouds codebase in your IDE. Importing just the CloudStack API should
>> be enough to let you work with it.
>> >
>> >> I already reported another bug, also related to the CloudStack
>> >> layer
>> [1], so I pick them up both.
>> >
>> > Awesome! Ping us here if you need help, or join the #jclouds IRC
>> > channel
>> @ Freenode. We'll be happy to help!
>> >
>> >
>> > =========== The Leonteq Mail Gateway made the following annotation
>> > ===========
>> >
>> > This e-mail is confidential. If you are not the intended recipient,
>> > you should
>> >
>> > not copy it, re-transmit it, use it or disclose its contents, but
>> > should
>> >
>> > return it to the sender immediately and delete the copy from your system.
>> >
>> > Leonteq Securities is not responsible for, nor endorses, any
>> > opinion,
>> >
>> > recommendation, conclusion, solicitation, offer or agreement or any
>> >
>> > information contained in this communication.
>> >
>> > Leonteq Securities cannot accept any responsibility for the accuracy
>> > or
>> >
>> > completeness of this message as it has been transmitted over a
>> > public
>> network.
>> >
>> > If you suspect that the message may have been intercepted or
>> > amended, please
>> >
>> > call the sender. Should you require any further information, please
>> > contact
>> >
>> > the Compliance Manager on compliance@leonteq.com<mailto:
>> compliance@leonteq.com>.
>> >
>> >
>> >
>> > ====================================================================
>> > ==
>> > ========
>>
RE: [1.9.1] - CloudStack - userMetaData vs userData
Posted by MANIE Irmo <ir...@leonteq.com>.
I made both pull requests [1] [2], but I've made them against the 1.9.x branch. Is that ok?
Didn’t know if you guys really go for a new major version next release, since the master is on 2.0.0-SNAPSHOT.
I read somewhere you do a minor release every 6 weeks right?
[1] https://github.com/jclouds/jclouds/pull/852
[2] https://github.com/jclouds/jclouds/pull/853
-----Original Message-----
From: Ignasi Barrera [mailto:nacx@apache.org]
Sent: Dienstag, 1. September 2015 11:30
To: dev@jclouds.apache.org
Subject: RE: [1.9.1] - CloudStack - userMetaData vs userData
Absolutely. Thanks for taking care of this!
El 1/9/2015 11:18, "MANIE Irmo" <ir...@leonteq.com> escribió:
> In terms of using the portable key/value userMetaData and encode this
> as the binary CloudStack userData there is still the case that
> CloudStack tags (where the userMetaData currently goes) is actual
> key/value so it makes most sense to keep it there (merged with the
> portable tags). I don’t think we want to duplicate userMetaData into both tags and userData.
>
> I'll just add the userData to the CloudStackTemplateOptions only, so
> you have to be specific when using the portable api, and then you guys
> can decide later on whether it's valuable to also add this as a
> portable feature and use it for other providers too.
> Sounds like a plan?
>
> -----Original Message-----
> From: Ignasi Barrera [mailto:nacx@apache.org]
> Sent: Dienstag, 1. September 2015 10:06
> To: dev@jclouds.apache.org
> Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>
> I agree that it limits us to key/value, but it also makes sense, as it
> is a format easy to consume once deserialised. Anyway, what you say is
> correct. The better way to address the issue in this case is to
> directly populate the option in the provider specific options.
>
> If you go through the CloudStackTemplateOptions path, I wouldn't
> populate it to the portable options, although some other providers
> (AWS and Azure for example) already support that kind of user data. We
> can open a JIRA issue to study if it makes sense to expose such a
> binary property in the portable model. That option is often used to
> provide bootstrap scripts, and other initialisation stuff, so we'd
> better understand first how people is using it in the different
> providers and then make room for such a feature in the portable options.
>
> On 1 September 2015 at 09:39, MANIE Irmo <ir...@leonteq.com> wrote:
> > The CloudStack userData is more of a free format entry, so using the
> userMetaData for it is not such a good idea because it limits you to
> key/value.
> > Also considering that the generic userMetaData is now added as
> CloudStack tags (which are actually key-value tags), it might get
> confusing what is used where.
> >
> > I reckon we just need to add it as a new property in
> CloudStackTemplateOptions first, then map it down into the adapter.
> > But I guess we can't push the property up to TemplateOptions, since
> that's the generic one that should apply to all implementations right?
> >
> > - Irmo
> >
> > -----Original Message-----
> > From: Ignasi Barrera [mailto:nacx@apache.org]
> > Sent: Dienstag, 1. September 2015 09:18
> > To: dev@jclouds.apache.org
> > Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
> >
> >> and the vast variety of repos used in the various pom files makes
> getting the project in a compiling state a living hell.
> >
> > A general advice I give is to just import the project for the
> > provider
> you're going to work with. There is no need to import the entire
> jclouds codebase in your IDE. Importing just the CloudStack API should
> be enough to let you work with it.
> >
> >> I already reported another bug, also related to the CloudStack
> >> layer
> [1], so I pick them up both.
> >
> > Awesome! Ping us here if you need help, or join the #jclouds IRC
> > channel
> @ Freenode. We'll be happy to help!
> >
> >
> > =========== The Leonteq Mail Gateway made the following annotation
> > ===========
> >
> > This e-mail is confidential. If you are not the intended recipient,
> > you should
> >
> > not copy it, re-transmit it, use it or disclose its contents, but
> > should
> >
> > return it to the sender immediately and delete the copy from your system.
> >
> > Leonteq Securities is not responsible for, nor endorses, any
> > opinion,
> >
> > recommendation, conclusion, solicitation, offer or agreement or any
> >
> > information contained in this communication.
> >
> > Leonteq Securities cannot accept any responsibility for the accuracy
> > or
> >
> > completeness of this message as it has been transmitted over a
> > public
> network.
> >
> > If you suspect that the message may have been intercepted or
> > amended, please
> >
> > call the sender. Should you require any further information, please
> > contact
> >
> > the Compliance Manager on compliance@leonteq.com<mailto:
> compliance@leonteq.com>.
> >
> >
> >
> > ====================================================================
> > ==
> > ========
>
RE: [1.9.1] - CloudStack - userMetaData vs userData
Posted by Ignasi Barrera <na...@apache.org>.
Absolutely. Thanks for taking care of this!
El 1/9/2015 11:18, "MANIE Irmo" <ir...@leonteq.com> escribió:
> In terms of using the portable key/value userMetaData and encode this as
> the binary CloudStack userData there is still the case that CloudStack tags
> (where the userMetaData currently goes) is actual key/value so it makes
> most sense to keep it there (merged with the portable tags). I don’t think
> we want to duplicate userMetaData into both tags and userData.
>
> I'll just add the userData to the CloudStackTemplateOptions only, so you
> have to be specific when using the portable api, and then you guys can
> decide later on whether it's valuable to also add this as a portable
> feature and use it for other providers too.
> Sounds like a plan?
>
> -----Original Message-----
> From: Ignasi Barrera [mailto:nacx@apache.org]
> Sent: Dienstag, 1. September 2015 10:06
> To: dev@jclouds.apache.org
> Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>
> I agree that it limits us to key/value, but it also makes sense, as it is
> a format easy to consume once deserialised. Anyway, what you say is
> correct. The better way to address the issue in this case is to directly
> populate the option in the provider specific options.
>
> If you go through the CloudStackTemplateOptions path, I wouldn't populate
> it to the portable options, although some other providers (AWS and Azure
> for example) already support that kind of user data. We can open a JIRA
> issue to study if it makes sense to expose such a binary property in the
> portable model. That option is often used to provide bootstrap scripts, and
> other initialisation stuff, so we'd better understand first how people is
> using it in the different providers and then make room for such a feature
> in the portable options.
>
> On 1 September 2015 at 09:39, MANIE Irmo <ir...@leonteq.com> wrote:
> > The CloudStack userData is more of a free format entry, so using the
> userMetaData for it is not such a good idea because it limits you to
> key/value.
> > Also considering that the generic userMetaData is now added as
> CloudStack tags (which are actually key-value tags), it might get confusing
> what is used where.
> >
> > I reckon we just need to add it as a new property in
> CloudStackTemplateOptions first, then map it down into the adapter.
> > But I guess we can't push the property up to TemplateOptions, since
> that's the generic one that should apply to all implementations right?
> >
> > - Irmo
> >
> > -----Original Message-----
> > From: Ignasi Barrera [mailto:nacx@apache.org]
> > Sent: Dienstag, 1. September 2015 09:18
> > To: dev@jclouds.apache.org
> > Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
> >
> >> and the vast variety of repos used in the various pom files makes
> getting the project in a compiling state a living hell.
> >
> > A general advice I give is to just import the project for the provider
> you're going to work with. There is no need to import the entire jclouds
> codebase in your IDE. Importing just the CloudStack API should be enough to
> let you work with it.
> >
> >> I already reported another bug, also related to the CloudStack layer
> [1], so I pick them up both.
> >
> > Awesome! Ping us here if you need help, or join the #jclouds IRC channel
> @ Freenode. We'll be happy to help!
> >
> >
> > =========== The Leonteq Mail Gateway made the following annotation
> > ===========
> >
> > This e-mail is confidential. If you are not the intended recipient,
> > you should
> >
> > not copy it, re-transmit it, use it or disclose its contents, but
> > should
> >
> > return it to the sender immediately and delete the copy from your system.
> >
> > Leonteq Securities is not responsible for, nor endorses, any opinion,
> >
> > recommendation, conclusion, solicitation, offer or agreement or any
> >
> > information contained in this communication.
> >
> > Leonteq Securities cannot accept any responsibility for the accuracy
> > or
> >
> > completeness of this message as it has been transmitted over a public
> network.
> >
> > If you suspect that the message may have been intercepted or amended,
> > please
> >
> > call the sender. Should you require any further information, please
> > contact
> >
> > the Compliance Manager on compliance@leonteq.com<mailto:
> compliance@leonteq.com>.
> >
> >
> >
> > ======================================================================
> > ========
>
RE: [1.9.1] - CloudStack - userMetaData vs userData
Posted by MANIE Irmo <ir...@leonteq.com>.
In terms of using the portable key/value userMetaData and encode this as the binary CloudStack userData there is still the case that CloudStack tags (where the userMetaData currently goes) is actual key/value so it makes most sense to keep it there (merged with the portable tags). I don’t think we want to duplicate userMetaData into both tags and userData.
I'll just add the userData to the CloudStackTemplateOptions only, so you have to be specific when using the portable api, and then you guys can decide later on whether it's valuable to also add this as a portable feature and use it for other providers too.
Sounds like a plan?
-----Original Message-----
From: Ignasi Barrera [mailto:nacx@apache.org]
Sent: Dienstag, 1. September 2015 10:06
To: dev@jclouds.apache.org
Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
I agree that it limits us to key/value, but it also makes sense, as it is a format easy to consume once deserialised. Anyway, what you say is correct. The better way to address the issue in this case is to directly populate the option in the provider specific options.
If you go through the CloudStackTemplateOptions path, I wouldn't populate it to the portable options, although some other providers (AWS and Azure for example) already support that kind of user data. We can open a JIRA issue to study if it makes sense to expose such a binary property in the portable model. That option is often used to provide bootstrap scripts, and other initialisation stuff, so we'd better understand first how people is using it in the different providers and then make room for such a feature in the portable options.
On 1 September 2015 at 09:39, MANIE Irmo <ir...@leonteq.com> wrote:
> The CloudStack userData is more of a free format entry, so using the userMetaData for it is not such a good idea because it limits you to key/value.
> Also considering that the generic userMetaData is now added as CloudStack tags (which are actually key-value tags), it might get confusing what is used where.
>
> I reckon we just need to add it as a new property in CloudStackTemplateOptions first, then map it down into the adapter.
> But I guess we can't push the property up to TemplateOptions, since that's the generic one that should apply to all implementations right?
>
> - Irmo
>
> -----Original Message-----
> From: Ignasi Barrera [mailto:nacx@apache.org]
> Sent: Dienstag, 1. September 2015 09:18
> To: dev@jclouds.apache.org
> Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>
>> and the vast variety of repos used in the various pom files makes getting the project in a compiling state a living hell.
>
> A general advice I give is to just import the project for the provider you're going to work with. There is no need to import the entire jclouds codebase in your IDE. Importing just the CloudStack API should be enough to let you work with it.
>
>> I already reported another bug, also related to the CloudStack layer [1], so I pick them up both.
>
> Awesome! Ping us here if you need help, or join the #jclouds IRC channel @ Freenode. We'll be happy to help!
>
>
> =========== The Leonteq Mail Gateway made the following annotation
> ===========
>
> This e-mail is confidential. If you are not the intended recipient,
> you should
>
> not copy it, re-transmit it, use it or disclose its contents, but
> should
>
> return it to the sender immediately and delete the copy from your system.
>
> Leonteq Securities is not responsible for, nor endorses, any opinion,
>
> recommendation, conclusion, solicitation, offer or agreement or any
>
> information contained in this communication.
>
> Leonteq Securities cannot accept any responsibility for the accuracy
> or
>
> completeness of this message as it has been transmitted over a public network.
>
> If you suspect that the message may have been intercepted or amended,
> please
>
> call the sender. Should you require any further information, please
> contact
>
> the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
>
>
>
> ======================================================================
> ========
Re: [1.9.1] - CloudStack - userMetaData vs userData
Posted by Ignasi Barrera <na...@apache.org>.
I agree that it limits us to key/value, but it also makes sense, as it
is a format easy to consume once deserialised. Anyway, what you say is
correct. The better way to address the issue in this case is to
directly populate the option in the provider specific options.
If you go through the CloudStackTemplateOptions path, I wouldn't
populate it to the portable options, although some other providers
(AWS and Azure for example) already support that kind of user data. We
can open a JIRA issue to study if it makes sense to expose such a
binary property in the portable model. That option is often used to
provide bootstrap scripts, and other initialisation stuff, so we'd
better understand first how people is using it in the different
providers and then make room for such a feature in the portable
options.
On 1 September 2015 at 09:39, MANIE Irmo <ir...@leonteq.com> wrote:
> The CloudStack userData is more of a free format entry, so using the userMetaData for it is not such a good idea because it limits you to key/value.
> Also considering that the generic userMetaData is now added as CloudStack tags (which are actually key-value tags), it might get confusing what is used where.
>
> I reckon we just need to add it as a new property in CloudStackTemplateOptions first, then map it down into the adapter.
> But I guess we can't push the property up to TemplateOptions, since that's the generic one that should apply to all implementations right?
>
> - Irmo
>
> -----Original Message-----
> From: Ignasi Barrera [mailto:nacx@apache.org]
> Sent: Dienstag, 1. September 2015 09:18
> To: dev@jclouds.apache.org
> Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
>
>> and the vast variety of repos used in the various pom files makes getting the project in a compiling state a living hell.
>
> A general advice I give is to just import the project for the provider you're going to work with. There is no need to import the entire jclouds codebase in your IDE. Importing just the CloudStack API should be enough to let you work with it.
>
>> I already reported another bug, also related to the CloudStack layer [1], so I pick them up both.
>
> Awesome! Ping us here if you need help, or join the #jclouds IRC channel @ Freenode. We'll be happy to help!
>
>
> =========== The Leonteq Mail Gateway made the following annotation ===========
>
> This e-mail is confidential. If you are not the intended recipient, you should
>
> not copy it, re-transmit it, use it or disclose its contents, but should
>
> return it to the sender immediately and delete the copy from your system.
>
> Leonteq Securities is not responsible for, nor endorses, any opinion,
>
> recommendation, conclusion, solicitation, offer or agreement or any
>
> information contained in this communication.
>
> Leonteq Securities cannot accept any responsibility for the accuracy or
>
> completeness of this message as it has been transmitted over a public network.
>
> If you suspect that the message may have been intercepted or amended, please
>
> call the sender. Should you require any further information, please contact
>
> the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
>
>
>
> ==============================================================================
RE: [1.9.1] - CloudStack - userMetaData vs userData
Posted by MANIE Irmo <ir...@leonteq.com>.
The CloudStack userData is more of a free format entry, so using the userMetaData for it is not such a good idea because it limits you to key/value.
Also considering that the generic userMetaData is now added as CloudStack tags (which are actually key-value tags), it might get confusing what is used where.
I reckon we just need to add it as a new property in CloudStackTemplateOptions first, then map it down into the adapter.
But I guess we can't push the property up to TemplateOptions, since that's the generic one that should apply to all implementations right?
- Irmo
-----Original Message-----
From: Ignasi Barrera [mailto:nacx@apache.org]
Sent: Dienstag, 1. September 2015 09:18
To: dev@jclouds.apache.org
Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
> and the vast variety of repos used in the various pom files makes getting the project in a compiling state a living hell.
A general advice I give is to just import the project for the provider you're going to work with. There is no need to import the entire jclouds codebase in your IDE. Importing just the CloudStack API should be enough to let you work with it.
> I already reported another bug, also related to the CloudStack layer [1], so I pick them up both.
Awesome! Ping us here if you need help, or join the #jclouds IRC channel @ Freenode. We'll be happy to help!
=========== The Leonteq Mail Gateway made the following annotation ===========
This e-mail is confidential. If you are not the intended recipient, you should
not copy it, re-transmit it, use it or disclose its contents, but should
return it to the sender immediately and delete the copy from your system.
Leonteq Securities is not responsible for, nor endorses, any opinion,
recommendation, conclusion, solicitation, offer or agreement or any
information contained in this communication.
Leonteq Securities cannot accept any responsibility for the accuracy or
completeness of this message as it has been transmitted over a public network.
If you suspect that the message may have been intercepted or amended, please
call the sender. Should you require any further information, please contact
the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
==============================================================================
Re: [1.9.1] - CloudStack - userMetaData vs userData
Posted by Ignasi Barrera <na...@apache.org>.
> and the vast variety of repos used in the various pom files makes getting the project in a compiling state a living hell.
A general advice I give is to just import the project for the provider
you're going to work with. There is no need to import the entire
jclouds codebase in your IDE. Importing just the CloudStack API should
be enough to let you work with it.
> I already reported another bug, also related to the CloudStack layer [1], so I pick them up both.
Awesome! Ping us here if you need help, or join the #jclouds IRC
channel @ Freenode. We'll be happy to help!
RE: [1.9.1] - CloudStack - userMetaData vs userData
Posted by MANIE Irmo <ir...@leonteq.com>.
I'm happy to contribute the changes, but it's going to take a while. I'm behind a company proxy and that combination with maven and the vast variety of repos used in the various pom files makes getting the project in a compiling state a living hell.
I already reported another bug, also related to the CloudStack layer [1], so I pick them up both.
- Irmo
[1] https://issues.apache.org/jira/browse/JCLOUDS-993
-----Original Message-----
From: Ignasi Barrera [mailto:nacx@apache.org]
Sent: Dienstag, 1. September 2015 00:13
To: dev@jclouds.apache.org
Subject: Re: [1.9.1] - CloudStack - userMetaData vs userData
I assume you refer to this userData [1]. I'm not a CloudStack user, so I don't know how that user data is expected to be used, but what you propose makes sense to me (taking into account the size limitation of that property).
Adding this feature should be pretty straightforward. You just have to customize the DeployVirtualMachineOptions used to create the VM to include the encoded userData, extracted from the given metadata. Do you want to open a JIRA issue to track this and try contributing a patch as a pull request? I'll be happy to help if you're interested in contributing.
I.
[1] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/options/DeployVirtualMachineOptions.java#L208-L222
[2] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java#L166
On 26 August 2015 at 18:02, MANIE Irmo <ir...@leonteq.com> wrote:
> Hi,
>
> In the compute service api there is a template option 'userMetaData',
> but this data is merged with the tags in the CloudStack adapter. [1] In the CloudStack specific options there is also a 'userData' property [2] . Is there plan to be able to populate this via the general template options and embed this in the CloudStackTemplateOptions?
> That specific property is very useful for our provisioning because it becomes available via a simple VM local REST api [3]. This way we can figure out what to install on the VM without having to consult CloudStack for the tags, since these are not available via that local api.
>
> This is for me the only reason I now have to use the CloudStack specific compute api so I don't benefit from all the high level goodies.
>
> - Irmo
>
> [1]
> https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/mai
> n/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServic
> eAdapter.java#L256 [2]
> https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/mai
> n/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOption
> s.java [3]
> http://cloudstack-administration.readthedocs.org/en/latest/api.html
>
>
>
>
>
> =========== The Leonteq Mail Gateway made the following annotation
> ===========
>
> This e-mail is confidential. If you are not the intended recipient,
> you should
>
> not copy it, re-transmit it, use it or disclose its contents, but
> should
>
> return it to the sender immediately and delete the copy from your system.
>
> Leonteq Securities is not responsible for, nor endorses, any opinion,
>
> recommendation, conclusion, solicitation, offer or agreement or any
>
> information contained in this communication.
>
> Leonteq Securities cannot accept any responsibility for the accuracy
> or
>
> completeness of this message as it has been transmitted over a public network.
>
> If you suspect that the message may have been intercepted or amended,
> please
>
> call the sender. Should you require any further information, please
> contact
>
> the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
>
>
>
> ======================================================================
> ========
Re: [1.9.1] - CloudStack - userMetaData vs userData
Posted by Ignasi Barrera <na...@apache.org>.
I assume you refer to this userData [1]. I'm not a CloudStack user, so
I don't know how that user data is expected to be used, but what you
propose makes sense to me (taking into account the size limitation of
that property).
Adding this feature should be pretty straightforward. You just have to
customize the DeployVirtualMachineOptions used to create the VM to
include the encoded userData, extracted from the given metadata. Do
you want to open a JIRA issue to track this and try contributing a
patch as a pull request? I'll be happy to help if you're interested in
contributing.
I.
[1] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/options/DeployVirtualMachineOptions.java#L208-L222
[2] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java#L166
On 26 August 2015 at 18:02, MANIE Irmo <ir...@leonteq.com> wrote:
> Hi,
>
> In the compute service api there is a template option 'userMetaData', but this data is merged with the tags in the CloudStack adapter. [1]
> In the CloudStack specific options there is also a 'userData' property [2] . Is there plan to be able to populate this via the general template options and embed this in the CloudStackTemplateOptions?
> That specific property is very useful for our provisioning because it becomes available via a simple VM local REST api [3]. This way we can figure out what to install on the VM without having to consult CloudStack for the tags, since these are not available via that local api.
>
> This is for me the only reason I now have to use the CloudStack specific compute api so I don't benefit from all the high level goodies.
>
> - Irmo
>
> [1] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java#L256
> [2] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/options/CloudStackTemplateOptions.java
> [3] http://cloudstack-administration.readthedocs.org/en/latest/api.html
>
>
>
>
>
> =========== The Leonteq Mail Gateway made the following annotation ===========
>
> This e-mail is confidential. If you are not the intended recipient, you should
>
> not copy it, re-transmit it, use it or disclose its contents, but should
>
> return it to the sender immediately and delete the copy from your system.
>
> Leonteq Securities is not responsible for, nor endorses, any opinion,
>
> recommendation, conclusion, solicitation, offer or agreement or any
>
> information contained in this communication.
>
> Leonteq Securities cannot accept any responsibility for the accuracy or
>
> completeness of this message as it has been transmitted over a public network.
>
> If you suspect that the message may have been intercepted or amended, please
>
> call the sender. Should you require any further information, please contact
>
> the Compliance Manager on compliance@leonteq.com<ma...@leonteq.com>.
>
>
>
> ==============================================================================