How quickly are you planning to cut 12.2.3?
On Thu, Nov 30, 2017 at 4:25 PM, Alfredo Deza <ad...@redhat.com> wrote: > 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.baum...@bfh.ch> 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@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
