Overall, I'm happy with our three days of hacking on Crowbar 2.  We've reached 
the critical "deploys workload" milestone and I'm excited about well the design 
is working and how clearly we've been able to articulate our approach in code & 
UI.

Of course, it's worth noting again that Crowbar 1 has also had significant 
progress on OpenStack Havana 
workloads<http://robhirschfeld.com/2013/10/29/looking-to-leverage-openstack-havana-crowbar-delivers-3xl/>
 running on Ubuntu, Centos/RHEL, and SUSE/SLES

Here are the focus items from the hack:
§  Documentation - cleaned up documentation specifically by updating the README 
in all the projects to point to the real documentation in an effort to help 
people find useful information faster.  Reminder: if unsure, put documentation 
in barclamp-crowbar/doc!
§  Docker Integration for Crowbar 2 progress.  You can now install Docker from 
internal packages on an admin node.  We have a strategy for allowing containers 
be workload nodes.
§  Ceph installed as workload is working.  This workload revealed the need for 
UI improvements and additional flags for roles (hello "cluster")
§  Progress on OpenSUSE and Fedora as Crowbar 2 install targets.  This gets us 
closer to true multi-O/S support.
§  OpenSUSE 13.1 setup as a dev environment including tests.  This is a target 
working environment.
§  Being 12 hours offset from the US really impacted remote participation.

One thing that became obvious during the hack is that we've reached a point in 
Crowbar 2 development where it makes sense to move the work into distinct 
repositories.  There are build, organization and packaging changes that would 
simplify Crowbar 2 and make it easier to start using; however, we've been 
trying to maintain backwards compatibility with Crowbar 1.  This is becoming 
impossible; consequently, it appears time to split them.  Here are some items 
for consideration:
1.    Crowbar 2 could collect barclamps into larger "workload" repos so there 
would be far fewer repos (although possibly still barclamps within a workload). 
 For example, there would be a "core" set that includes all the current CB2 
barclamps.  OpenStack, Ceph and Hadoop would be their own sets.
2.    Crowbar 2 would have a clearly named "build" or "tools" repo instead of 
having it called "crowbar"
3.    Crowbar 2 framework would be either part of "core" or called "framework"
4.    We would put these in a new organization ("Crowbar2" or "Crowbar-2") so 
that the clutter of Crowbar's current organization is avoided.

While we clearly need to break apart the repo, this suggestion needs community 
more discussion!
Rob
______________________________
Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Reply via email to