While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach? Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach. I am very much looking forward to your comments. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Nice work Ralf! I like this, is KIS and covers the need for specialized/extended Link types. The only real difference with this and the previous is that the lifecycle of the link is managed by the source Resource and as such makes the association a composition. As it is a composite association there is no need to explicitly interact with the link via HTTP verbs but rather indirectly via its owning source Resource. To your question "Is it an interface or is it a representation model?" - It's both. The interface is the means by which we manipulate the model. Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, August 16, 2010 7:09 PM To: occi-wg@ogf.org Subject: [occi-wg] Another proposal on Linking While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach? Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach. I am very much looking forward to your comments. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Ok, to further confuse the situation, I decided to write down the "thin link" proposal [1] we have been discussing as one alternative during the last telco. Wearing my fire-proof pants... -Alexander [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link Am 17.08.2010 um 01:04 schrieb Edmonds, AndrewX:
Nice work Ralf! I like this, is KIS and covers the need for specialized/extended Link types. The only real difference with this and the previous is that the lifecycle of the link is managed by the source Resource and as such makes the association a composition. As it is a composite association there is no need to explicitly interact with the link via HTTP verbs but rather indirectly via its owning source Resource.
To your question "Is it an interface or is it a representation model?" - It's both. The interface is the means by which we manipulate the model.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, August 16, 2010 7:09 PM To: occi-wg@ogf.org Subject: [occi-wg] Another proposal on Linking
While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach?
Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach.
I am very much looking forward to your comments.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
Alexander, Thanks for clarifying the Thin Link proposal. I would like to let the discussion of "Link as a resource or not" rest for a while and only focus on Thin vs Fat Links for now. You state simplicity and non-extensibility as design goals of Thin Links. I understand your motivation but must object against the "no extensibility" part. I cannot see how non-extensible Thin Links could meet the real world use cases OCCI has to cope with for wider adoption. From my point of view there will always be use cases where it is necessary to express attributes of the relation between two resources, attributes which have no meaning without the relation. The alternative would be some sort of pseudo-resources existing only for the purpose of containing relation attributes but that does not seem like a clean approach to me. Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people). The disk controller attribute cannot be stored as a Compute attribute since it is irrelevant without the associated disk and a Compute resource can be Linked to many Storage resources. The disk controller attribute cannot be stored as a Storage attribute since the Storage resource can be Linked to many Compute resources. How do we solve this scenario with Thin Links? regards, Ralf On Tue, 17 Aug 2010 11:48:33 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
Ok, to further confuse the situation, I decided to write down the "thin link" proposal [1] we have been discussing as one alternative during the last telco.
Wearing my fire-proof pants...
-Alexander
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Am 17.08.2010 um 01:04 schrieb Edmonds, AndrewX:
Nice work Ralf! I like this, is KIS and covers the need for specialized/extended Link types. The only real difference with this and the previous is that the lifecycle of the link is managed by the source Resource and as such makes the association a composition. As it is a composite association there is no need to explicitly interact with the link via HTTP verbs but rather indirectly via its owning source Resource.
To your question "Is it an interface or is it a representation model?" - It's both. The interface is the means by which we manipulate the model.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, August 16, 2010 7:09 PM To: occi-wg@ogf.org Subject: [occi-wg] Another proposal on Linking
While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach?
Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach.
I am very much looking forward to your comments.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Ralf, Am 17.08.2010 um 12:57 schrieb Ralf Lyren:
Thanks for clarifying the Thin Link proposal. I would like to let the discussion of "Link as a resource or not" rest for a while and only focus on Thin vs Fat Links for now.
ok.
You state simplicity and non-extensibility as design goals of Thin Links. I understand your motivation but must object against the "no extensibility" part. I cannot see how non-extensible Thin Links could meet the real world use cases OCCI has to cope with for wider adoption.
Well, actually I was tempted to suggest what you rule out below :-) The reason for this is, rather than preaching of the "pure way of REST", that extensibility in links in OCCI core makes them conceptually resources in OCCI core. It then feels a bit awkward having the two classes separate, if a link gets its own subcategories with attributes and the like. The question is: what makes them different from Resources if we go that path.
From my point of view there will always be use cases where it is necessary to express attributes of the relation between two resources, attributes which have no meaning without the relation. The alternative would be some sort of pseudo-resources existing only for the purpose of containing relation attributes but that does not seem like a clean approach to me.
Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people).
The disk controller attribute cannot be stored as a Compute attribute since it is irrelevant without the associated disk and a Compute resource can be Linked to many Storage resources.
The disk controller attribute cannot be stored as a Storage attribute since the Storage resource can be Linked to many Compute resources.
How do we solve this scenario with Thin Links?
I would really see some kind of resource (one of those you called "pseudo-resources") here. Of course, one would have to manage many more resource objects then... We will have to decide between those paradigms: either make Links "Resources" (sort of), giving them subtypes and attributes and bells and whistles, or go for the other approach, where many more things would be modeled as (OCCI) Resources. Best, Alexander
On Tue, 17 Aug 2010 11:48:33 +0200, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
Ok, to further confuse the situation, I decided to write down the "thin link" proposal [1] we have been discussing as one alternative during the last telco.
Wearing my fire-proof pants...
-Alexander
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Am 17.08.2010 um 01:04 schrieb Edmonds, AndrewX:
Nice work Ralf! I like this, is KIS and covers the need for specialized/extended Link types. The only real difference with this and the previous is that the lifecycle of the link is managed by the source Resource and as such makes the association a composition. As it is a composite association there is no need to explicitly interact with the link via HTTP verbs but rather indirectly via its owning source Resource.
To your question "Is it an interface or is it a representation model?" - It's both. The interface is the means by which we manipulate the model.
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Monday, August 16, 2010 7:09 PM To: occi-wg@ogf.org Subject: [occi-wg] Another proposal on Linking
While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach?
Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach.
I am very much looking forward to your comments.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
The reason for this is, rather than preaching of the "pure way of REST", that extensibility in links in OCCI core makes them conceptually resources in OCCI core. It then feels a bit awkward having the two classes separate, if a link gets its own subcategories with attributes and the like.
The question is: what makes them different from Resources if we go that path.
Indeed not much. Good point. But we will get back to the Link as a Resource discussion. I am mostly convinced a Link should be a resource now but there is still a few issues I would like to have sorted out. That will be a separate thread though.
I would really see some kind of resource (one of those you called "pseudo-resources") here. Of course, one would have to manage many more resource objects then...
Could you perhaps make an example of what this would look like using my disk-controller-example for instance? I am afraid there could be several issues regarding the lifecycle of these additional resources. They have little meaning when the Link does not exist etc. Any special semantics implied when tying these resources together with Links is also somewhat unclear.
We will have to decide between those paradigms: either make Links "Resources" (sort of), giving them subtypes and attributes and bells and whistles, or go for the other approach, where many more things would be modeled as (OCCI) Resources.
Exactly. I understand the first approach but I am still not sure what the other approach would look like in a real world scenario. regards, Ralf
Am 17.08.2010 um 14:09 schrieb Ralf Lyren:
I would really see some kind of resource (one of those you called "pseudo-resources") here. Of course, one would have to manage many more resource objects then...
Could you perhaps make an example of what this would look like using my disk-controller-example for instance?
I am afraid there could be several issues regarding the lifecycle of these additional resources. They have little meaning when the Link does not exist etc. Any special semantics implied when tying these resources together with Links is also somewhat unclear.
--8<-- snip --8<-- Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people). --8<-- snap --8<-- resource::compute -> link -> resource::disk -> link -> resource::clusterfs where disk is the "logical disk" that is plugged into the compute vm, and clusterfs is your shared disk/cluster filesystem. The former then would capture the interface/address stuff, and basically is a disk representation specifically for your compute VM. From my point of view, especially for the VM use case, you have VMs and some kind of virtual storage, which is attached to it. This virtual storage may or may not be shared and, if necessary, can again rely upon other (physical or virtual) storage. There will be a layer of "virtual storage" anyway, since even if you attach physical storage directly to a VM, the representation of it within the VM is still a virtual disk. After all, if you look at your typical NetApp ecosystem, the question whether a certain entity (disk, LUN, iSCSI target, you name it) is physical or virtual pretty much depends on the perspective... Best, Alexander -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
--8<-- snip --8<-- Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people). --8<-- snap --8<--
resource::compute -> link -> resource::disk -> link -> resource::clusterfs
where disk is the "logical disk" that is plugged into the compute vm, and clusterfs is your shared disk/cluster filesystem. The former then would capture the interface/address stuff, and basically is a disk representation specifically for your compute VM.
Yep. But what about the life cycle issues? What should happen when either resource::disk or one of the links is deleted? Could a resource::disk exist on its own now, i.e. without reference to both compute and storage? How to handle the case where the IMF does not allow resource:disk to exist on its own (as stated in my example)? You could also have the scenario where two resource::compute link to the same resource::disk. This sort of defies the purpose of the resource::disk in the first place. Not to mention that you would have to issue 3 POST request for each storage you want to hook up to the compute.
From my point of view, especially for the VM use case, you have VMs and some kind of virtual storage, which is attached to it. This virtual storage may or may not be shared and, if necessary, can again rely upon other (physical or virtual) storage. There will be a layer of "virtual storage" anyway, since even if you attach physical storage directly to a VM, the representation of it within the VM is still a virtual disk.
Indeed but the virtual drive in this case should be unique to the VM. Little point in having a bunch of virtual drives with different pre-defined attachment points (SCSI/IDE/whatever) lying around. With Fat Links you can still add whatever additional virtual layer you need by creating new resources. The important part is that you do not have to model things as a resource when the life cycle properties do not match those of a full-blown resource. I do appreciate your description and explanation of the Thin Link approach though. My goal is to have as many of the pros and cons of the different approaches spelled out so we perhaps could reach a decision tomorrow ;) regards, Ralf
Am 17.08.2010 um 16:01 schrieb Ralf Nyren:
--8<-- snip --8<-- Let me take my favorite example again. We have: - A Compute resource - in this case it is a Virtual Machine - A Storage resource - in this case it is a shared disk for use with a cluster filesystem (e.g. GFS2) Now we need to attach the disk to the virtual machine and in order to do so we must specify what disk controller interface/address the disk should appear on in the virtual machine. Let's say we want it to appear as an IDE drive on bus 1, unit 0 (hdc for Linux people). --8<-- snap --8<--
resource::compute -> link -> resource::disk -> link -> resource::clusterfs
where disk is the "logical disk" that is plugged into the compute vm, and clusterfs is your shared disk/cluster filesystem. The former then would capture the interface/address stuff, and basically is a disk representation specifically for your compute VM.
Yep. But what about the life cycle issues? What should happen when either resource::disk or one of the links is deleted?
Could a resource::disk exist on its own now, i.e. without reference to both compute and storage?
Well, that pretty much depends on the semantics of the resource::disk usage which, by definition, is domain-specific.
How to handle the case where the IMF does not allow resource:disk to exist on its own (as stated in my example)?
The server would probably have to take care of removing the resource::disk.
You could also have the scenario where two resource::compute link to the same resource::disk. This sort of defies the purpose of the resource::disk in the first place.
No, actually I disagree regarding this point. On the contrary, resources can be (but not necessary are) shared by definition of the model, and so can resource::disk. Only Links are private (non-shared). Whether this makes sense from a domain-specific view is of course another story, but as said, I was focusing on keeping the model clean, and not rendering things towards being convenient for your use case ;-)
Not to mention that you would have to issue 3 POST request for each storage you want to hook up to the compute.
Actually, I haven't ever seen this use case coming up. Until now, people wanted compute resources, storage resources (e.g. CDMI), and a link between them. You are right that, if you have a complex IaaS model and map this to thin links, you end up with lots of resources. On the other hand, you could always define an OCCI action, which collates together the complete linking process (i.e. provide a single operation for setting up a more or less complex relationship of OCCI resources).
From my point of view, especially for the VM use case, you have VMs and some kind of virtual storage, which is attached to it. This virtual storage may or may not be shared and, if necessary, can again rely upon other (physical or virtual) storage. There will be a layer of "virtual storage" anyway, since even if you attach physical storage directly to a VM, the representation of it within the VM is still a virtual disk.
Indeed but the virtual drive in this case should be unique to the VM. Little point in having a bunch of virtual drives with different pre-defined attachment points (SCSI/IDE/whatever) lying around.
Agreed.
With Fat Links you can still add whatever additional virtual layer you need by creating new resources. The important part is that you do not have to model things as a resource when the life cycle properties do not match those of a full-blown resource.
Yes, but again: resources and links get somewhat blended, and the core model FUBARs. Maybe we should work out the differences of Resource and Link wrt. core, and adjust the model there so to cater your needs *and* keep it clean... Any suggestions?
I do appreciate your description and explanation of the Thin Link approach though. My goal is to have as many of the pros and cons of the different approaches spelled out so we perhaps could reach a decision tomorrow ;)
Sure. That's the entire point of the list, isn't it? Plus, I like good discussion :-) Best, Alexander -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
resource::compute -> link -> resource::disk -> link -> resource::clusterfs
Could a resource::disk exist on its own now, i.e. without reference to both compute and storage?
Well, that pretty much depends on the semantics of the resource::disk usage which, by definition, is domain-specific.
Of course but my point is that it is not possible for the IMF to enforce a policy which says "resource:disk cannot exist on its own". That is simply not possibly due to the nature of a resource. As such it is not possible to express a many-to-many relation with relation attributes, not when the entities are required. I think this is a limitation which should not be overlooked.
You could also have the scenario where two resource::compute link to the same resource::disk. This sort of defies the purpose of the resource::disk in the first place.
No, actually I disagree regarding this point. On the contrary, resources can be (but not necessary are) shared by definition of the model, and so can resource::disk. Only Links are private (non-shared). Whether this makes sense from a domain-specific view is of course another story, but as said, I was focusing on keeping the model clean, and not rendering things towards being convenient for your use case ;-)
Yes, thanks for keeping things clean. But again, what I am trying to say is that there is a certain type of use cases which cannot be expressed by the model.
Not to mention that you would have to issue 3 POST request for each storage you want to hook up to the compute.
Actually, I haven't ever seen this use case coming up. Until now, people wanted compute resources, storage resources (e.g. CDMI), and a link between them.
Well, I am sure there are enough real world use cases to justify the need for relation attributes. If you would like an example have a look at ElasticHosts [1] and see how they allow their users to assign disks and VLANs. For wide adoption of OCCI I believe well defined extensibility is very important.
You are right that, if you have a complex IaaS model and map this to thin links, you end up with lots of resources. On the other hand, you could always define an OCCI action, which collates together the complete linking process (i.e. provide a single operation for setting up a more or less complex relationship of OCCI resources).
Good point about actions although you would still need 2 GET requests to find out which Storage Resource the Compute Links to. The target attribute of the first Link will point to resource:disk...
From my point of view, especially for the VM use case, you have VMs and some kind of virtual storage, which is attached to it. This virtual storage may or may not be shared and, if necessary, can again rely upon other (physical or virtual) storage. There will be a layer of "virtual storage" anyway, since even if you attach physical storage directly to a VM, the representation of it within the VM is still a virtual disk.
Indeed but the virtual drive in this case should be unique to the VM. Little point in having a bunch of virtual drives with different pre-defined attachment points (SCSI/IDE/whatever) lying around.
Agreed.
Good, but how to accomplish this? In order to create the Links you have to create resource:disk first, and if you are allowed to do that you end up with precisely those virtual drives lying around. Ok, you might say actions here but then you all of a sudden have a resource type which is not allowed to be created, weird.
With Fat Links you can still add whatever additional virtual layer you need by creating new resources. The important part is that you do not have to model things as a resource when the life cycle properties do not match those of a full-blown resource.
Yes, but again: resources and links get somewhat blended, and the core model FUBARs. Maybe we should work out the differences of Resource and Link wrt. core, and adjust the model there so to cater your needs *and* keep it clean... Any suggestions?
Yes, I will update the Link page shortly.
I do appreciate your description and explanation of the Thin Link approach though. My goal is to have as many of the pros and cons of the different approaches spelled out so we perhaps could reach a decision tomorrow ;)
Sure. That's the entire point of the list, isn't it? Plus, I like good discussion :-)
Indeed, me too. Just trying to be polite =) regards, Ralf [1] http://www.elastichosts.com/cloud-hosting/api
participants (3)
-
Alexander Papaspyrou -
Edmonds, AndrewX -
Ralf Nyren