<div dir="ltr">Folks<div><br></div><div>I am writing this email to discuss very important topic which appeared to be rather hot with several bugs associated with it. </div><div><br></div><div>For example these ones:</div><div><div><a href="https://bugs.launchpad.net/fuel/+bug/1472018">https://bugs.launchpad.net/fuel/+bug/1472018</a><br></div><div><a href="https://bugs.launchpad.net/fuel/+bug/1468053">https://bugs.launchpad.net/fuel/+bug/1468053</a><br></div><div><br></div><div>There were several fixes applied. One of them was merged (unfortunately) and one was stopped by me and other reviewers of stable branches (fortunately),</div><div><br></div><div>I want to  describe why these bugs happened, why such fixes should not be applied and which solution I envision the best for such cases.</div><div><br></div><div>The key issue here is that our CI tests are using some code not from packages of particular releases, but from other sources, e.g. pypi for python.</div><div>Libraries being installed are determined by using particular requirements.txt/test-requirements.txt files. These files usually do not contain upper bound for libraries versions, thus the newest versions are getting installed. This leads to the issues which are especially no good for already released code:</div><div><br></div><div>1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released</div><div>2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code</div><div>3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use</div><div>4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of packages</div><div><br></div><div>All this means that you will get false-negative (you are lucky in this case) -1's from CI or false-positive (oops, it can ruin the production installation) +1's from CI. <br></div><div><br></div><div>So far I suggest that we do the following (which, strictly speaking, seems to be the only reasonable one): in order to do good testing of components, we need to do complete freeze of all other libraries and components code we are linking/running against. Especially, this should happen for already released code which gets into state of being maintained after that.</div><div><br></div><div>This means that we need to not only freeze our repositories, but use a frozen copy of rubygems/pypi/nodejs repositories for all types of tests we run. This will require certain amount of effort from our Infra teams to build up a mechanism of freezing/unfreezing the mirrors, determining how we should add new pieces of code in such mirrors, may be, add some additional code-review policies, create real mirroring scripts and so on.</div><div><br></div><div>But I think we should start doing this now in order to finish it at least before 8.0 timeframe.</div><div><br></div><div>As a temporary solution, I suggest that we apply a series of changes into these requirements.txt files before running actual tests instead of modifying product code.</div><div><br></div><div>Please provide your comments and thoughts.</div><div><br></div><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">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><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></div>