On Thu, 2011-05-26 at 17:12 -0400, John R. Dunning wrote:
[Sorry about the late reply here, I've been a bit slammed by too
many
distractions. In know, join the club :-( ]
> From: Mark McLoughlin <markmc(a)redhat.com>
> Date: Tue, 24 May 2011 15:52:38 +0100
>
[...]
>
> - Have well documented deployable and template description formats
> with plenty of examples. Deployable authors will create these
> descriptions manually or with the help of simple command line
> tools and store them as they fit (e.g. in their own git repo)
We're missing assemblies here. Oversight?
Per previous discussion, I'm ok with, for rev 1, having an easy way to
make skeletal assemblies. I don't think we should be skipping them.
We're considering assemblies to just be part of the deployable format
for now. We can allow them to be externally referenced in future so that
they can be re-used by multiple deployments.
[...]
>
> In order to allow the CLI to fire-and-forget, we will need to add new
> build and push APIs which can handle multiple images at once.
>
> These would look like:
>
> - image(image_id, template, targets[])
> + builds an image for the supplied targets
> + image_id should be ommitted, if a new image is required
> + template and targets may be ommitted if a previous build
> exists and the previous template and targets will be used
>
> - push(image_id, providers, credentials)
> + push the image the supplied providers
> + assumes factory can figure out which target image is
> appropriate for each provider
> + credentials argument is a <provider_credentials/> document
>
> Also, we'll need to rename image factory's current concept of an image
> as a target image. Some initial work on that here[3].
>
> = Conductor APIs =
>
> Conductor needs APIs to support the following:
>
> 1) List the available provider types in an XML doc
> 2) List the available providers in an XML doc
> 3) Dump a <provider_credentials/> document encapsulating all of the
> available provider accounts
>
> The latter API would be subject to authentication and access control.
I believe all those above apis need to be subject to some level of
auth and access control, correct?
We had some debate about this and I think Scott/Jay said the same thing.
It's not clear to me that e.g. the list of provider types supported by
Conductor is something that needs access control, but it's not a big
deal.
> = Conductor IWHD Queries =
>
> Conductor has basically two use cases for querying IWHD:
>
> 1) As a user, I want to launch a deployable:
>
> 2) As a user, I want to launch an instance of an image
>
> For (1), conductor needs to resolve each deployable image reference to
> a set of provider images. This can be done with something like:
>
> $> $build_id = curl
http://iwhd/$image_id/latest_build
> $> curl -d '$build=="'$build_id'"'
http://iwhd/target_images/_query
> $> foreach $target_image_id; do curl -d
'$target_image=="'$target_image_id'"'
http://iwhd/provider_images; done
>
> For (2), conductor needs to list all images available for launching a
> standalone instance and, when the user launches the image, it needs to
> list the parameters for the image. Both are easily achieved by
> querying the images bucket.
>
> = Image Building CLI =
>
> The image building CLI is used by Aeolus users to build and upload
> images from templates. It is also used by deployable authors to list
> the available images.
>
> The use cases are:
>
> 1) As an image builder or deployable author, I want to list all
> images
> 2) As an image builder or deployable author, I want to list all
> builds of an image
> 3) As an image builder or deployable author, I want to list all the
> targets and providers an image has been built for
> 4) As an image builder, I want to build an image
> 5) As an image builder, I want to push an image to a provider
> 6) As an image builder, I want to import an image
> 7) As an image builder, I want to delete an image
> 8) As an image builder, I want to delete old versions of an image
> 9) As an image builder, I want to delete a provider image
> 10) As an image builder, I want to delete an image
>
> The tool needs to interact with IWHD for listing, image factory for
> building and conductor for provider/account details.
>
> It might look like:
>
> $> aeolus-image images # list
available images
> $> aeolus-image builds $image_id # list the
builds of an image
> $> aeolus-image target-images $build_id # list the
target images from a build
> $> aeolus-image provider-images $target_image_id # list the
provider images from a target image
> $> aeolus-image build --target ec2 --template my.tmpl # build a new
image for ec2 from the template
> $> aeolus-image build --image $image_id # rebuild the
image template and targets from latest build
> $> aeolus-image build --target ec2 --target rackspace \ #
> --image $image_id \ # rebuild the
image with a new template and set of targets
> --template my.tmpl #
> $> aeolus-image push --provider ec2-us-east-1 $target_image_id # push the
target image to the specified provider
> $> aeolus-image push $build_id # push all
target images for a build, to same providers as previously
> $> aeolus-image push --account $provider_account $build_id # ditto,
using a specific provider account
> $> aeolus-image push $image_id # push all
the target images for the latest build
> $> aeolus-image import --provider ec2-us-east-1 $ami_id # import an
AMI from the specified provider
> $> aeolus-image delete --image $image_id # deletes all
builds, target images and provider images
> $> aeolus-image delete --build $build_id # deletes a
build, updating latest/parent references as appropriate
> $> aeolus-image delete --target-image $target_image # deletes a
target image and its provider images
> $> aeolus-image delete --provider-image $provider_image # deletes a
provider image
> $> aeolus-image targets # list the
values available for the --target parameter
> $> aeolus-image providers # list the
values available for the --provider parameter
> $> aeolus-image accounts #
> list the values available for the --account parameter
Ok, so I think I get this, but to be very clear, what you're talking
about is a tool (or set of them) which culls information both from
iwhd and from conductor's internal db, right.
Yes.
And maybe in some cases from kalpana too?
No, Aeolus doesn't have a dependency on Kalpana. We're expecting Kalpana
to consume similar IWHD and Conductor APIs to the ones the CLI uses.
Cheers,
Mark.