search

kubernetes-sigs / cluster-api-provider-cloudstack

A Kubernetes Cluster API Provider implementation for Apache CloudStack.
https://cluster-api-cloudstack.sigs.k8s.io/
Apache License 2.0
37 stars 35 forks source link

Next CAPC release: v0.4.9 #311

Closed rohityadavcloud closed 10 months ago

rohityadavcloud commented 1 year ago

Describe the solution you'd like

I'm starting this issue on Github to have us discuss the next CAPC release, since we don't have an explicit mailing list for CAPC. Two tasks are proposed: discuss and work on the releases; and review/improve the process/guidelines/automation for CAPC release.

  1. v0.4.9-rcX has been going on for quite sometime, and those changes aren't available generally via clusterctl until we do a release. There could be opportunities to do a quicker v0.4.9 release that's just validating the already stable main branch (or with minimum stablisations) and doing another v0.5.0 that supports more recently changes in dependencies, support for newer CAPI and k8s versions.

  2. For process/guidelines/automation, we've something already that needs to be reviewed and improved if needed, request for review and comments on following:

Thoughts? Thanks.

rohityadavcloud commented 1 year ago

/cc owners and recently contributors @jweite-amazon @dims @g-gaston @chrisdoherty4 @weizhouapache @vishesh92 @davidjumani cc @vignesh-goutham @davidjumani @hrak @kiranchavala and others

g-gaston commented 1 year ago

My 2c Since it has been a bit since we don't cut a release and we have new maintainers/contributors who might not have experience with this process (I don't 😄), let's cut the next 0.4.x patch first.

With the gained experience from that release, we can see as a group if there is anything in the process we want to change/improve. And then we can go and cut 0.5.0 from main, which will probably allow us to learn even more and devise more improvements for the process.

I would recommend making 0.4.x patch as small as possible. I don't think we have a release-0.4 branch, so maybe we can cut one from the last 0.4 tag and decide what we want to add on top.

In addition, I would recommend asking someone who has run a release before to take care of these two and work with the help of someone who has. That way we spread the knowledge a bit more and reduce single points of failure. We also increase the chances of finding opportunities for improvement since this new perosn is more likely to run into any possible pitfall.

rohityadavcloud commented 1 year ago

Hi @g-gaston thanks for replying, your comments are inline with my proposal. We do a quicker v0.4.9 release with scope limited to just blocker/critical issue needed for the release, and then do a v0.5.0 that could have a wider scope in future.

I think the CAPC project can benefit from a set of governance rules or bylaws that specify (a) how the project is maintained incl. release process, (b) how to build consensus and handle disagreements. Here's an example of how the CloudStack project does it: https://cloudstack.apache.org/bylaws.html and https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases

If there are no objections we can simply decide to adopt the same rules as the parent CloudStack project, which would imply the owners of the project are sort of the project management committee (PMC) members who are tasked with the project governance, voting and releases related matter including inviting new owners. And as far as releases are concerned we can make it simply the following:

  1. Only a project owner (https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/blob/main/OWNERS) can be a release manager and any project owner can propose to do a release.
  2. Github milestones can be used to track/scope issues and PRs for a release. (such as https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/milestone/3)
  3. The documentation for release process already exists and can be improved as required here: https://cluster-api-cloudstack.sigs.k8s.io/development/releasing
  4. The release manager ideally should be a member of GCR repo or ask an existing member to assist with publication in the k8s-infra-staging-capi-cloudstack https://github.com/kubernetes/k8s.io/blob/main/groups/sig-cluster-lifecycle/groups.yaml#L122

If there are no objections, I propose myself as release manager (RM) for v0.4.9 (or happy if others want to do this - the bottomline - this need to be asap), and ask any other owners to volunteer as RM for v0.5.0 - @jweite-amazon @davidjumani @dims @g-gaston @chrisdoherty4 @weizhouapache @vishesh92

Thoughts?

dims commented 1 year ago

@rohityadavcloud technically you all fall under sig-cluster-lifecycle. So please run it by the chairs and leads - https://github.com/kubernetes/community/blob/master/sig-cluster-lifecycle/README.md#leadership

rohityadavcloud commented 1 year ago

Thanks for replying @dims we can do once between the owners and others in community we get feedback, and agree with some sort of proposal/way ahead. In fact if there's any available/existing guideline on governance and releases, then we should stick to that under k8s-sigs. Let us know if there are any?

g-gaston commented 1 year ago

@rohityadavcloud I volunteer for the v0.4.9 release! :)

rohityadavcloud commented 1 year ago

Thanks @g-gaston - I'm happy to assist you. For the v0.4.9, can you share a timeline for the same?

I've triaged existing tickets here - https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/milestone/3 could you have a look and help resolve as many as possible (or move them to next milestone). And I suggest you to do the following:

  1. Once you're ready and there are no blockers/critical issues in the milestone, please create a RC and push a git tag for the same, you can get some assistance from @dims on how to create Github release (RCs).
  2. Run e2e tests on the RC and create the yaml files, test locally it works. Cut further RCs as required.
  3. Add yourself to https://github.com/kubernetes/k8s.io/blob/main/groups/sig-cluster-lifecycle/groups.yaml#L122
  4. Get one or two more volunteers from the community who can test/verify the release/RC. When ready, bump the git tag to v0.4.9 and follow the process at https://cluster-api-cloudstack.sigs.k8s.io/development/releasing to publish the artifacts. Test using clusterctl to verify the same.
rcastrogiovanni commented 1 year ago

Hi @rohityadavcloud, At the moment it is not possible to use clusterAPI if in Cloudstack you use projects. Is this something that can be added to the new release? Thanks, Roberto

rohityadavcloud commented 1 year ago

Hi @rcastrogiovanni I see https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/issues/217 tagged to the next v0.4.9 milestone. We should definitely try as it's a very common and asked-for improvement by multiple people, it would depend on the release manager @g-gaston to lead the effort - who can advise us.

g-gaston commented 1 year ago

Update: I'm still working on this. It will probably take at least a couple more weeks since I won't be able to work on this at all next week, but I will resume the work the following week.

rohityadavcloud commented 11 months ago

Thanks @g-gaston it's been going on for months now, can we conclude the v0.4.9 RCs and GA the release?

g-gaston commented 11 months ago

Update: lastest RC is ready to be promoted. Pending some testing green light by the community and resolving one last discussion about v1beta3 in slack.