<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 1:57 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.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 01/23/2013 01:49 PM, Sandy Walsh wrote:<br>
> Agreed. My concern is, this is a somewhat simple application and it<br>
> seems (to me) that openstack.common immediately makes things complex.<br>
> I'm sure there is more being used in Oslo than just logging and config<br>
> that I'm missing.<br>
<br>
</div>In this specific case, I believe the Ceilometer folks are adding, or<br>
actively working on adding, pieces to Oslo that match the work they did<br>
on the new Pecan-based WSGI router framework. I think the reason that<br>
they use Oslo now is because they copied in a whole chunk of Nova code<br>
to begin the project -- for expedience's sake -- and then after working<br>
with the Oslo team saw that it would be cleaner to use Oslo and<br>
contribute fixes back into it. Ceilo contributors, please correct me if<br>
I am wrong!<br></blockquote><div><br></div><div>Besides logging and config, we're using the RPC and service code. We've never used the WSGI stack, and I'm working on getting example code together as part of my pitch to replace the WSGI stack for new development with Pecan and WSME. Ceilometer's V2 API is part of that, but I need to show how extensions would work, too. We also have a blueprint for adding an API to listen to notifications to the RPC library, so it will be possible to write client code using notifications no matter which transport is selected in a deployment.</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">
<div class="im"><br>
> Permission to speak freely ...<br>
><br>
> Put another way, should every openstack project have to use the common<br>
> libraries if they can skin the cat in an easier way? Should they have to<br>
> take on the extra workload of fixing up another project in that effort?<br>
> Will they be shunned if they don't?<br>
<br>
</div>Shunned? No. Encouraged to align, yes. :) As you know, it's a pet peeve<br>
of mine to see duplicated code, so I take special note on things such as<br>
these.<br>
<div class="im"><br>
> I know the right answer is "yes, do it for the betterment of the<br>
> community." ... but sometimes you just want to get make some progress<br>
> quickly. (this is just me talking off the cuff here, of course :)<br>
><br>
> Again, and it's just my $0.02, but the whole thing seems like hanging a<br>
> picture nail with a sledge hammer.<br>
<br>
</div>I totally understand the pressure to get things working and make<br>
progress, trust me. :) This was merely a gentle nudge to remember that<br>
there is benefit in code re-use that often trumps short-term gains in<br>
productivity.<br>
<br>
All said with the deepest respect and reverence for your work, Sandy :)<br>
<div class="HOEnZb"><div class="h5"><br>
Best,<br>
-jay<br>
<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>
</div></div></blockquote></div><br>