Inline: Thanks! ––––––––– Sébastien Han Senior Principal Software Engineer, Storage Architect "Always give 100%. Unless you're giving blood." On Fri, Dec 6, 2019 at 12:22 AM Kai Wagner <kwagner@xxxxxxxx> wrote: > > > On 05.12.19 10:33, Sebastien Han wrote: > > Sorry, this has turned again into a ceph-disk/ceph-volume discussion... > > Yes because that's basically what you're doing here. So what? > Personally I don't > see the value in just switching back again as I didn't found real good > and absolutely necessary reasons to do so and why rook and/or > ceph-volume couldn't be fixed in that regard. I also didn't find out why > the new solution should be any better in the case that we don't talk > about switching back in a few month again because all of those issues > are fixed now - You said it yourself "ultimately fixed" which at the > same time means that such tools need some time to reach the point were > all those issues are fixed. We need to start to talk across boundaries > and to reach out and involve other project maintainer to work on real > solutions instead of moving out of their way. ceph-volume is a sunk cost! And your argument basically falls into that paradigm, "oh we have invested so much already, that we cannot stop and we should continue even though this will only bring more trouble". Incapable of accepting this sunk cost. All the issues that have been fixed with a lot of pain. All that pain could have been avoided if LVM wasn't there and pursuing in that direction will only lead us to more pain again. > Just imagine we would switch back to partitions, that would mean that > we're doing again a breaking change between releases. This change would > result in the same thing such like filestore->bluestore or > ceph-disk->ceph-volume - people have to rewrite the whole data of their > cluster at one point or another (or do we want to support both tools > forever?). That's completely wrong. It's not because you change the tool to provision OSDs that you must trash and re-create your OSD. That's why ceph-volume has the "simple scan" command interface. ceph-ansible has handled that migration pretty well transparently without any breaking change. > I have the feeling that we sometimes treat this whole project > still just like a kick-starter project were everything can be switched > and changed between releases in any direction and whenever we think it > would be nice to do so. Could we please start to think about that > there's a big and luckily growing user base behind that are actively > relaying on this solution and they're not keen on moving their data > around just because we had a "feeling"? I disagree, we are just talking about the provisioning tool, no breaking changes involved and I don't even recall any major re-architecture that ever introduced difficulties to users. > No one should feel personally offended by the last remark but > introducing such changes isn't something we could/should just do. We > really should have 100% valid arguments why replacing one tool by > another tool, which we had already in the past, now magically solves > everything and we're sure that we can't fix such issues in the current > solution. 100% is a myth, there is no such thing and no we didn't have that in the past. Back then, I warned about what was coming with containers and here we are... Also, I'm not saying we should replace the tool but allow not using LVM for a simple scenario to start with Anyway, again, that discussion has gotten intense and we should probably stop the storm here. I'm not a big fan of the "ceph-volume activate" wrapper idea but short-term that's probably the best thing we can do, I'll send an e-mail for this shortly. I'll also investigate not using ceph-volume in Rook when it comes to collocating block/db/wal in the same disk for a bluestore OSD. Thanks everyone for your replies, appreciate the inputs. > > Kai > > -- > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg > GF:Geschäftsführer: Felix Imendörffer, (HRB 36809, AG Nürnberg) > > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
