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 <irmo.ma...@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: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>. >> > >> > >> > >> > ==================================================================== >> > == >> > ======== >>
