Skip to content

Ops Tools

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

45 results found

  1. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Migration Guide for OpsManager to enterprise-operator

    It would be great to have a migration guide or documentation to help with migrating an existing OpsManager installation to the kubernetes enterprise-operator based installation.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. Add ability to create user credentials in different namespace then mongo cluster

    As the title states. I am creating my mongo cluster in a different namespace then my application, however because k8s does not allow sharing secrets between namespaces it is impossible to access the credentials.

    I suggest adding a namespace field inside of the users definition to allow the creation of the secret in another namespace.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. MongoDB kubernetes operator - follow recommended kubernetes object labeling -

    Hi, i would like to thank you first for this operator, good job 👍 . It works well.

    Did you consider using this label convention for objects (statefulset, svc, secrets) https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/?

    Currently in my cluster Im trying to follow these recommended labels for objects while Im forwarding kubernetes logs using EFK but cannot store log to elasticsearch because there is object mapping for kubernetes.labels.app field as object not a concrete value. Right now there is hard-coded service selector https://github.com/mongodb/mongodb-kubernetes-operator/blob/1aa7093d2cc977bc3b1f5a5fa7e1e902d37768c8/controllers/replica_set_controller.go#L455 which expects pods to be labeled with app=<serviceName>

    Example labels following conventions for statefulset:

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      labels:
    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Add ability to configure Pod Distruption Budget for STS

    During maintenance work EKS admins may need to evict nodes. This should not cause outage for MongoDB cluster/replicaset running on these nodes. we can create manually PDB for STS, but it would be nice to have an option to do it as part of MongoDB Kubernetes Operator.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. MongoDB Operator Deployment Env Variables Push Down

    This is a feature request to have custom environment variables, configured in the MongoDB Operator's Deployment manifest, push down or propagate to all resources created by the Operator.

    For example, it may be desired to add environment variables with context. A more specific example could include setting a TZ timezone environment variable that is automatically added to all pod containers created by the Operator.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. 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…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    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.

  8. Allow service spec changes via MongoDBCommunity CR

    I aim to include extra sidecar containers, such as a metrics sidecar, allowing me to deploy an external metrics exporter alongside that would be scraped via service. I intend to configure annotations on the service for Prometheus automatic discovery, enabling the scraping of metrics and exposing the exporter container at the service level, similar to the one exposed when prometheus integration is enabled.

    Updating the service spec is not currently possible, and as result, a lot of manual steps are required, like creating a custom service for each cluster, which points to the sidecar container with the required annotations in…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Add comprehensive configuration options for persistent volumes

    From a project point of view, we need additional configuration options for persistent volumes. For instance, as far as we know, each MongoDB Deployment that uses a persistent volume is configured with Access Mode ReadWriteOnce per default. We need to customise this option for optimal usage. For configuration options would be a plus.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Add options to the connection string through the MongoDBUser

    We would like to add options to the connection string that is generated by the operator when creating a new MongoDBUser.
    The idea is to include these options in the MongoDBUser CRD so the operator can then add them to the connectionString stored in the generated secret.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. Add a variable for set the RS name

    Add own variable to set the RS name so that the deployment name can be used to name the pod

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. Enable external-dns integration via per-service annotations on each generated service

    Currently the MongoDB Kubernetes Operator allows specification of annotations on services created by the operator, but only annotations with the same value across all services. The external-dns operator can create DNS names based on annotations on services. In order to support external-dns integration the MongoDB Kubernetes Operator would need to allow one to specify specific annotations for each generated service.

    Current spec for external access services:
    externalAccess:
    externalService:
    annotations:
    # Same annotations will be applied on all services

    You could consider a placeholder/substitution scheme like:
    externalAccess:
    externalService:
    annotations:
    external-dns.alpha.kubernetes.io/hostname: mydb-db-<instance number>.mydns.com

    Or some other way of assigning a per-service annotation…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. Allow configuration of alerts (and setting customer alerts) via enterprise operator

    It would be nice to be able to configure an environments alerts directly from the Operator which will be deploying that environment.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. Timeline on Server internal authentication via Keyfile

    Hi Operator team,

    The K8s operator community edition README mentions the feature Server internal authentication via keyfile is in progress. My team is hoping to use this feature on our current project and wanted to ask what the timeline is for this. Is it likely to be included in the next release, and if so when is that release? Thanks!

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. EmptyDir as data-volume and log-volume

    spec:
    members: 1
    type: ReplicaSet
    version: "4.4.5"
    statefulSet:
    spec:
    template:
    spec:
    volumes:
    - name: data-volume
    emptyDir: {}
    - name: log-volume
    emptyDir: {}

    This type of override would be very helpful for automated testing pipelines - pipeline should spin up single mongodb instance, populates data and proceed with application testing. For that, we don't need persistent volumes, we need clear folder on each invocation.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. Support Service Binding Specification for Kubernetes

    Service Binding Specification for Kubernetes standardizes exposing backing service secrets to applications. The spec is available here: https://github.com/servicebinding/spec

    This blog post would be helpful: https://muthukadan.net/kubernetes/binding/support-service-binding-specification-for-kubernetes/

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. Enable S3 Snapshot Storage via Kubernetes Operator with IAM role

    Configuring an S3 Snapshot Storage with IAM roles is only possible via Ops Manager UI or API.

    It would be great to be able to do this configuration via the MongoDB Kubernetes Operator.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Provide support to update version manifest to Ops Manager that uses local mode

    With Ops Manager Local Mode on Kubernetes, the version manifest is required to be updated manually via UI or API.

    It would be the best practice to support updating version manifest using a command to the Operator or OM Pods.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. Add ability to have systemLog redirected to stdout (just have to remove systemLog.destination and path)

    To be able to have MongoDB logs redirect to stdout and this having it into GKE CloudLogs, we should NOT configure a systemLog.destination nor a systemLog.path.

    In 0.6.0 release, systemLog.destination and path are hardcoded and cannot be nullable.

    see automationconfigbuilder.go at line 208:

    ...
    process.SetSystemLog(SystemLog{
    Destination: "file",
    Path: path.Join(DefaultAgentLogPath, "/mongodb.log"),
    })
    ...

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?

Feedback and Knowledge Base