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_Instances
>>>>>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