On Fri, 2011-07-01 at 14:35 -0400, Hugh Brock wrote:
A couple of imgfac feature requests made their way to me during the
SA
training this week that I wanted to pass along in hopes they would
make their way into a release soon-ish:
Quick reply on the bits I know enough about to comment on.
1. The image list in the CLI returns a not-very-human-readable list
of
UUIDs, and nothing else. I'm told that part of the reason for this is
that there *is* no other data to return about images, at least not
easily. So I would like to propose that we
a. Add the ability for the image owner to set Name and
Description metadata tags on images via the factory
or, b. Add the ability for the image owner to set arbitrary
tags on images via the factory
c. Have the factory return Name and Description metadata tags
in addition to image UUIDs
or, d. Have the factory return arbitrary tag values specified
in the --list call
Martyn and I talked to Scott about this last week - there is a wealth of
information that _could_ be returned with the image, the question is,
what do we _want_ to return. As you say, name and/or description would
be a great place to start, though I think we need to get feedback if
there are other things people want/need in this list. Scott suggested
just pulling back the name/description from the template, since that has
both in a defined format already. This make sense to me, and I think
Martyn is going to try to knock this together. The big question mark is
whether all the required relationships exist after the build stage to
return the template, or if some are created after push. If the latter,
then we will not be able to show the detail on the image for those that
have not been pushed yet (my memory is that we _can_ get to this
however, just not very cleanly via iwhd - IOW, there may be several http
calls to get this info for each image returned, which could be a
problem).
We could certainly do the other routes you suggest, but as build/push
happen in factory proper talking to iwhd, they would need to be added
there (and, imo, might make the cli interface even more complex than it
is now). I am also a little concerned about duplicating metadat we
already have in templates. Another related issue is that even with
useful info, I think the list command needs to have some interaction
thought - what happens, for instance, when I have more than, oh 20,
images? I get a huge unreadable list back. Maybe pagination in a cli
tool is silly, but I think we should consider it, or whether the list
command is really even the direction that makes the most sense here.
e. And, finally, since images are in the warehouse in a tree
structure, we should provide an option to return the image
list formatted like a PS tree, so that users can easily see
the image hierarchy
We talked about this also, and I think this could be done next iteration
if desired. Martyn and I were thinking perhaps this makes more sense in
a 'show' type of command, as there is substantially more detail returned
per object, and will even more quickly run into the 'too many results'
issue I mentioned above.
-j
2. The image factory depends on a config file that describes the
providers it can connect to and includes parameters for connecting to
them. Unfortunately when used in conjunction with Conductor this
implies that provider config has to be set in three places (Conductor,
DC Core, Factory). It would be great if Factory would provide an API
that lets Conductor pass parameters that override whatever is in its
config file so that an admin only has to set them on Conductor.
3. Right now when users build images and push them to rhev-m or
vmware, the only identification of the image in rhev-m or vmware is
the image UUID. Image factory should provide a way to push the image
name (see 1a. above) to rhev-m or vmware so that a human being has
some idea what was actually pushed.
If you guys could let me know if these features are implementable in
the relatively near future, I would appreciate it. Alternative
suggestions welcome.
Thanks,
--Hugh