mongodb-container
mongodb-container copied to clipboard
sclorg
Configuration Server Run-Mode functionality
This PR accomplishes two things:
1.) Setting up init folder structure to a more domain-driven design - this will help with segregating/sharing code across future run modes. (coming in other PRs). I've looked through both new mongodb/db structure, and init/pre-init structure to make sure nothing was missed, and it seems to be a mostly organizational change. The exception seems to be s2i - which I was not sure of the intent of this, so I didn't attempt to incorporate it. I might need someone with the backstory to add the commit adding that functionality. p.s why extend the image with s2i as opposed to just a plain docker build? I guess I would expect the tool to be used more exclusively in quick turn-around type uses; as opposed to extension of a middleware image - where I would expect iterations to be much more well defined, and steady.
2.) Added run-configsvr
Just a note, https://github.com/jbornemann/mongodb-on-os I plan on submitting to container-quickstarts as an example of how all of these run modes fit together on OpenShift in a sharded Mongo environment.
@omron93 this is probably a good first PR to start on, in terms of splitting up https://github.com/sclorg/mongodb-container/pull/255
There are some new features which are good. But also there is a lot of changes (naming, structuring,...) which was done probably by writing code independently. It would be good to have reason for these changes - useless rewriting of code can bring only hidden bugs ;-)
The intent was to structure the code in a way such that functions are shard, or segregated based on run-mode - to easily find functions, and reduce duplication. With the introduction of new run-modes, code organization problems are uncovered that weren't previously there.
s2i
No strong feelings about having vs not having it. Personally, if I were a user wanting to extend the image; I would just extend it via Dockerfile, add scripts, and change the entrypoint - but that is just personal taste. To me, s2i is more of a tool for deploying applications on an existing image within a mostly pre-defined lifecycle (assemble, save-artifacts, run) - although, yes, you can extend it.
Also I have idea about config server
Sure, sounds good to me. Those two things seem to be likely to change together, so probably does make sense to consolidate.
rs_remove()
I delegate to @msurbey again for this one. No strong feelings.
@omron93 just FYI, if it suites your fancy - feel free to help move these PRs forward. I likely won't have a whole lot of dedicated time to this.
