4) Without Ceph, Storage network will be used for Swift traffic (afair both replication and client/server).
5) Yes, this is still correct. We have a blueprint to make this more flexible: https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks On Sat, Jul 12, 2014 at 1:50 PM, Dmitriy Novakovskiy <[email protected]> wrote: > Some more questions on networks > > 4) When I build the environment w/o Ceph I still get the Storage network to > be configured on "Configure interfaces" and on "Networks" screens. Why is > that, what this network will be used for? > > 5) If I choose to deploy w/ Ceph - what will Storage network be used for? I > assume that it will serve replication, and data traffic between a VM and an > RBD volume will go through Management network - is that correct? > > --- > Regards, > Dmitriy > > > On Sat, Jul 12, 2014 at 3:12 AM, Dmitriy Novakovskiy > <[email protected]> wrote: >>> >>> It is not reported. >> >> >> Done - https://bugs.launchpad.net/fuel/+bug/1341026 >> >> >>> 2) All settings are locked after starting the deployment, it's a one >>> time thing and they must be inside the public network >> >> >> Any plans on changing that? Adding new floating IP pools post-deployment >> is a frequent request from users >> >> --- >> Regards, >> Dmitriy >> >> >> On Sat, Jul 12, 2014 at 3:04 AM, Andrew Woodward <[email protected]> wrote: >>> >>> On Fri, Jul 11, 2014 at 4:54 PM, Dmitriy Novakovskiy >>> <[email protected]> wrote: >>> >> 1) All networks support (multiple) ranges, only public has this shown >>> >> (but they all should have them displayed). This is necessary in the >>> >> event that you have a large network, for example /20 but want to use >>> >> addresses from multiple segments. Alternately your range may be >>> >> partially used in the middle, but you want/need to use the addresses >>> >> around the range. >>> > >>> > >>> > So does it mean that there's a bug and other networks should have >>> > "plus" >>> > button too? Is it reported, or do I need to report one? >>> >>> It is not reported. >>> >>> > >>> >> really the floating network address should be under the public range, >>> >> another >>> >> issue I need to raise. >>> > >>> > >>> > Just to double-check - do you mean "under" on GUI (positioning) or >>> > "under" - >>> > one range is a subset of another :) ? >>> > >>> >>> GUI positioning. Also now that I think about it there is some >>> code/calculating logic that needs to be tweaked too. The current >>> method is to require that the public range is exclusive of the >>> floating range, but this is hard for the user to ensure that they >>> don't intersect. The user shouldn't need to worry too much about this, >>> instead the addresses should just be marked as allocated in the db the >>> same as the vip and management are, that way fuel absolutely avoids >>> provisioning the floating range, but the user doesn't have all kinds >>> of annoying data entry needs. >> >> > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Dmitry Borodaenko -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
