[glue-wg] Glue 2.1 draft new version (0.5) - little modification

Paolo Andreetto paolo.andreetto at pd.infn.it
Fri Aug 25 04:20:54 EDT 2017


On 08/24/2017 11:24 AM, Alessandro Paolini wrote:
>
>
> On 24 August 2017 at 10:37, <stephen.burke at stfc.ac.uk
> <mailto:stephen.burke at stfc.ac.uk>> wrote:
>
>     Alessandro Paolini [mailto:alessandro.paolini at egi.eu
>     <mailto:alessandro.paolini at 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
----------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20170825/a60b0315/attachment-0001.html>


More information about the glue-wg mailing list