On Tue, Nov 13, 2018 at 4:16 PM Nathan Cutler <ncutler@xxxxxxx> wrote: > > >> Wherever the tool lives, it has to be tailored to a specific Ceph > >> (major) version, e.g. "Luminous" or "Nautilus". As the adjective "major" > >> indicates, from one major version to another, major changes take place. > > > > This is not accurate for ceph-volume, as we are in a position where we > > need to backport every feature. What exists in the master branch > > exists all the way back to Luminous, which requires us to deal with > > the changes in APIs (e.g. from Luminous to Mimic). > > 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. The ceph-volume project doesn't backport features because I want to :) We were in a position where we *had* to. Which is fine, we can backport and if-case luminous/mimic/nautilus. What I am saying is that the statement "Wherever the tool lives, it has to be tailored to a specific Ceph version" is not accurate. It isn't accurate for ceph-volume, and it sure isn't accurate for other tools like ceph-deploy. Other Ceph components aren't required to backport 100% of what exists in master > > Case in point: the Jewel ceph-volume, like the rest of Jewel, is not > getting any new features - or any backports at all for that matter - > because Jewel has been declared EOL. ceph-volume doesn't exist in Jewel. A tool outside of ceph.git can freely chose what it supports or not regardless of what Ceph considers EOL. For example, installers like ceph-deploy have to support them because an EOL Ceph release doesn't mean there are no users at that version. Happy to keep discussing why having ceph-volume in ceph.git is not the greatest fit, but would welcome a reply in a separate thread to avoid hijacking Erwan's issue at hand which is more about the disparity of JSON reporting. > > For all features that get backported, the "major change" from one stable > version of Ceph to the next is just that: the "next" version of the > feature supports the corresponding version of Ceph. > > Nathan
