Objective: Establish process for future sprints
Following Sprint: http://crowbar.sync.in/sprint0802
Crowbar Refactoring Coordination Efforts
Unfortunately, this session was not recorded :(
Using migrations to create the models - migrations will show up in the barclamps
So far, we've build good practices w/ Chef and been able to create orchestration models. However, Chef is not along in the CMDB space. Now that we understand the problem better, we're able to start decoupling from Chef and be able to drive any CMDB.
"Clawhammer" can yank out and bash in things from CMDB
Attribute maps will help figure out which Crowbar information needs to be synchronized into each CMDB
Does this create a problem with data synchronization? How much data should Crowbar store?
Crowbar is automated orchestration. This is different than most people use chef. Rundeck and similar tools do some of this, but more of an automation of what people do to drive chef.
Crowbar has two problems dealing with chef.
The second usage problem is that most people edit the attributes.rb of the recipe and upload that into their cookbook for customization. While we could do this, it doesn't allow for multiple instances of the cookbook being deployed in the cloud. It also means that you have upload/change recipes for configuration changes. This felt "bad" for a system that wanted to use unmodified recipes (yes, that was a goal in the olden days, though not really realized, hopefully with attribute driven recipes shortly).
The recipes are the class methods with the proposal roles being the data for an instance of that class and the crowbar barclamp pieces being the factory for those instances. <squint, no I mean it, squint>
Add on to that the element roles (e.g. glance-server, nova-multi-compute, ....), you get reasonable orchestration.
So, nova-multi-controller is a run-list that pulls in the correct recipes or other roles to build a nova controller node. These are short-cut lists so that the master run-list in the node-role can be easily updated to add desired function.
Clawhammer has the real possibily to adding even more scalpel like slicing to the problem directed chef runs. I could see us build run_lists on the fly so that only certain recipes are run at only certain times. This helps with faster and more controlled bring up of nodes
So, where did this come from? Defensive coding because chef sucks. To clarify: Chef sucks when used as a relational database. BECAUSE IT ISN'T ONE! But we use it that way anyway. This is why we are doing some of the database work.
Some of the things were designed from the beginning (or near beginning).
The following people are available for development this sprint (time zone)
Last edited by Adam Spiers,