Awesome. One thing I forgot in the should be able to section is to start with ./dev switch development/master to check out all the crowbar 2.0 code. On Sep 7, 2013 7:15 PM, "Shane Gibson" <shane_gib...@symantec.com> wrote:
> ** ** > > 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:* crowbar-boun...@dell.com [mailto:crowbar-boun...@dell.com] *On > Behalf Of *Victor Lowther > *Sent:* Saturday, September 07, 2013 4:56 PM > *To:* crow...@lists.us.dell.com > *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 > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ >
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
