New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ansible playbooks for deploying each of the providers #2622

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@abaruni
Contributor

abaruni commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@abaruni

abaruni Aug 16, 2017

Contributor
Contributor

abaruni commented Aug 16, 2017

@csantanapr csantanapr added the wip label Aug 16, 2017

@jasonpet

This comment has been minimized.

Show comment
Hide comment
@jasonpet

jasonpet Aug 16, 2017

Contributor

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.

Contributor

jasonpet commented Aug 16, 2017

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 comment has been minimized.

Show comment
Hide comment
@csantanapr

csantanapr Aug 16, 2017

Contributor

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

Contributor

csantanapr commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rabbah

rabbah Aug 16, 2017

Member

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.
Member

rabbah commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rabbah

rabbah Aug 16, 2017

Member

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.

Member

rabbah commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasonpet

jasonpet Aug 16, 2017

Contributor

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.

Contributor

jasonpet commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasonpet

jasonpet Aug 16, 2017

Contributor

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

Contributor

jasonpet commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasonpet

jasonpet Aug 16, 2017

Contributor

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.

Contributor

jasonpet commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@csantanapr

csantanapr Feb 28, 2018

Contributor

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

Contributor

csantanapr commented Feb 28, 2018

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

@csantanapr csantanapr closed this Feb 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment