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/
