Support pebble push testing in harness

Use case

A recent commit pushed much needed support for ops.harness based unit testing of sidecar charms. However any method that involves a pebble.push() will raise an NotImplementedError. It will be useful to have support for harness based testing of such methods too, even though it is currently possible to write unit tests by mocking the push() method. Mocking may allow checking what is being pushed however testing code downstream of the push call may become more involved, if it depends on the pushed content.

[jameinel]

In which case you really need to do it only in memory, as there may not be a ‘mongod’ user on your host system, but again it would likely exist inside the container image.

I certainly wouldn’t want people to have to patch the functionality to do basic testing. The question is more what leads to good, maintainable tests such that we can guide people towards high quality charms.

On Tue, May 4, 2021 at 9:25 AM Balbir Thomas @.***> wrote:

So the charms clearly need to manipulate files on disk. Why does the test suite need files on disk?

If you are asking why test suite needs to implement file storage on disk, it may be that it is probably not necessary and can as well be in memory as long as it can imitate behaviour of Pebble API (push() and pull()). Although I wonder if there will be a need to unit test file permission and owner ship settings and if so, how this can be done with in memory representation of files. For example MongoDB is very stringent about the permission and ownership of the key file, when authentication is enabled. It insists that this key file is owned by user/group “mongodb” and that the permissions are read/write by owner only. If this condition is violated MongoDB fails to start. Setting owner, group and permissions is part of the Pebble push() API. The underlying question is if harness should allow unit testing all the functionality exposed by the Operator Framework API, without the need to patch the Operator Framework API itself. I can see there being divergent views on this. My own inclination is that making harness feature complete in this manner will be a more pleasant developer experience. Thoughts ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/518#issuecomment-831939086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7I335X5KVLNTQ7SBCTTL7YU5ANCNFSM43MUX2WQ .

[balbirthomas]

So the charms clearly need to manipulate files on disk. Why does the test suite need files on disk?

If you are asking why test suite needs to implement file storage on disk, it may be that it is probably not necessary and can as well be in memory as long as it can imitate behaviour of Pebble API (push() and pull()). Although I wonder if there will be a need to unit test file permission and owner ship settings and if so, how this can be done with in memory representation of files. For example MongoDB is very stringent about the permission and ownership of the key file, when authentication is enabled. It insists that this key file is owned by user/group “mongodb” and that the permissions are read/write by owner only. If this condition is violated MongoDB fails to start. Setting owner, group and permissions is part of the Pebble push() API. The underlying question is if harness should allow unit testing all the functionality exposed by the Operator Framework API, without the need to patch the Operator Framework API itself. I can see there being divergent views on this. My own inclination is that making harness feature complete in this manner will be a more pleasant developer experience. Thoughts ?