<div dir="ltr"><div class="gmail_default" style="font-size:small">Clint, Rob,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks a lot for your input: that's really a good point, and we didn't consider it before, while we definitely should.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Team,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Let's discuss this topic again before making any final decisions. </div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font>--<br></font><div dir="ltr"><font>Regards,<br>Alexander Tivelkov</font></div></div>
</div>
<br><br><div class="gmail_quote">2014/1/24 Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 24 January 2014 22:26, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
<br>
>> This enourmous amount of repositories adds too much infrustructural<br>
>> complexity, and maintaining the changes in in consistent and reliable<br>
>> manner becomes a really tricky tasks. We often have changes which require<br>
>> modifing two or more repositories - and thus we have to make several<br>
>> changesets in gerrit, targeting different repositories. Quite often the<br>
<br>
</div>As does adding any feature with e.g. networking - change neutron,<br>
neutronclient and nova, or block storage, change cinder, cinderclient<br>
and nova... This isn't complexity - it's not the connecting together<br>
of different things in inappropriate ways - its really purity, you're<br>
having to treat each thing as a stable library API.<br>
<div class="im"><br>
>> dependencies between these changesets are not obvious, the patches get<br>
>> reviewed and approved on wrong order (yes, this also questions the quality<br>
>> of the code review, but that is a different topic), which causes in<br>
>> inconsostent state of the repositories.<br>
<br>
</div>Actually it says your tests are insufficient, otherwise things<br>
wouldn't be able to land :).<br>
<div class="im"><br>
> So, as somebody who does not run Murano, but who does care a lot about<br>
> continuous delivery, I actually think keeping them separate is a great<br>
> way to make sure you have ongoing API stability.<br>
<br>
</div>+1 bet me to that by just minutes:)<br>
<div class="im"><br>
> Since all of those pieces can run on different machines, having the APIs<br>
> able to handle both "the old way" and "the new way" is quite helpful in<br>
> a large scale roll out where you want to keep things running while you<br>
> update.<br>
><br>
> Anyway, that may not matter much, but it is one way to think about it.<br>
<br>
</div>Indeed :)<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>
</font></span><div class="HOEnZb"><div class="h5"><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></div></div>