Anuket Project
2021-04-29 - [Anuket RA2] - Meeting Agenda and Minutes
Attendees:
@Riccardo Gasparetto Stori (Vodafone)
@Pankaj.Goyal (AT&T)
@Tom Kivlin(Vodafone)
@Karine Sevilla (Orange)
@Gergely Csatari (Nokia)
Agenda and Minutes:
Antitrust notices
Walk-in items
PR 2355: Require Node Feature Discovery and Device Plugins
content is ok, can also mention dev plugins are needed for SRIOV as well
introduce the topic of Device plugins within issue 2255 - in the architecture
only one comment pending, then ok to go
PR 2362 - merged
PR 2378 - k8s api policy
opened https://github.com/cntt-n/CNTT/issues/2380 for feature gates
@Gergely Csatari backwards compatibility: if a new GA API breaks the backwards compatibility with the Beta version of that API, we must run both the GA and the beta to avoid breaking the workload
@Cédric Ollivier: workloads should adapt instead, split supported APIs and backwards compatibility into two PRs
PR 2332: ch6 with tables listing the K8S SIG features that are mandatory or not.
issue 976: forgot to actually delete the placeholder appendix - now in PR 2372
Issues https://github.com/cntt-n/CNTT/issues/2341 and https://github.com/cntt-n/CNTT/issues/2349 - Target kubernetes version and accepted API versions
FYI: upstream now targeting 3 releases per year, not 4 (starting from 1.25 iirc): https://github.com/kubernetes/enhancements/pull/2567/files
Can we target 1.21 for Kali?
1.21 should be EOS 03/22 → upstream supports 12 months starting from 1.19
Kali+1 will be released at the end of 21
which means we have time to release kali+1 before 1.21 is unsupported
Must decide on a generic policy to define which APIs are acceptable
Suggestion is to keep upstream API versions (ie v1)
first we should decide on which APIs RA2 needs, then for each one, decide on the release.
cluster LCM: had a go at ch 123: https://github.com/cntt-n/CNTT/pull/2373
requirements on clusters being LCM'd and cluster customisation are required as workloads need e.g. node customisation, real time kernels, etc
cluster configuration is an issue - today, operators refer to RA2 for cluster requirements, but have to write own reqs for cluster LCM
specify the what, not the how - should not mandate how implementations do cluster lcm, but only what the end result is
RI and RC impact - if a spec is in ch4, it must be tested against
to be added to next TSC discussion
AOB & Project review
Permanent FYI
CNF Working Group within CNCF - https://docs.google.com/document/d/1YFimQftjkTUsxNGTsKdakvP7cJtJgCTqViH2kwJOrsc/edit
This also incorporates the previous requirements gathering exercise
Actions/Next steps
June 7/10 virtual Face to Face - will need to come up with a list of topics to discuss, to inform the wider community and get feedback
Please register https://community.lfnetworking.org/events/details/linux-foundation-lfn-developer-testing-forums-presents-lfn-developer-testing-forum-june-2021/
Topics can be created here under the Section titled "Create a topic Proposal ...."
Meeting Recording