Dan, your arguments conviced me, changing my vote to "request" only.
--- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014/1/9 Antoni Segura Puimedon <[email protected]> > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Miguel Angel" <[email protected]> > > Cc: [email protected], [email protected], [email protected] > > 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 <[email protected]> > > > > > > > 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 > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > >
_______________________________________________ vdsm-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
