[glue-wg] GLUE2.1 draft: request for final discussion and approval

[Stephen Burke - UKRI STFC]

> I'll look at the Cloud part later.

These are mostly just technical comments, I don't know enough about how you use the cloud information to judge whether the attributes are the right ones, but I assume you've done some prototyping by now.

In the Service you say that the AUP should be a URL - if you want that to be a hard restriction you should type it as a URL rather than a string so it could be type-checked.

I'm a bit surprised that there are no new attributes in Endpoint, especially as the text above the table suggests that there should be - did something get missed out?

For the Share relations you have 1..* for Endpoint and Resource which is wrong, they should follow the inherited attributes and be *, i.e. the only mandatory relation is Service. The diagram is correct. I won't necessarily spot all mistakes in relations so someone should probably go through and check systematically that everything is consistent.

I would rename ShareAcceleratorInfo to AcceleratorLimit (lots of Info classes!).

I find the Share limits a bit confusing, i.e. the InstanceMaxXxx. Presumably you've done that to allow for different Shares allowing users to instantiate the same VMs with different limits, but I wonder if that's an important feature - the alternative would be to put limits in InstanceType and just have multiple objects if you have instances with different limits. Anyway if I look at InstanceType you have mandatory CPU and RAM attributes which suggest that the values are just fixed, so I don't understand where the limits come in - are they just defaults, or what?

For Manager: MaxRAM seems a slightly strange thing to publish, is it useful? I'm also not sure what you'd do with the InstanceMax/Min attributes. Clients should be looking at the Share rather than the Manager, so these would normally be for monitoring or accounting use cases, is there a need to monitor those things?

InstanceType: I'd be inclined to call the ID attribute something like InstanceID or TemplateID rather than IDForEndpoint, I don't think there's any particular need to specify a use in the name.

Again if MarketPlaceID is supposed to be a URL you should type it as such and perhaps call it URL rather than ID. Also a trivial point, I'd call it Marketplace rather than MarketPlace, it's a single word.

The vCPU attribute should probably just be called CPU, the virtual part is implied by the context (and you don't have vRAM). And as above, I don't really understand what these mean if the number can be variable.

Perhaps my ignorance, but is the network connectivity really bound to the image rather than being specified when you instantiate it?

NetworkPortsIn/Out, do you really want an explicit list of every port rather than allowing a range?

OtherHardware should probably be an open enumeration, otherwise it's effectively free text and not useful for selection.

The text says CloudComputingPrice but the class is actually called CloudServicePrice.

VirtualAcclelerator to InstanceType is *-*, better to have it *-1 and just duplicate it if necessary - logically it's part of the Instance. Also I'd again ask whether this is a realistic use case - will you really have VMs with multiple GPU types? Again ComputeCapability should probably be an open enumeration.

I'll stop there and come back later ...

Stephen