[one-users] updating TEMPLATE from hooks with onevm update
Olivier Sallou
olivier.sallou at irisa.fr
Wed Nov 27 08:50:35 PST 2013
On 11/27/2013 01:05 PM, Carlos Martín Sánchez wrote:
> Hi,
>
> On Tue, Nov 26, 2013 at 4:02 PM, Olivier
> Sallou <olivier.sallou at irisa.fr <mailto:olivier.sallou at irisa.fr>> wrote:
>
>
> On 11/26/2013 03:04 PM, Simon Boulet wrote:
>>
>> Perhaps that's the real problem here... I'm not very familiar
>> with context.sh script. Is the entire VM template available
>> (including the USER_TEMPLATE) or only the CONTEXT section?
>
> user_template is not set by itelf in the vm context file, only the
> context. But in my context, I add variables that refer to
> USER_TEMPLATE (but it is right that there are not set in first
> place, only after hooks). So it seems that we can refer to
> USER_TEMPLATE var, but only if there are predefined, not added in
> a hook (template not regenerated/calculated).
>
> the best would be to have user_template vars added to the
> context.sh file in addition to the one in the vm template, AFTER
> the hooks.
>
>
> True, you can get the whole VM (XML format encoded in base64) with the
> pre-defined context attribute $TEMPLATE [1]. But that will be done the
> moment the VM is created, before the on create hooks can update the
> template.
>
> We should change the behaviour and parse the context when the VM is
> deployed, or at least the $TEMPLATE variable... A more generic
> approach could be to add a synchronized hook before the VM is created,
> to allow to edit it before it is parsed by oned.
I think that a hook before VM is created, providing the vm info (user,
vm id etc..) would be perfect. But could we get the vm id is VM is not
yet created ? (vmid is necessary to update its user template).
I can manage for the moment this issue, I manage some things directly in
the VM or via an external server requested by the VM at startup but it
would be easier and better to do this directly in OpenNebula via hooks
as suggested
Olivier
>
> Meanwhile, I think you have to options:
> - Edit the VMs before they are sent to OpenNebula, in the ruby API [2][3]
> - Edit the script that creates the cdrom iso [4] and insert your
> variables, or the onevm show -x output. It will be located
> in /var/lib/one/remotes/tm/shared/context
>
> Regards
>
> [1] http://opennebula.org/documentation:rel4.2:cong
> [2] http://opennebula.org/doc/4.2/oca/ruby/OpenNebula/Template.html#instantiate-instance_method
> [3] http://opennebula.org/doc/4.2/oca/ruby/OpenNebula/VirtualMachine.html#allocate-instance_method
> [4] https://github.com/OpenNebula/one/blob/master/src/tm_mad/common/context
> --
> Carlos Martín, MSc
> Project Engineer
> OpenNebula - Flexible Enterprise Cloud Made Simple
> www.OpenNebula.org
> <http://www.opennebula.org/> | cmartin at opennebula.org
> <mailto:cmartin at opennebula.org> | @OpenNebula
> <http://twitter.com/opennebula>
>
>
> On Tue, Nov 26, 2013 at 4:02 PM, Olivier Sallou
> <olivier.sallou at irisa.fr <mailto:olivier.sallou at irisa.fr>> wrote:
>
>
> On 11/26/2013 03:04 PM, Simon Boulet wrote:
>> Bonjour Olivier,
>>
>> I think there are two issues in your question.
>>
>> On Tue, Nov 26, 2013 at 5:55 AM, Olivier Sallou
>> <olivier.sallou at irisa.fr <mailto:olivier.sallou at irisa.fr>> wrote:
>>
>>
>> On 11/26/2013 11:51 AM, Olivier Sallou wrote:
>>>
>>> On 11/26/2013 11:14 AM, Carlos Martín Sánchez wrote:
>>>> stored in VM/USER_TEMPLATE. You can see this with the onevm
>>>> show -x command. The onevm update action only allows to
>>>> edit the USER_TEMPLATE attributes, and as you described,
>>>> the create hook is triggered after the VM has been
>>>> correctly created.
>>>>
>>
>> First, yes, you can use the VM CREATE hooks to inject or change
>> the USER_TEMPLATE attributes by issuing the onevm update action.
>> To prevent VMs from being deployed before the hooks has run, you
>> can set VM_SUBMIT_ON_HOLD = "YES", and have your hook do a onevm
>> release at the end of its execution for the scheduler to pick and
>> deploy the VM. This will make sure that when the VM is deployed,
>> the template contains all the attributes you wanted.
>>
>> You can also do some extra sanitization / filtering and not allow
>> the VM to be deployed if contains some missing attributes, etc.
>> by not calling the onevm release at the end.
>>
>> This works very well for us. In fact, we do some heavy stuff in
>> the hooks, such as attaching additional IP addresses, attaching
>> or detaching disks, etc. dynamically according to external
>> sources, such as the OpenNebula user template (but also external
>> databases, CRM, etc.)
> My hook job is ok regarding vm user_template update, I tried with
> and without VM_SUBMIT_ON_HOLD (thanks for the hint), but I have
> the same issue, my user_template variables are not set in the
> context.sh file.
>
>>
>>
>>> What I expect is to get my USER_TEMPLATE in the context.sh
>>> mounted in my VM.
>>>
>>> A basic use case is to generate a unique password for a web
>>> application running in the VM. I'd like to generate the
>>> passsword with a hook and send the password to the user by
>>> mail (until here, this is fine). The generated password is
>>> also in the VM context/template so that it appears in the
>>> context.sh of the VM. At startup, a specific init script
>>> read the VM contextualization and init the web application
>>> with the password provided.
>> The above example could be managed directly in the VM,
>> without specific contextualization, but there are cases where
>> some variables could be user dependent, so those variables
>> would need to be set dynamically on opennebula server side.
>>
>>
>>
>> Perhaps that's the real problem here... I'm not very familiar
>> with context.sh script. Is the entire VM template available
>> (including the USER_TEMPLATE) or only the CONTEXT section?
>
> user_template is not set by itelf in the vm context file, only the
> context. But in my context, I add variables that refer to
> USER_TEMPLATE (but it is right that there are not set in first
> place, only after hooks). So it seems that we can refer to
> USER_TEMPLATE var, but only if there are predefined, not added in
> a hook (template not regenerated/calculated).
>
> the best would be to have user_template vars added to the
> context.sh file in addition to the one in the vm template, AFTER
> the hooks.
>
> Olivier
>>
>> Simon
>>
>
> --
> Olivier Sallou
> IRISA / University of Rennes 1
> Campus de Beaulieu, 35000 RENNES - FRANCE
> Tel: 02.99.84.71.95
>
> gpg key id: 4096R/326D8438 (keyring.debian.org <http://keyring.debian.org>)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org <mailto:Users at lists.opennebula.org>
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
--
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131127/1579f4b0/attachment-0002.htm>
More information about the Users
mailing list