feat: expose the ability to set Pebble log targets

[tonyandrewmeyer]

Exposes the log-targets section of the Pebble layer spec, to allow charms to configure log forwarding in Pebble without having to provide layers as plain YAML.

New types:

• LogTargetDict: a typed dictionary similar to ServiceDict and CheckDict.
• LogTarget: similar to Service and Check.

Changed types:

• LayerDict and PlanDict have (not required) log-targets keys.
• Layer and Plan have log_targets attributes (Plan is read-only, as with checks and services).

Fixes #1073

[kayra1]

Thanks for the fast response!

[benhoyt]

Nice, thanks! A few minor comments.

Could you also please do one quick test against a real Pebble instance with a log-targets and make sure it's coming through okay? I'd be okay with just a manual test hacking test/pebble_cli.py or something, but an automated test in test_real_pebble.py would be fine too if it's straight-forward.

[tonyandrewmeyer]

Could you also please do one quick test against a real Pebble instance with a log-targets and make sure it's coming through okay? I'd be okay with just a manual test hacking test/pebble_cli.py or something, but an automated test in test_real_pebble.py would be fine too if it's straight-forward.

Sure. I had wondered about a test_real_pebble addition, but when looking through what that tests, it seemed to be more the actual Pebble functionality (pushing and pulling, running health checks, exec'ing) rather than just config. It seems complicated to do that with log forwarding, since I assume a Loki server would be required. What would you like a real_pebble test to do? Just check that particular config is appropriately created?

Also for this: the CI real pebble test gets the latest version of (main) pebble. Is it ok to assume that anyone running tox -e pebble also has the latest version, or should the tests check the version and skip appropriately?

[benhoyt]

What would you like a real_pebble test to do? Just check that particular config is appropriately created?

Yeah, I wasn't thinking it'd test the Loki part -- just let the log forwarding itself fail. Just test that adding a layer with a log target can be queried and comes through with appropriate attributes in get_plan or something.

Also for this: the CI real pebble test gets the latest version of (main) pebble. Is it ok to assume that anyone running tox -e pebble also has the latest version, or should the tests check the version and skip appropriately?

Yeah, I think it's fine to assume the dev is on Pebble latest, no need for version checks.

[tonyandrewmeyer]

@benhoyt the tests fail because the workflow uses pebble@latest. Is it ok to change that to pebble@master? (They pass locally for me in that case). I'm not sure whether we want to verify that we're compatible with the latest released pebble or the next version of pebble.

If we don't change it, then I can disable the labels until the next pebble release.

[benhoyt]

@tonyandrewmeyer Yep, I think it's fine to have the real Pebble tests work off @master. We own the project and the master branch is (should be!) stable.

[benhoyt]

Approved. Just one minor comment about the HACKING.md change now that we're using @master.