Serverless

[cplee]

This PR is intended to start a discussion about what to do with the serverless work. I'm proposing these changes to allow the serverless codepipeline to trigger directly off changes in dromedary and not need the dromedary-serverless project to create the lambda. The dromedary-serverless project would still exist to hold the CFN and pipeline lambdas. I see 3 options...I'd appreciate feedback on the options before proceeding with this PR:

1. Reject this PR...require ALL serverless work to be done in the dromedary-serverless repo, but then the pipeline won't be able to trigger off changes in this repo.
2. Approve this PR...and keep the CFN/lambdas in the dromedary-serverless repo. Benefit is that there is still only one dromdeary. Downside is the infrastructure code is separate from the app code.
3. Approve this PR..and merge more. Either pull in the the CFN/lambdas as a subdirectory of the dromedary repo, or fork dromedary and merge the stuff in dromedary-serverless into the fork and remove the "non-serverless" CFN from the fork. Benefit would be it would be clearer and simpler. Downside is now we have a fork of dromedary.

This PR includes a couple changes to allow the dromedary app to integrate with codepipeline and run as a lambda. These changes will not be used when deployed with the CFN included in this project, but rather will be driven from the dromedary-serverless CFN:

• gulp tasks to integrate with a serverless codepipeline
• index.js to allow deployment as a lambda

Additionally, a few changes where made to the test cases to remove need for urllib-sync which was causing issues running from within a lambda. Reverted back to async requests wrapped with promises:

• revise tests to use promises and async calls
• Add nocache option to /data to aid in functional testing when multiple instances are running

[PaulDuvall]

@cplee This might be a longer-term view, but ideally I think I’d like to see if we can make a repo just for the dromedary app itself (charthandler, etc.) and associated resources (tests, etc.), a repo for the traditional infrastructure that's not necessarily app related and a repo for the serverless infrastructure that uses the app repo and any necessary resources from the infrastructure repo. Is this too ambitious? Not entirely sure how to handle the question of the dromedary app specific stuff in Chef and other tools?

[cplee]

@PaulDuvall: that lines up with option 2 with the addition of pulling out the traditional infrastructure out into it's own repo. Doesn't sound too ambitious, but I see the point about untangling some of the gulp tasks that deploy into the chef cookbook.

So for now, it seems it would be OK to proceed with this PR, but I'd like to keep it open for a bit longer to give others( @erickascic, @cndudley, @NickDeClario ) who are active in dromedary a chance to review.

[cplee]

Sorry about all the blue commits above...that's from the talk I did for AWS meetup. I haven't heard any feedback so I assume this PR is ready to merge

[PaulDuvall]

I haven't heard any feedback so I assume this PR is ready to merge

Yes, we'll have to assume this.

Also, @jeffb-stell extracted all the pipeline code into a separate repo and updated the consec branch (which should just be treated as its own repo rather than a branch - as was inevitable with such a long-lived branch). This modification did not affect master so I'll work to update the dromedary to use the pipelines repo. This will likely likely require some updates to the pipelines repo first since I believe it's a month off of master. All that said, I'll merge this PR.