Or if you want to use the same volume across multiple containers I guess? But you would have the same issue if we put the volume somewhere else.
I think the issue here is that the things we want to persist at runtime are co-located with stuff people might want to change at build-time
I think the issue here is that the things we want to persist at runtime are co-located with stuff people might want to change at build-time
I had an idea where we have a volume for these handful of files, and then symlink them on start or something
Yeah, something like that could work
yeah, I was considering logs, but I'd almost prefer disabling the log dir by default, and lean on docker logs
ok cool...I'll play around with this idea
FWIW, I built a CLI that launches the docker image with sensible defaults, and then it can also run as a Mac service (like systemd, it will restart on failure, etc)
I just do
manageiq start and I have an MIQ...awesome for quick demos / double checks
@jvleminc you're talking about the branding via "upload image" in the UI?
or are you modifying the source directly?
We do something like this:
COPY branding/* ${APP_ROOT}/
RUN cp -v ${APP_ROOT}/login-screen-logo.png $( find ${RUBY_GEMS_ROOT}/bundler/gems/ -name login-screen-logo.png ) && \
cp -v ${APP_ROOT}/login-screen-logo.png $( find ${APP_ROOT}/public/assets/layout/ -name "login-screen-logo-*.png" ) && \
cp -v ${APP_ROOT}/brand_atmosphera.svg $(find ${APP_ROOT}/public/assets/layout/ -name brand-*.svg)
one way around that is to actually keep the code committed in a repo
then build the images from that repo
but if my idea of extracting the identity files into a separate volume work, that would probably solve your problem because the APP_ROOT volume would go away
When deploying in kube this is all driven by env vars so we don't need a volume, but that's kind of cumbersome for running a single image.
We could do something like store all the config in
We could do something like store all the config in
/etc/manageiq/config or something then set the envs from there in the entrypoint.
Might be harder for stuff that isn't config and isn't driven by env though
it might need code changes to support that...haven't quite wrapped my head around "new" files getting into there
Ok, for now I have started to use this script: https://github.com/gdraheim/docker-copyedit
Works fine.
Works fine.
How could i add field to user table in manageiq?
Is there activation field for user in db?
And how could i add dummy new user?
Hello, ran into an issue with a specific vcenter provider where when I try provisioning to it, I receive the error:
Status [Error Creating Service] Message [[MiqException::MiqProvisionError]: Customization Specification [1000000000028] does not exist.] However, when I check the vcenter, the custom specs are there . I’ve tried recreating the custom specs (on the vcenter end), removing the provider and re-adding it to manageiq - all with no success. There are other vcenter providers within the same manageiq region and they work just fine. Any other thoughts or ideas as to where I can troubleshoot?
we are not even at K-release yet. Why is the code saying L-release?
we deprecate in K and remove in L