Hi All,
On a test environment using the `oc cluster up` command, I am unable
to deploy the ruby-ex example application. I am deploying on Fedora
24, using origin v1.3.
As you can see, the build succeeds, pushed the image and then
deployment times out.
$ oc logs bc/ruby-ex
Cloning "https://githu
Were there any logs from the ruby pod as it was being spun up? If you
trigger a new deployment:
oc deploy ruby-ex --latest
When you see a new ruby-ex-* pod get created (the one with the random
suffix) try checking the logs with
oc logs POD_NAME
To see if the app was failing to load.
O
On Tue, Sep 27, 2016 at 11:17 PM, Clayton Coleman wrote:
> oc logs POD_NAME
$ oc log ruby-ex-2-7ywo7
W0927 15:20:50.019027 17417 cmd.go:269] log is DEPRECATED and will
be removed in a future version. Use logs instead.
Error from server: container "ruby-ex" in pod "ruby-ex-2-7ywo7" is
waitin
You can run "oc get events" to see the message about pulling, but it's
possible that your machine can't pull from the registry that the image is
on. That could be a lot of things - if you're doing a build that pushed an
image to the internal registry, docker has to have --insecure-registry
set. I
Hi,
although the image was pushed during the build, it says: Failed to
pull image "172.30.165.95:5000/myproject/ruby-ex
Manually pulling gives:
$ docker pull 172.30.165.95:5000/myproject/ruby-ex:latest
Trying to pull repository 172.30.165.95:5000/myproject/ruby-ex ...
Pulling repository 172.30
Hi,
On Wed, Sep 28, 2016 at 9:00 AM, Gerard Braad wrote:
> Full output I posted here:
> https://gist.github.com/gbraad/e82edffb671a5dd154a939491514f7f8
Created an almost similar environment (using CentOS 7 1602 instead of
Fedora 24) and the same steps yield a working situation. It is most
likely
"Cannot overwrite digest
sha256:050a263ccf9db73bf688f22f7fdcb690d588dbd1cc8c5a7f50b461ef64dcc88d"
Why do we need to do this?
On Wed, Sep 28, 2016 at 10:02 AM, Gerard Braad wrote:
> Hi,
>
> On Wed, Sep 28, 2016 at 9:00 AM, Gerard Braad wrote:
> > Full output I posted here:
> > https://gist.gith
Gerard, were you on docker 1.8 and did you then upgrade to 1.9 or 1.10? I
recall a bug we had that sounds similar to what you're seeing here.
On Wednesday, September 28, 2016, Michail Kargakis
wrote:
> "Cannot overwrite digest sha256:050a263ccf9db73bf688f22f7fdcb6
> 90d588dbd1cc8c5a7f50b461ef64d
On Wed, Sep 28, 2016 at 6:50 PM, Andy Goldstein wrote:
> Gerard, were you on docker 1.8 and did you then upgrade to 1.9 or 1.10? I
> recall a bug we had that sounds similar to what you're seeing here.
I had not done an upgrade at all.
a clean cloud image install:
$ dnf install -y curl docker
$ d
Can you run this command:
sudo cat /var/lib/docker/image/devicemapper/repositories.json | python
-mjson.tool
and find the repository entry for 172.30.165.95:5000/myproject/ruby-ex.
Then find the entry for
http://172.30.165.95:5000/myproject/ruby-ex@sha256:df71f696941a9daa5daaea808cfcaaf72071d7ad2
On Wed, Sep 28, 2016 at 10:26 PM, Andy Goldstein wrote:
> sudo cat /var/lib/docker/image/devicemapper/repositories.json | python
> -mjson.tool
https://gist.github.com/gbraad/e82edffb671a5dd154a939491514f7f8#file-to-andy-goldstein-md
Currently recreating another environment. If you need access to
I just updated from docker 1.9 to docker 1.10 and can reproduce this issue.
I managed to deploy by using the RepoTags instead of the RepoDigest. Is
this a known issue in the sense that there is a fix to it or we can only
pull by tags?
On Wed, Sep 28, 2016 at 4:26 PM, Andy Goldstein wrote:
> Can
The data you pasted in the gist don't match the 172.30.165.95 IP. Are you
experiencing the same error message about overwriting the digest with the
data in the gist?
On Wed, Sep 28, 2016 at 10:50 AM, Gerard Braad wrote:
> On Wed, Sep 28, 2016 at 10:26 PM, Andy Goldstein
> wrote:
> > sudo cat /v
On Wed, Sep 28, 2016 at 10:55 PM, Andy Goldstein wrote:
> The data you pasted in the gist don't match the 172.30.165.95 IP. Are you
> experiencing the same error message about overwriting the digest with the
> data in the gist?
reproducible...
The IP is different because of successive `oc cluste
On Wed, Sep 28, 2016 at 10:56 PM, Michail Kargakis wrote:
> I just updated from docker 1.9 to docker 1.10 and can reproduce this issue.
> I managed to deploy by using the RepoTags instead of the RepoDigest. Is this
> a known issue in the sense that there is a fix to it or we can only pull by
> tag
You can work around this by pulling by tag instead of by hash. Try setting
{DOCKER-REGISTRY-IP}/myproject/ruby-ex:latest instead of
{DOCKER-REGISTRY-IP}/myproject/ruby-ex@sha256:... in your DC.
Not sure how pull by hash can be fixed though.
On Wed, Sep 28, 2016 at 5:08 PM, Gerard Braad wrote:
>
On Wed, Sep 28, 2016 at 11:22 PM, Michail Kargakis wrote:
> You can work around this by pulling by tag instead of by hash. Try setting
> {DOCKER-REGISTRY-IP}/myproject/ruby-ex:latest instead of
> {DOCKER-REGISTRY-IP}/myproject/ruby-ex@sha256:... in your DC.
> Not sure how pull by hash can be fixed
cc Seth, who has done some more investigation and will reply with an update.
Andy
On Wed, Sep 28, 2016 at 11:30 AM, Gerard Braad wrote:
> On Wed, Sep 28, 2016 at 11:22 PM, Michail Kargakis
> wrote:
> > You can work around this by pulling by tag instead of by hash. Try
> setting
> > {DOCKER-REG
Hey Gerard,
I also hit this issue this morning:
https://paste.fedoraproject.org/438222/51651371/
Seems that a recent change to docker (projectatomic/docker) introduced
a regression:
$ git describe
v1.10.3-95-g8b7fa4a
$ git log --oneline a612434.. | grep -i digest
8e24cc3 Merge pull request #194
On Fri, Sep 30, 2016 at 1:16 AM, Seth Jennings wrote:
> You can go to koji and downgrade to an old version (this is the one I used):
> http://koji.fedoraproject.org/koji/buildinfo?buildID=796377
Currently on C7, and waiting for a fix instead
> I've opened a bug to track this:
> https://bugzilla.
Same is reproducible on Atomic after an rpm-ostree upgrade
[fedora@atomic
openshift-origin-client-tools-v1.3.0-3ab7af3d097b57f933eccef684a714f2368804e7-linux-64bit]$
docker version
Client:
Version: 1.10.3
API version: 1.22
Package version: docker-1.10.3-52.git8b7fa4a.fc24.x86_64
G
21 matches
Mail list logo
