> I would argue that c-v is not a special case here. To the extent that > you have decided that its worth the backporting effort to maintain > feature parity across multiple major versions, then c-v features are > being backported, but c-v is not the only Ceph component where feature > backporting takes place. This practice is fairly commonplace in other > Ceph components as well, and when the decision to backport is made, > someone always has to shoulder the maintenance burden for the lifetime > of the major version. It's not that we've made the decision to backport, it's that we must backport every feature. Every PR to master gets backported to luminous, mimic, downstream and eventually nautilus. This is a huge burden. External tools like ceph-ansible depend on ceph-volume to be able to handle multiple versions of ceph. These installation tools also need to get new features quickly. We often get into instances where ceph-ansible has code for features in ceph and ceph-volume that have not been released. This causes PRs where the best answer we have is "you must wait for a new ceph release for that to work", which is not ideal. For example, https://github.com/ceph/ceph-ansible/pull/3289 I've just always failed to see the value of ceph-volume in ceph.git. As someone who works on ceph-volume and ceph-ansible, it's done nothing but cause more difficulty and work for everyone involved.
