[openstack-dev] [nova][ceilometer] model for ceilo/nova interaction going forward

Doug Hellmann doug.hellmann at dreamhost.com
Tue Nov 27 17:40:21 UTC 2012


On Mon, Nov 26, 2012 at 6:01 PM, Mark McLoughlin <markmc at redhat.com> wrote:

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

OK. I largely agree, I just wanted to make sure I understood what you were
saying.

Doug


>
> Cheers,
> Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/b040bc42/attachment.html>


More information about the OpenStack-dev mailing list