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
Also, the change discussed here (allow push as part of build call) goes
beyond the CLI. To build it in the CLI requires support in the conductor
API, which in turn simplifies our conductor UI plans, as the UI will
definitely push and build together in some cases.
Scott