On Fri, 2011-07-29 at 12:26 -0400, Mike Orazi wrote:
On 07/27/2011 05:06 PM, Jason Guiditta wrote:
> On Sun, 2011-07-24 at 14:44 -0400, Hugh Brock wrote:
>> Hello all.
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
This is entirely possible, though I think per object with should just
work on iwhd side (Jim or Pete, please correct me if I am wrong). What
I recall for issues around this were two things:
1. There is not a way to just 'clear out everything from iwhd' simply,
without removing the contents of the fs and mongo manually (again,
sketchy memory on this). However, I also recall this being described as
'by design', though I forget the rationale.
2. Since there is no object hierarchy in iwhd, there may be a bit of
effort (as in possibly a lot) in making sure constraints are met on a
delete, otherwise we could end up with orphaned objects that should no
Are there any other details like that which we need to be able to
about and agree upon across projects before moving forward?
Other details I can think of:
* I think there is some overlap likely here in the feature Matty posted
about launching standalone images, as there was some rework under
discussion to writer what will essentially be an OO client library to
deal with our objects stored in iwhd.
* What do we want to do with event notifications (status change,
completion %, for example)? I maintain that sending them to either the
cli or a log file owned by same doesn't make much sense. However, they
are transient, so if we do nothing with the notification, it is lost.
There was discussion of saving status in a tag on one or more objects in
iwhd, but not everyone agreed with this approach. Depending on what we
want to do with this information, we can propose ways to handle it, but
without a firm requirement of 'I would like to use notifications for X'
this will be a circular discussion.
* We talked about a nicer presentation of the information returned
(using an erb or builder template system, for example).
* There was also talk of a 'show' command to present full detail on an
* Better/more robust error reporting in aeolus-image and console