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.