On Wed, Dec 18, 2013 at 4:31 AM, Vincent Untz <vu...@suse.com> wrote:
> Hi Rob, > > Your mail seems to indicate that Crowbar 1.x has reached the end of its > life. This makes me really sad: I think we're proving this view is wrong > on a daily basis, as you can see with the amount of changes going in > Crowbar 1.x. I dare to say that its development has never been so fast, > and we're improving it in an iterative way. Crowbar 1.x is unmaintainable in the longer term for the simple fact that it relies on aging, unmaintained infrastructure for core functionality -- iterative improvements might work around specific annoyances for the short term, but as long as Crowbar relies on chef-server 1.0x and Rails 2.3, there is only so much you can do. The chief offender here is chef-server 10.x, which has a couple of properties I see as party stoppers: * Timing-related bugs that have their root cause in Couchdb not having any locks (or, at least, Chef not using them) and being eventually consistent. Ever wonder why there are sleeps in odd places in the code, and why the core code that juggles Chef objects is as weird as it is? We put those there to let and/or force (where we can) chef and couchdb to get synchronized, but (at this point -- the low-hanging fruit having been plicked a while ago) the way to find places that need those hacks is by running into data races at scale on real hardware. * The database files are append-only and grow in size over time despite garbage collection, leading to fairly significant slowdown on admin nodes that run for long periods of time. Run an admin node in production for 6 months and you will see what I mean. Those two things combined make it take pretty significant effort to get Crowbar to manage more than 60-70 nodes, and things really start hitting a wall at about 100 nodes. A lesser offender here is Rails 2.3, which is officially dead and unmaintained. > Also, I can only repeat one more time that I totally fail to understand > the reasons to move to another github org. You're mentioning that > without this, it would "require substantial investment in Crowbar 1 > infrastructure, to update and test". I beg to disagree here. It's only a > matter of creating branches in the toplevel crowbar repo. Can you > clarify what is substantial in doing that? It doesn't even have to > require huge changes in the ./dev workflow. > I do not want to go back to having branches in the top-level repo -- I strongly prefer that it only hold release-independent (and therefore non-branch-needing) things, and pull in other repos that are branched based on release. > What's really worrying to me, though, is that your suggestion might lead > to a split in the community. Our community is not that big, and I don't > think we can afford it. > > Cheers, > > Vincent > > PS: also +1 on Ralf's comment about "Open Crowbar". We've been working > on the Crowbar project all together -- it's already open! > >
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
