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-xW5W…
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.
Hello everyone,
Sorry for another cross post so soon.
In the land before time we had Stackforge.
Stackforge gave non-OpenStack projects a place to live with their own clearly defined "not OpenStack" namespacing. As the wheel of time spun we realized that many Stackforge projects were becoming OpenStack projects and we would have to migrate them. This involved Gerrit downtimes to rename things safely. To ease the pain of this, the TC decided that all projects developed in the OpenStack Infrastructure could live under the OpenStack git namespace to simplify migrations.
Unfortunately this had the effect of creating confusion over which projects were officially a part of OpenStack, and whether or not projects that were not OpenStack could use our project hosting. Stackforge lived on under a different name, "unofficial project hosting", but many potential infrastructure users either didn't understand this or didn't want that strong association to OpenStack for their project hosting [0].
Turns out that we want to be able to host OpenStack and non-OpenStack projects together without confusion in a way that makes all of the projects involved happy. In an effort to make this a reality the OpenStack Infra team has been working through a process to rename itself to make it clear that our awesome project infrastructure and open collaboration tooling is community run, not just for OpenStack, but for others that want to be involved. To this end we've acquired the opendev.org domain which will allow us to host services under a neutral name as the OpenDev Infrastructure team.
The OpenStack community will continue to be the largest and a primary user for the OpenDev Infrastructure team, but our hope in making our infrastructure services more inclusive is that we'll also attract new contributors, which will ultimately benefit OpenStack and other open infrastructure projects.
Our goals for OpenDev are to:
* Encourage additional active infrastructure contributors to help us scale. Make it clear that this is community-run tooling & infrastructure and everyone can get involved.
* Make open source collaboration tools and project infrastructure more accessible to those that want it.
* Have exposure to and dogfooding of OpenStack clouds as viable open source cloud providers.
* Enable more projects to take advantage of the OpenStack-pioneered model of development and collaboration, including recommended practices like code review and gating.
* Help build relationships with new and adjacent open source projects and create an inclusive space for collaboration and open source development.
Much of this is still in the early planning stages. This is the infrastructure team's current thinking on the subject, but understand we have an existing community from which we'd like to see buy-in and involvement. To that end we have tried to compile a list of expected FAQ/Q&A information below, but feel free to followup either on this thread or with myself for anything we haven't considered already.
Any transition will be slow and considered so don't expect everything to change overnight. But don't be surprised if you run into some new HTTP redirects as we reorganize the names under which services run. We'll also be sure to keep you informed on any major (and probably minor) transition steps so that they won't surprise you.
Thank you,
Clark
[0] It should be noted that some projects did not mind this and hosted with OpenStack Infra anyway. ARA is an excellent example of this.
FAQ
* What is OpenDev?
OpenDev is community-run tools and infrastructure services for collaboratively developing open source software.
The OpenDev infrastruture team is the community of people who operate the infrastructure under the umbrella of the OpenStack Foundation.
* What services are you offering? What is the expected timeline?
In the near-term we expect to transition simple services like etherpad hosting to the OpenDev domain. It wil take us months and potentially up to a year to transition key infrastructure pieces like Git and Gerrit.
Example services managed by the team today include etherpad, wiki, the zuul and nodepool CI system, git and gerrit, and other minor systems like pbx conferencing and survey tools.
* Where will these services live?
We've acquired opendev.org and are planning to set up DNS hosting very soon. We will post a simple information page and FAQ on the website and build it out as necessary over time.
* Why are you changing from the OpenStack infrastructure team to the OpenDev infrastructure team?
In the same way we want to signal that our services are not strictly for OpenStack projects, and that not every project using our services is an official part of OpenStack, we want to make it clear that our team also serves this larger community.
* Who should use OpenDev services? Does it have to be projects related to OpenStack, or any open source projects?
In short, open source contributors who share our community values, especially those who might want to help contribute to improving and maintaining OpenDev infrastructure over time. Projects using OpenDev hosted git and gerrit services should have an OSI-approved license.
* Will the OpenStack projects live at git.opendev.org?
All projects hosted with OpenDev will live at git.opendev.org. For backwards compatibility reasons, at the very least git.openstack.org will be an alias for git.opendev.org for the forseeable future. The same is true of the other existing whitelabel git domains such as git.starlingx.io and git.zuul-ci.org. Whether or not other 'whitelabel' domains are created is an open question. Given a neutral domain name, the desire for such sites may not seem as necessary.
* Does this mean the infrastruture team will be spending less time on OpenStack?
OpenStack will continue to be the largest and a primary user for the OpenDev Infrastructure team, and we expect that our work will benefit all users. There will be additional effort required as we transition to the new namespace and reorganize, but over the long term we hope this inclusive approach will help us attract new contributors and ultimately benefit OpenStack.
* Are OpenStack cloud test resources the only resources that will be used?
At the present time all of the donated resources come to us from a combination of OpenStack Public and Private clouds. Nobody from any of the proprietary clouds has asked to donate resources to us. It is conceivable that the shift to OpenDev could open the door to those cloud providers wanting to donate some cloud resources. Assuming nodepool supports talking to those clouds, it is certainly a possibility, but at the moment it's all speculation.
* Is this name associated with the OpenDev Conferences (opendevconf.com) that OpenStack Foundation has previously organized?
Yes! They are related, albeit indirectly. To quote from the conference's promotional site, "the focus is on bringing together composable open infrastructure technologies across communities and industries." The possibility of cross-promotional tie-ins could prove synergistic, since the conference and the collaboratory we're building share a lot of similar values and goals, and are ultimately supported by the same donors, community and foundation.
* How will OpenDev be governed? Will the OpenStack TC retain oversight over it?
The OpenDev governance discussion is just getting started, but like all OSF-supported initiatives, OpenDev follows the Four Opens, so it will ultimately be directly governed by OpenDev contributors. While it won't be under the sole oversight of the OpenStack Technical Committee anymore, OpenDev users (in particular OpenStack) should be represented in the governance model so that they can feed back their requirements to the OpenDev team.
Katazens,
We’re looking for a volunteer to help maintain a Kata package for the Fedora distribution. Please get in touch if you are looking to get involved and are will to help in this space.
Thanks!
Eric
Hello everyone,
My apologies for cross posting but wanted to make sure the various developer groups saw this.
Rather than use the Infrastructure Onboarding session in Berlin [0] for infrastructure sysadmin/developer onboarding, I thought we could use the time for user onboarding. We've got quite a few new groups interacting with us recently, and it would probably be useful to have a session on what we do, how people can take advantage of this, and so on.
I've been brainstorming ideas on this etherpad [1]. If you think you'll attend the session and find any of these subjects to be useful please +1 them. Also feel free to add additional topics.
I expect this will be an informal session that directly targets the interests of those attending. Please do drop by if you have any interest in using this infrastructure at all. This is your chance to better understand Zuul job configuration, the test environments themselves, the metrics and data we collect, and basically anything else related to the community developer infrastructure.
[0] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22950/i…
[1] https://etherpad.openstack.org/p/openstack-infra-berlin-onboarding
Hope to see you there,
Clark
There’s a proposal to move from PST to UTC for scheduling our architecture forum. The call is currently on Monday’s at 8am PST, 11pm in CST, UTC 15:00, though after this weekend it’ll be 7am in for us west-coasters.
I want to make sure we have key stakeholders and devs on the call who’d like to be. I suggested a few times for call going forward in a google poll, [1]. Please provide feedback.
Thanks,
Eric
[1] - https://goo.gl/forms/bdTf0R5orH9IdxO72
I've updated the kata herder rota the end of the year. **Note** - a few weeks there we might want to check and shuffle or annotate:
- next week (2018-11-12) The two nominees (myself and Eric) will be away from our desks - so that week is *currently empty* of herders. If you can help, please go place yourself in the table
- The week of Christmas (2018-12-24) - well, I'm pretty sure many people will not be available then. Carlos, you are currently listed in that week, you may wish to update/edit that slot!
- The week of New Year (2018-12-31) - similarly, I predict a quiet week. Frank and Sebastien - you are currently listed in that slot...
As ever, for all other herders, you may wish to check which slots you have landed in by default and update accordingly wrt your availability.
As ever - many thanks for your time and efforts!
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
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.
Good morning. And happy GuyFawkes (bonfire!) night (https://en.wikipedia.org/wiki/Guy_Fawkes_Night) - well, OK, maybe that is a little U.K. centric ;-)
Herders this week are:
Frank (who I already see has had a good pass through the open PRs!)
Sebastien
And iirc James said he will try to step up this week when he can.
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
Happy hunting!
(I will copy/extend the herder table to the end of the year and send out a separate email for that update...)
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.
Hi!
For those who will be in Berlin for the Summit, please mark your
calendars for the following Forum session:
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22815/c…
This session is an opportunity for the technical leadership of all OSF
projects to meet, discuss pain points, compare experiences and explore
synergies. We expect to have members of the OpenStack, Kata Containers,
StarlingX, Airship, and Zuul communities around. It will be the
occasion, among other things, to compare the initial governance
structures for the pilot projects.
If you can make it, please join us !
--
Thierry Carrez (ttx)
Good morning,
The gatekeeper schedule for this week is looking a bit thin - take this as a call for help/volunteers....
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
James and I are both a bit swamped, so we are short on EMEA reviewers, the APAC slot is empty, and I believe Carlos will not be back online until Wednesday - so, things are looking rather thin right now.
If you have some spare cycles to do some reviews (and kudos to those of you already actively doing that this morning!), then please dive in and help out. You don't have to be in the herding table to contribute ;-)
Many thanks!
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.