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 > <[email protected] <mailto:[email protected]>> 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 [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
