Bug 1394306

Dan, can you offer some guidance here?

Jeremy, Dan will want to know why a second storage network is needed -- what is the use case and is there another way to get Fidelity what they need?

(In reply to Jeremy from comment #0)
> Description of problem: Is it possible to add a second storage network in
> director
> 
> 
> Version-Release number of selected component (if applicable):
> python-tripleoclient-0.3.4-6.el7ost.noarch
> openstack-tripleo-heat-templates-0.8.14-18.el7ost.noarch
> openstack-tripleo-common-0.3.1-1.el7ost.noarch
> openstack-tripleo-heat-templates-kilo-0.8.14-18.el7ost.noarch
> openstack-tripleo-image-elements-0.9.9-2.el7ost.noarch
> openstack-tripleo-0.0.7-1.el7ost.noarch
> 
> 
> 
> 
> Additional info:
> 
> Also is it possible to change the ip address of the storage network in
> director , or would that be a seperate RFE?

I need more information about what is being asked. Why do you need a second storage network? What do you mean by "is it possible to change the ip address of the storage network"? Do you mean post-deployment you want to renumber the IP addresses on one of the networks?

Unfortunately, modifying the IP addresses on an already-deployed network is not currently supported.

We have two storage-related networks in OSP-Director, Storage and Storage Management. Not very much runs on the Storage Management network, mostly it is used for Ceph monitoring and Swift proxy (when Swift is deployed). You can reassign the services from Storage Management to another network if desired, then use the Storage Management network as desired.

With OSP 8 and later, you also have the option of enabling the "Management" network. This can be used for system administration, but can also be used for connectivity to an extra network if desired. The only catch is that OpenStack services which use a virtual IP can't run on the Management network, but they can run on the Storage Management network.

Hello,
The customer says: 
"
We are going to have multiple tiers of storage backends. We started off with just ceph, the current effort is to add higher performance storage via our existing Infinidat arrays, in the future we will add a 3rd tier of high performance storage from an all-flash array (flash product is TBD)."

Thanks,

(In reply to Jeremy from comment #3)
> Hello,
> The customer says: 
> "
> We are going to have multiple tiers of storage backends. We started off with
> just ceph, the current effort is to add higher performance storage via our
> existing Infinidat arrays, in the future we will add a 3rd tier of high
> performance storage from an all-flash array (flash product is TBD)."
> 
> Thanks,

Thanks. I'm curious as to why they want multiple networks for multiple storage technologies? Are they going to use multiple NIC interfaces? If the proposal is to use separate VLANs on the same interface, then I wonder if it wouldn't be better to put all 3 storage technologies on one network? After all, the Storage network is currently used for Ceph, Swift, Cinder, and Glance. If using a single network, it can also be placed on a bond for more aggregate bandwidth.

In any case, it sounds like the additional storage network would not have any services set up by OSP-Director, so I think using the Management network is possible.

So the answer is: yes, you can configure an additional network if desired. The Storage Management network can be repurposed as a second storage network, or the Management network can be activated and they can use that, as long as you don't need any OpenStack services listening on a virtual IP on the Management network.

However, there is very little information in this ticket, and I don't feel very confident giving specific recommendations without knowing more about what they are trying to achieve.

From the customer:

We want multiple networks because we can not necessarily change the way that our storage arrays are configured. It's very restricting to have to change our environment (compute, network, storage) to fit OSP rather than change OSP to fit into our environment. Our clusters will live for years and being locked into the architecture that was deployed day 1 will not work. These clusters cannot be static, they need to grow and evolve as our requirements/challenges/goals change. 

I was able to use the management network to add the new VLAN interface.

Really we need two RFEs here, per the customer.

#1. the ability to reconfigure existing networks on an UPDATE operation rather than only on CREATE/DEPLOY. A customer may want to change an existing network address range or add new addresses to a range WITHOUT redeploying. There is a semi-documented process for achieving this already. So the RFE would be to get this tested and supported through upgrades, etc.

#2. the ability to ADD new networks beyond the 6-7 networks provided through network isolation. Customers may have a need to add arbitrary networks and want the ability to manage them through the same facilities they use to manage the current set of networks. 

dsneddon, how should I proceed? Do you want me to create 1 (or 2) new RFEs to disambuguate and track these requests?

It seems to me that some of this may be achievable already but has not been through CI or QA.

Hello, Dan

The below is that you commented. 

"We have two storage-related networks in OSP-Director, Storage and Storage Management. Not very much runs on the Storage Management network, mostly it is used for Ceph monitoring and Swift proxy (when Swift is deployed). You can reassign the services from Storage Management to another network if desired, then use the Storage Management network as desired."

I have one question. Did you mean that storage management network is used for Ceph monitoring in OSP-Director?

Assaf, can you clarify that all network connectivity scanarios in TripleO are indeed on DFG:Networking? I am not sure moving the bug from DFG:DF was the right thing to do here.

Moving to Hardware Provisioning DFG.

>Really we need two RFEs here, per the customer.

>#1. the ability to reconfigure existing networks on an UPDATE operation rather than >only on CREATE/DEPLOY. A customer may want to change an existing network address range >or add new addresses to a range WITHOUT redeploying. There is a semi-documented >process for achieving this already. So the RFE would be to get this tested and >supported through upgrades, etc.

>#2. the ability to ADD new networks beyond the 6-7 networks provided through network >isolation. Customers may have a need to add arbitrary networks and want the ability to >manage them through the same facilities they use to manage the current set of networks. 

The RFE for additional, i.e. composable, networks is tracked here and is planned for OSP-12:
https://bugzilla.redhat.com/show_bug.cgi?id=1406102

(In reply to jliberma from comment #6)
> Really we need two RFEs here, per the customer.
> 
> #1. the ability to reconfigure existing networks on an UPDATE operation
> rather than only on CREATE/DEPLOY. A customer may want to change an existing
> network address range or add new addresses to a range WITHOUT redeploying.
> There is a semi-documented process for achieving this already. So the RFE
> would be to get this tested and supported through upgrades, etc.

This one is actually problematic to implement. Heat doesn't allow the subnet to be modified if there are existing ports on the subnet. Additionally, we need a feature in Heat to be able to update ports on existing Ironic nodes. Recent additions to Ironic/Neutron integration may make this possible (I'll have to test again), but the Control Plane is a separate problem.

When TripleO was first developed, the Ironic servers were created with "implicit" Neutron ports (only the network name was passed, and Ironic would request a port on that network from Neutron). This results in a port that cannot be updated. I have a bug open:

https://bugs.launchpad.net/neutron/+bug/1691885

This is not an issue when the Ironic server if a Neutron port is created and then passed to the Ironic server. However, we don't have a way to switch from one mode to the other during upgrades. This may result in a hard split when we implement spine-and-leaf that results in older deployments not being able to upgrade directly to the new, updatable, resource type. New deployments would have the new mechanism, and would be able to take advantage of updatable subnets and optionally routed spine-and-leaf.

We now have the ability to add networks to any deployment using Composable Networks. This allows the installer to add a network to a deployment, and using the ServiceNetMap one can move services from one network to another if need be.

This is primarily aimed at new deployments, although it is possible to add a network to an existing deployment on stack update. The one thing we still cannot do is modify an existing network, although we have assisted customers in creating a new network, migrating from the old, and then deactivating the old network.

I believe that using Composable Networks with OSP 12+, the original functionality requested is now possible. I am closing this ticket for now, please feel free to reopen if further discussion is needed.