On 04/11/2017 02:00 PM, Giulio Fidente wrote:
On Tue, 2017-04-11 at 16:50 +0200, Jan Provaznik wrote:
On Mon, Apr 10, 2017 at 6:55 PM, Ben Nemec <[email protected]>
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
I think there are three major pieces that would need to be in place to
have a storage provider network:
1) The storage network must be bridged in the net-iso templates. I
don't think our default net-iso templates do that, but there are
examples of bridged networks in them:
https://github.com/openstack/tripleo-heat-templates/blob/master/network/config/multiple-nics/compute.yaml#L121
For the rest of the steps I will assume the bridge was named br-storage.
2) Specify a bridge mapping when deploying the overcloud. The
environment file would look something like this (datacentre is the
default value, so I'm including it too):
parameter_defaults:
NeutronBridgeMappings: 'datacentre:br-ex,storage:br-storage'
3) Create a provider network after deployment as described in the link
Giulio provided. The specific command will depend on the network
architecture, but it would need to include "--provider:physical_network
storage".
We might need to add the ability to do 3 as part of the deployment,
depending what is needed for the Ganesha deployment itself. We've
typically avoided creating network resources like this in the deployment
because of the huge variations in what people want, but this might be an
exceptional case since the network will be a required part of the overcloud.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
