gsc build fails for any distro workload on a Ubuntu 24.04 host system #202
Comments
|
Same problem. Install requests version 2.31.0 until it will be fixed |
|
We can no longer install packages via pip |
|
Does it work if you install these packages from |
All the packages are installed via apt |
|
Root cause of the issue: GSC uses Ubuntu 24.04 installs |
|
There are three approaches to fix this issue, @dimakuv @mkow, Please suggest which one suits better:
Test: Note:
|
|
Gramine and GSC currently don't claim official support for Ubuntu 24.04. So I think we can safely wait for option 3 -- this bug should be fixed in Ubuntu itself, and looks like there is no easy workaround for GSC at the moment. So my suggestion is to sit and wait for ~2 months. If nothing happens in this time frame, then we should revisit this issue. |
|
As we approach the Gramine 1.8 release and prepare for the official support of Ubuntu 24.04, we have been anticipating some resolution from the Ubuntu package manager regarding this issue. However, since I am still able to reproduce the problem, should we start considering alternative solutions to address this issue? |
|
@anjalirai-intel The fix is currently in progress:
Given this, I would still prefer for this to be fixed in Ubuntu 24.04. From my understanding, the fix is very close to be available in Ubuntu 24.04. |
|
There is duplicate bug reported here which have current status about the bug:
|
|
The bug is not being fixed as of yet, and the release date of Gramine v1.8 and GSC v1.8 is getting closer. I propose to continue with solutions 1 (pip install) or 2 (manual install) from here: #202 (comment) @woju What could you recommend? Maybe there's another solution to circumvent the bug in Ubuntu 24.04 with respect to this package? |
|
The "correct" thing to do from Python POV would be to package gsc as a Python distribution, then instruct people to install it (and it's requirements that can't be installed from Linux distro's package manager) into virtual environment (virtualenv or venv). "Correct" is scarequoted, because this would require full reorganisation of the repository and God forbid if someone would be packaging a Python app, then user will be dealing with two different venvs at the same time, and that would almost guarantee that people will confuse those (unless they'd have expert knowledge about what package goes where, which they probably don't have because gsc is meant to be easy). So people would do something like this: python3 -m venv --system-site-packages ./venv
./venv/bin/activate
pip3 install .
gsc ...There's also a hybrid approach that we can do right now: instruct people to get a venv, but run the script as we currectly do: python3 -m venv --system-site-packages ./venv
./venv/bin/activate
pip3 install 'docker>=6.1.0'
./gsc ...This will be also confusing to two kinds of people: 1) those who don't know python: wtf is venv; and 2) those who know python: why we don't install this package into venv. Of those available ways, I suggest in order: 1) We wait as long as possible for Ubuntu to release those packages. If they can't make it before we want to release gsc, then 2) for now write in README that people install docker-py into venv and run gsc from activated venv. That's the least amount of work for us. If someone objects against that and say they want to install gsc into venv, then 3) we reorganise the GSC repo. That'd be some work (mainly because we also need to package templates), but overall doable and not very complicated. Worse, it'd be yet more work downstream if someone maintains internal GSC fork because IDK, maybe they have some changes to the templates or something like that. |
|
Thanks @woju. The hybrid approach (where Python's venv inherits all system packages but only installs @anjalirai-intel @jkr0103 Could you test this approach? It should be enough to execute Woju's snippet to test it: If this indeed works fine, then I propose to add a section on |
|
If you add such a section, can you title it "... on Ubuntu 24.04 (and any recent distro compliant with PEP 668)"? It's not Ubuntu problem per se, eventually all distros (their recent versions) will need this or similar procedure. |
I feel users might miss it if we add it to the limitations section as it's towards the end of document, also this is still a temporary workaround until fix is upstreamed. |
@dimakuv We tried the venv experiment with Ubuntu 20.04 and Ubuntu 24.04 distro for bash workload, we were able to run the workloads, No issue seen with venv environment |
|
Just adding comment here, FWIW. We were eager to adopt 24.04. All our systems are provisioned via Ansible. The failure of a critical application using Docker SDK Python led me here. To workaround this issue I chose to use as minimal steps as necessary. Additionally, all of our Python libs are applied via apt (this now being an exception). With Ansible (ansible [core 2.16.8]): I'll be keeping a close eye on the status of this issue as we'll want to remove this workaround as soon as the proper Docker SDK Python version (docker>=6.1.0) is available via apt. Thanks for all the attention on this issue! |
TBH, with a properly packaged application, they would be able to install |
Fix is upstreamed now for nobel. We can take back the venv workaround pushed with PR#214 and instruct to do |
|
@jkr0103 Feel free to submit a corresponding PR. |
Description of the problem
gsc build fails for any distro workload on a Ubuntu 24.04 host system
As per gsc requirement
pip3 install docker jinja2 tomli tomli-w pyyamlwhen we try to install these libraries, it fails with below errors.Ubuntu adopted PEP 668 from 23.04 , which dictates that
pipcan no longer install packages managed by the distro's general-purpose package manager, hence we useapt-get. Above listed requirement are installed via apt, versions are mentioned belowdocker: 5.0.3
jinja2 : 3.1.2
tomli : 2.0.1
tomli-w : 1.0.0
pyyaml : 6.0.1
Steps to reproduce
https://github.com/gramineproject/gsc/tree/master/test#building-sample-images
Expected results
Actual results
Error:
The text was updated successfully, but these errors were encountered: