Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[John van Ommen]

In regards to your last comment, that "it would be great for tenants
to be able to setup connections into AWS", HP CSA comes close to doing
that:

http://www8.hp.com/us/en/software-solutions/cloud-service-automation/

It's not *exactly* what you're looking for, you wouldn't be using the
OpenStack API. But it's as close as you can get right now.

IMHO, HP's OpenStack and it's integration with HP's automation tools
has made giant strides in the last year.

On Mon, Oct 3, 2016 at 4:29 PM, Curtis  wrote:
> On Mon, Oct 3, 2016 at 11:52 AM, Jonathan Proulx  wrote:
>>
>> So my sense from responses so far:
>>
>> No one is doing unified SDN solutions across clouds and no one really
>> wants to.
>
> I do want to (but am not doing). When I worked at a public cloud based
> on openstack we certainly wanted this kind of functionality, mostly
> between openstack regions. Likely so would telecoms, hence the
> tricircle link that was sent. But I left before we really got into it
> so I'm not sure what's happened there, or what has or is happening in
> openstack-land.
>
> I would also think it would be great for tenants to be able to setup
> connections into AWS, and even start up AWS instances via the
> openstack API. :)
>
> Thanks,
> Curtis.
>
>>
>> Consensus is just treat each network island like another remote DC and
>> use normal VPN type stuff to glue them together.
>>
>> ( nod to http://romana.io an interesting looking network and security
>> automation project as a network agnostic alternative to SDN for
>> managing cross cloud policy on whatever networks are available. )
>>
>> -Jon
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> --
> Blog: serverascode.com
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Curtis]

On Mon, Oct 3, 2016 at 11:52 AM, Jonathan Proulx  wrote:
>
> So my sense from responses so far:
>
> No one is doing unified SDN solutions across clouds and no one really
> wants to.

I do want to (but am not doing). When I worked at a public cloud based
on openstack we certainly wanted this kind of functionality, mostly
between openstack regions. Likely so would telecoms, hence the
tricircle link that was sent. But I left before we really got into it
so I'm not sure what's happened there, or what has or is happening in
openstack-land.

I would also think it would be great for tenants to be able to setup
connections into AWS, and even start up AWS instances via the
openstack API. :)

Thanks,
Curtis.

>
> Consensus is just treat each network island like another remote DC and
> use normal VPN type stuff to glue them together.
>
> ( nod to http://romana.io an interesting looking network and security
> automation project as a network agnostic alternative to SDN for
> managing cross cloud policy on whatever networks are available. )
>
> -Jon
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Blog: serverascode.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [kolla] Heka deprecated in Kolla

[Michał Jastrzębski]

Hello,

Kolla deprecates Heka in Ocata cycle, because Mozilla doesn't support
this project any more. During Ocata cycle we will prepare migration
plan and alternative to fill this missing functionality. As part of
N->O cycle we will migrate Heka to alternative we will decide upon in
following release. Our goal is to make this migration totally
transparent and logging infrastructure (which heka was part of) will
keep working in same way on higher levels (elastic, kibana).

Regards,
Michal

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Kilo to Liberty upgrade

[David Medberry]

Definitely read (and re-read) the release notes here:

https://wiki.openstack.org/wiki/ReleaseNotes/Liberty

paying close attention to the Upgrade Notes, API changes, etc.

You might also search (google or otherwise) this distribution list for
history on this topic as many of us did this q

On Mon, Oct 3, 2016 at 12:45 PM, Eric Yang  wrote:

> Hi all,
>
>
>
> Can anybody please share your experience with upgrading a Kilo environment
> to Liberty? More specifically I have a Kilo environment deployed and
> managed under Fuel 7.0, and I am looking for a path to upgrade it to
> Liberty. I would certainly like to:
>
> -  Keep it under management of the Fuel master;
>
> -  Preserve the previous configuration as much as possible;
>
> -  Find a way to migrate the instances with minimum to no
> down-time.
>
> I am open to giving up on some of the above criteria if I can upgrade with
> the least disruption to the instance workloads.
>
>
>
> I am also using Ceph underneath Cinder/Swift/Glance, and runs Juniper
> OpenContrail as a Neutron plugin.
>
>
>
> Thanks in advance for any idea/suggestions,
>
> *Eric Yang*
>
> *Senior Solutions Architect*
>
>
>
> *[image: cid:image003.jpg@01D1AB68.B3283440]* 
>
> *Technica Corporation*
>
> 22970 Indian Creek Drive, Suite 500, Dulles, VA 20166
>
> *Direct:* 703.662.2068
>
> *Cell:* 703.608.0845
>
>
>
> technicacorp.com
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Kilo to Liberty upgrade

