<div dir="ltr"><div>I think we should also look at the root cause of these CI failures.</div><div>They are connected with difference in packages and not with manifests or deployment process.</div><div>So another possible solution is to stay as close as possible to the package sources used by OpenStack Puppet modules CI.</div><div>For example, we have a BP [0] that adds an ability to deploy UCA packages with Fuel.</div><div>Current package sources used by openstack-modules CI can be found here [1]</div><div><br></div><div>Just my 2c.</div><div>Thanks.</div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages">https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages</a></div><div>[1] <a href="https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/repos.pp#L4">https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/repos.pp#L4</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 2:21 PM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry<span class=""><div><br></div><div>><span style="font-size:12.8000001907349px">I don't think "hurried" is applicable here: the only way to become more</span></div><span style="font-size:12.8000001907349px">>ready to track upstream than we already are is to *start* tracking</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>upstream. Postponing that leaves us in a Catch-22 situation where we</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>can't stay in sync with upstream because we're not continuously catching</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>up with upstream.</span><br style="font-size:12.8000001907349px"><div><br></div></span><div>First of all, if you read my email again, you will see that I propose a way of tracking upstream in less continuous mode with nightly testing and switching to it based on automated integration testing which will leave us 0 opportunity to face the aforementioned issues.</div><span class=""><div><br></div><div><span style="font-size:12.8000001907349px">>That would lock us into that Catch-22 situation where we can't allow</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>Fuel CI to vote on puppet-openstack commits because fuel-library is</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>always too far behind puppet-openstack for its votes to mean anything</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">>useful.</span><br></div><div><br></div></span><div>This is not true. We can run FUEL CI against any set of commits. </div><span class=""><div><br></div><div><span style="font-size:12.8000001907349px">> We have to approach this from the opposite direction: make Fuel CI</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> stable and meaningful enough so that, 9 times out of 10, Fuel CI failure</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> indicates a real problem with the code, and the remaining cases can be</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> quickly unblocked by pushing a catch-up commit to fuel-library (ideally</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> with a Depends-On tag).</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">Dmitry, could you please point me at the person who will be strictly responsible for creating this 'ketchup' commit? Do you know that this may take up the whole day (couple of hours to do RCA, couple of hours on writing and debugging and couple of hours for FUEL CI tests run) and block the entire Fuel project from having ANY code merged? Taking into consideration that openstack infra is currently under really high load it may take even several days for the fix to land into master. How do you expect us to have any feature merged prior to FF?</span></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> It is a matter of trust between projects: do we trust Puppet OpenStack</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> project to take Fuel's problems seriously and to avoid breaking our CI</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> more often than necessary? Can Puppet OpenStack project trust us with</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> the same? So far, our collaboration track record has been pretty good</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> bordering on examplary, and I think we should build on that and move</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> forward instead of clinging to the old ways.</span><br style="font-size:12.8000001907349px"></div></span><span class=""><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">The problem with moving only one piece at a time is that you end up so</span></div><span style="font-size:12.8000001907349px">> far behind that you're slowing everyone down. BKL and GIL are not the</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> only way to deal with concurrency, we can do better than that.</span></span><div><span style="font-size:12.8000001907349px"><br></span><div><span style="font-size:12.8000001907349px">I have always thought that buliding software is about verification being more important than 'trust'. There should not be any humanitarian stuff invloved - we are not in a relationship with Puppet-OpenStack folks, although I really admire their work very much. We should not follow sliding git references without being 100% sure that we have mutual gating of the code.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Moreover, having such git ref as a source in our Puppetfile will lead to the situation when we have UNREPRODUCIBLE build of Fuel project. Each build may and will result in different code and you will not be able to tell which one without actually looking into the build logs. I think, that this is unacceptable as it may lead to impossibilty of debugging and troubleshooting of anything because it will be impossible to reproduce things.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Additionally, we do not have:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">1) depends-on support</span></div><div><span style="font-size:12.8000001907349px">2) any process instantiated for monitoring of the Puppet-Openstack FUEL CI job</span></div><div><span style="font-size:12.8000001907349px">3) any person responsible for monitoring of that job</span></div><div><br></div><div><span style="font-size:12.8000001907349px">Finally, we have another blocker issue [0] which essentially killed March 1st in EU timezone from code merge point of view as our master is blocked right now by non-boostrapping master node.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>Having that said I propose that we:</div><div><br></div><div>1) immediately pick a set of stable commits to puppet-openstck</div><div>2) immediately update puppetfile  with this set</div><div>3) unblock other fuel developers</div><div>4) fix the aforementioned issues</div><div>5) turn tracking of upstream commits on when we have all the pieces set up and when we are sure that we will not ever break master with this change. </div><div><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">[0] <a href="https://bugs.launchpad.net/fuel/+bug/1551584" target="_blank">https://bugs.launchpad.net/fuel/+bug/1551584</a></span></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 5:10 AM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Feb 29, 2016 at 01:19:29PM +0300, Vladimir Kuklin wrote:<br>
> Thanks for bringing this up. Frankly, I think that we hurried a little bit<br>
> by making our integration with upstream puppet manifests too continuous. I<br>
> would suppose that we used a little bit different technique.<br>
<br>
</span>I don't think "hurried" is applicable here: the only way to become more<br>
ready to track upstream than we already are is to *start* tracking<br>
upstream. Postponing that leaves us in a Catch-22 situation where we<br>
can't stay in sync with upstream because we're not continuously catching<br>
up with upstream.<br>
<span><br>
> First of all, we need to have a set of stable Fuel commits against which<br>
> the changes to upstream manifests should be tested. Could you please<br>
> elaborate on whether we are doing this already?<br>
<br>
</span>We are using the same known-good Fuel ISO for puppet-openstack and<br>
fuel-library, so in that sense, yes, we are doing this already.<br>
<br>
We use the HEAD of master branch of fuel-library in these tests, because<br>
using the fuel-library commit from the known-good ISO would mean having<br>
to update that ISO every time we merge a commit that brings fuel-library<br>
up to date with recent changes in puppet-openstack.<br>
<span><br>
> Secondly, we need to have FUEL CI working with a set of stable commits of<br>
> puppet openstack manifests which passed those upstream tests as we should<br>
> not have too much moving parts or we will get into situation similar to<br>
> requirements.txt updates when we have pypi updated with new library, e.g.<br>
> oslo-serialization.<br>
<br>
</span>That would lock us into that Catch-22 situation where we can't allow<br>
Fuel CI to vote on puppet-openstack commits because fuel-library is<br>
always too far behind puppet-openstack for its votes to mean anything<br>
useful.<br>
<br>
We have to approach this from the opposite direction: make Fuel CI<br>
stable and meaningful enough so that, 9 times out of 10, Fuel CI failure<br>
indicates a real problem with the code, and the remaining cases can be<br>
quickly unblocked by pushing a catch-up commit to fuel-library (ideally<br>
with a Depends-On tag).<br>
<br>
It is a matter of trust between projects: do we trust Puppet OpenStack<br>
project to take Fuel's problems seriously and to avoid breaking our CI<br>
more often than necessary? Can Puppet OpenStack project trust us with<br>
the same? So far, our collaboration track record has been pretty good<br>
bordering on examplary, and I think we should build on that and move<br>
forward instead of clinging to the old ways.<br>
<span><br>
> In this case, we will be able to do proper testing against frozen code-base<br>
> for each piece thus avoiding such issues while retaining fair amount of<br>
> integration with upstream puppet manifests for OpenStack.<br>
<br>
</span>The problem with moving only one piece at a time is that you end up so<br>
far behind that you're slowing everyone down. BKL and GIL are not the<br>
only way to deal with concurrency, we can do better than that.<br>
<br>
--<br>
Dmitry Borodaenko<br>
<span><br>
<br>
> On Fri, Feb 26, 2016 at 1:28 PM, Ivan Berezovskiy <<a href="mailto:iberezovskiy@mirantis.com" target="_blank">iberezovskiy@mirantis.com</a><br>
> > wrote:<br>
><br>
> > Hello, Fuelers!<br>
> ><br>
> > Yesterday we've faced an issue which came from puppet-neutron<br>
</span>> > module: LP #1549934 <<a href="https://bugs.launchpad.net/fuel/+bug/1549934" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1549934</a>>. Fix<br>
<span>> > was prepared very fast:<br>
> > <a href="https://review.openstack.org/#/c/284882/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/284882/</a> (thanks Sergey for this).<br>
> > So, If CI is red on your patch please re-base it on top of master.<br>
> ><br>
> > Anyway, this issue affected a lot of patches and blocked some developers,<br>
> > because BVT and neutron_smoke tests was also broken. We need to find<br>
> > a way how to minimize risks and affection of such changes on fuel-library.<br>
> > We have jobs which monitors upstream patches:<br>
> > <a href="https://ci.fuel-infra.org/view/puppet-openstack/" rel="noreferrer" target="_blank">https://ci.fuel-infra.org/view/puppet-openstack/</a><br>
> > Let's start to monitor those jobs on daily basis. We should have at least 1<br>
> > (ideally 2 or more) engineers which are responsible for analysis of those<br>
> > CI failures. If patch to puppet module is incorrect - we should review it<br>
> > with explanation what is actually wrong. If patch is correct, but breaks<br>
> > current Fuel CI, it means that problem is in our side and we should prepare<br>
> > fuel-library adapt patch to fix the issue. Ideally, we should have an<br>
> > ability<br>
> > to test this fuel-library patch together with upstream one e.g. using<br>
> > 'Depends on'<br>
> > in commit message.<br>
> ><br>
> > Thoughts?<br>
> ><br>
> > --<br>
> > Thanks, Ivan Berezovskiy<br>
> > MOS Puppet Team Lead<br>
</span>> > at Mirantis <<a href="https://www.mirantis.com/" rel="noreferrer" target="_blank">https://www.mirantis.com/</a>><br>
<span>> ><br>
> > slack: iberezovskiy<br>
> > skype: bouhforever<br>
> > phone: + 7-960-343-42-46<br>
> ><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
><br>
><br>
> --<br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> +7 (495) 640-49-04<br>
> +7 (926) 702-39-68<br>
> Skype kuklinvv<br>
> 35bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
</span>> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.ru/" rel="noreferrer" target="_blank">http://www.mirantis.ru/</a>><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a><br>
<div><div><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div><div dir="ltr"><div><div dir="ltr"><div><div class="h5">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br></div></div><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Regards,<div>Sergey Kolekonov</div></div></div></div></div>
</div>