Ops Tools
441 results found
-
Ops Manager: more precise firewall configuration documentation
Currently, it is not clear from the documentation what are the source hosts for each port to open. The diagram fills in a bit this imprecision, but it is not formal enough. Also, some ports need to be open only if certain features are needed (eg. download link for snapshots).
This makes firewall configuration imprecise and experimental (or not as secure as it could be).
Suggestion: each table of the the Ops Manager firewall configuration webpage should document those columns:
- source component: client component(s)
- target component: server component(s)
- protocol: tcp/udp
- port
- feature: to specify if…1 vote -
Ops Manager API call for Host Mappings
This feature request is for a new Group/Project API call for the management of the host mappings created in Ops Manager from monitoring information. Whether it be an endpoint for "Reset Duplicates" or full featured create/delete of individual host mappings, both will alleviate issues where overlapping mappings affect monitoring in Ops Manager.
Note: The issue of overlapping mappings may occur when a mongod process has moved/changed IP addresses multiple times. With enough cycling (as seen in Kubernetes clusters with frequent pod restarts), eventually a previously mapped IP address may now be associated with a different mongod process.
12 votes -
Allow to generate/download MongoDB Server Audit process logs
Problem Statement,
What is the problem? As of now (2021-03-17) Ops Manager does not support downloading MongoDB Server Audit process logs via UI/API. Atlas does have support for it (viaGET /groups/{GROUP-ID}/clusters/{HOSTNAME}/logs/{LOG-NAME}
API call).Why is this a problem? Users needs to be able to download MongoDB Server Audit process logs via Ops Manager, same way as they do for MongoDB Server process logs/FTDC and MongoDB Agent logs (this significantly simplify troubleshooting, when required). Some users require to download MongoDB Server Audit process logs programmatically to store them in Security Information and Event Management (SIEM) system.
Proposal,
* Add MongoDB…4 votes -
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 voteLow customer demand. Potentially in the future if we hear sufficient demand.
-
Do not download EOL releases
Currently our Ops Mgrs keep re-downloading EOL releases of mongodb, e.g. mongodb-linux-x8664-2.6.12, mongodb-linux-x8664-3.0.15, etc. Ops Manager should automatically exclude EOL releases - they are taking up unnecessary disk space.
12 votes -
Automated rotation of the Keyfile
Hello,
I have an idea about the Keyfile rotation. So actually you can rotate the Keyfile only through the ops manager manually. But I would recommend to do this automatically with an API. This would help us alot since we have alot of mongoDB instances and this would save alot of time.
2 votes -
Supported Ansible module for MongoDB
Supported Ansible modules for MongoDB. Maybe a module for self managed and Atlas.
7 votes -
Display the feature compatibility version (FCV) in Cloud Manager/Ops Manager UI
The FCV could be different than the MongoDB version. Also, sometime the FCV on different shards/CSRS in a sharded cluster might be different (e.g. FCV is upgraded on the shards, but for some reason FCV is not upgraded on the CSRS), and this could cause issues.
It would be nice if FCV is displayed next to the MongoDB version information. So that we can spot out the discrepancy quickly.
1 vote -
Add MongoDB user discovery via the API
For users running DBaaS MongoDB products powered by Ops Manager automation, it would be useful if the API provided a way to replicate the cluster import behavior where MongoDB users are automatically discovered. This would help in scenarios where an existing Ops Manager deployment fails, and hundreds of deployments need to be moved to a different Ops Manager without knowing what MongoDB credentials the end user of that deployment had created. Having this API would allow the DBaaS provider's own scripting/automation to orchestrate moving these deployments to a new Ops Manager stack with reduced downtime.
2 votes -
Allow scheduling grooms
Add the ability to schedule groom jobs at a specific point in time. Also expose this functionality through the API for easy modifications through configuration management tools.
7 votes -
Warn if deploying changes will require a rolling restart
When reviewing changes in automation, warn if deploying changes will require a rolling restart.
As an example, look at the documentation for server parameters. Many parameters include the description "You can only set THIS during start-up", but the the warning that setting this parameter necessitates a restart is missing from Ops Manager (or Cloud Manager).
2 votes -
Allow disabling Blockstore for assignment through the Ops Manager CRD
By default, when enabling backups and configuring a Blockstore for an Ops Manager custom object, the specified Blockstore will be set as "Assignment enabled" in the UI.
It would be helpful to expose the enable/disable button for the blockstore through the CRD since disabling it through the UI, results in the parameter being reverted every time the operator consolidates. This is useful for the case when more than a single store is configured and as a user you would like to disable the blockstore to make it unavailable for new backup jobs.
3 votes -
Support migrations to different snapshot stores
Currently it is not possible to transition between snapshot store types.
There are two options currently when transitioning to the new one.
- Terminate backups (deleting all previous snapshots)
- Create a new project and abandon the previous one to allow automated restores at a later time
Both of these options are difficult to manage for large deployments. The first option requires you to store the snapshots elsewhere and disallows automated restores. The second option requires many operations and clutters the Ops Manager project list.
Ideally we should be able to transition from any store location/type to any other location/type. One of…
30 votes -
3 votes
-
Add the ability for the backup daemon to download and validate snapshots
In order to test snapshots automatically, create a new job type that allows the Backup Daemon to download the snapshot from the snapshot store, then run validate on each collection.
If any collection fails validation, send an alert to the Backup Admin with the list of corrupted data.
17 votes -
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 -
Update automation config through API without pushing entire config file
For updating any Automation managed parameter, the only method through API is involving pushing the entire Automation config (which is a json file of hundreds lines) with modifications/addition all together.
Even though I just want to update one single value.
Is it a bit dangerous that there may be human mistake when modifying such a large json file. Wrong configuration may be push to the server.
Graceful if there is a feature which allow user to partial update the configuration through API.
Ref Case: 00730243
6 votes -
update monitoring & backup agent credentials via automationConfig API instead of separate API calls
Right now if you want to change the credentials for the monitoring agent or the backup agent, you've got to make separate API calls. Why not make it so that you can specify everything at once in the same automationConfig API PUT?
2 votes -
Allow Ops manager to downgrade FCV
Ops Manager UI (4.0 -4.4) does not allow downgrading of Feature Compatibility Version (FCV), once the FVC has been upgraded to a higher version. Ops Manager automatically
removes the lower version from the supported FCVs once upgrade completes. But the cluster deployment allows downgrading one level using shell commands. This limitation makes it difficult when planning an upgrade as regression process are more difficult.
We are in the process of upgrading the environment from 4.0 to 4.4 (which requires an intermediate upgrade to 4.2.). So the downgrade process is so difficult with Ops Manager UI.1 vote -
Create Ops Manager API endpoint to download mms0.log files
We should expand the Ops Manager API to provide mms0.log downloads the same way we allow mongod deployment log downloads. This will help users with diagnostics when they deploy many Ops Manager instances via the kubernetes operator but do not yet have centralized logging.
3 votes
- Don't see your idea?