MDSMonitor: avoid health checks on new file system

[batrick]

Fixes: http://tracker.ceph.com/issues/23885

Signed-off-by: Patrick Donnelly pdonnell@redhat.com

[batrick]

I'm not really a fan of this solution but it works. @jcsp, any better ideas?

[jcsp]

For the case where the user creates MDSs first and then the filesystem, we could perhaps do a tick() after creating the FS in pending_fsmap (but before committing it) so that it has daemons assigned to it from the beginning? That way no need to explicitly give anything a pass on the health checks.

In the case where they create a filesystem before creating any MDSs, I think the current behaviour is OK -- the health warning acts as a cue to new users that "fs new" on its own is not sufficient to have a working filesystem.

[batrick]

For the case where the user creates MDSs first and then the filesystem, we could perhaps do a tick() after creating the FS in pending_fsmap (but before committing it) so that it has daemons assigned to it from the beginning? That way no need to explicitly give anything a pass on the health checks.

I tried that but the mon froze due to proposal request logic I think. I've tried a different approach which almost works. See the commit message.

[batrick]

Adding a sleep before creating the fs in vstart.sh works. I think this is done. @jcsp what do you think?

[batrick]

retest this please

[jcsp]

Does it work to just call "maybe_promote_standby(fs)" here? I see that calling tick() was problematic because it does a propose_pending(), but maybe_promote_standby in isolation should be alright

[batrick]

We would actually use maybe_resize_cluster because there are no ranks in. I didn't want to use that becuase it needs to check the current epoch FSMap to see if a rank has become active:

ceph/src/mon/MDSMonitor.cc

Lines 1754 to 1762 in eb5ca24

	/* Check that both the current epoch mds_map is resizeable as well as the
	* current batch of changes in pending. This is important if an MDS is
	* becoming active in the next epoch.
	*/
	if (!fsmap_mds_map.is_resizeable() ||
	!pending_mds_map.is_resizeable()) {
	dout(5) << __func__ << " mds_map is not currently resizeable" << dendl;
	return false;
	}

maybe_resize_cluster could be restructured to work but I'm not sure it's worth it.