comments about cloud attributes in GLUE2.1 draft
hi Stephen, On 3 June 2018 at 14:56, Stephen Burke - UKRI STFC <stephen.burke@stfc.ac.uk
wrote:
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.
Ok for changing the type in URL
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?
originally there were two attributes regarding the contextualisation, but we moved them in another class
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.
Ok
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
Ok the limits come in - are they just defaults, or what? Enol, Baptiste, what do you think?
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?
in general we use these attributes for getting information about the hardware features of the cloud framework, independently from the Share
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.
Ok, TemplateID
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.
Ok, MarketplaceURL, type URL
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.
Ok
Perhaps my ignorance, but is the network connectivity really bound to the image rather than being specified when you instantiate it?
the network connectivity may depend on the software installed in the image
NetworkPortsIn/Out, do you really want an explicit list of every port rather than allowing a range?
yes, the applications require specific ports, and we need to take into account the network configuration in the several sites that is quite diverse
OtherHardware should probably be an open enumeration, otherwise it's effectively free text and not useful for selection.
Ok
The text says CloudComputingPrice but the class is actually called CloudServicePrice.
thank you, corrected!
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.
Marco, Paolo, Do you agree?
CloudComputingImage: conceptually this seems like another kind of Resource. I don't think we ever considered having two types of Resource in one Service and maybe it's better not to do it explicitly, but I'd expect it to be similar, and it is except for not having a relationship to Manager. Doesn't a Manager manage Images too?
Enol, Baptiste, what do you think?
There's also no relationship to InstanceType - does that mean that any VM can run any OS?
In principle, yes. Enol, Baptiste?
For the first two attributes I have the same comments as for InstanceType.
Ok
DefaultPassword is a bit surprising, should that be published?
I remember this was already discussed and agreed, I will check the past email threads.
I find ImageAcceleratorInfo a bit surprising, are there OS images that require GPUs? And if so, it seems unlikely that there are images that require more than one type?
Paolo, Marco, could you please comment on that?
NetworkTraffic doesn't seem like the right name, maybe NetworkConfiguration? And is it really part of the Image rather than the Instance? Maybe I just don't understand what it's for, the explanation isn't very detailed.
Ok for changing the name. These attributes are related to the application. Baptiste?
CloudComputingInstance: again I don't especially like the ID names, maybe ExternalID and InternalID?
Ok for renaming (the first one could become VmID) Side question: the same names (IDFromEndpoint and LocalIDFromManager) are used in the ComputingActivity class. Do we change them as well? CEJobID and LocalJobID?
It also seems like at least one of those should be mandatory so you can tell which job the object refers to. For Owner I'm not sure why you don't just make it an optional attribute and remove the CONFIDENTIAL value?
Baptiste, Enol, what do you think?
You have two attributes with ComputeManager in the name, should be ComputingManager.
thank you, corrected!
ToStorageService: again I'd call the IDForEndpoint attribute something different, maybe LocationID?
Ok Cheers, 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
Alessandro Paolini <alessandro.paolini@egi.eu> said:
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?
in general we use these attributes for getting information about the hardware features of the cloud framework, independently from the Share
But who is "we", i.e. what is the use case? If you have a real use for the attributes it's fine, I was just wondering if you'd added things without a concrete idea of what you'd do with them.
NetworkPortsIn/Out, do you really want an explicit list of every port rather than allowing a range?
yes, the applications require specific ports, and we need to take into account the network configuration in the several sites that is quite diverse
OK, but if you have a lot of ports it would be a lot of data to publish. If you changed the type to string you'd get a bit less type checking, but you'd have the flexibility to publish ranges and still be able to have single numbers.
Side question: the same names (IDFromEndpoint and LocalIDFromManager) are used in the ComputingActivity class. Do we change them as well? CEJobID and LocalJobID?
OK, I missed that. We shouldn't change things in an existing class, and it may be that it would be better to keep the same names for the cloud class - something to discuss. Stephen
Hi Stephen, For the In/Out ports we could use the NetworkConfigurationPort_t t6ype instead of UInt32, it would allow '80', '80,443' and '2000:25000'. Would it be OK? For the IntanceMax/Min attributes: it's useful for us to be able to know the capacity and the specificities of the infrastructure. Cheers, Baptiste On Tue, 5 Jun 2018 at 11:39 Stephen Burke - UKRI STFC < stephen.burke@stfc.ac.uk> wrote:
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
Alessandro Paolini <alessandro.paolini@egi.eu> said: things?
in general we use these attributes for getting information about the
hardware features of the cloud framework, independently from the Share
But who is "we", i.e. what is the use case? If you have a real use for the attributes it's fine, I was just wondering if you'd added things without a concrete idea of what you'd do with them.
NetworkPortsIn/Out, do you really want an explicit list of every port rather than allowing a range?
yes, the applications require specific ports, and we need to take into account the network configuration in the several sites that is quite diverse
OK, but if you have a lot of ports it would be a lot of data to publish. If you changed the type to string you'd get a bit less type checking, but you'd have the flexibility to publish ranges and still be able to have single numbers.
Side question: the same names (IDFromEndpoint and LocalIDFromManager) are used in the ComputingActivity class. Do we change them as well? CEJobID and LocalJobID?
OK, I missed that. We shouldn't change things in an existing class, and it may be that it would be better to keep the same names for the cloud class - something to discuss.
Stephen
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Baptiste Grenier EGI Foundation - Operations Officer Phone: +31 627 860 852 Skype: baptiste.grenier.egi
Baptiste Grenier <baptiste.grenier@egi.eu> said:
For the In/Out ports we could use the NetworkConfigurationPort_t t6ype instead of UInt32, it would allow '80', '80,443' and '2000:25000'. Would it be OK? It seems better, it would be a big reduction in size for a large contiguous range and there would still be the option to publish ports individually.
Stephen
participants (3)
-
Alessandro Paolini -
Baptiste Grenier -
Stephen Burke - UKRI STFC