Re: configuring periodic import of images

[Tony Saxon]

So I got it working, and I'm trying to figure out why what I did worked.

I took a closer look at the packet captures where I saw what I thought was
the polling. It wasn't actually good traffic, but rather the master
thinking that it had a connection open to the registry server. Checking
netstat on both machines showed an open connection on the master, but
nothing on the registry server. I then restarted the master while taking a
capture. This showed it trying to close the open connection and just
getting rst packets. After restarting it I didn't see any traffic to the
docker registry at all. I took a closer look at my master config file.
Originally it did not have a section in it for the imagePolicyConfig. After
being given the information from Clayton earlier about that section I added
it. Since I wasn't seeing the traffic, I changed the
scheduledImageImportMinimumIntervalSeconds to 30 instead of 900. After
restarting it again, it pulled down the image without issue.

As a final test I changed the code, rebuilt the app and docker image and
repushed it to the repository. Within 30 seconds it was detected, pulled
and started deploying.

On Tue, Aug 16, 2016 at 4:36 PM, Tony Saxon  wrote:

> Ok, I ran a packet capture on both the master and the docker registry and
> I see periodic traffic from the master to the docker container on port
> 5000. It's about every 30 seconds or so, so I'm assuming that it's the
> periodic polling. It doesn't appear that it's picking up a difference
> between the registry and the imagestream.
>
> However if I perform another 'oc tag' command, it updates the imagestream
> and pulls down the latest tag and deploys to the application.
>
> On Tue, Aug 16, 2016 at 3:29 PM, Clayton Coleman 
> wrote:
>
>> Yes, scheduled=true will poll the upstream registry.
>>
>> On Tue, Aug 16, 2016 at 1:59 PM, Tony Saxon  wrote:
>>
>>> Ok, that makes sense. But I am understanding correctly that when you use
>>> scheduled=true that it should periodically poll the source registry and
>>> pull the latest tag configured if it's newer than what is currently pulled?
>>>
>>> On Tue, Aug 16, 2016 at 1:48 PM, Clayton Coleman 
>>> wrote:
>>>


 On Aug 16, 2016, at 1:40 PM, Tony Saxon  wrote:

 Can someone tell me if I'm understanding the difference between
 alias=true and scheduled=true for tagging imagestreams as documented at
 https://docs.openshift.org/latest/dev_guide/managing_images.
 html#adding-tag ?

 The way I read it is that alias true will track the source image tag
 and update the destination when the source is updated, whereas scheduled
 does the same thing but only on a periodic basis. Am I off on that?


 Alias simply points to the destination, and will *not* update when the
 destination changes.  Ie "a:latest" points to "b:1.0" - updating "b:1.0"
 only triggers deployments based on b:1.0.  A deployment created from
 "a:latest" will use "b:1:0" in its pods.

 Alias is really when you want to drive Openshift based on external
 versioned tags in another repo (my:latest updating from MySQL:5.1,
 MySQL:5.2, etc).



 On Mon, Aug 15, 2016 at 4:04 PM, Tony Saxon 
 wrote:

> I'm using a registry deployed from a docker compose:
>
> registry:
>   restart: always
>   image: registry:2.2.1
>   ports:
> - 5000:5000
>   environment:
> REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
> REGISTRY_HTTP_TLS_KEY: /certs/domain.key
> REGISTRY_AUTH: htpasswd
> REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
> REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
>   volumes:
> - /var/docker/registry/data:/var/lib/registry
> - /var/docker/registry/certs:/certs
> - /var/docker/registry/auth:/auth
>
>
> It was originally using "image:2" but that was the one that I had
> problems even importing the docker imaged due to the schema v1/v2 issue.
> After changing it to 2.2.1 and repushing the image it worked.
>
> On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
> wrote:
>
>> Did a test, but the import looks like it works correctly for hub
>> images.  In this case are you using a regular Docker registry, the
>> integrated registry, or a third party Docker registry?
>>
>> On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman > > wrote:
>>
>>> It's currently 15 minutes:
>>>
>>> imagePolicyConfig:
>>>   disableScheduledImport: false
>>>   maxImagesBulkImportedPerRepository: 5
>>>   maxScheduledImageImportsPerMinute: 60
>>>   scheduledImageImportMinimumIntervalSeconds: 900
>>>
>>> Will take a look and see if I can recreate this issue.
>>>
>>>
>>> On 

Re: configuring periodic import of images

[Tony Saxon]

Ok, I ran a packet capture on both the master and the docker registry and I
see periodic traffic from the master to the docker container on port 5000.
It's about every 30 seconds or so, so I'm assuming that it's the periodic
polling. It doesn't appear that it's picking up a difference between the
registry and the imagestream.

However if I perform another 'oc tag' command, it updates the imagestream
and pulls down the latest tag and deploys to the application.

On Tue, Aug 16, 2016 at 3:29 PM, Clayton Coleman 
wrote:

> Yes, scheduled=true will poll the upstream registry.
>
> On Tue, Aug 16, 2016 at 1:59 PM, Tony Saxon  wrote:
>
>> Ok, that makes sense. But I am understanding correctly that when you use
>> scheduled=true that it should periodically poll the source registry and
>> pull the latest tag configured if it's newer than what is currently pulled?
>>
>> On Tue, Aug 16, 2016 at 1:48 PM, Clayton Coleman 
>> wrote:
>>
>>>
>>>
>>> On Aug 16, 2016, at 1:40 PM, Tony Saxon  wrote:
>>>
>>> Can someone tell me if I'm understanding the difference between
>>> alias=true and scheduled=true for tagging imagestreams as documented at
>>> https://docs.openshift.org/latest/dev_guide/managing_images.
>>> html#adding-tag ?
>>>
>>> The way I read it is that alias true will track the source image tag and
>>> update the destination when the source is updated, whereas scheduled does
>>> the same thing but only on a periodic basis. Am I off on that?
>>>
>>>
>>> Alias simply points to the destination, and will *not* update when the
>>> destination changes.  Ie "a:latest" points to "b:1.0" - updating "b:1.0"
>>> only triggers deployments based on b:1.0.  A deployment created from
>>> "a:latest" will use "b:1:0" in its pods.
>>>
>>> Alias is really when you want to drive Openshift based on external
>>> versioned tags in another repo (my:latest updating from MySQL:5.1,
>>> MySQL:5.2, etc).
>>>
>>>
>>>
>>> On Mon, Aug 15, 2016 at 4:04 PM, Tony Saxon 
>>> wrote:
>>>
 I'm using a registry deployed from a docker compose:

 registry:
   restart: always
   image: registry:2.2.1
   ports:
 - 5000:5000
   environment:
 REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
 REGISTRY_HTTP_TLS_KEY: /certs/domain.key
 REGISTRY_AUTH: htpasswd
 REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
 REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
   volumes:
 - /var/docker/registry/data:/var/lib/registry
 - /var/docker/registry/certs:/certs
 - /var/docker/registry/auth:/auth


 It was originally using "image:2" but that was the one that I had
 problems even importing the docker imaged due to the schema v1/v2 issue.
 After changing it to 2.2.1 and repushing the image it worked.

 On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
 wrote:

> Did a test, but the import looks like it works correctly for hub
> images.  In this case are you using a regular Docker registry, the
> integrated registry, or a third party Docker registry?
>
> On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
> wrote:
>
>> It's currently 15 minutes:
>>
>> imagePolicyConfig:
>>   disableScheduledImport: false
>>   maxImagesBulkImportedPerRepository: 5
>>   maxScheduledImageImportsPerMinute: 60
>>   scheduledImageImportMinimumIntervalSeconds: 900
>>
>> Will take a look and see if I can recreate this issue.
>>
>>
>> On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon 
>> wrote:
>>
>>>
>>> So I've found that if I tag the imagestream manually, that it is
>>> able to pull down the latest changes and deploys them to my app:
>>>
>>> oc tag --source=docker --scheduled=true
>>> docker-lab.example.com:5000/testwebapp:latest testwebapp:latest
>>>
>>> [root@os-master ~]# oc describe is
>>> Name:   testwebapp
>>> Created:4 days ago
>>> Labels: 
>>> Annotations:openshift.io/image.dockerRepos
>>> itoryCheck=2016-08-15T17:49:36Z
>>> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>>>
>>> Tag Spec
>>> Created PullSpec
>>>   Image
>>> latest  docker-lab.example.com:5000/testwebapp:latest *38
>>> minutes ago  docker-lab.example.com:5000/te
>>> stwebapp@sha256:dd75ff58184489...
>>>
>>> About an hour ago   docker-lab.example.com:5000/te
>>> stwebapp@sha256:2a4f9e1262e377...
>>> 4
>>> days ago  docker-lab.example.com:5000/te
>>> stwebapp@sha256:c1c8c6c3e1c672...
>>>

Re: configuring periodic import of images

[Clayton Coleman]

Yes, scheduled=true will poll the upstream registry.

On Tue, Aug 16, 2016 at 1:59 PM, Tony Saxon  wrote:

> Ok, that makes sense. But I am understanding correctly that when you use
> scheduled=true that it should periodically poll the source registry and
> pull the latest tag configured if it's newer than what is currently pulled?
>
> On Tue, Aug 16, 2016 at 1:48 PM, Clayton Coleman 
> wrote:
>
>>
>>
>> On Aug 16, 2016, at 1:40 PM, Tony Saxon  wrote:
>>
>> Can someone tell me if I'm understanding the difference between
>> alias=true and scheduled=true for tagging imagestreams as documented at
>> https://docs.openshift.org/latest/dev_guide/managing_images.
>> html#adding-tag ?
>>
>> The way I read it is that alias true will track the source image tag and
>> update the destination when the source is updated, whereas scheduled does
>> the same thing but only on a periodic basis. Am I off on that?
>>
>>
>> Alias simply points to the destination, and will *not* update when the
>> destination changes.  Ie "a:latest" points to "b:1.0" - updating "b:1.0"
>> only triggers deployments based on b:1.0.  A deployment created from
>> "a:latest" will use "b:1:0" in its pods.
>>
>> Alias is really when you want to drive Openshift based on external
>> versioned tags in another repo (my:latest updating from MySQL:5.1,
>> MySQL:5.2, etc).
>>
>>
>>
>> On Mon, Aug 15, 2016 at 4:04 PM, Tony Saxon  wrote:
>>
>>> I'm using a registry deployed from a docker compose:
>>>
>>> registry:
>>>   restart: always
>>>   image: registry:2.2.1
>>>   ports:
>>> - 5000:5000
>>>   environment:
>>> REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
>>> REGISTRY_HTTP_TLS_KEY: /certs/domain.key
>>> REGISTRY_AUTH: htpasswd
>>> REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
>>> REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
>>>   volumes:
>>> - /var/docker/registry/data:/var/lib/registry
>>> - /var/docker/registry/certs:/certs
>>> - /var/docker/registry/auth:/auth
>>>
>>>
>>> It was originally using "image:2" but that was the one that I had
>>> problems even importing the docker imaged due to the schema v1/v2 issue.
>>> After changing it to 2.2.1 and repushing the image it worked.
>>>
>>> On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
>>> wrote:
>>>
 Did a test, but the import looks like it works correctly for hub
 images.  In this case are you using a regular Docker registry, the
 integrated registry, or a third party Docker registry?

 On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
 wrote:

> It's currently 15 minutes:
>
> imagePolicyConfig:
>   disableScheduledImport: false
>   maxImagesBulkImportedPerRepository: 5
>   maxScheduledImageImportsPerMinute: 60
>   scheduledImageImportMinimumIntervalSeconds: 900
>
> Will take a look and see if I can recreate this issue.
>
>
> On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon 
> wrote:
>
>>
>> So I've found that if I tag the imagestream manually, that it is able
>> to pull down the latest changes and deploys them to my app:
>>
>> oc tag --source=docker --scheduled=true
>> docker-lab.example.com:5000/testwebapp:latest testwebapp:latest
>>
>> [root@os-master ~]# oc describe is
>> Name:   testwebapp
>> Created:4 days ago
>> Labels: 
>> Annotations:openshift.io/image.dockerRepos
>> itoryCheck=2016-08-15T17:49:36Z
>> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>>
>> Tag Spec
>> Created PullSpec
>>   Image
>> latest  docker-lab.example.com:5000/testwebapp:latest *38
>> minutes ago  docker-lab.example.com:5000/te
>> stwebapp@sha256:dd75ff58184489...
>>
>> About an hour ago   docker-lab.example.com:5000/te
>> stwebapp@sha256:2a4f9e1262e377...
>> 4
>> days ago  docker-lab.example.com:5000/te
>> stwebapp@sha256:c1c8c6c3e1c672...
>>
>>   * tag is scheduled for periodic import
>>   ! tag is insecure and can be imported over HTTP or self-signed HTTPS
>>
>>
>> This updates the tags, redeploys the pods and all my new changes are
>> visible once the new containers are up. It appears that it's not doing 
>> the
>> periodic import despite being configured to. What is the default period
>> that it uses to check the source registry?
>>
>>
>> On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon 
>> wrote:
>>
>>> So I've found that if I tag the imagestream manually, that it is
>>> able to pull down the latest changes and 

Re: configuring periodic import of images

[Tony Saxon]

Ok, that makes sense. But I am understanding correctly that when you use
scheduled=true that it should periodically poll the source registry and
pull the latest tag configured if it's newer than what is currently pulled?

On Tue, Aug 16, 2016 at 1:48 PM, Clayton Coleman 
wrote:

>
>
> On Aug 16, 2016, at 1:40 PM, Tony Saxon  wrote:
>
> Can someone tell me if I'm understanding the difference between alias=true
> and scheduled=true for tagging imagestreams as documented at
> https://docs.openshift.org/latest/dev_guide/managing_
> images.html#adding-tag ?
>
> The way I read it is that alias true will track the source image tag and
> update the destination when the source is updated, whereas scheduled does
> the same thing but only on a periodic basis. Am I off on that?
>
>
> Alias simply points to the destination, and will *not* update when the
> destination changes.  Ie "a:latest" points to "b:1.0" - updating "b:1.0"
> only triggers deployments based on b:1.0.  A deployment created from
> "a:latest" will use "b:1:0" in its pods.
>
> Alias is really when you want to drive Openshift based on external
> versioned tags in another repo (my:latest updating from MySQL:5.1,
> MySQL:5.2, etc).
>
>
>
> On Mon, Aug 15, 2016 at 4:04 PM, Tony Saxon  wrote:
>
>> I'm using a registry deployed from a docker compose:
>>
>> registry:
>>   restart: always
>>   image: registry:2.2.1
>>   ports:
>> - 5000:5000
>>   environment:
>> REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
>> REGISTRY_HTTP_TLS_KEY: /certs/domain.key
>> REGISTRY_AUTH: htpasswd
>> REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
>> REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
>>   volumes:
>> - /var/docker/registry/data:/var/lib/registry
>> - /var/docker/registry/certs:/certs
>> - /var/docker/registry/auth:/auth
>>
>>
>> It was originally using "image:2" but that was the one that I had
>> problems even importing the docker imaged due to the schema v1/v2 issue.
>> After changing it to 2.2.1 and repushing the image it worked.
>>
>> On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
>> wrote:
>>
>>> Did a test, but the import looks like it works correctly for hub
>>> images.  In this case are you using a regular Docker registry, the
>>> integrated registry, or a third party Docker registry?
>>>
>>> On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
>>> wrote:
>>>
 It's currently 15 minutes:

 imagePolicyConfig:
   disableScheduledImport: false
   maxImagesBulkImportedPerRepository: 5
   maxScheduledImageImportsPerMinute: 60
   scheduledImageImportMinimumIntervalSeconds: 900

 Will take a look and see if I can recreate this issue.


 On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon 
 wrote:

>
> So I've found that if I tag the imagestream manually, that it is able
> to pull down the latest changes and deploys them to my app:
>
> oc tag --source=docker --scheduled=true docker-lab.example.com:5000/te
> stwebapp:latest testwebapp:latest
>
> [root@os-master ~]# oc describe is
> Name:   testwebapp
> Created:4 days ago
> Labels: 
> Annotations:openshift.io/image.dockerRepos
> itoryCheck=2016-08-15T17:49:36Z
> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>
> Tag Spec
> Created PullSpec
>   Image
> latest  docker-lab.example.com:5000/testwebapp:latest *38
> minutes ago  docker-lab.example.com:5000/te
> stwebapp@sha256:dd75ff58184489...
> About
> an hour ago   docker-lab.example.com:5000/te
> stwebapp@sha256:2a4f9e1262e377...
> 4
> days ago  docker-lab.example.com:5000/te
> stwebapp@sha256:c1c8c6c3e1c672...
>
>   * tag is scheduled for periodic import
>   ! tag is insecure and can be imported over HTTP or self-signed HTTPS
>
>
> This updates the tags, redeploys the pods and all my new changes are
> visible once the new containers are up. It appears that it's not doing the
> periodic import despite being configured to. What is the default period
> that it uses to check the source registry?
>
>
> On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon 
> wrote:
>
>> So I've found that if I tag the imagestream manually, that it is able
>> to pull down the latest changes and deploys them to my app:
>>
>> On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon 
>> wrote:
>>
>>> There are logs showing that it's detecting that the imagestream has

Re: configuring periodic import of images

[Tony Saxon]

Can someone tell me if I'm understanding the difference between alias=true
and scheduled=true for tagging imagestreams as documented at
https://docs.openshift.org/latest/dev_guide/managing_images.html#adding-tag
?

The way I read it is that alias true will track the source image tag and
update the destination when the source is updated, whereas scheduled does
the same thing but only on a periodic basis. Am I off on that?

On Mon, Aug 15, 2016 at 4:04 PM, Tony Saxon  wrote:

> I'm using a registry deployed from a docker compose:
>
> registry:
>   restart: always
>   image: registry:2.2.1
>   ports:
> - 5000:5000
>   environment:
> REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
> REGISTRY_HTTP_TLS_KEY: /certs/domain.key
> REGISTRY_AUTH: htpasswd
> REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
> REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
>   volumes:
> - /var/docker/registry/data:/var/lib/registry
> - /var/docker/registry/certs:/certs
> - /var/docker/registry/auth:/auth
>
>
> It was originally using "image:2" but that was the one that I had problems
> even importing the docker imaged due to the schema v1/v2 issue. After
> changing it to 2.2.1 and repushing the image it worked.
>
> On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
> wrote:
>
>> Did a test, but the import looks like it works correctly for hub images.
>> In this case are you using a regular Docker registry, the integrated
>> registry, or a third party Docker registry?
>>
>> On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
>> wrote:
>>
>>> It's currently 15 minutes:
>>>
>>> imagePolicyConfig:
>>>   disableScheduledImport: false
>>>   maxImagesBulkImportedPerRepository: 5
>>>   maxScheduledImageImportsPerMinute: 60
>>>   scheduledImageImportMinimumIntervalSeconds: 900
>>>
>>> Will take a look and see if I can recreate this issue.
>>>
>>>
>>> On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon 
>>> wrote:
>>>

 So I've found that if I tag the imagestream manually, that it is able
 to pull down the latest changes and deploys them to my app:

 oc tag --source=docker --scheduled=true docker-lab.example.com:5000/te
 stwebapp:latest testwebapp:latest

 [root@os-master ~]# oc describe is
 Name:   testwebapp
 Created:4 days ago
 Labels: 
 Annotations:openshift.io/image.dockerRepos
 itoryCheck=2016-08-15T17:49:36Z
 Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp

 Tag Spec
 Created PullSpec
   Image
 latest  docker-lab.example.com:5000/testwebapp:latest *38
 minutes ago  docker-lab.example.com:5000/te
 stwebapp@sha256:dd75ff58184489...
 About
 an hour ago   docker-lab.example.com:5000/te
 stwebapp@sha256:2a4f9e1262e377...
 4 days
 ago  docker-lab.example.com:5000/te
 stwebapp@sha256:c1c8c6c3e1c672...

   * tag is scheduled for periodic import
   ! tag is insecure and can be imported over HTTP or self-signed HTTPS


 This updates the tags, redeploys the pods and all my new changes are
 visible once the new containers are up. It appears that it's not doing the
 periodic import despite being configured to. What is the default period
 that it uses to check the source registry?


 On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon 
 wrote:

> So I've found that if I tag the imagestream manually, that it is able
> to pull down the latest changes and deploys them to my app:
>
> On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon 
> wrote:
>
>> There are logs showing that it's detecting that the imagestream has
>> changed, but doesn't seem like there's any explanation of why it can't 
>> get
>> it:
>>
>> Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822
>> 77042 image_change_controller.go:47] Build image change controller 
>> detected
>> ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
>> Aug 15 08:20:01 os-master origin-master:
>> ation":2}]},{"tag":"8.1","items":[{"created":"2016-08-02T18:
>> 21:31Z","dockerImageReference":"openshift/wildfly-81-centos7
>> @sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf
>> 704a0f651f96","image":"sha256:68a27d407fd1ead3b8a9e33aa2054c
>> 948ad3a54556d28bb4caaf704a0f651f96","generation":2}]},{"tag"
>> :"9.0","items":[{"created":"2016-08-02T18:21:31Z","dockerIma
>> geReference":"openshift/wildfly-90-centos7@sha256:212d8e093d
>> 

Re: configuring periodic import of images

[Tony Saxon]

I'm using a registry deployed from a docker compose:

registry:
  restart: always
  image: registry:2.2.1
  ports:
- 5000:5000
  environment:
REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
REGISTRY_HTTP_TLS_KEY: /certs/domain.key
REGISTRY_AUTH: htpasswd
REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
  volumes:
- /var/docker/registry/data:/var/lib/registry
- /var/docker/registry/certs:/certs
- /var/docker/registry/auth:/auth


It was originally using "image:2" but that was the one that I had problems
even importing the docker imaged due to the schema v1/v2 issue. After
changing it to 2.2.1 and repushing the image it worked.

On Mon, Aug 15, 2016 at 4:00 PM, Clayton Coleman 
wrote:

> Did a test, but the import looks like it works correctly for hub images.
> In this case are you using a regular Docker registry, the integrated
> registry, or a third party Docker registry?
>
> On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
> wrote:
>
>> It's currently 15 minutes:
>>
>> imagePolicyConfig:
>>   disableScheduledImport: false
>>   maxImagesBulkImportedPerRepository: 5
>>   maxScheduledImageImportsPerMinute: 60
>>   scheduledImageImportMinimumIntervalSeconds: 900
>>
>> Will take a look and see if I can recreate this issue.
>>
>>
>> On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon  wrote:
>>
>>>
>>> So I've found that if I tag the imagestream manually, that it is able to
>>> pull down the latest changes and deploys them to my app:
>>>
>>> oc tag --source=docker --scheduled=true docker-lab.example.com:5000/te
>>> stwebapp:latest testwebapp:latest
>>>
>>> [root@os-master ~]# oc describe is
>>> Name:   testwebapp
>>> Created:4 days ago
>>> Labels: 
>>> Annotations:openshift.io/image.dockerRepos
>>> itoryCheck=2016-08-15T17:49:36Z
>>> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>>>
>>> Tag Spec
>>> Created PullSpec
>>>   Image
>>> latest  docker-lab.example.com:5000/testwebapp:latest *38
>>> minutes ago  docker-lab.example.com:5000/te
>>> stwebapp@sha256:dd75ff58184489...
>>> About
>>> an hour ago   docker-lab.example.com:5000/te
>>> stwebapp@sha256:2a4f9e1262e377...
>>> 4 days
>>> ago  docker-lab.example.com:5000/te
>>> stwebapp@sha256:c1c8c6c3e1c672...
>>>
>>>   * tag is scheduled for periodic import
>>>   ! tag is insecure and can be imported over HTTP or self-signed HTTPS
>>>
>>>
>>> This updates the tags, redeploys the pods and all my new changes are
>>> visible once the new containers are up. It appears that it's not doing the
>>> periodic import despite being configured to. What is the default period
>>> that it uses to check the source registry?
>>>
>>>
>>> On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon 
>>> wrote:
>>>
 So I've found that if I tag the imagestream manually, that it is able
 to pull down the latest changes and deploys them to my app:

 On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon 
 wrote:

> There are logs showing that it's detecting that the imagestream has
> changed, but doesn't seem like there's any explanation of why it can't get
> it:
>
> Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822   77042
> image_change_controller.go:47] Build image change controller detected
> ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
> Aug 15 08:20:01 os-master origin-master: ation":2}]},{"tag":"8.1","item
> s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
> :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead3b8a9e3
> 3aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:
> 68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f65
> 1f96","generation":2}]},{"tag":"9.0","items":[{"created":"20
> 16-08-02T18:21:31Z","dockerImageReference":"openshift/wildfl
> y-90-centos7@sha256:212d8e093d50b44cf8dd3101d22e7efce6293d74
> 1a6dc30fced9cd27b70c7c22","image":"sha256:212d8e093d50b44
> cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","generati
> on":2}]},{"tag":"latest","items":[{"created":"2016-08-02T18:
> 21:31Z","dockerImageReference":"openshift/wildfly-100-centos7@sha256
> :5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c2bb895
> edda89cabbb3d","image":"sha256:5a428b5b36d4cd98dce8603d5accb
> 30ff014b7d4fb73c2bb895edda89cabbb3d","generation":2}]}]}},{"
> metadata":{"name":"testwebapp","namespace":"testwebapp","
> selfLink":"/oapi/v1/namespaces/testwebapp/imagestr
> eams/testwebapp","uid":"dae5b8d1-5fc3-11e6-88da-525400f41cdb
> 

Re: configuring periodic import of images

[Clayton Coleman]

Did a test, but the import looks like it works correctly for hub images.
In this case are you using a regular Docker registry, the integrated
registry, or a third party Docker registry?

On Mon, Aug 15, 2016 at 3:34 PM, Clayton Coleman 
wrote:

> It's currently 15 minutes:
>
> imagePolicyConfig:
>   disableScheduledImport: false
>   maxImagesBulkImportedPerRepository: 5
>   maxScheduledImageImportsPerMinute: 60
>   scheduledImageImportMinimumIntervalSeconds: 900
>
> Will take a look and see if I can recreate this issue.
>
>
> On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon  wrote:
>
>>
>> So I've found that if I tag the imagestream manually, that it is able to
>> pull down the latest changes and deploys them to my app:
>>
>> oc tag --source=docker --scheduled=true docker-lab.example.com:5000/te
>> stwebapp:latest testwebapp:latest
>>
>> [root@os-master ~]# oc describe is
>> Name:   testwebapp
>> Created:4 days ago
>> Labels: 
>> Annotations:openshift.io/image.dockerRepos
>> itoryCheck=2016-08-15T17:49:36Z
>> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>>
>> Tag Spec
>> Created PullSpec
>>   Image
>> latest  docker-lab.example.com:5000/testwebapp:latest *38
>> minutes ago  docker-lab.example.com:5000/te
>> stwebapp@sha256:dd75ff58184489...
>> About an
>> hour ago   docker-lab.example.com:5000/te
>> stwebapp@sha256:2a4f9e1262e377...
>> 4 days
>> ago  docker-lab.example.com:5000/te
>> stwebapp@sha256:c1c8c6c3e1c672...
>>
>>   * tag is scheduled for periodic import
>>   ! tag is insecure and can be imported over HTTP or self-signed HTTPS
>>
>>
>> This updates the tags, redeploys the pods and all my new changes are
>> visible once the new containers are up. It appears that it's not doing the
>> periodic import despite being configured to. What is the default period
>> that it uses to check the source registry?
>>
>>
>> On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon  wrote:
>>
>>> So I've found that if I tag the imagestream manually, that it is able to
>>> pull down the latest changes and deploys them to my app:
>>>
>>> On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon 
>>> wrote:
>>>
 There are logs showing that it's detecting that the imagestream has
 changed, but doesn't seem like there's any explanation of why it can't get
 it:

 Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822   77042
 image_change_controller.go:47] Build image change controller detected
 ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
 Aug 15 08:20:01 os-master origin-master: ation":2}]},{"tag":"8.1","item
 s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
 :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead3b8a9e3
 3aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:
 68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f65
 1f96","generation":2}]},{"tag":"9.0","items":[{"created":"20
 16-08-02T18:21:31Z","dockerImageReference":"openshift/
 wildfly-90-centos7@sha256:212d8e093d50b44cf8dd3101d22e7efce6
 293d741a6dc30fced9cd27b70c7c22","image":"sha256:212d8e093d50
 b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","gener
 ation":2}]},{"tag":"latest","items":[{"created":"2016-08-
 02T18:21:31Z","dockerImageReference":"openshift/wildfly-100-
 centos7@sha256:5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c
 2bb895edda89cabbb3d","image":"sha256:5a428b5b36d4cd98dce8603
 d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","generation":2}]}
 ]}},{"metadata":{"name":"testwebapp","namespace":"
 testwebapp","selfLink":"/oapi/v1/namespaces/testwebapp/image
 streams/testwebapp","uid":"dae5b8d1-5fc3-11e6-88da-525400
 f41cdb","resourceVersion":"359311","generation":2,"creati
 onTimestamp":"2016-08-11T13:02:27Z","annotations":{"opensh
 ift.io/image.dockerRepositoryCheck":"2016-08-11T13:02:27Z"}}
 ,"spec":{"tags":[{"name":"latest","annotations":null,"
 from":{"kind":"DockerImage","name":"docker-lab.example.com:
 5000/testwebapp:latest"},"generation":1,"importPolicy":{
 "scheduled":true}}]},"status":{"dockerImageRepository":"172.
 30.11.167:5000/testwebapp/testwebapp","tags":[{"tag":"
 latest","items":[{"created":"2016-08-11T13:02:27Z","
 dockerImageReference":"docker-lab.example.com:5000/testwebap
 p@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf
 9044f3af06074","image":"sha256:c1c8c6c3e1c6729d1366aca
 f54c9772b4849f35d971e73449cf9044f3af06074","generation":1}]}]}}]}
 Aug 15 08:22:00 os-master origin-master: ation":2}]},{"tag":"8.1","item
 

Re: configuring periodic import of images

[Clayton Coleman]

It's currently 15 minutes:

imagePolicyConfig:
  disableScheduledImport: false
  maxImagesBulkImportedPerRepository: 5
  maxScheduledImageImportsPerMinute: 60
  scheduledImageImportMinimumIntervalSeconds: 900

Will take a look and see if I can recreate this issue.


On Mon, Aug 15, 2016 at 2:33 PM, Tony Saxon  wrote:

>
> So I've found that if I tag the imagestream manually, that it is able to
> pull down the latest changes and deploys them to my app:
>
> oc tag --source=docker --scheduled=true docker-lab.example.com:5000/
> testwebapp:latest testwebapp:latest
>
> [root@os-master ~]# oc describe is
> Name:   testwebapp
> Created:4 days ago
> Labels: 
> Annotations:openshift.io/image.dockerRepositoryCheck=2016-08-
> 15T17:49:36Z
> Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp
>
> Tag Spec
> Created PullSpec
>   Image
> latest  docker-lab.example.com:5000/testwebapp:latest *38 minutes
> ago  docker-lab.example.com:5000/testwebapp@sha256:dd75ff58184489...
> 
> About an
> hour ago   docker-lab.example.com:5000/testwebapp@sha256:
> 2a4f9e1262e377...
> 4 days
> ago  docker-lab.example.com:5000/testwebapp@sha256:
> c1c8c6c3e1c672...
>
>   * tag is scheduled for periodic import
>   ! tag is insecure and can be imported over HTTP or self-signed HTTPS
>
>
> This updates the tags, redeploys the pods and all my new changes are
> visible once the new containers are up. It appears that it's not doing the
> periodic import despite being configured to. What is the default period
> that it uses to check the source registry?
>
>
> On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon  wrote:
>
>> So I've found that if I tag the imagestream manually, that it is able to
>> pull down the latest changes and deploys them to my app:
>>
>> On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon  wrote:
>>
>>> There are logs showing that it's detecting that the imagestream has
>>> changed, but doesn't seem like there's any explanation of why it can't get
>>> it:
>>>
>>> Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822   77042
>>> image_change_controller.go:47] Build image change controller detected
>>> ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
>>> Aug 15 08:20:01 os-master origin-master: ation":2}]},{"tag":"8.1","item
>>> s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
>>> :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead3b8a9e3
>>> 3aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:
>>> 68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f65
>>> 1f96","generation":2}]},{"tag":"9.0","items":[{"created":"
>>> 2016-08-02T18:21:31Z","dockerImageReference":"openshi
>>> ft/wildfly-90-centos7@sha256:212d8e093d50b44cf8dd3101d22e7e
>>> fce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212d8e09
>>> 3d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","
>>> generation":2}]},{"tag":"latest","items":[{"created":"2016-
>>> 08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-
>>> 100-centos7@sha256:5a428b5b36d4cd98dce8603d5accb30ff014b7d4f
>>> b73c2bb895edda89cabbb3d","image":"sha256:5a428b5b36d4cd9
>>> 8dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","generati
>>> on":2}]}]}},{"metadata":{"name":"testwebapp","namespace"
>>> :"testwebapp","selfLink":"/oapi/v1/namespaces/testwebapp/
>>> imagestreams/testwebapp","uid":"dae5b8d1-5fc3-11e6-88da-
>>> 525400f41cdb","resourceVersion":"359311","generation":2,"
>>> creationTimestamp":"2016-08-11T13:02:27Z","annotations":{"
>>> openshift.io/image.dockerRepositoryCheck":"2016-
>>> 08-11T13:02:27Z"}},"spec":{"tags":[{"name":"latest","annot
>>> ations":null,"from":{"kind":"DockerImage","name":"docker-la
>>> b.example.com:5000/testwebapp:latest"},"generation":1,"impor
>>> tPolicy":{"scheduled":true}}]},"status":{"dockerImageRepository":"
>>> 172.30.11.167:5000/testwebapp/testwebapp","tags":
>>> [{"tag":"latest","items":[{"created":"2016-08-11T13:02:
>>> 27Z","dockerImageReference":"docker-lab.example.com:5000/
>>> testwebapp@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d97
>>> 1e73449cf9044f3af06074","image":"sha256:c1c8c6c3e1c6729
>>> d1366acaf54c9772b4849f35d971e73449cf9044f3af06074","generati
>>> on":1}]}]}}]}
>>> Aug 15 08:22:00 os-master origin-master: ation":2}]},{"tag":"8.1","item
>>> s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
>>> :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead3b8a9e3
>>> 3aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:
>>> 68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f65
>>> 1f96","generation":2}]},{"tag":"9.0","items":[{"created":"
>>> 2016-08-02T18:21:31Z","dockerImageReference":"openshi
>>> 

Re: configuring periodic import of images

[Tony Saxon]

So I've found that if I tag the imagestream manually, that it is able to
pull down the latest changes and deploys them to my app:

oc tag --source=docker --scheduled=true
docker-lab.example.com:5000/testwebapp:latest testwebapp:latest

[root@os-master ~]# oc describe is
Name:   testwebapp
Created:4 days ago
Labels: 
Annotations:
openshift.io/image.dockerRepositoryCheck=2016-08-15T17:49:36Z
Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp

Tag Spec
Created
PullSpec
Image
latest  docker-lab.example.com:5000/testwebapp:latest *38 minutes
ago  docker-lab.example.com:5000/testwebapp@sha256:dd75ff58184489...

About an
hour ago   docker-lab.example.com:5000/testwebapp@sha256:2a4f9e1262e377...

4 days
ago
docker-lab.example.com:5000/testwebapp@sha256:c1c8c6c3e1c672...


  * tag is scheduled for periodic import
  ! tag is insecure and can be imported over HTTP or self-signed HTTPS


This updates the tags, redeploys the pods and all my new changes are
visible once the new containers are up. It appears that it's not doing the
periodic import despite being configured to. What is the default period
that it uses to check the source registry?


On Mon, Aug 15, 2016 at 2:29 PM, Tony Saxon  wrote:

> So I've found that if I tag the imagestream manually, that it is able to
> pull down the latest changes and deploys them to my app:
>
> On Mon, Aug 15, 2016 at 8:46 AM, Tony Saxon  wrote:
>
>> There are logs showing that it's detecting that the imagestream has
>> changed, but doesn't seem like there's any explanation of why it can't get
>> it:
>>
>> Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822   77042
>> image_change_controller.go:47] Build image change controller detected
>> ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
>> Aug 15 08:20:01 os-master origin-master: ation":2}]},{"tag":"8.1","item
>> s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
>> :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead
>> 3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"
>> sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf7
>> 04a0f651f96","generation":2}]},{"tag":"9.0","items":[{"
>> created":"2016-08-02T18:21:31Z","dockerImageReference":"o
>> penshift/wildfly-90-centos7@sha256:212d8e093d50b44cf8dd3101d
>> 22e7efce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212
>> d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c2
>> 2","generation":2}]},{"tag":"latest","items":[{"created":"
>> 2016-08-02T18:21:31Z","dockerImageReference":"openshift/
>> wildfly-100-centos7@sha256:5a428b5b36d4cd98dce8603d5accb30ff
>> 014b7d4fb73c2bb895edda89cabbb3d","image":"sha256:5a428b5b36d
>> 4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","
>> generation":2}]}]}},{"metadata":{"name":"testwebapp","
>> namespace":"testwebapp","selfLink":"/oapi/v1/namespaces/
>> testwebapp/imagestreams/testwebapp","uid":"dae5b8d1-
>> 5fc3-11e6-88da-525400f41cdb","resourceVersion":"359311","gen
>> eration":2,"creationTimestamp":"2016-08-11T13:02:27Z","annotations":{"
>> openshift.io/image.dockerRepositoryCheck":"2016-08-11T13:02:27Z"}},"spec"
>> :{"tags":[{"name":"latest","annotations":null,"from":{"kind"
>> :"DockerImage","name":"docker-lab.example.com:5000/testwebapp:latest
>> "},"generation":1,"importPolicy":{"scheduled":true}}]},"status":{"
>> dockerImageRepository":"172.30.11.167:5000/testwebapp/testwebapp
>> ","tags":[{"tag":"latest","items":[{"created":"2016-08-
>> 11T13:02:27Z","dockerImageReference":"docker-lab.example.
>> com:5000/testwebapp@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4
>> 849f35d971e73449cf9044f3af06074","image":"sha256:c1c8c6c3e1c
>> 6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074","
>> generation":1}]}]}}]}
>> Aug 15 08:22:00 os-master origin-master: ation":2}]},{"tag":"8.1","item
>> s":[{"created":"2016-08-02T18:21:31Z","dockerImageReference"
>> :"openshift/wildfly-81-centos7@sha256:68a27d407fd1ead
>> 3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"
>> sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf7
>> 04a0f651f96","generation":2}]},{"tag":"9.0","items":[{"
>> created":"2016-08-02T18:21:31Z","dockerImageReference":"o
>> penshift/wildfly-90-centos7@sha256:212d8e093d50b44cf8dd3101d
>> 22e7efce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212
>> d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c2
>> 2","generation":2}]},{"tag":"latest","items":[{"created":"
>> 2016-08-02T18:21:31Z","dockerImageReference":"openshift/
>> wildfly-100-centos7@sha256:5a428b5b36d4cd98dce8603d5accb30ff
>> 014b7d4fb73c2bb895edda89cabbb3d","image":"sha256:5a428b5b36d
>> 4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","
>> generation":2}]}]}},{"metadata":{"name":"testwebapp","
>> 

Re: configuring periodic import of images

[Tony Saxon]

There are logs showing that it's detecting that the imagestream has
changed, but doesn't seem like there's any explanation of why it can't get
it:

Aug 15 08:18:10 os-master origin-master: I0815 08:18:10.446822   77042
image_change_controller.go:47] Build image change controller detected
ImageStream change 172.30.11.167:5000/testwebapp/testwebapp
Aug 15 08:20:01 os-master origin-master:
ation":2}]},{"tag":"8.1","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-81-centos7@sha256
:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","generation":2}]},{"tag":"9.0","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-90-centos7@sha256
:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","generation":2}]},{"tag":"latest","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-100-centos7@sha256
:5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","image":"sha256:5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","generation":2}]}]}},{"metadata":{"name":"testwebapp","namespace":"testwebapp","selfLink":"/oapi/v1/namespaces/testwebapp/imagestreams/testwebapp","uid":"dae5b8d1-5fc3-11e6-88da-525400f41cdb","resourceVersion":"359311","generation":2,"creationTimestamp":"2016-08-11T13:02:27Z","annotations":{"
openshift.io/image.dockerRepositoryCheck
":"2016-08-11T13:02:27Z"}},"spec":{"tags":[{"name":"latest","annotations":null,"from":{"kind":"DockerImage","name":"
docker-lab.example.com:5000/testwebapp:latest
"},"generation":1,"importPolicy":{"scheduled":true}}]},"status":{"dockerImageRepository":"
172.30.11.167:5000/testwebapp/testwebapp
","tags":[{"tag":"latest","items":[{"created":"2016-08-11T13:02:27Z","dockerImageReference":"
docker-lab.example.com:5000/testwebapp@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074
","image":"sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074","generation":1}]}]}}]}
Aug 15 08:22:00 os-master origin-master:
ation":2}]},{"tag":"8.1","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-81-centos7@sha256
:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","generation":2}]},{"tag":"9.0","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-90-centos7@sha256
:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","generation":2}]},{"tag":"latest","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-100-centos7@sha256
:5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","image":"sha256:5a428b5b36d4cd98dce8603d5accb30ff014b7d4fb73c2bb895edda89cabbb3d","generation":2}]}]}},{"metadata":{"name":"testwebapp","namespace":"testwebapp","selfLink":"/oapi/v1/namespaces/testwebapp/imagestreams/testwebapp","uid":"dae5b8d1-5fc3-11e6-88da-525400f41cdb","resourceVersion":"359311","generation":2,"creationTimestamp":"2016-08-11T13:02:27Z","annotations":{"
openshift.io/image.dockerRepositoryCheck
":"2016-08-11T13:02:27Z"}},"spec":{"tags":[{"name":"latest","annotations":null,"from":{"kind":"DockerImage","name":"
docker-lab.example.com:5000/testwebapp:latest
"},"generation":1,"importPolicy":{"scheduled":true}}]},"status":{"dockerImageRepository":"
172.30.11.167:5000/testwebapp/testwebapp
","tags":[{"tag":"latest","items":[{"created":"2016-08-11T13:02:27Z","dockerImageReference":"
docker-lab.example.com:5000/testwebapp@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074
","image":"sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074","generation":1}]}]}}]}
Aug 15 08:23:59 os-master origin-master:
ation":2}]},{"tag":"8.1","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-81-centos7@sha256
:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","image":"sha256:68a27d407fd1ead3b8a9e33aa2054c948ad3a54556d28bb4caaf704a0f651f96","generation":2}]},{"tag":"9.0","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-90-centos7@sha256
:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","image":"sha256:212d8e093d50b44cf8dd3101d22e7efce6293d741a6dc30fced9cd27b70c7c22","generation":2}]},{"tag":"latest","items":[{"created":"2016-08-02T18:21:31Z","dockerImageReference":"openshift/wildfly-100-centos7@sha256

Re: configuring periodic import of images

[Tony Saxon]

Right, I get the v1schema vs v2schema issue. What I'm saying is that I've
already been able to import the image from the private docker repository
into an imagestream:

[root@os-master ~]# oc describe is
Name:   testwebapp
Created:24 hours ago
Labels: 
Annotations:
openshift.io/image.dockerRepositoryCheck=2016-08-11T13:02:27Z
Docker Pull Spec:   172.30.11.167:5000/testwebapp/testwebapp

Tag Spec
Created
PullSpec
Image
latest  docker-lab.example.com:5000/testwebapp:latest *24 hours
agodocker-lab.example.com:5000/testwebapp@sha256:c1c8c6c3e1c672...


  * tag is scheduled for periodic import
  ! tag is insecure and can be imported over HTTP or self-signed HTTPS


[root@os-master ~]# oc describe dc/testwebapp
Name:   testwebapp
Created:24 hours ago
Labels: app=testwebapp
Annotations:openshift.io/generated-by=OpenShiftNewApp
Latest Version: 3
Selector:   app=testwebapp,deploymentconfig=testwebapp
Replicas:   3
Triggers:   Config, Image(testwebapp@latest, auto=true)
Strategy:   Rolling
Template:
  Labels:   app=testwebapp,deploymentconfig=testwebapp
  Annotations:
openshift.io/container.testwebapp.image.entrypoint=["/bin/sh","-c","/usr/local/tomcat/bin/startup.sh
\u0026\u0026 tail -f /usr/local/tomcat/logs/catalina.out"],
openshift.io/generated-by=OpenShiftNewApp
  Containers:
  testwebapp:
Image:
docker-lab.example.com:5000/testwebapp@sha256:c1c8c6c3e1c6729d1366acaf54c9772b4849f35d971e73449cf9044f3af06074
Port:
QoS Tier:
  cpu:  BestEffort
  memory:   BestEffort
Environment Variables:
  No volumes.

Deployment #3 (latest):
Name:   testwebapp-3
Created:18 hours ago
Status: Complete
Replicas:   3 current / 3 desired
Selector:
app=testwebapp,deployment=testwebapp-3,deploymentconfig=testwebapp
Labels: app=testwebapp,
openshift.io/deployment-config.name=testwebapp
Pods Status:3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Deployment #2:
Created:21 hours ago
Status: Complete
Replicas:   0 current / 0 desired
Deployment #1:
Created:24 hours ago
Status: Complete
Replicas:   0 current / 0 desired

No events.

All updated images have been pushed to the registry from the same docker
client. If the issue was the manifest 2 vs 1 issue wouldn't I have been
unable to deploy the app initially as well?

On Fri, Aug 12, 2016 at 9:30 AM, Clayton Coleman 
wrote:

> To have openshift import an image's metadata from another registry (which
> finds the digest ID of the image, so that internally you can trigger
> deployments that use the latest digest ID), OpenShift needs to be able to
> get the correct digest ID.  When Docker 1.10+ tries to push an image, it
> first tries to push as a v2schema, and if that fails pushes as a v1schema.
> Because v1schema and v2schema have different digest IDs, when a v2schema is
> pushed the Docker registry tells OpenShift 1.2 that the digest is the
> v1schema value, but in reality only the v2schema value can be pulled.
>
> OpenShift 1.3 adds support for using the newer registry client so that it
> gets the v2schema value.  We hope to cut an rc very soon, but until then,
> if you want to have openshift import images by digest (what most of the
> tools do by default) you need to push your images using Docker 1.9.  If you
> want to bypass the import by digest, you can use the `--reference` flag
> which only imports the tag name (but includes none of the metadata):
>
> oc tag --reference --source=docker SOME_DOCKER_TAG IMAGESTREAM:TAG
>
>
>
> On Fri, Aug 12, 2016 at 8:58 AM, Tony Saxon  wrote:
>
>> Ok, so I'm a little confused. If my problem is the manifest schema, I had
>> thought that I already fixed that by downgrading my private registry to an
>> older version that didn't support schema 2 (http://lists.openshift.redhat
>> .com/openshift-archives/users/2016-August/msg00081.html).
>>
>> Basically I downgraded my registry to version 2.2.1 just so that I could
>> deploy an application from an imagestream that pulled from my private
>> registry. That works successfully.
>>
>> Does the internal registry that is used by docker support schema 2? If I
>> reconfigure that to be secure and expose it externally and push my images
>> to that will I still run into this problem?
>>
>> On Thu, Aug 11, 2016 at 9:26 PM, Philippe Lafoucrière <
>> philippe.lafoucri...@tech-angels.com> wrote:
>>
>>> https://docs.openshift.com/enterprise/3.2/install_config/ins
>>> tall/docker_registry.html
>>>
>>> " The manifest v2 schema 2
>>> 
>>>  (*schema2*) is not yet supported."
>>>
>>> Sorry :)
>>> ​
>>>
>>
>>
>> 

Re: configuring periodic import of images

[Clayton Coleman]

To have openshift import an image's metadata from another registry (which
finds the digest ID of the image, so that internally you can trigger
deployments that use the latest digest ID), OpenShift needs to be able to
get the correct digest ID.  When Docker 1.10+ tries to push an image, it
first tries to push as a v2schema, and if that fails pushes as a v1schema.
Because v1schema and v2schema have different digest IDs, when a v2schema is
pushed the Docker registry tells OpenShift 1.2 that the digest is the
v1schema value, but in reality only the v2schema value can be pulled.

OpenShift 1.3 adds support for using the newer registry client so that it
gets the v2schema value.  We hope to cut an rc very soon, but until then,
if you want to have openshift import images by digest (what most of the
tools do by default) you need to push your images using Docker 1.9.  If you
want to bypass the import by digest, you can use the `--reference` flag
which only imports the tag name (but includes none of the metadata):

oc tag --reference --source=docker SOME_DOCKER_TAG IMAGESTREAM:TAG



On Fri, Aug 12, 2016 at 8:58 AM, Tony Saxon  wrote:

> Ok, so I'm a little confused. If my problem is the manifest schema, I had
> thought that I already fixed that by downgrading my private registry to an
> older version that didn't support schema 2 (http://lists.openshift.
> redhat.com/openshift-archives/users/2016-August/msg00081.html).
>
> Basically I downgraded my registry to version 2.2.1 just so that I could
> deploy an application from an imagestream that pulled from my private
> registry. That works successfully.
>
> Does the internal registry that is used by docker support schema 2? If I
> reconfigure that to be secure and expose it externally and push my images
> to that will I still run into this problem?
>
> On Thu, Aug 11, 2016 at 9:26 PM, Philippe Lafoucrière <
> philippe.lafoucri...@tech-angels.com> wrote:
>
>> https://docs.openshift.com/enterprise/3.2/install_config/ins
>> tall/docker_registry.html
>>
>> " The manifest v2 schema 2
>> 
>>  (*schema2*) is not yet supported."
>>
>> Sorry :)
>> ​
>>
>
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: configuring periodic import of images

[Philippe Lafoucrière]

https://docs.openshift.com/enterprise/3.2/install_config/install/docker_registry.html

" The manifest v2 schema 2

 (*schema2*) is not yet supported."

Sorry :)
​
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: configuring periodic import of images

[Clayton Coleman]

It is only in alpha.3

On Aug 11, 2016, at 7:12 PM, Andrew Lau  wrote:

I'm not sure if it's only in the 1.3.0-alpha3 but

https://docs.openshift.org/latest/install_config/install/docker_registry.html#docker-registry-configuration-reference-middleware

specifically, acceptschema2: false

?

On Fri, 12 Aug 2016 at 09:01 Philippe Lafoucrière <
philippe.lafoucri...@tech-angels.com> wrote:

>
> On Thu, Aug 11, 2016 at 5:15 PM, Tony Saxon  wrote:
>
>> Damn, I just went through having to downgrade my registry because I was
>> pushing with 1.12 and openshift (running docker 1.10) wasn't able to pull
>> the image due the the sha256 hash that it was referencing not existing
>> because of the v1/v2 issues. I guess my only option if I don't want to
>> upgrade my openshift is to push from a machine running docker 1.10?
>
>
> I'm afraid so. We're running into the same issue, and haven't found a
> solution yet :(
> You could also try the 1.3.0-alpha3, but I wouldn't recommend it for
> production of course...
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: configuring periodic import of images

[Philippe Lafoucrière]

On Thu, Aug 11, 2016 at 5:15 PM, Tony Saxon  wrote:

> Damn, I just went through having to downgrade my registry because I was
> pushing with 1.12 and openshift (running docker 1.10) wasn't able to pull
> the image due the the sha256 hash that it was referencing not existing
> because of the v1/v2 issues. I guess my only option if I don't want to
> upgrade my openshift is to push from a machine running docker 1.10?


I'm afraid so. We're running into the same issue, and haven't found a
solution yet :(
You could also try the 1.3.0-alpha3, but I wouldn't recommend it for
production of course...
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: configuring periodic import of images

[Tony Saxon]

Damn, I just went through having to downgrade my registry because I was
pushing with 1.12 and openshift (running docker 1.10) wasn't able to pull
the image due the the sha256 hash that it was referencing not existing
because of the v1/v2 issues. I guess my only option if I don't want to
upgrade my openshift is to push from a machine running docker 1.10?

On Thu, Aug 11, 2016 at 4:30 PM, Philippe Lafoucrière <
philippe.lafoucri...@tech-angels.com> wrote:

> If you are using different versions of docker on openshift, and the server
> where the image was build, you will fall into this (known) problem.
> Check out https://trello.com/c/CJiUnVUm/136-3-docker-1-10-push-
> force-schema1-manifest-via-daemon-flag
>
> Hopefuly, this seems to be fixed in the upcoming 1.3. Check the section :
> Upgrading to Docker Registry 2.4, cross-repository linking, and better
> usage tooling
> in https://github.com/openshift/origin/releases/tag/v1.3.0-alpha.3
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: configuring periodic import of images

[Philippe Lafoucrière]

If you are using different versions of docker on openshift, and the server
where the image was build, you will fall into this (known) problem.
Check out https://trello.com/c/CJiUnVUm/136-3-docker-1-10-
push-force-schema1-manifest-via-daemon-flag

Hopefuly, this seems to be fixed in the upcoming 1.3. Check the section :
Upgrading to Docker Registry 2.4, cross-repository linking, and better
usage tooling
in https://github.com/openshift/origin/releases/tag/v1.3.0-alpha.3
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users