juju-gui

gui fails to deploy a bundle due to "Invalid charm id: undefined"

Bug #1276107 reported by Jorge Castro on 2014-02-04

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	juju-gui	Incomplete	High	Unassigned

Bug Description

I am trying to deploy this bundle (see attached), but the GUI doesn't deploy it. deployer does.

Import Environment Failed
Import from "bundles.yaml" failed.
Invalid charm id: undefined

Revision history for this message

Jorge Castro (jorge) wrote on 2014-02-04:

bundles.yaml Edit (2.6 KiB, text/plain)

Revision history for this message

Jorge Castro (jorge) wrote on 2014-02-04:

Juan Negron thinks it's these lines that are causing the issue:

- lxc:keystone=0

Changed in juju-gui:
status:	New → Confirmed

Revision history for this message

Richard Harding (rharding) wrote on 2014-02-04:

Note that this is on the jujucharms.com site with the fakebackend. It also fails on comingsoon.

Changed in juju-gui:
importance:	Undecided → High
status:	Confirmed → Triaged

Revision history for this message

Francesco Banconi (frankban) wrote on 2014-02-04:

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.