Could someone please help me understand why the last three tests might have failed? I don't know enough about what the tests are designed to exercise, but the files I added or modified were all in their separate directories; I can delete them entirely and run Huginn without a problem.

Hi @baip,

thanks for all that work, the spec failures are not related to you changes. Sadly we do have some flaky specs recently.

Is there any way to have a simpler deployment to OpenShift? The amount of code we would need to maintain scares me a bit. Especially compared to Heroku it looks like a lot of boiler plate that every project needs to duplicate. If our docker container would not run as root could the docker image be used to simplify the deployment process?

@dsander It's actually not that bad: only files in openshift/templates, .s2i/bin, and .openshift/action_hooks/setup_env; other files in .openshift are left over from the OpenShift v2. I just wish to keep the scripts recorded somewhere because they would still provide a good example of automated Linux deployment. I can delete them right before the last commit -- would that be more preferable?

If we ask user to run something like a new bin/setup_openshift script, the deployment can be much simpler. The complexity mostly arises from the template files AND allowing the possibility of changing DATABASE_ADAPTER after deployment (so have to provide modified build scripts to use the same hack Dockerfile uses). But providing template files makes it possible for users to do a one-liner deploy or even entirely on the web console. I can slim down the scripts in .s2i/bin though.

Thanks it indeed looks a lot simpler now.

The complexity mostly arises from the template files AND allowing the possibility of changing DATABASE_ADAPTER after deployment (so have to provide modified build scripts to use the same hack Dockerfile uses).

I don't know much about how OpenShift works. Is it kind of a mixture of deploying docker containers and how Heroku works? In the Dockerfile we only have those hacks to precompile the assets when we build the image. Since Rails requires a database connection to do that we need to add the sqlite gem. Heroku does not require the hack because the asset precompilation is done on every deploy (which is kind of the standard for Rails applications). Switching the database adapter should not require any hacks as long as bundle install runs on every deploy.

I think OpenShift now runs Docker containers, while Heroku custom built their own container solution based on LXC. Besides running Docker images directly, OpenShift has something called source-to-image, which uses a language runtime image with scripts that can build user code into a new image and start the application when deployed. So this operation mode is very similar to Heroku. We can also describe the entire setup in a template file, but when using these quickstart templates, the database is being deployed at the same time as the application itself and may not be ready for Huginn to use, which is why I had to modify the builder scripts to use sqlite3 temporarily. If a user/setup script manually deploys the database image first, and then the application with all the DATABASE_* environment variables set up properly, there would be no need for any of the custom scripts or quickstart templates.

the database is being deployed at the same time as the application itself and may not be ready for Huginn to use, which is why I had to modify the builder scripts to use sqlite3 temporarily.

I see so we could do the asset precompilation in the run script which would allow us to get rid of the assemble script?

When #2112 is merged, can we use one of the docker images for OpenShift? To me it looks like most of the logic that is done in both scripts is already handled by the docker containers.

Yes, but the pod restart will then take significantly longer; the run script does "database:migratebut notbundle install`, so it's quite fast right now. Docker images should work, but then one loses the ability to play with the code and still easily deploy.

I played around with OpenShift a bit and noticed their stock build image for ruby worked as long as I set ON_HEROKU=true in the build environment variables. Not sure how and why (maybe something in Rails changed) but the asset precompilation step does not seem to require a database connection anymore. Maybe that simplifies things a bit?

My build environment config:

                    {
                        "name": "ON_HEROKU",
                        "value": "true"
                    },
                    {
                        "name": "LC_ALL",
                        "value": "en_US.UTF-8"
                    },
                    {
                        "name": "LANG",
                        "value": "en_US.UTF-8"
                    },
                    {
                        "name": "APP_SECRET_TOKEN",
                        "value": "xxx"
                    }

Wow, you're right. I had actually tried adding ON_HEROKU=TRUE, but only after I started tinkering with customizing the assemble script to set up .env. I realized that ON_HEROKU sets up several defaults if the relevant environment variables are not set themselves, but didn't know that it also skips the dotenv file altogether. I wish I had consulted you first....

The only other thing I needed for build was `DATABASE_ADAPTER=mysql2"; otherwise deploy would have problems.

Thanks a lot @baip!

Glad to see it merged. Thanks!

Nice @baip!