barclamp-neutron: Renaming br-public to br-ex?
23 views
Skip to first unread message
Ralf Haferkamp
Jul 22, 2015, 6:17:44 AM7/22/15
to cro...@googlegroups.com
Hi,
with https://github.com/crowbar/barclamp-neutron/pull/227 and related pull
requests in crowbar and barclamp-nova we will allow the "public" and
"nova_floating" networks use different physical interfaces and separate
network ranges (up to now we required "nova_floating" to use the same interface
as "public" and use an IP range within the "public" network).
When using the openvswitch mechanism driver we create neutron's external
network bridge (the one hosting the "floating" network) with the name
"br-public".
This creates the somewhat ugly situation that when deploying a configuration
where "public" and "nova_floating" are on different physical interfaces and
separate IP ranges, we endup with a bridge called "br-public" that has nothing
to do with the "public" network. Better names would be e.g. "br-floating" or
"br-ex" (this is what e.g. devstack uses and what is also used in a lot of places
in the upstream documentation when referring to the external network bridge).
However, renaming that thing is not exactly easy especially when taking
upgrades into account. So IMO the best way of handling it would be to avoid
renaming the bridge for existing installations (that includes "tex" systems
that get the backported patch deployed as an update, but also "tex" systems
that get upgraded to "tex+1" at some point). Only completely new deployments
would get the bridge created by the new name (whatever we choose for that).
The downside of this approach would be of course that we will have some
difference in the naming between system that have been upgraded from "tex" and
new deplyoments. This might create some issues e.g. with the documentation.
Though currently it seems "br-public" is not mentioned anywhere in the
deployment guide.
Any opinions on this? Other suggestions how we should handle this?
Of course we could just stay with the current name (br-public) and not worry
about the ambiguity at all.
--
Ralf
with https://github.com/crowbar/barclamp-neutron/pull/227 and related pull
requests in crowbar and barclamp-nova we will allow the "public" and
"nova_floating" networks use different physical interfaces and separate
network ranges (up to now we required "nova_floating" to use the same interface
as "public" and use an IP range within the "public" network).
When using the openvswitch mechanism driver we create neutron's external
network bridge (the one hosting the "floating" network) with the name
"br-public".
This creates the somewhat ugly situation that when deploying a configuration
where "public" and "nova_floating" are on different physical interfaces and
separate IP ranges, we endup with a bridge called "br-public" that has nothing
to do with the "public" network. Better names would be e.g. "br-floating" or
"br-ex" (this is what e.g. devstack uses and what is also used in a lot of places
in the upstream documentation when referring to the external network bridge).
However, renaming that thing is not exactly easy especially when taking
upgrades into account. So IMO the best way of handling it would be to avoid
renaming the bridge for existing installations (that includes "tex" systems
that get the backported patch deployed as an update, but also "tex" systems
that get upgraded to "tex+1" at some point). Only completely new deployments
would get the bridge created by the new name (whatever we choose for that).
The downside of this approach would be of course that we will have some
difference in the naming between system that have been upgraded from "tex" and
new deplyoments. This might create some issues e.g. with the documentation.
Though currently it seems "br-public" is not mentioned anywhere in the
deployment guide.
Any opinions on this? Other suggestions how we should handle this?
Of course we could just stay with the current name (br-public) and not worry
about the ambiguity at all.
--
Ralf
Vincent Untz
Jul 22, 2015, 9:27:16 AM7/22/15
to cro...@googlegroups.com
tex+1 upgrades, but maybe I'm too optimistic...
Vincent
--
Les gens heureux ne sont pas pressés.
Adam Spiers
Jul 29, 2015, 12:02:21 PM7/29/15
to cro...@googlegroups.com
although I agree the docs might end up a bit confusing for one or two
releases.
> I'm not even sure I would worry about
> tex+1 upgrades, but maybe I'm too optimistic...
Reply all
Reply to author
Forward
0 new messages