Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
the
size/XL
|
/assign @jichenjc /hold |
k8s-ci-robot
added
the
do-not-merge/hold
|
@sbueringer: GitHub didn't allow me to assign the following users: prankul88. Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| ||Cluster API v1alpha1 (v0.1)|Cluster API v1alpha2 (v0.2)| | ||
| |-|-|-| | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|| | ||
| |OpenStack Provider v1alpha2 (v0.2)||✓| |
There was a problem hiding this comment.
should we say master instead of v0.2? or v0.2 branch?
There was a problem hiding this comment.
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.
ok, then why we need v0.2 ? as master actually works fine and we can have release-0.2 when v1alpha3 out..
There was a problem hiding this comment.
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.
0.2 stands for the tags make sense to me.
README.md
Outdated
| |-|-|-|-|-| | ||
| |OpenStack Provider v1alpha1 (ea309e7f)|✓|✓|✓|✓| | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|✓|✓|✓| | ||
| |OpenStack Provider v1alpha2 (v0.2)|✓|✓|✓|✓| |
There was a problem hiding this comment.
technically we can say we support v0.2 on P/Q/R, but we haven't try P/Q/R on v0.2, correct?
There was a problem hiding this comment.
Yup, no idea what we can put here. We didn't really change the code from 0.1 in this regard. I personally only tried it on Queens (and on @chrigl 's OpenStack, not sure which version it is)
There was a problem hiding this comment.
Should I remove all checkmarks except Queens?
There was a problem hiding this comment.
My environments is Stein, installed according to OpenStack community installation guide.
There was a problem hiding this comment.
I updated the table to reflect what should work and what's actually tested
| 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
| **NOTE**: Because the user is able to customize any `user-data`, it is also possible to deploy older versions. | ||
| But we won't provide any examples or working templates. See [user-data in the examples](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/tree/master/cmd/clusterctl/examples/openstack/provider-component/user-data). | ||
| |OpenStack Provider v1alpha1 (release-0.1 branch)|✓|✓|✓| | ||
| |OpenStack Provider v1alpha2 (v0.2)|||✓| |
There was a problem hiding this comment.
master branch or v0.2 branch will be better? v0.2 seems a tag..
There was a problem hiding this comment.
Same as above 0.2 stands for all our 0.2.x releases (which will be tags)
|
PTAL @jichenjc @hidekazuna |
|
@jichenjc @hidekazuna Can I get a /lgtm to get this merged? :) |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
lgtm
* update release doc, fix manager image tag * update doc * fixed typo * review fixes * review * review * review fix * update Openstack support table
5 participants
Final doc pr before v0.2.0.
I tried to shorten the documentation a bit, because to be honest we're not able to keep that much documentation up-to-date. Most of the previous documentation was easily accessible by taking a quick glimpse into the code. Also there will be a lot more documentation from the Cluster API project itself (https://cluster-api.sigs.k8s.io). I will also add a PR in the main repo in the week or so to add the OpenStack provider to the quickstart.
Fixes #380
P.S. I would like to create the release after this PR is merged, but I will open another issue for this.