On Thu, Oct 27, 2011 at 09:03:11AM -0400, Greg Blomquist wrote:
> On 10/26/2011 01:23 PM, Chris Alfonso wrote:
>> On 26/10/11 12:08 -0400, Jason Guiditta wrote:
>>> On 26/10/11 11:16 -0400, Hugh Brock wrote:
>>>> On Wed, Oct 26, 2011 at 10:50:32AM -0400, Matt Wagner wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm not the author of this change, and honestly don't even
know the
>>>>> whole story behind why it changed. But since this is causing a lot
of
>>>>> confusion:
>>>>>
>>>>> The syntax to push an image with aeolus-image has changed. Here is
>>>>> the new syntax:
>>>>>
>>>>> $ aeolus-image push --provider ec2-us-east-1 --account matt_ec2 \
>>>>> --image 6ae8421f-9ab2-4925-8f8d-ab165862b137 \
>>>>> --build bf2c3ef3-2d67-455c-9c19-0d9a6bb9bdbb \
>>>>> --targetimage 193564a1-dd0d-4543-b182-d78d482010de
>>>>>
>>>>> I have documented this on the
>>>>>
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Launching_Inst...
>>>>> page as well.
>>>>
>>>> Interesting. It seems like we could/should infer the image and the
>>>> build from the target image? Can someone explain?
>>>>
>>>> --Hugh
>>>>
>>>
>>> +1, this seems more verbose than it should need to be.
>>>
>>> -j
>>> _______________________________________________
>>> aeolus-devel mailing list
>>> aeolus-devel(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/aeolus-devel
>>
>> It might even be nice to combine push functionality in with build. I know the
idea is build once and push to many providers, but if you already know you're going to
push, it would be nice to do the following:
>>
>> aeolus-image build --push --target target --account<acount>
--provider<provider> --template<template>
>
> This looks eerily similar to what Dan Radez proposed a few weeks ago
> (not on the list, unfortunately) to morazi.
>
> We all thought it was a great idea, but it was basically shot down due
> to the new Conductor image build/push UI. Has that thinking changed
> since Dan brought this up?
>
> I guess the underlying question is whether the aeolus-image tool going
> to be a long term solution, or something that eventually goes away.
Hmm...
* I expect aeolus-image to be around for the long term -- I think CLI
users are going to be a major part of our base
* I don't really know why improving the CLI would create any conflict
with the build/push UI
Anyone else have an answer there?
--Hugh
My apologies if I caused some confusion here.
I wasn't attempting to shoot down the idea as much as suggest similar
behavior between the UI and cli is probably desirable and it might make
as much sense to see the UX thinking around this area is first.
I have some concerns about the fact that some of the build/push can be
quite long and which steps are long is entirely dependent on whether we
are doing snapshot builds vs local build & push.
The other big question I have is how we handle multi provider
build/pushes in terms of picking out the correct built image
uuid/provider mapping when we chain build/push calls.
I think each of the issues is solvable, but it isn't as simple as it
initially seems.
Thanks,
Mike