[Incubation] Meshery Incubation Application

[ctcarrier]

Meshery Incubation Application

v1.5 This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/meshery/meshery Project Site: https://meshery.io/ Sub-Projects: https://github.com/meshery/schemas, https://github.com/meshery/meshkit, https://github.com/meshery/meshery-istio, https://github.com/meshery/meshsync, https://github.com/meshery/meshery-linkerd, https://github.com/meshery/meshery-operator Communication: https://slack.meshery.io/

Project points of contacts: Meshery Maintainers, [email protected]

Incubation Criteria Summary for Meshery

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

https://github.com/meshery/meshery/blob/master/ADOPTERS.md

Application Process Principles

Suggested

N/A

Required

• [ ] Give a presentation and engage with the domain specific TAG(s) to increase awareness
  • This was completed and occurred on 04-Nov-2021, and can be discovered at https://www.youtube.com/watch?v=FPMde6EHcJU&t=3936s.

• [x] TAG provides insight/recommendation of the project in the context of the landscape

https://docs.meshery.io/project/community

• [x] All project metadata and resources are vendor-neutral.

As an open source, vendor neutral project, Meshery was created out of the necessity to enable platform engineers, site reliability engineers, DevSecOps teams - all engineers to collaborate in the management of their infrastructure and workloads.

• [ ] Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
• Met during Project's application on 01-Mar-2024: https://github.com/cncf/toc/pull/1264

• [ ] Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

• [ ] Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Installation Concepts Guides Contributing and Community Reference

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• [x] Clear and discoverable project governance documentation.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md

• [x] Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

• [x] Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

• [ ] Governance clearly documents vendor-neutrality of project direction.

• [ ] Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md https://docs.meshery.io/project/contributing https://docs.meshery.io/project/community

• [ ] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#contributors https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#maintainership

• [ ] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#becoming-a-maintainer https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#emeritus-maintainers

• [ ] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

• [ ] If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

https://github.com/meshery/meshery/blob/master/MAINTAINERS.md

Required

• [ ] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

https://github.com/meshery/meshery/blob/master/MAINTAINERS.md

• [x] A number of active maintainers which is appropriate to the size and scope of the project.

• [x] Code and Doc ownership in Github and elsewhere matches documented governance roles.

• [x] Document agreement that project will adopt CNCF Code of Conduct.

https://github.com/meshery/meshery/blob/master/CODE_OF_CONDUCT.md

• [x] CNCF Code of Conduct is cross-linked from other governance documents.

https://github.com/meshery/meshery/blob/master/CODE_OF_CONDUCT.md

• [ ] All subprojects, if any, are listed.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• [x] Contributor ladder with multiple roles for contributors.

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#contributors https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#maintainership

Required

• [x] Clearly defined and discoverable process to submit issues or changes.

https://docs.meshery.io/project/contributing

• [x] Project must have, and document, at least one public communications channel for users and/or contributors.

Slack and mailing lists documented on website.

• [x] List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

Documented on website.

• [x] Up-to-date public meeting schedulers and/or integration with CNCF calendar.

https://meshery.io/calendar

• [x] Documentation of how to contribute, with increasing detail as the project matures.

https://layer5.io/community/newcomers

• [x] Demonstrate contributor activity and recruitment.

Engineering Principles

Suggested

• [x] Roadmap change process is documented.

https://github.com/meshery/meshery/blob/master/ROADMAP.md

• [x] History of regular, quality releases.

https://github.com/meshery/meshery/releases

Required

• [x] Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

https://docs.meshery.io/project/overview

• [x] Document what the project does, and why it does it - including viable cloud native use cases.

https://docs.meshery.io/concepts/logical

• [x] Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

https://github.com/meshery/meshery/blob/master/ROADMAP.md

• [x] Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

https://docs.meshery.io/concepts/architecture

• [x] Document the project's release process.

https://docs.meshery.io/project/contributing/build-and-release

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

• [x] Clearly defined and discoverable process to report security issues.

https://docs.meshery.io/project/security-vulnerabilities

• [x] Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

https://github.com/meshery/meshery/blob/master/GOVERNANCE.md#github-project-administration

• [x] Document assignment of security response roles and how reports are handled.

https://docs.meshery.io/project/security-vulnerabilities

• [x] Document Security Self-Assessment.

https://docs.meshery.io/project/security-vulnerabilities#evaluation

• [x] Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

https://www.bestpractices.dev/en/projects/3564

Ecosystem

Suggested

N/A

Required

• [x] Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

https://github.com/meshery/meshery/blob/master/ADOPTERS.md

• [x] Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• [ ] TOC verification of adopters.

Refer to the Adoption portion of this document.

• [x] Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

https://docs.meshery.io/extensibility/integrations

Additional Information

[angellk]

@ctcarrier thank you for submitting Meshery's application for incubation. Your presentation to TAG Network was almost 3 years ago - please work with TAG Network and/or TAG Runtime to provide an update on Project meshery scope, architecture and community. cc: @leecalcote @raravena80

[angellk]

Note: replaces #1264

[craigbox]

@ctcarrier thank you for submitting Meshery's application for incubation. Your presentation to TAG Network was almost 3 years ago - please work with TAG Network and/or TAG Runtime to provide an update on Project meshery scope, architecture and community. cc: @leecalcote @raravena80

Reading the project website:

