You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "uberspot (via GitHub)" <gi...@apache.org> on 2023/05/30 10:22:35 UTC

[GitHub] [couchdb-helm] uberspot opened a new pull request, #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

uberspot opened a new pull request, #120:
URL: https://github.com/apache/couchdb-helm/pull/120

   outside of the helm-chart for consistency and to prevent accidental deletions by helm.
   
   #### What this PR does / why we need it:
   
   Currently the chart manages the PVCs for the statefulset. Which means any re-installation of the chart will result in data loss unless snapshots/backups have been taken beforehand. 
   This PR allows for opting out of that behavior and managing the PVCs separately from the chart.
   Anyone setting selfManaged: true will have to have taken a backup of the data before hand OR have modified the owner annotations on the PV/PVC resources to prevent their deletion.
   
   [Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.
   - [x] Chart Version bumped
   - [x] e2e tests pass
   - [x] Variables are documented in the README.md
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] yekibud commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "yekibud (via GitHub)" <gi...@apache.org>.
yekibud commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1601794644

   > Most k8s environments would instead just have the user create a PVC themselves, PVs get generated from the CSI driver and the only thing this chart needs as input is the name of the PVC so it knows what to mount on the volume. It shouldn't need to manage PV or PVC objects if you want to use existing Claims.
   
   You mean from a parent chart?  You would still have to template out the PV and PVC and specify an existing `volumeID`, etc. if you wanted to use an existing claim like from a backup/snapshot, wouldn't you?  The current implementation allows you to do everything by simply providing values, which seems preferable to me, but I can't say if that represents "most k8s environments", so defer to others and the maintainers to weigh in.  Your changes are pretty minor and straight forward, so probably fine to support both approaches, I suppose.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] yekibud commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "yekibud (via GitHub)" <gi...@apache.org>.
yekibud commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1600997042

   How is this different from what `persistentVolume.existingClaims` provides?  


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] clayvan commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "clayvan (via GitHub)" <gi...@apache.org>.
clayvan commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1726758930

   For what it's worth @yekibud I do think `existingClaims` supports most use cases, but I would agree its unintuitive to use as you have to dig through the templates to understand how to use it. At the very least it would be nice to see what an example `existingClaims` value would look like. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] uberspot commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "uberspot (via GitHub)" <gi...@apache.org>.
uberspot commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1611278419

   Anyone who could review this? :) 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] uberspot commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "uberspot (via GitHub)" <gi...@apache.org>.
uberspot commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1601143950

   Existing claims requires you to provide a ton of information for the actual PV objects and then tries to template them out. I tried using that and it was unnecessarily complex and unintuitive. 
   Most k8s environments would instead just have the user create a PVC themselves, PVs get generated from the CSI driver and the only thing this chart needs as input is the name of the PVC so it knows what to mount on the volume. It shouldn't need to manage PV or PVC objects if you want to use existing Claims. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] willholley commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "willholley (via GitHub)" <gi...@apache.org>.
willholley commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1623463034

   @uberspot the linter picked up a couple of trailing spaces. If you can address the errors and rebase (you'll need to bump the chart version), I'll get this merged.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [couchdb-helm] uberspot commented on pull request #120: Add .Values.persistentVolume.selfManaged so PVCs can be managed

Posted by "uberspot (via GitHub)" <gi...@apache.org>.
uberspot commented on PR #120:
URL: https://github.com/apache/couchdb-helm/pull/120#issuecomment-1602157765

   > 
   
   Yeah I'm talking about manually created PVCs that then generate PVs themselves. That's how the Trident CSI works for example https://github.com/NetApp/trident  
   All you need in that case is a self-declared PVC object. And this chart then only needs a pvc name so it can use it as a volume. That's the minimum needed input in that case. 👍 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org