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>. > > > > > > > > ====================================================================== > > ======== >