[David Medberry]

Definitely read (and re-read) the release notes here:

https://wiki.openstack.org/wiki/ReleaseNotes/Liberty

paying close attention to the Upgrade Notes, API changes, etc.

You might also search (google or otherwise) this distribution list for
history on this topic as many of us did this quite some time ago.



(Sorry hit "send" inadvertently before the note was done.)

On Mon, Oct 3, 2016 at 12:45 PM, Eric Yang  wrote:

> Hi all,
>
>
>
> Can anybody please share your experience with upgrading a Kilo environment
> to Liberty? More specifically I have a Kilo environment deployed and
> managed under Fuel 7.0, and I am looking for a path to upgrade it to
> Liberty. I would certainly like to:
>
> -  Keep it under management of the Fuel master;
>
> -  Preserve the previous configuration as much as possible;
>
> -  Find a way to migrate the instances with minimum to no
> down-time.
>
> I am open to giving up on some of the above criteria if I can upgrade with
> the least disruption to the instance workloads.
>
>
>
> I am also using Ceph underneath Cinder/Swift/Glance, and runs Juniper
> OpenContrail as a Neutron plugin.
>
>
>
> Thanks in advance for any idea/suggestions,
>
> *Eric Yang*
>
> *Senior Solutions Architect*
>
>
>
> *[image: cid:image003.jpg@01D1AB68.B3283440]* 
>
> *Technica Corporation*
>
> 22970 Indian Creek Drive, Suite 500, Dulles, VA 20166
>
> *Direct:* 703.662.2068
>
> *Cell:* 703.608.0845
>
>
>
> technicacorp.com
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Kilo to Liberty upgrade

[Eric Yang]

Hi all,

Can anybody please share your experience with upgrading a Kilo environment to 
Liberty? More specifically I have a Kilo environment deployed and managed under 
Fuel 7.0, and I am looking for a path to upgrade it to Liberty. I would 
certainly like to:

-  Keep it under management of the Fuel master;

-  Preserve the previous configuration as much as possible;

-  Find a way to migrate the instances with minimum to no down-time.
I am open to giving up on some of the above criteria if I can upgrade with the 
least disruption to the instance workloads.

I am also using Ceph underneath Cinder/Swift/Glance, and runs Juniper 
OpenContrail as a Neutron plugin.

Thanks in advance for any idea/suggestions,
Eric Yang
Senior Solutions Architect

[cid:image003.jpg@01D1AB68.B3283440]
Technica Corporation
22970 Indian Creek Drive, Suite 500, Dulles, VA 20166
Direct: 703.662.2068
Cell: 703.608.0845

technicacorp.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Clint Byrum]

Excerpts from Jonathan Proulx's message of 2016-10-03 13:52:42 -0400:
> 
> So my sense from responses so far:
> 
> No one is doing unified SDN solutions across clouds and no one really
> wants to.
> 
> Consensus is just treat each network island like another remote DC and
> use normal VPN type stuff to glue them together.
> 
> ( nod to http://romana.io an interesting looking network and security
> automation project as a network agnostic alternative to SDN for
> managing cross cloud policy on whatever networks are available. )
> 

Oh sorry, there are people taking the complex route to what you want..
sort of:

https://wiki.openstack.org/wiki/Tricircle

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Jonathan Proulx]

So my sense from responses so far:

No one is doing unified SDN solutions across clouds and no one really
wants to.

Consensus is just treat each network island like another remote DC and
use normal VPN type stuff to glue them together.

( nod to http://romana.io an interesting looking network and security
automation project as a network agnostic alternative to SDN for
managing cross cloud policy on whatever networks are available. )

-Jon

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Silence Dogood]

I think the best general way to view networking in cloud is WAN vs Cloud
Lan.

There's almost always an edge routing env for your cloud environments (
whether they be by region or by policy or by tim is an angry dude and you
don't touch his instances ).

Everything beyond that edge is a WAN problem and can be handled in fairly
traditional ways... of course that's over simplifying things like BGP
passing into your cloud's lan env.  Or multihoming the edge router for that
cloud env to multiple networks ( god help you if there is spanning tree
involved ).

Honestly, I'd still use that demarcation though.  It helps split the issue
into manageable chunks.

-Matt

On Mon, Oct 3, 2016 at 11:59 AM, Chris Marino  wrote:

