Handling module compatibility in branches, that is, the module in Github branch track/1.8 of the training operator is compatible with that charm (1.8/stable, 1.8/edge), but the module in branch main is compatible with that charm (latest/edge).
Removing the note from the README.md as it will be obviated that there is a 1:1 compatibility mapping between the module and the charm in the same Github branch
What needs to get done
Remove the compatibility note from the README.md
Update the terraform-checks.yaml call to:
omit model input, unless kubeflow needs to be defined. In that case, we should reference issue kubeflow/kubeflow/issues/6136 with a comment-explanation.
omit channel input, since latest/edge is the new default one.
Backport the merged PR to 1.9-related branch while updating the
terraform-checks.yaml call to deploy track/stable charm.
Definition of Done
Module in main has been updated and backported to 1.9-related branch.
Context
Update terraform module CI and docs according to agreed convention in https://github.com/canonical/training-operator/pull/200#discussion_r1772486064 where we agreed that:
What needs to get done
model
input, unlesskubeflow
needs to be defined. In that case, we should reference issue kubeflow/kubeflow/issues/6136 with a comment-explanation.channel
input, sincelatest/edge
is the new default one.terraform-checks.yaml
call to deploytrack/stable
charm.Definition of Done
Module in
main
has been updated and backported to 1.9-related branch.