DNM: adding rmfs etc (wip-nullfs) #1852
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
If we are adding newfs and rmfs, I wonder if this is the time to add a 'name' argument so that we don't have to shoehorn it in later. Even if we just enforce that it is always 'default' or something for the time being... |
|
First patches look good! Generally speaking, as long as we can see a path toward creating multiple named fs instances in the cluster, I think we're good. Don't strictly need to do that now, but when we do let's set things up so the user-facing UI doesn't change, if we can! |
|
Hmm, newfs + rmfs makes me realize we also need lsfs, and that the naming is silly. What about something like: ceph fs new This diverges from the current ceph mds * command namespace, but it is crufty anyway, and arguably creating instances of file systems is a top level thing. New and rm would be idempotent, and for now new will fail if there is already an existing fs. We can do this in a later pull request too, we don't really need to hold up the no default fs thing forever bikeshedding... |
Signed-off-by: John Spray <john.spray@inktank.com>
When 'enabled' is false, the MDSMap is effectively null. This allows Ceph clusters with no filesystem or filesystem data/metadata pools. Signed-off-by: John Spray <john.spray@inktank.com>
Because not everyone uses CephFS, we would like to avoid initially creating any data/metadata pools for CephFS. To avoid creating those pools, we must avoid initially populating the MDSMap. Signed-off-by: John Spray <john.spray@inktank.com>
Because many Ceph users don't use the filesystem, don't create the 'data' and 'metadata' pools by default -- they will be created by newfs if they are needed. Signed-off-by: John Spray <john.spray@inktank.com>
Only prompt for --yes-i-really-mean-it if there is an existing FS. Signed-off-by: John Spray <john.spray@inktank.com>
Previously we trusted user implicitly: now check input against OSDMap to validate that the pools really exist. Signed-off-by: John Spray <john.spray@inktank.com>
This is the setting we would apply to data pools created automatically, so notify the user if they're failing to use it for data pools they have created by hand. Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@inktank.com>
Where 'stopped' means ignoring beacons and not performing 'tick' activities. Signed-off-by: John Spray <john.spray@inktank.com>
Sets enabled=false on the mds map so that an administrator can remove the filesystem pools if he wishes. Signed-off-by: John Spray <john.spray@inktank.com>
MDS commands are now divided into two handler functions, one for create/remove of the filesystem, and one for operations on the filesystem itself. Signed-off-by: John Spray <john.spray@inktank.com>
This avoids the need to do anything clever about kicking out MDS daemons during a rmfs: we push that responsibility onto the admin to run 'mds stop' or somestuch first. Signed-off-by: John Spray <john.spray@inktank.com>
newfs and rmfs commands now refer to the filesystem by name, so that in future these commands can support a multi-filesystem model. rmfs when no filesystem exists is now a warning rather than an error. Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@inktank.com>
Tests for osdmaptool previously assumed that --createsimple would always result in at least 3 pools. Signed-off-by: John Spray <john.spray@inktank.com>
Previously we checked if the MDS map had ever been updated (epoch > 1), now we have an explicit flag for whether it's enabled. Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@inktank.com>
Previously assumed that a pool with ID 2 existed in the default OSD map. Signed-off-by: John Spray <john.spray@inktank.com>
Signed-off-by: John Spray <john.spray@redhat.com>
Signed-off-by: John Spray <john.spray@redhat.com>
& also catch some more tests that were assuming a 'data' pool existed. Signed-off-by: John Spray <john.spray@redhat.com>
Signed-off-by: John Spray <john.spray@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.