> This can also be done with IPv4 address as well. Not quite the flexibility
> that comes with v6, but workable for all but the very largest environments.
>
> This is the approach that is embodied in the Romana (http://romana.io/) 
> project
> (I am part of this effort).
>
> If you run all your OpenStack VMs on a 10/8 provider network, you can
> carve up the address space for projects, subnets, etc. You can NAT to your
> existing network, or push host routes to the VMs that need access (a
> feature that has not yet been implemented).
>
> CM
> ᐧ
>
> On Mon, Oct 3, 2016 at 8:20 AM, Jonathan Proulx  wrote:
>
>> On Sat, Oct 01, 2016 at 11:47:56AM -0600, Curtis wrote:
>> :On Fri, Sep 30, 2016 at 8:15 AM, Jonathan Proulx 
>> wrote:
>> :>
>> :> Starting to think refactoring my SDN world (currently just neutron
>> :> ml2/ovs inside OpenStack) in preparation for maybe finally lighting up
>> :> that second Region I've been threatening for the past year...
>> :>
>> :> Networking is always the hardest design challeng.  Has anyone seen my
>> :> unicorn?  I dream of something the first works with neutron of course
>> :> but also can extend the same network features to hardware out side
>> :> openstack and into random public cloud infrastructures through VM
>> and/or
>> :> containerised gateways.  Also I don't want to hire a whole networking
>> :> team to run it.
>> :>
>> :> I'm fairly certain this is still fantasy though I've heard various
>> :> vendors promise the earth and stars but I'd love to hear if anyone is
>> :> actually getting close to this in production systems and if so what
>> :> your experience has been like.
>> :>
>> :
>> :Do you want to have tenants be able to connect their openstack
>> :networks to another public clouds network using some kind of API? If
>> :so, what are your tenant networks? vlans? vxlan?
>>
>> Yes, I do  want to have tenants be able to connect their openstack
>> networks to another public clouds network using some kind of API.
>>
>> Since this is under consideration as part of a new region I haven't
>> implemented anything yet (current region is GRE but willing to cut
>> that off as 'legacy' epecially as we're trying to wind down the DC it
>> lives in).  So at this point all possibilites are on the table.
>>
>> My main question is "is anyone actually doing this" with a follow up
>> of "if so how?"
>>
>> Thanks,
>> -Jon
>>
>> :Thanks,
>> :Curtis.
>> :
>> :> -Jon
>> :>
>> :> --
>> :>
>> :> ___
>> :> OpenStack-operators mailing list
>> :> OpenStack-operators@lists.openstack.org
>> :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>> k-operators
>> :
>> :
>> :
>> :--
>> :Blog: serverascode.com
>>
>> --
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Chris Marino]

This can also be done with IPv4 address as well. Not quite the flexibility
that comes with v6, but workable for all but the very largest environments.

This is the approach that is embodied in the Romana (http://romana.io/) project
(I am part of this effort).

If you run all your OpenStack VMs on a 10/8 provider network, you can carve
up the address space for projects, subnets, etc. You can NAT to your
existing network, or push host routes to the VMs that need access (a
feature that has not yet been implemented).

CM
ᐧ

On Mon, Oct 3, 2016 at 8:20 AM, Jonathan Proulx  wrote:

> On Sat, Oct 01, 2016 at 11:47:56AM -0600, Curtis wrote:
> :On Fri, Sep 30, 2016 at 8:15 AM, Jonathan Proulx 
> wrote:
> :>
> :> Starting to think refactoring my SDN world (currently just neutron
> :> ml2/ovs inside OpenStack) in preparation for maybe finally lighting up
> :> that second Region I've been threatening for the past year...
> :>
> :> Networking is always the hardest design challeng.  Has anyone seen my
> :> unicorn?  I dream of something the first works with neutron of course
> :> but also can extend the same network features to hardware out side
> :> openstack and into random public cloud infrastructures through VM and/or
> :> containerised gateways.  Also I don't want to hire a whole networking
> :> team to run it.
> :>
> :> I'm fairly certain this is still fantasy though I've heard various
> :> vendors promise the earth and stars but I'd love to hear if anyone is
> :> actually getting close to this in production systems and if so what
> :> your experience has been like.
> :>
> :
> :Do you want to have tenants be able to connect their openstack
> :networks to another public clouds network using some kind of API? If
> :so, what are your tenant networks? vlans? vxlan?
>
> Yes, I do  want to have tenants be able to connect their openstack
> networks to another public clouds network using some kind of API.
>
> Since this is under consideration as part of a new region I haven't
> implemented anything yet (current region is GRE but willing to cut
> that off as 'legacy' epecially as we're trying to wind down the DC it
> lives in).  So at this point all possibilites are on the table.
>
> My main question is "is anyone actually doing this" with a follow up
> of "if so how?"
>
> Thanks,
> -Jon
>
> :Thanks,
> :Curtis.
> :
> :> -Jon
> :>
> :> --
> :>
> :> ___
> :> OpenStack-operators mailing list
> :> OpenStack-operators@lists.openstack.org
> :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> :
> :
> :
> :--
> :Blog: serverascode.com
>
> --
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Clint Byrum]

