MongoDB 3.4 + Sharding/ConfigServer/Security Functionality #255
Conversation
Fixed format/wording Implemented https://jira.mongodb.org/browse/SERVER-27289 (bug fix) Removed nproc (unused)
… the updated mongodb statefulset quickstart example
Bug in replset already initialized check Added mongod log to stdout Reorganization in preparation for new deployment types (configserver, shard, mongos, etc) Add configserver functionality Set config file port to always use 27017
|
Can one of the admins verify this patch? |
2 similar comments
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
@jbornemann @ecwpz91 Thank you very much for these improvements. And sorry for replying too late. Certainly this PR contains a lot of useful features and improvements. Some points to this PR:
Also this PR is really big and it is very hard to review it. Would it be possible to split this PR into smaller ones? Can I somehow help? |
|
@omron93 thanks for taking a look! Revisiting a bit, it looks like there is some coordination that would need to occur between this PR and your PR #256 I saw recently that rh-mongodb-34 is in beta? It might be an easier PR to review if done commit by commit; I was careful to isolate features to commits. Just a quick question - it looks like we are moving towards a "latest" folder instead of copying functionality version release to version release. I think this is a good step forward. Any thoughts on keeping a single folder, and tagging mongo releases instead? The latest folder will probably solve a lot of the code friction issues; but it seems like we could collapse the previous folders into it as well - we know the latest SHAs in each, and could tag them. Besides new features, it seems the Dockerfile build (specifying the rh-mongo image) is really the only thing that changes between mongo releases - Having a single dynamic Dockerfile that builds a mongo release knowing the tag name might make back-porting easier if it comes to that. |
Right.
That is true. But discussion about all features have to take place in one PR and will be mixed together.
We are releasing builds/rebuilds of almost all versions (only 2.4 is EOL). And we need deliver fixes/updates in image scripts into all our build images. So I think tagging is not right approach (maybe I don't understand you proposal right).
That is right. I plan to do similar PR as sclorg/mariadb-container#44 for mongodb too. We try to keep source accessible - we want to have sources easily available for each version (also we want to have it buildable using |
|
@omron93 I have #264 and #263 split out along with others. It would make sense to review these two first, as the others build off of these. I may need some help shepherding some of this stuff - I won't have a whole lot of time this week to devote to this unfortunately. I didn't integrate the s2i features into the new code organization here. I wasn't quite sure the intent of using s2i in this context. Feel free to make changes, or add commits. |
|
Can one of the admins verify this patch? |
3 similar comments
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
Lots of content here, I know; but the gist is that @ecwpz91 and I have added features to enable setting up a fully sharded, secured MongoDB cluster on OpenShift (or elsewhere?). The container can now be run to accommodate deploying a shard router, shard configuration server, or replica set member. In addition, members of replica sets have features to secure communications over TLS - including automatic certificate, and CSR generation.
@hhorak I saw the previous comment about using Red Hat builds for 3.4. Let me know how I can help get a 3.4 build up