[opensuse-factory] Maintaining containers for Factory
Hi, while the cloud team starts to create containers for different applications there are some open questions regarding to openSUSE Factory: - is there already some sort of idea/strategy if/how containers for specific packages (like mariadb, rabbitmq, ...) could be maintained for openSUSE:Factory ? - should a container (eg mariadb) be in the devel project (server:database for mariadb) and submitted to openSUSE:Factory ? - do we have a naming schema for the container packages (eg. mariadb-container or mariadb-image)? Cheers, Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Tue, Aug 13, Thomas Bechtold wrote:
while the cloud team starts to create containers for different applications there are some open questions regarding to openSUSE Factory:
Welcome in the club! At first, I hope you know https://en.opensuse.org/Building_derived_containers already? This should already answer a lot of questions.
- is there already some sort of idea/strategy if/how containers for specific packages (like mariadb, rabbitmq, ...) could be maintained for openSUSE:Factory ?
Currently, it works this way: - create a devel project for the container - create a correct *.kiwi file for the container with correct labels - submit to openSUSE:Factory - tell the team, that they should be released as official containers on registry.opensuse.org - everytime, we release a new openSUSE Tumbleweed snapshot, containers, which have changed (base containers, RPMs part of the container, ...), we will release a new version of this container into the registry.
- should a container (eg mariadb) be in the devel project (server:database for mariadb) and submitted to openSUSE:Factory ?
For openSUSE Kubic we created devel:kubic:containers Since you need to setup building containers correct in the devel project, I would create a devel project only for building containers and not enable it in many different devel projects.
- do we have a naming schema for the container packages (eg. mariadb-container or mariadb-image)?
For Kubic we are using kubic-*-image For Tumbleweed we are using tumbleweed-*-image You should think about the namespace on the registry. If this containers are generic useable, it should go into the registry.opensuse.org/opensuse namespace. If this containers are only useable for your Cloud product, we should maybe discuss a new namespace for this. And if the containers are generic useable, please make sure, the containers build for x86-64, aarch64, power64le and s390x. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
On Tue, Aug 13, Thomas Bechtold wrote:
while the cloud team starts to create containers for different applications there are some open questions regarding to openSUSE Factory:
Welcome in the club!
At first, I hope you know https://en.opensuse.org/Building_derived_containers already?
This should already answer a lot of questions.
it did. Thanks!
- is there already some sort of idea/strategy if/how containers for specific packages (like mariadb, rabbitmq, ...) could be maintained for openSUSE:Factory ?
Currently, it works this way: - create a devel project for the container - create a correct *.kiwi file for the container with correct labels - submit to openSUSE:Factory - tell the team, that they should be released as official containers on registry.opensuse.org - everytime, we release a new openSUSE Tumbleweed snapshot, containers, which have changed (base containers, RPMs part of the container, ...), we will release a new version of this container into the registry.
Is it possible (like for RPM packages) to build a container for different distros (eg. SLE_15_SP1 and openSUSE_Leap_15.1) within the same OBS package? Maybe with kiwi profiles and multibuild? Or what's the recommended way to maintain containers for multiple distros? I saw that the CaaSP/kubic containers use a pre-checkin.sh script with sed to create .kiwi files for different distros and keep theses kiwi files in different OBS packages. SES is doing something similar (but with xsl instead of pre-checkin.sh/sed)
- should a container (eg mariadb) be in the devel project (server:database for mariadb) and submitted to openSUSE:Factory ?
For openSUSE Kubic we created devel:kubic:containers Since you need to setup building containers correct in the devel project, I would create a devel project only for building containers and not enable it in many different devel projects.
ok. I guess we create then something in the Cloud:OpenStack: namespace on OBS for the openstack specific containers. But what about a container like mariadb? Where should be the devel project for that container?
- do we have a naming schema for the container packages (eg. mariadb-container or mariadb-image)?
For Kubic we are using kubic-*-image For Tumbleweed we are using tumbleweed-*-image
You should think about the namespace on the registry. If this containers are generic useable, it should go into the registry.opensuse.org/opensuse namespace. If this containers are only useable for your Cloud product, we should maybe discuss a new namespace for this.
And if the containers are generic useable, please make sure, the containers build for x86-64, aarch64, power64le and s390x.
One more question about generic usable containers - do we try to be compatible (basically using the docker-entrypoint.sh scripts from github.com/docker-library) with the "official" dockerhub containers? That's something we might need because some helm charts rely on ENV vars that can be set and are then used in the docker-entrypoint.sh script. Best, Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 16, Thomas Bechtold wrote:
On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
On Tue, Aug 13, Thomas Bechtold wrote:
Is it possible (like for RPM packages) to build a container for different distros (eg. SLE_15_SP1 and openSUSE_Leap_15.1) within the same OBS package? Maybe with kiwi profiles and multibuild? Or what's the recommended way to maintain containers for multiple distros?
This would be more a question for our kiwi and OBS experts, I don't know.
- should a container (eg mariadb) be in the devel project (server:database for mariadb) and submitted to openSUSE:Factory ?
For openSUSE Kubic we created devel:kubic:containers Since you need to setup building containers correct in the devel project, I would create a devel project only for building containers and not enable it in many different devel projects.
ok. I guess we create then something in the Cloud:OpenStack: namespace on OBS for the openstack specific containers. But what about a container like mariadb? Where should be the devel project for that container?
The official base container for tumbleweed is build here: https://build.opensuse.org/project/show/Virtualization:containers:images:ope... I think that would fit very well for generic openSUSE Tumbleweed containers, ask the project maintainers what they think.
- do we have a naming schema for the container packages (eg. mariadb-container or mariadb-image)?
For Kubic we are using kubic-*-image For Tumbleweed we are using tumbleweed-*-image
You should think about the namespace on the registry. If this containers are generic useable, it should go into the registry.opensuse.org/opensuse namespace. If this containers are only useable for your Cloud product, we should maybe discuss a new namespace for this.
And if the containers are generic useable, please make sure, the containers build for x86-64, aarch64, power64le and s390x.
One more question about generic usable containers - do we try to be compatible (basically using the docker-entrypoint.sh scripts from github.com/docker-library) with the "official" dockerhub containers? That's something we might need because some helm charts rely on ENV vars that can be set and are then used in the docker-entrypoint.sh script.
This really depends. If you want to replace containers we would else use from docker hub, you need to make our container compatible. If you want to have/need something different, you cannot make it compatible... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am Freitag, 16. August 2019, 15:01:25 CEST schrieb Thomas Bechtold:
Hi,
On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
On Tue, Aug 13, Thomas Bechtold wrote:
- is there already some sort of idea/strategy if/how containers for specific packages (like mariadb, rabbitmq, ...) could be maintained for openSUSE:Factory ?
Currently, it works this way: - create a devel project for the container - create a correct *.kiwi file for the container with correct labels - submit to openSUSE:Factory - tell the team, that they should be released as official containers on registry.opensuse.org - everytime, we release a new openSUSE Tumbleweed snapshot, containers, which have changed (base containers, RPMs part of the container, ...), we will release a new version of this container into the registry.
Is it possible (like for RPM packages) to build a container for different distros (eg. SLE_15_SP1 and openSUSE_Leap_15.1) within the same OBS package? Maybe with kiwi profiles and multibuild? Or what's the recommended way to maintain containers for multiple distros? I saw that the CaaSP/kubic containers use a pre-checkin.sh script with sed to create .kiwi files for different distros and keep theses kiwi files in different OBS packages. SES is doing something similar (but with xsl instead of pre-checkin.sh/sed)
kiwi profiles and _multibuild won't help here, with those it's not possible to distinguish different OS versions. You can use obs-service-kiwi_metainfo_helper to get various placeholders for the .kiwi file. If that's not enough, you could roll your own obs service to apply more complex transformations. Keep in mind that OBS services can't change the build dependencies.
- should a container (eg mariadb) be in the devel project (server:database for mariadb) and submitted to openSUSE:Factory ?
For openSUSE Kubic we created devel:kubic:containers Since you need to setup building containers correct in the devel project, I would create a devel project only for building containers and not enable it in many different devel projects.
ok. I guess we create then something in the Cloud:OpenStack: namespace on OBS for the openstack specific containers. But what about a container like mariadb? Where should be the devel project for that container?
- do we have a naming schema for the container packages (eg. mariadb-container or mariadb-image)?
For Kubic we are using kubic-*-image For Tumbleweed we are using tumbleweed-*-image
You should think about the namespace on the registry. If this containers are generic useable, it should go into the registry.opensuse.org/opensuse namespace. If this containers are only useable for your Cloud product, we should maybe discuss a new namespace for this.
And if the containers are generic useable, please make sure, the containers build for x86-64, aarch64, power64le and s390x.
One more question about generic usable containers - do we try to be compatible (basically using the docker-entrypoint.sh scripts from github.com/docker-library) with the "official" dockerhub containers? That's something we might need because some helm charts rely on ENV vars that can be set and are then used in the docker-entrypoint.sh script.
IMO entirely up to the maintainer of the image and the targeted use cases. Cheers, Fabian
Best,
Tom
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thomas Bechtold
Hi,
On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
On Tue, Aug 13, Thomas Bechtold wrote:
- is there already some sort of idea/strategy if/how containers for specific packages (like mariadb, rabbitmq, ...) could be maintained for openSUSE:Factory ?
Currently, it works this way: - create a devel project for the container - create a correct *.kiwi file for the container with correct labels - submit to openSUSE:Factory - tell the team, that they should be released as official containers on registry.opensuse.org - everytime, we release a new openSUSE Tumbleweed snapshot, containers, which have changed (base containers, RPMs part of the container, ...), we will release a new version of this container into the registry.
Is it possible (like for RPM packages) to build a container for different distros (eg. SLE_15_SP1 and openSUSE_Leap_15.1) within the same OBS package? Maybe with kiwi profiles and multibuild? Or what's the recommended way to maintain containers for multiple distros? I saw that the CaaSP/kubic containers use a pre-checkin.sh script with sed to create .kiwi files for different distros and keep theses kiwi files in different OBS packages. SES is doing something similar (but with xsl instead of pre-checkin.sh/sed)
I haven't found a simple way how to achieve this (haven't tried too hard though), but I'm afraid that even if you achieve that, it'll be very painful to use in practice. I have the feeling that KIWI works best on OBS if you have one project for each distribution that you are building, define the repositories in OBS and use OBS' repositories inside your KIWI image (that's also the official recommendation: https://osinside.github.io/kiwi/building/build_in_buildservice.html). Creating packages for different distros in the same project resulted for me in an overly complex project configuration to "fix" all the "unresolvable: have choice for SOMEPACKAGE: SOMEPAKAGE_1 SOMEPACKAGE_2" errors. Building a container for different distros from the same package, will probably make this even worse... Cheers, Dan
participants (4)
-
Dan Cermak -
Fabian Vogt -
Thomas Bechtold -
Thorsten Kukuk