Excerpts from Jonathan Proulx's message of 2016-10-03 11:16:03 -0400:
> On Sat, Oct 01, 2016 at 02:39:38PM -0700, Clint Byrum wrote:
> 
> :I know it's hard to believe, but this world was foretold long ago and
> :what you want requires no special equipment or changes to OpenStack,
> :just will-power.  You can achieve it now if you can use operating system
> :versions published in the last 5 or so years.
> :
> :The steps to do this:
> :
> :1) Fix your apps to work via IPv6
> :2) Fix your internal users to have v6 native
> :3) Attach your VMs and containers to a provider network with v6 subnets
> :4) Use IPSec and firewalls for critical isolation. (What we use L2
> :   separation for now)
> 
> That *is* hard to belive :) IPv6 has been coming soon since I started
> in tech a very long time ago ... 
> 
> I will consider that but I have a diverse set of users I don't
> control.  I *may* be able to apply pressure in the if you really need
> this then do the right thing, but I probably still want a v4 solution
> in my pocket.
> 

Treat v4 as an internet-only, insecure, extra service that one must ask
for. It's extremely easy, with OpenStack, to provide both if people want
it, and just let them choose. Those who choose v4 only will find they
can't do some things, and have a clear incentive to change.

It's not that v6 is coming. It's here, knocking on your door. But,
like a vampire, you still have to invite it in.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] SDN for hybridcloud, does it *really* exist?

[Jonathan Proulx]

On Sat, Oct 01, 2016 at 02:39:38PM -0700, Clint Byrum wrote:

:I know it's hard to believe, but this world was foretold long ago and
:what you want requires no special equipment or changes to OpenStack,
:just will-power.  You can achieve it now if you can use operating system
:versions published in the last 5 or so years.
:
:The steps to do this:
:
:1) Fix your apps to work via IPv6
:2) Fix your internal users to have v6 native
:3) Attach your VMs and containers to a provider network with v6 subnets
:4) Use IPSec and firewalls for critical isolation. (What we use L2
:   separation for now)

That *is* hard to belive :) IPv6 has been coming soon since I started
in tech a very long time ago ... 

I will consider that but I have a diverse set of users I don't
control.  I *may* be able to apply pressure in the if you really need
this then do the right thing, but I probably still want a v4 solution
in my pocket.

-Jon
 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Ops Meetups Team - Update on Schedule planning

[Matt Van Winkle]

Hi Ops Meetups Team,

Friday, a few of us met to discuss the current version of the agenda [1].  We 
made a few tweaks and have a few items to discuss at the next meeting.  Namely:

- We removed the scheduled session for lightning talks because room for them is 
in the Ops war stories track
- We added a slot to have all the WG leaders introduce their teams, what they 
are working on and what they hope to accomplish as a team in BCN.  A pending 
action is open to reach out to them
- We swapped the AUC Update and Swift sessions from the first version to give 
those interested in various storage topics to attend both
- We need to confirm that the NFV sessions in this calendar are duplicates now 
that the WG has had sessions scheduled through the separate WG process.  If so, 
this will free up two slots in the morning
- There are 3 or so empty slots that we can still look at, but the team 
wondered if leaving the ones late in the day open might be good for 
overflow/follow up from earlier sessions

We can discuss all of this in more detail in the meeting tomorrow.  [2] I will 
try to make notes in the agenda.

Thanks!
VW

[1] 
https://docs.google.com/spreadsheets/d/1EUSYMs3GfglnD8yfFaAXWhLe0F5y9hCUKqCYe0Vp1oA/edit#gid=803513477

[2] https://wiki.openstack.org/wiki/Ops_Meetups_Team#Meeting_Information




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Reserve an external network for 1 tenant

[Saverio Proto]

Sorry I missed the Mailing List in the Cc:
Saverio

