Concept 'target' should be exploded in two parts: 'IaaS' + 'Operating System'

[cdeneux]

Today, the Roboconf term target includes:

• the definition of the IaaS on which VM will be deployed: Amazon, OpenStack, Docker, ...
• the image to push into the VM to run it. This image includes the operating system.

Alongside:

• application components can be deployed using the plugin script. These scripts depends on the operating system previously deployed,
• we can select the IaaS that we want at deployment time. In a QA environment, we can use Docker as IaaS, and in a production environment we can prefer to use OpenStack.

IMO, a Roboconf application does not depend on a IaaS but depends on operating system. I think that in the Roboconf application graph we should mention the operating system for a generic VM instead of "target" (operating system on a specific VM). And at deployment time, for example with the admin console, we define which IaaS to use to instantiate VMs.

[vincent-zurczak]

After discussions...

• Admin in Roboconf define profiles.
• Each profile is associated with "parameters".
• Application templates reference profile names. Where and which parameters will be used by Roboconf are not known. They will be resolved later in the platform.

So, basically, we need to...

• Store target profiles.
• Upgrade the REST API to associate target properties with a profile.
• Have a default profile.
• Manage profiles through REST.
• Upgrade the web administration (e.g. target associations and profiles management).