Pr refactor doc #474
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,192 +1,148 @@ | ||
| # Kubernetes Cluster API Provider OpenStack | ||
|
|
||
| [](https://goreportcard.com/report/kubernetes-sigs/cluster-api-provider-openstack) | ||
|
|
||
| ------ | ||
|
|
||
| Kubernetes-native declarative infrastructure for OpenStack. | ||
|
|
||
| ## What is the Cluster API Provider OpenStack | ||
|
|
||
| The [Cluster API][cluster_api] brings | ||
| declarative, Kubernetes-style APIs to cluster creation, configuration and | ||
| management. | ||
|
|
||
| The API itself is shared across multiple cloud providers allowing for true OpenStack | ||
| hybrid deployments of Kubernetes. It is built atop the lessons learned from | ||
| previous cluster managers such as [kops][kops] and | ||
| [kubicorn][kubicorn]. | ||
|
|
||
|
|
||
| ## Launching a Kubernetes cluster on OpenStack | ||
|
|
||
| Check out the [getting started guide](./docs/getting-started.md) for launching a cluster on OpenStack. | ||
|
|
||
| ## Features | ||
|
|
||
| - Native Kubernetes manifests and API | ||
| - Choice of Linux distribution (as long as a current cloud-init is available) | ||
| - Support for single and multi-node control plane clusters | ||
| - Deploy clusters with and without LBaaS available | ||
| - Support for security groups | ||
| - Doesn't use SSH for bootstrapping nodes | ||
|
|
||
| ------ | ||
|
|
||
| ## Compatibility with Cluster API and Kubernetes Versions | ||
|
|
||
| This provider's versions are compatible with the following versions of Cluster API: | ||
|
|
||
| ||Cluster API v1alpha1 (v0.1)|Cluster API v1alpha2 (v0.2)| | ||
| |-|-|-| | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|| | ||
| |OpenStack Provider v1alpha2 (v0.2)||✓| | ||
|
|
||
| This provider's versions are able to install and manage the following versions of Kubernetes: | ||
|
|
||
| ||Kubernetes 1.13|Kubernetes 1.14|Kubernetes 1.15| | ||
| |-|-|-|-| | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|✓|✓| | ||
| |OpenStack Provider v1alpha2 (v0.2)|||✓| | ||
|
Contributor
There was a problem hiding this comment. master branch or v0.2 branch will be better? v0.2 seems a tag..
Member
Author
There was a problem hiding this comment. Same as above 0.2 stands for all our 0.2.x releases (which will be tags) |
||
|
|
||
| This provider's versions are able to install Kubernetes to the following versions of OpenStack: | ||
|
|
||
| ||OpenStack Pike|OpenStack Queens|OpenStack Rocky|OpenStack Stein| | ||
| |-|-|-|-|-| | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|✓|✓|✓| | ||
| |OpenStack Provider v1alpha2 (v0.2)|+|✓|+|✓| | ||
|
|
||
| Key: | ||
| * `✓` tested | ||
| * `+` should work, but we weren't able to test it | ||
|
|
||
| Each version of Cluster API for OpenStack will attempt to support two Kubernetes versions. | ||
|
|
||
| **NOTE:** As the versioning for this project is tied to the versioning of Cluster API, future modifications to this | ||
| policy may be made to more closely aligned with other providers in the Cluster API ecosystem. | ||
|
|
||
| ------ | ||
|
|
||
| ## Operating system images | ||
|
|
||
| Note: Cluster API Provider OpenStack relies on a few prerequisites which have to be already | ||
| installed in the used operating system images, e.g. a container runtime, kubelet, kubeadm,.. . | ||
| Reference images can be found in [kubernetes-sigs/image-builder](https://github.com/kubernetes-sigs/image-builder/tree/master/images/capi). If it isn't possible to pre-install those | ||
| prerequisites in the image, you can always deploy and execute some custom scripts | ||
| through the [KubeadmConfig](https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm). | ||
|
|
||
| ------ | ||
|
|
||
| ## Documentation | ||
|
|
||
| Documentation is in the `/docs` directory | ||
|
|
||
| ## Getting involved and contributing | ||
|
|
||
| Are you interested in contributing to cluster-api-provider-openstack? We, the | ||
| maintainers and community, would love your suggestions, contributions, and help! | ||
| Also, the maintainers can be contacted at any time to learn more about how to get | ||
| involved via the [cluster-api-openstack channel on Kubernetes Slack][slack] or the | ||
| [SIG-Cluster-Lifecycle Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle). | ||
|
|
||
| In the interest of getting more new people involved we try to tag issues with | ||
| [`good first issue`][good_first_issue]. | ||
| These are typically issues that have smaller scope but are good ways to start | ||
| to get acquainted with the codebase. | ||
|
|
||
| We also encourage ALL active community participants to act as if they are | ||
| maintainers, even if you don't have "official" write permissions. This is a | ||
| community effort, we are here to serve the Kubernetes community. If you have an | ||
| active interest and you want to get involved, you have real power! Don't assume | ||
| that the only people who can get things done around here are the "maintainers". | ||
|
|
||
| We also would love to add more "official" maintainers, so show us what you can | ||
| do! | ||
|
|
||
| This repository uses the Kubernetes bots. See a full list of the commands [here][prow]. | ||
| Please also refer to the [Contribution Guide](CONTRIBUTING.md) and the [Development Guide](docs/development.md) for this project. | ||
|
|
||
| ## Code of conduct | ||
|
|
||
| Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md). | ||
|
|
||
| ## Github issues | ||
|
|
||
| ### Bugs | ||
|
|
||
| If you think you have found a bug please follow the instructions below. | ||
|
|
||
| - Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate. | ||
| - Get the logs from the cluster controllers. Please paste this into your issue. | ||
| - Open a [new issue][new_issue]. | ||
| - Remember that users might be searching for your issue in the future, so please give it a meaningful title to help others. | ||
| - Feel free to reach out to the Cluster API community on the [Kubernetes Slack][slack]. | ||
|
|
||
| ### Tracking new features | ||
|
|
||
| We also use the issue tracker to track features. If you have an idea for a feature, or think you can help Cluster API Provider OpenStack become even more awesome follow the steps below. | ||
|
|
||
| - Open a [new issue][new_issue]. | ||
| - Remember that users might be searching for your issue in the future, so please | ||
| give it a meaningful title to help others. | ||
| - Clearly define the use case, using concrete examples. | ||
| - Some of our larger features will require some design. If you would like to | ||
| include a technical design for your feature, please include it in the issue. | ||
| - After the new feature is well understood, and the design agreed upon, we can | ||
| start coding the feature. We would love for you to code it. So please open | ||
| up a **WIP** *(work in progress)* pull request, and happy coding. | ||
|
|
||
|
|
||
| <!-- References --> | ||
|
|
||
| [cluster_api]: https://github.com/kubernetes-sigs/cluster-api | ||
| [kops]: https://github.com/kubernetes/kops | ||
| [kubicorn]: http://kubicorn.io/ | ||
| [slack]: https://kubernetes.slack.com/messages/cluster-api-openstack | ||
| [good_first_issue]: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22good+first+issue%22 | ||
| [prow]: https://go.k8s.io/bot-commands | ||
| [new_issue]: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/new | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,48 @@ | ||
|
|
||
| # Releasing | ||
|
|
||
| ## Output | ||
|
|
||
| ### Expected artifacts | ||
|
|
||
| 1. A container image of the `cluster-api-provider-openstack` controller manager | ||
|
|
||
| ### Artifact locations | ||
|
|
||
| 1. The container image is found in the registry `us.gcr.io/k8s-artifacts-prod/capi-openstack/` with an image | ||
| name of `capi-openstack-controller` and a tag that matches the release version. For | ||
| example, in the `v0.2.0` release, the container image location is | ||
| `us.gcr.io/k8s-artifacts-prod/capi-openstack/capi-openstack-controller:v0.2.0` | ||
|
|
||
|
|
||
| ## Process | ||
|
|
||
| For version v0.x.y: | ||
|
|
||
| 1. An issue is proposing a new release with a changelog since the last release | ||
| 1. Create an annotated tag `git tag -a v0.x.y -m v0.x.y` | ||
| 1. To use your GPG signature when pushing the tag, use `git tag -s [...]` instead | ||
| 1. Push the tag to the GitHub repository `git push origin v0.x.y` | ||
| 1. Note: `origin` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack` | ||
| 1. Run `make release` to build artifacts and push the images to the staging bucket | ||
| 1. Follow the [Image Promotion process](https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io#image-promoter) to promote the image from the staging repo to `us.gcr.io/k8s-artifacts-prod/capi-openstack` | ||
| 1. Create a release (with the above mentioned release notes) in GitHub based on the tag created above | ||
| 1. The release issue is closed | ||
| 1. An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] cluster-api-provider-openstack $VERSION is released` | ||
|
|
||
| <!-- TODO add link to image promote PR after the first release --> | ||
|
|
||
| ### Permissions | ||
|
|
||
| Releasing requires a particular set of permissions. | ||
|
|
||
| * Push access to the staging gcr bucket ([kubernetes/k8s.io/k8s.gcr.io/k8s-staging-capi-openstack/OWNERS](https://github.com/kubernetes/k8s.io/blob/master/k8s.gcr.io/k8s-staging-capi-openstack/OWNERS) | ||
| * Tag push access to the GitHub repository ([kubernetes/org/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml](https://github.com/kubernetes/org/blob/master/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml#L136-L137)) | ||
| * GitHub release creation access ([kubernetes/org/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml](https://github.com/kubernetes/org/blob/master/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml#L136-L137)) | ||
|
|
||
| ## Staging | ||
|
|
||
| There is a post-submit Prow job running after each commit on master which pushes a new image to the staging repo (`gcr.io/k8s-staging-capi-openstack/capi-openstack-controller:latest`). Following configuration is involved: | ||
| * staging gcr bucket: [kubernetes/k8s.io/k8s.gcr.io/k8s-staging-capi-openstack/manifest.yaml](https://github.com/kubernetes/k8s.io/blob/master/k8s.gcr.io/k8s-staging-capi-openstack/manifest.yaml) | ||
| * post-submit `post-capi-openstack-push-images` Prow job: [kubernetes/test-infra/config/jobs/image-pushing/k8s-staging-capi-openstack.yaml](https://github.com/kubernetes/test-infra/blob/master/config/jobs/image-pushing/k8s-staging-capi-openstack.yaml)) (corresponding dashboard is located at [https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images](https://testgrid.k8s.io/sig-cluster-lifecycle-image-pushes#post-capi-openstack-push-images)) | ||
| * Google Cloud Build configuration which is used by the Prow job: [kubernetes-sigs/cluster-api-provider-openstack/cloudbuild.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/master/cloudbuild.yaml) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we say master instead of v0.2? or v0.2 branch?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I wanted to release 0.2.0 based on v1alpha2 and we shouldn't branch away a release-0.2 before v1alpha3 I would like to keep 0.2 (see also: https://github.com/kubernetes-sigs/cluster-api-provider-aws#compatibility-with-cluster-api-and-kubernetes-versions (their list is not up-to-date))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, then why we need v0.2 ? as master actually works fine and we can have release-0.2 when v1alpha3 out..
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0.2 stands for the tags 0.2.0, 0.2.1, etc.. I think it's more precise to say CAPO 0.2 then something on the master branch. And it's the same as CAPA is doing. If we don't want to release then master would be the only option. But I think when we're doing releases it's far better to tell our users which release supports what, so they don't have to figure out which release comes from which branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0.2 stands for the tags make sense to me.