Glue 2.1 draft new version (0.5) - little modification
Dear all, when working on the implementation of the new schema for the cloud prototype, with Baptiste and Enol we agreed on a little modification regarding two attributes for better representing the current situation. In the CloudComputingEndpoint class there are the following attributes: - ContextualizationName: supported contextualization mechanism (cloudinit, bash), if any; - ContextualizationVersion: supported contextualization mechanism version In our opinion these attributes should refer to the single image rather than describing a global feature of the entire endpoint; they would have more sense if they belong to the CloudComputingImage class. Our proposal is moving them under CloudComputingImage class, so their new name will be: GLUE2CloudComputingImageContextualizationName GLUE2CloudComputingImageContextualizationVersion Please let us know what do you think about it, in case we can also discuss it next week during the meeting. For you convenience I've also produced a new version of the draft, attached to this email, reflecting this change. Best regards, Alessandro -- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Heya gluers, One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached. Thanks --jens On 16/08/2017 12:38, Alessandro Paolini wrote:
Dear all,
when working on the implementation of the new schema for the cloud prototype, with Baptiste and Enol we agreed on a little modification regarding two attributes for better representing the current situation.
In the CloudComputingEndpoint class there are the following attributes:
- ContextualizationName: supported contextualization mechanism (cloudinit, bash), if any; - ContextualizationVersion: supported contextualization mechanism version
In our opinion these attributes should refer to the single image rather than describing a global feature of the entire endpoint; they would have more sense if they belong to the CloudComputingImage class.
Our proposal is moving them under CloudComputingImage class, so their new name will be: GLUE2CloudComputingImageContextualizationName GLUE2CloudComputingImageContextualizationVersion
Please let us know what do you think about it, in case we can also discuss it next week during the meeting. For you convenience I've also produced a new version of the draft, attached to this email, reflecting this change.
Best regards, Alessandro
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen,
Jens (STFC,RAL,SC) said: One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached.
We didn't discuss this, but my comments would be: P1: seems uncontroversial. P2: The semantics for multiple paths would need to be clear - in the past it was used as a default path on which to write files, if you have more than one it wouldn't be obvious. A more backward compatible approach would be to add a new multivalued attribute for additional paths, then it's clear that the existing one should be the default. P3: The reason for having a separate Capacity object was that there are potentially many different semantics for what the attributes can refer to. Putting the attributes back in the main object would need both a clear definition for which precise semantics are intended, and a case for why those particular semantics are universally the most important ones. Personally I don't think it's a useful idea given that the information is already available from the existing object. P4: Seems like a strange idea to me. StorageShareCapacity is logically a part of the StorageShare object, hence the name and indeed the proposal in P3. If a similar object is wanted for Datastore then it should be a new object with a new name. In principle it's possible that one Share could be spread across multiple Datastores so there's no simple relation between them. Stephen
Thanks, Stephen. I tried to join the call, and it was only after having downloaded the client 4-5 times I remembered that Skype for business only works in IE, not in FF (at least not for me) On 23/08/2017 15:45, Burke, Stephen (STFC,RAL,PPD) wrote:
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen,
Jens (STFC,RAL,SC) said: One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached. We didn't discuss this, but my comments would be:
P1: seems uncontroversial.
P2: The semantics for multiple paths would need to be clear - in the past it was used as a default path on which to write files, if you have more than one it wouldn't be obvious. A more backward compatible approach would be to add a new multivalued attribute for additional paths, then it's clear that the existing one should be the default.
P3: The reason for having a separate Capacity object was that there are potentially many different semantics for what the attributes can refer to. Putting the attributes back in the main object would need both a clear definition for which precise semantics are intended, and a case for why those particular semantics are universally the most important ones. Personally I don't think it's a useful idea given that the information is already available from the existing object.
P4: Seems like a strange idea to me. StorageShareCapacity is logically a part of the StorageShare object, hence the name and indeed the proposal in P3. If a similar object is wanted for Datastore then it should be a new object with a new name. In principle it's possible that one Share could be spread across multiple Datastores so there's no simple relation between them.
Stephen
On 23/08/2017 17:17, Jensen, Jens (STFC,RAL,SC) wrote:
Thanks, Stephen. I tried to join the call, and it was only after having downloaded the client 4-5 times I remembered that Skype for business only works in IE, not in FF (at least not for me) Sorry, hit send too soon.
But it would be useful to have a dialogue about how to figure this out - I'd much prefer to not have a separate format for each of the WLCG experiments in addition to the GLUE. Maybe extensions - I was planning to have a think about it this month. Cheers --jens
Chrome and Safari also work. JP
On Aug 23, 2017, at 11:17 AM, Jensen, Jens (STFC,RAL,SC) <jens.jensen@stfc.ac.uk> wrote:
Thanks, Stephen. I tried to join the call, and it was only after having downloaded the client 4-5 times I remembered that Skype for business only works in IE, not in FF (at least not for me)
On 23/08/2017 15:45, Burke, Stephen (STFC,RAL,PPD) wrote:
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen,
Jens (STFC,RAL,SC) said: One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached. We didn't discuss this, but my comments would be:
P1: seems uncontroversial.
P2: The semantics for multiple paths would need to be clear - in the past it was used as a default path on which to write files, if you have more than one it wouldn't be obvious. A more backward compatible approach would be to add a new multivalued attribute for additional paths, then it's clear that the existing one should be the default.
P3: The reason for having a separate Capacity object was that there are potentially many different semantics for what the attributes can refer to. Putting the attributes back in the main object would need both a clear definition for which precise semantics are intended, and a case for why those particular semantics are universally the most important ones. Personally I don't think it's a useful idea given that the information is already available from the existing object.
P4: Seems like a strange idea to me. StorageShareCapacity is logically a part of the StorageShare object, hence the name and indeed the proposal in P3. If a similar object is wanted for Datastore then it should be a new object with a new name. In principle it's possible that one Share could be spread across multiple Datastores so there's no simple relation between them.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
Hi Jens, sorry for not replying before: I've just noticed that your message (and the consequent reply by Stephen) finished in the spam folder... Regarding the P1, I will correct the document, thank you for spotting this (I'm being in vacation since tomorrow till Sep 12th, so in the next two weeks i'm not being able to participate to the discussion). Regarding P2, P3, and P4 it is not completely clear to me the need, maybe because I look at the GLUESchema as operator/administrator rather then user, and I don't know well the needs of the experiments. cheers, Alessandro On 23 August 2017 at 16:45, <stephen.burke@stfc.ac.uk> wrote:
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen,
Jens (STFC,RAL,SC) said: One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached.
We didn't discuss this, but my comments would be:
P1: seems uncontroversial.
P2: The semantics for multiple paths would need to be clear - in the past it was used as a default path on which to write files, if you have more than one it wouldn't be obvious. A more backward compatible approach would be to add a new multivalued attribute for additional paths, then it's clear that the existing one should be the default.
P3: The reason for having a separate Capacity object was that there are potentially many different semantics for what the attributes can refer to. Putting the attributes back in the main object would need both a clear definition for which precise semantics are intended, and a case for why those particular semantics are universally the most important ones. Personally I don't think it's a useful idea given that the information is already available from the existing object.
P4: Seems like a strange idea to me. StorageShareCapacity is logically a part of the StorageShare object, hence the name and indeed the proposal in P3. If a similar object is wanted for Datastore then it should be a new object with a new name. In principle it's possible that one Share could be spread across multiple Datastores so there's no simple relation between them.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Alessandro Paolini Sent: 16 August 2017 12:38 said:
For you convenience I've also produced a new version of the draft, attached to this email, reflecting this change.
One comment on the new attributes for accelerators. You have things like: "The number of accelerator cards slots which are currently unoccupied by jobs and are free for new jobs in this Share to start immediately. The syntax is AcceleratorType:n, e.g. GPU:4 MIC:2 FPGA:1" That kind of syntax is clumsy and hard to parse and verify for correctness. It would be better to create separate new objects for each accelerator type, with attributes like Type: GPU FreeSlots: 4 UsedSlots: 2 Also as a reminder, we had some errata for GLUE 2 that were kept somewhere in our document area - we should make sure that they get incorporated into the new document. Stephen
Hi Paolo, Marco, what do you think about Stephen's remark? Stephen, do you mean that syntax could create problems for making queries, or other? In my opinion we could have two options (the accelerator Type attribute is already defined in the AcceleratorEnvironment class): 1) creating separate attributes for each accelerator type, in the ComputingShare like: FreeGPUAcceleratorSlots UsedGPUAcceleratorSlots FreeMICAcceleratorSlots UsedMICAcceleratorSlots FreeFPGAAcceleratorSlots UsedFPGAAcceleratorSlots and in the ComputingManager class like: TotalGPUAcceleratorSlots UsedGPUAcceleratorSlots TotalMICAcceleratorSlots UsedMICAcceleratorSlots TotalFPGAAcceleratorSlots UsedFPGAAcceleratorSlots The question is: are these accelerator types the only ones expected to be provided in the coming few years? If new ones will be provided by the sites, they will not be represented, at least initially. 2) We use the already defined attributes for publishing the number of accelerators in general, regardless the type do you see any other option? In both the cases, the data type AcceleratorSlot_t should be modified: it would become simply a number, I suppose. Cheers, Alessandro On 23 August 2017 at 16:57, <stephen.burke@stfc.ac.uk> wrote:
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Alessandro Paolini Sent: 16 August 2017 12:38 said:
For you convenience I've also produced a new version of the draft, attached to this email, reflecting this change.
One comment on the new attributes for accelerators. You have things like:
"The number of accelerator cards slots which are currently unoccupied by jobs and are free for new jobs in this Share to start immediately. The syntax is AcceleratorType:n, e.g. GPU:4 MIC:2 FPGA:1"
That kind of syntax is clumsy and hard to parse and verify for correctness. It would be better to create separate new objects for each accelerator type, with attributes like
Type: GPU FreeSlots: 4 UsedSlots: 2
Also as a reminder, we had some errata for GLUE 2 that were kept somewhere in our document area - we should make sure that they get incorporated into the new document.
Stephen
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Alessandro Paolini [mailto:alessandro.paolini@egi.eu] said:
Stephen, do you mean that syntax could create problems for making queries, or other?
Yes, effectively you're creating a new mini-schema inside an attribute, so you'll have to build some kind of extra parser to manipulate it rather than just using whatever is native to the schema representation. For example, the numbers aren't numbers, just parts of strings, so you can't do numerical comparisons without extra parsing, or even verify that they are valid numbers. Also if an accelerator name is mistyped it's hard to detect, compared with an enumerated Type attribute where you can easily check whether it's a member. If you're trying to get new information into existing schema attributes that may be the only way to do it, but since we're modifying the schema here there's no reason not to do it properly.
do you see any other option?
If there could be more accelerator types defined in the future my suggestion would be to have a new separate object class like AcceleratorInfo which would be related to the Share in the same kind of way as StorageShareCapacity. Stephen
On 24 August 2017 at 10:37, <stephen.burke@stfc.ac.uk> wrote:
Alessandro Paolini [mailto:alessandro.paolini@egi.eu] said:
Stephen, do you mean that syntax could create problems for making queries, or other?
Yes, effectively you're creating a new mini-schema inside an attribute, so you'll have to build some kind of extra parser to manipulate it rather than just using whatever is native to the schema representation. For example, the numbers aren't numbers, just parts of strings, so you can't do numerical comparisons without extra parsing, or even verify that they are valid numbers. Also if an accelerator name is mistyped it's hard to detect, compared with an enumerated Type attribute where you can easily check whether it's a member. If you're trying to get new information into existing schema attributes that may be the only way to do it, but since we're modifying the schema here there's no reason not to do it properly.
do you see any other option?
If there could be more accelerator types defined in the future my suggestion would be to have a new separate object class like AcceleratorInfo which would be related to the Share in the same kind of way as StorageShareCapacity.
I personally like this option. So each ComputingShare object would report the accelerator numbers in general, and through the new object class AcceleratorInfo we would have the information on the accelerators in particular for each ComputingShare. Then the ComputingManager object could report the total numbers regardless the accelerators type, since the information on the accelerator types are already reported in the AcceleratorEnvironment object, related to the ExecutionEnvironment. Or do we need a new object for each accelerator type under ComputingManager as well for reporting the total numbers? cheers, alessandro
Stephen
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
On 08/24/2017 11:24 AM, Alessandro Paolini wrote:
On 24 August 2017 at 10:37, <stephen.burke@stfc.ac.uk <mailto:stephen.burke@stfc.ac.uk>> wrote:
Alessandro Paolini [mailto:alessandro.paolini@egi.eu <mailto:alessandro.paolini@egi.eu>] said: > Stephen, do you mean that syntax could create problems for making queries, or other?
Yes, effectively you're creating a new mini-schema inside an attribute, so you'll have to build some kind of extra parser to manipulate it rather than just using whatever is native to the schema representation. For example, the numbers aren't numbers, just parts of strings, so you can't do numerical comparisons without extra parsing, or even verify that they are valid numbers. Also if an accelerator name is mistyped it's hard to detect, compared with an enumerated Type attribute where you can easily check whether it's a member. If you're trying to get new information into existing schema attributes that may be the only way to do it, but since we're modifying the schema here there's no reason not to do it properly.
> do you see any other option?
If there could be more accelerator types defined in the future my suggestion would be to have a new separate object class like AcceleratorInfo which would be related to the Share in the same kind of way as StorageShareCapacity.
I personally like this option. So each ComputingShare object would report the accelerator numbers in general, and through the new object class AcceleratorInfo we would have the information on the accelerators in particular for each ComputingShare.
Then the ComputingManager object could report the total numbers regardless the accelerators type, since the information on the accelerator types are already reported in the AcceleratorEnvironment object, related to the ExecutionEnvironment. Or do we need a new object for each accelerator type under ComputingManager as well for reporting the total numbers?
Hi all I agree with you, the syntax proposed is not the optimal solution, indeed I've always considered it just a starting point (I was inspired by some attributes like GLUE2PolicyRule). IMHO "hardcoding" the accelerator type into the name attribute is too restrictive. In the next future we'll have new types of accelerators, think about the new neural network accelerator cards like Google TPU. So I'd avoid to have an attribute like Free***AcceleratorSlots. I agree to define a new class "AcceleratorInfo" but the trouble is: if we have more accelerator types in the same environment how can we publish the Free/Used slots per shares? It could be required to distinguish free/used slots per share AND per type. Keep in touch -- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7378 Skype: andreettopl ----------------------
Paolo Andreetto [mailto:paolo.andreetto@pd.infn.it] said:
I agree to define a new class "AcceleratorInfo" but the trouble is: if we have more accelerator types in the same environment how can we publish the Free/Used > slots per shares?
You can create an object instance per Share and give it a relation to the Share - in LDAP it would be directly under the Share in the DIT. Stephen
On 08/25/2017 11:15 AM, stephen.burke@stfc.ac.uk wrote:
Paolo Andreetto [mailto:paolo.andreetto@pd.infn.it] said:
I agree to define a new class "AcceleratorInfo" but the trouble is: if we have more accelerator types in the same environment how can we publish the Free/Used > slots per shares? You can create an object instance per Share and give it a relation to the Share - in LDAP it would be directly under the Share in the DIT.
Stephen
It makes sense. We've got to "extract": - FreeAcceleratorSlots - UsedAcceleratorSlots - MaxAcceleratorSlotsPerJob from the ComputingShare into the new objects, and do the same for the aggregated info in a ComputingManager: - TotalPhysicalAccelerators - TotalAcceleratorSlots - UsedAcceleratorSlots Now I'm really busy, ASAP I provide a new version with the new classes and relationships. Keep in touch. -- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7378 Skype: andreettopl ----------------------
Hi Paolo, did you manage to add the new classes and relationships to the document? cheers, Alessandro On 25 August 2017 at 11:35, Paolo Andreetto <paolo.andreetto@pd.infn.it> wrote:
On 08/25/2017 11:15 AM, stephen.burke@stfc.ac.uk wrote:
Paolo Andreetto [mailto:paolo.andreetto@pd.infn.it <paolo.andreetto@pd.infn.it>] said:
I agree to define a new class "AcceleratorInfo" but the trouble is: if we have more accelerator types in the same environment how can we publish the Free/Used > slots per shares?
You can create an object instance per Share and give it a relation to the Share - in LDAP it would be directly under the Share in the DIT.
Stephen
It makes sense.
We've got to "extract": - FreeAcceleratorSlots - UsedAcceleratorSlots - MaxAcceleratorSlotsPerJob from the ComputingShare into the new objects, and do the same for the aggregated info in a ComputingManager: - TotalPhysicalAccelerators - TotalAcceleratorSlots - UsedAcceleratorSlots
Now I'm really busy, ASAP I provide a new version with the new classes and relationships.
Keep in touch.
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
Hi Alessandro Not yet, I'm very busy in these days with CREAM on CentOS7. I hope to publish the new draft by the end of this week. Keep in touch -- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7378 Skype: andreettopl ----------------------
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
A new version of document is available at: https://pandora.infn.it/public/910cf0 Basically, I created several classes containing information about the (real or virtual) accelerator devices and linked them to corresponding GLUE entity. The name of the classes may result very long, expecially when dealing with Cloud Computing entities. BTW is there a way we can use to share, and maybe edit, the document without using the mail? Keep in touch. -- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7378 Skype: andreettopl ----------------------
Hi Paolo, unfortunately the link requires a password. Regarding the document sharing, perhaps it is not trivial moving it now on google docs, are you aware of other tools? cheers, Alessandro On 18 September 2017 at 15:34, Paolo Andreetto <paolo.andreetto@pd.infn.it> wrote:
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
A new version of document is available at: https://pandora.infn.it/ public/910cf0 Basically, I created several classes containing information about the (real or virtual) accelerator devices and linked them to corresponding GLUE entity. The name of the classes may result very long, expecially when dealing with Cloud Computing entities.
BTW is there a way we can use to share, and maybe edit, the document without using the mail?
Keep in touch.
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Hi all Sorry, try this one: https://pandora.infn.it/public/94f514 This is the link of the draft imported into gdrive: https://docs.google.com/document/d/1BpeTBQfCn8xRo4Ff38esRhBwzoUHE4bVxba2rEAz... Let me know if there's some problems. On 09/18/2017 04:14 PM, Alessandro Paolini wrote:
Hi Paolo,
unfortunately the link requires a password.
Regarding the document sharing, perhaps it is not trivial moving it now on google docs, are you aware of other tools?
cheers, Alessandro
On 18 September 2017 at 15:34, Paolo Andreetto <paolo.andreetto@pd.infn.it <mailto:paolo.andreetto@pd.infn.it>> wrote:
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
A new version of document is available at: https://pandora.infn.it/public/910cf0 <https://pandora.infn.it/public/910cf0> Basically, I created several classes containing information about the (real or virtual) accelerator devices and linked them to corresponding GLUE entity. The name of the classes may result very long, expecially when dealing with Cloud Computing entities.
BTW is there a way we can use to share, and maybe edit, the document without using the mail?
Keep in touch.
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <tel:+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7378 Skype: andreettopl ----------------------
thank you! On 18 September 2017 at 16:29, Paolo Andreetto <paolo.andreetto@pd.infn.it> wrote:
Hi all
Sorry, try this one: https://pandora.infn.it/public/94f514
This is the link of the draft imported into gdrive: https://docs.google.com/document/d/1BpeTBQfCn8xRo4Ff38esRhBwzoUHE 4bVxba2rEAzI-U/edit?usp=sharing
Let me know if there's some problems.
On 09/18/2017 04:14 PM, Alessandro Paolini wrote:
Hi Paolo,
unfortunately the link requires a password.
Regarding the document sharing, perhaps it is not trivial moving it now on google docs, are you aware of other tools?
cheers, Alessandro
On 18 September 2017 at 15:34, Paolo Andreetto <paolo.andreetto@pd.infn.it
wrote:
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
A new version of document is available at: https://pandora.infn.it/public /910cf0 Basically, I created several classes containing information about the (real or virtual) accelerator devices and linked them to corresponding GLUE entity. The name of the classes may result very long, expecially when dealing with Cloud Computing entities.
BTW is there a way we can use to share, and maybe edit, the document without using the mail?
Keep in touch.
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Hi Paolo, I've given a quick look, it seems fine, thank you. I'm going to modify accordingly the Accelerators definition in the cloud classes as well. cheers, Alessandro On 18 September 2017 at 16:29, Paolo Andreetto <paolo.andreetto@pd.infn.it> wrote:
Hi all
Sorry, try this one: https://pandora.infn.it/public/94f514
This is the link of the draft imported into gdrive: https://docs.google.com/document/d/1BpeTBQfCn8xRo4Ff38esRhBwzoUHE 4bVxba2rEAzI-U/edit?usp=sharing
Let me know if there's some problems.
On 09/18/2017 04:14 PM, Alessandro Paolini wrote:
Hi Paolo,
unfortunately the link requires a password.
Regarding the document sharing, perhaps it is not trivial moving it now on google docs, are you aware of other tools?
cheers, Alessandro
On 18 September 2017 at 15:34, Paolo Andreetto <paolo.andreetto@pd.infn.it
wrote:
On 09/13/2017 02:54 PM, Alessandro Paolini wrote:
Hi Paolo,
did you manage to add the new classes and relationships to the document?
A new version of document is available at: https://pandora.infn.it/public /910cf0 Basically, I created several classes containing information about the (real or virtual) accelerator devices and linked them to corresponding GLUE entity. The name of the classes may result very long, expecially when dealing with Cloud Computing entities.
BTW is there a way we can use to share, and maybe edit, the document without using the mail?
Keep in touch.
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
-- ---------------------- Ing. Paolo Andreetto INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy
Tel: +39 049.967.7378 <+39%20049%20967%207378> Skype: andreettopl ----------------------
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
Hi Paolo, I've noticed now that the Accelerators attributes are missing in the ComputingActivities class: which attributes should be added besides the ones related to the "Time"? could you please add them in the same way you did for the CloudComputingInstanceAcceleratorInfo ? On 18 September 2017 at 17:02, Alessandro Paolini <alessandro.paolini@egi.eu
wrote:
I'm going to modify accordingly the Accelerators definition in the cloud classes as well.
sorry for writing this, I was looking at the wrong document... cheers, Alessandro
cheers, Alessandro
On 18 September 2017 at 16:29, Paolo Andreetto <paolo.andreetto@pd.infn.it
wrote:
Hi all
Sorry, try this one: https://pandora.infn.it/public/94f514
This is the link of the draft imported into gdrive: https://docs.google.com/document/d/1BpeTBQfCn8xRo4Ff38esRhBw zoUHE4bVxba2rEAzI-U/edit?usp=sharing
Let me know if there's some problems.
-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin
On Sep 18, 2017, at 9:14 AM, Alessandro Paolini <alessandro.paolini@egi.eu<mailto:alessandro.paolini@egi.eu>> wrote: Regarding the document sharing, perhaps it is not trivial moving it now on google docs, are you aware of other tools? OGF provides working groups with an space to manage and share documents. This is our space: https://redmine.ogf.org/dmsf/glue-wg We should post this document under Drafts/. JP
participants (5)
-
Alessandro Paolini -
Jensen, Jens (STFC,RAL,SC) -
Navarro, JP -
Paolo Andreetto -
stephen.burke＠stfc.ac.uk