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