Skip to content
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

Improve encapsulation power of juju_integration to avoid leaking implementation detail #625

Open
sed-i opened this issue Nov 7, 2024 · 1 comment

Comments

@sed-i
Copy link

sed-i commented Nov 7, 2024

Requirements

Let's say we have two apps to deploy,

resource "juju_application" "some_app" {
  name  = "some-app"
  model = local.model_name

  charm {
    name    = "my-charm"
    channel = var.channel
    base    = "[email protected]"
  }
  units  = 1
}


module "bundle" {
  source     = "git::https://github.com/canonical/bundle//terraform"
  model_name = local.model_name
  channel    = local.channel
}

To create a juju integration, we must provide the application Block Set verbatim:

resource "juju_integration" "some-app-bundle" {
  model = local.model_name

  application {
    name     = module.bundle.app_name
    endpoint = module.bundle.my_endpoint
  }

  application {
    name     = juju_application.some_app.app_name
    endpoint = "some-endpoint"
  }
}

Ideally, module.bundle would offer its side of an integration in its entirety, without the user needing to know the implementation detail of the underlying charms:

resource "juju_integration" "some-app-bundle" {
  model = local.model_name

  module.bundle.my_endpoint

  application {
    name     = juju_application.some_app.app_name
    endpoint = "some-endpoint"
  }
}
  • Afaict, this is not supported by terraform?
  • Should we adjust the juju_integration interface to improve encapsulation?

Urgency

It would save from a weird workaround.
Currently, the implementation of juju_integration forces us to leak implementation detail.

Notes & References

No response

@sed-i sed-i added kind/feature suggests new feature or enhancement state/untriaged untriaged bug report labels Nov 7, 2024
@sed-i sed-i changed the title juju_integration to not leak implementation detail Improve encapsulation power of juju_integration to avoid leaking implementation detail Nov 7, 2024
@sed-i sed-i changed the title Improve encapsulation power of juju_integration to avoid leaking implementation detail Improve encapsulation power of juju_integration to avoid leaking implementation detail Nov 7, 2024
@Aflynn50 Aflynn50 added area/integration and removed state/untriaged untriaged bug report labels Nov 11, 2024
@hmlanigan hmlanigan removed the kind/feature suggests new feature or enhancement label Nov 12, 2024
@hmlanigan
Copy link
Member

@sed-i

I'd expect the following to work provided both apps have matching provided and required endpoint names as with juju integrate module.bundle.app_name juju_application.some_app.app_name:

resource "juju_integration" "some-app-bundle" {
  model = local.model_name

  application {
    name     = module.bundle.app_name
  }

  application {
    name     = juju_application.some_app.app_name
  }
}

Only if juju cannot disambiguate the endpoints should it be necessary to specify them. For the two example applications, is that the choice?

As to your suggestion of the application block being exported by the bundle module, that sounds like question for a terraform expert and not specific to the juju provider. It has no control over how terraform interprets didn't input into the different resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants