Community Question: best release cadence of the module terraform-azurerm-aks

[zioproto]

Contributors of this module regularly ask when the next release will happen after their specific PR was merged.

We don't have a documented release cadence, so folks using this module in production cannot predict when the release will happen.

Please thumbs up this issue if you would like a regular release cadence.
This would mean that issues and PRs will be labeled with milestones, and once a PR is merged it should be possible to manage the expectation of when the next release will happen.

Please also share if you are using this module in production and if you could help with PR reviews.

Please also share how we can make this process right for you. How often should the release happen ?

thanks

[zioproto]

Tagging recent contributors to have their feedback:

@the-technat @mazilu88 @nlamirault @gzur @digiserg @eyenx @vermacodes @jvelasquez @viters @matelang

[eyenx]

I would very much appreciate a regular release cadence for this module.

Please also share if you are using this module in production and if you could help with PR reviews.

Yes we are using it for Production on several clusters. I would very much try to help with PRs where I can

Please also share how we can make this process right for you. How often should the release happen ?

I think a release every other months would be a good start.

[lonegunmanb]

Wow I think this pull request is really a good question. I'd like to wait for a while, let's say one week to gather more feedbacks. One release per month or two weeks looks good to me since we've a CI pipeline to ensure the code quality. I hope folks who're using this module can share your thought so we can do better, thanks everyone!

[the-technat]

Thanks for asking. We @swisspost would appreciate a regular release candence.

Please also share if you are using this module in production and if you could help with PR reviews.

We are on our way to using this module in production (we got multiple internal customers waiting for a productive platform). And sure we are happy to help with PR reviews.

Please also share how we can make this process right for you. How often should the release happen ?

For us monthly or bimonthly would be more than enough

[viters]

We @the-heart-rnd would also appreciate a regular release cadence.

Please also share if you are using this module in production and if you could help with PR reviews.

We are on our way to use a lot more AKS and manage all of that using TF and this module. I do not know if we are familiar with the TF/AKS enough yet to bring value to this module, but we most certainly will try. As we use it more, we will gain better understanding at what would be useful. Please mention me if I could be of help.

Please also share how we can make this process right for you. How often should the release happen ?

I agree with @the-technat with "monthly or bimonthly would be more than enough".

[matelang]

Thanks @zioproto for opening this discussion and for asking for input.

I also use this module with several clients, and I think all of them would benefit of regular release cadence.

If the CI is readily available, maybe we could implement automatic semantic versioning based on regulated/standard/intelligent commit messages (or PR titles).

Regardless whether the maintainers want to keep manually releasing based on an agreed upon cadence or to implement an automated solution I am in favor of having a constant cadence.

[lonegunmanb]

If the CI is readily available, maybe we could implement automatic semantic versioning based on regulated/standard/intelligent commit messages (or PR titles).

Hi @matelang, I've considered using automatic semantic release but now I'm hesitated to do so due to the following reasons:

1. Automatic semantic release requires a strict commit message format that I think would raise the bar for our contributors.
2. IaC code hate breaking changes, if we launch major upgrades that contain breaking change frequently, that might scare our users. I'm kind of old school so I would control a limited time window for breaking changes, and release changes that won't break the existing code asap.
3. I want our users treat major version upgrade very carefully, so I think we could make a regular cadence for breaking changes, let's say four or six months?

Anyway, all these're my personal thought, I would like to hear the voice from this growing community. And finally, thanks folks for using this module!

[the-technat]

@lonegunmanb thanks for sharing your concerns about automatic semantic releasing.

To your second point some experience on our side: If you look at the terraform-aws-eks module, the equivilent to this module, they release major versions quite friquently and it's always a nightmare to upgrade. We spent weeks to prepare and test that Terraform would successfully upgrade the v17 to v18 code without breaking anything. It included several manual steps and state migrations (on every cluster!). So as you said, IaC hates breaking changes, although they seem to be necessary sometimes. But then they should be introduced in a major version and should have an according upgrade guide that explains what changed inside.

[lonegunmanb]

@lonegunmanb thanks for sharing your concerns about automatic semantic releasing.

To your second point some experience on our side: If you look at the terraform-aws-eks module, the equivilent to this module, they release major versions quite friquently and it's always a nightmare to upgrade. We spent weeks to prepare and test that Terraform would successfully upgrade the v17 to v18 code without breaking anything. It included several manual steps and state migrations (on every cluster!). So as you said, IaC hates breaking changes, although they seem to be necessary sometimes. But then they should be introduced in a major version and should have an according upgrade guide that explains what changed inside.

Thanks for sharing @the-technat , your experience is definitely the most precious knowledge we've learnt so far. As you said I have concerns that we should treat major version upgrade with extreme caution, and we would try to avoid manual state migration as best as we could.

Sometimes we cannot upgrade a module without breaking changes and heavily manually operations, eg: terraform-azurerm-compute, this module used resources that were superseded from AzureRM 3.0, my approach is creating a new parallel module . We'd like to keep Azure module stable since we don't have as many modules as Aws community has now so it's still possible for us to maintain such parallel modules.

Stability will be our most important feature for the foreseeable future, that's the promise I could give to this community for now.

[lonegunmanb]

To the community: I've added dependabot to keep go.mod file updated, and the bot would check the dependencies every Monday. Let's say, I'll check, test and merge prs raised by dependabot every Monday, then I'll publish a release on the first Tuesday every month, how does that sound to you?

[eyenx]

To the community: I've added dependabot to keep go.mod file updated, and the bot would check the dependencies every Monday. Let's say, I'll check, test and merge prs raised by dependabot every Monday, then I'll publish a release on the first Tuesday every month, how does that sound to you?

Sounds good!

[thpang]

It would be also nice if on the road map there was an outline of items in the azurerm_kubernetes_cluster that are available will be surfaced. Right now looking for FIPS support which is not supported here, but is available in the azurerm_kubernetes_cluster resource.

[lonegunmanb]

Thanks @thpang for the road map idea, we'll have an internal discuss. Meanwhile is there any existing issue about the FIPS support you've mentioned? If not, would you please open one so we can catch up later? Thanks!

[cveld]

On migration challenges: do you guys work together with the terraform cli folks to get additional features into the box so that module developers can provide a much cleaner experience?

[cveld]

On publishing merged PRs: shouldn't every new version immediately be published?

[lonegunmanb]

Hi @cveld,

On migration challenges: do you guys work together with the terraform cli folks to get additional features into the box so that module developers can provide a much cleaner experience?

There're two "Terraform CLI" teams that are related to these modules: Terraform CLI Core and Terraform AzureRM Provider. We're working with the provider team now. May I ask what could the "much cleaner experience" look like?

On publishing merged PRs: shouldn't every new version immediately be published?

There're two types of change, breaking change and non-breaking change. The module user might need to upgrade their code or execute manually Terraform state manipulation for breaking change, so we'd like to release non-breaking changes as much as possible, then compress all breaking changes into one major version upgrade, so the module's users don't have to take risks to carry a major version upgrade if they just want to use a new feature or apply a bug fix. They also need time to evaluate the impact of a major version upgrade, so we decided to release a major version about half a year to reduce the impact.