Wasp logs are partially displayed
Hey, two questions:
1) How twisted it is to run Wasp in a container via specifying
ENTRYPOINT ["./wasp", "start"] in the Dockerfile? Insetead of calling wasp build and building an image. Don't ask me why please 😁
2) When I do so -- the logs output is only limited to [Client!] and [Server!] warnings, but no messages like 🐝 --- Starting npm install... are displayed. It's the log lever suppression and I need to make them more sensitive, or the issue might be related to something else?
11 Replies
I will respond fully a bit later when I catch time, but quick answer is that it seems to me like you are seeing only stderr messages? The ones with ! are stderr, the rest is stdout, and you seem to be getting only stderr? So that is probably on your side then, you are viewing only stderr.
Running Wasp via Docker that way -> well it is okish, but
wasp build makes sure that all is as it should be for production, including possibly some security stuff -> I can't remember if there is anything one should worry about, probably not, but still, with wasp build you are certainly doing it right. But you could tell us what do you need it for 😄 so we can figure out the best way to do it!>> But you could tell us what do you need it for
I need to run Wasp on UBI9 (RH universal base image) inside of an OpenShift pod.
There's A TON of limitations, so the easiest way is to run wasp as is on the image itself, without building it on Alpine and pushing the image somewhere
>> So that is probably on your side then, you are viewing only stderr.
I've got the exact opposite answer suggesting that OpenShift is configured properly, but the log level is not specified on the application level 🥲
Hah, both blaming the other :D.
Hm let me think -> what does it mean that the log level is not specificed on the application level? So I can tell you how Wasp works, and it is pretty simple: it prints some stuff to stdout, some to stderr. There is no way to configure this in Wasp, no way to specify the log level, we never did that. It is as if you had a JS file that has some
console.log('hello') statements in it and some console.error('this is error') statements in it, that is it, nothing smart about it. So I have no idea what to do on the Wasp side, as there is nothing to do really.
Can you try to run wasp version in the same way you are running wasp start and see if you get any output in that case? If not, then indeed stdout from wasp is not coming to the terminal. If you do get output, then we can investigate further as to why wasp start specifically is behaving weird.
As for running Wasp on UBI9 inside of an OpenShift pod -> ok interesting, I would be happy to help you out with that. Yeah, you can just try to run Wasp with wasp start, but what would be better is if we could run it properly for production. If we want to do that, we could take a look at Dockerfile that wasp generates and either add to it / override it via https://wasp-lang.dev/docs/advanced/deployment/overview#customizing-the-dockerfile, or we could instead write our own Dockerfile from scratch (that uses UBI9 and does exaclty what is needed), that would be inspired by Wasp's Dockerfile. But that would probably be the most "correct" way.
If needed, I can take some time to try to help you with this more proactively. Some options: we can sit on a call together and try to make it work, or you could give me some pointers on how I can test deploying this on OpenShift myself, so I can reproduce your situation and try to come up with some kind of solution myself, that I could then share with you.@martinsos ok this sounds convincing 😁 Honestly I think the issue is somewhere in the build/deployment pipeline, and not in the Openshift/Wasp itself. Probably an override is hidden somewhere. I'll try to run
wasp version and see what it'll give, great suggestion!
As for the custom dockerfile -- that would be brilliant! I've played with the custom Dockerfile for some time, but got stuck at some point. Agree, that would be an optimal way to deploy the app.
I'll spend a couple days to get all the pieces together and will get back to you, thanks 🙂Ok no worries, but do let me know if you get stuck on anything, and as I said, if you help me recreate the situation, I am more than willing to put an effort into replicating it on my side an trying to get it to work.
@martinsos
wasp version works fine, I'm calling it like this:
ENTRYPOINT ["./wasp", "version"]
The way wasp start outputs data is 100% the same as wasp version, right?
Ok so that is quite weird. Ha, so this does sound like
wasp start is the culprit then hm, in some way!
Ok so I checked again, and they indeed use the same way of printing stuff to the screen -> the same command really.
There are three main differences I managed to detect:
1. wasp start often adds emojis to its output, actually at its start. But I doubt that could cause the output to not be displayed? Yeah, I don't think could be the reason, but I also can't eliminate it completely.
2. wasp start never finishes execution, while wasp version does. wasp start just keeps running. The only reason why this could be an issue, that I can think of, is if stdout flushing doesn't happen. Maybe it happens only when the program ends? But why is stderr going through then? This is also quite far fetched hm. What we could try to do is add explicit flushing via Haskell's hFlush.
3. wasp start also has stderr output, wasp version doesn't. Maybe, when stderr is output, the environment in which you are running drops stdout, or you know, only stderr is shown? But that also sounds quite weird.
So this is quite tricky, I don't have a lot of good ideas here! But I am sure we can solve it. Ok, here come things I think we should try:
1. Run a program that outputs some stdout, then some stderr, and then continues running forever. How does that one behave? If it is also missing stdout, then we have a very minimal example to test, and don't have to keep our eyes on wasp start.
2. Add hFlush (forced flushing of stdout) to wasp start, and also remove emojis, see if that changes anything. I could make an experimental release that is like this, but it will take me some time to build it and deploy it (30 min to an hour).
I think the direction (1) is easiest to test. The easiest way might be to just write a simple nodejs script that does console.log("hello"), then console.error("whoopsie"), and then just has a while(true) loop with 1 second timeout in it, so it runs forever.
I could make an experimental version of Wasp that has additional wasp max-test command, which would do the same thing I described above for node.js script, and you could test that. You are running on Redhat? I could build this on my Arch, I think it should work, and I just send it over. That is probably the easiest option actually! Yeah I should do that. But it will take me a bit and I am on a retreat which makes it harder to find time, but I might be able to do it, I just need to work it in into the schedule. What is your schedule with all this?
Ok I am building an experimental versio now
Ok @maksym36ua I created it here: https://github.com/wasp-lang/wasp/releases/tag/v0.11.4-max-test .
So you can install it with curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s -- -v 0.11.4-max-test.
Then, try running:
wasp version
wasp max-test
wasp max-test2
wasp max-test3
wasp start
And let's see for each of these commands how they behave -> I put a lot of stuff in them and made some modifications, so I believe this will give us a good idea of what is the issue!Wowowowow, this is wild! Looking!
@maksym36ua , I am just curious, what was the issue here at the end?
Issue on the Openshift side. 6+ hours delay in displaying the stdout logs :sadboi:
Auff