BZ 761279/766137 - Handling of imported images

Tomas Sedovic tsedovic at redhat.com
Wed Dec 14 15:33:08 UTC 2011


On 12/14/2011 04:08 PM, Scott Seago wrote:
> On 12/14/2011 07:48 AM, Tomas Sedovic wrote:
>> On 12/13/2011 08:08 PM, Matt Wagner wrote:
>>> Hi all,
>>>
>>> I had previously sent out a similar patchset[1], but it hasn't been
>>> reviewed and this one builds on it, so I'm resending the whole thing.
>>>
>>> This patch won't be terribly effective unless you test it with a build
>>> of Image Factory that uses sloranz's bug/no-template-on-import branch,
>>> which is currently an open pull request[2].
>>>
>>> This implements a few changes:
>>>
>>> 1.) When images are imported, Factory will no longer create a
>>> (pointless, empty) Template object in iwhd for them. This allows us to
>>> create an imported? method on Warehouse objects to detect if images are
>>> imported or not.
>>>
>>> 2.) We do not offer to upload/push or build imported images, since this
>>> is nonsensical.
>>>
>>> 3.) Imported images are now tied to a specific Provider Account, not
>>> just a Provider/Target. Existing images had to have this association,
>>> but we weren't setting it for imported images. Now we are.
>>>
>>> 4.) As a consequence of #3, the UI is changed slightly -- importing an
>>> image prompts for a provider account, not a provider. More
>>> significantly, the aeolus-cli syntax is changed here. Rather than
>>> specifying a --target and a --provider, you just specify a
>>> --provider_account. Conductor can get the rest of the information from
>>> this. For example, you would now run "aeolus-cli import
>>> --provider_account ec2-mawagner --id ami-abc123"
>>>
>>> 5.) As an incidental benefit, aeolus-cli image import and the Conductor
>>> web UI now call the exact same method to import images. Previously they
>>> were doing similar, but not identical, calls to Factory.
>>>
>>> This will resolve BZ #766137 [3] and #761279 [4].
>>>
>>> Thanks,
>>> Matt
>>>
>>> [1]
>>> https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007280.html
>>>
>>> [2] https://github.com/aeolusproject/imagefactory/pull/51
>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=766137
>>> [4] https://bugzilla.redhat.com/show_bug.cgi?id=761279
>>
>> Hey Matt,
>>
>> ACK to the series. 2 notes:
>>
>> I still saw all the providers on the imported images#show page (see my
>> reply to the corresponding patch).
>>
>> Second, if we're scoping images by the accounts now as well, we could
>> remove the "Import" button from the page that lists all the images and
>> only show it on the images lists under any single pool family.
>>
>> Then you'd get the provider account automatically so there'd be no
>> need to ask for it in the import page.
>>
>> We're doing the same thing with the "New Image" button -- it's
>> displayed only on pages that are associated with a particular pool
>> family.
>>
>> Anyway, great work! The code looks good and does what it's supposed to.
>>
>> Thomas
> You'll still need to ask for a provider account, since a pool family can
> have more than one. However, the provider account list could be filtered
> to only include those associated with the current pool family.

Good point, you're right.

>
> As for the 'new image'/Pool Family link, are we actually scoping images
> to pool families? I know we need to, but I wasn't sure we were actually
> doing that yet.

We don't but after discussing it with Hugh, we've decided to not show 
the 'new image' button on the global images list anyway.

>
> Scott
>



More information about the aeolus-devel mailing list