IMO, I am glad to see there are at least three solutions here to address repair and can be potential candidates for sidecar. As Joey pointed out, all of them may not be great at everything they do, and to me, it makes sense to "cherry pick" the best each product has, and build a good C* sidecar.
Thanks, Sumanth On Tue, Aug 28, 2018 at 2:45 PM, Blake Eggleston <beggles...@apple.com> wrote: > I haven’t settled on a position yet (will have more time think about > things after the 9/1 freeze), but I wanted to point out that the argument > that something new should be written because an existing project has tech > debt, and we'll do it the right way this time, is a pretty common software > engineering mistake. The thing you’re replacing usually needs to have some > really serious problems to make it worth replacing. > > I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless > mess. It would bring a relatively mature project as well as a community of > users and developers that the other options won’t. It’s probably a lot less > work to rework whatever shortcomings reaper has, add new-hotness repair > schedulers to it, and get people to actually use them than it would be to > write something from scratch and build community confidence in it and get > reaper users to switch. > > On August 28, 2018 at 1:40:59 PM, Roopa Tangirala > (rtangir...@netflix.com.invalid) > wrote: > I share Dinesh's concern too regarding tech debt with existing codebase. > Its good we have multiple solutions for repairs which have been always > painful in Cassandra. It would be great to see the community take the > best > pieces from the available solutions and roll it into the fresh side car > which will help ease Cassandra's maintenance for lot of folks. > > My main concern with starting with an existing codebase is that it comes > with tech debt. This is not specific to Reaper but to any codebase that > is > imported as a whole. This means future developers and patches have to > work > within the confines of the decisions that were already made. Practically > speaking once a codebase is established there is inertia in making > architectural changes and we're left dealing with technical debt. > > > > *Regards,* > > *Roopa Tangirala* > > Engineering Manager CDE > > *(408) 438-3156 - mobile* > > > > > > > On Mon, Aug 27, 2018 at 10:49 PM Dinesh Joshi > <dinesh.jo...@yahoo.com.invalid> wrote: > > > > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > We're hoping to get some feedback on our side if that's something > people > > > are interested in. We've gone back and forth privately on our own > > > preferences, hopes, dreams, etc, but I feel like a public discussion > > would > > > be healthy at this point. Does anyone share the view of using Reaper > as > > a > > > starting point? What concerns to people have? > > > > > > I have briefly looked at the Reaper codebase but I am yet to analyze it > > better to have a real, meaningful opinion. > > > > My main concern with starting with an existing codebase is that it > comes > > with tech debt. This is not specific to Reaper but to any codebase that > is > > imported as a whole. This means future developers and patches have to > work > > within the confines of the decisions that were already made. > Practically > > speaking once a codebase is established there is inertia in making > > architectural changes and we're left dealing with technical debt. > > > > As it stands I am not against the idea of using Reaper's features and I > > would very much like using mature code that has been tested. I would > > however like to propose piece-mealing it into the codebase. This will > give > > the community a chance to review what is going in and possibly change > some > > of the design decisions upfront. This will also avoid a situation where > we > > have to make many breaking changes in the initial versions due to > > refactoring. > > > > I would also like it if we could compare and contrast the functionality > > with Priam or any other interesting sidecars that folks may want to > call > > out. In fact it would be great if we could bring in the best > functionality > > from multiple implementations. > > > > Dinesh > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
