All,
We had a good design discussion today.
Notes http://crowbar.sync.in/community-planning-meeting-2014-01-29
Recording http://youtu.be/VGXQ8WzlDbM
Topics include: types of data in CB2, OCB repo migration needs, Docker Admin
Container (design review), Berkshelf discussion
Here's the text:
## Design Meeting 2/5
* Attribute Injection Training (posted to youtube)
* when to use which type of data storage
* topics that still remain:
* data model
* node-role datum class
### When to use which data methods in the noderole (when to the Wall?)
.data
* user settable information from the proposal
* settings changes via the API or UI
* only changed while a deployment/noderole is in the proposed state
* configuration (from User to CB)
.sysdata
* data that's created by code in the CB framework
* default settings that could be overridden by the user
* outbound data (from CB to Jig/Node)
.wall
* data that comes back from the jig run
* inbound data (from Jig/Node to CB)
Data presented to a run is merged based on precedence & position in node-role
relationship graph.
Precedence: user > sysdata > wall
Precedence: self > parent
All data is stored as JSON blobs
### Transisition Roadmap to OCB
* Use Github pull request process (documented)
* Use OpenCrowbar.org point wiki.opencrowbar.org
* Missing Docs
* how to get started
* workflow for contribution
* design documentation
* document build tools (community discussion)
* /core/docs ares
* Workable process for devs & test to create a multinode system (VMs initially
then Hardware)
* Build output & product installation (not blocking for migration)
* Resolve how to add workloads into core (aka adding barclamps) - not blocking
but high priority
* make sure that we have all the workload repos cloned properly
* make sure we connect workload to core
* make sure we have the berks w/ correct references (do not dup)
* how do we upgrade core cookbooks (assuming they use berkshelf too)
* resolve how to handle upstream cookbooks (fork, pull, etc)
### Docker Admin Node
Rob's objective > Recording showing OCB admin in docker able to boot/manage VMs
on same machine
Objective: Enable minimal time for a dev usable working Admin node
Working = Admin node, you can boot VMs or H/W from the Admin instannce (as long
as networking is setup)
_This is NOT a canned image._ but can be used as a prep'ed environment
Design Choice: Chef-Solo is used to boostrap all the pre-reqs inside the
environment ("boostrap"). Output from the boostrap process can be committed as
a container that can be used as a quick-start. Boostrap running creates the
complete system - very repeatable.
The code for OCB lives outside of the container but runs inside the container.
So, changes in instlal process are able to be made even if you have an existing
container.
Bootstrap does not care which environment it runs in. You can use it agasint
VMs or physical nodes too. That means it is effectively an installation
process. Idea is that developers are using THE SAME install process that we
would use in production. This needs some more testing/docs, but should work.
Where does the code come from?
* Devs use a git clone and directory of the code is mapped into the
container (bind mount the source)
* TBD -> we need to figure out what to if the code is RPM packages
REQUIRES connectively to the Internet! (online mode)
Design Goal: use the same paths for all environments
Blocking Item: Sledgehammer in OCB repo
### Cookbook Management Discussion
Berkshelf 3
* you will need a copy of the Chef Server Bits (it's in the omnibus
installer)
* Berkshelf is just a gem in the Chef Server omnibus < VL thinks this is not
an issue, should be able to get from rubymine
* Berkshelf and knife are merging
Concerns
* how are we going to get the cookbooks into the nodes
* there will be a mix of cookbooks (crowbar local, upstream, etc)
* how do all the devs have the right cookbooks & manage versions
* Berksfile (v3) has gotten more robuts. includes code and precedence w/
tags for version
VL votes to implement now - stop discussing discussing (RH +1)
Alternatives:
* just copy in the code (fork) (-1000 from VL)
* custom code that handles code (-2000 from VL)
* librarian - has no centralized depencency resolver
Can we scope of this discussion is limited to the jig that implements the
upstream integration?
* Developers have to act outside of the Jig
* need to resolve that developers are using/upstreaming the right versions
There are upstream cookbooks throughout the code base (e.g.: apache server
setup)
Rob
______________________________
Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone
_______________________________________________
Crowbar mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
