----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Miguel Angel" <miguelan...@ajo.es> > Cc: dsull...@redhat.com, arch@ovirt.org, vdsm-de...@fedorahosted.org > Sent: Thursday, January 9, 2014 2:35:40 AM > Subject: Re: [vdsm] Smarter network_setup hooks > > On Wed, Jan 08, 2014 at 03:34:24PM +0100, Miguel Angel wrote: > > Hi Assaf, Thank you very much for the summary, > > > > Just a few questions, there are things I don't understand yet: > > > > 2014/1/8 Assaf Muller <amul...@redhat.com> > > > > > Mid-thread summary: > > > > > > First some terminology so we're all on the same page: > > > 'request' - The setupNetworks that just arrived > > > 'running config' - If unified persistence is being used - All networking > > > on the host as VDSM sees it > > > 'expected' - If unified persistence is being used - The running config > > > after the effects of the request, but before the hook is ran > > > > > > > > correct > > > > > > > I think we all agree that we have to expose the 'request' to the hook. > > > However, there's two different approaches: > > > 1) Allow the hook to rewrite parts of the request (For example, if two > > > networks were sent, and the hook handled one of them, it could > > > then delete that network from the request, so VDSM will only continue > > > to configure the 2nd network). > > > > > > > In this case ,if the hook deleted the "2nd network", VDSM couldn't handle > > the network config persistence anymore, right?, > > Right. If the before_network_setup hook decides to drop an item from the > 'request', it means that neither following hooks, nor Vdsm proper, would > see it. I find it as a useful and simple sematics: the hook practically > says "I'm taking it from here", and from then on, it is repsonsible for > everything. Implementation and persistence alike. > > > > > I didn't expect this use case, I only expected tweaks, etc (before or after > > network setup), for example, setting special hardware > > capabilities using ethtool or those kind of things. > > Neither have I expected this. But it's a powerful tool that's relatively > easy to implement. > > > > > > 2) Toni's idea with marking devices as hook-configured. So if a network > > > is > > > over a bridge over a VLAN over a bond over three NICs, hooks > > > could configure only the NICs (For example) and VDSM would configure > > > the rest, whereas the first idea means that the hook would > > > have to configure the entire network (Bridge, VLANs, bonds, and all 3 > > > NICs) and then remove that network from the request. > > > The disadvantage of this method is that it would be harder to > > > implement, and have references to the hooks flag throughout all of VDSM. > > > > > > > > You mean that if the hook marked a certain device as "hook handled" then, > > VDSM would just keep this information along with > > the network config, etc... and won't do any setup, just config-keeping, > > right? > > That's my understanding, too. And I share the feeling that this is error > prone: Vdsm sees the config, but must remember that it should not touch > it or act upon it. > > > > Then there's the matter of IF to expose the 'running config' and > > > 'expected'. > > > > > > My main argument is that it's very easy to expose to the hooks (But then > > > why not expose other 'random' data that is easy for VDSM to calculate?), > > > and that we don't understand all usages for the setupNetworks hooks. I'd > > > rather we expose too much information than not enough and screw > > > over hook writers. > > > > > > > > We have something important here, the hooks don't need to be > > python-written, they could be bash scripts, or any other thing... > > that means that they wouldn't have access to get "running config", but they > > could calculate "expected". > > > > So, my vote here goes for "request" + "running config". > > > > The "running config" is accessible to any process, albeit not in its > Vdsm representation. All the information is available if you do `ip a` > and `virsh net-list`. > > I do not imagine why a hook would need the "running config"; If it does > end up needing it, it could re-calculate it just as Vdsm does. Passing > this as argument to each hook script is a premature optimization imho. > > If I end up wrong, it would not be hard to add the "running config" to > the Vdsm/hook API. Removing something from an API is a much harder > task. > > My vote goes to only "request".
Only "request" for me too. > > > > > > Either way, let's get some votes in a timely manner so we could manage to > > > implement this for 3.4. > > > > > > > > Thanks Assaf! ;) > _______________________________________________ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch