Conversation
shipperizer
left a comment
There was a problem hiding this comment.
we merged yesterday a more "barebone" tf module
said that, i do believe this is a good example of how a deployment might look like so i m happy to pick it and move it to the examples folder and use it as a reference, would that work?see this as refrerence
| data "juju_model" "lego" { | ||
| name = var.model | ||
| } |
There was a problem hiding this comment.
this tends to create problems when deployed in a bigger project, data sources get evaluated before resources so it might create a failure unless a specific depends_on clause is applied to the lego module
| resource "juju_secret" "lego_credentials" { | ||
| model = data.juju_model.lego.name | ||
| name = var.secret_name | ||
| value = var.secret_value | ||
| info = "LEGO plugin configuration credentials" | ||
| } |
There was a problem hiding this comment.
secret might be passed from the outside, so this is more part of how an opinionated module deployment should look like, i'm not sure we want this in
There was a problem hiding this comment.
Up to you. We are currently packing several charms in our modules, which is by definition opinionated
| resource "juju_access_secret" "lego_credentials_access" { | ||
| model = data.juju_model.lego.name | ||
| applications = [ | ||
| juju_application.lego.name | ||
| ] | ||
| secret_id = juju_secret.lego_credentials.secret_id | ||
| } |
There was a problem hiding this comment.
see above comment on the secret
Feel free to close this PR is you think it's too opinionated for the module and leave this as an example |
Description
Add the TF product for the LEGO charm
Checklist: