Versions Compared

Old Version 4

changes.mady.by.user Scot Steele

Saved on

compared with

New Version 5

changes.mady.by.user Gergely Csatari

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents
absoluteUrltrue

Participants

Antitrust policies

Moselle retrospective Gergely Csatari 

Let's discuss what went well, what was problematic in Moselle and what should we change.

What went well

  • New content in RA2
  • New content in RM, however scope was not always clear
  • Working together with CNCF CNF Testsuite
  • Lots of support from the team across the board

What was not going very well

  • Chaotic doc conversion with lots of late changes and non review-ed merges
    • rst limitations and quirks
    • limited PoC / trial conversion
  • Long time pending pr-s without any reviews
  • Lots of cat herding
  • Still have some disconnect between the RA and RC communities.  Always going to be an issue between converting requirements into deliverables.  Basically converting requirements into user stories and tests.  Some of the requirements cannot be tested. 
  • Need to better articulate the must haves, should haves, and nice to haves 
  • Recruiting new members into the community
  • Anuket has not developer potential in upstream projects, like CNF Testsuite, Kubernetes of OpenStack
  • Limited resources on RI2, RC2 and Functest potential for single point of failure.
  • Functest's bus factor is 1, what happens if Cedric Ollivier wins the lottery?

What should we change

  • Add documentation guidelines
    • heavily commented template, for example, with comments indicating heading level, simple and complex table formats (use of csv?), etc.
  • Clarify contribution guidelines
  • Do a better job of converting RAx requirements into user stories and test cases that can be used in RCx.
  • More community outreach to recruit new member companies – propose session at ONS Summit
  • Need to add field trials against the Anuket Assured badge to gain traction in the community
  • Can we work with CNCF to develop field trials of not only the Anuket infrastructure piece, but also toe CNF/VNF piece.
  • Need to relook at Functest as it is currently a single point of failure (Cedric)
  • Maybe we should create a doc team with a sub-stream leader who should review and merge the pr-s outside of the scope of doc sub-streams

Anuket Scope issue

Following up the DTF session [2] and the discussion on the TSC meeting on 2022.07.12 [1] I try to frame the scope problem in this mail and propose some timeslots for a regular call to sort the topic out.


The scope of Anuket Specifications is constantly expanding without having a broader consensus about the change, than one sub-project or pr. On top of that the scope of Anuket itself (defined in the charter [3]) is different from the scope of the Anuket Specifications defined in chapter 0 [4]. I think this difference is not inconsistent as the scope of Anuket Specifications is a subset of the scope of Anuket.


In my view the focus of Anuket specifications should be still on the integration of cloud infrastructures (IaaS or CaaS) and their workloads and the IaaS and CaaS components should be available as open source. Anuket Specifications in RM or RA level should not specify infrastructure requirements not affecting the runtime capabilities of the infrastructure, requirements different from the IaaS abstraction or requirements not available in open source.

Infrastructure requirements not affecting the runtime capabilities are simply not relevant when [VC]NF-s and cloud infrastructure is integrated. Specifying them does not help to solve this problem. Moving to higher abstraction then IaaS or CaaS by defining PaaS requirements is something we need to look into due to the fact that both OpenStack and Kubernetes implements some features in this domain, but we should not require features not implemented in these. To require features which are not implemented yet in open source would need a capability to implement these features in open source and Anuket does not have this capability at the moment. Collecting the gaps is useful only if there is a hope that these gaps are closed. Require features what we all know do not exist leads to specifications without implementation.

We agreed to have a meeting series to have an agreement of these topics. Please feel this doodle to find the correct timeslot for the meeting: https://doodle.com/meeting/participate/id/dLgmEJvb

How to document documentation best practices

AoB

  • None