7 results found

1. Allow the Kubernetes Operator to delete a project

   Currently it is not possible to delete a project via kubectl command.

   As the Kubernetes Operator allows one to create a project (configmap) and deploy a replica set, we would expect it to also allow the deletion of a project so that we can fully automate the solution.

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminDan (Admin, MongoDB) responded

   While deletion of a deployment is possible via Kubernetes, deleting a MongoDB resource doesn’t remove it from the Ops Manager UI. You must remove the resource from Ops Manager manually. To learn more, see Remove a Process from Monitoring.

   
   

   Deleting a MongoDB resource for which you enabled backup doesn’t delete the resource’s snapshots. You must delete snapshots in Ops Manager.

   
   

   Find out more.

   
   

   Work is planned to remove Ops Manager as a prerequisite (though it's use will still be optional and supported) and as part of that we hope to address this deletion aspect.

2. Add support to convert a replica set to a sharded cluster in Kubernetes

   Currently it is not possible to use Ops Manager UI or Kubernetes Operator to convert Replica Set to Sharded cluster. Error : changed not allowed.

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminDan (Admin, MongoDB) responded

   Planned - we have a requirement to have this completed in time for MongoDB 9.0. But no timeline (yet) for delivering this within that timeframe. 

3. Use separate tls.crt and tls.key items in a kubernetes secret for certificates instead of a combined item named server.pem for a MondoDB rep

   There should be a way to use separate tls.crt and tls.key items in a kubernetes secret for certificates instead of a combined item named server.pem.

   We request our certs using cert-manager which generates secrets from the cert CRD and will get auto renewed every so often. These secrets have 2 items, tls.crt and tls.key.

   So far the only way I have seen to enable tls is to combine these 2 items and rename it into a new secret in kubernetes as item called server.pem. This however means that when a cert auto renews that the wrong secret is being used. So our replicaSets would break on each renewal (every 90 days).

   If some flexibility was built in on how to provide certificates to the replicaSet, there would be no issue and auto renewing our certs would not break MongoDB in production every 90 days.

   There should be a way to use separate tls.crt and tls.key items in a kubernetes secret for certificates instead of a combined item named server.pem.

   We request our certs using cert-manager which generates secrets from the cert CRD and will get auto renewed every so often. These secrets have 2 items, tls.crt and tls.key.

   So far the only way I have seen to enable tls is to combine these 2 items and rename it into a new secret in kubernetes as item called server.pem. This however means that when a cert auto renews that the wrong secret… more

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  Andrey responded

   Support for Cert Manager as well as support for separate crt and key is on a roadmap.
   We will look into updating our docs to describe cert rotation.

4. sharding

   Should provide sharding feature in community Operator.

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   planned  ·  2 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Allow to pin specific MongoDB Agent version to be used

   What is the problem that needs to be solved? In some rare situations where upgrade of Cloud Manager's MongoDB Agent to the latest version leads to Golang panic (or any other critical issue) there's no way for Cloud Manager user to rollback MongoDB Agent version in case if this environment is running in Kubernetes Operator. The script which launch MongoDB Agent is using the latest version from Cloud Manager Project, without any option to change it other then editing the script itself which is not possible in Kubernetes pod.

   Why is it a problem? (the pain) If after Cloud Manager's MongoDB Agent upgrade there are some critical issues (constant Golang panic, etc.) the user will be stuck awaiting MongoDB to rollback MongoDB Agent version in required Cloud Manager Project.

   What is the problem that needs to be solved? In some rare situations where upgrade of Cloud Manager's MongoDB Agent to the latest version leads to Golang panic (or any other critical issue) there's no way for Cloud Manager user to rollback MongoDB Agent version in case if this environment is running in Kubernetes Operator. The script which launch MongoDB Agent is using the latest version from Cloud Manager Project, without any option to change it other then editing the script itself which is not possible in Kubernetes pod.

   Why is it a problem? (the pain) If after Cloud Manager's… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminDan (Admin, MongoDB) responded

   We're currently planning work to avoid pulling mongod and the agent from Ops Manager. This is expected to give the ability to manually control the version of the agent in use.

6. Separeted mongod and mongodb agent in Kubernetes Operator container

   Now both mongod and agent Ops Manager are running in the mongodb-enterprise-database container. Sometimes it becomes necessary to restart the agent separately from the mongodb instance. Now this is impossible to do because systemd does not work in containers

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminDan (Admin, MongoDB) responded

   We have plans to have the two run separately! Though no firm timeline yet, we're hoping this year.

   
   

   Right now we have two architectures. The default is a single container that pulls the binaries for the agent and MongoDB server (mongod) from Ops Manager/Cloud Manager. The other is in Private Preview (potential for breaking changes still) and is known as our Static Architecture.

   
   

   Neither actually runs each in their own containers, and we're hoping to alter the static architecture to make that the case before we release it fully and make it the default.

   
   

   Aside from restarting one and not the other, this would offer a more intuitive setup when configuring and troubleshooting, and align to a very future proof definition of what "static" means - where security tools are converging on blocking any significant changes to a container between the image and runtime.

7. There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

   There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

   Looking at closed issues, one may get an idea that this operation is impossible, but with the latest CSI it should be - it requires some handcrafting. On the other side Enterprise operator has this covered here - https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/. I suggest writing similar how-to for the Community operator.
   My currently tested workflow for volume expansion is similar to this explained on the page above, but as for my knowledge Community operator doesn't allow this operation - as it will recreate StatefulSet when you delete, and there's no way for pause reconciliation of MongoDBCommunity. So it requires you to scale down operator deployment for the time of expansion.

   So it looks like this:
   1. Scale down mongodb-kubernetes-operator to 0
   2. Dump current mongodb StatefulSet specs to file
   3. Delete StatefulSet leaving pods (--cascade=orphan)
   4. Modify saved StatefulSet specs in the file and update volumeClaimTemplates to match your new size requirements

   And here it splits, as I'm using Longhorn, and it needs some time to detach and resize the volume. Because of that, using rollout - as described on the Enterprise operator hasn't worked. So for possibly any other CSI plugin, you should continue as described on the page:

   1. Patch PVCs with the new size
   2. Re-create StatefulSet with new specs for volumeClaimTemplates
   3. Rollout restart StatefulSet

   But in my case, it was like this:

   1. Delete one pod (secondary RS members first, primary last - as usual)
   2. Wait for PV to be in a detached state
   3. Patch PVC
   4. Wait for PV to resize
   5. Re-create StatefulSet with new specs for volumeClaimTemplates
   6. Wait for it to reconcile
   7. Delete StatefulSet, leaving pods again
   8. Repeat the above steps for any other pods in your StatefulSet

   And finally, make changes to MongoDBCommunity specs to match those in the manually created StatefulSet and scale-up operator.

   There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

   Looking at closed issues, one may get an idea that this operation is impossible, but with the latest CSI it should be - it requires some handcrafting. On the other side Enterprise operator has this covered here - https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/. I suggest writing similar how-to for the Community operator.
   My currently tested workflow for volume expansion is similar to this explained on the page above, but as for my knowledge Community operator doesn't allow this operation - as… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminDan (Admin, MongoDB) responded

   Planned - no fixed date but likely complete within Q2.