2016-10-03 9:15 GMT+02:00 Saverio Proto :
> Hello Kevin,
>
> thanks for your answer.
>
> so far I managed to make the network not shared just by making it not
> external. Because I dont need NAT and floatingips this will match my
> use case.
>
> As an admin I create the network like:
> openstack network create --no-share --project user_project_uuid
> --provider-physical-network physnet2 --provider-network-type flat
> NETWORKNAME
>
> In this way only the users that belong to user_project_uuid see the
> network with 'list' and 'show' operations.
>
> I still have to test carefully if Openstack will allow isolation to
> brake in case a user or admin tries to create more networks mapped to
> physnet2
>
> I hope I will upgrade to Mitaka as soon as possible.
>
> thank you
>
> Saverio
>
>
>
>
>
> 2016-10-03 7:00 GMT+02:00 Kevin Benton :
>> You will need mitaka to get an external network that is only available to
>> specific tenants. That is what the 'access_as_external' you identified does.
>>
>> Search for the section "Allowing a network to be used as an external
>> network" in
>> http://docs.openstack.org/mitaka/networking-guide/config-rbac.html.
>>
>> On Thu, Sep 29, 2016 at 5:01 AM, Saverio Proto  wrote:
>>>
>>> Hello,
>>>
>>> Context:
>>> - openstack liberty
>>> - ubuntu trusty
>>> - neutron networking with vxlan tunnels
>>>
>>> we have been running Openstack with a single external network so far.
>>>
>>> Now we have a specific VLAN in our datacenter with some hardware boxes
>>> that need a connection to a specific tenant network.
>>>
>>> To make this possible I changed the configuration of the network node
>>> to support multiple external networks. I am able to create a router
>>> and set as external network the new physnet where the boxes are.
>>>
>>> Everything looks nice except that all the projects can benefit from
>>> this new external network. In any tenant I can create a router, and
>>> set the external network and connect to the boxes. I cannot restrict
>>> it to a specific tenant.
>>>
>>> I found this piece of documentation:
>>>
>>>
>>> https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
>>>
>>> So it looks like it is impossible to have a flat external network
>>> reserved for 1 specific tenant.
>>>
>>> I also tried to follow this documentation:
>>>
>>> http://docs.openstack.org/liberty/networking-guide/adv-config-network-rbac.html
>>>
>>> But it does not specify if it is possible to specify a policy for an
>>> external network to limit the sharing.
>>>
>>> It did not work for me so I guess this does not work when the secret
>>> network I want to create is external.
>>>
>>> There is an action --action access_as_external that is not clear to me.
>>>
>>> Also look like this feature is evolving in Newton:
>>> http://docs.openstack.org/draft/networking-guide/config-rbac.html
>>>
>>> Anyone has tried similar setups ? What is the minimum openstack
>>> version to get this done ?
>>>
>>> thank you
>>>
>>> Saverio
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Reserve an external network for 1 tenant

[Saverio Proto]

Hello Matt,

first of all in the file : plugins/ml2/openvswitch_agent.ini

you need to have bridge mappings, in my case for example:
bridge_mappings = physnet1:br-eth3,physnet2:br-eth4

this will define what physnet1 means in the openstack context. To
create the external network I do:

openstack network create --no-share --project uuid
--provider-physical-network physnet2 --provider-network-type flat
--external NETWORKNAME

Of course the --no-share is useless because being the network external
it will be shared by default.

Saverio


2016-10-03 6:15 GMT+02:00 Matt Kassawara :
> How are you creating the provider (external) network?
>
> On Thu, Sep 29, 2016 at 6:01 AM, Saverio Proto  wrote:
>>
>> Hello,
>>
>> Context:
>> - openstack liberty
>> - ubuntu trusty
>> - neutron networking with vxlan tunnels
>>
>> we have been running Openstack with a single external network so far.
>>
>> Now we have a specific VLAN in our datacenter with some hardware boxes
>> that need a connection to a specific tenant network.
>>
>> To make this possible I changed the configuration of the network node
>> to support multiple external networks. I am able to create a router
>> and set as external network the new physnet where the boxes are.
>>
>> Everything looks nice except that all the projects can benefit from
>> this new external network. In any tenant I can create a router, and
>> set the external network and connect to the boxes. I cannot restrict
>> it to a specific tenant.
>>
>> I found this piece of documentation:
>>
>>
>> https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
>>
>> So it looks like it is impossible to have a flat external network
>> reserved for 1 specific tenant.
>>
>> I also tried to follow this documentation:
>>
>> http://docs.openstack.org/liberty/networking-guide/adv-config-network-rbac.html
>>
>> But it does not specify if it is possible to specify a policy for an
>> external network to limit the sharing.
>>
>> It did not work for me so I guess this does not work when the secret
>> network I want to create is external.
>>
>> There is an action --action access_as_external that is not clear to me.
>>
>> Also look like this feature is evolving in Newton:
>> http://docs.openstack.org/draft/networking-guide/config-rbac.html
>>
>> Anyone has tried similar setups ? What is the minimum openstack
>> version to get this done ?
>>
>> thank you
>>
>> Saverio
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators