fix: align Juju naming rules with testing class rules

[tonyandrewmeyer]

I have long been irritated by the messy way Scenario handled names, particularly with regards to underscores and dashes. #2565 has provided me with the excuse to do a full clean-up of how this is handled, making sure that everything matches real Juju properly, and avoiding inefficient (and sometimes wrong) round-tripping.

This PR aligns Scenario's simulated dispatch with how real Juju invokes hooks, and rejects entity names that Juju itself would reject, so tests can no longer pass against a charm that Juju would refuse to deploy or run.

I verified all of this against the juju/names and juju/charm sources for 3.x and 4.x, and against a live Juju 3.6.23 k8s model.

Dispatch environment and event names

#2552 made JUJU_HOOK_NAME preserve the entity-name spelling by carrying two forms of the event path (a normalised string plus an original_prefix). That is now collapsed to one representation: _EventPath.name is the Python-attribute event kind (what ops calls the event, and what its handle paths use), and _EventPath.prefix is the verbatim entity name from which the Juju hook name is built.

Other places where the simulated environment diverged from real Juju:

• Actions are dispatched as actions/<name> with no hooks/ prefix and no -action suffix; JUJU_ACTION_NAME keeps the verbatim name, and JUJU_ACTION_TAG is now set.
• JUJU_RELATION_ID is <endpoint>:<id>, not just the ID.
• State.get_relations matches the endpoint verbatim rather than treating foo-bar and foo_bar as the same endpoint (Juju allows both spellings, as distinct endpoints).

The consistency checker now compares the event's entity-name prefix to the entity name exactly, rather than a normalised startswith check (which also wrongly accepted, for example, a foobar event for a foo container).

Name validation

Scenario accepted any string as a container, storage, relation endpoint, or action name. Names are now validated at construction time, raising StateValidationError, using the same rules as Juju:

• relation endpoints: lowercase alphanumeric runs separated by single hyphens or underscores, starting with a letter (RelationSnippet). Underscores are valid here, and Juju produces hook names such as peer_under-relation-created for them.
• storage: hyphen-separated lowercase alphanumeric, starting with a letter, each part containing at least one letter (StorageNameSnippet). juju deploy fails for an underscored storage name.
• actions: lowercase alphanumeric and hyphens, starting and ending alphanumeric (actionNameRule). juju deploy fails with "bad action name" for an underscored action name.
• containers: Juju passes the name verbatim to Kubernetes, so the RFC 1123 DNS-label rule applies (no underscores, max 63 characters); the pod is never created for an underscored container name.

Documentation fixes

• The manage-actions how-to used ctx.on.action('do_backup'), a name Juju would reject.
• ops.CharmEvents now documents how dashed metadata names map to the prefixed event attributes (dashes become underscores) versus the indexed self.on[<name>] form (verbatim).
• The _Action docstring example used do_backup, which Juju would reject; corrected.

Drive-bys

Checks that were previously unreachable now run: the workload-event "container is in the state" error and the cannot-connect warning were nested inside the name-mismatch branch, so they only fired when the event name was already wrong; they now run unconditionally, like the equivalent relation and storage checks.

The "no action instance" error message used to say "workload event" and "container", presumably a copy and paste error; it now refers to actions.

Fixes #2565.

[james-garner-canonical]

I'm a big fan of this, aligning Scenario's behaviour with Juju's here is clearly the right thing to do, and should make everyone's lives easier in the long run.

This does seem like it has the potential to be very breaky though, doesn't it? And there are two distinct types of breakage it might cause: catching real charm bugs that slipped through due to Scenario previously being incorrect; and catching testing-only reliance on Scenario's previous (incorrect) behaviour.

I haven't reviewed in depth at this point -- I'd really like to see a super-tox/Hyrum comparison for this PR before going further.

[tonyandrewmeyer]

This does seem like it has the potential to be very breaky though, doesn't it?

My hope, perhaps naïvely, is that everyone is using names in their tests that match the names in their charm, and so if their charm works, their tests will still work.

And there are two distinct types of breakage it might cause: catching real charm bugs that slipped through due to Scenario previously being incorrect;

These ones I am ok with, although if there are a small number the practice of opening a few downstream PRs is probably good here.

and catching testing-only reliance on Scenario's previous (incorrect) behaviour.

This would be worse, although I would still be tempted to say that this is a bug in the charm tests.

I haven't reviewed in depth at this point -- I'd really like to see a super-tox/Hyrum comparison for this PR before going further.

Sure, running now.

[tonyandrewmeyer]

Main: 208 passed / 58 failed
This branch: 205 passed / 61 failed

1. airflow-coordinator-k8s-operator, state.get_relations("airflow_coordinator")[0] → IndexError.
2. hook-service-operator: InconsistentScenarioError: cannot emit hook_service_pebble_ready because container hook-service is not in the state
3. hydra-operator: same pattern as hook-service (hydra_pebble_ready / container hydra).

I'll open downstream PRs.

[james-garner-canonical]

Main: 208 passed / 58 failed This branch: 205 passed / 61 failed

1. airflow-coordinator-k8s-operator, state.get_relations("airflow_coordinator")[0] → IndexError.
2. hook-service-operator: InconsistentScenarioError: cannot emit hook_service_pebble_ready because container hook-service is not in the state
3. hydra-operator: same pattern as hook-service (hydra_pebble_ready / container hydra).

I'll open downstream PRs.

I assume those three are the only movement between passed and failed (that is, nothing new passes because of this PR). But I wonder if we need more information on any changes within the 58 that failed in both cases (e.g. any new individual tests failing). Why they're already failing is also important -- for example, if it's because we're not setting them up properly yet, then perhaps some additional manual or AI analysis of those cases would be valuable to understand if that isn't masking a possible new failure here.

Since we're currently working on fleshing out super-tox (into hyrum), this PR seems like a great testing ground for this kind of analysis.

[tonyandrewmeyer]

I assume those three are the only movement between passed and failed (that is, nothing new passes because of this PR). But I wonder if we need more information on any changes within the 58 that failed in both cases (e.g. any new individual tests failing). Why they're already failing is also important -- for example, if it's because we're not setting them up properly yet, then perhaps some additional manual or AI analysis of those cases would be valuable to understand if that isn't masking a possible new failure here.

I can dig into that. Hyrum is already better than super-tox at this, in that logging is better.

Since we're currently working on fleshing out super-tox (into hyrum), this PR seems like a great testing ground for this kind of analysis.

Fair, although the comparison feature has not landed yet. But I will be moving on to that now (well, after the fairly trivial private names and de-dependency changes).