The exported methods from the servicestate package all return tasksets now,
which is expected to be put into changes that are executed by the overlord
loop. This involves changes in many parts that use quotas, such as the tests,
where a new mock function to create a quota group in state without running any
servicectl commands as well as changes to the client side.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
had to make the comment in wrappers/services_test.go a one-liner
otherwise half of it is lost
last set of files needing changing (as per current master)
* client/quota.go: support current-memory key
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* cmd/snap/quota: refactor quota CLI as per new design
* Make quota command only responsible for showing/displaying quota group
information.
* Introduce new set-quota command which creates or updates quota groups
* Move the display of memory limit under a map section "constraints" which then
has a memory key to allow future resource types to live under this section.
* Display current memory usage for quota groups under a new section "current",
which like "constraints" can be expanded for future resource types too.
Also update the spread test and unit tests for the new output formats.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota-groups: check the cgroup procs file in a loop
This too is a race condition, thanks to Maciej for pointing this out.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/snap-quota-groups: compare slice mem usage from both snapd and kernel
This check ensures that what the kernel says the current memory usage is and
what snapd says the current memory usage is don't differ by more than 10%. In
practice they should be exactly equal if the program is doing nothing as the
go-example-webserver should be, but something does happen to change it \
shouldn't change drastically.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/snap-quota: add a snap with a service to one of the groups
This ensures that we can check the `snap quota` and `snap quotas` output for
the "current" section with the memory usage in it.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota: fix trusty check
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota: increase limits so the webserver snap can start
These limits were too low so the service was killed and no memory usage was
reported in the output, but we want to see some usage from the output to check
that it works, so increase the limits so the server is not killed due to OOM.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota: fix group-one line in output
Also fix the defer statement which was missing the snap to unset the config on.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota-groups: refactor memory check for empty quota groups
We only should be checking what snapd says about memory usage for these empty
groups, we don't need to compare with what the kernel says.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/snap-quota-groups: fix typo
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota-groups: treat memory=4096 as memory=0 for new systems
On the following systems:
- Arch Linux
- Fedora 33
- Fedora 34
- Debian sid
- Ubuntu 21.04
The memory usage of an "empty" but active cgroup ends up being 4K for some
reason, so handle this in the expected output.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/snap-quota-groups: silly typos
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota: fix more typos
non capturing groups are not a thing in grep -E because of course they aren't
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota-groups: use python if python3 is not available
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests/main/snap-quota: adjust memory limits for test groups to be at least 4K
On some systems, an empty cgroup with just cgroups nested inside it (but not
necessarily any processes) will have 4K memory usage, so on these systems, we
should make sure that the nested cgroups have enough space in them.
In a follow-up, we will adjust the minimum usable memory limit for a given
cgroup to be 4K to prevent this situation from happening in practice.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
The test sometimes fails on OBS when building for AARCH64, where it's likely
done in a VM. Tweak the test so that even very slow hosts have a chance of
running it successfully.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
This is a followup for PR#9692 where it was suggested that the
new "snapctl" support for reading from stdin should have some
protection against reading too much data. See
https://github.com/snapcore/snapd/pull/9692#discussion_r530255566
This starts with a 4MB limit.
