Skip to content

Update pvc.yaml #39

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.

Sign up for GitHub

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

Open
Aijazkhan123 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update pvc.yaml #39

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions Kubernetes-Manifests-file/Database/pvc.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,10 @@ kind: PersistentVolumeClaim
metadata:
name: mongo-volume-claim
namespace: three-tier
spec:
accessModes:
spec:
accessModes:
- ReadWriteOnce
storageClassName: ""
storageClassName: gp2
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Critical: storageClassName mismatch will prevent PVC binding.

Changing storageClassName from "" to gp2 breaks the binding with the existing PV mongo-pv in Kubernetes-Manifests-file/Database/pv.yaml, which has no storageClassName field (defaults to "").

Impact:

  • If the cluster has a gp2 StorageClass (e.g., AWS EKS), a new EBS volume will be dynamically provisioned, orphaning the existing hostPath PV and potentially losing data.
  • If the cluster lacks a gp2 StorageClass, the PVC will remain Pending indefinitely, and the MongoDB pod will fail to start.

Recommended fixes:

Option 1: Revert to match the existing PV 
-  storageClassName: gp2
+  storageClassName: ""
Option 2: Update the PV to use gp2 (if AWS EKS is the target)

If the intent is to use AWS EBS volumes, update Kubernetes-Manifests-file/Database/pv.yaml to remove the hostPath PV or add storageClassName: gp2 and switch from hostPath to dynamic provisioning. However, note that manually creating a PV with gp2 is unusual—dynamic provisioning is the standard approach for EBS.

# In pv.yaml - but consider removing this PV entirely for dynamic provisioning
 spec:
   capacity: 
     storage: 1Gi
+  storageClassName: gp2
   volumeMode: Filesystem
   accessModes:
     - ReadWriteOnce
-  hostPath:
-    path: /data/db
+  awsElasticBlockStore:
+    volumeID: <your-ebs-volume-id>
+    fsType: ext4
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
storageClassName: gp2
storageClassName: ""
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@Kubernetes-Manifests-file/Database/pvc.yaml` at line 9, The PVC's
storageClassName was changed to "gp2" which prevents binding to the existing PV
"mongo-pv" (which has no storageClassName/defaults to ""), so either revert the
PVC's storageClassName to empty/remove the storageClassName field in
Kubernetes-Manifests-file/Database/pvc.yaml to match the PV, or if you intend to
use AWS EBS, update the PV "mongo-pv" in
Kubernetes-Manifests-file/Database/pv.yaml to use storageClassName: gp2 and
replace the hostPath PV with a dynamically provisioned PV (or remove the static
PV and rely on dynamic provisioning) so PVC and PV storageClassName values
match.

resources:
requests:
storage: 1Gi
storage: 1Gi