On 10/26/2011 01:54 PM, Chris Alfonso wrote:
> On 26/10/11 13:39 -0400, Jason Guiditta wrote:
>> On 26/10/11 13:27 -0400, Hugh Brock wrote:
>>> On Wed, Oct 26, 2011 at 01:23:28PM -0400, 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>
>>>>
>>>> Thoughts?
>>> I have no idea why we would not support doing this...
>>>
>> +1, we have talked about doing this in the past. However, I think
>> there is a potential issue from an implementation standpoint, at least
>> as things worked when last I touched this code. Factory needs the
>> current data in the initial email passed to it in some way (I agree the
>> user shoudl not have to do all of it). Not all of that information
>> exists in iwhd when you issue the build request (thinking target image
>> uuid,
>> for instance). So either factory would need to queue up the steps, or
>> the cli tool would (I dont think the latter maes much sense). If we
>> wanted to go the former route, I think tere woudl need to be 2
>> (non-trivial, even controversial) changes to factory workflow:
>> 1. It would need to store placeholder objects immediately in iwhd
>> (though this coudl probably be gotten around depending on the impl of
>> 2).
>> 2. If a build and push were requested at the same time, it would need
>> to recognize that, and queue up the push to be executed once the build
>> step was done. This could also impact design of api, and what a post
>> to that api might return.
>>
>> -j
> I like the idea of the client tool encompassing this functionality, it
> can just feed there response from the build into the push. I have only
> looked through the aeolus-image command objects, I'm happy to take a
> stab at the implementation and post it for review. I would prefer to not
> have to introduce queueing functionality and request tracking on the
> imagefactory side to achieve client tooling niceties.
>
> - Chris
>
>
>
> _______________________________________________
> aeolus-devel mailing list
> aeolus-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/aeolus-devel
I'm worried about our ability to easily get status back from build, but
I'd love to able to make build + push in a single step available.
And absolutely agree on keeping it low impact to factory and avoiding
having to introduce queue management in general.
If you have cycles to work through a patch that would be great!
Thanks,
Mike
Yeah, in the proposed UI design we've already combined build and push --
and had talked about having to do the build;wait;push bit in the
conductor controller or model. If we can get that combination pushed
further down the API chain that would be even better.
Scott