-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Craft the juju model-config for suppressing fan-config #22
base: main
Are you sure you want to change the base?
Conversation
Partially address juju/terraform-provider-juju#667 |
@peppepetra @dparv @Gmerold @asbalderson @amc94 @canonical/kubernetes heads up! Changes ahead |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please notice the following repos which require merging first
- name: Vanilla | ||
yaml: test/vanilla.yaml | ||
cloud_integration: '' | ||
cloud_integration: "false" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I feel like 'cloud_integration=' was more intuitive than this, especially since we now need to set both "cloud" and "cloud_integration". Can we not just read the cloud from the variable and then set it in the model internally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, there may be cases you want to deploy on a cloud -- but without the cloud-integrations. Juju requires the cloud
value. So, I switched cloud_integration
to be true/false
to engage the cloud integration. But yeah -- i liked cloud_integration=<cloud>
better too...
I wasn't sure how else to model this better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok @bschimke95 i was won over by a powerful argument -- cloud
in juju parlance is the name of a particular cloud instance. So i might have an openstack cloud instance named my-openstack-instance
but i still want the openstack
cloud-integration. So I think i've put it back to the way it was before i changed it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I think all related PRs are merged but I'll leave the merging to you.
760592e
to
8021f52
Compare
8021f52
to
53bd484
Compare
BREAKING CHANGE
In order to prevent terraform users from deploying with fan networking enabled, we need to control the juju model object and explicitly prevent it from being set to enable fan networking in machine modules. To do this, we must break the user interface of the main TF modules by adjusting the
model
configuration.Rather than it being the
name
of the module, it will now by a configuration structure similar to the juju-provider model resource. This lets us override the keys in the config to specify thefan-config
andcontainer-networking-method
.This will be interruptive to existing uses of our terraform modules.