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:n...@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" <irmo.ma...@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:n...@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 <irmo.ma...@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:n...@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 complia...@leonteq.com<mailto: > complia...@leonteq.com>. > > > > > > > > ==================================================================== > > == > > ======== >
