Comment 6 for bug 1828422

> the subordinate wouldn't own /etc/apt/sources.list.d/cloud-
archive.list, right?

Yes, I think you are correct. It was more about providing more context to the subordinate about what the principal is doing/has state, and also providing a trigger (via the relation hook) to allow the subordinate to take action. The idea of adding state/context to the container-scope relation is just (my) idea of being able to allow the subordinate to make better/more informed decisions of whether to do things.

There is an example in the openstack-dashboard charm set (principal/subordinate) where the subordinate installs and removes a package that the principal installed; however, the principal wasn't aware of it, and so on upgrade, re-installs the package and breaks the installation. This is because the separation of concerns around 'who owns what' wasn't clear and therefore unfortunately broke.

I tend to think that the principal charm should actually do all the installation of packages, rendering of templates, and starting/stopping services, and the subordinate should indicate what it needs installed, rendered, and start/stopped; obviously there are issues around this (due to timing or hooks, when things get installed, etc.) but it might make for a clearer and more understandable approach to what is happening with a set of principal/subordinate charms.