Hi Jeff,
clarification on the other issue (getting a workload) is also important. i can understand why you would not want the image to get a "workload" (I would call it a job) from the site's batch system. you wouldn't even allow it. configured or not.
on the other hand, workload could also refer to something in the experiment's task queue off site. this would mean that the VM "woke up" as a pilot job. I don't see anything wrong with that at all. and that would be a type of pre-configuration.
The point is that "you don't see anything wrong with that", but other sites might. So, we don't want to specify it in the policy. That's why it is left a site contextualization issue, so each site can apply the mechanisms they are happy with. Another option would be to create X different versions of an image, each of them with a different way to retrieve the workload, sites can pick the ones they allow. That would not be inline with the philosophy of generating cross-site images, which is the main purpose of this policy.
On 22 Apr 2010, at 09:21, Sander Klous wrote:
Hi Jeff, (This time with reply-all, sorry)
- I think what they mean with pre-configured accounts is actually pre-configured credentials, which is a security concern. I will try to get this point clarified in the working group.
- The original proposal was to pre-configure the VM to connect back to the site batch system. This is the main mode of operation at CERN. At Nikhef this will never happen, so a different way is required to retrieve a workload (e.g. connect to a pilot job framework). Hence, in order to make an image usable cross-site, the mechanism to obtain the workerload can not be pre-configured.
Thanks for the feedback, Sander
On Apr 22, 2010, at 9:15 AM, Jeff Templon wrote:
Hi
mostly looks ok, but i do not understand two points:
why no pre-configured accounts? why should a combined ALICE VO image not contain an "alice" user account, already set up to go?
why not pre-configured to retrieve a workload?
Both of these things are valuable from the VO point of view. I would like to understand what the objections are. Other than the obvious one, being if one forbids enough of the advantages, then nobody will submit VMs ...
JTOn 22 Apr 2010, at 09:05, Sander Klous wrote:
Hi, Comments please. Preferably before the meeting starts at 16:00 this afternoon. -- Sander
Begin forwarded message:
Resent-From: hepix-virtualisation@cern.ch From: david.kelsey@stfc.ac.uk Date: April 22, 2010 12:32:26 AM GMT+02:00 To: hepix-virtualisation@cern.ch Subject: Updated draft of VM policy
Dear all,
The updated draft (V1.2) of the Virtualisation Policy may be found at the JSPG wiki...
http://www.jspg.org/wiki/Policy_Trusted_Virtual_Machines
I also attach a PDF version just in case this is not reachable.
Lots of things to be discussed I am sure :=)
For discussion tomorrow.
Regards Dave
Dr David Kelsey Particle Physics Department Rutherford Appleton Laboratory Chilton, DIDCOT, OX11 0QX, UK
e-mail: david.kelsey@stfc.ac.uk Tel: [+44](0)1235 445746 (direct) Fax: [+44](0)1235 446733
-- Scanned by iCritical.
<VirtualisationPolicy-v1.2.pdf>
ct-grid mailing list ct-grid@nikhef.nl https://mailman.nikhef.nl/mailman/listinfo/ct-grid