<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 8:17 AM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 8/14/2014 6:42 PM, Doug Hellmann wrote:<br>
</div>
<blockquote type="cite">
<br>
<div>
<div>On Aug 14, 2014, at 4:41 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann <span dir="ltr">
<<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn <<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>> wrote:<br>
<br>
><br>
>>> At the end of the day, that's probably going to mean saying No to more<br>
>>> things. Everytime I turn around everyone wants the TC to say No to<br>
>>> things, just not to their particular thing. :) Which is human nature.<br>
>>> But I think if we don't start saying No to more things we're going to<br>
>>> end up with a pile of mud that no one is happy with.<br>
>><br>
>> That we're being so abstract about all of this is frustrating. I get<br>
>> that no-one wants to start a flamewar, but can someone be concrete about<br>
>> what they feel we should say 'no' to but are likely to say 'yes' to?<br>
>><br>
>><br>
>> I'll bite, but please note this is a strawman.<br>
>><br>
>> No:<br>
>> * Accepting any more projects into incubation until we are comfortable with<br>
>> the state of things again<br>
>> * Marconi<br>
>> * Ceilometer<br>
><br>
> Well -1 to that, obviously, from me.<br>
><br>
> Ceilometer is on track to fully execute on the gap analysis coverage<br>
> plan agreed with the TC at the outset of this cycle, and has an active<br>
> plan in progress to address architectural debt.<br>
<br>
</div>
Yes, there seems to be an attitude among several people in the community that the Ceilometer team denies that there are issues and refuses to work on them. Neither of those things is the case from our perspective.<br>
</blockquote>
<div><br>
</div>
<div>Totally agree.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Can you be more specific about the shortcomings you see in the project that aren’t being addressed?<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Once again, this is just a straw man.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You’re not the first person to propose ceilometer as a project to kick out of the release, though, and so I would like to be talking about specific reasons rather than vague frustrations.</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I'm just not sure OpenStack has 'blessed' the best solution out there.</div>
<div><br>
</div>
<div><a href="https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready" target="_blank">https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready</a></div>
<div><br>
</div>
<div><font color="#333333" face="Arial Unicode MS,
                    Arial, sans-serif"><span style="font-size:14px;line-height:20px">"</span></font></div>
