Charm size is bigger than other reactive OpenStack charms
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-
Here are top 10 charms in the store in terms of the size of the charms below.
octavia (~46MB) and octavia-
[charm,
octavia,https:/
octavia-
barbican-vault,https:/
masakari,https:/
designate,https:/
manila,https:/
gnocchi,https:/
manila-ganesha,https:/
barbican,https:/
nova-cell-
[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/
5.8M wheelhouse/
1.8M wheelhouse/
1.6M wheelhouse/
1.4M wheelhouse/
1.3M wheelhouse/
1.1M wheelhouse/
916K wheelhouse/
836K wheelhouse/
776K wheelhouse/
Changed in charm-octavia: | |
status: | Opinion → Won't Fix |
Changed in charm-octavia-diskimage-retrofit: | |
status: | Opinion → Won't Fix |
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.