<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 14, 2022 at 12:12 AM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</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 Wed, Apr 13, 2022, at 12:11 AM, Ian Wienand wrote:<br>
> On Tue, Apr 12, 2022 at 05:05:22PM -0700, Michael Johnson wrote:<br>
> 65;6602;1c> tldr: All devstack based jobs are going to fail with newer <br>
> versions of<br>
>> git - don't bother rechecking<br>
>> <br>
>> git has released a security fix [1] that is starting to roll out in<br>
>> distributions (Ubuntu focal for example) that will cause pbr to be<br>
>> unable to access the package metadata for packages checked out locally<br>
>> due to the directory ownership used in devstack.<br>
><br>
> This turns out to be annoyingly complicated.<br>
><br>
> Since devstack checks out all code as "stack" and then installs<br>
> globally with "sudo pip install -e ...", pbr will be running in a<br>
> directory owned by "stack" as root and its git calls will hit this<br>
> failure.<br>
><br>
> If we make the code directories owned by root, we now have additional<br>
> problems.  Several places do things in the code repositories --<br>
> e.g. setup virtualenvs, run ./tools/*.sh scripts to generate sample<br>
> config files and run tox as "stack" (tox then tries to install the<br>
> source tree in it's virtualenv -- if it's owned by root -- again --<br>
> failure).<br>
><br>
> I explored a bunch of these options in<br>
><br>
>   <a href="https://review.opendev.org/c/openstack/devstack/+/837636" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/837636</a><br>
><br>
> and anyone feel free to take over that and keep trying.<br>
><br>
> The other option is to use the new config flag to mark our checkouts<br>
> as safe.  This is obviously simpler, but it seems like a very ugly<br>
> thing for a nominally generic tool like devstack to do to your global<br>
> git config.  This is done with<br>
><br>
>   <a href="https://review.opendev.org/c/openstack/devstack/+/837659" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/837659</a><br>
><br>
> and appears to work; but will need backporting for grenade if we want<br>
> to take this path.<br>
<br>
This ended up being the quickest option to unblocking things so we backported it all the way through to Victoria then landed the changes from Victoria up to master in that order. This means that devstack testing should work again and you can recheck/approve/push changes once again.<br>
<br>
However, we noticed that these changes don't quite work on Ubuntu Bionic just on Ubuntu Focal. Dan pushed up <a href="https://review.opendev.org/c/openstack/devstack/+/837759" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/837759</a> to address the Bionic problem and make unstack clean up after ourselves. Once this lands to master we can backport it using our typical backporting process.<br>
<br>
Finally fungi has been working on <a href="https://review.opendev.org/c/openstack/devstack/+/837731" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/837731</a> to separate the package creation step from the package installation step. This allows us to build the python package as the stack user and do the install as root avoiding any git concerns about different ownership of repositories. As the commit message in that change notes this effectively means that we cannot have editable installs anymore.<br>
<br>
If we decide that is a necessary feature of devstack then I think we should look into resurrecting <a href="https://review.opendev.org/c/openstack/devstack/+/558930" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/558930</a> to have devstack install into a global virtualenv. Then stack can own the virtualenv, and there is no git concern about file ownership. In the past this change sort of died out as it is quite a large change to how devstack operates and will potentially have significant fallout of its own if we land it and there just didn't seem to be a will to go through that. Maybe this situation has changed our opinion on that. Others should feel free to push updates to that change as I'm not sure I'll have time to dedicate to it again.<br></blockquote><div><br></div><div>As a data point: maintaining bifrost has become much easier once we did a similar thing and started using a virtualenv.</div><div><br></div><div>Dmitry<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">
<br>
><br>
> When this kicked off I sent in a link to HN thinking that thanks to<br>
> our very upstream focused CI we were likely some of the first to hit<br>
> this; it's currently the top post so I think that is accurate that<br>
> this is having wide impact:<br>
><br>
>   <a href="https://news.ycombinator.com/item?id=31009675" rel="noreferrer" target="_blank">https://news.ycombinator.com/item?id=31009675</a><br>
><br>
> It is probably worth keeping one eye on upstream for any developments<br>
> that might change our options.<br>
><br>
> -i<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>