charm has difficulties when run behind a firewall

Bug #1119412 reported by Gary Poster
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
juju-gui
Fix Released
High
Francesco Banconi

Bug Description

Some of these may be difficult to resolve. However, this records the challenges that can arise in these circumstances.

Let's start with a given that the machine is running Precise, and that the machine has access to standard Precise deb repos through (or within) the firewall.

Let's also assume that the user is working with the juju in the PPA. I don't think we test it any other way, do we? The charm has some code to try to make this work, but we don't have any automated guarantees. Anyway, if the user is not using the Juju from the PPA, the machine needs access to ppa:juju/pkgs on Launchpad in order to get python-charmhelpers and python-shelltoolbox. This also means accepting a cert.

What else does the charm need?

- It needs access to ppa:juju-gui/ppa on Launchpad in order to get the newer haproxy version we need. This also means accepting another cert.
- It needs to be able to download the release tarball from Launchpad.

Once we address bug 1117896, the following will only be needed if you are trying to run a GUI branch, rather than a release.

- It needs access to ppa:chris-lea/node.js on Launchpad in order to get the newer node and npm. This means accepting yet another cert.
- It needs to be able to check out the desired branch over bzr+ssh (usually from Launchpad).

Minimally, we should record these requirements (and assumptions!) in the charm's README. We can close this bug then, though we may want to open a duplicate later if we come up with a better solution.

Tags: theme-oil

Related branches

Revision history for this message
Gary Poster (gary) wrote :

A simple improvement might be to see if we can get our haproxy in the juju ppa, or, assuming that the certs are shared, another ppa owned by ~juju. That would mean that, once bug 1117896 was fixed, the only necessity to run the charm with a released verion of the GUI is the ability to download the release tarball.

Revision history for this message
Gary Poster (gary) wrote :

To make it possible for the charm to stop downloading the tarball, I propose that the charm start including the currently released version of the tarball when it is made. Default charm behavior would be to use the included version. Downloading from LP (the current default behavior) would be available as an option.

This corresponds to SA comments that they generally prefer charms to not reach out to other sources.

Maybe we should go so far as including the haproxy as a deb?

Revision history for this message
Gary Poster (gary) wrote :

Better solution, after some email discussion with Matthew Wedgwood: make it possible to specify a location to download the gui, and make it possible to specify a single archive (or no archive?) that will be used to obtain all deb dependencies.

For the first, I imagine adding charm functionality to support a directory URI from which to download releases. This could default to a CDN location. If no version number is specified but a directory URI was available, the charm would look on launchpad for the newest version and then download the release (named juju-gui-RELEASE.tgz) in the directory. If a version number were specified, the charm would look in the directory URI for juju-gui-RELEASE.tgz without contacting Launchpad.

David Britton (dpb)
tags: added: theme-oil
Revision history for this message
David Britton (dpb) wrote :

Adding theme-oil to this for tracking purposes. This bit is causing us to open another hole in the firewall for one charm and one tarball. Would be nice to get this fixed, thanks!

Gary Poster (gary)
Changed in juju-gui:
assignee: nobody → Francesco Banconi (frankban)
Changed in juju-gui:
status: Triaged → In Progress
Gary Poster (gary)
Changed in juju-gui:
status: In Progress → Fix Released
Revision history for this message
Gary Poster (gary) wrote :

We believe we have fixed this. The charm now only requires access to standard Ubuntu repositories. We've requested confirmation from some folks that this works for them, but we would appreciate anyone giving it a try and telling us how it goes.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.