packaging: OBS plans
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps. Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8... Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool. Question: Moving forwards, the Kata community will have to discuss/decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.) There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing. There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency). There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden. Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please? Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption). Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/discuss. Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe). I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-) Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Thanks for putting this summary together Graham. Some of the discussion around packaging the images has also found it's way onto: - https://github.com/kata-containers/packaging/issues/219 Cheers, James Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link:
https://docs.google.com/presentation/d/1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8...
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- James --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Hi, I am adding some more details on the next steps. - We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo. - For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211#issuecomment-4266418... . This is another things open to volunteers - For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/packaging/issues/219 Ideas are welcome! Thanks,Marco On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all,
We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link:
https://docs.google.com/presentation/d/1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8...
Fundamentally the plan is to:
- move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES.
- the devel setup will be maintained by a combination of Kata community members and SUSE employees.
- rewrite the specs to be more in line with SUSE standards
- Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image.
- a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by:
- the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe)
- the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________kata-dev mailing listkata-dev@lists.katacontainers.iohttp://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
+Lokesh, he has taken up packaging kata containers for Fedora. Update: Based in the comments from today's architecture meeting. We are going for Kiwi to build the image in our OBS packages. - This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora? - Carlos On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Really +1'ing Lokesh now ;) Le lun. 15 oct. 2018 à 19:49, Jose Carlos Venegas Munoz < jose.carlos.venegas.munoz@intel.com> a écrit :
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent
source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham < graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs
upon) to set as the default for the different distro packages.
This may
be influenced by: - the ability to build some rootfs images from
others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use
a rootfs
based on the same distro (so SUSE would use a SUSE rootfs,
Ubuntu an
Ubuntu rootfs etc.)
There was some discussion around archiving older versions of
package base sources/RPMs/kiwi, and packages
so users have an option to pin or unwind their installations.
There are
some methods that may be useable for that in OBS - but, it
needs better
definition and testing.
There was some discussion around how for some distros (say
Ubuntu as an
example), we need to replace/over-ride the default golang
version that
comes with the distro to do a build of Kata. Presently we hold
binaries
in the repo for golang, and that is not acceptable in the
official SUSE
devel flows. There did seem to be a way to do this better (by
adding a
sub-package dependency).
There was a question if OBS can auto-detect new releases (of
Kata), and
automatically build. I think the answer is no, it does not do
auto
change detect/build - but, you can have a 'service file' that
wraps the
spec file builds and injects version info, so you can have a
one-step
update/build process (edit the service file and kick off a
build),
which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging
efforts
in parallel with other distros - that is, if another distro is
already
working on packaging Kata, then we do not want to invest too
much
effort on something that will then be replaced with a formal
release
from a distro. Julio - can you ascertain the current status
and plans
for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs
image.
Graham to seek out details and contacts (all Clear Linux work
is open,
and will welcome adoption).
Action: Archana had a question about sub-versioning and how
users flip
versions - we ran out of time. Archana will open a GitHub
Issue to ask/
discuss.
Next step: The plan is to initially write the specs for SUSE
in the
devel area, and then migrate the other distro builds one at a
time from
home to devel. Marco and Carlos will work together on the
devel scripts
(with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive
meeting
and thanks Marco for pushing us along with this :-)
Graham
Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential
material for
the sole use of the intended recipient(s). Any review or
distribution
by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- James --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Hey guys, sorry I've been distracted lately. I do have a WIP COPR available at: https://copr.fedorainfracloud.org/coprs/lsm5/kata/ and the sources for it are at: https://pagure.io/kata-rpm-reviews/tree/master The package reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=1585446 As far as making kata available officially in Fedora, the only option is to get the package reviews done. The pagure.io link has my changes to the spec files which I initially fetched from OBS. Are there any people interested in working together on the official fedora process? I can help out with package reviews / co-maintenance and the like. Let me know... On Mon, Oct 15, 2018 at 01:45:38PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
Hi Lokesh, Thanks for the update. Comments inline. On Tue, Oct 16, 2018 at 08:48:46AM -0400, Lokesh Mandvekar wrote:
Hey guys, sorry I've been distracted lately.
I do have a WIP COPR available at: https://copr.fedorainfracloud.org/coprs/lsm5/kata/ and the sources for it are at: https://pagure.io/kata-rpm-reviews/tree/master
The package reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=1585446
Good, I see the spec files cleanup compared with the ones we have in OBS. It is great to see that the packages already are using the golang provided form fedora. For the image the solution I see you are following is to package osbuilder. And installed this is generated as part of the post install steps. We did not consider this case but looks good :).Because the image generation could have an error (like network issues), What happen in that case?. Is the package not installed ? Or it is installed but the image is not generated? In case the package is installed but the image not generated we could have a simple script that can be used later for the user.
As far as making kata available officially in Fedora, the only option is to get the package reviews done. The pagure.io link has my changes to the spec files which I initially fetched from OBS.
Are there any people interested in working together on the official fedora process? I can help out with package reviews / co-maintenance and the like. Let me know...
I can help to provide some feedback, I'll create an account, probably nitkon may want to take a look too. I think most of the issues would be solve in your case. Do you have any blocker? - The golang vendored version is fixed in your case. - The image generation seems that have a fix also in your case. @Marco @James: So seems that if the osbuilder case works for fedora, we can keep two different models, Kiwi looks like the preferred solution for SUSE and because our current packages are manged by OBS I see this as a natural step too (to avoid work duplication). For longer term when more distros include packages for kata we can review for a generic solution if needed.
On Mon, Oct 15, 2018 at 01:45:38PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
Hey people, just letting you all know that I'm resuming work on this. Carlos (or anyone else), if you'd like to be package reviewers, please let me know, else I gotta go hunting for victims :D HTH. On Tue, Oct 16, 2018 at 02:14:17PM -0500, Jose Carlos Venegas Munoz wrote:
Hi Lokesh, Thanks for the update. Comments inline.
On Tue, Oct 16, 2018 at 08:48:46AM -0400, Lokesh Mandvekar wrote:
Hey guys, sorry I've been distracted lately.
I do have a WIP COPR available at: https://copr.fedorainfracloud.org/coprs/lsm5/kata/ and the sources for it are at: https://pagure.io/kata-rpm-reviews/tree/master
The package reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=1585446
Good, I see the spec files cleanup compared with the ones we have in OBS.
It is great to see that the packages already are using the golang provided form fedora.
For the image the solution I see you are following is to package osbuilder. And installed this is generated as part of the post install steps. We did not consider this case but looks good :).Because the image generation could have an error (like network issues), What happen in that case?. Is the package not installed ? Or it is installed but the image is not generated? In case the package is installed but the image not generated we could have a simple script that can be used later for the user.
As far as making kata available officially in Fedora, the only option is to get the package reviews done. The pagure.io link has my changes to the spec files which I initially fetched from OBS.
Are there any people interested in working together on the official fedora process? I can help out with package reviews / co-maintenance and the like. Let me know...
I can help to provide some feedback, I'll create an account, probably nitkon may want to take a look too.
I think most of the issues would be solve in your case.
Do you have any blocker?
- The golang vendored version is fixed in your case. - The image generation seems that have a fix also in your case.
@Marco @James: So seems that if the osbuilder case works for fedora, we can keep two different models, Kiwi looks like the preferred solution for SUSE and because our current packages are manged by OBS I see this as a natural step too (to avoid work duplication). For longer term when more distros include packages for kata we can review for a generic solution if needed.
On Mon, Oct 15, 2018 at 01:45:38PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
Hey Lokesh, Glad that you are back to the Kata world, we appreciate it a lot :D . I can dedicate part of my time to review but anyone else willing to review and be beta testers would be really great. Let us know what are next steps. - Carlos
-----Original Message----- From: Lokesh Mandvekar [mailto:lsm5@fedoraproject.org] Sent: Thursday, November 8, 2018 2:31 PM To: Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com> Cc: Marco Vedovati <mvedovati@suse.com>; kata-dev@lists.katacontainers.io; mpatel@redhat.com; bbreard@redhat.com Subject: Re: [kata-dev] packaging: OBS plans
Hey people, just letting you all know that I'm resuming work on this.
Carlos (or anyone else), if you'd like to be package reviewers, please let me know, else I gotta go hunting for victims :D
HTH.
On Tue, Oct 16, 2018 at 02:14:17PM -0500, Jose Carlos Venegas Munoz wrote:
Hi Lokesh, Thanks for the update. Comments inline.
On Tue, Oct 16, 2018 at 08:48:46AM -0400, Lokesh Mandvekar wrote:
Hey guys, sorry I've been distracted lately.
I do have a WIP COPR available at: https://copr.fedorainfracloud.org/coprs/lsm5/kata/ and the sources for it are at: https://pagure.io/kata-rpm-reviews/tree/master
The package reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=1585446
Good, I see the spec files cleanup compared with the ones we have in OBS.
It is great to see that the packages already are using the golang provided form fedora.
For the image the solution I see you are following is to package osbuilder. And installed this is generated as part of the post install steps. We did not consider this case but looks good :).Because the image generation could have an error (like network issues), What happen in that case?. Is the package not installed ? Or it is installed but the image is not generated? In case the package is installed but the image not generated we could have a simple script that can be used later for the user.
As far as making kata available officially in Fedora, the only option is to get the package reviews done. The pagure.io link has my changes to the spec files which I initially fetched from OBS.
Are there any people interested in working together on the official fedora process? I can help out with package reviews / co-maintenance and the like. Let me know...
I can help to provide some feedback, I'll create an account, probably nitkon may want to take a look too.
I think most of the issues would be solve in your case.
Do you have any blocker?
- The golang vendored version is fixed in your case. - The image generation seems that have a fix also in your case.
@Marco @James: So seems that if the osbuilder case works for fedora, we can keep two different models, Kiwi looks like the preferred solution for SUSE and because our current packages are manged by OBS I see this as a natural step too (to avoid work duplication). For longer term when more distros include packages for kata we can review for a generic solution if needed.
On Mon, Oct 15, 2018 at 01:45:38PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
On Thu, Nov 08, 2018 at 08:39:56PM +0000, Venegas Munoz, Jose Carlos wrote:
Hey Lokesh,
Glad that you are back to the Kata world, we appreciate it a lot :D . I can dedicate part of my time to review but anyone else willing to review and be beta testers would be really great. Let us know what are next steps.
Immediate next step for me would be to refresh the specs at https://pagure.io/kata-rpm-reviews/tree/master Let me get back to you once that's done.
- Carlos
-----Original Message----- From: Lokesh Mandvekar [mailto:lsm5@fedoraproject.org] Sent: Thursday, November 8, 2018 2:31 PM To: Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com> Cc: Marco Vedovati <mvedovati@suse.com>; kata-dev@lists.katacontainers.io; mpatel@redhat.com; bbreard@redhat.com Subject: Re: [kata-dev] packaging: OBS plans
Hey people, just letting you all know that I'm resuming work on this.
Carlos (or anyone else), if you'd like to be package reviewers, please let me know, else I gotta go hunting for victims :D
HTH.
On Tue, Oct 16, 2018 at 02:14:17PM -0500, Jose Carlos Venegas Munoz wrote:
Hi Lokesh, Thanks for the update. Comments inline.
On Tue, Oct 16, 2018 at 08:48:46AM -0400, Lokesh Mandvekar wrote:
Hey guys, sorry I've been distracted lately.
I do have a WIP COPR available at: https://copr.fedorainfracloud.org/coprs/lsm5/kata/ and the sources for it are at: https://pagure.io/kata-rpm-reviews/tree/master
The package reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=1585446
Good, I see the spec files cleanup compared with the ones we have in OBS.
It is great to see that the packages already are using the golang provided form fedora.
For the image the solution I see you are following is to package osbuilder. And installed this is generated as part of the post install steps. We did not consider this case but looks good :).Because the image generation could have an error (like network issues), What happen in that case?. Is the package not installed ? Or it is installed but the image is not generated? In case the package is installed but the image not generated we could have a simple script that can be used later for the user.
As far as making kata available officially in Fedora, the only option is to get the package reviews done. The pagure.io link has my changes to the spec files which I initially fetched from OBS.
Are there any people interested in working together on the official fedora process? I can help out with package reviews / co-maintenance and the like. Let me know...
I can help to provide some feedback, I'll create an account, probably nitkon may want to take a look too.
I think most of the issues would be solve in your case.
Do you have any blocker?
- The golang vendored version is fixed in your case. - The image generation seems that have a fix also in your case.
@Marco @James: So seems that if the osbuilder case works for fedora, we can keep two different models, Kiwi looks like the preferred solution for SUSE and because our current packages are manged by OBS I see this as a natural step too (to avoid work duplication). For longer term when more distros include packages for kata we can review for a generic solution if needed.
On Mon, Oct 15, 2018 at 01:45:38PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, I forgot to add him. On Mon, Oct 15, 2018 at 01:17:24PM -0500, Jose Carlos Venegas Munoz wrote:
+Lokesh, he has taken up packaging kata containers for Fedora.
Update: Based in the comments from today's architecture meeting.
We are going for Kiwi to build the image in our OBS packages.
- This is a working solution for SUSE standards. - For the other distros because we maintain them this is an easy path. - It would be nice to have another Distros involved to know what is a good solution for adoption. Lokesh(at Fedora): Do you have any preference/advice to make more friendly the packaging process for fedora?
- Carlos
On Fri, Oct 12, 2018 at 11:06:31AM +0200, Marco Vedovati wrote:
Hi,
I am adding some more details on the next steps.
- We should have in the next days a new devel project on OBS. - It will be set up with the target distributions and architectures. - This project will one day become the official Kata repo.
- For the golang components: we need new architecture independent package source and build instructions. - For RPM-based distro: I can kickstart this. - For DEB-based distros: volunteers needed! - For the kernel: probably the current spec file can be used, but it needs some updates: https://github.com/kata-containers/packaging/issues/211# issuecomment-426641819 . This is another things open to volunteers
- For the rootfs images/initrd: as James said, a discussion is ongoing about the possible packaging solutions: https://github.com/kata-containers/ packaging/issues/219 Ideas are welcome!
Thanks, Marco
On Thu, 2018-10-11 at 10:46 +0100, Hunt, James O wrote:
Thanks for putting this summary together Graham.
Some of the discussion around packaging the images has also found it's way onto:
- https://github.com/kata-containers/packaging/issues/219
Cheers,
James
Le jeu. 11 oct. 2018 à 10:31, Whaley, Graham <graham.whaley@intel.com> a écrit :
Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps.
Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS
Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/ 1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W8PQPlHmo/edit#slide= id.g43c0c246ee_0_157
Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool.
Question: Moving forwards, the Kata community will have to discuss/ decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.)
There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing.
There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency).
There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden.
Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please?
Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption).
Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/ discuss.
Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe).
I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-)
Graham
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-d ev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5
participants (6)
-
Hunt, James O
-
Jose Carlos Venegas Munoz
-
Lokesh Mandvekar
-
Marco Vedovati
-
Venegas Munoz, Jose Carlos
-
Whaley, Graham