Evolution proposal in "OCCI Platform" specification
Dear OCCI team, We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud. But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues. For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on). OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true). What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases. Attached, the new OCCI Platform spec we propose. We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs). Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification. Regards, Pierre-Yves Gibello - OCCIWare project
Dear Pierre-Yves Gibello, AFAIK, this looks like a reasonable addition. I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams. Regards, Boris Parak -- CESNET On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose.
We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course). The target state for "configure" was "inactive", there is no "configured" state in the figure. Thanks for reading so carefully, the mistake came through our peer review without being noticed ! Regards, Pierre-Yves Gibello - OCCIWare team P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any. Le 25/03/2017 à 14:44, Boris Parak a écrit :
Dear Pierre-Yves Gibello,
AFAIK, this looks like a reasonable addition.
I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams.
Regards, Boris Parak -- CESNET
On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose.
We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi, Thanks for the contribution - looks good. Can you maybe write a little Errata text and include that in the doc as well? Cheers, -Thijs -----Original Message----- From: occi-wg [mailto:occi-wg-bounces@ogf.org] On Behalf Of Pierre-Yves Gibello Sent: Monday, March 27, 2017 10:58 AM To: Boris Parak <xparak@mail.muni.cz>; occi-wg@ogf.org Cc: occiware@ow2.org Subject: Re: [occi-wg] Evolution proposal in "OCCI Platform" specification Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course). The target state for "configure" was "inactive", there is no "configured" state in the figure. Thanks for reading so carefully, the mistake came through our peer review without being noticed ! Regards, Pierre-Yves Gibello - OCCIWare team P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any. Le 25/03/2017 à 14:44, Boris Parak a écrit :
Dear Pierre-Yves Gibello,
AFAIK, this looks like a reasonable addition.
I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams.
Regards, Boris Parak -- CESNET
On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose.
We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Hi, What do you mean by "errata" ? There is no mistake in any released doc, my document is an evolution proposal. Regards, Pierre-Yves Gibello - OCCIWare project Le 31/03/2017 à 17:10, Metsch, Thijs a écrit :
Hi,
Thanks for the contribution - looks good. Can you maybe write a little Errata text and include that in the doc as well?
Cheers,
-Thijs
-----Original Message----- From: occi-wg [mailto:occi-wg-bounces@ogf.org] On Behalf Of Pierre-Yves Gibello Sent: Monday, March 27, 2017 10:58 AM To: Boris Parak <xparak@mail.muni.cz>; occi-wg@ogf.org Cc: occiware@ow2.org Subject: Re: [occi-wg] Evolution proposal in "OCCI Platform" specification
Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course).
The target state for "configure" was "inactive", there is no "configured" state in the figure.
Thanks for reading so carefully, the mistake came through our peer review without being noticed !
Regards, Pierre-Yves Gibello - OCCIWare team
P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any.
Le 25/03/2017 à 14:44, Boris Parak a écrit :
Dear Pierre-Yves Gibello,
AFAIK, this looks like a reasonable addition.
I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams.
Regards, Boris Parak -- CESNET
On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose.
We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Hi Pierre-Yves, Add an appendix section named "Change Log" at the end of the OCCI Plaform document. You could take inspiration from the "Change Log" section at the end of the OCCI Core document. A+ Philippe Le 04/04/2017 à 10:26, Pierre-Yves Gibello a écrit :
Hi,
What do you mean by "errata" ? There is no mistake in any released doc, my document is an evolution proposal.
Regards, Pierre-Yves Gibello - OCCIWare project
Le 31/03/2017 à 17:10, Metsch, Thijs a écrit :
Hi,
Thanks for the contribution - looks good. Can you maybe write a little Errata text and include that in the doc as well?
Cheers,
-Thijs
-----Original Message----- From: occi-wg [mailto:occi-wg-bounces@ogf.org] On Behalf Of Pierre-Yves Gibello Sent: Monday, March 27, 2017 10:58 AM To: Boris Parak <xparak@mail.muni.cz>; occi-wg@ogf.org Cc: occiware@ow2.org Subject: Re: [occi-wg] Evolution proposal in "OCCI Platform" specification
Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course).
The target state for "configure" was "inactive", there is no "configured" state in the figure.
Thanks for reading so carefully, the mistake came through our peer review without being noticed !
Regards, Pierre-Yves Gibello - OCCIWare team
P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any.
Le 25/03/2017 à 14:44, Boris Parak a écrit :
Dear Pierre-Yves Gibello,
AFAIK, this looks like a reasonable addition.
I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams.
Regards, Boris Parak -- CESNET
On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose.
We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Philippe Merle Inria researcher http://chercheurs.lille.inria.fr/~pmerle/
Hi, This is done now, along with minor updates/fixes, all listed in change log (the most prominent one being the addition of a "context" attribute to the Component kind). Attached the PDF version (the git repo is up to date - https://github.com/gibello/occi-wg ). Regards, Pierre-Yves Gibello - OCCIWare project Le 04/04/2017 à 12:27, Philippe Merle a écrit :
Hi Pierre-Yves,
Add an appendix section named "Change Log" at the end of the OCCI Plaform document.
You could take inspiration from the "Change Log" section at the end of the OCCI Core document.
A+ Philippe
Le 04/04/2017 à 10:26, Pierre-Yves Gibello a écrit :
Hi,
What do you mean by "errata" ? There is no mistake in any released doc, my document is an evolution proposal.
Regards, Pierre-Yves Gibello - OCCIWare project
Le 31/03/2017 à 17:10, Metsch, Thijs a écrit :
Hi,
Thanks for the contribution - looks good. Can you maybe write a little Errata text and include that in the doc as well?
Cheers,
-Thijs
-----Original Message----- From: occi-wg [mailto:occi-wg-bounces@ogf.org] On Behalf Of Pierre-Yves Gibello Sent: Monday, March 27, 2017 10:58 AM To: Boris Parak <xparak@mail.muni.cz>; occi-wg@ogf.org Cc: occiware@ow2.org Subject: Re: [occi-wg] Evolution proposal in "OCCI Platform" specification
Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course).
The target state for "configure" was "inactive", there is no "configured" state in the figure.
Thanks for reading so carefully, the mistake came through our peer review without being noticed !
Regards, Pierre-Yves Gibello - OCCIWare team
P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any.
Le 25/03/2017 à 14:44, Boris Parak a écrit :
Dear Pierre-Yves Gibello,
AFAIK, this looks like a reasonable addition.
I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams.
Regards, Boris Parak -- CESNET
On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com> wrote:
Dear OCCI team,
We at OCCIWare project (www.occiware.org) are using OCCI Platform to model and deploy/configure software applications in the cloud.
But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues.
For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on).
OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true).
What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases.
Attached, the new OCCI Platform spec we propose. \end{itemize} We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs).
Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification.
Regards, Pierre-Yves Gibello - OCCIWare project
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Good to see this caught. When you have a set of changes that you would like to push out to the already-published documents, see also the errata process, section 8 of GFD.152: https://www.ogf.org/documents/gfd.152.pdf Alan On Apr 7, 2017, at 7:23 AM, Pierre-Yves Gibello <pygibello@linagora.com<mailto:pygibello@linagora.com>> wrote: Hi, This is done now, along with minor updates/fixes, all listed in change log (the most prominent one being the addition of a "context" attribute to the Component kind). Attached the PDF version (the git repo is up to date - https://github.com/gibello/occi-wg ). Regards, Pierre-Yves Gibello - OCCIWare project Le 04/04/2017 à 12:27, Philippe Merle a écrit : Hi Pierre-Yves, Add an appendix section named "Change Log" at the end of the OCCI Plaform document. You could take inspiration from the "Change Log" section at the end of the OCCI Core document. A+ Philippe Le 04/04/2017 à 10:26, Pierre-Yves Gibello a écrit : Hi, What do you mean by "errata" ? There is no mistake in any released doc, my document is an evolution proposal. Regards, Pierre-Yves Gibello - OCCIWare project Le 31/03/2017 à 17:10, Metsch, Thijs a écrit : Hi, Thanks for the contribution - looks good. Can you maybe write a little Errata text and include that in the doc as well? Cheers, -Thijs -----Original Message----- From: occi-wg [mailto:occi-wg-bounces@ogf.org] On Behalf Of Pierre-Yves Gibello Sent: Monday, March 27, 2017 10:58 AM To: Boris Parak <xparak@mail.muni.cz<mailto:xparak@mail.muni.cz>>; occi-wg@ogf.org<mailto:occi-wg@ogf.org> Cc: occiware@ow2.org<mailto:occiware@ow2.org> Subject: Re: [occi-wg] Evolution proposal in "OCCI Platform" specification Thanks a lot... it was a mistake ! Fixed now, in the attached version (and in the git repo, of course). The target state for "configure" was "inactive", there is no "configured" state in the figure. Thanks for reading so carefully, the mistake came through our peer review without being noticed ! Regards, Pierre-Yves Gibello - OCCIWare team P.S. Please let us know of the process & schedule to integrate this in the next spec release, if any. Le 25/03/2017 à 14:44, Boris Parak a écrit : Dear Pierre-Yves Gibello, AFAIK, this looks like a reasonable addition. I noticed that you are using 'configured' as a target state in action tables. However, there is no such state declared in state tables or shown in state diagrams. Regards, Boris Parak -- CESNET On Fri, Mar 24, 2017 at 3:22 PM, Pierre-Yves Gibello <pygibello@linagora.com<mailto:pygibello@linagora.com>> wrote: Dear OCCI team, We at OCCIWare project (www.occiware.org<http://www.occiware.org>) are using OCCI Platform to model and deploy/configure software applications in the cloud. But we quickly came to the conclusion that the current "OCCI Platform" spec is too uncomplete, as we needed to extend it to cover some basic issues. For instance, an application component (eg. a software component, like a database or an app server) will first be installed (we call that "deployed"), then configured, prior to managing its lifecycle (start/stop and so on). OCCI Platform assumes the component is already installed and configured (it provides only "inactive" and "active" states with "start" and "shttps://github.com/gibello/occi-wgtop" actions), or that install/configure/start is a single action (which is not true). What we propose here is adding 2 states ("undeployed" and "deployed") and 3 actions ("deploy", "configure" and "undeploy") in both the component and the application states (all modifications are located in chapters 3.1 and 3.2 of the OCCI Platform spec: figures 2 and 3 + tables 3 and 5). Of course, the new states and transitions can be considered optional by implementers, which would make things as simple as before for minimal use cases. Attached, the new OCCI Platform spec we propose. \end{itemize} We cloned the OCCI specifications repository (redmine) on github, and the commits can be found here : https://github.com/gibello/occi-wg (simply "git clone" the repo, then "make" to build the specs). Let us know what you think, and if relevant, which process to update the next version of "OCCI platform" specification. Regards, Pierre-Yves Gibello - OCCIWare project _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de> Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg <platform.pdf>_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
participants (5)
-
Boris Parak -
Metsch, Thijs -
Philippe Merle -
Pierre-Yves Gibello -
Sill, Alan