Deployment of the web compiler on OpenShift

Development
1

Using this topic to discuss the deployment of the web compiler on OpenShift.

Deploying the ReactJS frontend on OpenShift failes the first time. The build containers tries to utilize the memory beyond the project’s quota and gets killed by the OOM error. After the build fails, however, we can continue with the deployment by editing the YAML for the build config and specifying the resource limit under the spec section as follows:

resources:
    limits:
      memory: "1Gi"

After that triggering a manual re-build would do the trick and result in a working pod :wink:

A side note on deleting all components corresponding to an app using the oc cli:

oc delete all --selector app={app_name}

@bvasilev anything I missed?

2

Hi guys, why can’t the limit be set right from the start?

3

Hey @litmaath, we could set the limits easily if we are deploying from the web interface. However, it is much quicker to deploy the web compiler from the CLI. However, setting the limit would require describing everything in a yaml file, which could get pretty long. Therefore, we just deploy with a single command for now. The more pressing issue is that the frontend does not come up on openshift at all. Even though locally it seems to be working completely okay. I think it could be related to resource quota in general. I will try to look into the logs to figure it out. @bvasilev pinged me on Slack describing a new approach he wants to try out when deploying things on OpenShift. I’ll let him elaborate on that :wink:

4

I found this nodeshift tool which might be very useful for deployment. Tutorial on how to use here. It internally uses s2i but simplifies the process a lot (it’s just a single command). The problem with it is that you cannot specify the memory limits in the command. However, it was easy to add so I made a fork of it on NPM. I’ll make an issue on the official repo later. I still haven’t made it work. I think it’s not running the command to start the React server.

By the way, for all the approaches it’s important to specify HOST=0.0.0.0 because that’s what OpenShift uses when exposing the app. It’s also good to add PORT=8080. Otherwise, we have to change the port on the OpenShift Service. In React this can be specified in .env file in the root folder of the project.

1 Like
5

Cool. I think I tried deploying with the .env file that described the port. I see now that you have updated the .env file

Did you get a chance to deploy again after making this change?

On a side note, is this what fixed the backend deployment a few weeks back?

6

Yeah, I remember we changed the server to 0.0.0.0 and then we deployed from the catalog and it was surprisingly easy.

But there is a difference between deploying the frontend and the backend because we weren’t making a route for the backend because we needed it to be accessible only from inside the cluster (by the frontend), whereas we want the frontend to be exposed to the world through the URL. The service on the frontend is also working, the same way the backend is. The problem is that the route is not working.

7

Hey all! As I said today in the meeting I have made a NodeJS react-app play along with a Django rest API before so i’ll share my config in case it helps.

That’s the server.js file https://github.com/operationalintelligence/rucio-opint-frontend/blob/master/server.js

I think webpack config is also relevant: https://github.com/operationalintelligence/rucio-opint-frontend/blob/master/webpack.config.js

That’s the Openshift configuration with the route and everything: https://openshift.cern.ch/console/project/rucio-opint-ui/overview I believe Boris and Mayank have access since they are at the rucio-opint-devs group.

What is the error exactly with the routes? I might remember something.

Cheers!

1 Like
8

Thanks for sharing these resources @ppaparri . Turns out though it was a much simpler fix :wink: We just had to expose the site to the internet instead of the default intranet setting.

9

Aaaah yeah there is also this amazing default value in CERN’s sites. I have forgotten :stuck_out_tongue:

10

@bvasilev thanks for your work on deploying the compiler :slight_smile: We for sure have our first users coming on board. Would you have some time this week to look into some of the remaining issues with me?

@litmaath @all could you leave some feedback on how to improve the user interface. I’ll then put them on the github project board for the next release.

Here’s the link: http://simple-compiler.web.cern.ch/

11

Hi all, I asked the compiler to process a junk file (a copy of /etc/group from my laptop) and did not find the resulting logs very helpful? Naively, I would have expected it to complain about “unexpected attribute/token/… on line N” or something alike? For comparison, let’s see what the C compiler does:

$ cd /tmp
$ cp /etc/group c.c
$ cc c.c
c.c:1:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
 root:x:0:notifications
     ^
$

Next I will try with a less broken file… :slight_smile:

12

Hi guys, the file we used on the QA cluster compiles fine, of course. Adding a single spurious space to the indentation of one line does not seem to give me a helpful error message to identify that broken line? Clicking the “augmented_conf.yaml” and “error” links just gives me a line that only contains “1”, which presumably is the return code of the compilation?