[one-users] updating TEMPLATE from hooks with onevm update

[Carlos Martín Sánchez]

Hi,

On Tue, Nov 26, 2013 at 4:02 PM, Olivier Sallou <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.

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 |
@OpenNebula <http://twitter.com/opennebula> <cmartin at opennebula.org>


On Tue, Nov 26, 2013 at 4:02 PM, Olivier Sallou <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>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)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131127/2be57300/attachment-0002.htm>