← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1631038] Re: Need /etc/sysctl.d/10-juju.conf

 

This bug was fixed in the package juju-core - 2.0.0-0ubuntu0.16.10.3

---------------
juju-core (2.0.0-0ubuntu0.16.10.3) yakkety; urgency=medium

  * debian/control: Fix the build failure due to dependency issues.
    (LP: #1617440)
    - Nope, we really don't want a Build-Depends on golang-github-coreos-go-
      systemd-dev.
    - Drop golang-go.crypto from Build-Depends.

juju-core (2.0.0-0ubuntu0.16.10.2) yakkety; urgency=medium

  * Restore golang-github-coreos-go-systemd-dev
  * Fix missing dh_install for sysctl file (LP: #1631038)

juju-core (2.0.0-0ubuntu0.16.10.1) yakkety; urgency=medium

  * New upstream release 2.0.0 (LP: #1617440)
  * d/copyright updated for 2.0.0 vendored packages.
  * Add sysctl files for lxd provider (LP: #1631038)
  * Update d/watch file
  * Add upstream signing key
  * Restore golang-golang-x-[crypto,net]-dev dependencies
  * Update bootstrap order for autpopkgtests for juju cli changes

 -- Mathieu Trudel-Lapierre <cyphermox@xxxxxxxxxx>  Thu, 03 Nov 2016
11:51:54 -0600

** Changed in: juju-core (Ubuntu Yakkety)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1631038

Title:
  Need /etc/sysctl.d/10-juju.conf

Status in juju-release-tools:
  Fix Committed
Status in juju-core package in Ubuntu:
  Fix Released
Status in juju-core source package in Xenial:
  Fix Released
Status in juju-core source package in Yakkety:
  Fix Released
Status in juju-core source package in Zesty:
  Fix Released

Bug description:
  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]
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-release-tools/+bug/1631038/+subscriptions