feat(cephfs): implementation of mkdirs

[maitredede]

Hello, this PR adds "ceph_mkdirs" implementation (to create path+subpath at once).

Signed-off-by: Damien DALY maitredede@gmail.com

Checklist

• [✓] Added tests for features and functional changes
• [✓] Public functions and types are documented
• [✓] Standard formatting is applied to Go code
• [✓] Is this a new API? Added a new file that begins with //go:build ceph_preview
• [✓] Ran make api-update to record new APIs

[anoopcs9]

Checklist

* [ ]  Added tests for features and functional changes

* [ ]  Public functions and types are documented

* [ ]  Standard formatting is applied to Go code

* [ ]  Is this a new API? Added a new file that begins with `//go:build ceph_preview`

* [ ]  Ran `make api-update` to record new APIs

New or infrequent contributors may want to review the go-ceph Developer's Guide including the section on how we track API Status and the API Stability Plan.

The go-ceph project uses mergify. View the mergify command guide for information on how to interact with mergify. Add a comment with @Mergifyio rebase to rebase your PR when github indicates that the PR is out of date with the base branch.

@maitredede Please go through the above checklist and make sure that every requirement is met.

[anoopcs9]

I see some unrelated changes in the pull request. Please make sure that you only touch the relevant API sections.

[maitredede]

Hi @anoopcs9 , thanks for your time 😄

I have gone through all checks, but I don't know if I did well with make api-update (it raised an error, I tried to fix).

I have also used make test-docker. Is there something I have missed ?

[phlogistonjohn]

Hi there, thank you very much for the contribution!

Without speaking for @anoopcs9 I think he might have meant to make use of the checkbox feature on github and tick off the boxes so that we know you followed each guideline.

For example, I can see that you added a test so it'd be good to tick off that item. Same for documenting the function. One item that's not quite right is the API policy - even though this is a small api and probably an uncontroversial implementation we expect the new api to be added in it's own file and then the go build tag ceph_preview applied (take a look at the linked documentation up in the PR template for more info). If you do this make api-update will record your new API as a preview API in the json & markdown files.

Additionally, we'd prefer if you squashed the patches in the PR into one commit. That way the intermediate changes, like cleaning up the indents in the doc comments, disappear from commit history. Finally, we use a commit message style closer to that of the ceph project or the linux kernel. Just use a subsystem name like cephfs: as the commit topic (prefix) not feat(...).

[maitredede]

Hello @phlogistonjohn,

Thanks for your reply. I have followed your instructions and updated my first post accordingly.

[anoopcs9]

Without speaking for @anoopcs9 I think he might have meant to make use of the checkbox feature on github and tick off the boxes so that we know you followed each guideline.

Thank you John, that's exactly what I wanted.

@maitredede Thanks for making the required changes. Can you also avoid using the preview suffix from the source file name? makedirs itself holds good. Preview nature of the API is already indicated using the build tags inside which will get removed once it reaches the expected stable version in future.

[maitredede]

Can you also avoid using the preview suffix from the source file name?

Yes, of course, I missed this one 😅

[anoopcs9]

All good.

See below for 2 minor comments.

[anoopcs9]

Unnecessary empty new line?

[phlogistonjohn]

Agreed. Please remove this.

[anoopcs9]

@maitredede Can you also add Signed-off-by: in the commit message? Forgot to comment earlier.

[phlogistonjohn]

Please fix the extra whitespace in the doc comment and add a signed off by line as @anoopcs9 suggested. After that I think we'll be good.

[phlogistonjohn]

Agreed. Please remove this.

[maitredede]

Please fix the extra whitespace in the doc comment and add a signed off by line as @anoopcs9 suggested. After that I think we'll be good.

Hello :) The whitespace seams to be added by a code formatting tool (I don't know if it is the gofmt used by vscode extension), I will try to double check for my next PRs. The "signed off by" line has been added to my first message. Is is ok ?

[phlogistonjohn]

Please fix the extra whitespace in the doc comment and add a signed off by line as @anoopcs9 suggested. After that I think we'll be good.

Hello :) The whitespace seams to be added by a code formatting tool (I don't know if it is the gofmt used by vscode extension), I will try to double check for my next PRs. The "signed off by" line has been added to my first message. Is is ok ?

It looks like you pasted it in the PR description. It belongs in the commit message. Try running git commit --am -s it should update the commit message to contain the Signed-off-by line based on your local git user settings.

[maitredede]

It looks like you pasted it in the PR description. It belongs in the commit message. Try running git commit --am -s it should update the commit message to contain the Signed-off-by line based on your local git user settings.

Thanks for you help :)

[phlogistonjohn]

LGTM. Thank you for working with us to get everything meeting the process!

[anoopcs9]

Thank you.