On Wed, Oct 26, 2011 at 01:54:16PM -0400, 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:
[snip]
>>>
>>>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
I think this is a great idea. And I agree, if we can use the client
tool to avoid major changes in the factory itself, that would be even
better.
There are various reasons we need the warehouse to store placeholder
objects, and I would support making it possible to do that if it isn't
too much work.
Take care,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey