Add an initial importer for Image Repositories

[smarterclayton]

Image Repositories that have "dockerImageRepository" set will have
images imported if "tags" is empty or if there are "tags" that have
an empty string value. Once complete, or if sufficient failures
occur, the annotation "openshift.io/image.dockerRepositoryCheck"
will be set to a timestamp (time completed) or a string message.

This won't work until we can pull by ID against the local registry.

@ncdc

[ncdc]

Do you want this to support both v1 and v2 registries?

[smarterclayton]

See my note about not being able to merge this util pull by id works.

On Mar 12, 2015, at 8:12 PM, Andy Goldstein [email protected] wrote:

Do you want this to support both v1 and v2 registries?

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

I might have it use (instead of image ids) the tags.

On Mar 12, 2015, at 8:12 PM, Andy Goldstein [email protected] wrote:

Do you want this to support both v1 and v2 registries?

—
Reply to this email directly or view it on GitHub.

[ncdc]

I ask about supporting both versions of the registry as it means we'll need to modify things like getTags to try both v1 and v2 URL routes (https://github.com/openshift/origin/pull/1303/files#diff-9ebbd569a27134d93340002608ebe1a9R182)

[ncdc]

And yes, for external v1 registries, I think tags might be the only real universal option.

[smarterclayton]

I'll probably only support v1 for now. This is primarily for use existing v1 registry and get metadata.

On Mar 12, 2015, at 8:20 PM, Andy Goldstein [email protected] wrote:

I ask about supporting both versions of the registry as it means we'll need to modify things like getTags to try both v1 and v2 URL routes (https://github.com/openshift/origin/pull/1303/files#diff-9ebbd569a27134d93340002608ebe1a9R182)

—
Reply to this email directly or view it on GitHub.

[ncdc]

Wrong method name

[smarterclayton]

See the last commit - during imageRepositoryMapping, if the dockerImageReference has a different tag than mapping.Tag, the server can assume that the reference's tag is valid. Otherwise, it must use the tag provided. This will allow both scenarios to work now.

[smarterclayton]

@ironcladlou please review the first commit. Standardized some things with retry handler (only one place needs to check errors).

[ironcladlou]

@smarterclayton

@ironcladlou please review the first commit. Standardized some things with retry handler (only one place needs to check errors).

Made a few comments on the commit. Cool refactor!

[ironcladlou]

Controller changes LGTM!

[smarterclayton]

I added a significant number of changes to how tags and status events are stored. When a user sets a "Tag", they are making a reference to another object. There are only two types of references supported - a tag that already exists on the image repo (so you can have tag "foo" pointing to "latest"), or the image id reference described elsewhere. Image repository mappings are changed to post status updates directly to the image repository, vs making a spec change. As a result, the Spec.Tags and Status.Tags can differ - since @ncdc's earlier change made that a non issue (except in one case around builds), the change is less invasive. Consumers of the Status.Tags field should be aware that the "Image" field may be empty (the reference is purely tag oriented) or that the DockerImageReference may be empty (in which case the next older tag should be preferred).

@bparees please review the build controller changes - we can no longer assume that "Image" is set, which means that the value we set should either be Image (preferentially) or DockerImageReference (if Image is empty). That ensures that a change is triggered. This does not affect deployments because they rely on the template being changed to trigger a rollout.

@ncdc updateTagHistory is removed in favor of refactoring into two helper methods AddTagEventToImageRepository (which handles compression of related events) and TagValueToTagEvent (which handles splitting out the tag use case). I don't believe this should impact your changes - users will set tags to differentiate things (and can still set IDs), but the mapping part is now significantly different.

[smarterclayton]

[test]

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1339/)

[bparees]

-1

[bparees]

-1, it's not a change, it's a trigger. specifically an image change trigger.

[smarterclayton]

Actually, it's the parameters to an image change trigger. It's the definition of what should change.

----- Original Message -----

    for _, trigger := range config.Triggers {
        if trigger.Type != buildapi.ImageChangeBuildTriggerType {
            continue
        }

•       icTrigger := trigger.ImageChange
  

•       change := trigger.ImageChange
  

-1, it's not a change, it's a trigger. specifically an image change trigger.

---

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1303/files#r26478655

[bparees]

the parameters would include the actual new imageid, this doesn't. this is the vessel, not the values.

[bparees]

DockerImageReference is a fully qualified/tagged/immutable value?

[smarterclayton]

Yes

----- Original Message -----

            continue
        }

        // (must be different) to trigger a build

•       if icTrigger.LastTriggeredImageID != latest.Image {
  

•           imageSubstitutions[icTrigger.Image] = latest.DockerImageReference
  

•           shouldTriggerBuild = true
  

•           icTrigger.LastTriggeredImageID = latest.Image
  

•       last := change.LastTriggeredImageID
  

•       next := latest.Image
  

•       if len(next) == 0 {
  

•           // tags without images should still trigger builds (when going from a
  

  pure tag to an image

•           // based tag, we should rebuild)
  

•           next = latest.DockerImageReference
  

•       }
  

•       if len(last) == 0 || next != last {
  

•           subs[change.Image] = latest.DockerImageReference
  

DockerImageReference is a fully qualified/tagged/immutable value?

---

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1303/files#r26511971

[ncdc]

This is a pretty big change and it's sometimes hard to keep all the priorities/conditionals straight, but I think I can wrap my head around it so...

LGTM

[smarterclayton]

At worst, we break someone and fix it. :)

[ncdc]

Exactly!

[smarterclayton]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1199/) (Image: devenv-fedora_1063)

[openshift-bot]

Evaluated for origin up to ebbf8a6