On 03/12/2012, at 3:02 PM, Tomas Sedovic wrote:

On 12/03/2012 01:26 PM, Justin Clift wrote:

...

Hi all,

We have slowly-developing upstream repo of image templates for the existing Aeolus:

https://github.com/aeolus-incubator/templates

When we do the next major Aeolus release, it would be useful to include them "already bundled" in some useful way.

Very much so. Heat has been doing this from the start and it's been very helpful to newcomers (users, developers and potential users evaluating the tool).

I would actually go a step further and offer not only templates but deployables as well. I know we can make a trivial deployable from a given template so this would be for showing off more complex stuff: multi-instance deployments, launch-time parameters and provisioning, etc.

We can put them in the Default (or Sample) catalog and have Conductor immediately useful.

Bundling sample deployables will be more difficult because they need to contain specific image IDs in order to be launchable, but I still think it's a good idea to do.

Yeah, the "need a specific image ID in deployables" is a sticking point that I'm not yet sure how to work around either.

...

To make it practical though, a few things would need to happen:

• Update them to use CentOS 6.x

  The templates are using various versions of Fedora at the moment, some F16, some F17, etc.

  CentOS 6.x is one of the primary "supported" platforms for next upstream release, whereas F16 will be completely EOL soon. So we're probably best to update the templates for CentOS 6. Won't have to update them every 6 months after that. ;)

I agree. We should provide some Ubuntu images as well. It will serve two purposes:

1. we show that we do in fact support Ubuntu guests as a first-class OS

2, a significant portion of the upstream developers use and are familiar with Ubuntu

If we offer their LTS releases, we would only have to update the templates every two year.

Good idea. :)

...

• Figure out how to bundle them in said "useful way"

  • Should they be pulled down by dev-tools, and placed on the filesystem at suitable location?

  • Should they be pre-populated in Conductor?

If we don't do this, the benefit will be very limited. If you have to add the templates to Conductor manually, you gain little over getting them from GitHub -- especially since you can already add the templates via URL.

I suppose the "optimal" way to do this, would be have dev-tools add the images/deployables using the up-and-coming Conductor API. I'm unsure if that will have the needed functionality in time though.

If it doesn't, we might have to somehow inject them directly into the database. Sounds a bit more prone to breakage though.

+ Justin

-- Aeolus Cloud Evangelist http://www.aeolusproject.org

Making examples part of the release is surely a good idea. But in my point of view we should make sure that we provide only working examples. I think that broken examples are worse then no examples in this case.

So I would see as a prerequisite having automated testing of these examples a part of the (at least) release or even development process.

Which brings me to the question whether we have support for putting templates into conductor in the CLI. The answer is not yet.

Then do we have the API to do it. Again the answer is no. So I would say that we have to implement the API and the CLI and then provide the examples with the release.