On Thu, Jan 21, 2016 at 4:26 PM, Klaus Aehlig <[email protected]> wrote:
> > If we have a KVM cluster and user shutdown detection is off, then we > still > > want to ensure that ganeti-kvmd is off. > > Correct. The point I was trying to make is that in this case you still try > to stop the daemon on node addition and most like get the same warning > (as on a new node to be added they're likely not running). > > > What I had in mind is to make sure that 'enabled_hypervisors' acts as a > > master switch - if it's off, KVM related code shouldn't be even > > invoked (unless we just turned that switch off and want the cluster > > react accordingly - but that is handled in LUClusterSetParams using > > the 'ensure_kvmd' flag). > > However, this is not what you're patch is achieving. EnsureKvmdOnNodes > is called at a couple of places on non-KVM clusters, e.g., > - at cluster init, and > - whenever the set of enabled hypervisors changes, regardless of > whether kvm is in the old or the new set > Yes, but in these cases the calls are justified and conditional (it is executed only if we know we need to potentially switch the state of kvmd). > So, that's why my suggestion was, to keep things basically as they are; > this > has the advantage that all the decissions on whether and what to do with > kvm > is in one central place of the code. If we worry about spurious warnings, > we > can tell EnsureKvmdOnNodes "don't worry, from the context we're in, we > don't > really expect the daemon to be running anyway; but silently try to stop, > just > to be sure". These situations basically are > - node addition (irrespectively of whether kvm is enabled or not), > - parameter changes where kvm is enabled neither before nor after the > change. I think the difference here is, that my approach was to do a "no-op if we know for sure that there is no need to change the state of kvmd" . Your suggestion is rather "make a silent try, just to be sure". > What do you think of this suggestion? > I generally like more when we do operations only in states when we know they are needed. But I guess you are talking from experience and the "silent try just to be sure" approach might be good for recovering from inconsistent states (e.g. kvmd is running while kvm is disabled and we do a node addition/node parameter change). > Regards, > Klaus > > -- > Klaus Aehlig > Google Germany GmbH, Dienerstr. 12, 80331 Muenchen > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle >
