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
