Hi Darrel, I've created some shell scripts for crowbar multi-node setups back in the day https://github.com/iteh/crowbar-virtualbox Maybe this is starting point for what you want to accomplish.
- Edmund 2013/11/21 Darrel O'Pry <darrel.o...@gmail.com> > > On Thu, Nov 21, 2013 at 6:45 AM, Adam Spiers <aspi...@suse.com> wrote: > >> Darrel O'Pry (darrel.o...@gmail.com) wrote: >> >> > I hear a lot of knee jerk throw everything out and start over >> undertones. I >> > don't that that is a wise idea as it loses history. One of the things I >> > love about git is history. Also being an agile developer I focus on >> > continuous improvement and rarely like to start things over. >> >> Exactly Darrel! I understand where the instinct for "let's start >> afresh" comes from, but really it's only sweeping ugly stuff under the >> carpet. And it's not just git history we'd risk losing - it's issue >> history, wiki history ... >> > > It also doesn't address the workflow issues that created the current state > of things... It's more important to address a possible cause rather than a > symptom. > > <snip> > >> >> > 2) On boarding new developers. >> > <snip> > >> > Beyond that we go our of our way to make development across platforms >> easy. >> > We typically use virtual box and vagrant as a starting point to >> normalize >> > everyone's development environment and share the git checkout with the >> > vagrant. This way everyone is building on the same build environment. >> We >> > typically share the git checkout from the VM host to the build VM. The >> > build, run, test within the VM. You just expand the number of vagrants >> you >> > use to test on other platforms. I tend toward veewee if I need to build >> and >> > track any sort of super custom vagrant base boxes. >> > >> >> Standardising the dev environment is a great idea. There's still some >> remaining work to do in order for this to be SUSE-friendly though. >> Most SUSE-oriented folk prefer KVM to VirtualBox, and last time I >> looked, vagrant's support for kvm / libvirt still needed work. This >> would be well worth completing. Secondly, building openSUSE-based >> ISOs is still a work in progress (I worked with John on this last >> weekend). >> > > This is a situation where I feel the needs of the project to be accessible > as a whole, should override the preferences of a few participants. > VirtualBox is a free cross platform desktop virtualization environment. It > is available to windows, mac, and linux developers. It is accessible for > both corporate teams and private hackers. The public shared project should > focus on the most accessible development tools possible. Try to cater to > kvm, vbox, vmware will just add unnecessary complexity to on boarding a new > developer. > > It's totally doable, but it means that new developers have more decisions > to make to get started on the project and someone has to spend time > planning, testing, and maintain support for multiple virtual box providers. > It means time will be spent debugging whether the problem is the > virtualization layer or crowbar. Time better spent making crowbar more > awesome. > > If the team at SUSE or any other team is really insistent on maintaining > another development environment, they should be welcome to fork and manage > their own tooling to convert the vboxes to kvm. Alternatively, get involved > in the vagrant and veewee communities to streamline the generation and > publishing of consistent virtual machines for multiple virtualization > providers. > > Even then tools like veewee don't make much sense in a developer's > workflow. I've tried fitting things like veewee into developer workflows > with the idea of letting everyone build images from preseed and > kickstart... Too much time is spent building images and drinking coffee for > simple package additions. > > The approach our teams use is to build minimal vboxes using veewee. We > mostly use debian/ubuntu so we switch the tasksel from standard/server to > minimal to reduce the OS footprint in the VMs. We also remove ruby, chef, > and puppet to avoid conflicts with whatever we'll be installing. We store > the veewee definitions in our code repositories so they're tracked with > code, but we don't require developers to build the vboxes. We build and > publish them to a private website where our team can access them. We don't > do any configuration via veewee except setting up ssh and public key access > (necessary for vagrant). We also use private keypairs in lieu of the public > vagrant keys for our private projects. > > All of the dev environment configuration is handled by vagrant > provisioning shell scripts.. typically config.vm.provision "shell", path: > "bootstrap.sh". > > There is of course a need to expand on this to build a dev environment for > a project like crowbar that needs multiple vm for building and needs to > setup a rather complex testing environment with mutiple vms. The nice thing > is you can also ship a testing environment with vagrant and the same boxes. > This makes it possible to > > vagrant up dev > vagrant up ubuntu12.10-admin > vagrant up bare-node1 > vagrant up bare-node2 > vagrant up bare-node3 > vagrant up bare-node4 > > Which could all be wrapped up in a grunt, make, rake, shell script task... > There could even have a grunt watcher kicking of environment re-builds and > test locally on commit. It would probably be wise to expand testing to KVM > and other virtualization providers and testing stacks... > > When we've helped clients implement deployment and testing of other > opensource projects in private environments with more rigorous testing and > QA requirements, We've created a separate internal deployment repository > that includes the upstream code as a sub-module and provides the project or > implementation specific continuous deployment pipeline around the existing > public project tooling. > > Feel free to reach out directly if anyone wants to implement this stuff. > I'm glad to help if people are interested in the community can agree on a > direction, but my time to contribute actual code to open source projects is > limited by my own consulting practice. We've also been unfortunately lax in > building model repositories as starting points, and I'm unable to share > examples of our client work. I do have an interest in testing out tooling > and workflows in lots of different development environments and settings. > Crowbar is a pretty complex case from a continuous deployment perspective > and the virtual development to bare metal deployment is a an important use > case to work with. > > > > 3) Maintenance >> > >> > We use jenkins extensively to review our pull requests. We do a number >> of >> > smoke tests including linting to enfoce code style, fxcop/sniffing/etc >> to >> > look for common code mistakes, code coverage. We lean heavily on peer >> > review of pull requests. Our team is distributed and we don't always >> have >> > the luxury of pairing, instead we do a code review with each pull >> request >> > that includes a developer on the project and a developer from another >> > project. It serves to cross train, and have someone less familiar with >> the >> > project who will not take the knowledge one develops writing and >> working on >> > the code for granted. >> >> +1. Of course Crowbar doesn't use Jenkins yet, but it probably could >> in the future if we reduced the number of git repos and wanted to >> switch to it (I'm not religious either way - github is good enough for >> our code reviews IMO). > > > We actually use GitHub for everything. Jenkins is pretty easy to integrate > with GitHub and setup to update your pull requests with testing... We run a > Jenkins server per GitHub repository in the cloud and run our build agents > on physical hardware with virtual box and vagrant available so we can do > all of our unit testing inside the same development environment as the > developers without having to do a lot of customization in our build farm to > support projects. > > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > -- Edmund Haselwanter Head of Consulting and Training / Leiter Consulting und Training Körnerstr. 7-10 10785 Berlin T: +49 171 7607049 F: +49 30 577018099 cloudbau GmbH, Körnerstr. 7-10, 10785 Berlin Geschäftsführer: Sören Blom, Hendrik Volkmer, Edmund Haselwanter Registergericht: AG Hamburg, HRB 125114 Steuernummer: 37/223/21966 www.cloudbau.de
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
