On Tue, Aug 09, 2011 at 01:06:15PM -0500, Ian McLeod wrote:
Hugh,
I was recently forwarded a series of user stores with your name attached
to them. I've had a look, had some discussions and distilled out a few
points of clarification that I think need to come from within your team.
Can you either dole these out to the right people or suggest where I
might broadcast this request more widely?
The questions are:
* Cloud-type specific support packages - We expect we'll have to install
support packages such as VMWare tools on a per-cloud-type basis. Our
initial thought is to simply add a configuration option that says "when
building the following TDL for the following target, add the following
packages and repos". Our main concern here is that targe-type may not
be granular enough. That is, ESX 3.0 may need a different tools package
from ESX 4.0, even though the same generic non-tools-enabled image can
be booted on both and built using a target type of "vsphere". Who can
help clarify exactly what packages are needed here and whether the
proposed approach is workable, even in the short term?
(adding aeolus-devel for public comment)
Good question.
I'll throw this to the field for further clarification, but it strikes
me that the specification of optional packages to be added at push
*might* best be done as part of the data associated with the cloud
provider account. Seems to me each provider account will have to point
to a specific, known instance of a cloud provider, and that an admin
could then be comfortable specifying precisely what packages this
particular provider requires.
* Image permissions - The Factory never actually knows which user an
image is being built for. Long ago we suggested that layering
permission information on top of a completed Image object would be done
by the Conductor. Can we agree this is still the case?
I can't think of any other way to handle it. I'm not completely clear
on the mechanism Conductor should use to add permission metadata (for
example) to a Warehouse object -- do we write it via arguments to
Factory, or directly to the Warehouse?
* Retrieving IP address and SSH private key - Which SSH private key?
In
the EC2 case, you can only retrieve an SSH private key once, at the time
it is created in the EC2 infra. After that EC2 "forgets" it and only
exposes the public component via the REST-ish interface used to grab the
key for injection at boot time. This isn't strictly a Factory concern
but I thought I'd bring it up for clarification.
I should defer here to Jan Provaznik, who mostly owns ssh key
retrieval. It may not, in fact, be a requirement that we retrieve an
ssh key from the instance, given a working config server that could
inject a user's public key into the instance post-boot. I'd like more
use case input from the list here.
* Obvious names for the VMs/templates created in VMWare and RHEV-M -
We
are happy to use any sensible naming convention put forward to us. At
the moment, we do something along the lines of "factory-image-<uuid>" to
ensure uniqueness.
I don't think anyone on our side particularly cares how we form the
name. Since we want to guarantee uniqueness (right?), we should
probably go with "your-pretty-name-here-<uuid>" if that works.
* Improved status reporting - At the moment we report a short status
string like "BUILDING", "UPLOADING", "FAILED" or
"COMPLETED" and attempt
to update a semi-meaningful "percent complete" value. Both of these are
shared as QMF properties on the Image object representing the build or
push request. We've talked about adding properties to provider more
human-friendly detail. Some initial thoughts were to add a QMF long
string (up to 64k) that contains an abbreviated log of the build process
and/or a string meant to contain a single line sentence-fragment style
status that could be passed through directly to the UI. Any other
thoughts or clarifications?
I think both those items would be outstanding. Can anyone think of
anything else they'd like to have back in terms of build status?
Thanks much,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey