Rob, These are excellent suggestions
1) Workload and barclamp repos. I like the organizing principle here. The natural breakdown of workloads into barclamps, and then barclamps into their script/puppet/chef code can be managed with tools more familiar to those communities: berkshelf/librarian, etc. 2) YES to separate build tools repo! 3) I think I understand what you mean by the difference between "crowbar" and "crowbar framework or core." But I'm not sure, so please elaborate. 4) org name: opencrowbar? -judd On Sun, Nov 3, 2013 at 11:05 AM, <rob_hirschf...@dell.com> wrote: > 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/ > -- Judd Maltin T: 917-882-1270 F: 501-694-7809 what could possibly go wrong?
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
