Inline ... This is what I do and by no means is the only way. So I encourage others to reply as well.
________________________________________ From: Halterman, Jonathan <[email protected]> Sent: Thursday, June 25, 2015 11:53 AM To: [email protected] Subject: Re: Dev workflow Followup to this: Do you typically run the entire test suite on changes? Just the suite for a specific sub-project? I noticed that some of the individual test cases take 4+ minutes on my VM so I wanted to see what others do. [Sumit] If you are making changes to specific modules (e.g. view, agent, or stacks within ambari-server) you can only run tests for the module. The issue is when you make changes to ambari-server whose unit tests can take 20-40 minutes. You can run tests specific to files being changed if the changes are limited in scope. Also, adding a patch to the Apache JIRA and submitting the patch will also get you a test run for free - you still need to wait. So it might be a good idea to do so just before commit and while developing you can run specific tests. - jonathan From: <Halterman>, Jonathan Halterman <[email protected]<mailto:[email protected]>> Date: Thursday, June 25, 2015 at 11:14 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Dev workflow I just wanted to ping the community to get a sense for what dev workflow other developers are using. The wiki hints at a few possibilities – using ambari-vagrant, using the dev-tools' Docker, but since building/installing/running Ambari is a bit different than other projects, I’m curious what the end to end dev workflow looks like. Some specific questions: * What’s your general workflow for deploying and testing changes in an ambari-server? [Sumit] In my case, I deploy Ambari/Stack on a Vagrant VM and update the jars/scripts as needed with my fixes. I usually keep my VM updated by re-deploying fresh every 1-2 days. This can be troublesome if you are testing some scenarios that require more work than the default deployment such as external DB, security, AD integration, etc. In general, you can go a few days without having to update your VM or sync'ing. * Do you run ambari-server for development on your local machine? [Sumit] I do not. Running Ambari in DEBUG mode allows easy debugging from your dev machine (see below). * Do you run ambari-server in a VM or container? If so: * Do you use synced folders or shared volumes? [Sumit] Yes, I run on VMs. I do not use sync'ed folders or volume but that has worked for me before. For me the reason is that I switch between Vagrant, ec2, gce, etc. for my development. * If so, what kind of synced folders (vagrant, nfs, rsync)? [Sumit] Vagrant works fine. * Are you able to successfully build ambari when using synced folders? [Sumit] I have not tried it. * Are you able to successfully build an rpm/deb when using synced folders? [Sumit] I have not tried it either. * If you don’t use synced folders, what’s your workflow for testing code? [Sumit] Build on the dev machine and copy over jars. If there are changes to the scripts then I will use some scripts to copy them over and overlay them properly. * Does the ambari apt/deb package need to be installed in order to start ambari-server for development purposes? [Sumit] I assume yes. In my case, I use one of the latest builds from my organization and then patch it with my fixes. * How do you start ambari-server for development purposes (with the ability to attach a debugger)? [Sumit] If you look into /usr/sbin/ambari_server_main.py then you can see the SERVER_START_CMD_DEBUG and also how to start the server with this option. HTH Cheers, Jonathan