A self-service engineering platform, Meshery, is the open source, cloud native manager that enables the design and management of all Kubernetes-based infrastructure and applications (multi-cloud). Among other features, As an extensible platform, Meshery offers visual and collaborative GitOps, freeing you from the chains of YAML while managing Kubernetes multi-cluster deployments.

Would TAG App Delivery not be the appropriate group?

[leecalcote]

Meshery's August 15th, 2024 prevention to TAG Runtime - meeting recording and slides

[angellk]

@ctcarrier In preparation for Meshery to be picked up by a TOC member after the KubeCon freeze period -- and prior to TOC member assignment -- please:

• review the definition of an adopter
• verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
• submit information for each adopter to the Adopter Interview Questionnaire form
• complete the required Security Self Assessment
• review the Meshery GitHub and Website for all documents linked that are not open to the public, for example:
  • Meshery Test Plan linked on the Meshery Build and Release page
  • Roadmap Document linked at the bottom of the ROADMAP.md

[angellk]

@craigbox

Would TAG App Delivery not be the appropriate group?

With a lot of overlap between different domains with some projects - if the TOC reviewer determines the TAG Runtime presentation was insufficient, they can ask additional clarifying questions and/or ask the TAG App Delivery to conduct a Domain Technical Review.

[leecalcote]

It's noted in the description above, but it's worth noting that Meshery's incubation application was originally filed here - https://github.com/cncf/toc/pull/1264 - on March 1st, 2024.

[angellk]

Link to the slack thread discussion for anyone seeing this in the future 😅 Thanks @leecalcote for staying on top of this.

[angellk]

@ctcarrier In preparation for Meshery to be picked up by a TOC member after the KubeCon freeze period -- and prior to TOC member assignment -- please:

• review the definition of an adopter

• verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and

• submit information for each adopter to the Adopter Interview Questionnaire form

• complete the required Security Self Assessment

• review the Meshery GitHub and Website for all documents linked that are not open to the public, for example:

  • Meshery Test Plan linked on the Meshery Build and Release page
  • Roadmap Document linked at the bottom of the ROADMAP.md

@ctcarrier @leecalcote The adopters have not been submitted and the ROADMAP document has not been made public. Also, the Release and Test Plan document links to a number of non-vendor neutral resources including the Slack, YouTube. You noted that work was being done to address these concerns - could you please link the issue created in the Meshery GitHub repo?

[miacycle]

@angellk thank you for this note. I know that one of these earlier points of feedback was an agenda item in a weekly Meshery development meeting a couple weeks ago. I don't believe that the other items listed here were on the maintainer team's radar, though. I've opened and issue (https://github.com/meshery/meshery/issues/13455), and send an email to the maintainers mailing list, asking for it to be treated with high priority. I'm guessing that these will be addressed today.

[jamieplu]

I have just finished ensuring that all documents in the project's shared drive are publicly accessible with Comment permission enabled.

[vishalvivekm]

I have addressed the vendor neutrality concerns on slack, youtube.

[leecalcote]

✅ A collection of adopter interviewees has been submitted.

[hortison]

A note related to Security Self-Assessment, Meshery is and has been at "passing" in level in the OpenSSF Best Practices.

[craigbox]

I have addressed the vendor neutrality concerns on slack, youtube.

https://slack.meshery.io/ is a redirect to https://layer5io.slack.com/. Likewise, http://discuss.meshery.io is a redirect to http://discuss.layer5.io. The "Community meetings" link on https://meshery.io/ is now a link back to https://meshery.io/, but all the meetings remain on the Layer5 YouTube channel.

Changing or hiding the links does not reflect the intention of the requirement: the project, when at incubation level, the resources (in this case the communication and community channels) must be neutral, i.e. not using resources belonging to the company that created the project.

[codeknight03]

Hey @craigbox , Kudos for up keeping vendor neutrality for CNCF projects.

Just wanted to add, as a contributor to different CNCF projects, the slack experience with meshery does feel better than having a single channel in CNCF slack because this way we get different channels for focussed discussions around different meshery components.

[craigbox]

@codeknight03 You can 100% have your own Slack (Kubernetes, Envoy, Cilium, Istio etc all do). The issue was that it can't be the Layer5 Slack (any more than it could be the Slack of any other contributing vendor).

I see that the Layer5 slack has now been rebranded as the Meshery Slack. Assuming the experience is vendor-neutral (not being automatically invited to join a Layer5 program on joining, for example; I am not suggesting you do this, this is just a hypothetical) then I expect the requirements are now met for Slack.

Side note: if you prefer, you could also have many channels on the CNCF slack (as Argo does)

[angellk]

@codeknight03 @leecalcote @ctcarrier One of the adopters is a duplicate company - please submit 2 more adopters from separate organizations!

verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and

submit information for each adopter to the Adopter Interview Questionnaire form

[angellk]

Confirmed 4 adopters have been added - moving Meshery project to 'Ready for assignment'. As a TOC member is available, they will self-assign and reach out for next steps @codeknight03 @leecalcote @ctcarrier

As the request is 5-7, please add one more, otherwise the TOC member may need to close the application until the project has sufficient adopters for Incubation.

[leecalcote]

Digital Ocean has recently added themselves to the Meshery adopter's list.

[angellk]

@ctcarrier @leecalcote I am picking this up to conduct a Due Diligence for the TOC. I will create a slack channel for us to use in the CNCF slack as well as reach out for a Kick-Off call with the project maintainers.