[DPE-7379] Requested entity name #239

dragomirp · 2025-08-12T10:27:56Z

Implement a way to request entity name by passing a secret.

Draft implementation PRs:

dragomirp · 2025-08-12T20:05:54Z

tests/v0/integration/application-charm/requirements.txt

@@ -1 +1 @@
-ops >= 2.0.0
+ops >= 2.0.0, < 3.0.0


Ops 3 doesn't doesn't work on focal.

dragomirp · 2025-08-12T20:08:36Z

lib/charms/data_platform_libs/v0/data_interfaces.py

@@ -1926,13 +1926,27 @@ def __init__(
        extra_group_roles: Optional[str] = None,
        entity_type: Optional[str] = None,
        entity_permissions: Optional[str] = None,
+        requested_entity_secret: Optional[str] = None,


Pass a secret URI directly. Simpler but the user needs to manage grants and clean up the secret after relation.

dragomirp · 2025-08-12T20:12:06Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+        requested_entity_name: Optional[str] = None,
+        requested_entity_password: Optional[str] = None,


Pass the entity name and a password, to create a temporary secret from inside the lib.

dragomirp · 2025-08-12T20:28:29Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+        ):
+            try:
+                secret = self.framework.model.get_secret(id=secret_uri)
+                secret.remove_all_revisions()


Don't remove the relation data, so that the secret isn't recreated.

Gu1nness

Excellent work overall, just a very few questions.
Could you add some unit tests to the PR on top of the integration testing so that we can ensure easily the safeguards you added (not mixing the secret uri and requested username + password) ?

Gu1nness · 2025-08-14T12:23:27Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+        ) and not self.secrets_enabled:
+            raise SecretsUnavailableError("Secrets unavailable on current Juju version")
+
+        if self.requested_entity_secret and self.requested_entity_name:


Also add the case where requested_entity_secret and requested_entity_password to prevent that case as well?

Checks for entity secret and entity password conflict and for entity password without entity name added in 09f95f2

Gu1nness · 2025-08-14T12:24:37Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+        # Create helper secret if needed
+        if (
+            self.relation_data.requested_entity_name
+            and "requested-entity-secret" not in event_data


For consistency of checks I would rather use and not self.relation_data.requested_entity_secrets.
Or there's a difference semantically in this case ?

Added in fc5f510. My concern was if the secret will be recreated, but it doesn't seem to happen when scaling data-int on k8s.

Gu1nness · 2025-08-14T12:27:24Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+                    self.relation_data.requested_entity_name: str(
+                        self.relation_data.requested_entity_password
+                    )


I'm not sure I'm fully happy about the formatting here.
If I understand correctly, this means the format is <username>: <password | None > ?
What about this other option ?

username: <username> password: <password>

I'm just a bit afraid of the None encoded as a string in this case whereas the other way we could just not add the password field ?

My concern here is v1 compatibility, my understanding is that we should be able to set multiple entities in v1 which should be easier with a mapping (one key, one entity). With explicit name and password we have to decide how to expand on this. Multiple secrets would be too much complexity IMHO, so we'll most probably need to somehow serialise the name/pass pairs, either by setting lists of names and passwords matching by index, eg:

names: ["username1", "rolename1", "username2"] passwords: ["pass1" null, null]

Possibly passing the type here as well (type: ["user", "role", "user"]).

Or having a nested mapping inside the predefined secret key, eg:

requested-entities: {"username1": { "password": "pass1", "type": "user"}, "rolename1" {"password": null, "type": "role"}}

Since this is still a WIP, I'm not opposed to changing the format, so the question is which would be the most appropriate way to make this v1 compatible.

Rechecked the specification and the agreed format is:

entity-name: <username> password: <password>

Updated to that format in 3f7d614.

dragomirp · 2025-08-15T19:23:37Z

lib/charms/data_platform_libs/v0/data_interfaces.py

+                        self.relation_data.requested_entity_password
+                    )
+                },
+                label=f"{self.model.uuid}-{event.relation.id}-requested-entity",


Switched to globally unique label.

marceloneppel

LGTM

dragomirp · 2025-08-21T13:24:10Z

Charm interfaces PR: canonical/charm-relation-interfaces#294

dragomirp · 2025-08-28T19:24:06Z

Had to pin ops dependency for the s3 test charm as well.

dragomirp added 4 commits August 12, 2025 13:25

Requested entity name

0531706

Typing tweaks

c8e6473

Use ops 2

c56f99d

Typedef

742f0ca

dragomirp force-pushed the dpe-7379-user-creation branch 4 times, most recently from 31f17de to b75d73d Compare August 12, 2025 18:32

Integration test

69b2e2d

dragomirp force-pushed the dpe-7379-user-creation branch from b75d73d to 69b2e2d Compare August 12, 2025 18:48

dragomirp commented Aug 12, 2025

View reviewed changes

dragomirp added the enhancement New feature or request label Aug 12, 2025

dragomirp marked this pull request as ready for review August 12, 2025 21:08

dragomirp requested review from Gu1nness and marceloneppel August 12, 2025 21:08

Gu1nness requested changes Aug 14, 2025

View reviewed changes

dragomirp added 2 commits August 15, 2025 21:01

Unit test and tweaks

09f95f2

Check data class instead of rel data directly

fc5f510

dragomirp commented Aug 15, 2025

View reviewed changes

marceloneppel approved these changes Aug 18, 2025

View reviewed changes

Explicit secret fields

3f7d614

dragomirp requested review from Gu1nness and marceloneppel August 19, 2025 14:04

marceloneppel approved these changes Aug 19, 2025

View reviewed changes

Gu1nness approved these changes Aug 19, 2025

View reviewed changes

dragomirp mentioned this pull request Aug 20, 2025

[DPE-7379] Add requested entity secret canonical/charm-relation-interfaces#294

Merged

dragomirp mentioned this pull request Aug 22, 2025

[DPE-7379] custom entity name canonical/data-integrator#171

Merged

delgod approved these changes Aug 28, 2025

View reviewed changes

Pin ops for s3 charm

23cc33a

dragomirp merged commit 3c4f5d4 into main Aug 28, 2025
63 of 64 checks passed

dragomirp deleted the dpe-7379-user-creation branch August 28, 2025 19:24

		requested_entity_name: Optional[str] = None,
		requested_entity_password: Optional[str] = None,

[DPE-7379] Requested entity name #239

[DPE-7379] Requested entity name #239

Uh oh!

Conversation

dragomirp commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gu1nness left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marceloneppel left a comment

Choose a reason for hiding this comment

Uh oh!

dragomirp commented Aug 21, 2025

Uh oh!

dragomirp commented Aug 28, 2025

Uh oh!

Uh oh!

Uh oh!

dragomirp commented Aug 12, 2025 •

edited

Loading