[Openstack-operators] Small openstack

gustavo panizzo (gfa) gfa at zumbi.com.ar
Thu Jan 8 10:53:36 UTC 2015

On 01/08/2015 06:36 PM, Antonio Messina wrote:
> Hi all, I'm also interested in this setup.
> On Fri, Dec 26, 2014 at 12:31 AM, George Shuklin
> <george.shuklin at gmail.com> wrote:
>> Report on progress so far:
>> I was able to fix policies (nova/neutron) to allow tennants to plug to 'own'
>> external networks, found and report few bugs about error messaging in ML2,
>> got working dhcp-agent (on external network! haha). Right now it works with
> Can you please be a bit more specific on the issues and bug reports? I
> did some testing on this kind of setup, and as far as I understand
> Neutron in Juno does not allow you to change the policy for one
> specific network, so the best I could do is to allow *any* tenant to
> plug a port on *any* external network, while in my setup I would like
> to only allow tenants to plug an interface on one specific external
> network (I will create different "external" networks of this kind)

i may be wrong as i haven't tested that on juno, but in icehouse and 
havana i've setup external/provider networks one for each tenant
you may need to apply a patch for BUG #1352102 (i'm not sure if it made 
it into juno)

> I wrote a short blogpost with the configuration I made:
> http://www.s3it.uzh.ch/blog/openstack-neutron-vlan/

i've set the policy like this

    "network:attach_external_network": "rule:admin_or_owner"

> .a.
>> Up to now it looks really great from infrastructure (ops) point of view: no
>> SPoF on networks nodes, no NAT, no confusing local addresses with floatings.
>> Each instance receive white IP and use it as it is. All routing is offloaded
>> to network hardware. Cool oldstyle robust networking, less non-computing
>> (not paying) hosts, less moving parts. It may be not so great from point of
>> view of 'bleeding edge' part of openstack (heat/LB/etc), but I do not want
>> my infrastructure to bleed...
> I really like this design too, very KISS-y

100% agree

1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

More information about the OpenStack-operators mailing list