-
Notifications
You must be signed in to change notification settings - Fork 502
Developers
This is where to go for developer information. Learn how to build, test, and contribute to the project here.
The development cycle and its policies are found in Development Policies.
We use common git practices for our development. We also take advantage of Github and Gerrithub web based tools to ease our process.
This is an active project and we are feeling the growing pains of an expanding developer community. The server is also being embedded in commercial products. As a result, our process is becoming more formal.
- The submitter writes some new code or fix some old code...
- Submit the patch to gerrithub (see src/CONTRIBUTING_HOWTO.txt)
- The release manager (Frank Filz) and/or the subsystem maintainer(s) and/or other community members review the change.
- subsystem maintainers and other community members may give a +1 review
- The release manager will give a +2 review to indicate the patch has been accepted for merging
- The reviewers work with the submitter to get a correct and appropriate change.
- The release manager pulls the accumulated changes and merges an update to the source tree.
- The release manager pushes periodic updates to the next branch in the repository on Github.
- Every update push has a named, annotated tag which contains a comment describing the total merge.
- Both the branch and tag are pushed to the repository.
- An announcement containing the short log and annotation comment along with more detailed comments (as appropriate) is sent to the devel@lists.nfs-ganesha.org Mailing List
- Rinse and Repeat.
The nfs-ganesha project titles the overall maintainer as release manager. The current release manager is Frank Filz (ffilzlnx at mindspring.com). In part, this title came about when the project was growing larger than Deniel Philippe's capacity to manage it, but we didn't want to usurp his position, so the title became release manager rather than maintainer.
Past release managers are: Jim Lieb (first to hold the title of release manager). Deniel Philippe (originator of the project)
These people are experts in the various nfs-ganesha subsystems.
The following table is the current list of subsystem maintainers. These folks were picked because they have contributed to the project the most in these particular areas. Their review and suggestions are important.
| Subsystem | Maintainer | |
|---|---|---|
| MDCACHE | Daniel Gryniewicz or Frank Filz | dang1 at ibm.com or ffilzlnx at mindspring.com |
| CEPH FSAL | Frank Filz | ffilzlnx at mindspring.com |
| DRC/TIRPC | Daniel Gryniewicz or Matt Benjamin | dang at redhat.com or mbenjamin at redhat.com |
| RGW FSAL | Matt Benjamin | mbenjami at ibm.com |
| SAL/locks | Frank Filz | ffilzlnx at mindspring.com |
| VFS FSAL | Frank Filz | ffilzlnx at mindspring.com |
Note that this is not exhaustive but highlights some of the major areas of contribution that have current acknowledged experts.
The people in this table have been chosen based on their past contributions in those particular areas. It is not a closed list. We also and always need reviewers and backup maintainers. Volunteers are encouraged.
Everything developer that does not fit a category all its own ends up here...
A weekly phone conference takes place every Tuesday at 7:00 AM Pacific Local time (15:00 UTC during the summer, 16:00 UTC during the winter).
Here are the call in details:
- Ganesha community call
- Tuesday, November 7 · 7:00 – 8:00am
- Time zone: America/Los_Angeles
- Google Meet joining info
- Video call link: https://meet.google.com/mkh-ctnj-tqz
- Or dial: (US) +1 401-702-0462 PIN: 495 972 631#
- More phone numbers: https://tel.meet/mkh-ctnj-tqz?pin=2844708468265
- Or join via SIP: sip:2844708468265@gmeet.redhat.com
tests, criteria, results, etc.
Using LTTng with Ganesha is fairly straight forward. First, build with LTTng enabled by adding this to your cmake:
-DUSE_LTTNG=ON
Next, you need to set up LTTng before running Ganesha. LTTng aggregates tracepoints via a channel into a session. For Ganesha, we only need a single channel within the session. Set it up like this:
lttng create <sessionname> lttng enable-channel -u --session=<sessionname> --subbuf=size="128k" channel0
Optionally, if you want trace lines to include thread IDs, you can have LTTng add them:
lttng add-context -u -t pthread_id -v vtid
Next, you need to enable events from Ganesha. If no events are specifically enabled, then all events are enabled, so you only need this if you want a sub-set of events. In Ganesha, all logging is converted to events, so having logging on can send a lot of events. Events themselves are in src/include/gsh_lttng/* or in src/libntirpc/ntirpc/lttng/*. Events are in the form "provider:event", with * as a wildcard. So, "*:*" enables all events, "mdcache:*" enables all mdcache events, and "mdcache:mdc_lru_ref" enables the single event.
lttng enable-event --channel=channel0 -u mdcache:mdc_lru_ref lttng enable-event --channel=channel0 -u mdcache:mdc_lru_unref
Finally, you need to start lttng
lttng start
Next, run Ganesha like normal, preloading the Ganesha LTTng library:
LD_PRELOAD=/path/to/libganesha_trace.so:/path/to/libntirpc_tracepoints.so ganesha.nfsd
Do your workload. When it's done, stop Ganesha. The results of tracing are in binary format in ~/lttng-traces and are processed into text with babeltrace:
babeltrace ~/lttng-traces/<sessionname>-<timestamp> > trace.log
You can then look at trace.log with whatever tool you want.