Thanks all for your feedback on deprecating ceph-disk, we are very excited to be able to move forwards on a much more robust tool and process for deploying and handling activation of OSDs, removing the dependency on UDEV which has been a tremendous source of constant issues. Initially (see "killing ceph-disk" thread [0]) we planned for removal of Mimic, but we didn't want to introduce the deprecation warnings up until we had an out for those who had OSDs deployed in previous releases with ceph-disk (we are now able to handle those as well). That is the reason ceph-volume, although present since the first Luminous release, hasn't been pushed forward much. Now that we feel like we can cover almost all cases, we would really like to see a wider usage so that we can improve on issues/experience. Given that 12.2.2 is already in the process of getting released, we can't undo the deprecation warnings for that version, but we will remove them for 12.2.3, add them back again in Mimic, which will mean ceph-disk will be kept around a bit longer, and finally fully removed by N. To recap: * ceph-disk deprecation warnings will stay for 12.2.2 * deprecation warnings will be removed in 12.2.3 (and from all later Luminous releases) * deprecation warnings will be added again in ceph-disk for all Mimic releases * ceph-disk will no longer be available for the 'N' release, along with the UDEV rules I believe these four points address most of the concerns voiced in this thread, and should give enough time to port clusters over to ceph-volume. [0] http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-October/021358.html On Thu, Nov 30, 2017 at 8:22 AM, Daniel Baumann <daniel.baumann@xxxxxx> wrote: > On 11/30/17 14:04, Fabian Grünbichler wrote: >> point is - you should not purposefully attempt to annoy users and/or >> downstreams by changing behaviour in the middle of an LTS release cycle, > > exactly. upgrading the patch level (x.y.z to x.y.z+1) should imho never > introduce a behaviour-change, regardless if it's "just" adding new > warnings or not. > > this is a stable update we're talking about, even more so since it's an > LTS release. you never know how people use stuff (e.g. by parsing stupid > things), so such behaviour-change will break stuff for *some* people > (granted, most likely a really low number). > > my expection to an stable release is, that it stays, literally, stable. > that's the whole point of having it in the first place. otherwise we > would all be running git snapshots and update randomly to newer ones. > > adding deprecation messages in mimic makes sense, and getting rid of > it/not provide support for it in mimic+1 is reasonable. > > Regards, > Daniel > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |