On Dec 20, 2013 8:45 AM, "Dirk Müller" <d...@dmllr.de> wrote:
>
> Hi Victor,
>
> > * 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.
>
> Didn't you fix that yourself btw already in Crowbar?
>
>
https://github.com/crowbar/barclamp-crowbar/commit/58ebf59341cca0380eb5f8c174510a545d13480e#diff-e6352a5317a68e2415c2bfccc18b402d

It reduces but does not eliminate the data file growth over time.

> > 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.
>
> Absolutely agreed. And OpenCrowbar is going to scale beyond that?

Yes, our tentative design goal is in the thousands of nodes range

> > 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.
>
> Fine. On the other side you're saying that crowbar is a critical piece
> of infrastructure. Can the pieces that crowbar 2.x needed from
> crowbar/ be splitted into a separate git module? crowbar-framework
> perhaps?

The crowbar 2 framework (as opposed to the dev/build env and some of the
Chef cookbooks) is rather different in architecture and implementation.

> >> PS: also +1 on Ralf's comment about "Open Crowbar". We've been working
> >> on the Crowbar project all together -- it's already open!
>
> +1
_______________________________________________
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