For now, since the original change to use global config on the client is causing some problem, I reverted the commit. See rev 3939. We can put it back in once we get this sorted out. -- John On Wed, Nov 11, 2009 at 9:45 AM, Scott Zawalski <scottz@xxxxxxxxxx> wrote: > On Wed, Nov 11, 2009 at 09:37, John Admanski <jadmanski@xxxxxxxxxx> wrote: >> On Wed, Nov 11, 2009 at 9:35 AM, Martin Bligh <mbligh@xxxxxxxxxx> wrote: >>>> I thought about it a bit more: >>>> >>>> Maybe a better approach would be to have the global_config module find >>>> the ini file in job.autodir (so on a client it would show up in the >>>> client/ dir, and on the server in the "true" top-level dir) and then >>>> add support to Autotest.run so that it copies over the server's copy >>>> of the config to the client before launching a client job? >>>> >>>> So that way it would "just work", and changes to the server config >>>> would automatically get pushed out to client jobs. All without moving >>>> the file that users running a server need to edit. And it's not too >>>> complex of a design; the Autotest.run code already needs to copy over >>>> a few files by hand like control files so copying over the config too >>>> isn't too much of a burden. >>> >>> Sounds good to me. > > I like this approach also. The only real gotcha I can see (That may > not really be one) is if someone puts a global_config.ini with other > values in their client directory that is then bundled in the client > tarball. Ultimately it would be overwritten but putting something like > a warn in the section that transfers over the global_config.ini should > be enough to hint at that. > >>> >>>> The only concern I have is that this still might not play well with a >>>> multi-server setup. If the servers have different configs I'm not sure >>>> that it works all that well (although I still don't know that this >>>> introduces any "new" problems, so I don't think it makes things any >>>> messier in that case then they already are). I cc'ed Scott and Steve >>>> in case they can comment on that. >>> >>> By multi-server setup, do you mean multiple copies of the autotest >>> server code on the same tree? Or a master with drones? >>> >> >> I meant a master with drones. But I don't think it's a huge issue; >> keeping the config in sync between all drones is already a >> pre-existing issue, so however we already deal with that (or maybe we >> don't, I can't remember) is independent of this suggested change, in >> my mind. > > Right. However, it is still good to consider but the task ultimately > falls on the person setting up the servers. We don't do this well > internally yet but puppet is eventually planned to take care of that > for us so we basically push the config to one location that then > propagates to all parties involved. We should definitely mention this > in our documentation but my guess is that our multiserver setup is > less than documented. That is something to put on ye old documentation > TODO list. > > > >> >> -- John >> _______________________________________________ >> Autotest mailing list >> Autotest@xxxxxxxxxxxxxxx >> http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >> > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
