You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Halterman, Jonathan" <jo...@hp.com> on 2015/06/25 20:14:27 UTC
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?
* Do you run ambari-server for development on your local machine?
* Do you run ambari-server in a VM or container? If so:
* Do you use synced folders or shared volumes?
* If so, what kind of synced folders (vagrant, nfs, rsync)?
* Are you able to successfully build ambari when using synced folders?
* Are you able to successfully build an rpm/deb when using synced folders?
* If you don’t use synced folders, what’s your workflow for testing code?
* Does the ambari apt/deb package need to be installed in order to start ambari-server for development purposes?
* How do you start ambari-server for development purposes (with the ability to attach a debugger)?
Cheers,
Jonathan
Re: Dev workflow
Posted by "Halterman, Jonathan" <jo...@hp.com>.
Hi Nate,
I don¹t have that environment setup anymore, but I recall my attempt at
running locally yielded a various database related warnings and errors
during startup and usage. My setup involved a heavily modded properties
file and manually importing the postgres embedded schema.
The dev setup described on the wiki[1] talks about how to build ambari
from source and how to run it from a deb/apt package, but missing is how
to run it from source (as a dev typically would). That¹s probably the gap
we should look to fill, and ideally the platform shouldn¹t matter.
Cheers,
Jonathan
https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development
On 6/29/15, 10:14 AM, "Nate Cole" <nc...@hortonworks.com> wrote:
>Aplogies for the delayed response.
>
>When you say it ³didn¹t seem to run very well² - can you describe the
>issues you saw? The wiki page seems pretty complete on the prerequisites
>required to setup the dev environment. Outside that, the properties that
>i pasted earlier should help point you in the right direction.
>
>If you have specific problems running please let me know and I can see if
>I can provide the workaround.
>
>Thanks
>
>> On Jun 26, 2015, at 5:40 PM, Halterman, Jonathan
>><jo...@hp.com> wrote:
>>
>> Hi Nate - thanks a lot for the response.
>>
>> I guess the peculiar thing for a newcomer to Ambari is that running the
>>server seems to involve the same process, whether you¹re a developer
>>hacking on source or an end user installing from a deb/apt package. This
>>is to say, that running the server generally requires installing an
>>apt/deb package. There doesn¹t appear to be a straightforward way to
>>just clone the source and start the thing, as is typical, even with the
>>basic dependencies like Postgres in place.
>>
>> So that all said, what¹s the process for running locally? I actually
>>tried this previously (on OS X) using some pointers and properties from
>>Jonathan Hurley, but the server just didn¹t seem to run very well, and I
>>got the sense that despite using platform independent technologies, that
>>this project just wasn¹t really setup to run outside of a platform
>>specific deb/apt install. I¹d love to run locally though, and to help
>>enhance things in that area. But to start, do you have any specific
>>pointers/resources you can share towards addressing each of the bullet
>>points you highlighted? If it makes sense to start throwing this stuff
>>on the wiki, please feel free.
>>
>> Cheers,
>> Jonathan
>>
>> From: Nate Cole <nc...@hortonworks.com>>
>> Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org>"
>><de...@ambari.apache.org>>
>> Date: Friday, June 26, 2015 at 6:18 AM
>> To: "dev@ambari.apache.org<ma...@ambari.apache.org>"
>><de...@ambari.apache.org>>
>> Subject: Re: Dev workflow
>>
>> Other¹s have commented; I personally have development working locally
>>with Eclipse, but it is a bit more work to get going. The benefit is
>>you don¹t have to build rpm or even jar - just run locally. Debugging
>>becomes inline and can recompile while the server is running. Easy.
>>
>> * Install Vagrant only for use with Ambari¹s agents. This is because
>>the agent code is pretty specific to directory locations and linux
>>commands, etc.
>> * Run Ambari Server locally out of an IDE
>> * * This requires setting up your local machine with Postgres
>> * * Setting several values in ambari.properties to reference local
>>directories instead of deployed locations. I have attached the one I
>>use, replace SRC_HOME and ETC_HOME appropriately. (May have some
>>deprecated properties, I don¹t update it often).
>> * * Setting database values in the properties file to reference local
>>filesystem.
>> * * When using an IDE, when you start Ambari, add a directory to the
>>classpath that has the ETC_HOME directory.
>> * Have the ability to copy agent python files to vagrant. I have
>>several helper scripts to do this with mapped directories.
>> * Successfully build ambari-web locally. UI folks use brunch to ease
>>development, for backend it¹s enough to build maven.
>> * Successfully build ambari-views.
>> * When the UI is loading and installing a clusters, agents should
>>registered manually, not bootstrapped. (openssl directory assumptions
>>don¹t match up for me and it was just painful)
>>
>> I¹m not sure if this has ever been documented. If you choose to go
>>this route and don¹t find any documentation we can get a wiki started
>>for ³local development.² To my knowledge only a few have done it this
>>way. You can PM me at ncole@apache.org<ma...@apache.org> to work
>>through any issues you see or setup a hangout to discuss.
>>
>> Thanks,
>> Nate
>>
>
Re: Dev workflow
Posted by Nate Cole <nc...@hortonworks.com>.
Aplogies for the delayed response.
When you say it “didn’t seem to run very well” - can you describe the issues you saw? The wiki page seems pretty complete on the prerequisites required to setup the dev environment. Outside that, the properties that i pasted earlier should help point you in the right direction.
If you have specific problems running please let me know and I can see if I can provide the workaround.
Thanks
> On Jun 26, 2015, at 5:40 PM, Halterman, Jonathan <jo...@hp.com> wrote:
>
> Hi Nate - thanks a lot for the response.
>
> I guess the peculiar thing for a newcomer to Ambari is that running the server seems to involve the same process, whether you’re a developer hacking on source or an end user installing from a deb/apt package. This is to say, that running the server generally requires installing an apt/deb package. There doesn’t appear to be a straightforward way to just clone the source and start the thing, as is typical, even with the basic dependencies like Postgres in place.
>
> So that all said, what’s the process for running locally? I actually tried this previously (on OS X) using some pointers and properties from Jonathan Hurley, but the server just didn’t seem to run very well, and I got the sense that despite using platform independent technologies, that this project just wasn’t really setup to run outside of a platform specific deb/apt install. I’d love to run locally though, and to help enhance things in that area. But to start, do you have any specific pointers/resources you can share towards addressing each of the bullet points you highlighted? If it makes sense to start throwing this stuff on the wiki, please feel free.
>
> Cheers,
> Jonathan
>
> From: Nate Cole <nc...@hortonworks.com>>
> Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
> Date: Friday, June 26, 2015 at 6:18 AM
> To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
> Subject: Re: Dev workflow
>
> Other’s have commented; I personally have development working locally with Eclipse, but it is a bit more work to get going. The benefit is you don’t have to build rpm or even jar - just run locally. Debugging becomes inline and can recompile while the server is running. Easy.
>
> * Install Vagrant only for use with Ambari’s agents. This is because the agent code is pretty specific to directory locations and linux commands, etc.
> * Run Ambari Server locally out of an IDE
> * * This requires setting up your local machine with Postgres
> * * Setting several values in ambari.properties to reference local directories instead of deployed locations. I have attached the one I use, replace SRC_HOME and ETC_HOME appropriately. (May have some deprecated properties, I don’t update it often).
> * * Setting database values in the properties file to reference local filesystem.
> * * When using an IDE, when you start Ambari, add a directory to the classpath that has the ETC_HOME directory.
> * Have the ability to copy agent python files to vagrant. I have several helper scripts to do this with mapped directories.
> * Successfully build ambari-web locally. UI folks use brunch to ease development, for backend it’s enough to build maven.
> * Successfully build ambari-views.
> * When the UI is loading and installing a clusters, agents should registered manually, not bootstrapped. (openssl directory assumptions don’t match up for me and it was just painful)
>
> I’m not sure if this has ever been documented. If you choose to go this route and don’t find any documentation we can get a wiki started for “local development.” To my knowledge only a few have done it this way. You can PM me at ncole@apache.org<ma...@apache.org> to work through any issues you see or setup a hangout to discuss.
>
> Thanks,
> Nate
>
Re: Dev workflow
Posted by "Halterman, Jonathan" <jo...@hp.com>.
Hi Nate - thanks a lot for the response.
I guess the peculiar thing for a newcomer to Ambari is that running the server seems to involve the same process, whether you’re a developer hacking on source or an end user installing from a deb/apt package. This is to say, that running the server generally requires installing an apt/deb package. There doesn’t appear to be a straightforward way to just clone the source and start the thing, as is typical, even with the basic dependencies like Postgres in place.
So that all said, what’s the process for running locally? I actually tried this previously (on OS X) using some pointers and properties from Jonathan Hurley, but the server just didn’t seem to run very well, and I got the sense that despite using platform independent technologies, that this project just wasn’t really setup to run outside of a platform specific deb/apt install. I’d love to run locally though, and to help enhance things in that area. But to start, do you have any specific pointers/resources you can share towards addressing each of the bullet points you highlighted? If it makes sense to start throwing this stuff on the wiki, please feel free.
Cheers,
Jonathan
From: Nate Cole <nc...@hortonworks.com>>
Reply-To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Date: Friday, June 26, 2015 at 6:18 AM
To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
Subject: Re: Dev workflow
Other’s have commented; I personally have development working locally with Eclipse, but it is a bit more work to get going. The benefit is you don’t have to build rpm or even jar - just run locally. Debugging becomes inline and can recompile while the server is running. Easy.
* Install Vagrant only for use with Ambari’s agents. This is because the agent code is pretty specific to directory locations and linux commands, etc.
* Run Ambari Server locally out of an IDE
* * This requires setting up your local machine with Postgres
* * Setting several values in ambari.properties to reference local directories instead of deployed locations. I have attached the one I use, replace SRC_HOME and ETC_HOME appropriately. (May have some deprecated properties, I don’t update it often).
* * Setting database values in the properties file to reference local filesystem.
* * When using an IDE, when you start Ambari, add a directory to the classpath that has the ETC_HOME directory.
* Have the ability to copy agent python files to vagrant. I have several helper scripts to do this with mapped directories.
* Successfully build ambari-web locally. UI folks use brunch to ease development, for backend it’s enough to build maven.
* Successfully build ambari-views.
* When the UI is loading and installing a clusters, agents should registered manually, not bootstrapped. (openssl directory assumptions don’t match up for me and it was just painful)
I’m not sure if this has ever been documented. If you choose to go this route and don’t find any documentation we can get a wiki started for “local development.” To my knowledge only a few have done it this way. You can PM me at ncole@apache.org<ma...@apache.org> to work through any issues you see or setup a hangout to discuss.
Thanks,
Nate
Re: Dev workflow
Posted by Nate Cole <nc...@hortonworks.com>.
Other’s have commented; I personally have development working locally with Eclipse, but it is a bit more work to get going. The benefit is you don’t have to build rpm or even jar - just run locally. Debugging becomes inline and can recompile while the server is running. Easy.
* Install Vagrant only for use with Ambari’s agents. This is because the agent code is pretty specific to directory locations and linux commands, etc.
* Run Ambari Server locally out of an IDE
* * This requires setting up your local machine with Postgres
* * Setting several values in ambari.properties to reference local directories instead of deployed locations. I have attached the one I use, replace SRC_HOME and ETC_HOME appropriately. (May have some deprecated properties, I don’t update it often).
* * Setting database values in the properties file to reference local filesystem.
* * When using an IDE, when you start Ambari, add a directory to the classpath that has the ETC_HOME directory.
* Have the ability to copy agent python files to vagrant. I have several helper scripts to do this with mapped directories.
* Successfully build ambari-web locally. UI folks use brunch to ease development, for backend it’s enough to build maven.
* Successfully build ambari-views.
* When the UI is loading and installing a clusters, agents should registered manually, not bootstrapped. (openssl directory assumptions don’t match up for me and it was just painful)
I’m not sure if this has ever been documented. If you choose to go this route and don’t find any documentation we can get a wiki started for “local development.” To my knowledge only a few have done it this way. You can PM me at ncole@apache.org<ma...@apache.org> to work through any issues you see or setup a hangout to discuss.
Thanks,
Nate
Re: Dev workflow
Posted by Donald Hansen <do...@hansenfamily.us>.
I started doing some POC work for my company using Ambari a couple months
ago. I follow a similar approach as Sumit for the most part. The one
exception is with UI changes. I have a linked folder to my UI code and use
"brunch w" to update the UI code when I make changes. Basically what is
under "Frontend Development" on this page
https://cwiki.apache.org/confluence/display/AMBARI/Quick+Start+Guide
On Thursday, June 25, 2015, Sumit Mohanty <sm...@hortonworks.com> wrote:
> 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 <jonathan.halterman@hp.com <javascript:;>>
> Sent: Thursday, June 25, 2015 11:53 AM
> To: dev@ambari.apache.org <javascript:;>
> 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 <jonathan.halterman@hp.com
> <javascript:;><mailto:jonathan.halterman@hp.com <javascript:;>>>
> Date: Thursday, June 25, 2015 at 11:14 AM
> To: "dev@ambari.apache.org <javascript:;><mailto:dev@ambari.apache.org
> <javascript:;>>" <dev@ambari.apache.org <javascript:;><mailto:
> dev@ambari.apache.org <javascript:;>>>
> 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
>
Re: Dev workflow
Posted by "Halterman, Jonathan" <jo...@hp.com>.
Thanks for the response Sumit. Just to clarify your workflow: So you edit
code either locally (or directly on a VM?), rebuild jar(s) after each code
change, copy jars if necessary, and restart a server to test?
- jonathan
On 6/25/15, 6:36 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>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 <jo...@hp.com>
>Sent: Thursday, June 25, 2015 11:53 AM
>To: dev@ambari.apache.org
>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
><jo...@hp.com>>
>Date: Thursday, June 25, 2015 at 11:14 AM
>To: "dev@ambari.apache.org<ma...@ambari.apache.org>"
><de...@ambari.apache.org>>
>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
Re: Dev workflow
Posted by Sumit Mohanty <sm...@hortonworks.com>.
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 <jo...@hp.com>
Sent: Thursday, June 25, 2015 11:53 AM
To: dev@ambari.apache.org
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 <jo...@hp.com>>
Date: Thursday, June 25, 2015 at 11:14 AM
To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
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
Re: Dev workflow
Posted by "Halterman, Jonathan" <jo...@hp.com>.
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.
- jonathan
From: <Halterman>, Jonathan Halterman <jo...@hp.com>>
Date: Thursday, June 25, 2015 at 11:14 AM
To: "dev@ambari.apache.org<ma...@ambari.apache.org>" <de...@ambari.apache.org>>
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?
* Do you run ambari-server for development on your local machine?
* Do you run ambari-server in a VM or container? If so:
* Do you use synced folders or shared volumes?
* If so, what kind of synced folders (vagrant, nfs, rsync)?
* Are you able to successfully build ambari when using synced folders?
* Are you able to successfully build an rpm/deb when using synced folders?
* If you don’t use synced folders, what’s your workflow for testing code?
* Does the ambari apt/deb package need to be installed in order to start ambari-server for development purposes?
* How do you start ambari-server for development purposes (with the ability to attach a debugger)?
Cheers,
Jonathan