On Sun, 2011-07-24 at 14:44 -0400, Hugh Brock wrote:
> Hello all.
> Here's a revision of the 0.4.0 planning document that contains my
> attempt to capture the many suggestions and comments thus far. I think
> it's starting to look like a nice wish-list for a release, although I
> want more detail on the Orchestrator bits.
> Speaking of the whole Conductor/Orchestrator split. Mark and I got
> very excited about this because it seemed like there would be room for
> two smaller independent OSS projects there rather than one big hairy
> one. I've heard privately from various people however that they
> thought that split would leave Conductor as a not-all-that-interesting
> piece by itself, concerned only with cloud resource allocation and
> permissions (and some level of display of various things).
> How do folks out there feel about this? Can we have some debate here,
> Oh, and please feel free to comment further on the revision below.
Replying directly to the main email here, since I do not see this topic
covered at all. And that topic would be aeolus-image. We took a rough
first swag at it for the release heading out the door, but even from the
initially described list of functionality, not all things are done.
What I am wondering is if they are still a priority, or even still
valid. If the answer to both is yes, then if there are any major
suggestions for changes, (be that what params are passed in, how config
is used, $anything-else), now would be the time to discuss them. For
reference, the remaining features that we did not yet get to implement
that were on our list already (disregarding general internal
improvements we may have had in mind already) are:
--rebuild from existing template)
--rebuild new template to set of targets)
In addition to these what have a couple placeholder tasks for checking
status of a build and cleaning up existing objects of a certain type.
There is no design in place for either of these things yet. And of
course, we could use more building out of error-reporting (which is
largely getting back and returning to user, better message from factory
Sorry for the slow response. Personally I like these stories as
candidates to land in 0.4.0.
The thing I'm worried about is making sure that we call out the
dependencies required to make this happen and ensure that everyone is
comfortable that we can meet those dependencies.
I seem to remember some caveats around delete somewhere in the stack,
but currently the details are escaping me (or maybe it is no longer the
Are there any other details like that which we need to be able to talk
about and agree upon across projects before moving forward?