Dell - Internal Use - Confidential
Another item worth mentioning for people looking to play w/ CB2.0 – we have a
SIMULATOR that can populate a test system for easy play!
To use the simulator:
In your dev system, run the test server: ./dev tests server
In a new window, start erlang
cd ~/crowbar/barclamps/crowbar/BDD
cp example.config default.config
[review default.config and update if needed]
./linux_compile.sh
erl
dev:pop().
Open the Crowbar UI under http://[dev system IP]:3000
You can then explore and even run the Annealer!
I’ll upload a demo.
Note, most of this is in the INTEGRATED DOCS system of the barclamps. Please
update there if you find errors.
From: crowbar-bounces On Behalf Of Shane Gibson
Sent: Saturday, September 07, 2013 7:15 PM
To: crowbar
Subject: Re: [Crowbar] Crowbar 2.0 Status Report
Victor – thanks for the great update. After having spent some time discussing
the Crowbar 2.0 vision and direction with Rob – we were keen to see bits and
pieces of the implementation come together. Nice to see this happening quickly!
We will be give this iteration a run through on our environment too…
~~shane
From: [email protected] [mailto:[email protected]] On Behalf Of
Victor Lowther
Sent: Saturday, September 07, 2013 4:56 PM
To: [email protected]
Subject: [Crowbar] Crowbar 2.0 Status Report
As of the latest set of pushes to development release, Crowbar 2.0 is now able
to deploy an admin node that can then boot other nodes into Sledgehammer.
Unlike the last time CB2.0 was able to do this, the Crowbar framework is
performing all the work needed to bootstrap itself into usefulness without
manual intervention. With the current codebase, you should be able to:
* Build a Crowbar ISO using the usual ./dev build --os ubuntu-12.04 method.
* Boot a VM (or real machine, if you have one to spare) to the generated
ISO, and let it install
* Once the admin node is installed, log in as crowbar/crowbar, sudo -i to
root, and run /opt/dell/bin/install-crowbar your.admin.fqdn
* Watch the script output with screen -r
* Once screen terminates, log in to the Crowbar webui at
http://192.168.124.10:3000 with crowbar/crowbar
* Poke around all the new UI bits and see all the new shininess
* Boot other nodes into sledgehammer and then watch them drop to a login
prompt instead of doing something useful
While that does not sound like much on the surface, that Rob and I have been
able to go from just having a working web UI and test suite to having most of
the key bits in place to act as a Crowbar admin node over the last 3 weeks in
our spare time validates several of the key design features of CB 2.0, which I
will go over in more detail below.
Design difference between CB 1.x and CB 2.0:
* Shifting from coarse-grained linear semi-implicit dependencies between
barclamps to having a proper dependency graphs for roles and node-role bindings.
In Crowbar 1.x, the core Crowbar framework has several partially-overlapping
ad-hoc mechanisms for determining when it should do what, and they are all
driven by having barclamp authors assigning integer priorities to barclamps,
chef roles, configuration data, and hacks and monkey patching to work around
where they do not play nicely together. Since the rules were informal and
never documented, the only way to determine when things would happen is via
experimenting with priority numbers until things worked the way you expected
them to, or adding yet another hack if you could not get things to work
properly. In Crowbar 2.0, barclamp writers only need to explicitly declare the
dependencies on other roles their roles have, and make sure their declarations
do not make the role dependency graph circular, which is easier to reason
about. The Crowbar framework then uses the dependency graph between roles to
build the graph between node-role bindings as the cluster is built out to
ensure that things always happen in the right order.
* Shifting the primary emphasis in interacting with Crowbar from
interactions at a barclamp level to interactions at the role and node-role
binding level.
In Crowbar 1.x, virtually all of the interaction between the user and Crowbar
happens in terms of barclamp level proposals. In Crowbar 2.0, that
responsibility is divided into 3 different spheres of responsibility:
* Roles, which represent a specific bundle of capabilities that can be
attached to a node. For instance, dns-server is the role in Crowbar 2.0 that
allows a server to act as a DNS server.
* Deployments, which act as a collection of nodes along with a default
set of role configuration information for any roles that may be bound to a node
in the deployment. Deployments will be hierarchical, and there is a system
deployment that the Crowbar framework manages at the root of that hierarchy.
All newly-discovered nodes will be added to the system deployment to get their
initial node-role bindings.
* Node-role bindings (called noderoles for short -- please suggest a
better name for this!), which represent a specific instance of a role bound to
a node. Noderoles have their own configuration in addition to the role
configuration at a deployment level and the default role configuration.
* Not relying on Chef as a foundational component.
Crowbar 1.x relies on Chef 10.x for everything, including storing all of the
information needed to run the Crowbar framework. This meant that any failure
on the part of Chef had catastrophic consequences on Crowbar. Crowbar 2.0 is a
standalone application that does not rely on Chef to store its configuration
information.
* Not relying on Chef as the only way to effect change on a node.
In Crowbar 2.0, we have the concept of a jig as a component that can be used to
effect change on another node. Support for using Chef in Crowbar 2.0 is
provided by the Chef jig, and Crowbar 2.0 also has a Script jig that is used
for bootstrapping. Every role declares what jig must be used to do what it
needs on a node.
Next Steps for Crowbar 2.0 (in rough dependency order):
* Make framework side of the Network barclamp operate properly, instead of
working in rigged demo mode.
Right now, the Crowbar framework side of things is just smart enough to
allocate an IP to the admin node to exercise the network recipe and bootstrap
the rest of the admin node roles. It needs to be able to track IP address
allocations in a generic fashion, and it needs to be able to support other
networks besides the admin network.
* Flesh out node discovery.
We can boot nodes into Sledgehammer, but we need to wire in more functionality
to allow node discovery and configuration to take place.
* Come up with a reasonable OS installation story, and implement it.
* De-cruft the Crowbar-specific Chef cookbooks.
While the current Chef cookbooks work with minimal changes, a side-effect of
how the Crowbar framework manages configuration data via the node-role graph is
that it is very easy for most of our core cookbooks to operate in an entirely
attribute-driven fashion. Refactoring them and stripping out the CB 1.x
specific cruft would be a good way to learn the framework.
Questions? Comments? Flames? Pull requests? I am at your service.
_______________________________________________
Crowbar mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