<ul>
<li>Successfully passed the challenge of being adopted by 3 related projects which have agreed to join or use ceilometer:
<ul style="padding:0px;margin:0.3em 0px 0px 1.6em">
<li>Synaps </li><li>Healthnmon </li><li><a href="https://wiki.openstack.org/w/index.php?title=StackTach&action=edit&redlink=1" title="StackTach (page does not exist)" style="color:rgb(186,0,0);text-decoration:none" target="_blank">StackTach</a>"
</li></ul>
</li></ul>
<div><br>
</div>
<div>Stacktach seems to still be under active development (<a href="http://git.openstack.org/cgit/stackforge/stacktach/log/" target="_blank">http://git.openstack.org/cgit/stackforge/stacktach/log/</a>), is used by rackspace in production
 and from everything I hear is more mature then ceilometer.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Stacktach is older than ceilometer, but does not do all of the things ceilometer does now and aims to do in the future. It has been a while since I last looked at it, so the situation may have changed, but some of the reasons stacktach would not be a full
 replacement for ceilometer include: it only works with AMQP; it collects notification events, but doesn’t offer any metering ability per se (no tracking of values like CPU or bandwidth utilization); it only collects notifications from some projects, and doesn’t
 have a way to collect data from swift, which doesn’t emit notifications; and it does not integrate with Heat to trigger autoscaling alarms.</div>
<div><br>
</div>
</div>
</blockquote></div></div>
Well, that's my cue. <br>
<br>
Yes, StackTach was started before the incubation process was established and it solves other problems. Specifically around usage, billing and performance monitoring, things I wouldn't use Ceilometer for. But, if someone asked me what they should use for metering
 today, I'd point them towards Monasca in a heartbeat. Another non-blessed project.<br></div></blockquote><div><br></div><div>I think this is the crux of the potential argument against ceilometer today. There are several other viable competing open source candidates in this space.  And an argument can be made that having OpenStack bless a winner before one clearly emerges on its own doesn't help. If blessing a winner resulted in the teams working together more and less duplicated efforts that would be one thing, but that does not appear to be happening in this space.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
It is nice to see that Ceilometer is working to solve their problems, but there are other solutions operators should consider until that time comes. It would be nice to see the TC endorse those too. Solve the users need first.<div class="">

<br>
<br>
<blockquote type="cite">
<div>
<div></div>
<div>We did work with a few of the Stacktach developers on bringing event collection into ceilometer, and that work is allowing us to modify the way we store the meter data that causes a lot of the performance issues we’ve seen. That work is going on now and
 will be continued into Kilo, when we expect to be adding drivers for time-series databases more appropriate for that type of data.</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
StackTach isn't actively contributing to Ceilometer any more. Square peg/round hole. We needed some room to experiment with alternative solutions and the rigidity of the process was a hindrance. Not a problem with the core team, just a problem with the dev
 process overall. <br>
<br>
I recently suggested that the Ceilometer API (and integration tests) be separated from the implementation (two repos) so others might plug in a different implementation while maintaining compatibility, but that wasn't well received.
<br>
<br>
Personally, I'd like to see that model extended for all OpenStack projects. Keep compatible at the API level and welcome competing implementations.
<br>
<br>
We'll be moving StackTach.v3 [1] to StackForge soon and following that model. The API and integration tests are one repo (with a bare-bones implementation to make the tests pass) and a separate repo with the implementation we endorse, but the tools are there
 if you want to make your own. Like what Dwarf did with Nova [2]. Something to consider.
<br>
<br>
[1] <a href="https://github.com/StackTach" target="_blank">https://github.com/StackTach</a>
<br>
screencasts <a href="https://www.youtube.com/playlist?list=PLmyM48VxCGaW5pPdyFNWCuwVT1bCBV5p3" target="_blank">
https://www.youtube.com/playlist?list=PLmyM48VxCGaW5pPdyFNWCuwVT1bCBV5p3</a><br>
[2] <a href="https://github.com/juergh/dwarf" target="_blank">https://github.com/juergh/dwarf</a><br>
<br>
(views are mine, not my employer)<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div>
<div></div>
<div>We’ve just finished the TC meeting where some of these issues were discussed, but I want to reiterate my stance here more publicly. As a community, we need to be able to talk about the technical shortcomings of projects. We need to be able to say, for
 example, “ceilometer, your runtime performance isn’t good enough, you need to work on that rather than adding features.” But we must also be willing give the team in question the benefit of the doubt that they will work on the problem before we bring out the
 pitchforks of de-integration, because there are serious community implications around that level of rejection.</div>
<div><br>
</div>
<div>Doug</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
><br>
>> Divert all cross project efforts from the following projects so we can focus<br>
>> our cross project resources. Once we are in a bitter place we can expand our<br>
>> cross project resources to cover these again. This doesn't mean removing<br>
>> anything.<br>
>> * Sahara<br>
>> * Trove<br>
>> * Tripleo<br>
><br>
> You write as if cross-project efforts are both of fixed size and<br>
> amenable to centralized command & control.<br>
><br>
> Neither of which is actually the case, IMO.<br>
><br>
> Additional cross-project resources can be ponied up by the large<br>
> contributor companies, and existing cross-project resources are not<br>
> necessarily divertable on command.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
</div>
What “cross-project efforts” are we talking about? The liaison program in Oslo has been a qualified success so far. Would it make sense to extend that to other programs and say that each project needs at least one designated QA, Infra, Doc, etc. contact?<br>


<span><font color="#888888"><br>
Doug<br>
</font></span>
<div><br>
><br>
>> Yes:<br>
>> * All integrated projects that are not listed above<br>
><br>
> And what of the other pending graduation request?<br>
><br>
> Cheers,<br>
> Eoghan<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">
OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div></div></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>