[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Builds and Deployments can now reference image streams when running an integrated registry




----- Original Message -----
> This is really cool and completely clarifies the intent of imagerepositories
> for me... one question inline below.
> 
> ----- Original Message -----
> > From: "Clayton Coleman" <ccoleman redhat com>
> > To: "[PUBLIC] Openshift Dev" <dev lists openshift redhat com>
> > Sent: Friday, January 23, 2015 6:48:24 PM
> > Subject: Builds and Deployments can now reference image streams when
> > running	an integrated registry
> > 
> > Pull https://github.com/openshift/origin/pull/679 contained some fairly
> > major
> > changes to how images, builds, and deployments can be linked together.  It
> > delivers the idea that image repositories are named ways of referencing a
> > stream of images over time, by making it so that both builds and
> > deployments
> > can directly reference an image repository by name, and when that image
> > repository gets updated, they'll trigger builds or deployments.
> > 
> > An example is in the sample-app now:
> > https://github.com/openshift/origin/blob/5193072c5cd77d348dfbb6bf830e308d1f53ada3/examples/sample-app/application-template-stibuild.json
> > 
> > This image repository represents where an app goes:
> > 
> >     {
> >       "metadata":{
> >         "name": "origin-ruby-sample",
> >       },
> >       "kind": "ImageRepository",
> >       "labels": {
> >         "name": "origin-ruby-sample"
> >       }
> >     },
> > 
> > The build outputs directly to that image repository by name ("output.to"),
> > and reads from the ruby-20-centos image repository as well by name
> > ("triggers[0].imageChange.from")
> > 
> >     {
> >       "metadata":{
> >         "name": "ruby-sample-build",
> >       },
> >       "kind": "BuildConfig",
> >       "triggers": [
> >         {
> >           "type": "imageChange",
> >           "imageChange": {
> >             "image": "openshift/ruby-20-centos",
> >             "from": {
> >               "name": "ruby-20-centos"
> >             },
> >             "tag":"latest"
> >           }
> >         }
> >       ],
> >       "parameters": {
> >         ...
> >         "output": {
> >           "to": {
> >             "name": "origin-ruby-sample"
> >           }
> >         },
> >       },
> >       "labels": {
> >         "name": "ruby-sample-build"
> >       }
> >     },
> 
> can you elaborate a little more on the long term vision for referencing
> imagerepositories?  right now this only works if you have an imagerepository
> with that name in your namespace, but eventually we're going to move to a
> syntax like:
> 
>          "output": {
>            "to": {
>              "name": "origin-ruby-sample"
>              "namespace": "myopenshiftnamespace"
>            }
>          },
> 
> right?

I think so.  We might also let you define an image repository that "follows" another one:

    {
      "metadata":{
        "name": "php",
      },
      "kind": "ImageRepository",
      "follows": {
        "name": "php",
        "namespace": "myco",
      }
    },

where you would get all the tags from myco/php, but you could also set your own (i.e., follow upstream, until you want to pin to a specific image).  We probably also need to support:

    {
      "metadata":{
        "name": "php",
      },
      "kind": "ImageRepository",
      "watches": {
        "dockerRepository": "mydockerregistry.com/somenamespace/php",
        "tags": {
          "latest": "latest",
          "other": "differentname"
        }
      }
    },

where you can integrate external Docker registries, and have tags that get remapped to how you want to use them internally.  But these all need more use cases supporting them.

> 
> Similarly, for imagerepositories, will they be able to map to anything other
> than a repository that matches their namespace?  or am I forced to always
> match the openshift namespace for my imagerepository to the docker registry
> namespace?

I think so.  The old behavior of setting "dockerImageRepository" is preserved (if you set those manually, and the tags exist in the registry for the value of the tag) it should still work.  The "watches" would be one way of improving that, but you can still do:

    {
      "metadata":{
        "name": "php",
      },
      "kind": "ImageRepository",
      "dockerImageRepository": "mydockerregistry.com/somenamespace/php",
      "tags": {
        "some_virtual_tag": "an_actual_tag_in_that_repo",
      }
    },

You can then manage those tags manually (if you have your own tagging scheme).  However, I think at the end of the day in the cluster it would be ideal to do:

  docker pull docker-registry.default.local/<namespace>/<imagerepositoryname>

and have both security, authorization, proxying, load balancing, etc all managed by whatever registry is running at docker-registry.default.local (and tied into the access model you have in openshift).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]