Is the operator ready for production?
fzyzcjy opened this issue · comments
Hi thanks for the database! I wonder whether this operator is ready for production or not?
I think so.
Definitely no. I can't perform a version upgrade in a rolling upgrade fashion without downtime due to operator/agent bugs. Maintainers and the community rarely answer to open issues or fix them. I think you can use it in production at your own risk (in the end is an unsupported operator by DBAtlas).
@marandalucas @tzorzan Thanks for the replies!
@tzorzan So I wonder what do you use in production? Worried about that bug you mentioned
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.
👀
Another vote for "no". Having serious issues with buggy agent/operator functions.
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.
any update on this?
@fzyzcjy moving to percona mongodb operator ...
percona? They claim it is production ready.
@rdxmb Thanks! I know they claim it like that, so just want to know a bit of real user experience, since you know sometimes there are edge cases etc.
just started with it ...
... but seems definitely more stable!
@rdxmb I am just wondering how can we build ours systems with Percona for Mongodb when the code based is [300 commits ahead][45478 commits behind] mongodb:master? And there is not separate documentation, we need to rely on mongodb docs. There is no way to raise an issue and contribute to the code.
Hi, I'm Dan and I'm the product manager for this Operator.
"Production ready" is a subjective term that depends on your needs and whether a bug you find is blocking for you.
But generally yes... we do try to ensure it's production ready. Fixes are slower for it than we'd like - we only have so much time to dedicate to it, and it shares an engineering team with our Enterprise Operator (which is used by paying MongoDB customers). But we try to unblock folks where cost and time available allow.
Having said that, we're trying to establish how much effort the Community Operator (this one) needs - and a big part of that is the survey mentioned in the readme of this repo.
Note
Hi, I'm Dan Mckean 👋 I'm the Product Manager for MongoDB's support of Kubernetes.
The Community Operator is something I inherited when I started, but it doesn't get as much attention from us as we'd like, and we're trying to understand how it's used in order to establish it's future. It will help us establish exactly what level of support we can offer, and what sort of timeframe we aim to provide support in 🙂
Here's a super short survey (it's much easier for us to review all the feedback that way!): https://docs.google.com/forms/d/e/1FAIpQLSfwrwyxBSlUyJ6AmC-eYlgW_3JEdfA48SB2i5--_WpiynMW2w/viewform?usp=sf_link
If you'd rather email me instead: dan.mckean@mongodb.com
We do genuinely care about issue and PRs raised here, so please don't stop raising them if you continue to use the Operator!
@code-uri I think this is very OT for this project here.
when the code based is [300 commits ahead][45478 commits behind] mongodb:master?
What do you mean with code here? The percona images? Or the helm chart? Or the operator? I think it would be best to post the questions in the community of that operator, not here.
And there is not separate documentation
https://docs.percona.com/percona-operator-for-mongodb/index.html
There is no way to raise an issue and contribute to the code.
@rdxmb If I got to Percona for mongodb GitHub repo it is mentioned that it is forked from mongodb when I checked the forked repo i see that the fork is behind mongodb by 45478 commits and 300 commits ahead. meaning the Percona db is deviated from mongodb master code by many commits. how can we know for sure that features in monogdb latest release will work as it expected on Percona for mongodb server?
@dan-mckean Thank you for the information!
@code-uri That does look like a problem, so +1 want to hear from the solutions
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.
Hey all. I'm a product manager at Percona. Here is my take on it:
There are two pieces - Percona Server for MongoDB and Percona Operator for MongoDB.
Percona Server for MongoDB is a 100% compatible alternative to MongoDB Community version. On top of the community version we add various enterprise features and they are 100% free and source available (see feature comparison here).
Percona Operator for MongoDB - it is Percona’s code, not a fork of the MongoDB Operator. We created it from scratch, it is also 100% free, source available and feature rich.
As for production question - both Server and Operator are used in production by lots of community users and customers. There are bunch of case studies on our website.
I’m not sure I understand the diffs question.
when the code based is [300 commits ahead][45478 commits behind] mongodb:master?
What was compared to what?
As you can see we recently released an RC of 7.0 (here), so we are quite up-to-date.
@spron-in Hi, I did try to switch to Percona using helm charts but uninstalling the chart doesn't delete the resources created by it and deleting them manually is quite tedious..and when you're learning to set it up you don't wanna have to manually delete all k8s resources every time you test a change in configuration.. plus everything is doubled..2 sets replica sets, service, pv, pic and pods.. 1 set is rs0, the other is is cfg.. worse that that until you don't uninstall also the operator chart the resources gets created again...then you can manually delete the resources..
I opened an issue but never got an answer to it, so I abandoned the idea of switching to Percona..it's just not worth the trouble and it's a mess..
Also in a post on your forums one of your staff points to the fact that the licence is not open source anymore but you went with the same licence as Mongo.
The only benefits for switching are a few enterprise only features like the hot backup, but with something like K10, there is not even need for it..
Please shine some light on these as Percona is very promising, but as far as my experience has been far from being a drop in replacement..and very bad DX