[one-users] Reference CONTEXT variables within CONTEXT
Valentin Bud
valentin.bud at gmail.com
Sun May 19 23:03:09 PDT 2013
Hi,
On Sat, May 18, 2013 at 12:05 PM, Valentin Bud <valentin.bud at gmail.com>wrote:
> Hello Carlos,
>
> I would gladly open a request if you and others from the community think
> this is useful.
> I see this topic as a Request For Comments :-).
>
> For me the NAME of the VM would prove useful to be available within
> CONTEXT. The NAME being the `onetemplate instantiate 8 --name NAME`
>
> This way I could have the following template which the users could use:
>
> CONTEXT=[
> CONTEXT_FILES_LOCATION="$CONTEXT_FILES_LOCATION",
> DOMAIN="$DOMAIN",
> FILES="$CONTEXT_FILES_LOCATION/$FQDN/ssh_host_rsa_key
> $CONTEXT_FILES_LOCATION/$FQDN/ssh_host_rsa_key.pub",
> FQDN="$HOSTNAME.$DOMAIN.",
> HOSTNAME="$HOSTNAME" ]
> CONTEXT_FILES_LOCATION="/var/lib/cloud/context"
> CPU="1"
> DISK=[
> IMAGE="debian6-stable" ]
> DISK=[
> IMAGE="vdb.$HOSTNAME.$DOMAIN" ]
> DOMAIN="domain.tld"
> GRAPHICS=[
> LISTEN="0.0.0.0",
> TYPE="vnc" ]
> ** HOSTNAME="$NAME" **
> MEMORY="2048"
> NIC=[
> NETWORK="dev.domain.tld" ]
> OS=[
> ARCH="x86_64" ]
> VCPU="4"
>
> From Sunstone, at instantiation time you are asked to give the VM a name.
> That NAME could be used in the template also. Maybe NAME is not the proper
> way for this variable.
>
I meant that maybe NAME is not the proper name for this variable. Another
question would be: could I use a variable, DB_NAME for example, in the
template and reference that from within IMAGE? I will try this today and
come back with the results.
DB_NAME=dbtest
HOSTNAME=$DB_NAME
DISK=[
IMAGE="vdb.$DB_NAME.domain.tld ]
I am trying to simplify the instantiation process for the users by
providing the template and creating the second disk on the fly. In this way
the user would only change the DB_NAME to a given name and everything would
happen automagically behind the scenes.
For now, the user needs to clone a persistent image for the second disk,
change the $HOSTNAME and the name of the second disk to the one previously
cloned. After this two steps the user can instantiate the new VM. This
process is prone to human errors.
If I could save the second disk and reference the DB_NAME from within IMAGE
I would restrict all the attributes from the template besides DB_NAME and
the process would be less prone to errors.
Does the above make any sense?
>
> The above applies to my use case. In my case each project I run on top of
> OpenNebula is a (sub)domain.
>
> The above would ease the process of instantiating a new VM. Maybe I could
> even use a hook to create the second image on the fly at CREATE time,
> though I think OpenNebula would complain that the disk is missing. Haven't
> tested this yet.
>
I am off the track here. It would be nice to be able to save the Volatile
disks. In my use case we need to preserve the disk on which the DB lives
for accounting purposes. I don't see a point in reinventing the wheel with
a hook.
Thanks for your input on this matter.
Cheers and Goodwill,
>
> Thoughts? Thanks.
>
> Cheers and Goodwill,
>
>
> On Fri, May 17, 2013 at 4:47 PM, Carlos Martín Sánchez <
> cmartin at opennebula.org> wrote:
>
>> Hi,
>>
>> I'm glad you found a way to make it work.
>>
>> If it is really needed, we could add support to reference other context
>> attributes. Please open a request If you still think it would be better.
>>
>> Cheers,
>> Carlos
>>
>> --
>> Join us at OpenNebulaConf2013 <http://opennebulaconf.com> in Berlin,
>> 24-26 September, 2013
>> --
>> Carlos Martín, MSc
>> Project Engineer
>> OpenNebula - The Open-source Solution for Data Center Virtualization
>> www.OpenNebula.org | cmartin at opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>
>>
>>
>> On Thu, May 16, 2013 at 2:14 PM, Valentin Bud <valentin.bud at gmail.com>wrote:
>>
>>> Hello Community,
>>>
>>> First of all, I apologise I forgot to say hi in my previous E-Mail :|.
>>>
>>> On Thu, May 16, 2013 at 10:28:14AM +0300, Valentin Bud wrote:
>>> > I am trying to reference the CONTEXT variables from within CONTEXT.
>>> >
>>> > For example, I define the DOMAIN="domain.tld" and the HOSTNAME="host".
>>> > I would like to have a variable FQDN="$HOST.$DOMAIN.".
>>> >
>>> > I have tried to achieve the above using the following in CONTEXT
>>> section
>>> > of the template.
>>> >
>>> > Case I
>>> > --
>>> >
>>> > $ onetemplate show vars
>>> >
>>> > TEMPLATE CONTENTS
>>> > CONTEXT=[
>>> > DOMAIN="domain.tld",
>>> > FQDN="$DOMAIN.$HOSTNAME.",
>>> > HOSTNAME="host" ]
>>> >
>>> > [... output omitted for brevity ...]
>>> >
>>> > Instantiating the template results in the following variables added to
>>> > the VM.
>>> >
>>> > $ onevm show vars
>>> >
>>> > VIRTUAL MACHINE TEMPLATE
>>> > CONTEXT=[
>>> > DISK_ID="1",
>>> > DOMAIN="domain.tld",
>>> > *FQDN="..",*
>>> > HOSTNAME="host",
>>> > TARGET="hda" ]
>>> >
>>> > Case II
>>> > --
>>> >
>>> > $ onetemplate show vars
>>> >
>>> > CONTEXT=[
>>> > DOMAIN="domain.tld",
>>> > FQDN="$CONTEXT[$DOMAIN].$CONTEXT[$HOSTNAME].",
>>> > HOSTNAME="host" ]
>>> > [... output omitted for brevity ...]
>>> >
>>> > Same result in the VM.
>>> >
>>> > $ onevm show vars
>>> >
>>> > VIRTUAL MACHINE TEMPLATE
>>> > CONTEXT=[
>>> > DISK_ID="1",
>>> > DOMAIN="domain.tld",
>>> > *FQDN=".."*,
>>> > HOSTNAME="host",
>>> > TARGET="hda" ]
>>> > [... output omitted for brevity ...]
>>> >
>>> > Is it possible to achieve what am I trying or should I search for a new
>>> > solution?
>>> >
>>> > I have a simple use case. I am generating, via a hook, the ssh keys for
>>> > the VM in question. At boot I copy the keys from /mnt to /etc/ssh via
>>> > a crafted one-context script. Awesome mechanism by the way :-).
>>> >
>>> > I am generating the keys in
>>> > CONTEXT_FILES_LOCATION=/var/lib/cloud/context/host.domain.tld.
>>> >
>>> > I would like to use the following in the CONTEXT section:
>>> >
>>> > CONTEXT=[
>>> > CONTEXT_FILES_LOCATION=/var/lib/cloud/context/host.domain.tld./,
>>> > DOMAIN="domain.tld",
>>> > FILES="$CONTEXT_FILES_LOCATION/$FQDN/ssh_host_rsa_key ...",
>>> > HOSTNAME="host",
>>> > FQDN="$HOSTNAME.$DOMAIN." ]
>>> >
>>> > This makes the template much more dynamic. I would just change the
>>> HOSTNAME
>>> > and the paths would get generated dynamically.
>>> >
>>>
>>> Writing the HOSTNAME, DOMAIN, CONTEXT_FILES_LOCATION outside the CONTEXT
>>> section and referencing them from within CONTEXT works :-).
>>>
>>> Example
>>> --
>>>
>>> $ onetemplate show vars
>>>
>>> TEMPLATE CONTENTS
>>> CONTEXT=[
>>> CONTEXT_FILES_LOCATION="$CONTEXT_FILES_LOCATION",
>>> DOMAIN="$DOMAIN",
>>> FILES="$CONTEXT_FILES_LOCATION/$FQDN/ssh_host_rsa_key
>>> $CONTEXT_FILES_LOCATION/$FQDN/ssh_host_rsa_key.pub",
>>> FQDN="$HOSTNAME.$DOMAIN.",
>>> HOSTNAME="$HOSTNAME" ]
>>> CONTEXT_FILES_LOCATION="/var/lib/cloud/context"
>>> CPU="1"
>>> DISK=[
>>> IMAGE="vars" ]
>>> DOMAIN="domain.tld"
>>> GRAPHICS=[
>>> LISTEN="0.0.0.0",
>>> TYPE="vnc" ]
>>> HOSTNAME="host"
>>> MEMORY="2048"
>>> NIC=[
>>> NETWORK="host.domain.tld" ]
>>> OS=[
>>> ARCH="x86_64" ]
>>> VCPU="4"
>>>
>>> After instantiating the machine I have the desired results.
>>>
>>> $ onevm show vars
>>>
>>> VIRTUAL MACHINE TEMPLATE
>>> CONTEXT=[
>>> CONTEXT_FILES_LOCATION="/var/lib/cloud/context",
>>> DISK_ID="1",
>>> DOMAIN="dev.corview.de",
>>> FILES="/var/lib/cloud/context//ssh_host_rsa_key
>>> /var/lib/cloud/context//ssh_host_rsa_key.pub",
>>> FQDN="vars.domain.tld.",
>>> HOSTNAME="vars",
>>> TARGET="hda" ]
>>>
>>> Now I can easily generate SSH host keys for each machine if this wasn't
>>> done already in a previous VM instantation.
>>>
>>> Thanks and sorry for the noise. If this is mentioned somewhere in the
>>> docs, my bad.
>>>
>>> Cheers and Goodwill,
>>>
>>> --
>>> Valentin Bud
>>> http://databus.pro/ | valentin at databus.pro
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>
>>
> --
> Valentin Bud
> http://databus.pro | valentin at databus.pro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130520/60ade243/attachment-0002.htm>
More information about the Users
mailing list