Hi Sander,
4. Images should not be pre-configured to obtain a workload. How the running instance of an image obtains a workload is a contextualization option left to the site at which the image is instantiated.
The rules of engagement with respect to the contextualization are not specified in the policy. Point 7.4 is quite dependent upon how a site, endorser and image combiner might interpret the options in which contextualization can be done.
5. Instantiated images should not be any more constrained, notably in terms of network access, than a normal worker node at the site at which the image is instantiated.
Isn't this something that you state to a Site admin, not an Endorser?
6. There should be no installed accounts or user credentials of any form in an image.
I assume (must be clarified) that the policy refers to personal unix accounts. This account might belong to any of the specified (human) roles. This is what seems to be forbidden by the policy including credentials.
Nitpicking: I think point number 7.9 should be moved to 7.1 IMHO
8. You must assist the Grid in security incident response and must have a vulnerability assessment process in place.
So the Endorser is the one that gets all the blame, plus the role to act in the security incidents of 300+ sites. I hope the role of Endorser is plural to the poor soul that says 'yes' to the job.
10. You recognise that if a Site runs an image which no longer appears on your list of endorsed images no longer endorsed, that you are no longer responsible for any consequences of this.
(crooked sentence)
So, if I was an Endorser and shit has severely hit (and smothered) the fan then I would remove an endorsed image from the endorsed list and claim that it was not to be executed from a certain moment in time. This is probably what you do not wish to imply.
Oscar
On 22/4/10 9:58 AM, Sander Klous wrote:
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
ct-grid mailing list ct-grid@nikhef.nl https://mailman.nikhef.nl/mailman/listinfo/ct-grid