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

[Simon Boulet]

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


>  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?

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20131126/1dfde801/attachment-0002.htm>