Darrel O'Pry (darrel.o...@gmail.com) wrote: > 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.
Strongly agree! > > > 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. In principle I agree with all of this, but realistically widescale adoption of VirtualBox at SUSE is just not going to happen - too many of our existing workflows are already KVM-centric. > 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. Yes, I think these are more realistic routes (hence my above comments about vagrant support for KVM / libvirt). Given the phonetic similarity between veewee and kiwi, I strongly suspect that the creator of veewee was aware of kiwi before they invented veewee. I'm not familiar with veewee, so I wonder what the high-level differences are, other than the obvious: Ruby vs. Perl, and the focus on building for VMs. > 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. That all sounds good. IIRC Judd is a big vagrant fan, but I'm not sure if anyone else is using it for Crowbar work currently. > 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... Right. Replacing a large chunk of ./dev with standard tools would make working on CI etc. more accessible to a wider audience. [snipped] > 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. Actually we're currently working on setting up our Jenkins to do automatic smoke-testing of Crowbar pull requests. Watch this space ... _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
