Bug 1183973
Summary: | some dockerfiles are based on fedora:20 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jakub Dorňák <jdornak> |
Component: | fedora-dockerfiles | Assignee: | Aditya Patawari <adimania> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | adimania, emailscottcollier, hhorak, lmohanty, rpjday |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-02 07:40:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jakub Dorňák
2015-01-20 10:44:59 UTC
This is largely because these dockerfiles are tested on fedora 20 only. Perhaps some sort of CI would help us to test these files rapidly and update accordingly. I'll catch up with Scott and try to figure this out. @Aditya I have some experience in CI/Jenkins. Let me know if I can be of any help. (In reply to Lalatendu Mohanty from comment #2) > @Aditya I have some experience in CI/Jenkins. Let me know if I can be of any > help. Sure. Any help is welcomed. Scott has indicated that we may use Fedora's Jenkins setup for this but I want to do this locally before I do anything at Fedora Infra. Have a look at [1]. [1]: https://github.com/fedora-cloud/Fedora-Dockerfiles/issues/74 currently, 'fedora', 'fedora:latest' and 'fedora:21' all point to the f21 image. So, guess we just need to worry about fedora:20 if at all. I did wrote a script to build and test the containers but anything with 'fedora', 'fedora:latest' and 'fedora:21' is not working for me due to the bug here [1]. Right now the priority should be to fix this but I am not sure who should I catch. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1171928 It would seem time to update the sample Dockerfiles in this package if they're meant to actually be usable to build sample images. In the first place, I believe Fedora 20 was already EOLed back in June, so it seems pointless to use that as the basis for sample Dockerfiles, especially since trying it produces: ===== start ===== $ sudo docker build -t rday/apache . Sending build context to Docker daemon 23.55 kB Step 0 : FROM fedora:20 ---> 1b48ab88a33e Step 1 : MAINTAINER http://fedoraproject.org/wiki/Cloud ---> Using cache ---> 66b6495307a4 Step 2 : RUN yum -y update && yum clean all ---> Running in 23e4fd6a05c5 One of the configured repositories failed (Fedora 20 - x86_64), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Disable the repository, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable fedora 4. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=fedora.skip_if_unavailable=true Cannot retrieve metalink for repository: fedora/20/x86_64. Please verify its path and try again The command '/bin/sh -c yum -y update && yum clean all' returned a non-zero code: 1 $ ===== end ===== Since the current Docker hub version seems to be Fedora 21, edit the sample apache Dockerfile to reflect that and try again: ===== start ===== $ sudo docker build -t rday/apache . Sending build context to Docker daemon 23.55 kB Step 0 : FROM fedora:21 Trying to pull repository docker.io/library/fedora ... 21: Pulling from library/fedora e26efd418c48: Pull complete 48ecf305d2cf: Already exists Digest: sha256:53c673185c86cf2b8ef774d6fa59391a3728005abaccf1320a7a0ab8b5f4361f Status: Downloaded newer image for docker.io/fedora:21 ---> e26efd418c48 Step 1 : MAINTAINER http://fedoraproject.org/wiki/Cloud ---> Running in b55dcae20e36 ---> 93a00fff41f5 Removing intermediate container b55dcae20e36 Step 2 : RUN yum -y update && yum clean all ---> Running in 9b0117a776fc One of the configured repositories failed (Fedora 21 - x86_64), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Disable the repository, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable fedora 4. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=fedora.skip_if_unavailable=true Cannot retrieve metalink for repository: fedora/21/x86_64. Please verify its path and try again The command '/bin/sh -c yum -y update && yum clean all' returned a non-zero code: 1 $ ===== end ===== So that didn't seem much more successful. One more shot, with Fedora 22: ===== start ===== $ sudo docker build -t rday/apache . Sending build context to Docker daemon 23.55 kB Step 0 : FROM fedora:22 ---> ded7cd95e059 Step 1 : MAINTAINER http://fedoraproject.org/wiki/Cloud ---> Using cache ---> e076c40756a4 Step 2 : RUN yum -y update && yum clean all ---> Running in d866320158f7 Yum command has been deprecated, redirecting to '/usr/bin/dnf -y update'. See 'man dnf' and 'man yum2dnf' for more information. To transfer transaction metadata from yum to DNF, run: 'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate' Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-22&arch=x86_64': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-22&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org] The command '/bin/sh -c yum -y update && yum clean all' returned a non-zero code: 1 $ ===== end ===== So, at the moment, those Dockerfiles don't seem buildable from. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |