[RFE] lazy installation of agent dependencies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
Currently every machine used by Juju has a set of packages installed unconditionally.
Comparing cloud image manifest
https:/
with systems provisioned via Juju & MAAS I can see the following additional packages installed:
1) controller machines:
bridge-utils, cloud-image-utils, cloud-utils, cpu-checker, distro-info, genisoimage, juju-mongo-
non-controller ubuntu machines (without charms):
bridge-utils, cloud-image-utils, cloud-utils, cpu-checker, distro-info, genisoimage, libaio1:amd64, libboost-
libboost, cpu-checker, msr-tools, libnss, ceph rbd-related dependencies and some others are for qemu-utils
Not every system we provision uses those packages as "kvm containers" are subjectively used less frequently than LXD containers in Juju models.
Those dependencies should be made optional for at least 2 reasons:
1) some users/customers ask to reduce the amount of packages installed to have a smaller attack surface;
2) installation speed.
Changed in juju: | |
importance: | Undecided → Medium |
status: | New → Triaged |
The one we actually want is 'cpu-checker' as we want to know whether we
*could* launch a KVM guest on a given machine, and we could defer
installing the rest of the packages to actually launch them until we
actually have requested it.
We could potentially have a flag for disabling KVM support entirely, it
doesn't really make sense to do it on a per-machine level.
On Mon, May 28, 2018 at 2:34 AM, Dmitrii Shcherbakov <
<email address hidden>> wrote:
> Public bug reported: /cloud- images. ubuntu. com/xenial/ current/ xenial- server- cloudimg- tools3. 2, juju-mongodb3.2, libaio1:amd64, chrono1. 58.0:amd64, libboost- filesystem1. 58.0:amd64, iostreams1. 58.0:amd64, libboost- program- options1. 58.0:amd64, random1. 58.0:amd64, libboost- regex1. 58.0:amd64, system1. 58.0:amd64, libboost- thread1. 58.0:amd64, perftools4, libiscsi2:amd64, libnspr4:amd64, libnss3:amd64, amd64, libplymouth4:amd64, librados2, librbd1, amd64, libsnappy1v5:amd64, libtcmalloc- minimal4, libunwind8, cpp0.5v5: amd64, msr-tools, qemu-block- extra:amd64, qemu-utils, iostreams1. 58.0:amd64, random1. 58.0:amd64, libboost- system1. 58.0:amd64, thread1. 58.0:amd64, libiscsi2:amd64, libnspr4:amd64, extra:amd64, qemu-utils, sharutils, ubuntu-fan /bugs.launchpad .net/bugs/ 1773756 /bugs.launchpad .net/juju/ +bug/1773756/ +subscriptions
>
> Currently every machine used by Juju has a set of packages installed
> unconditionally.
>
> Comparing cloud image manifest
>
> https:/
> amd64.manifest
>
> with systems provisioned via Juju & MAAS I can see the following
> additional packages installed:
>
> 1) controller machines:
> bridge-utils, cloud-image-utils, cloud-utils, cpu-checker, distro-info,
> genisoimage, juju-mongo-
> libboost-
> libboost-
> libboost-
> libboost-
> libgoogle-
> libnss3-nssdb, libpcrecpp0v5:
> libsmartcols1:
> libyaml-
> sharutils, ubuntu-fan
>
> non-controller ubuntu machines (without charms):
> bridge-utils, cloud-image-utils, cloud-utils, cpu-checker, distro-info,
> genisoimage, libaio1:amd64, libboost-
> libboost-
> libboost-
> libnss3:amd64, libnss3-nssdb, librados2, librbd1, msr-tools,
> qemu-block-
>
> libboost, cpu-checker, msr-tools, libnss, ceph rbd-related dependencies
> and some others are for qemu-utils
>
> Not every system we provision uses those packages as "kvm containers"
> are subjectively used less frequently than LXD containers in Juju
> models.
>
> Those dependencies should be made optional for at least 2 reasons:
>
> 1) some users/customers ask to reduce the amount of packages installed to
> have a smaller attack surface;
> 2) installation speed.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: cpe-onsite
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https:/
>
> Title:
> [RFE] lazy installation of agent dependencies
>
> To manage notifications about this bug go to:
> https:/
>