Closed network support

[Curtis Hovey-Canonical]

On Tue, Jan 7, 2014 at 4:08 AM, William Reade
<william.reade at canonical.com> wrote:
> On Tue, Jan 7, 2014 at 6:37 AM, John Arbash Meinel <john at arbash-meinel.com>
> Actually setting up a closed environment, and seeing what breaks, is
> critical. Figuring out some of the broken bits in advance will help, for
> sure, but reality is our best teacher here.

Juju-QA has been discussing how to do this. The goal is to
setup/discover the recommended setup for proxying. We want to record
what wanted access to where. When tests fail we can report a
regression, or document a new requirement.

We don't know how to setup a closed-network cloud within canonistack,
such that CI can call juju bootstrap/deploy and always get machines
with limited networking. One possibility is to use the MaaS or
local/manual-provider where we cripple the network and setup the proxy
for one machine before using juju.

I think publishing the os-images and juju tools to the closed cloud
will always be a recommendation, but we can test that
streams.canonical.com is available.

>> I think charms themselves can try to download remote things. For
>> priority charms, (eg Openstack) we want to make sure that they *can*
>> be installed without outside access.

Fat charms? Putting the apps in Ubuntu Universe? Setting up a proxy to
capture the required assets so that charms on the closed network can
use them? I think we are obligated to document what needs external
assets. IS uses tools like Mojo and charm-tools to create local repos
of vetted charms.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui