On Tue, Jul 05, 2011 at 11:12:15AM -0400, Jason Guiditta wrote:
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
Well, OK, I have several thoughts:
* We definitely need to always be able to retrieve the template
itself, for any number of reasons. So we should sort that out.
* I don't really like the idea of having to parse each template in
order to extract whatever metadata is required, and I'm not sure it
will always be the same information anyway. So I think I'd prefer
just allowing the image creator to set a "name" tag on the top-level
image object when creating it, that can easily be returned. For that
matter it seems to me that different customers may have different
metadata they want to store per image, and that therefore allowing
image creators to set arbitrary tags on creation and then have them
returned as part of the list would be a good thing.
We could certainly do the other routes you suggest, but as
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.
aeolus-image list | more? Or, sure, add a pagination flag if you want.
> 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.
Sure, I like that idea. Thanks!
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"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."