Skip to content
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

[DM-19745] Single machine deployment of the DM-EFD using k3s ("kubes") #20

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@afausti
Copy link
Member

commented May 14, 2019

  • Assume the cluster already exists and use config_path to connect to the cluster
  • Specify the storage class to be used to create persistent volumes

afausti added some commits May 14, 2019

Assume the cluster already exists
- Remove the gke cluster creation
- Assume a cluster already exists and use config_path to connect to it
- This is a first step to separate the cluster creation from the
application deployment
Specify storage class and influxdb disk size
- Add variable to specify the storage class to be used for all persistent volumes.
- For k3s deployment use the 'local-path' storage class
- Add variable to specify the influxdb disk size.
@jhoblitt
Copy link
Member

left a comment

I don't think we can merge the gke module removal this into master as it would break the production efd-kafka instance on gke. It would actually cause the gke cluster to be deleted. Everything other than that and the config_path param should be mergable... maybe everything else can go onto an integration branch?

I think the best path forward might be to remove the gke setup from this mod and create another "top level" module that handles a gke cluster plus the deployment using a refactored version of this module. What do you think?

@afausti

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

Sounds good. My plan is to keep the changes on this branch until I get a working DM-EFD on k3s. Then I will include a terraform module that automates the k3s cluster creation. And if we work on a separate module to create the gke cluster we can test the whole deployment on both before merging.

@jhoblitt

This comment has been minimized.

Copy link
Member

commented May 14, 2019

You may also want to consider rebasing on master before branching to pickup the prometheus improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.