Re: [openstack-dev] [TripleO] breaking changes, new container image parameter formats
On 25.7.2017 04:40, Michał Jastrzębski wrote: ... DockerInsecureRegistryAddress: 172.19.0.2:8787/tripleoupstream DockerKeystoneImage: 172.19.0.2:8787/tripleoupstream/centos-binary- keystone:latest ... That's strange construction, are you sure guys that you don't want to separate address:port from namespace? (tripleoupstream here). Say you'd like to setup docker to point to insecure registry (add --insecure-registry do systemd conf), that will take addr:port not whole thing. Thanks Michał, i think it was just a copy-paste error in the e-mail and in reality the parameter value should indeed look like: DockerInsecureRegistryAddress: 172.19.0.2:8787 I posted a tripleo-docs patch which documents the changes discussed in this thread: https://review.openstack.org/486635 Thanks Jirka __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] breaking changes, new container image parameter formats
>>... >>DockerInsecureRegistryAddress: 172.19.0.2:8787/tripleoupstream >>DockerKeystoneImage: 172.19.0.2:8787/tripleoupstream/centos-binary- >> keystone:latest >>... That's strange construction, are you sure guys that you don't want to separate address:port from namespace? (tripleoupstream here). Say you'd like to setup docker to point to insecure registry (add --insecure-registry do systemd conf), that will take addr:port not whole thing. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] breaking changes, new container image parameter formats
On 19.7.2017 14:41, Dan Prince wrote: I wanted to give a quick heads up on some breaking changes that started landing last week with regards to how container images are specified with Heat parameters in TripleO. There are a few patches associated with converting over to the new changes but the primary patches are listed below here [1] and here [2]. Here are a few examples where I'm using a local (insecure) docker registry on 172.19.0.2. The old parameters were: DockerNamespaceIsRegistry: true DockerNamespace: 172.19.0.2:8787/tripleoupstream DockerKeystoneImage: centos-binary-keystone:latest ... The new parameters simplify things quite a bit so that each Docker*Image parameter contains the *entire* URL required to pull the docker image. It ends up looking something like this: ... DockerInsecureRegistryAddress: 172.19.0.2:8787/tripleoupstream DockerKeystoneImage: 172.19.0.2:8787/tripleoupstream/centos-binary- keystone:latest ... The benefit of the new format is that it makes it possible to pull images from multiple registries without first staging them to a local docker registry. Also, we've removed the 'tripleoupstream' default container names and now require them to be specified. Removing the default should make it much more explicit that the end user has specified container image names correctly and doesn't accidentally use 'tripleoupstream' by accident because one of the container image parameters didn't get specified. Additional info based on #tripleo discussion: To keep using the values that were the defaults, you need to add `-e $THT_PATH/environments/docker-centos-tripleoupstream.yaml` [3] to the `openstack overcloud deploy` command. Finally the simplification of the DockerInsecureRegistryAddress parameter into a single setting makes things more clear to the end user as well. A new python-tripleoclient command makes it possible to generate a custom heat environment with defaults for your environment and registry. For the examples above I can run 'overcloud container image prepare' to generate a custom heat environment like this: openstack overcloud container image prepare -- namespace=172.19.0.2:8787/tripleoupstream --env- file=$HOME/containers.yaml We choose not to implement backwards compatibility with the old image formats as almost all of the Heat parameters here are net new in Pike and as such have not yet been released yet. The changes here should make it much easier to manage containers and work with other community docker registries like RDO, etc. [1] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/comm it/?id=e76d84f784d27a7a2d9e5f3a8b019f8254cb4d6c [2] https://review.openstack.org/#/c/479398/17 [3] https://github.com/openstack/tripleo-heat-templates/blob/5cbcc8377c49e395dc1d02a976d9b4a94253f5ca/environments/docker-centos-tripleoupstream.yaml __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] breaking changes, new container image parameter formats
I wanted to give a quick heads up on some breaking changes that started landing last week with regards to how container images are specified with Heat parameters in TripleO. There are a few patches associated with converting over to the new changes but the primary patches are listed below here [1] and here [2]. Here are a few examples where I'm using a local (insecure) docker registry on 172.19.0.2. The old parameters were: DockerNamespaceIsRegistry: true DockerNamespace: 172.19.0.2:8787/tripleoupstream DockerKeystoneImage: centos-binary-keystone:latest ... The new parameters simplify things quite a bit so that each Docker*Image parameter contains the *entire* URL required to pull the docker image. It ends up looking something like this: ... DockerInsecureRegistryAddress: 172.19.0.2:8787/tripleoupstream DockerKeystoneImage: 172.19.0.2:8787/tripleoupstream/centos-binary- keystone:latest ... The benefit of the new format is that it makes it possible to pull images from multiple registries without first staging them to a local docker registry. Also, we've removed the 'tripleoupstream' default container names and now require them to be specified. Removing the default should make it much more explicit that the end user has specified container image names correctly and doesn't accidentally use 'tripleoupstream' by accident because one of the container image parameters didn't get specified. Finally the simplification of the DockerInsecureRegistryAddress parameter into a single setting makes things more clear to the end user as well. A new python-tripleoclient command makes it possible to generate a custom heat environment with defaults for your environment and registry. For the examples above I can run 'overcloud container image prepare' to generate a custom heat environment like this: openstack overcloud container image prepare -- namespace=172.19.0.2:8787/tripleoupstream --env- file=$HOME/containers.yaml We choose not to implement backwards compatibility with the old image formats as almost all of the Heat parameters here are net new in Pike and as such have not yet been released yet. The changes here should make it much easier to manage containers and work with other community docker registries like RDO, etc. [1] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/comm it/?id=e76d84f784d27a7a2d9e5f3a8b019f8254cb4d6c [2] https://review.openstack.org/#/c/479398/17 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev