On Tue, Jan 7, 2014 at 4:08 AM, William Reade <[email protected]> wrote: > On Tue, Jan 7, 2014 at 6:37 AM, John Arbash Meinel <[email protected]> > 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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
