hi Stephen,
On 3 June 2018 at 14:56, Stephen Burke - UKRI STFC <stephen.burke(a)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!).
>
Ok
>> 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?
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
