Peter Memishian wrote: > > I went through the suggested fix in the bug report, and generally that > > was the approach I had been considering as well. In addition to making > > this private (we can quibble about naming later), I'd also do an > > explicit check to see if we're operating without SVCCFG_REPOSITORY set, > > and fail plus issue a message saying that svcadm refresh is the droid > > you're looking for. > > thanks for the feedback Liane! i've made changes along those lines, let me know if they're what you had in mind
http://cr.opensolaris.org/~amaguire/svccfg_refresh/ > > > (I think that's the correct mechanism for avoiding the weird situation > > where the running service has been refreshed, but the restarter and the > > service itself hasn't yet been notified -- but I'm open to other > > suggestions too.) > > > > That can all wait, though, until it's been confirmed that this does > > actually solve both problems. > > It's confirmed: it solves both problems (!) > > So, now the logistics: do we think we can find a way to get this ARC'd and > putback in build 82 (which just opened today)? (UV is currently targeting > the start of build 83.) > > i'd be happy to drive this but would need someone with sponsorship privileges to sponsor the fasttrack. assuming a reasonably short timer, i think snv_82 is doable. in terms of other things to be done i suspect we'd like to add a few test cases to the SMF test suite to cover this option too? and i guess we'll need to settle on a name. if "refresh" is too loaded, what about "rotatesnap"/"refreshsnap", or something along those lines that is more explicit about the fact that we're messing with snapshots (and not additionally running methods, as the "real" refresh does)? thanks! alan
