* Sebastian Gebhard <[email protected]> [2013-07-25 09:43:03 +0200]: > Hi dimara > > Am 24.07.13 19:41, schrieb Dimitris Aragiorgis: > >Hello Sebastian, > > > >* Sebastian Gebhard <[email protected]> [2013-07-24 12:53:22 +0000]: > > > >>This design doc adds details about how the autoconfiguration of > >>openvswitch should work in the cluster <-> node group <-> node > >>hierarchy. Parameters that are needed for succesful configration > >>are idenfied and inheritance of parameters is defined. > >> > >>Also, some rephrasing of the definition in the first part of the > >>document. After looking into gnt-network, in my opinion it is not the > >>right place to put the switch management into, since it has more to > >>do with links and nics than with network names and addresses. > >> > >Just some food for though: > > > >gnt-network is currently used to manage IP pool. I have already some > >work in progress to decouple IP pool management from gnt-network and > >make it support abstract networks (simple collision domains, IPv4 networks, > >only IPv6 networks, etc.) The good thing is that you can define a network > >and abstract all infra info from the instance by attaching it to a network. > >The nic will inherit its netparams (currently link, mode) and > >you can have all the network info exported in hooks and configuration > >scripts. > > > >I think that ovs configuration can be a part of gnt-network > >connect/disconnect. By that you can define the underlying infra for > >a whole nodegroup and all instances that will reside in that network > >will inherit its configuration. > > > >Ideally we could have nicparams calculated during instance start up and > >not only instance create and by that one could easyly change the underlying > >ovs setup (via connect/disconnect/tags) and reboot instance/hot-modify NICs > >all instances will inherit the change. > > > >Well I will follow the ovs related threads/patches and if possible share > >some thoughts and ideas about the implementation details. > > > >Hope it helps, > >dimara > > > > > Thanks for your input. You point out some very interesting things. I > gave it a lot of thought. > > I like your ideas of abstracting the network info from the instance > by putting all the nicparams into a network object that is managed > by gnt-network. I see a lot of potential here, since this would > allow easy migration between all the network modes. >
Well the main idea is to completely separate L2 from L3. My goal is to be able to define a new Ganeti network with: # gnt-network add net and make it a collision domain with: # gnt-network connect net bridged br0 (here we must add vlan nicparam as well) And then, only if desired, add L3 characteristics to it: # gnt-network modify --network 1.2.3.4/23 --gateway 1.2.3.4/5 net or an IPv6 subnet: # gnt-network modify --network6 2001:23:35:223::1/64 net Those characteristics will be exported to all NIC configuration scripts/hooks. Moreover, we could let Ganeti decide the IP allocation and add an IP pool to the Ganeti network with: # gnt-network modify --pool 1.2.3.4/23 net (exactly what happens now with --network) > How far is your work in progress? I think it would be a good > solution for me to hop onto your solution and extend it by the stuff > that is needed by openvswitch. > The code that does the abstraction is pretty much ready. On the other hand, the concept of having nicparams not hardcoded in case the NIC belongs to a network and inherit them from netparams during instance startup or modify is not implemented yet, but I will dig into it as soon as hotplug gets merged upstream. Still there should be a new clean design for that, because currently networks with NICs on them are not allowed to be disconnected from the nodegroup. Maybe a new command like: # gnt-network reconnect net <new netparams> must be introduced. But those are just random thoughts. Once I have something concrete I will propose a corresponding design doc. > On the other hand I think, this is only good for the instance > configuration and stuff. The part that I am currently working on is > setting up the openvswitch and connection to the outside. I don't > see how this would make sense in gnt-network, since its basically a > one time thing during setup. Whats your opinion on that? > My point exactly. `gnt-network connect` is done only once when defining the underlying network infra (L2). Having in mind that all nodes under a nodegroup are identical, an L2 network infra is also the same. So you could introduce an new RPC/backend function that will configure ovs on node level and invoke it for every node inside that nodegroup (just like Ganeti does now with bridges). I think it suits perfectly. Well these are my current thoughts about ovs and networking support in Ganeti. Let's see what everybody else says about it. Thanks for digging into it, dimara
signature.asc
Description: Digital signature
