Focus for the next three weeks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...

>> Right now we don't have a way to restrict the users creating 
>> containers that they cannot address.  I propose that we add a 
>> method to the environment interface that is SupportsContainers() 
>> bool.  This can then be used to stop people at least creating 
>> containers that they can't use.
>> 
>> This I think we need to do in the next three weeks, and make
>> sure the add-machine and deployment commands respect whether 
>> containers are supported or not.  Currently the only provider 
>> that actually supports containers is MAAS.
>> 
>> Next I think we should have SupportedContainers() on a machine. 
>> Different machines can support different containers.  However
>> I'm not sure we should do this in the next three weeks, so will
>> be the focus of a different email.

I don't see a big gain in having the bool before the list. You can
treat an empty list as false, and only allow "LXC" for phase one, and
then you don't have to implement 2 APIs.

> 
> Do we want to support creating just one container, or block 
> container creation full stop in most environments?

If we don't actually spend the time to actually do the necessary port
forwarding, we just want to block container creation. And because of
the "private IP addresses are fully exposed" problem you've outlined,
I don't think we can easily do the necessary port forwarding.

> 
>> 6. Container addressability for EC2 / Openstack
>> 
>> I don't know where this is at right now.  Can Martin please fill 
>> us in.
> 
> Doing EC2 requires some work on goamz, but is all pretty 
> straightforward, with a few unknowns around how they permit VPC 
> with older accounts. I'm still not clear what the solution for 
> Openstack deployments without neutron is. You mentioned previously 
> that was a requirement and something IS knew how to do, but I'm 
> none the wiser as to what needs implementing there.
> 
> Martin
> 

The bit I heard about for Openstack-without-neutron was that there was
a Nova api that would let you add another IP address. But that still
had a bug upstream where the new IP address didn't get added to the
correct routing tables.

IOW, it isn't something that I feel we could depend upon today. More
something that we'll want to support when we get it figured out.

Kapil does have VPC-by-default on one of his accounts, and has already
posted some bugs about juju not working there. (Something about it not
getting added to an expected security group, etc.)
  https://bugs.launchpad.net/bugs/1221868

He also stated that Amazon has changed there plans again and normal
VPC is going to also be doing public IP addresses for all machines in
the near term.

So I would personally recommend focusing on MaaS first,
SupportedContainers() second, and goamz third. And then
Openstack-with-neutron. The main caveat on that is that we don't have
a CPC that exposes neutron, and Canonistack doesn't have it either.
Which pushes it even farther down the "worth implementing" chain. If
the Openstack clouds we spin up via MaaS (grizzly+) will have it, then
it is probably worth investigating.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIvLdUACgkQJdeBCYSNAANkugCgy595P4rJ0E4oOosfADqDg2N9
aKAAoJKAKn+8sLQCHm3nsIP271bQUzLq
=6kc7
-----END PGP SIGNATURE-----