Bug 1470866 - RFE: Add ability to install RPMs from repositories
RFE: Add ability to install RPMs from repositories
Status: CLOSED UPSTREAM
Product: Red Hat Software Collections
Classification: Red Hat
Component: source-to-image (Show other bugs)
unspecified
All Linux
unspecified Severity unspecified
: ---
: 2.4
Assigned To: Tomas Hrcka
BaseOS QE - Apps
: FutureFeature
Depends On:
Blocks: 1479550
  Show dependency treegraph
 
Reported: 2017-07-13 17:18 EDT by Aleksandar Kostadinov
Modified: 2017-08-08 15:12 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1479550 (view as bug list)
Environment:
Last Closed: 2017-07-26 10:44:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2017-07-13 17:18:39 EDT
Description of problem:
Trying to create a python app using sti build but library is missing.

Version-Release number of selected component (if applicable):
2.7 and 3.5

How reproducible:
always

Steps to Reproduce:
1. oc new-app python:2.7~https://github.com/sopel-irc/sopel.git
2. oc new-app python:3.5~https://github.com/sopel-irc/sopel.git
3. oc new-app python:latest~https://github.com/sopel-irc/sopel.git

4. oc logs -f bc/sopel

Actual results:

  Sti build fails like:

> ---> Installing dependencies ...
> You are using pip version 7.1.0, however version 9.0.1 is available.
> You should consider upgrading via the 'pip install --upgrade pip' command.
> Collecting xmltodict (from -r requirements.txt (line 1))
> Downloading xmltodict-0.11.0-py2.py3-none-any.whl
> Collecting pytz (from -r requirements.txt (line 2))
> Downloading pytz-2017.2-py2.py3-none-any.whl (484kB)
> Collecting praw (from -r requirements.txt (line 3))
> Downloading praw-5.0.1-py2.py3-none-any.whl (86kB)
> Collecting pyenchant (from -r requirements.txt (line 4))
> Downloading pyenchant-1.6.8.tar.gz (63kB)
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
> File "<string>", line 20, in <module>
> File "/tmp/pip-build-qSAnGK/pyenchant/setup.py", line 210, in <module>
> import enchant
> File "enchant/__init__.py", line 92, in <module>
> from enchant import _enchant as _e
> File "enchant/_enchant.py", line 145, in <module>
> raise ImportError(msg)
> ImportError: The 'enchant' C library was not found. Please install it via your > OS package manager, or use a pre-built binary wheel from PyPI.
> ----------------------------------------
> Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-qSAnGK/pyenchant

Expected results:
build succeeds

Additional info:
I think there should be some mechanism to add additional packages for the builds, otherwise running python apps would be hit or miss.
Comment 2 Aleksandar Kostadinov 2017-07-14 18:44:29 EDT
The only thing needed to add to Dockerfile so that `sopel` build can work is the `enchant` RPM.
Comment 3 Lukas Zachar 2017-07-17 08:21:09 EDT
(In reply to Aleksandar Kostadinov from comment #0)
> Additional info:
> I think there should be some mechanism to add additional packages for the
> builds, otherwise running python apps would be hit or miss.

IMHO that is the right way. Otherwise we will end up with enormously big image which works only when we guessed right what is being used. 

Images should be as small as possible, right?
Comment 4 Aleksandar Kostadinov 2017-07-17 09:08:32 EDT
Shouldn't there be a sti mechanism to add additional packages when needed?

Would be hard for users to keep the sti image uptodate with security and other updates. It makes sense IMO to have the whole workflow automated. Otherwise users would stay outdated.
Comment 5 Tomas Orsava 2017-07-24 10:45:04 EDT
(In reply to Aleksandar Kostadinov from comment #4)
> Shouldn't there be a sti mechanism to add additional packages when needed?
> 
> Would be hard for users to keep the sti image uptodate with security and
> other updates. It makes sense IMO to have the whole workflow automated.
> Otherwise users would stay outdated.

There is an s2i mechanism to add additional Python packages through requirements.txt and similar. However, installing additional RPMs is a more complex issue and not currently covered by s2i to my knowledge. You can file a bug against s2i requesting that feature to be added.
Comment 6 Tomas Orsava 2017-07-24 10:52:18 EDT
Though it may be deemed that installing arbitrary RPMs is a feature outside the scope of s2i, in that case you might want to extend the image yourself instead.
Comment 7 Aleksandar Kostadinov 2017-07-24 11:17:16 EDT
I tried to explain earlier, that in online/dedicated one cannot have automatic builds with the docker strategy. Thus making the support of a sti builder image a manual process (or a process in an external infrastructure) which IMO misses the point of using OpenShift. If this sti builder management is not done right then user can be exposed to vulnerabilities if that sti builder image becomes outdated.

I'm ok if this bug is moved to the base sti component. But I can't see exactly which product/component should I choose.
Comment 8 Tomas Orsava 2017-07-25 05:28:15 EDT
There is a source-to-image component under both RHSCLs and Fedora products, so assigning to RHSCLs, please reassign if appropriate.
Comment 9 Joe Orton 2017-07-26 10:44:53 EDT
Please file RFEs upstream, we are just downstream packaging here, it doesn't make sense to track RFEs here.

https://github.com/openshift/source-to-image/issues
Comment 10 Aleksandar Kostadinov 2017-08-07 17:38:01 EDT
FYI https://github.com/openshift/source-to-image/issues/786

Note You need to log in before you can comment on or make changes to this bug.