On Tue, 2017-04-11 at 16:50 +0200, Jan Provaznik wrote: > On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec <openst...@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  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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev