Need /etc/sysctl.d/10-juju.conf
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-release-tools |
Fix Released
|
High
|
Nicholas Skaggs | ||
juju-core (Ubuntu) |
Fix Released
|
Undecided
|
Nicholas Skaggs | ||
Xenial |
Fix Released
|
Undecided
|
Nicholas Skaggs | ||
Yakkety |
Fix Released
|
Undecided
|
Nicholas Skaggs | ||
Zesty |
Fix Released
|
Undecided
|
Nicholas Skaggs |
Bug Description
In order to increase the number of containers that can be used with the lxd provider we need an /etc/sysctl.
fs.
fs.
This is a partial fix for bug #1602192.
[SRU Information]
[Impact]
This represent a partial workaround to the problem of being unable to launch double digit containers via LXD. While upstream work within the kernel and LXD should provide a better solution, this seeks to mitigate the specific case of running a charm bundle locally via LXD.
[Verification]
First confirm the values are now set by checking with
sysctl -a | grep fs.inotify.
Then, try running a bunch of lxc containers. You should be able to start around 20 before they fail.
To test juju, start 13 containers using lxc. Then perform a juju bootstrap and deploy the ubuntu charm. Using the old package, the deploy should never complete. With the changes, you should be able to deploy. NOTE: You will still hit an upper limit depending on your machine of around 20 or so containers. This test is intended to demonstrate you can deploy even with more than 13 running lxc containers.
As an additional verification, you can attempt to deploy a large bundle like canonical-
[Regression Potential]
As these values are not currently set, there is no potential for regressions. Rather, the risk is on setting the values.
[Other]
This change tweaks kernel settings that will change the users machine for all running binaries -- not just LXD and juju. These values have been chosen as reasonable defaults and as safe to implement. See the discussion on bug 1602192.
Changed in juju-release-tools: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in juju-release-tools: | |
assignee: | nobody → Torsten Baumann (torbaumann) |
tags: | added: conjure |
Changed in juju-release-tools: | |
status: | Triaged → In Progress |
assignee: | Torsten Baumann (torbaumann) → Nicholas Skaggs (nskaggs) |
status: | In Progress → Fix Committed |
Changed in juju-core (Ubuntu Zesty): | |
status: | New → Fix Released |
Changed in juju-core (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in juju-core (Ubuntu Yakkety): | |
status: | New → In Progress |
Changed in juju-core (Ubuntu Zesty): | |
assignee: | nobody → Nicholas Skaggs (nskaggs) |
Changed in juju-core (Ubuntu Yakkety): | |
assignee: | nobody → Nicholas Skaggs (nskaggs) |
Changed in juju-core (Ubuntu Xenial): | |
assignee: | nobody → Nicholas Skaggs (nskaggs) |
description: | updated |
description: | updated |
tags: |
added: v-done-xenial v-failed-yakkety removed: verification-needed |
tags: | removed: v-failed-yakkety |
tags: | added: verification-needed |
tags: |
added: verification-done-xenial verification-done-yakkety removed: v-done-xenial v-done-yakkety |
Changed in juju-release-tools: | |
status: | Fix Committed → Fix Released |
I think we need to create d/juju-2.0.sysctl with max_user_ watches = 524288 max_user_ instances = 256
fs.inotify.
fs.inotify.
then add this to to d/rules: juju-2. 0.sysctl debian/ juju-2. 0/etc/sysctl. d/10-juju. conf
install -m 644 -D debian/