Open sed-i opened 2 years ago
This functionality is super important for LMA 2. We intend to ship LMA 2 as fundamentally "an appliance" in a self-contained Juju model, which means that being able to define the offers upfront in the bundle is a far, far better UX that not doing so.
Turns out that, for now, this is limitation was meant to be there, as overlays are mostly specific to a deployment (see https://github.com/juju/charmstore/pull/884 ). Nevertheless, I feel very strongly that default offers should be a valid exception to the rule.
At least charmcraft should not crash trying to read the file. Probably we should load_all
the file and use only the first part.
if you could force
trust
like that, and given that trust gives you access to cloud credentials I would be very weary deploying any bundle from the store without having to carefully audit its contents first... (which you would also have to do every time there is a revision bump) [...] you would need to add logic to juju to distinguish between local and remote bundles. also patch pylibjuju. also make sure it can work in non-interactive mode for automated deployments -- @achilleasa
I agree that load
vs load_all
in charmcraft should not be our safety measure against unsafe bundles.
if you could force
trust
like that, and given that trust gives you access to cloud credentials I would be very weary deploying any bundle from the store without having to carefully audit its contents first... (which you would also have to do every time there is a revision bump) [...] you would need to add logic to juju to distinguish between local and remote bundles. also patch pylibjuju. also make sure it can work in non-interactive mode for automated deployments -- @achilleasa
As it turns out my understanding of how the trust
attribute works in the context of bundles was wrong. As @jameinel correctly pointed out, even if the bundle annotates some charms as trusted, the user must explicitly invoke the juju deploy
command with the --trust
flag to confirm that those charms should be trusted. Apologies for any confusion.
We will fix charmcraft, to not crash in this situation, and add a linter that will detect that the bundle has overlays, and refuse to pack if so.
But, as linters can be ignored, we will wait for Charmhub to start rejecting this kind of bundles (tracked here).
I'm trying to pack this bundle, which has multiple documents (bundle + overlay):
Ref: charm-bundles/1058