Ceph » CephFS

So this would be something like adding `CEPHFS_FEATURE_DUMMY` to `include/ceph_features.h`, then post MDS upgrade have a py test case that tests client eviction due to unsupported feature bit?

BTW we do have this [0] which is run as part of [1] so we can run this after the MDS upgrade (with some minor tweaks maybe)?

[0] https://github.com/ceph/ceph/blob/c2b21dbf694c4f91009603c94a8c46abd941d99b/src/test/client/ops.cc#L24-L32
[1] https://github.com/ceph/ceph/blob/main/qa/workunits/client/test.sh

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

(and that is not relevant?) I'll have to run through the PR to understand how it works, instead if it is addressed in the PR itself it not only would save time but also mean the dependency(since it brings in the functionality) is not a blocker.

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

I've a bit of different opinion - I'll have to run through the PR to understand how it works just to make use of it in a test case (if you feel this PR would be beneficial for me to go through, i'd be happy to do so). It would also not make us wait for the PR to be merged because test case is clearly dependent on it and on top of it I do see qa test case already added to the PR so adding one more would only strengthen the trust on code. What do you think, do let me know.

Dhairya Parmar wrote in #note-8:

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

(and that is not relevant?) I'll have to run through the PR to understand how it works, instead if it is addressed in the PR itself it not only would save time but also mean the dependency(since it brings in the functionality) is not a blocker.

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

Venky Shankar wrote in #note-7:

Dhairya Parmar wrote in #note-6:

Venky Shankar wrote in #note-5:

Dhairya Parmar wrote in #note-4:

@Venky Shankar @patrick can you update this tracker with the discussion you guys had on the call post standup on tuesday? My understanding is a bit unclear (I can only recall some bits and pieces and didn't really get about the admin socket thing that was being discussed).

https://github.com/ceph/ceph/pull/57192 introduces functionality to update client features via config option. This is useful to make a client behave as if it's running a particular ceph client version (since client features would reflect what features it supports). With this in place, the relevant upgrade sub-suite can be changed to use recent supported ceph versions rather than using old (octopus) release that's sticking around since it had missing features which were required to test client eviction due to missing features.

this tracker can be then addressed in the same PR itself since this completely depends on it.

IMO the dummy feature bit introduction and the relevant tests are not really related to https://github.com/ceph/ceph/pull/57192. That change brings in functionality to allow updating client feature bits which can be used to write upgrade tests.

I've a bit of different opinion - I'll have to run through the PR to understand how it works just to make use of it in a test case (if you feel this PR would be beneficial for me to go through, i'd be happy to do so). It would also not make us wait for the PR to be merged because test case is clearly dependent on it and on top of it I do see qa test case already added to the PR so adding one more would only strengthen the trust on code. What do you think, do let me know.

https://github.com/ceph/ceph/pull/57192 fixes a root_squash bug. How would adding test case to test upgrades for recent releases (even if those tests use the functionality to update client features) be relevant to the PR?