[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.
[...]
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?
= 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. And maybe in some cases
from kalpana too?
From: Carl Trieloff <cctrieloff(a)redhat.com>
Date: Thu, 26 May 2011 15:59:01 -0400
[...]
> - Support launching deployables in conductor simply by allowing the
> user to supply a URL to a deployable description, or choosing a
> URL from a list populated by an admin.
>
> - Include a set of command line tools for building images from a
> template description. This tools will also allow deployable
> authors to list available images available to be referenced in
> their deployables.
I would have said.
"This tools will also allow deployable
authors to list available images and assemblies available to be referenced in
their deployables. Templates referenced by the deployable are automatically
wrapped by an assembly."
Sure. Though if you're going to auto-generate things like assemblies
from that context, you need to be clear about where they go.
I'd be happy to have the answer be that they get dropped in iwhd, but
since we're proposing to not a-priori store stuff there, the policy
needs to be articulated.
[...]
>
> 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].
What are the assumptions around push... we need to support the case
where the images are cached at the resource provider and the case that
we only move the image to the provider when it is going to be
instantiated and then removed once we destroy it. The mail later seems
to imply that the push is a user action, where in reality it needs to be
policy driven.
We *do* have a relatively flexible policy engine in iwhd, which was
meant to be part of that solution. I'm pretty sure nobody's ever used
it other than for testing.
If we can convince ourselves that we don't need the smarter use case,
I think it's ok to leave it all manual. I don't know whether we can
convince ourselves of that for rev1.
If the user can push the image how does this affect the policy. I would
not allow user push for rev one, we don't export the ability for the
user to push the images, which means we don't have to unwind a
complicated policy interaction mess later.
Then there is no mention on services in the mail.
I guess I had assumed that service descriptors were along for the ride
in all the discussion of building images and all the related horsing
around. If that's not the case, I don't think it's an image-build
issue per se, but it has consequences for the rest of the project. I
hope we're not proposing to drop them.