** Description changed: In order to increase the number of containers that can be used with the lxd provider we need an /etc/sysctl.d/10-juju.conf file setting: - fs.inotify.max_user_watches = 524288 - fs.inotify.max_user_instances = 256 + fs.inotify.max_user_watches = 524288 + fs.inotify.max_user_instances = 256 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] + 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-kubernetes, hadoop, or another bigdata charm. Be sure to + remove any pre-existing containers before deploying as these bundles + will start more than a dozen on there own. + + [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.
** Description changed: In order to increase the number of containers that can be used with the lxd provider we need an /etc/sysctl.d/10-juju.conf file setting: fs.inotify.max_user_watches = 524288 fs.inotify.max_user_instances = 256 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] - 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. + First confirm the values are now set by checking with + + sysctl -a | grep fs.inotify.max_user_ + + 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-kubernetes, hadoop, or another bigdata charm. Be sure to remove any pre-existing containers before deploying as these bundles will start more than a dozen on there own. [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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1631038 Title: Need /etc/sysctl.d/10-juju.conf To manage notifications about this bug go to: https://bugs.launchpad.net/juju-release-tools/+bug/1631038/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
