James Carlson wrote: > Liane Praza writes: >> James Carlson wrote: >>> If the definition of the "svccfg refresh" user interface provides all >>> the needed functionality needed for a generic SMF "refresh" operation, >>> and it seems it does, then is it possible to work towards making >>> "svcadm refresh" obsolete? >> It's possible, but I'm not sure it's desirable. >> >> It seems frustrating to have "svcadm restart" and then have to remember >> that "refresh", which is often a (mentally) related operation to >> "restart" is done using a different command, with a significantly >> different syntax. > > ... and a bit worse that "refresh" and "restart" are separate, with > related ordinary word meanings, and I suspect most mortals are unable > to recall which is which. But that's a bit beside the point. > >> It'd also need to stay around for compatibility's >> sake, so wouldn't buy us much more than a stern warning in the svcadm >> manpage that the subcommand could go away in the future. I'm not sure >> that warning would lead to more customer satisfaction. > > The ultimate goal would be to provide a cleaner functional separation, > so that all parameter-related things end up in svccfg (including > 'refresh' snapshot manipulation), and that operational state bits end > up in svcadm ... assuming a far-future removal of "svcadm refresh."
But there's often a refresh method too, which makes it operational as well for a running system. I'm not convinced this would make a cleaner functional separation -- just a different one, while obsoleting the one many have become familiar with. Refresh often works for non-SMF configuration as well, which means that we'd be introducing a requirement to interact with svccfg for a common set of services which have no such operational requirement today. >> If you're generally concerned about the usabilty of the *adm/*cfg >> command split, I'd think a piecemeal approach to trying to change it >> would be more likely to make things worse rather than better in terms of >> confusion. > > A piecemeal approach to usability was not quite what I was suggesting. > It seems that the project rightly recognizes that 'refresh' is more > related to parameter configuration than to service state, but that it > doesn't go the whole way there. > > It seems you disagree, though, and I don't really have strong feelings > on it, so I'll fold. :-/ I'm not convinced that the choice to obsolete svcadm refresh is obvious, thus my bias would be to preserve existing, well-known interface. If anyone thinks that a few more days of discussion will help clarify we can convert to a fasttrack, but I admit I suspect this is a personal preference type of discussion. If it's clear it's a more natural administrative model, we'll see advice on public mailing lists and in documentation move rapidly away from svcadm refresh, and I'll be happy to file the obsolescence case if that happens. I'm always happy to obsolete things people don't use. :) liane
