On Mon, Aug 27, 2012 at 02:47:42PM +0200, Jan Provaznik wrote: > On 08/21/2012 06:15 PM, Tomas Sedovic wrote:
[heavy snipping below] > >As a side benefit, we would get the current and future features of Heat > >for free: > > > >* high availability > >* auto-scaling > >* load-balancing I think these things would be really valuable additions to Aeolus. I confess that I haven't fully wrapped my head around how some of these things can best be adapted to a cross-cloud environments -- it seems like it would introduce a bunch of new complexity. But if it works reliably, I think it would be a fantastic feature to add! > nit: you probably meant 'deployment' instead of 'deployable' in the > paragraph above. It occurs to me that if we as developers (and I'm absolutely including myself here -- I'm a repeat offender) keep mixing these terms up, it might make sense to try to change them. The terms are similar and one morphs into another at a certain point, so it's very easy to mix them up even if you know the distinction inside and out. I can't imagine users find this any easier than we do. (This is really a digression from the real topic here, but I wanted to mention it.) > - the deployment launch setup becomes more complicated, a request > will pass through 3 standalone services: > Conductor -> Heat -> Deltacloud -> Provider I was noticing the other day that we don't do a good job of accurately catching and reporting errors from other components, or making it clear which component the problem is. So if you have, say, trouble building an image, you need to poke around a bit to figure out if it's a Conductor problem or a Factory problem, and then you need to figure out what the actual error is. Adding an extra component seems like it would make this even more complicated. I'm all for adding Heat, mind you. I just think that if we do, we're going to have to commit to good error handling and reporting, without leaving people to read multiple logs to figure out where the problem began. -- Matt
