I agree that we need to get rid of the releases dir in the root crowbar repo and begin branching all repos (including the root crowbar repo) per release. The way it is currently structured leads to collisions between releases.
For example, Mesa and Roxy now require two different versions of Ubuntu 12.04, but because the root crowbar repo is not branched, it must be configured to build either one or the other. In my dev environment, I have to change symbolic links to point to the correct Ubuntu ISO whenever switching between Mesa and Roxy. Needless to say, this is very error prone, and if you do forget to change the links, you only find it when installing, which means at least an hour or two wasted. -1 on creating a new org. I would rather we clean up our current mess or at most create new repos. Thanks, Chris Dell -----Original Message----- From: crowbar-bounces On Behalf Of Adam Spiers Sent: Sunday, November 17, 2013 10:06 AM To: crowbar Subject: Re: [Crowbar] Crowbar 2 Hack Report Rob Hirschfeld (rob_hirschf...@dell.com) wrote: > That's a clear +1 towards new Github Org to me. Hmm, that's not clear to me - possibly the way to go, but I think that would require a lot more thought first. For example it raises the question of how the two organizations should be named, doubles the number of places issues can be tracked, potentially causes confusion over which wiki should be used, and which repo should host the website. It also doubles the number of (push) access lists and subscriptions to be managed. The plus side of that is that commit rights and notifications could be per-release ... for *now*, but only until Crowbar 3, at which point it's not at all clear what would be the right path. A github org per release is WAY overkill. Another reasonable route is to create new repositories within the existing org. There are pros and cons to this too. A third route is simply to break out the top-level repo (and the dev tool with it) into more sensible chunks. That's the least invasive approach, and the one which I (and I think *probably* Victor too) had in mind when we discussed it. Whichever approach we take, we should be clear that creating a new github org or repos is not the silver bullet. The real hard work is doing the cleanup. That *must* include getting rid of the releases/ tree. I am absolutely convinced that the *only* way to go is to have strictly a git branch per release, with the branch names unified across all repos which contain any release-specific data, as detailed at <http://crowbar.sync.in/crowbar-repos>. It also must include removing unused cruft which currently achieves nothing except confusing people :) > That aligns with other discussions that generally say "thank goodness, yes!" > Anyone have objections or issues? I wouldn't be keen on seeing a new org until I'm clear about the answers to the above questions. > -----Original Message----- > From: crowbar-bounces On Behalf Of Adam Spiers > Sent: Saturday, November 16, 2013 11:16 PM > To: crowbar > Subject: Re: [Crowbar] Crowbar 2 Hack Report > > Restructuring the repositories is lonnnnng overdue, so thank you for getting > behind this. Victor and I discussed it at some length during my Austin > visit, and we documented some of our ideas here: > > http://crowbar.sync.in/crowbar-repos > > You will see that in addition to restructuring, we mention a large amount of > cruft whose death is also long overdue. > > Judd Maltin (j...@newgoliath.com) wrote: > > 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- > > > op enstack-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/ > > _______________________________________________ > 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/
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
