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/

Reply via email to