2024-10-07T08:17:31.646Z

<Igor Golikov> Happy Monday folks! What is considered Done when you work on bug/feature? Do we have clear definition of done (unit tests, github tests, shaman builds etc)?

2024-10-07T12:27:52.589Z

<Patrick Donnelly> tests/docs/basic validation in qa (that the tests/feature work)

2024-10-07T12:28:08.753Z

<Patrick Donnelly> maybe a PendingReleaseNote addition

2024-10-07T12:53:50.989Z

<Venky Shankar> @Igor Golikov
```./virtualenv/bin/teuthology-suite --machine-type smithi --email [vshankar@redhat.com](mailto:vshankar@redhat.com) -p 100 --suite fs -k testing --force-priority --subset $((RANDOM % 1024))/1024 -c wip-vshankar-testing-20241004.070739-debug```

2024-10-07T13:39:04.977Z

<Igor Golikov> Is it possible to run teuthology on SHA that has not been built by Shaman? Is it capable of building the code before testing so any SHA can be used?

2024-10-07T14:42:35.284Z

<gregsfortytwo> @Igor Golikov are you looking for when to submit a PR, or the sub-tasks that @Christopher Hoffman has for the fscrypt branch? Most tickets aren’t “done”; they’re “In Progress” or “Fix Under Review” or “Pending Backport”, which mean what they say on the tin… 😉

2024-10-07T14:43:04.523Z

<gregsfortytwo> For Chris’ stuff you can ask him, but I’d expect it to be a slightly-less formal version of the same, with “passes relevant test in the branch” as the “completed” standard?

2024-10-07T14:58:34.920Z

<Venky Shankar> `--subset` does the magic here btw.

2024-10-07T17:15:36.816Z

<Igor Golikov> Got it, make sense for me

2024-10-07T17:24:33.566Z

<Igor Golikov> Ahh now I see the ceph-object-corps issues. I guess this is a bunch of serialized objects, for backward compatibility testing. So now when I changed the MClientReply message, the unit test (I run all unit tests by the book) fails while deserializing this message from the corpus.... I found this page <https://docs.ceph.com/en/reef/dev/corpus/?highlight=corpus> and I understand that its normal not to decode old objects. In general, I assume that all cluster nodes must run the same Ceph version?

2024-10-07T17:26:09.846Z

<Igor Golikov> Got it, make sense for me for PR.

2024-10-07T17:28:10.945Z

<gregsfortytwo> We have a pretty sophisticated but not super-well documented versioning system. (And different parts of the codebase are more modern than others.)
MClientReply is client-facing so needs to be forwards- and backwards-compatible. Check out the ENCODE_START macro and struct_v (or maybe for Messages it’s just version? Afk right now) usage; there should be clear examples in the git history for that file

2024-10-07T17:33:34.386Z

<Igor Golikov> 👍

2024-10-07T22:22:39.457Z

<Christopher Hoffman> @Igor Golikov As the wip-fscrypt work is separate from upstream ceph still, we'll have to get it added to my wip-fscrypt branch. You can create a PR to merge with the working branch. I'll be looking for tests to be included, where applicable, and a subtask to be included within the main libcephfs fscrypt tracker.

2024-10-07T23:59:55.915Z

<gregsfortytwo> @Patrick Donnelly every protocol bug manifests as a cap delay issue; how common do you think your recent fix is likely to be? Saw another one at [https://www.reddit.com/r/ceph/s/dn5HMwh4rL](https://www.reddit.com/r/ceph/s/dn5HMwh4rL) and wonder if that’s the relevant kernel for the nets issue