Charm size is bigger than other reactive OpenStack charms

Bug #1890067 reported by Nobuto Murata
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Octavia Charm
Won't Fix
Undecided
Unassigned
charm-octavia-diskimage-retrofit
Won't Fix
Undecided
Unassigned

Bug Description

I've realized that charm-octavia and octavia-diskimage-retrofit take a long time downloading the charms when deploying a bundle. Sometimes it times out when the internet connection is not excellent.

Here are top 10 charms in the store in terms of the size of the charms below.

octavia (~46MB) and octavia-diskimage-retrofit (~28MB) are definitely bigger than other reactive charms (~16MB). It may be inevitable to have big content in wheelhouse, but would be nice to review the dependencies again and consider offloading some pip packages to deb if available so that the time of `juju deploy` can be shorter and reliable, and the charm can leverage caching in Squid proxy for debs.

[charm,url,Content-Length]
octavia,https://api.jujucharms.com/charmstore/v5/octavia/archive,45687327
octavia-diskimage-retrofit,https://api.jujucharms.com/charmstore/v5/octavia-diskimage-retrofit/archive,27933318
barbican-vault,https://api.jujucharms.com/charmstore/v5/barbican-vault/archive,15563040
masakari,https://api.jujucharms.com/charmstore/v5/masakari/archive,13040410
designate,https://api.jujucharms.com/charmstore/v5/designate/archive,12897026
manila,https://api.jujucharms.com/charmstore/v5/manila/archive,12871058
gnocchi,https://api.jujucharms.com/charmstore/v5/gnocchi/archive,12869481
manila-ganesha,https://api.jujucharms.com/charmstore/v5/manila-ganesha/archive,12858847
barbican,https://api.jujucharms.com/charmstore/v5/barbican/archive,12854867
nova-cell-controller,https://api.jujucharms.com/charmstore/v5/nova-cell-controller/archive,12851132

[charm-octavia]
$ du -sh * | sort -hr | head -n5
38M wheelhouse
608K hooks
168K tests
104K lib
80K templates

$ du -sh wheelhouse/* | sort -hr | head
8.1M wheelhouse/Babel-2.8.0.tar.gz
5.8M wheelhouse/SQLAlchemy-1.3.18.tar.gz
1.8M wheelhouse/chardet-3.0.4.tar.gz
1.6M wheelhouse/netaddr-0.7.19.tar.gz
1.4M wheelhouse/os-ken-0.4.1.tar.gz
1.3M wheelhouse/pip-18.1.tar.gz
1.1M wheelhouse/alembic-1.4.2.tar.gz
916K wheelhouse/openstacksdk-0.47.0.tar.gz
836K wheelhouse/setuptools-41.6.0.zip
776K wheelhouse/charms.openstack-0.0.1.dev1.zip

Revision history for this message
Frode Nordahl (fnordahl) wrote :

Any direct charm dependency is bundled with the charm to avoid the boundary violation of the charm code depending on the binary code it is managing on the system. Hard lessons learned from the Python2 to Python3 migration and other breaking changes our charms has been through in the past lies behind this.

This default behavior for all reactive charms today is to set up a virtual environment that is isolated from and does not include packages from the system. Consuming Python libraries from a deb is not an option for charm code.

These two charms have charm code that interact with OpenStack APIs and the bundled dependencies and size of the charm is a direct consequence of that.

Changed in charm-octavia:
status: New → Opinion
Changed in charm-octavia-diskimage-retrofit:
status: New → Opinion
Frode Nordahl (fnordahl)
Changed in charm-octavia:
status: Opinion → Won't Fix
Changed in charm-octavia-diskimage-retrofit:
status: Opinion → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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