<div dir="ltr">On Tue, Aug 27, 2013 at 12:13 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">




<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><span style="color:rgb(34,34,34)">IMO, to be the healthiest project we can be, we must focus on what code</span><br>




</div>
is actually a part of Nova.  If you'd like to submit your changes for<br>
inclusion into Nova, then we can talk.<br></blockquote><div><br></div><div>That's ultimately what we're trying to accomplish here.<br><br></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">





What you are seeing here is a part of the pain of maintaining a fork.  I<br>
am not OK with shifting part of that burden on to the upstream project<br>
when it doesn't help the upstream project *at all*.</blockquote><div><br></div><div>We're not maintaining a fork, nor trying to shift burden. That's unfair. We have a long term interest in the success of OpenStack, like everyone here. We're not asking "upstream" to do anything. This isn't adversarial.</div>




<div><br></div><div>There are plenty of things that don't help nova directly, but certainly enable a vibrant ecosystem. For example, having extensible APIs and pluggable backends is critical to the philosophy and success of OpenStack as a whole.</div>



<div><br></div>
<div>We absolutely understand that having solid, in-tree implementations is also important. That's why as a part of the blueprint, there was a pan-community effort made to create a libvirt implementation. Although that particular effort has hit some speed bumps, merging the API extension would still benefit members of the community by simplifying deployments (i.e. for us) and Havana backports (i.e. needing to provide only an updated compute driver w/ config change). Other hypervisor driver maintainers have also expressed the desire to see it merged to speed and simplify development of in-tree implementations moving forward. It's not just going to get dropped on the floor.</div>



<div><br></div><div>In the end, I think that the need to have the reference implementation land at the same moment should be balanced against community interests. Yes, we really want to see the API in Havana, but it seems we're not alone. I would understand holding off if there were substantial downsides to merging, or if multiple hypervisor vendors had expressed a desire to see it not merged. But that doesn't seem to be the case. Six months is a long time, and ultimately the evolution of an open source ecosystem is just as important as the code itself.</div>



<div><br></div><div>Thanks,</div><div>-Adin</div></div></div></div>