BZ 761279/766137 - Handling of imported images

Scott Seago sseago at redhat.com
Wed Dec 14 15:35:47 UTC 2011


On 12/14/2011 10:33 AM, Tomas Sedovic wrote:
> 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.
>
Should we just remove the global image list and only show the image list 
under the pool family? That way the image list will always have the 'new 
image' action. For now, both the image list and the new action will be 
global (even though it's displayed under pool family), and then when we 
start scoping images, the images and the 'new image' action won't need 
UI changes.

Scott




More information about the aeolus-devel mailing list