Ramana, With the ceph-mgr volumes plugin becoming the official means to create volumes for cephfs, we need to plan to sunset ceph_volume_client.py. Part of that means turning off testing the ceph_volume_client.py library for clients running on master (for Octopus) but still testing clients running an older version like Mimic/Luminous/Nautilus. Testing ceph_volume_client.py in master is no longer productive as python3 movements are breaking it continuously and it's to be obsoleted in Octopus. Testing ceph_volume_client.py on an older client remains important as we're aware of at least one failure caused by `mds dump` being obsoleted by Nautilus. Also, we don't want to break current use-cases that are not ready to migrate to the new volumes plugin. So we need an upgrade test in qa/suites/fs/upgrade/ that does this testing. That will mostly be migrating the existing test in fs/basic_functional/tasks/volume-client to an upgrade test. The tricky part is installing luminous on the client machine and then configuring it to talk to the Nautilus/Octopus cluster. Up to now, we normally do testing of old clients by first setting up the cluster with the older version we like to test and then upgrading every node except the clients. This won't work anymore (easily) because we no longer can upgrade directly from Luminous to master/Octopus. So, we need to get a little smarter by simply installing luminous packages on a client node and then installing a ceph.conf to talk to the Nautilus/Octopus cluster. +Josh suggested that we could split out the function setting up the ceph.conf in qa/tasks/ceph.py into a separate task that can be run on the clients. It does need to be made a little smarter so that it installs a ceph.conf that is readable by a luminous client. In particular, it can't dump v2 monitor addresses to the ceph.conf. What do you think? -- Patrick Donnelly, Ph.D. He / Him / His Senior Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
