Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ansible playbooks for deploying each of the providers #2622
Thanks for this but I'm wondering: Why do we want to centralize these deployments? The providers are each self contained. We have strived to keep the core deployment minimal.
Further without testing these integrations they will rot. And if we test them as part of normal CI they will make the build dramatically longer.
What's the rationale here and should these playbook be consolidated elsewhere (like in devtools for example) instead.
This follows the pattern that was done for openwhisk-catalog. Travis tests inside the provider repos will be using these ansible updates. So to answer the question above, tests will be running regularly that make use of this and they will not affect the build time for this repo since they will be running elsewhere. We can talk further about whether the pattern we had been using is the right one, but I do not want lots of ansible code duplication (environments for example) in many different repos.
This integration would be same as we have today for catalog.
I will mark this PR as
The CI will look similar as catalog:
I agree maybe there is an optimal way to this with ansible but we would also do it for catalog, and push. Right now I don't what's best practice in terms of ansible distributed structure.
I would prefer to make progress and this will allow for individual repos to have CI/Travis integration, and also allow something like vagrant to deploy alarms
There's also a big difference between the catalog which are a couple of handful of actions vs deploying these providers which deploy containers requiring more memory from a vm.
Further if the CI for these playbook are tested separately why put it in this repo at all.