<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 14, 2021 at 9:07 PM Javier Pena <<a href="mailto:jpena@redhat.com">jpena@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 14, 2021 at 6:41 AM Marios Andreou <<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 13, 2021 at 9:41 PM James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>> wrote:<br> ><br> > I'd like to propose that TripleO opt out of dependency management by removing tripleo-common from global-requirements.txt.  I do not feel that the global dependency management brings any advantages or anything needed for TripleO. I can't think of any reason to enforce the ability to be globally pip installable with the rest of OpenStack.<br><br> To add a bit more context as to how this discussion came about, we<br> tried to remove tripleo-common from global-requirements and the<br> check-requirements jobs in tripleoclient caused [1] as a result.<br><br> So we need to decide whether to continue to be part of that<br> requirements contract [2] or if we will do what is proposed here and<br> remove ourselves altogether.<br> If we decide _not_ to implement this proposal then we will also have<br> to add the requirements-check jobs in tripleo-ansible [3] and<br> tripleo-validations [4] as they are currently missing.<br><br> ><br> > Two of our most critical projects, tripleoclient and tripleo-common do not even put many of their data files in the right place where our code expects them when they are pip installed. So, I feel fairly confident that no one is pip installing TripleO and relying on global requirements enforcement.<br><br> I don't think this is _just_ about pip installs. It is generally about<br> the contents of each project requirements.txt. As part of the<br> requirements contract, it means that those repos with which we are<br> participating (the ones in projects.txt [5]) are protected against<br> other projects making any breaking changes in _their_<br> requirements.txt. Don't the contents of requirements.txt also end up<br> in the .spec file from which we are building rpm e.g. [6] for tht? In<br> which case if we remove this and just stop catching any breaking<br> changes in the check/gate check-requirements jobs, I suspect we will<br> just move the problem to the rpm build and it will fail there.<br></blockquote><div><br></div><div>I don't see that in the spec file. Unless there is some other automation somewhere that regenerates all of the BuildRequires/Requires and modifies them to match requirements.txt/test-requirements.txt?</div><div><br></div></div></div></blockquote><div>We run periodic syncs once every cycle, and try our best to make spec requirements match requirements.txt/test-requirements.txt for the project. See <a href="https://review.rdoproject.org/r/c/openstack/tripleoclient-distgit/+/33367" target="_blank">https://review.rdoproject.org/r/c/openstack/tripleoclient-distgit/+/33367</a> for a recent example on tripleoclient.<br></div><div><br></div><div>I don't have a special opinion on keeping tripleo-common inside global-requirements.txt or not. However, all TripleO projects still need to be co-installable with other OpenStack projects, otherwise we will not be able to build packages for them due to all the dependency issues that could arise. </div></div></div></blockquote><div><br></div><div>I think this is probably less of an issue with containerized services(?). At present,  there are only two service containers that install tripleo-common (mistral,  nova-scheduler). With mistral deprecated and nova removed from the undercloud (tripleo-common has a tripleo specific scheduler filter used by undercloud nova), we probably won't have many issues.</div><div><br></div><div>However, as we sync requirements from project requirements to package specs regularly, there could be issues with broken  requirements.</div><div><br></div><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:rgb(0,0,0)"><div>I'm not sure if that was implied in the original post.<br></div><div><br></div><div>Regards,<br></div><div>Javier<br></div><div><br></div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">><br> > One potential advantage of not being in global-requirements.txt is that our unit tests and functional tests could actually test the same code. As things stand today, our unit tests in projects that depend on tripleo-common are pinned to the version in global-requirements.txt, while our functional tests currently run with tripleo-common from master (or included depends-on).<br><br> I don't think one in particular is a very valid point though - as<br> things currently stand in global-requirements we aren't 'pinning' all<br> we have there is "tripleo-common!=11.3.0  # Apache-2.0" [7] to avoid<br> (I assume) some bad release we made.<br></blockquote><div><br></div><div>tripleo-common is pinned to the latest release when it's pip installed in the venv, instead of using latest git (and including depends-on). You're right that it's probably what we want to keep doing, and this is probably not related to opting out of g-r. Especially since we don't want to require latest git of a dependency when running unit tests locally. However it is worth noting that our unit tests (tox) and functional tests (tripleo-ci) use different code for the dependencies. That was not obvious to me and others on the surface. Perhaps we could add additional tox jobs that do require the latest tripleo-common from git to also cover that scenario.</div><div><br></div><div>Here's an example:<br></div><div><a href="https://review.opendev.org/c/openstack/python-tripleoclient/+/787907" target="_blank">https://review.opendev.org/c/openstack/python-tripleoclient/+/787907</a><br></div><div><a href="https://review.opendev.org/c/openstack/tripleo-common/+/787906" target="_blank">https://review.opendev.org/c/openstack/tripleo-common/+/787906</a><br></div><div><br></div><div>The tripleo-common patch fails unit tests as expected, the tripleoclient which depends-on the tripleo-common patch passes unit tests, but fails functional. I'd rather see that failure caught by a unit test as well.<br></div><div><br></div><br clear="all"></div>-- <br><div dir="ltr">-- James Slagle<br>--</div></div></blockquote><div><br></div></div></div></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div></div>