13 Aug
2019
13 Aug
'19
5:46 a.m.
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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
13 Aug
13 Aug
6:35 a.m.
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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
16 Aug
16 Aug
8:01 a.m.
Hi,
On 8/13/19 1:35 PM, Thorsten Kukuk 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?
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)
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?
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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Tue, Aug 13, Thomas Bechtold wrote:
it did. Thanks!
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.
8:07 a.m.
On Fri, Aug 16, Thomas Bechtold wrote:
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:op…
I think that would fit very well for generic openSUSE Tumbleweed
containers, ask the project maintainers what they think.
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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
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. - 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. 
8:12 a.m.
Hi,
Am Freitag, 16. August 2019, 15:01:25 CEST schrieb Thomas Bechtold:
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?
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
Hi,
On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
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.
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?
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) - 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. Best,
Tom
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
17 Aug
17 Aug
2:37 p.m.
Thomas Bechtold <tbechtold(a)suse.com> writes:
Hi,
On 8/13/19 1:35 PM, Thorsten Kukuk wrote:
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
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?
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) - 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.
564
days inactive
568
days old
5 comments
4 participants
participants (4)
-
Dan Cermak -
Fabian Vogt -
Thomas Bechtold -
Thorsten Kukuk