Canonical Juju

LXD provider places a limit on memory for the controller but not for a workload machine

Bug #1784075 reported by Peter Matulis
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
High
Simon Richardson
Canonical Juju 2.4.2

Bug Description

After creating a controller with

$ juju bootstrap --no-gui localhost lxd1

I see a LXD maximum imposed on memory:

$ lxc config get juju-944bca-0 limits.memory
3584MB

However, an added machine does not have such a limit imposed, why?

$ juju add-machine
$ lxc config get juju-beadab-0 limits.memory
(null output)

$ lxc list
+---------------+---------+----------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+---------------+---------+----------------------+------+------------+-----------+
| juju-944bca-0 | RUNNING | 10.129.12.178 (eth0) | | PERSISTENT | 0 |
+---------------+---------+----------------------+------+------------+-----------+
| juju-beadab-0 | RUNNING | 10.129.12.199 (eth0) | | PERSISTENT | 0 |
+---------------+---------+----------------------+------+------------+-----------+

BTW,

$ grep MemTotal /proc/meminfo
MemTotal: 2041356 kB

Tags: docteam
Revision history for this message
Joseph Phillips (manadart) wrote :

I have observed this, but I think it may be an issue with LXD parsing config; possibly due to the size of fields containing cloud-init data.

When you cannot see any config as in this situation, try:
"lxc config edit <container>"

This will open an editor where you can manipulate the config YAML directly, and I believe you will see the same limit applied there - it appears to be an LXD default.

This is worth mentioning to the LXD team.

Richard Harding (rharding)
Changed in juju:
status: New → Incomplete
Revision history for this message
Peter Matulis (petermatulis) wrote :

No, I do not see a 'limits.memory' line with

lxc config edit juju-beadab-0

Joseph Phillips (manadart)
Changed in juju:
status: Incomplete → Triaged
importance: Undecided → High
milestone: none → 2.4.2
Revision history for this message
Joseph Phillips (manadart) wrote :

I was completely incorrect when I said this does not originate with Juju.

In environs/bootstrap/bootstrap.go, if there are no existing constraints for CPU power, CPU cores, memory or instance-type, this memory constraint is set.

It has always been done, and is intended to ensure that a sufficiently powerful instance is acquired on the regular clouds. For LXD it would simply have been ignored up until we began supporting constraints - now it is picked up.

We need to contrive some solution so that this is not done for LXD. In the interim, setting it high, or setting any value for CPU cores when specifying bootstrap constraints is a work-around.

Richard Harding (rharding)
Changed in juju:
assignee: nobody → Simon Richardson (simonrichardson)
Revision history for this message
Simon Richardson (simonrichardson) wrote :

The following PR resolves it, there maybe on going discussion about if the implementation is the right one... https://github.com/juju/juju/pull/9044

Changed in juju:
status: Triaged → In Progress
Simon Richardson (simonrichardson)
Changed in juju:
status: In Progress → Fix Committed
Canonical Juju QA Bot (juju-qa-bot)
Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.