Most of the charms in this bundle must be deployed from a branch, and this is not supported. Both the fake backend and the real one require the "charm" field to be specified on all services. This causes the "Invalid charm id" error when using the fake backend, and a more obscure "No such file or directory" on real environments. In the latter case, the deployer tries to download the branch and save it inside the Juju home, which does not exist in the GUI machine. Now that we are introducing local charms deployment, we could discuss a path to add support for local charms in bundles too. This might include updating the deployer so that the new HTTPS putCharm API is used (rather than the CLI), then enabling the functionality in the gui server itself, and finally changing how bundles are handled by the GUI fake backend.
2) the bundle includes the "juju-gui" service:
this is not a problem when sandbox is used, but generates a validation error in real environments because a service named "juju-gui" already exists.
A design decision seems required here IMHO: marking as Incomplete for this reason.
The bundle includes two bits we don't currently support:
1) local charms in bundles, e.g.:
ceph:
branch: lp:charms/precise/ceph
Most of the charms in this bundle must be deployed from a branch, and this is not supported. Both the fake backend and the real one require the "charm" field to be specified on all services. This causes the "Invalid charm id" error when using the fake backend, and a more obscure "No such file or directory" on real environments. In the latter case, the deployer tries to download the branch and save it inside the Juju home, which does not exist in the GUI machine. Now that we are introducing local charms deployment, we could discuss a path to add support for local charms in bundles too. This might include updating the deployer so that the new HTTPS putCharm API is used (rather than the CLI), then enabling the functionality in the gui server itself, and finally changing how bundles are handled by the GUI fake backend.
2) the bundle includes the "juju-gui" service:
this is not a problem when sandbox is used, but generates a validation error in real environments because a service named "juju-gui" already exists.
A design decision seems required here IMHO: marking as Incomplete for this reason.