Several stakeholders want to escalate this bug. I think we are being asked to fix this issue soon.
I think this bug as it is currently described is low because it advocates a solution without defining the root problem that needs solving. Canonical webops create fat-charms (embedded dependencies and content) to deploy services. I think this is a hack that has reached its evolutionary dead end. The mojo project may dictate that fat-charms are the only way to deploy to production.
I believe the real issue here is that we do not have a best-practice strategy to recommend placing dependencies in an environment for all charms/services to share. As for content, surely this could be handled as other DB and site charms by mounting/switching the storage.
If we do want to address this bug as it is described, then may this is a performance bug.
Hi John, Tim, and William, Kapil, et al.
Several stakeholders want to escalate this bug. I think we are being asked to fix this issue soon.
I think this bug as it is currently described is low because it advocates a solution without defining the root problem that needs solving. Canonical webops create fat-charms (embedded dependencies and content) to deploy services. I think this is a hack that has reached its evolutionary dead end. The mojo project may dictate that fat-charms are the only way to deploy to production.
I believe the real issue here is that we do not have a best-practice strategy to recommend placing dependencies in an environment for all charms/services to share. As for content, surely this could be handled as other DB and site charms by mounting/switching the storage.
If we do want to address this bug as it is described, then may this is a performance bug.