Hi Matt,
On Tue, 2011-07-26 at 15:09 -0400, Matt Wagner wrote:
Hi all,
As we plan the next iteration, I've been asked to organize our work
around the ability to launch an image without having to manually craft
an XML file and host it on a webserver. Instead, Conductor users should
be able to use a tool in Conductor to browse images stored in Image
Warehouse, click one of them, select a hardware profile and maybe a
pool, and launch it.
w00t! :)
What would the script for a screencast demo look like? e.g.
- Import an AMI by copy and pasting an AMI ID into an "Import Image"
form
- You're forwarded to the images list, with your imported image
highlighted
- Click on the "Launch" button beside the image
- You're forwarded to a page describing the instance. Wait for it to
boot up
- Log into the image, fool around
- Shut it down again from instance's page
Thinking about this script is a good first start to getting the UX
design right. With this script, the user is focused on "Launching an
Image" so they're launching the instance from the images list. This
shows that maybe a "New Instance" form perhaps isn't the right way to
add the feature.
There's a semi-related feature to be able to import images.
I've
proposed treating it as a separate feature so as to not confuse the
discussion, but it's also in scope for this next iteration so I'll
mention it here.
I'm not so sure because:
1) This standalone instances feature is what's motivating the adding
of the import image feature. From a user perspective, I'm not sure
how interesting import image is on its own
2) If we go with the design above where users launch instances from
the images list, a big part of what this feature needs will be the
images list and the ability to import images
3) If import image was a standalone feature, I think we'd be tempted
to overdo it - we might make it possible to import multiple
provider images as an "Image" or "Image Family" and we might
design we need to support the notion of image versions. None of
that is really important right, and that's more obvious if you
consider import image in the context of standalone instances
My plan, if I haven't misunderstood the request, is to start a
discussion here, and then create a wiki page once the discussion
stabilizes a bit.
Cool.
The work required is something like this:
* Figure out how this should interface with the UI. I think the actual
"launch an instance" form can be very simple, but it's not abundantly
clear to me where we should place the listing of images in Warehouse.
We should solve this before we dive in on implementation.
Absolutely. You should take a first cut at thinking about the use cases
and sketching the interface out yourself.
* Interface with Image Warehouse. We're already doing this to
some
extent, but two major areas came up on the call today. The first is
that a lot of what we're doing is already supported in the
aeolus-image command-line tool. To avoid code duplication and
reinventing the wheel, we'd like to break out a common library we can
both use. (This also applies to image importation.) Obviously, we'll
want to work with the Infrastructure team around aeolus-image. Second,
we endeavor to switch from our custom-written WarehouseModel code
using rest-client and nokogiri to ActiveResource.
* Actually implement it once we know where it goes, how it should look,
and have a better layer to connect to Warehouse. We'll collect the
user data, probably within the context of a pool, create a deployable
behind the scenes with this image in it, and then launch it like it's
a normal deployable.
Hmm, I don't think we should treat standalone instances as deployments.
The deployments interface is specifically suited to multiple instances.
I think it would be more than a bit weird if "Launch Image" sent you to
the deployments UI. An architecturally, I see deployments as being
layered on top of the standalone instances.
This task should convey the following advantages:
* The workflow will be simplified for users who do not need multi-image
deployable. They will not need to create an XML file, and will not be
required to have a webserver running to host the deployable XML. I
know from experience that the whole notion of pasting UUIDs into XML
files and pushing them to webservers was not entirely popular among
potential users.
Absolutely. Deployables are supposed to be reusable descriptions that
someone has taken care to author and test. It's definitely not the best
way to quickly launch one-off instances.
* It will provide an interface for browsing Image Warehouse. Right
now
(as far as I'm aware), you're resigned to either getting XML back from
Warehouse, or using the command-line tools if you want to know what
images are stored in Conductor. Both are perfectly valid, but we'll
implicitly provide a GUI.
I'd be a little wary of implementing an "Image Warehouse Browser" e.g.
showing images, builds, target images and provider images. This thing
doesn't need to be generic, it just needs to offer the list of images
that the user can launch.
* Ideally, we will incidentally improve the responsiveness of our
interface to Warehouse as we switch to ActiveResource, though this
remains to be seen.
* Although it's not an intentional goal, this may make it easier down
the road if we ever decide that we want to provide a GUI for creating
deployables.
Also:
* Support for standalone instances is needed for Conductor to
implement deltacloud API
Nice one Matt, well done
Cheers,
Mark.