Open Stack

On Tue, 2017-04-11 at 16:50 +0200, Jan Provaznik wrote:
> On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec <openstack at nemebean.com>
> wrote:
> > On 04/10/2017 03:22 AM, Jan Provaznik wrote:
> > Well, on second thought it might be possible to make the Storage
> > network
> > only routable within overcloud Neutron by adding a bridge mapping
> > for the
> > Storage network and having the admin configure a shared Neutron
> > network for
> > it.  That would be somewhat more secure since it wouldn't require
> > the
> > Storage network to be routable by the world.  I also think this
> > would work
> > today in TripleO with no changes.
> > 
> 
> This sounds interesting, I was searching for more info how bridge
> mapping should be done in this case and how specific setup steps
> should look like, but the process is still not clear to me, I would
> be
> grateful for more details/guidance with this.

I think this will be represented in neutron as a provider network,
which has to be created by the overcloud admin, after the overcloud
deployment is finished

While based on Kilo, this was one of the best docs I could find and it
includes config examples [1]

It assumes that the operator created a bridge mapping for it when
deploying the overcloud

> > I think the answer here will be the same as for vanilla Ceph.  You
> > need to
> > make the network routable to instances, and you'd have the same
> > options as I
> > discussed above.
> > 
> 
> Yes, it seems that using the mapping to provider network would solve
> the existing problem when using ceph directly and when using ganesha
> servers in future (it would be just matter of to which network is
> exposed).

+1

regarding the composability questions, I think this represents a
"composable HA" scenario where we want to manage a remote service with
pacemaker using pacemaker-remote

yet at this stage I think we want to add support for new services by
running them in containers first (only?) and pacemaker+containers is
still a work in progress so there aren't easy answers

containers will have access to the host networks though, so the case
for a provider network in the overcloud remains valid

1. https://docs.openstack.org/kilo/networking-guide/scenario_provider_o
vs.html
-- 
Giulio Fidente
GPG KEY: 08D733BA