mongo 3.2 lacks most of the tools about mongodb-container

[hhorak]

As the package is no in rh-mongodb32-mongo-tools there is a need for...
I don't get it, I believe mongoimport is part of rh-mongodb32-mongo-tools package. But this package is not installed in the image, right?

Anyway, I see the point, but every solution has some side effects.

Have the tools in the mongo image

The problem with mongo-tools is that the binaries are really big (statically-linked golang binaries with ~7MB each, so ~70MB in total).

Slightly less invasive but also less perfect would be to include only mongoimport in the image (remove unneeded binaries to safe image size; eventually by having something like mongo-tools-import sub-pkg)

Have an additional mongo-tools image that can be used to import data in the mongo db. This image can be used as sidecar, as post-deployment or as a job or runonce pod to load data into the mongo database.

I have "some" idea about how complex this would be in k8s or openshift, but I'd like to see another opinions, whether this is the way we could go and whether it is worth doing for the image size decreasing. @bparees, any opinion?

[bparees]

The sidecar would be fairly painful for users i think, they'd have to update the pod (or DC) to add the sidecar container, then ssh into it and use the tools, then update again to remove the sidecar container.

they're also likely to hit resource limits due to needing another container (especially in online) and having to redeploy my DB to add a tools container sounds very bad. If i were an admin faced with that, i'd instead ssh into the DB container and curl down the tools i needed and use them that way.

[jorgemoralespou]

@bparees why would the sidecar need to be removed and the
[email protected] redeployed? Couldn't just be used for a post-deployment
hook?
Couldn't the template have both containers and just guarantee that the db
is running?
Or the container be used in a job to do the load/import?

El 18 ago. 2016 17:44, "Ben Parees" [email protected] escribió:

The sidecar would be fairly painful for users i think, they'd have to
update the pod (or DC) to add the sidecar container, then ssh into it and
use the tools, then update again to remove the sidecar container.

they're also likely to hit resource limits due to needing another
container (especially in online) and having to redeploy my DB to add a
tools container sounds very bad. If i were an admin faced with that, i'd
instead ssh into the DB container and curl down the tools i needed and use
them that way.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#170 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEyDm7pg-r3PdMDyvadfNC2kz9nP9Lqks5qhH3FgaJpZM4Jh4cw
.

[bparees]

@bparees why would the sidecar need to be removed and the [email protected] redeployed?

@jorgemoralespou i was under the impression the admin wanted to use the command line tools by hand to do things. In which case they need the sidecar container to rsh into, and they'd want to remove it afterwards so it is not consuming quota resources.

Couldn't just be used for a post-deployment hook?

As for using a post-deployment hook, post-deployment hooks use the same image as the deployment, they can't run using an arbitrary image, so you'd be stuck using the DB image that doesn't have the tools, for your post-deployment action. So that won't work.

Couldn't the template have both containers and just guarantee that the db is running?

no. if you have a container in a pod, it will be running (or be in a crashloop state). you can't define a container in a pod and not have it be running, as far as i know.

Or the container be used in a job to do the load/import?

a job would work fine, again assuming you want to script/automate the loading. that wasn't my impression of the use case that was being presented, but if it is then sure, they could use a job to run a db-tools image that does the work by connecting to the db service.

[bparees]

a job would work fine, again assuming you want to script/automate the loading. that wasn't my impression of the use case that was being presented, but if it is then sure, they could use a job to run a db-tools image that does the work by connecting to the db service.

i should note that assumes the tools do not require direct filesystem access to the DB. If they need filesystem access to the DB, you need to run them in the same pod so they can access the volume (or have a PV that can be mounted multiple times).

[hhorak]

i should note that assumes the tools do not require direct filesystem access to the DB. If they need filesystem access to the DB, you need to run them in the same pod so they can access the volume (or have a PV that can be mounted multiple times).

This is not the case, imho all the tools work over network socket. Anyway, it seems that the option with a sidecar brings more complexity, so I'm more in favor rather to increase the image size. Question is whether we want to do tricks to not increase the image size too much, like removing not-desperately-needed binaries. The official image on docker hub includes all, so I'd go with that way as well.

[bparees]

Question is whether we want to do tricks to not increase the image size too much, like removing not-desperately-needed binaries. The official image on docker hub includes all, so I'd go with that way as well.

yeah i'm not inclined to play games to save a few megs.

[bparees]

@hhorak bump. i'd like to see us install these tools in the image.
@rhcarvalho fyi.

[hhorak]

I agree. @omron93, can you create a PR for that, pls?

[php-coder]

#187 just got merged. Can we close this issue then?