ansible playbooks for deploying each of the providers

[abaruni]

No description provided.

[rabbah]

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.

[abaruni]

cc @jasonpet

[jasonpet]

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.

[csantanapr]

This integration would be same as we have today for catalog.
catalog doesn't get deploy as part of default openwhisk.yml playbook
But catalog get's deploy using ansible bits from main repo.

I will mark this PR as wip since I don't want to merge it in this repo until there is CI test and integration in the individual repos for alarm, cloudant, and kafka so we know how the final version will look like for this ansible work here.

The CI will look similar as catalog:

• pull down openwhisk from master
• deploy local repo content (package and container) using ansible from openwhisk core
• run tests from local repo content

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

[rabbah]

questions:

1. Is there a hidden circular dependence like we had with the cli repo?
2. Are we now forcing every deployment of openwhisk to deploy the providers?
3. Does this belong in the dev tool repo instead.

[rabbah]

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.

[jasonpet]

Answer to number 1 and 2 is no. Providers depend on this repo, but this repo has no dependency on them. A separate playbook would have to be run to deploy providers. Number 3 is definitely something that should be further discussed.

[jasonpet]

The only reason it was put here was to reuse the ansible infrastructure. I guess we could duplicate some of this and put it in the dev tool repo. I am not at all familiar with the dev tool repo

[jasonpet]

Using the dev tools repo would create another dependency for the provider repos though. They already have a dependency on this one for the test utils.

[csantanapr]

I think we are going to wait on doing this and do it the kube way, closing for now