[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



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?

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?


> 
> The deployment config does the same thing - it triggers based on
> "origin-ruby-sample" via the "from" field:
> 
>     {
>       "metadata":{
>         "name": "frontend",
>       },
>       "kind": "DeploymentConfig",
>       "triggers": [
>         {
>           "type": "ImageChange",
>           "imageChangeParams": {
>             "automatic": true,
>             "containerNames": [
>               "ruby-helloworld"
>             ],
>             "from": {
>               "name": "origin-ruby-sample"
>             },
>             "tag": "latest"
>           }
>         }
>       ],
>       ...
>     }
> 
> Note that DeploymentConfig and BuildConfig have different names for their
> trigger parameters, and that's something we'll fix in the next API version.
> 
> When the example installs the default registry (as docker-registry), it's
> *automatically* linked up so that when you push an image to
> "<defaultRegistry>/test/origin-ruby-sample" via Docker, the image repository
> called "origin-ruby-sample" in the "test" namespace is updated.  As the
> integration with the registry gets better, there will be access control and
> security around those image repositories based on your project.  It's not
> quite there yet.  The end goal though is that as a user, you can create an
> ImageRepository, give it your own name, and then either push images there
> (set up automatically) or have it poll the contents of another repository.
> Then your builds and deployments are decoupled from an individual docker
> registry, and you can switch which images you're using without having to
> redo your builds or deployments.  This flexibility is key - our generation
> code will let you link these flows together across projects, so operations
> can deploy images to an entire orga!
>  nization, but each application or project can react as they need.
> 
> Existing Builds and DeploymentConfigs should be unaffected (we support the
> old behavior via backwards API compatibility) but if you hit any problems
> please let me know and we'll get it fixed.
> 
> Thanks!
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


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