<div dir="ltr">Hi Rob<div><br></div><div>Thanks for your excellent run of insightful reviewing :)</div><div><br></div><div>Cheers,</div><div><br></div><div>Chris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 February 2015 at 21:40, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I've really not been pulling my weight as a core reviewer in<br>
TripleO since late last year when personal issues really threw me for<br>
a while. While those are behind me now, and I had a good break over<br>
the christmas and new year period, I'm sufficiently out of touch with<br>
the current (fantastic) progress being made that I don't feel<br>
comfortable +2'ing anything except the most trivial things.<br>
<br>
Now the answer to that is to get stuck back in, page in the current<br>
blueprints and charge ahead - but...<br>
<br>
One of the things I found myself reflecting on during my break was the<br>
extreme fragility of the things we were deploying in TripleO - most of<br>
our time is spent fixing fallout from unintended, unexpected<br>
consequences in the system. I think its time to put some effort<br>
directly in on that in a proactive fashion rather than just reacting<br>
to whichever failure du jour is breaking deployments / scale /<br>
performance.<br>
<br>
So for the last couple of weeks I've been digging into the Nova<br>
(initially) bugtracker and code with an eye to 'how did we get this<br>
bug in the first place', and refreshing my paranoid<br>
distributed-systems-ops mindset: I'll be writing more about that<br>
separately, but its clear to me that there's enough meat there - both<br>
analysis, discussion, and hopefully execution - that it would be<br>
self-deceptive for me to think I'll be able to meaningfully contribute<br>
to TripleO in the short term.<br>
<br>
I'm super excited by Kolla - I think that containers really address<br>
the big set of hurdles we had with image based deployments, and if we<br>
can one-way-or-another get cinder and Ironic running out of<br>
containers, we should have a pretty lovely deployment story. But I<br>
still think helping on the upstream stuff more is more important for<br>
now. We'll see where we're at in a cycle or two :)<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Cheers,<div><br></div><div>Chris</div></div></div>
</div>