[RFC] Software Release Management Proposal

[kubernetes-retired]

[RFC] Software Release Management Proposal

[deepak-vij]

Hi Malte/Ionel, a gentle nudge regarding getting your feedback/comments on the proposed release process for Firmament codebase. We look forward to hearing from you. Accordingly, we will proceed with follow on steps within CAMSA/Firmament environment. Thanks.

Regards,
Deepak Vij

cc: @shivramsrivastava @timothysc @ICGog @ms705 @dhilipkumars

[ms705]

The proposed release process looks fine to me, although it seems unnecessary to have Firmament and Poseidon releases necessarily be in lockstep (there may be no need to cut a Firmament release if nothing has changed). However, if it simplifies things and @ICGog agrees, that's fine by me.

Presumably the later sections of the document are still to come?

[deepak-vij]

Agree Malte, release process should detect this and create a new release for Firmament or Poseidon only if there are any changes made to them. We will keep that in mind once we start building out the release process. thanks.

[ICGog]

Yes, I agree. I see no reason why do couple the Firmament and Poseidon releases.

The other thing worth mentioning is that we're already using Travis CI to build after each commit and run the tests Poseidon CI. I think we should probably extend that CI, unless we have better CI alternatives. This CI is also configured to show nice code coverage.

[deepak-vij]

Hi Ionel, thanks for your comment. Although, I am confused a bit. IIUC, what you are suggesting is that we keep Poseidon unit testing coverage in Travis CI. What we are currently planning is the following:

1. Firmament unit testing stays in CamSaS
2. Poseidon unit testing as part of the new incubation repo. Shiva is already working towards it and scheduled to wrap this task up early next week.
3. Integration testing suite as part of the new incubation repo. This primarily ensure that the complete workflow pipeline works (K8S -> Poseidon -> Firmament) by mocking K8S & Firmament. Dhilip is already working towards that and plan on completing this by next week.
4. end-to-end testing environment as part of new incubation repo. This tests the complete end-to-end functional capabilities between K8S, Poseidon/Heapster, & Firmament scheduler.

Please let me know, if this makes sense. Thanks.

[dhilipkumars]

@ms705 and @ICGog, Kubernetes ecosystem has built its own CI / CD pipeline jobs and bots which is far more friendly to K8s specific jobs. Like bringing up a k8s cluster and running tests against it. etc., We will endup doing a lot of work if we had to replicate what the k8s ci system is currently doing. Plus the cluster environments are sig sponsored. we could keep the travis ci as additional verification step.

We do not propose to change firmament CI system.

The reason we proposed to align Poseidon's and Firmament's release cycle as close as possible because more releases down the line it might become a lot harder to map which version of Poseidon works well with which version of Firmament. This release coupling is temporary until firmament has its own big community and starts following a specific release cycle on its own. (in parallel we are also working to simplify the whole installation process using helm/chart that would automatically resolve version mapping).

If you want a different release cycle (frequency and versioning) for firmament what would that be?

[dhilipkumars]

ref: #helm/charts#4479

[deepak-vij]

@shivramsrivastava is in the process of incorporating a new section on the main read.me page that captures all details for coordinating Firmament & Poseidon repos. He should be done soon.

[deepak-vij]

See the following link for description of coordinated release process in order for Firmament & Poseidon repos to work together in lockstep. We also incorporated all this as part of the read.me page. Closing this issue now.

https://github.com/kubernetes-sigs/poseidon/blob/master/docs/releases/release-process.md