[LU-2667] move NRS structures/definitions from lustre_net.h to new lustre_nrs.h header

• Type: Technical task
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.8.0
• Affects Version/s: Lustre 2.4.0
• Labels: patch
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

This ticket is for tracking the cleanup of the NRS structures from the lustre_net.h header into a separate header lustre_nrs.h. There are quite a number of NRS-specific structures that are not generally useful in the rest of the RPC code, and would be better in a separate header.

It might also make sense to have separate policy-specific private headers instead of putting them into lustre_nrs.h. This avoids inter-connecting the policies unnecessarily, and also ensures that the headers are properly structured to allow use by future NRS policies more easily.

Comments

[Andreas Dilger]

Patch landed to master for 2.8.0.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/13966/
Subject: LU-2667 ptlrpc: Move NRS structures out of lustre_net.h
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d867368cdfa1138909a64d13ab11ed3c0212a0b2

[Gerrit Updater]

Chris Horn ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13966
Subject: LU-2667 ptlrpc: Move NRS structures out of lustre_net.h
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 535e33b36784637dd1cb321f54dac53b147ea6ac

[Nikitas Angelinas]

I agree that that is a fair stance, and to the benefit of the project Andreas; thanks for putting that forward. We are looking at ways to address this work, I will come back soon with an update.

[Andreas Dilger]

Nikitas, I appreciate that you are busy (as we all are). However, if there is technical debt in patches that is not being addressed promptly after the patch is landed, then it makes it much more difficult for us to accept patches in the future under similar circumstances.

I prefer to be flexible when there are some minor issues with a patch, and fix the non-critical problems afterward, but we already got flak from other parties about accepting NRS policies after the feature freeze, so in the future we may be forced to deny patches from landing until all of the issues are addressed, if we aren't confident that the remaining issues will be addressed promptly. It seems that management doesn't understand that fixing technical debt is an important part of the development process, so blocking the whole feature from landing would keep their focus on fixing remaining issues in order to get the patch landed rather than dragging you off to work on something else. Hopefully you can convince your management that fixing these issues is not optional, and we aren't forced into an inflexible patch acceptance policy.

[Nikitas Angelinas]

Hi Andreas, i'd like to start writing and submitting some NRS patches again, but i have been assigned to a high-priority task in my employer's roadmap, which leaves we with little time to do much else atm unfortunately; depending on how things go, i'll do my best to put some work towards NRS (i need to at least start with addressing LU-3430 fairly soon).

[Andreas Dilger]

Hi Nikitas, now that master is open again for landings, it would be great to see your patches to clean up the NRS code.

[Nikitas Angelinas]

Thanks Andreas, as discussed in the Gerrit change, I will address the requirements in this ticket once more urgent coding tasks are completed.

[Andreas Dilger]

Nikitas, it seems I'm not able to assign this ticket to you, but I filed it to track the cleanup discussed in the NRS base patch.