>>>>> "Brandon" == Brandon S Allbery KF8NH <[EMAIL PROTECTED]> writes:
Brandon> On Nov 2, 2006, at 20:54 , Timothy S. Nelson wrote: > I think NLD is saying that the machine can automatically sign >> off when it knows the upgrade is good to go. Brandon> Well, it knows when the machine has integrated the change. Brandon> It does *not* necessarily know if everything is functioning Brandon> correctly afterward. So, do you need to tie Nagios into Brandon> this as well? What kinds of failures then trigger no-go on Brandon> a given change?) Like I said in the mail to Andrew, I think that this is another important input to the process. (We don't have this one yet) I think that it is important though. Brandon> It also doesn't deal with the problem of an unforeseen / Brandon> emergency change needing to be inserted into the sequence Brandon> (see Paul's discussion about branching etc.). Narayan's Brandon> proposal assumes that the changes are already committed and Brandon> are sequenced out to clients in order as they become ready; Brandon> this makes inserting other necessary changes problematic, Brandon> especially if they require alteration of later steps. My Brandon> proposal keeps the sequencing separate from the Brandon> effectively-inalterable committed changes, and while it Brandon> doesn't necessarily catch collisions (certainly it could Brandon> catch failed "patch" runs, but semantic conflicts are Brandon> harder and in some cases may well require actual deployment Brandon> to test machines) it would make it easier to handle them. Depending on the details, resequencing can be pretty easy. It would likely be simpler with a completely distributed scm system, than with svn. I think this could probably be scripted up. There are two general use cases where. You need to orchestrate something, and you don't care when it happens, as long as it happens in the right order. The other case is where it is a big hairy change and is a pain in the butt to get right. These are opposite ends of the spectrum, and probably require different levels of care and supervision. In general, we try to expose enough data from bcfg2 that you can make the correct procedural decisions for your environment, and then automate those... -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
