BZ 761279/766137 - Handling of imported images

Tomas Sedovic tsedovic at redhat.com
Wed Dec 14 16:10:41 UTC 2011


On 12/14/2011 04:35 PM, Scott Seago wrote:
> 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.
>

Yeah, that sounds like a reasonable thing to do.

> Scott
>



More information about the aeolus-devel mailing list