<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 6:01 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 2012-11-26 at 10:39 -0500, Doug Hellmann wrote:<br>
><br>
><br>
> On Fri, Nov 23, 2012 at 1:26 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
> wrote:<br>
>         On Thu, 2012-11-22 at 16:32 -0500, Eoghan Glynn wrote:<br>
<br>
</div><div class="im">>         > > If we were just designing a solution for metering, would<br>
>         we go for<br>
>         > > the notifications option?<br>
>         ><br>
>         > Probably, but the scope of ceilo has widened a bit from pure<br>
>         > metering.<br>
><br>
><br>
>         Right. From a far remove, that looks like a mistake at this<br>
>         early stage.<br>
><br>
>         As Sandy rightly says, if we just focused on metering, then<br>
>         the<br>
>         conclusion is simple - improve the notifications<br>
>         infrastructure. If<br>
>         Ceilometer focused on its original mission, forward progress<br>
>         would be<br>
>         easier.<br>
><br>
><br>
> We've had conflicting messages on that point. When we applied for<br>
> incubation I understood the TC mandate for the project to be "measure<br>
> everything," and that has led to consideration of features like<br>
> monitoring and collecting data more frequently and in different ways<br>
> than would be necessary for just billing-related purposes. However,<br>
> when changes related to those features are proposed we've had some<br>
> push-back because of scope creep. Are you suggesting we should drop<br>
> the monitoring work?<br>
<br>
</div>Uggh, I don't want to be talking about "TC mandates" here :)<br>
<br>
A project gets accepted into Incubation partly based on the fact that<br>
the TC has a reasonable level of trust in the judgement of the project<br>
leaders. I'd hate to see the TC get into mandating the detailed<br>
technical direction of an incubating project.<br>
<br>
The way I'd personally like to see Ceilometer approach incubation is to<br>
focus completely on metering, "knock the ball out of the park" and be a<br>
kick-ass metering solution when Grizzly is released.<br>
<br>
I worry that if the scope expands, you might get to Grizzly release time<br>
and still have a bunch of loose ends. I mention it in this Nova<br>
integration thread because it looks like a good example. IMHO, if<br>
Ceilometer was focused (for now) purely on metering then this thread<br>
would have been shorter and the solution might already be in place.<br>
<br>
So, it's not about TC mandates. It's about TC folks giving their best<br>
advice on the trade-offs you guys are facing. It's for you to make the<br>
decision on those trade-offs.<br>
<br>
(In fact, I only expressed an opinion here because the idea came up of<br>
moving Nova's virt drivers out as an Oslo library)<br>
<br>
That's not to say monitoring isn't important, or that there isn't a<br>
whole lot of benefit to monitoring an metering folks working together,<br>
or that no-one should be working on monitoring right now, or that Nova<br>
doesn't need to support monitoring requirements, or ... just let's not<br>
allow monitoring slow down progress on metering.<br></blockquote><div><br></div><div>OK. I largely agree, I just wanted to make sure I understood what you were saying.</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Mark.<br>
<br>
</blockquote></div><br>