github/open-cluster-management
1
0
Fork 0
mirror of https://github.com/open-cluster-management-io/ocm.git synced 2026-08-18 03:36:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Populate repo with useful documentations about the ocm project

Browse Source 
Signed-off-by: Mike Ng <ming@redhat.com>
This commit is contained in:
Mike Ng
2021-10-01 16:59:51 -04:00
parent b3a26c7721
commit 4816e6ca83
21 changed files with 827 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/dco.yml
+21
View File
@@ -0,0 +1,21 @@
name: DCO
on:
workflow_dispatch: {}
pull_request:
branches:
- main
jobs:
dco_check:
runs-on: ubuntu-latest
name: DCO Check
steps:
- name: Get PR Commits
id: 'get-pr-commits'
uses: tim-actions/get-pr-commits@master
with:
token: ${{ secrets.GITHUB_TOKEN }}
- name: DCO Check
uses: tim-actions/dco@master
with:
commits: ${{ steps.get-pr-commits.outputs.commits }}
CODE_OF_CONDUCT.md
+80
View File
@@ -0,0 +1,80 @@
# Contributor Covenant Code of Conduct
The Open Cluster Management project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
The English text of the CNCF Code of Conduct is made available here for reference.
Additional [language translations](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) are available.
## Our pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery, and unwelcomed sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior, and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at [acm-contact@redhat.com](mailto:acm-contact@redhat.com). All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html.
[Homepage]: https://www.contributor-covenant.org
For answers to common questions about this Code of Conduct, see
https://www.contributor-covenant.org/faq.
CONTRIBUTING.md
+43
View File
@@ -0,0 +1,43 @@
**Table of Contents**
- [Contributing guidelines](#contributing-guidelines)
- [Terms](#terms)
- [Certificate of Origin](#certificate-of-origin)
- [DCO Sign Off](#dco-sign-off)
- [Code of Conduct](#code-of-conduct)
- [Contributing a patch](#contributing-a-patch)
- [Issue and pull request management](#issue-and-pull-request-management)
# Contributing guidelines
## Terms
All contributions to the repository must be submitted under the terms of the [Apache Public License 2.0](https://www.apache.org/licenses/LICENSE-2.0).
## Certificate of Origin
By contributing to this project, you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the [DCO](DCO) file for details.
## DCO Sign Off
You must sign off your commit to state that you certify the [DCO](DCO). To certify your commit for DCO, add a line like the following at the end of your commit message:
```
Signed-off-by: John Smith <john@example.com>
```
This can be done with the `--signoff` option to `git commit`. See the [Git documentation](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--s) for details.
## Code of Conduct
The Open Cluster Management project has adopted the CNCF Code of Conduct. Refer to our [Community Code of Conduct](CODE_OF_CONDUCT.md) for details.
## Contributing a patch
1. Submit an issue describing your proposed change to the repository in question. The repository owners will respond to your issue promptly.
2. Fork the desired repository, then develop and test your code changes.
3. Submit a pull request.
## Issue and pull request management
Anyone can comment on issues and submit reviews for pull requests. In order to be assigned an issue or pull request, you can leave a `/assign <your Github ID>` comment on the issue or pull request.
DCO
+37
View File
@@ -0,0 +1,37 @@
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
MISSION.md
+86
View File
@@ -0,0 +1,86 @@
## Mission Statement
We seek to form an open community around multicluster and multicloud scenarios for containerized applications. We propose to anchor the initial community around github.com/open-cluster-management-io and open-cluster-management.io.
We seek to add value to the community by a focused effort around many aspects of how users are deploying and managing Kubernetes clusters today. We seek to engage other parts of the community and both contribute to pre-existing efforts and invite contributors in those communities to cross-collaborate as part of this project.
We are initially interested in the following lifecycles associated with expanding adoption of Kubernetes:
1. Cluster Lifecycle. How are clusters provisioned, upgraded, registered, scaled out or in and decommissioned?
2. Policy & Configuration Lifecycle. How are clusters configured, audited, secured, access controlled, managed for quota or cost?
3. Application Lifecycle. How are containerized or hybrid applications delivered across one or more clusters? How are those applications kept current with ongoing changes?
Our initial goals for the project are to define API and reference implementations for common use cases that we have observed as users grow their adoption of Kubernetes:
- Define API for cluster registration independent of cluster CRUD lifecycle.
- Define API for work distribution across multiple clusters.
- Define API for dynamic placement of content and behavior across multiple clusters.
- Define API for policy definition to ensure desired configuration and security settings are auditable or enforceable.
- Define API for distributed application delivery across many clusters and the ability to deliver ongoing updates.
We expect that over time, the project will make sense to contribute to an appropriate foundation for stewardship. In the meantime, we intend to engage and contribute where similar use cases are under active discussion in the community including the Kubernetes SIG-Multicluster and SIG-Policy workgroups, among others.
## Contributor Code of Conduct
The Open Cluster Management project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). The English text of the CNCF Code of Conduct is made available here for reference. Additional [language translations](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) are available.
"As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
The use of sexualized language or imagery
Personal attacks
Trolling or insulting/derogatory comments
Public or private harassment
Publishing others' private information, such as physical or electronic addresses, without explicit permission
Other unethical or unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior in Open Cluster Management may be reported by contacting `openclustermanagement@gmail.com`." [[Reference](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)]
## Getting Involved
Anyone who is interested in getting involved is welcome to contribute in a number of ways:
Join the recurring meeting forums (see below) to provide input as a stakeholder and help validate proposed use cases.
Suggest enhancements via github.com/open-cluster-management-io/enhancements for consideration to the community.
Contribute to development via Pull Request for new enhancements or defect fixes.
Suggested API and implementations will be accepted in accordance with the broad use cases outlined above. Our goal is to reserve the Kubernetes API Group open-cluster-management.io for well-reviewed and widely supported features.
## Community Meeting Forum
To ensure opportunities for broad user contributions, a public forum will be hosted to demonstrate new capabilities, solicit feedback and offer a forum for real time Q&A.
Meeting recordings will be posted to a YouTube channel for offline viewing.
The community meets on a bi-weekly cadence on Thursday at 15:30 UTC.
Meeting Agenda and Topics can be found here: https://github.com/open-cluster-management-io/community/projects/1.
## Communication
See the following options to connect with the community:
- [Website](https://open-cluster-management.io)
- [Slack](https://kubernetes.slack.com/archives/C01GE7YSUUF)
- [Mailing group](https://groups.google.com/g/open-cluster-management)
- [Community meetings](https://github.com/open-cluster-management-io/community#community-meetings)
- [YouTube channel](https://www.youtube.com/channel/UC7xxOh2jBM5Jfwt3fsBzOZw)
## Governance
* **Committees** The project will initially have a 3-person Bootstrap Steering Committee. The present steering
committee is a bootstrap committee and we want to work towards a future state where there is community representation and community determination of the steering committee members. In that future state, the steering committee size may be expanded to meet the needs of the community.
* **Special Interest Group (SIG)** are persistent open groups that focus on a part of the project.
SIGs must have open and transparent proceedings.
Anyone is welcome to participate and contribute provided they follow the Code of Conduct.
The project has a bootstrap [sig-architecture](sig-architecture) to provide oversight and guidance on API and architectural aspects of the project to ensure a consistent and robust technical foundation for the project. More SIGs are expected to be established with the evolution of the project.
## Public Roadmap
Roadmap is tracked using GitHub project. See https://github.com/open-cluster-management-io/community/projects/2
## Security Response
Please see https://github.com/open-cluster-management-io/ocm/blob/main/SECURITY.md.
OWNERS
+5
View File
@@ -0,0 +1,5 @@
approvers:
- deads2k
- jnpacker
- mikeshng
- qiujian16
README.md
+60 -1
View File
@@ -1 +1,60 @@
# ocm
![image](assets/ocm-logo.png)
Welcome! The open-cluster-management.io project is focused on enabling end-to-end visibility and control across your Kubernetes clusters.
Please read the [MISSION.md](MISSION.md) statement for more information.
The open-cluster-management architecture uses a hub - agent model. The hub centralizes control of all the managed clusters. An agent, which we call the klusterlet, resides on each managed cluster to manage registration to the hub and run instructions from the hub.
![image](assets/ocm-arch.png)
There are a number of key use cases that are enabled by this project, and are categorized to 3 sub projects.
### Cluster Lifecycle: Cluster registration and management
The API and controllers provide the function for cluster registration, manifests delivery, cluster scheduling and addon management. Simple core functions connect clusters, such as the klusterlet, to the hub. Other components run on this base. The following repositories describe the API and controllers:
* https://github.com/open-cluster-management-io/api
* https://github.com/open-cluster-management-io/registration
* https://github.com/open-cluster-management-io/work
* https://github.com/open-cluster-management-io/placement
* https://github.com/open-cluster-management-io/registration-operator
* https://github.com/open-cluster-management-io/addon-framework
### Application Lifecycle: Delivery, upgrade, and configuration of applications on Kubernetes clusters
* Centrally create, update, and delete Kubernetes clusters across multiple private and public clouds.
* Automatically deploy applications to specific clusters by subscribing to different workload (resource) channels, such as GitHub, Helm repository, ObjectStore, and resource templates.
The application model defines a Kubernetes-first way of describing the application. Your existing Kubernetes apps or `kustomized` apps can be adapted with the addition of a few new objects: `Channel`, and `Subscription`. Changes made to the app are then easily delivered to managed clusters based on the dynamic placement engine.
The following repositories describe the underlying API and controllers for the app model:
* https://github.com/open-cluster-management-io/multicloud-operators-subscription
* https://github.com/open-cluster-management-io/multicloud-operators-channel
### GRC: Governance, Risk and Compliance across Kubernetes clusters
* Use prebuilt security and configuration controllers toto enforce policies on Kubernetes configuration across your clusters.
Policy controllers allow the declarative expression of a desired condition that can be audited or enforced against a set of managed clusters. _Policies_ allow you to drive cross-cluster configuration or validate that a certain configuration explicitly does not exist.
The following repositories describe the underlying API and controllers for the GRC model:
* https://github.com/open-cluster-management-io/config-policy-controller
* https://github.com/open-cluster-management-io/governance-policy-status-sync
* https://github.com/open-cluster-management-io/governance-policy-spec-sync
* https://github.com/open-cluster-management-io/governance-policy-template-sync
* https://github.com/open-cluster-management-io/governance-policy-propagator
### Get connected
See the following options to connect with the community:
- [Website](https://open-cluster-management.io)
- [Slack](https://kubernetes.slack.com/archives/C01GE7YSUUF)
- [Mailing group](https://groups.google.com/g/open-cluster-management)
- [Community meetings](https://github.com/open-cluster-management-io/community/projects/1)
- [YouTube channel](https://www.youtube.com/channel/UC7xxOh2jBM5Jfwt3fsBzOZw)
SECURITY.md
+4
View File
@@ -0,0 +1,4 @@
# Security Response
If you've found a security issue that you'd like to disclose confidentially please contact Red Hat's Product Security team.
Details at https://access.redhat.com/security/team/contact
assets/ocm-arch.drawio
+1
View File
File diff suppressed because one or more lines are too long
assets/ocm-arch.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 253 KiB

assets/ocm-logo.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

common_repo_templates/CODE_OF_CONDUCT.md
+1
View File
@@ -0,0 +1 @@
Refer to our [Open Cluster Management Community Code of Conduct](https://github.com/open-cluster-management/community/blob/main/CODE_OF_CONDUCT.md)
common_repo_templates/CONTRIBUTING_template.md
+51
View File
@@ -0,0 +1,51 @@
**Table of Contents**
- [Contributing guidelines](#contributing-guidelines)
- [Terms](#terms)
- [Certificate of Origin](#certificate-of-origin)
- [DCO Sign Off](#dco-sign-off)
- [Code of Conduct](#code-of-conduct)
- [Contributing a patch](#contributing-a-patch)
- [Issue and pull request management](#issue-and-pull-request-management)
- [Pre-check before submitting a PR](#pre-check-before-submitting-a-pr)
# Contributing guidelines
## Terms
All contributions to the repository must be submitted under the terms of the [Apache Public License 2.0](https://www.apache.org/licenses/LICENSE-2.0).
## Certificate of Origin
By contributing to this project, you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the [DCO](https://github.com/open-cluster-management/community/blob/main/DCO) file for details.
## DCO Sign Off
You must sign off your commit to state that you certify the [DCO](https://github.com/open-cluster-management/community/blob/main/DCO). To certify your commit for DCO, add a line like the following at the end of your commit message:
```
Signed-off-by: John Smith <john@example.com>
```
This can be done with the `--signoff` option to `git commit`. See the [Git documentation](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--s) for details.
## Code of Conduct
The Open Cluster Management project has adopted the CNCF Code of Conduct. Refer to our [Community Code of Conduct](https://github.com/open-cluster-management/community/blob/main/CODE_OF_CONDUCT.md) for details.
## Contributing a patch
1. Submit an issue describing your proposed change to the repository in question. The repository owners will respond to your issue promptly.
2. Fork the desired repository, then develop and test your code changes.
3. Submit a pull request.
## Issue and pull request management
Anyone can comment on issues and submit reviews for pull requests. In order to be assigned an issue or pull request, you can leave a `/assign <your Github ID>` comment on the issue or pull request (PR).
## Pre-check before submitting a PR
<!-- Customize this template for your repository -->
Before submitting a PR, please perform the following steps:
- List of steps to perform before submitting a PR.
common_repo_templates/LICENSE
+201
View File
@@ -0,0 +1,201 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
common_repo_templates/OWNERS_template.md
+11
View File
@@ -0,0 +1,11 @@
# Owners
See the OWNERS docs: https://git.k8s.io/community/contributors/guide/owners.md
## Approvers
- _list_of_github_ids_here_
## Reviewers
- _list_of_github_ids_here_
common_repo_templates/README_template.md
+36
View File
@@ -0,0 +1,36 @@
# Replace with <repo_name>
[![License](https://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html)
## What is <repo_name>?
Example header: What is the `multicloud-operators-subscription` repository?
Example description: With `<repo_name>`, you can....
Go to the [Contributing guide](CONTRIBUTING.md) to learn how to get involved.
## Getting started
- Steps for development:
- Be sure every step is a task the user needs to take.
- You can also give the user the results or summary after the step. But results/summaries are not numbered as steps.
- Keep tasks goal oriented.
- Sub steps are tabbed in under the main step.
- Steps for deployment:
- List of steps for deployment.
- Please be aware of the community's [deployment images](https://github.com/open-cluster-management/community#deployment-images) special note.
- Steps for test:
- List of steps for testing.
- Check the [Security guide](SECURITY.md) if you need to report a security issue.
## References
- The `<repo_name>` is part of the `open-cluster-management` community. For more information, visit: [open-cluster-management.io](https://open-cluster-management.io).
- Optional: List and link of additional references if needed.
common_repo_templates/SECURITY.md
+1
View File
@@ -0,0 +1 @@
Refer to our [Community Security Response](https://github.com/open-cluster-management/community/blob/main/SECURITY.md).
common_repo_templates/open_task_template.md
+41
View File
@@ -0,0 +1,41 @@
# Task title
<!-- Task title should be a gerund phrase. For example, "Importing a cluster"-->
Brief paragraph description of what you are doing with the task. For example: You can import an existing cluster from another cloud provider to manage it.
## Prerequisites
<!-- List things to do before you can complete this task. You can leave this section out, if necessary. -->
Before you can import a cluster, you must have the following running:
- A running hub cluster to manage the imported cluster.
- A supported platform that is running a cluster on a you want to import.
<!-- You can use links to other information or procedures, if necessary, to guide the user to more information about the prerequisite. -->
## Main procedure
<!-- Now that you have listed the prerequisites, add your main procedure. If there is more than one menthod of completing the procedure (CLI and GUI, for example), make each one a section at this level. If you only have one section here, it will be similar to the name of the topic. It is based on an action, but does not have to be a gerund phrase. For example: "Import the cluster". -->
<!-- Add your lead in and main procedure. The steps in the procedure should be numbered steps. -->
To import a cluster, complete the following steps:
1. Step 1...
<!-- Each step should begin with an action, when possible. For example: Log in to the hub cluster. -->
<!-- Each step should represent one action, unless it is a menu cascade: Example of representing a menu cascade: Select **Actions** > **Delete**. Menu cascade is multiple steps from the same menu action. -->
<!-- If a step is complicated, you can add a secondary list of substeps to a step. The same guidelines apply to substeps that apply to steps. -->
1. Substep A...
2. Substep B...
3. Substep C...
2. Step 2...
<!-- You can add an unordered list to a step, if necessary. -->
- Item
- Item
3. Step 3...
<!-- After the final step of the procedure, provide a way for the user to know that the procedure was successful. -->
After importing the cluster successfully, you can access the cluster by...
sig-architecture/README.md
+5
View File
@@ -0,0 +1,5 @@
# SIG Architecture
The SIG Architecture maintains and evolves the design principles of Open Cluster Management, and provides a consistent body of expertise necessary to ensure architectural consistency over time.
The [charter](charter.md) defines the scope and governance of the sig-architecture
sig-architecture/api_changes.md
+110
View File
@@ -0,0 +1,110 @@
# Changing the API
This document is oriented at developers who want to change existing APIs for Open Cluster Management. As Open Cluster Management uses [Kubernetes Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to define its own API resources, a set of API change guidelines will also be applied to any [Kubernetes Custom Resource Definitions].
## Contents
- [Things you should consider before you change the APIs](#things-you-should-consider-before-you-change-the-apis)
- [Versions in the APIs](#versions-in-the-apis)
- [How to Add a New Version](#how-to-add-a-new-version)
- [Migrate stored objects to the new version](#migrate-stored-objects-to-the-new-version)
### Things you should consider before you change the APIs
Before attempting a change to the API, you should familiarize yourself with a number of [existing API types](https://github.com/open-cluster-management/api) and with the API conventions.
You should also consider the compatibility of the API changes. Open Cluster Management considers forwards and backwards compatibility of its APIs as top priority.
An API change is considered compatible if it:
- adds new functionality that is not required for correct behavior (e.g., does not add a new required field)
- does not change existing semantics, including:
* the semantic meaning of default values and behavior
* interpretation of existing API types, fields, and values
* which fields are required and which are not
* mutable fields do not become immutable
* valid values do not become invalid
* explicitly invalid values do not become valid
Let's see an example for compatible API changes.
In a hypothetical API of version `v1beta1`, the Application struct looks like this:
```golang
// v1beta1
type Application struct {
Name string `json:"name"`
Replicas int `json:"replicas"`
}
```
If we add a new `Param` field, it is safe to add new fields without changing the API version, so we can simply change it to:
```golang
// v1beta1
type Application struct {
Name string `json:"name"`
Replicas int `json:"replicas"`
Param string `json:"param"`
}
```
The version of the API is still `v1beta1`, we just need to add default value for the new `Param` field so that API calls and stored objects that used to work will continue to work.
Next time, we may consider to allow multiple `Param` values, then we can't simply replace `Param string` with `Param []string`. We have two options for this case:
1. Add new `Params []string` field and the new field must be inclusive of the singular field, also we must handle all the cases of version skew, multiple clients, rollbacks and so on.
2. Bump a new version(eg. `v1beta2`) for the API object and replace the old singular field `Param string` with the new plural field `Params []string`, we must implement api conversion logic to/from versioned APIs so that older clients that only know the singular field will continue to succeed and produce the same results as before the change, while newer clients can use your change without impacting older clients.
```golang
// v1beta2
type Frobber struct {
Height int
Width int
Params []string
}
```
### Versions in the APIs
For most API changes, you may find it easiest to change the versioned APIs first. Since Open Cluster Management uses Custom Resource Definitions to define its own API resources, when a CustomResourceDefinition is created, the first version is set in the CustomResourceDefinition `spec.versions` list to an appropriate stability level and a version number. For example `v1beta1` would indicate that the first version is not yet stable. All custom resource objects will initially be stored at this version. As our API evolve, we need to upgrade the API to a new version with conversion between API representations. For example, we may begin using the `v1beta1` API, later it might be necessary to add new version such as `v1beta2`.
### How to add a new version
1. Pick a conversion strategy. Since custom resource objects need to be able to be served at both versions, that means they will sometimes be served at a different version than their storage version. In order for this to be possible, the custom resource objects must sometimes be converted between the version they are stored at and the version they are served at. If the conversion involves schema changes and requires custom logic, a conversion webhook should be used.
2. If using conversion webhooks, create and deploy the conversion webhook. See the [Webhook conversion](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion) for more details.
3. Update the CustomResourceDefinition to include the new version in the `spec.versions` list with `served:true`. Also, set `spec.conversion` field to the selected conversion strategy. If using a conversion webhook, configure `spec.conversion.webhookClientConfig` field to call the webhook.
Once the new version is added, clients may incrementally migrate to the new version. It is perfectly safe for some clients to use the old version while others use the new version.
### Migrate stored objects to the new version
Although it is safe for clients to use both the old and new version before, during and after upgrading the objects to a new stored version, but we need to deprecate and drop the old version support, for those API objects created in the old version before we introduce the new version, we need to migration the stored object in the APIServer yo new version.
We have two options to acheived this:
Option 1: Use the [Storage Version Migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
Option 2: Manually upgrade the existing objects to a new stored version
We prefer to option 1 because the migration process with option 1 is totally transparent to users, while option 2 need users' assistent and may introduce service interrupt.
For option 1, all we need to do is creating a migration request by the `StorageVersionMigration` resource similar to below:
```yaml
apiVersion: migration.k8s.io/v1alpha1
kind: StorageVersionMigration
metadata:
name: multiclusterobservabilities-storage-version-migration
spec:
resource:
group: observability.open-cluster-management.io
resource: multiclusterobservabilities
version: v1beta2
```
Then the migration work will be done in a few seconds:
```bash
$ oc get storageversionmigration multiclusterobservabilities-storage-version-migration -o jsonpath="{.status}"
{"conditions":[{"lastUpdateTime":"2021-04-06T07:10:12Z","status":"True","type":"Succeeded"}]}
```
sig-architecture/charter.md
+33
View File
@@ -0,0 +1,33 @@
# SIG Architecture Charter
## Scope
The SIG Architecture maintains and evolves the design principles of Open Cluster Management, and provides a consistent body of expertise that is necessary to ensure architectural consistency over time.
### In scope
#### Code, Binaries, Docs, and Services
- *API definitions*
- *Architectural renderings*
- *API conventions*
- [API changes](api_changes.md)
- *Design principles*
- *Deprecation policy*
- *Enhancement Proposal process*
#### Cross-cutting and Externally-Facing Processes
- API review process
- Design documentation management
- Deprecation policy management
- Architectural initiative backlog management
### Out of scope
### Additional responsibilities of Chairs
- Ensure the agenda is populated 24 hours in advance of the community meeting, or the community meeting is cancelled.
- Report the Project status at events and community meetings, when possible.
- Actively promote diversity and inclusion in the Community.
- Uphold the Code of Conduct, especially in terms of personal behavior and responsibility.