BZ #761160 - Don't offer to build/push imported images

Matt Wagner matt.wagner at redhat.com
Fri Dec 9 21:29:23 UTC 2011


Hi all,

I'm sending two rounds of patches, one for aeolus-image-rubygem and one
for Conductor. They address an issue raised in
https://bugzilla.redhat.com/show_bug.cgi?id=761160 -- specifically, we
prompt users to build and push imported images, when this is, by
definition, not possible. (An imported image is just a pointer to an
image that already exists in a cloud.)

The problem is that we really had no means of knowing if an image is
imported or not. With these patches, we will detect whether an Image has
a template, and if does not, we will consider it imported.
(img.imported? == true). In that case, we hide the irrelevant controls.

This depends on a patch sloranz has to prevent Image Factory from
writing an empty template on import; it's an open pull request[1] but
you can pull the branch and test against it.

This patch should get us something useful, and should probably be
reviewed and committed by itself. But before I consider #761160
satisfactorily resolved, I'd like to fix a few more things:

* The image detail page shouldn't show providers for which the imported
 image is not built or pushed. Since you cannot built for or push to
 them, showing them serves no purpose and rather confusing. (None of
 this applies to the non-imported use case, of course.) This seems to
 be slightly more involved than I expected so I'm not doing it just
 yet. This makes me wonder if we should just show a totally different
 page in this case.

* The API image import code is similar-but-different. When I wrote my
 web import script the two methods were just too different for it to
 make sense to combine, but I'd like to go back and make them both
 share the Image.import method. Mostly because:

* To unambiguously find a provider image, we really want to know the
 provider _account_. This wasn't being set on image import. After
 talking a bit with the Image Factory folks, we decided that it really
 didn't make sense to pass this parameter to Factory to have it set it
 in Warehouse, when Factory didn't care about this information in the
 slightest. Ergo I set the attribute directly if we have it. But
 currently, we don't even prompt for it in the web UI or on the command
 line. I think we might want to, but I'd like to bounce this idea off
 of someone -- does it make sense that ProviderImages should be tied to
 a specific provider account as opposed to a provider?

As a tangent, I put together a little documentation about the Image
'family' of models as are stored in iwhd, since some of it was unclear
to me previously. It's based on what I discovered as I went, not
something written by an architect of the original idea, so it's not
necessarily 100% complete.

Whew, sorry for the long email.

-- Matt

[1] https://github.com/aeolusproject/imagefactory/pull/51
[2]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Image_Models



More information about the aeolus-devel mailing list