Stream: pascal
Topic: Automating fhirserver build
Josh Mandel (Oct 03 2021 at 02:06):
I'm new to pascal (well, I mean, beyond nerd camp for nerds in the mid 90's) and looking at Grahame's instructions for compiling the fhirserver (https://github.com/grahamegrieve/fhirserver/blob/master/linux-install-instructions.txt. Aim is to get a dockerized build process that's automated and repeatable, all from the commandline (i.e., without a desktop environment if possible).
I'm installing on ubuntu 20.04 starting from the 3 packages at https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64%20DEB/Lazarus%202.2RC1/
After following @Grahame Grieve's README steps I can do:
lazbuild work/fhirserver/packages/fhir.lpk
lazbuild work/fhirserver/packages/fhir4.lpk
with a bunch of warnings, hints, and notes -- but no errors. That's good, right? Do I need to compile other lpks in that packages directory too? What needs to happen next? (I don't see any executable outputs when I look with find work/fhirserver -executable -type f.)
Grahame Grieve (Oct 03 2021 at 02:57):
you need to compile all those packages yes
Grahame Grieve (Oct 03 2021 at 02:58):
once you've compiled all those packages, then you need to compile work/fhirserver/server/fhirserver.lpi
Grahame Grieve (Oct 03 2021 at 02:58):
that will produce the executable
Grahame Grieve (Oct 03 2021 at 02:59):
a dockerized build process that's automated and repeatable
That'll be a lovely outcome I'd really like
Grahame Grieve (Oct 03 2021 at 03:00):
and that you got fhir.lpk to build makes it very likely you'll get all the way - that includes all the code I know that depends on recent features of lazarus
Josh Mandel (Oct 03 2021 at 03:46):
OK, a couple of issues:
#14 15.18 (3104) Compiling /work/fhirserver/library/wp/wp_types.pas
#14 15.18 /work/fhirserver/library/wp/wp_types.pas(35,3) Fatal: (10022) Can't find unit Windows used by wp_types
#14 15.30 Fatal: (1018) Compilation aborted
#14 15.30 Error: /usr/bin/ppcx64 returned an error exitcode
#14 15.30 Error: (lazarus) Compile package fhir_wp 0.0: stopped with exit code 1
#14 15.30 Error: (lazbuild) fhir_wp 0.0 compilation failed
If I skip fhir_wp, compiling the rest of the packages works, but when I move on to compiling server/fhirserver.lpi I see:
> [11/11] RUN lazbuild work/fhirserver/server/fhirserver.lpi:
#15 1.630 Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP"
#15 1.630 Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas"
#15 1.630 Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP" "-Px86_64" "-Tlinux"
#15 1.630 Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas" "-Px86_64" "-Tlinux"
#15 2.022 ### TCodeToolManager.HandleException: [20170422130152] "include file not found "fhir.inc"" at Line=31 Col=5 in "/work/fhirserver/server/fhirserver.lpr"
#15 2.022 Error: (lazbuild) Broken dependency: MarkdownTests
This is after lazbuild work/delphi-markdown/packages/markdownengine.lpk, but I can't tell whether that actually includes MarkdownTests. If I try doing lazbuild work/delphi-markdown/tests/markdowntests.lpk before building the server, I get on to some new errors that have to do with windows32 platform (?)
win32 errors?
Grahame Grieve (Oct 03 2021 at 04:36):
SO:
Grahame Grieve (Oct 03 2021 at 04:37):
- fhir_wp - don't compile that. I forgot it was there
- markdowntests - yes, I missed that. Have to add that to the package list
- the last error.... don't know why you're compiling for win32 at all
Grahame Grieve (Oct 03 2021 at 04:39):
I think you need --build-mode=Linux
Grahame Grieve (Oct 03 2021 at 04:39):
btw, once you've built it, it won't run. I'm working on that now - some .so dependency issue, and I find them very hard to figure out (won't run on OSX for the same reason, different .dylib)
Grahame Grieve (Oct 03 2021 at 08:36):
well, if I could figure out how to commit from my linux dev PC, it would run, but the personal access token thing seems specifically designed to keep me out
Grahame Grieve (Oct 03 2021 at 09:05):
sorted that out. it should run, at least, though I have a lot of testing to do.
Grahame Grieve (Oct 03 2021 at 09:06):
Here's my experience with cross platform development, when I run into a problem:
- windows: I find the answer immediately
- linux : I find hundreds of different answers, one of which might be correct for me, but I can't figure out which
- macos: I can't find anything
Grahame Grieve (Oct 03 2021 at 09:36):
brew tells me that openSSL 1.1 is installed... but I can't find the dylib files. Where should I look?
Grahame Grieve (Oct 03 2021 at 09:47):
openssl failed to load: dlopen(libssl.1.1.dylib, 1): image not found
So I can't find it and neither can my program
Grahame Grieve (Oct 03 2021 at 09:48):
but brew says:
Grahame Grieve (Oct 03 2021 at 09:48):
brew install openssl@1.1
Warning: openssl@1.1 1.1.1l is already installed and up-to-date.
To reinstall 1.1.1l, run:
brew reinstall openssl@1.1
Josh Mandel (Oct 04 2021 at 03:41):
Will try with --buildmode=Linux. Alas I can't help on the MacOS / brew front
Josh Mandel (Oct 04 2021 at 04:05):
Build succeeds with --build-mode=Linux. I see when I try running it that at least libChakraCore is missing.
Grahame Grieve (Oct 04 2021 at 04:08):
that should be resolved now.
Grahame Grieve (Oct 04 2021 at 04:09):
no. somehow git beat me, and the code to fix that wasn't pushed
Josh Mandel (Oct 04 2021 at 04:15):
OK -- I see when I manually install chakraCore I get X related errors. I don't know if the server needs a graphical environment, but I've updated https://github.com/jmandel/fhirserver/blob/patch-3/Dockerfile to give it one...
Josh Mandel (Oct 04 2021 at 04:16):
At which point it fails to find /work/fhirserver/exec/64/tz.dat (I note that /work/fhirserver/exec/pack/tz.dat does exist, and if I try to copy this file to the other path and re-run the fhirserver, I get a segfault.)
Grahame Grieve (Oct 04 2021 at 04:52):
hmm. you shouldn't. the one in /pack is the correct file - it will need all the .dat files in there
Grahame Grieve (Oct 04 2021 at 04:52):
how did you manually install chakracore?
Josh Mandel (Oct 04 2021 at 04:54):
https://github.com/jmandel/fhirserver/blob/dc43a3a0c10e0fe6ac83daf09725dc9d5b952d07/Dockerfile#L45
Grahame Grieve (Oct 04 2021 at 04:55):
just copy it into /usr/lib? weird. I'd never do that on windows.
Grahame Grieve (Oct 04 2021 at 04:55):
anyway, the one in pack should go next to the executable, but the compiler flag for that didn't get pushed.
Josh Mandel (Oct 04 2021 at 04:56):
(I'm not sure if that's the right way to install; I was just trying to get past the error)
Grahame Grieve (Oct 04 2021 at 04:57):
ok
Grahame Grieve (Oct 04 2021 at 05:05):
I just hate git
Grahame Grieve (Oct 04 2021 at 05:07):
well....... maybe that will sort it.... maybe.
Grahame Grieve (Oct 04 2021 at 05:08):
so with that commit, chakracore should be in the exec/64 folder now
Grahame Grieve (Oct 04 2021 at 06:59):
the next issue for me to resolve is to get sqlite working on linux
Grahame Grieve (Oct 04 2021 at 09:40):
nothing special there - standard install of sqlite3 and dev tools, and it's good to go.
These parameters should do the trick:
-cmd exec -cfg http://tx.fhir.org/config -version 4
Grahame Grieve (Oct 04 2021 at 09:40):
it defaults to running on port 80. if you want a different port, create a file web.ini in the same directory:
[web]
http={port}
Josh Mandel (Oct 04 2021 at 14:34):
I'm running with these updated args, but still seeing
EFOpenError: Unable to open file "/work/fhirserver/exec/64/tz.dat": No such file or directory
(This is on commit 80bdd22ae24f9f21798b9ce5882de2d183a5b53c of fhirserver.)
Grahame Grieve (Oct 04 2021 at 17:55):
and that file exists?
Grahame Grieve (Oct 05 2021 at 06:20):
yay well, the server runs on OSX now
Grahame Grieve (Oct 05 2021 at 06:21):
figuring out the install won't be much fun... every .dylib will hurt
Jose Costa Teixeira (Oct 05 2021 at 11:41):
Is the Linux install working?
Jose Costa Teixeira (Oct 05 2021 at 11:42):
I can test it during the weekend - I can either test the installation, or test the server if the install goes well
Josh Mandel (Oct 05 2021 at 15:04):
Grahame Grieve: and that file exists?
No, /work/fhirserver/exec/64/ has only the fhirserver binary inside.
Grahame Grieve (Oct 05 2021 at 18:46):
so the files in exec/pack and exec/pack/linux need to be copied into exec/64 before executing
Rob Hausam (Oct 05 2021 at 18:58):
I know I got it most of the way there on Linux the last time that I tried, but that's been a little while now. I may try to dust it off and give it another try there, too (also probably over the weekend).
Grahame Grieve (Oct 05 2021 at 19:12):
it's a lot easier now. And Josh's work is making it easier
Joel Schneider (Oct 05 2021 at 22:09):
figuring out the install won't be much fun... every .dylib will hurt
Not sure if this might help, but homebrew (macOS) creates symlinks to many .dylib files under /usr/local/lib. OpenSSL seems to be an exception.
$ brew info openssl
...
openssl@1.1 is keg-only, which means it was not symlinked into /usr/local,
because macOS provides LibreSSL.
Josh Mandel (Oct 05 2021 at 22:47):
Adding the relevant cps for those config files. Now I see:
/work/fhirserver/library/fdb/fdb_odbc_fpc.pas(52,1) Fatal: (2002) illegal character "'!'" ($21)
which may be a new source code error in the repo?
Grahame Grieve (Oct 05 2021 at 22:48):
I committed a fix for that several hours ago
Josh Mandel (Oct 05 2021 at 22:49):
I git pulled 60sec ago
Grahame Grieve (Oct 05 2021 at 22:51):
well... git on my linux box says that line is fixed, and everything is committed and pushed.
Grahame Grieve (Oct 05 2021 at 22:51):
but it's very evidently not the case
Grahame Grieve (Oct 05 2021 at 22:54):
@Joel Schneider the problem is, so far I can only get the dylibs to load by providing a full path (including version) to the dylibs at their source. But what would I deploy for other users? I find OSX really very hostile.
Josh Mandel (Oct 06 2021 at 01:00):
Now at 956a0a7b1b45555a5af3b5285853d573c1efb266:
/work/fhirserver/server/remote_config.pas(414,18) Error: (5000) Identifier not found "UniversalDateTime"
/work/fhirserver/server/remote_config.pas(421,91) Error: (5000) Identifier not found "UniversalDateTime"
remote_config.pas(491) Fatal: (10026) There were 2 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Grahame Grieve (Oct 06 2021 at 08:45):
really? more git won't commit for me. I wish I understood :-(
Josh Mandel (Oct 06 2021 at 13:03):
Hrm. We should dig into these git issues. Maybe record a screen cast or something?
Grahame Grieve (Oct 06 2021 at 14:03):
not sure. I decided to try living with git command line. I made my changes and then git commit -a and git push. Said it had, and nothing more to do, but the changes disappeared. I've moved on, rebuilt the repo and installed gitkraken, which is working as I expected
Grahame Grieve (Oct 06 2021 at 14:03):
anyway, compile issues should be sorted now
Josh Mandel (Oct 06 2021 at 14:10):
Okay. If gitkraken works for you, great! (The git cli has a learning curve but it's not, like, buggy/lossy.)
Josh Mandel (Oct 06 2021 at 14:10):
Rebuilding now...
Josh Mandel (Oct 06 2021 at 14:14):
For the dependencies in this project
git clone https://github.com/dezlov/PascalTZ && \
git clone https://github.com/grahamegrieve/delphi-markdown && \
git clone https://github.com/mriscoc/extrasyn && \
git clone https://github.com/grahamegrieve/HtmlViewer && \
git clone https://github.com/grahamegrieve/lazarus-ide-tester && \
git clone https://github.com/Xor-el/QRCodeGenLib4Pascal
... how do you version these in your development / when do you update them? I'm thinking I should be cloning a specific tag or commit to avoid surprises as these evolve.
Grahame Grieve (Oct 06 2021 at 14:29):
I haven't considered that. They're pretty stable but I probably should. I may have to fork them
Josh Mandel (Oct 06 2021 at 14:30):
If you just want to pin to a git tag or hash, you don't need to fork. If you want to make your own changes... well, fork time.
Josh Mandel (Oct 06 2021 at 14:33):
Hmm, following your instructions I have two copies o-f libChakraCore.so:
$ find /work/fhirserver/ | grep -i chakraCore.so
/work/fhirserver/exec/pack/linux/libChakraCore.so
/work/fhirserver/exec/64/libChakraCore.so
... but the fhirserver executable isn't finding these. (I can revert to putting this in /usr/lib, where the fhirserver finds it. Overall I wouldn't check 45MB compiled libraries into your git source tree, since the libChakraCore team already makes these available in a published release.)
Anyway, after putting the lib in a good spot I get:
fhirserver: malloc.c:3839: _int_malloc: Assertion `chunk_main_arena (bck->bk)' failed.
Grahame Grieve (Oct 06 2021 at 19:57):
running out of memory?
Josh Mandel (Oct 06 2021 at 20:40):
Definitely not -- this happens instantaneously and I have ~32GB free.
Grahame Grieve (Oct 06 2021 at 21:31):
no, I'm at a loss. this is ubuntu?
Josh Mandel (Oct 06 2021 at 21:43):
Yes, built according to the dockerfile I shared
Josh Mandel (Oct 06 2021 at 21:45):
It actually generates various outputs when it fails.
Josh Mandel (Oct 06 2021 at 21:48):
A medium-sized output
A shorter output
A longer output
Grahame Grieve (Oct 06 2021 at 21:50):
what parameters are you running the server with?
Josh Mandel (Oct 06 2021 at 21:51):
https://github.com/jmandel/fhirserver/blob/patch-3/Dockerfile#L64
ENTRYPOINT ["/bin/entrypoint.sh"]
CMD ["-cmd", "exec", "-cfg", "http://tx.fhir.org/config", "-version", "4"]
Josh Mandel (Oct 06 2021 at 21:52):
This is equivalent to:
/work/fhirserver/exec/64/fhirserver -cmd exec -cfg http://tx.fhir.org/config -version 4
Josh Mandel (Oct 06 2021 at 21:52):
(I think I just cribbed this from you.)
Josh Mandel (Oct 06 2021 at 21:53):
Actually, those outputs were from running by hand with no args.
Josh Mandel (Oct 06 2021 at 21:53):
(As documented in the individual spoilers.)
Josh Mandel (Oct 06 2021 at 21:53):
Here are some more, with the args you supplied:
Josh Mandel (Oct 06 2021 at 21:54):
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
^ that's interesting
Josh Mandel (Oct 06 2021 at 21:54):
Josh Mandel (Oct 06 2021 at 21:56):
I'm assuming fhirserver needs an GUI so I've created a framebuffer-backed X display for it to run against; if I don't give it this, I get
(fhirserver:155): Gtk-WARNING **: 21:55:29.347: cannot open display:
Grahame Grieve (Oct 06 2021 at 21:57):
it doesn't need a display as far as I'm concerned.
Grahame Grieve (Oct 06 2021 at 21:58):
I don't understand any of this at all.
Grahame Grieve (Oct 06 2021 at 21:58):
the parameters you're using are correct, and it runs fine for me without all this system craziness
Grahame Grieve (Oct 06 2021 at 21:58):
why would it be different? it's a console application....
Josh Mandel (Oct 06 2021 at 22:06):
Hmm. I honestly don't know. When I look at the server binary I see a 417MB file with 243 of mentions of "X11" inside. What do you see?
# du -h /work/fhirserver/exec/64/fhirserver
417M /work/fhirserver/exec/64/fhirserver
# strings /work/fhirserver/exec/64/fhirserver | grep -i x11 | wc -l
243
# strings /work/fhirserver/exec/64/fhirserver | grep -i x11 | head
libgdk-x11-2.0.so.0
gdk_x11_get_default_xdisplay
gdk_window_impl_x11_get_type
gdk_x11_drawable_get_xdisplay
gdk_x11_colormap_get_xdisplay
gdk_x11_cursor_get_xdisplay
gdk_x11_image_get_ximage
gdk_x11_colormap_get_xcolormap
gdk_x11_display_get_xdisplay
gdk_x11_get_default_screen
Grahame Grieve (Oct 06 2021 at 22:10):
that'
Grahame Grieve (Oct 06 2021 at 22:10):
that's why I asked you about parameters. because some parameters will lead to guis, but we're not interested in them
Grahame Grieve (Oct 06 2021 at 22:11):
but all those are warnings...?
Josh Mandel (Oct 06 2021 at 22:13):
The spoilers I included above are the console output of the commands in big font. They don't look like warnings, but hard errors for the most part.
Grahame Grieve (Oct 06 2021 at 22:15):
but you said the spoilers were running without parameters?
Josh Mandel (Oct 06 2021 at 22:19):
The first set, yes. And then I posted another one. Each one has the full command I ran at the top
Grahame Grieve (Oct 06 2021 at 22:22):
I see the same command, different outcomes. so it's not predictable? or there's more going on?
Grahame Grieve (Oct 06 2021 at 22:30):
well, I suspect that the problem is the openSSL dependency, but I added some more logging, so try again
Josh Mandel (Oct 06 2021 at 22:36):
I do see hints of that when I strace the execution -- it first looks for X11 libraries in a "./tls" directory.
Grahame Grieve (Oct 06 2021 at 22:38):
nothing to do with me...
Grahame Grieve (Oct 06 2021 at 22:39):
presumably this is because gui stuff is linked in.
Grahame Grieve (Oct 06 2021 at 23:11):
anyway, let me know what the new log is
Josh Mandel (Oct 07 2021 at 00:23):
Still seeing all kinds of errors, nondeterministically. e.g.
$ docker run --rm -it fhirterm
2021-10-07--------------------------------
00:21:18 00:00:00 FHIR Server 1.9.363 Linux-64/FreePascal +Assertions +Debug
00:21:18 00:00:00 /work/fhirserver/exec/64/fhirserver -cmd exec -cfg http://tx.fhir.org/config -version 4
00:21:18 00:00:00 Loading Dependencies
00:21:18 00:00:00 SSL 1.1 from (default)
00:21:18 00:00:00 Timezone Data
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
corrupted double-linked list
... and it still expects X to be there even when called with the CLI args you provided.
Josh Mandel (Oct 07 2021 at 00:25):
Maybe 5% of the time now it ... doesn't immediately crash, but does output
[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$0000000000435B73
Josh Mandel (Oct 07 2021 at 00:27):
and then... proceeds to use 100% of available CPU for... we'll see how long
Grahame Grieve (Oct 07 2021 at 01:18):
weird. how would I investigate? Something really low level I'm taking for granted is not true
Grahame Grieve (Oct 07 2021 at 01:23):
https://forum.lazarus.freepascal.org/index.php/topic,56623.0.html
Grahame Grieve (Oct 07 2021 at 01:28):
maybe I should try the binary you're compiling?
Grahame Grieve (Oct 07 2021 at 01:35):
or vice versa
Josh Mandel (Oct 07 2021 at 01:39):
Huh. For sure you're welcome to try the thing I've compiled -- do you want it as part of the docker image, or just uploaded somewhere on its own?
Josh Mandel (Oct 07 2021 at 01:40):
I don't know the tool chain, so I don't really know what dependencies it has dynamically linked -- is it likely to be portable?
Grahame Grieve (Oct 07 2021 at 01:53):
should be, if I understand. Just the binary
Josh Mandel (Oct 07 2021 at 02:24):
https://cloudflare-ipfs.com/ipfs/QmZiEVubPt8aX6hbvNBQ7ebZ8sSzsqqAhUh5v6fqeYcM1U/fhirserver
Grahame Grieve (Oct 07 2021 at 03:22):
well, progress of a sort. Your binary bombs on my development PC exactly as you described.
Grahame Grieve (Oct 07 2021 at 03:23):
so it's something to do with the compile, not the execution environment. I will investigate
Grahame Grieve (Oct 07 2021 at 03:23):
is the docker image in the PR up to date?
Josh Mandel (Oct 07 2021 at 12:39):
Yes I'm keeping the docker file up to date. I will take it to use your build script today.
Josh Mandel (Oct 07 2021 at 15:45):
Looking now and will clean up the script you have -- but I'll note that this kind of monolithic script makes it very hard to cache layers -- like, with a typical Dockerfile when you run "docker build" the system is smart enough to use cached layers for any steps that have already completed. So, like, you'd want to avoid running the full fpclazup process every time you change a single line of source code in fhirserver. So I'll probably refactor these into "build/linux-setup.sh" that covers all the "dependencies" including dev tools and compiling dependent modules; and a "build/linux-compile-fhirserver.sh" or somesuch.
Josh Mandel (Oct 07 2021 at 16:32):
When I compile toolkit2/fhirtoolkit.lprI see:
(9015) Linking /work/fhirserver/server/C:/work/fhirserver/Exec/64/fhirserver
which I... don't expect to see ("C:/")
Josh Mandel (Oct 07 2021 at 17:05):
Similarly for:
(9022) Compiling resource >/work/fhirserver/server/lib/x86_64-linux/fhirserver.or
(9015) Linking >/work/fhirserver/server/C:/work/fhirserver/Exec/64/fhirserver
Josh Mandel (Oct 07 2021 at 17:35):
... but this is good progress -- I still need an X server running even with the "CLI" mode, but the sever now runs and tries to download vocabularies, then eventually fails at
17:18:09 00:10:03 Zero Configuration Process failed: Unable to write the entire buffer: '/root/fhir-server/sct_intl_20190731.cache'
17:18:09 00:10:03 First time, so can't continue.
EIOException: Unable to write the entire buffer: '/root/fhir-server/sct_intl_20190731.cache'
Josh Mandel (Oct 07 2021 at 18:36):
Grahame, can you clarify where libChakraCore.so needs to be in order for $BUILD/tools/lazarus/lazbuild server/fhirserver.lpr to succeed? (And is there any assumption about the current working directory when this command is executed?)
Josh Mandel (Oct 07 2021 at 18:52):
In the meantime, code at https://github.com/grahamegrieve/fhirserver/pull/128 is working (with a few documented workarounds in the PR) and I think it's ready to be merged
Grahame Grieve (Oct 07 2021 at 18:52):
Linking /work/fhirserver/server/C:/work/fhirserver/Exec/64/fhirserver
I forgot to includes the build mode
Grahame Grieve (Oct 07 2021 at 18:53):
Unable to write the entire buffer
ran out of space?
Grahame Grieve (Oct 07 2021 at 18:53):
where libChakraCore.so needs to be
same directory, but probably needs the build mode to be right
Josh Mandel (Oct 07 2021 at 18:59):
I'm not running out of space.
Josh Mandel (Oct 07 2021 at 18:59):
"same directory" as what?
Grahame Grieve (Oct 07 2021 at 19:01):
/exec/64
Grahame Grieve (Oct 07 2021 at 19:02):
are you still getting the "Unable to write the entire buffer" or is it working?
Josh Mandel (Oct 07 2021 at 19:03):
Re: libChakraCore: you mean exec/64 and not server/C:/work/fhirserver/Exec/64/, right? (the tzdat files need to be there which seems off).
Josh Mandel (Oct 07 2021 at 19:03):
Re: "unable to write entire buffer" this happened after several minutes/Gb of downloads
Josh Mandel (Oct 07 2021 at 19:04):
Not sure if it's what happens when there's a connectivity blip, or what.
Grahame Grieve (Oct 07 2021 at 19:04):
not server/C:/work/fhirserver/Exec/64/
I said that was because I forgot to include the build mode
Josh Mandel (Oct 07 2021 at 19:04):
OK -- let me know when I can revert this.
Grahame Grieve (Oct 07 2021 at 19:05):
I'll push soon.
Grahame Grieve (Oct 07 2021 at 19:05):
you didn't git pull in your script?
Josh Mandel (Oct 07 2021 at 19:05):
The script sets up the environment; it has by definition just cloned these repos.
Josh Mandel (Oct 07 2021 at 19:05):
May want a different script to do updates, if you're keeping the cloned folders alive over time.
Grahame Grieve (Oct 07 2021 at 19:05):
modularity, right. That might not true for linux-fhirserver.sh
Josh Mandel (Oct 07 2021 at 19:06):
If you're re-pulling dependencies you need to re-build them. So maybe there's a
- linux-setup
- linux-rebuild-dependenceis
- linux-fhirserver
Josh Mandel (Oct 07 2021 at 19:35):
(Refactored.)
Josh Mandel (Oct 07 2021 at 21:00):
Build is failing now at:
(10001) PPU Loading /work/fhirserver/packages/lib/x86_64-linux/v2_dictionary_database.ppu
(10011) PPU Source: v2_dictionary_database.pas not found
(10011) PPU Source: fhir.inc not available
(10028) Recompiling v2_dictionary_database, checksum changed for /work/fhirserver/server/lib/linux/fdb_manager.ppu
/work/fhirserver/library/v2/tests/v2_tests.pas(50,83) Fatal: (10022) Can't find unit v2_dictionary_database used by v2_tests
Fatal: (1018) Compilation aborted
I'm guessing this isn't my fault.
Josh Mandel (Oct 07 2021 at 21:07):
cp ./library/v2/v2_dictionary_database.pas library/v2/tests/
^^ this rescues it.
Grahame Grieve (Oct 07 2021 at 21:22):
maybe but something really bad is going on three
Grahame Grieve (Oct 07 2021 at 21:23):
you hacked it to make it worse later
Grahame Grieve (Oct 07 2021 at 21:25):
but I can't tell what the actual problem is without more output
Josh Mandel (Oct 07 2021 at 21:54):
What output would you like?
Josh Mandel (Oct 07 2021 at 22:10):
I've set up a GH actions build, so logs should be at https://github.com/jmandel/fhirserver/runs/3832657077?check_suite_focus=true (... I'm assuming it'll break the same way it does for me locally; will take >10min to find out.)
Grahame Grieve (Oct 07 2021 at 22:20):
how to trigger this?
Josh Mandel (Oct 07 2021 at 22:22):
https://github.com/jmandel/fhirserver/runs/3832657077?check_suite_focus=true#step:3:22720 is the error I'm getting, in the context of the full log
Josh Mandel (Oct 07 2021 at 22:22):
(Every push triggers this.)
Josh Mandel (Oct 07 2021 at 22:23):
(Every push to my fork, that is; if you merge my fork, you'll have the same behavior, which you may or may not care for.)
Grahame Grieve (Oct 07 2021 at 22:33):
I do want a build process like this, yes
Grahame Grieve (Oct 07 2021 at 22:34):
but I can't understand the error. It happens when the packages have overlapping search paths, and I can't find any
Grahame Grieve (Oct 07 2021 at 22:37):
are you still cloning the source file? (What is the source for those builds. btw?)
Josh Mandel (Oct 07 2021 at 22:44):
No, as I said, introducing that cp *fixed` the build and it all seems to work swimmingly.
Josh Mandel (Oct 07 2021 at 22:45):
But I removed it to show you the errors.
Josh Mandel (Oct 07 2021 at 22:45):
https://github.com/jmandel/fhirserver/blob/patch-3/Dockerfile is the source for the build
Josh Mandel (Oct 07 2021 at 22:46):
(and https://github.com/jmandel/fhirserver/blob/patch-3/.github/workflows/linux-docker-build.yml kicks it off)
Grahame Grieve (Oct 07 2021 at 22:46):
what's entrypoint.sh about?
Josh Mandel (Oct 07 2021 at 22:47):
entrypoint.sh is the script that runs every time the container starts. It
- starts a headless X server
-
executes fhirserver with any CLI arguments passed in to the image, or if none are passed, defaults to
*["-cmd", "exec", "-cfg", "http://tx.fhir.org/config", "-version", "4", "-local", "$TERMINOLOGY_CACHE"] -
Evaluates any CLI arguments as needed so,
$TERMINOLOGY_CACHEcan be an environment variable
Josh Mandel (Oct 07 2021 at 22:49):
The idea here is that with entrypoint.sh set up this way, someone can invoke the fhir server as:
docker run fhir/fhirserver -cmd exec -cfg https://some-other-cfg -version 5
or whatever other combination of args they want to pass in.
Josh Mandel (Oct 07 2021 at 22:50):
The docker run fhir/fhirserver bit will act a lot like just running the fhirsever binary (i.e., you can pass it the same args you'd pass the binary), but it takes care of setting up the environment first.
Grahame Grieve (Oct 07 2021 at 22:53):
for the github pull action, we want to run tests not execute the server, of course. But we're not up to that yet
Grahame Grieve (Oct 07 2021 at 22:55):
i don't understand line 7 of the dockerfile
Josh Mandel (Oct 07 2021 at 22:58):
COPY build/linux-toolchain.sh build/linux-update-dependencies.sh /work/bootstrap/
The operating model here is that you're starting from a blank slate (fresh Ubuntu filesystem) each time you do a docker build. The only way files get into that filesystem is to copy them in, or to download them from within the build process. COPY takes files from the host directory and puts them into the image.
Here, I copy just a couple of files into the image instead of copying the whole git repo, because of the way Docker builds are cached. Docker's smart enough to notice that the inputs (build/linux-toolchain.sh, build/linux-update-dependencies.sh) haven't changed, so it re-uses the "layer" it has created up through line 13, meaning I don't have to download and re-install the pascal compiler every time I change a single file in the FHIR server's source tree.
Josh Mandel (Oct 07 2021 at 22:59):
In line 13 I COPY in the full git repo, because... well, at this point I need to actually build the code.
Grahame Grieve (Oct 07 2021 at 23:00):
line 7 you copy the two scripts... but you don't need to?
Grahame Grieve (Oct 07 2021 at 23:01):
oh no I see.
Grahame Grieve (Oct 07 2021 at 23:23):
my real question was, why did you copy them somewhere else. But I think the answer was 'just because' not 'I actually needed ot'
Grahame Grieve (Oct 07 2021 at 23:23):
anyway, I can reproduce the problem.
Josh Mandel (Oct 07 2021 at 23:32):
my real question was, why did you copy them somewhere else
You mean, to /work/bootstrap instead of to /work/fhirserver? I could have copied to /work/fhirserver/build, yes.
Josh Mandel (Oct 07 2021 at 23:32):
Grahame Grieve: anyway, I can reproduce the problem.
Excellent
Grahame Grieve (Oct 07 2021 at 23:49):
and I fixed them. I updated the scripts in the master repo - the build should work once you get them
Josh Mandel (Oct 08 2021 at 00:14):
Thanks -- grabbed.
Josh Mandel (Oct 08 2021 at 00:37):
https://github.com/grahamegrieve/fhirserver/blob/master/build/linux-toolchain.sh#L26 Why did you add this back
Grahame Grieve (Oct 08 2021 at 00:46):
oversight
Josh Mandel (Oct 08 2021 at 00:49):
Which change was the fix for the compile error I was hitting?
Grahame Grieve (Oct 08 2021 at 00:49):
deleting the .ppu and .o files
Grahame Grieve (Oct 08 2021 at 00:50):
thought that might not be necessary after my next push. I'll let you know
Grahame Grieve (Oct 08 2021 at 02:08):
not necessary - I found the problem. weird how it turned up in the wrong place. Anyway, the build scripts work nicely for me now
Grahame Grieve (Oct 08 2021 at 09:59):
there's going to be test cases.. and one of the thing the tests need is a big snomed file.
Grahame Grieve (Oct 08 2021 at 09:59):
not sure how to deploy that - can't put it in git...
Josh Mandel (Oct 08 2021 at 16:13):
How often will these large files change? Do they need to be under version control (where the contents of the test file might need to change even though the file name remains static) or can they be represented with some kind of a content addressing scheme (where you would change the "file open" code in your test cases to specify a new file name when the vocabulary changes)?
Rob Hausam (Oct 08 2021 at 16:59):
Maybe this will help?
Josh Mandel (Oct 08 2021 at 18:03):
If there's a need for version control, then yes -- but the GH implementation of git-lfs is not free, and I'm not sure we have the need. That's what my questions above are intended to elicit.
Grahame Grieve (Oct 08 2021 at 18:15):
no need for version control. it hasn't changed for years. I'm going to put it on my website
Josh Mandel (Oct 08 2021 at 18:17):
Perfect. Put it on your website, the GH actions config can run wgetit to make it locally available before the tests run, and we can use GH Actions caching to prevent re-fetches across runs.
Grahame Grieve (Oct 08 2021 at 18:21):
the test cases need an configuration file with file locations and passwords / key pair locations + passphrases. how should we manage that?
Josh Mandel (Oct 08 2021 at 18:24):
They should be managed with GH Secrets and exposed to the container as environment variables.
Grahame Grieve (Oct 08 2021 at 18:25):
The locations are set by the .sh files. can the .sh write them and the environment variables to a config file?
Josh Mandel (Oct 08 2021 at 18:35):
Not exactly. There's no secure storage area you can write to between invocations, so what happens instead is you can paste a config file (embedding whatever secrets, etc) into https://github.com/jmandel/fhirserver/settings/secrets/actions and then have a step in the gh actions script that prints this to a file, so it's available.
Josh Mandel (Oct 08 2021 at 18:35):
(Or instead of a full config file as one secret, you can break this down into individual secrets that are managed separately.)
Grahame Grieve (Oct 08 2021 at 18:38):
sorry, I asked slightly the wrong question. I should have asked:
The locations are set by the parameters passed to the .sh files. can the GH Actions write them and the environment variables to a config file?
Josh Mandel (Oct 08 2021 at 18:43):
GH Actions lets you run arbitrary scripts. And lets you read secrets that have been configured from the web portal. I'm not really sure what kind of workflow you are describing, but if it can be expressed as a shell script that takes secrets as environment variables, and it can set up the whole environment required by the test scripts before running the test scripts, then it will work.
Grahame Grieve (Oct 08 2021 at 18:46):
right. so what kind of config files can the shell scripts write to? A ini file? Because that's what currently happens - there's a file /work/fhirserver/exec/64/test-settings.ini that provides all the parameters:
[locations]
fhirserver=c:\work\fhirserver
fhir-test-cases=c:\work\org.hl7.fhir\fhir-test-cases
markdown=c:\work\pascal\markdown
snomed=C:\work\fhirserver\testcases\snomed\snomed.cache
[mssql]
driver=SQL Server
server=(local)
database=test
[mysql]
driver=MySQL ODBC 8.0 Unicode Driver
server=34.122.27.199
database=test
username=test
password=XXX
[email]
sender=fhir-server@healthintersections.com.au
password=XXXX
destination=grahameg@gmail.com
[ssl]
cert=C:\work\RDPs\certificates\new\fhir.org.crt
key=C:\work\RDPs\certificates\new\fhir.org.key
cacert=C:\work\RDPs\certificates\new\fhir.org.int.crt
password=XXX
Grahame Grieve (Oct 08 2021 at 18:57):
the source for the snomed file is at http://www.healthintersections.com.au/FhirServer/snomed.test.cache
Josh Mandel (Oct 08 2021 at 19:09):
So if you want to, you could take a version of exactly that config file (with all the details filled in) you listed here and throw it into a secret. Then we could just echo that secret into any file location you wanted right before running the tests.
Josh Mandel (Oct 08 2021 at 19:10):
It appears that the secret points to other files that are also secrets; so we would need to capture those as well, if I'm understanding the format correctly.
Josh Mandel (Oct 08 2021 at 19:10):
But there is no way that you want to load production server secrets like a TLS key for the fhir.org website as a prerequisite for running tests, right?
Josh Mandel (Oct 08 2021 at 19:11):
Similarly, I'm not sure why the tests would be connecting to an externally hosted MySQL database.
Grahame Grieve (Oct 08 2021 at 19:13):
there's a test case for checking that all the database infrastructure for MySQL works.
Grahame Grieve (Oct 08 2021 at 19:13):
it doesn't have to be external
Grahame Grieve (Oct 08 2021 at 19:14):
same for mssql
Grahame Grieve (Oct 08 2021 at 19:14):
and I wouldn't use the production key for fhir.org in the tests, but I did internally, since I have to have it anyway
Grahame Grieve (Oct 08 2021 at 19:15):
we could check in a testing key and just have the passphrase as the secret
Josh Mandel (Oct 08 2021 at 19:15):
What are the things that actually need to be secret that the tests require to run?
Grahame Grieve (Oct 08 2021 at 19:27):
the secrets:
- email password
- ssl passphrase
local config:
- where the files are
- what the email addresses are
- what the database details are
Josh Mandel (Oct 08 2021 at 19:30):
For ssl, we could just generate a certificate each time the tests run, so this would not need to be a secret.
For email, can you give me the quick rundown on where and how the test suite is interacting with email?
Grahame Grieve (Oct 08 2021 at 19:35):
it sends a test email, to check that emailing works. It occasionally fails, when google introduces a new security requirement
Josh Mandel (Oct 08 2021 at 20:39):
Okay, so sounds that's the only true secret in the process.
Grahame Grieve (Oct 08 2021 at 20:43):
right. the destination email address and sender email address are configured, but not secret
Josh Mandel (Oct 10 2021 at 21:31):
OK, so tests are running at this point; you can see passing/failing/error output at https://github.com/jmandel/fhirserver/runs/3853245288?check_suite_focus=true#step:5:17890 (I don't really understand the outputs but I expect you might, Grahame.)
(To make this work, I added https://github.com/jmandel/fhirserver/blob/patch-3/fixtures/test-settings.ini.template and I fill out the template at runtime via https://github.com/jmandel/fhirserver/blob/patch-3/.github/workflows/linux-docker-build.yml#L33)
Grahame Grieve (Oct 10 2021 at 22:38):
do the first think it is that it looks like the setting locations/fhirserver is missing or blank
[locations]
fhirserver=
Grahame Grieve (Oct 10 2021 at 22:38):
that's the home directory for the fhirserver repo itself
Grahame Grieve (Oct 10 2021 at 22:38):
and also locations/snomed
Josh Mandel (Oct 10 2021 at 22:58):
do the first think it is that it looks like the setting locations/fhirserver is missing or blank
So, this should be set to /work/fhirserver, per https://github.com/jmandel/fhirserver/blob/patch-3/.github/workflows/linux-docker-build.yml#L19 -- is that the wrong value, or are you saying it's not actually getting set to that value?
Grahame Grieve (Oct 10 2021 at 22:59):
it's not getting set to any value
Grahame Grieve (Oct 10 2021 at 22:59):
there's no evidence I can see that anything in there is set
Josh Mandel (Oct 10 2021 at 23:01):
Hmm, I'll add some debug printouts.
Josh Mandel (Oct 10 2021 at 23:01):
When I run locally, what can I look for to determine if these settings are being picked up?
Grahame Grieve (Oct 10 2021 at 23:06):
well, I just committed some a to print the locations explicitly
Josh Mandel (Oct 10 2021 at 23:07):
Awesome. I'll merge that.
Josh Mandel (Oct 10 2021 at 23:08):
On the plus side, I am getting
(Though I'm not sure how to tell if that's coming from running the tests locally, or in GH actions.)
Grahame Grieve (Oct 10 2021 at 23:09):
if you got that, then the email password bit is working for sure
Josh Mandel (Oct 11 2021 at 00:08):
https://github.com/jmandel/fhirserver/runs/3853692645?check_suite_focus=true#step:5:55 your logs indicate the location is populated, I think?
Grahame Grieve (Oct 11 2021 at 00:14):
certainly do.
Grahame Grieve (Oct 11 2021 at 00:14):
so it's real weird. The file evidently existed, since it's read on line 50. But then it's not found on line 75
Grahame Grieve (Oct 11 2021 at 00:15):
oh
Grahame Grieve (Oct 11 2021 at 00:16):
apparently some of the tests assume that the current directory is the same as the directory that the executable is run from. There aren't supposed to be any, but there are
Grahame Grieve (Oct 11 2021 at 00:24):
looks to me like the snomed location is wrong though
Grahame Grieve (Oct 11 2021 at 00:34):
I fixed the tests that stood out and added more logging - try again
Josh Mandel (Oct 11 2021 at 02:30):
Cool -- https://github.com/jmandel/fhirserver/runs/3854355842?check_suite_focus=true#step:7:52 confirms that snomed.test.cache exists; more logs below.
Josh Mandel (Oct 11 2021 at 02:32):
I see the problem
Josh Mandel (Oct 11 2021 at 02:32):
snomed.test.cache vs snomed.cache
Josh Mandel (Oct 11 2021 at 02:33):
Fixing that now.
Grahame Grieve (Oct 11 2021 at 03:46):
I added some more debugging if you could update- thanks
Josh Mandel (Oct 11 2021 at 04:08):
https://github.com/jmandel/fhirserver/actions/runs/1327450135 should have more in 15min or so
Grahame Grieve (Oct 11 2021 at 05:03):
so the piece that's failing in one of the tests is
FileSetReadOnly(filename, true);
FileDelete(filename);
assertTrue(FileExists(filename), 'FileExists(filename) #3');
Grahame Grieve (Oct 11 2021 at 05:04):
FileSetReadyOnly is
if readOnly then
i := fpchmod(filename, S_IRUSR or S_IRGRP or S_IROTH or S_IRUSR or S_IXGRP or S_IXOTH)
else
i := fpchmod(filename, S_IRWXU or S_IRWXG or S_IRWXO);
Grahame Grieve (Oct 11 2021 at 05:04):
so the readonly file can't be deleted on my linux box but can be on the CI build... wonder why it would be different?
Grahame Grieve (Oct 11 2021 at 06:45):
I think I've fixed the TestFslDateTime test - relied on an implied timezone
Grahame Grieve (Oct 11 2021 at 06:45):
testWebServer_110 [00.000] fail @?#?: CA SSL Certificate not found at /work/fhiserver/fixtures/rootCA.crt - looks like a set up thing?
Grahame Grieve (Oct 11 2021 at 06:47):
the mysql test - can you add installing the mysql odbc driver?
Grahame Grieve (Oct 11 2021 at 06:47):
the TestSQLite is confusing - is it possible that /tmp doesn't exist, or access is denied?
Josh Mandel (Oct 11 2021 at 13:45):
Grahame Grieve: so the readonly file can't be deleted on my linux box but can be on the CI build... wonder why it would be different?
Are you writing unit tests for the OS (i.e., testing that the OS is providing the protection it claims to be)? Like, as a regular user if I own a file with 400 permissions, I can still delete it -- like
$ls -l ownj_deletej
-r-------- 1 jmandel jmandel 0 Oct 11 08:40 ownj_deletej
$ rm -f ownj_deletej
If I leave out -f ("force"), I get a prompt like "rm: remove write-protected regular empty file 'ownj_deletej'?" -- and with -f, the file is deleted straightaway. So the fact that it's "readonly" doesn't mean that the owner can't delete it.
Josh Mandel (Oct 11 2021 at 13:47):
I'm not sure what your FileDelete is intended to do, but you may need "softer" behavior. Keep in mind that during the CI process these tests are running in a docker container as root; that might explain the differences you're seeing, and making the server run as an unprivileged user would be nice for other reasons; we can start a separate thread on that once we've got the basics ironed out.
Josh Mandel (Oct 11 2021 at 13:49):
/work/fhiserver/fixtures/rootCA.crt
https://github.com/jmandel/fhirserver/tree/patch-3/fixtures should be mounted at /work/fhirserver/fixtures -- does your error message indicate the file isn't found, or just that there's something unexpected/wrong about the file?
Josh Mandel (Oct 11 2021 at 13:52):
Re: DB tests, I'm hesitate to dive in here because the configuration space is big and I don't know that I'll be able to see this all the way through. Do you have a complete step by step writeup detailing the components and setup required? https://github.com/grahamegrieve/fhirserver/blob/master/linux-install-instructions.txtdoesn't mention mysql
Grahame Grieve (Oct 11 2021 at 21:16):
to rootCA file... it doesn't exist - or doesn't look like it does to the fhirserver
Grahame Grieve (Oct 11 2021 at 21:17):
the root thing is probably the difference for the file test. I'm thinking about that.
Grahame Grieve (Oct 11 2021 at 21:17):
I would very much like to get at least the mysql test working - it's a forerunner for a whole lot of tests I have yet to add into the linux version that will use a mysql store
Josh Mandel (Oct 11 2021 at 21:25):
Grahame Grieve: the root thing is probably the difference for the file test. I'm thinking about that.
to rootCA file... it doesn't exist - or doesn't look like it does to the fhirserver
I'm not sure how this could happen; it's part of the repo that's copied into the container at build time. What makes you say it's absent?
Josh Mandel (Oct 11 2021 at 21:26):
Grahame Grieve: I would very much like to get at least the mysql test working - it's a forerunner for a whole lot of tests I have yet to add into the linux version that will use a mysql store
OK. If you can document the setup process (starting from: host machine has a mysql server running but nothing set up) we can try to replicate this in CI.
Grahame Grieve (Oct 11 2021 at 21:26):
working on the set up
Josh Mandel (Oct 11 2021 at 21:26):
All Tests [12:23.300] : 3176 ok, 7 errors, 3 failed
That's pretty good though :-)
Grahame Grieve (Oct 11 2021 at 21:27):
it is good.
Grahame Grieve (Oct 11 2021 at 21:27):
assertTrue(FileExists(TestSettings.SSLCAFile), 'CA SSL Certificate not found at '+TestSettings.SSLCAFile);
Josh Mandel (Oct 11 2021 at 21:27):
Typo
Josh Mandel (Oct 11 2021 at 21:27):
That'd do the trick.
Josh Mandel (Oct 11 2021 at 21:28):
/work/fhiserver/fixtures/rootCA.crt
I should put an r in FHIR. Can't forget the "resoruces".
Grahame Grieve (Oct 11 2021 at 21:28):
I make both those typos often too
Grahame Grieve (Oct 12 2021 at 10:58):
ok. mysql commands to set up a working test environment from vanilla set up:
Grahame Grieve (Oct 12 2021 at 10:58):
create user 'test'@'%' identified by 'test';
create database test;
GRANT ALL PRIVILEGES ON test.* TO 'test'@'%';
flush privileges;
Josh Mandel (Oct 12 2021 at 12:41):
And how do we tell the test suite what host and port the DB is running on?
Josh Mandel (Oct 12 2021 at 12:42):
And what version of mysql?
Jose Costa Teixeira (Oct 12 2021 at 14:10):
I have MariaDB 10.4.20 working
Jose Costa Teixeira (Oct 12 2021 at 14:10):
mysql had some issues that I don't recall, sorry
Jose Costa Teixeira (Oct 12 2021 at 14:12):
I also remember having to add this to the configuration (my.ini):
query_cache_size = 64M
#query_cache_size = 0
query_cache_min_res_unit =2
tmp_table_size = 128M
max_heap_table_size = 128M
#skip-name-resolve
innodb_file_per_table = 1
innodb_buffer_pool_size = 1280M
lower_case_table_names = 1
max_binlog_size = 100M
expire_logs_days=2
innodb_ft_min_token_size=1
ft_min_word_len=2
autocommit=1
connect_timeout=240
long_query_time=180
transaction-isolation = READ-COMMITTED
character-set-server = utf8
collation-server = utf8_general_ci
innodb_flush_method=O_DIRECT
optimizer_switch=orderby_uses_equalities=off
max_allowed_packet=128M
Jose Costa Teixeira (Oct 12 2021 at 14:14):
my DB init commands are the same as Grahame writes, except I added utf8 explicitly
CREATE DATABASE fhirDB CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Jose Costa Teixeira (Oct 12 2021 at 14:14):
(Don't know if this helps. I'm trying to catch up, let me know if I can do something - maybe I can take mysql setup because I've done it once)
Josh Mandel (Oct 12 2021 at 14:18):
Wow. This is a lot of config just to support running tests.
Jose Costa Teixeira (Oct 12 2021 at 14:54):
sorry, not for tests, that was for the prod-like server
Jose Costa Teixeira (Oct 12 2021 at 14:54):
(i missed the context)
Josh Mandel (Oct 12 2021 at 15:03):
I think there's a MySQL server in place now (mysql8, host: "mysql", as communicated via .ini param at https://github.com/jmandel/fhirserver/blob/patch-3/fixtures/test-settings.ini.template#L14); I'm still seeing errors from https://github.com/jmandel/fhirserver/runs/3871257411?check_suite_focus=true#step:10:56
Jose Costa Teixeira (Oct 12 2021 at 15:23):
OK then I'll test the proper config and do the same thing as I did before - check if the text indexing is working , etc. If it's mysql, then we use that
Grahame Grieve (Oct 12 2021 at 18:19):
port defaults to normal. I haven't got a config for that.
Grahame Grieve (Oct 12 2021 at 18:19):
host = server
Grahame Grieve (Oct 12 2021 at 18:19):
version doesn't matter for the tests
Grahame Grieve (Oct 12 2021 at 18:25):
you also have to install the MySQL odbc driver - which I believe is:
wget https://dev.mysql.com/get/Downloads/Connector-ODBC/8.0/mysql-connector-odbc_8.0.26-1ubuntu20.04_amd64.deb
dpkg -i mysql-connector-odbc_8.0.26–1ubuntu20.04_amd64.deb
Grahame Grieve (Oct 12 2021 at 18:36):
also can you update from the master - I have some changes to the code.
Josh Mandel (Oct 12 2021 at 20:33):
host = server
I don't know what this means.
Josh Mandel (Oct 12 2021 at 20:35):
Grahame Grieve: also can you update from the master - I have some changes to the code.
Done.
Josh Mandel (Oct 12 2021 at 21:43):
Re: that mysql connector, somehow their ubuntu release has like hundreds of megs of dependencies. What even is this?
Grahame Grieve (Oct 12 2021 at 22:21):
it's the ODBC driver for mysql for linux?
Grahame Grieve (Oct 12 2021 at 22:22):
host = server
you asked, how do you specify the host. That's the server setting in the test-settings.ini... or do I mis-understand?
Josh Mandel (Oct 12 2021 at 22:27):
Oh, yeah I guess I already populated the host value then.
Josh Mandel (Oct 12 2021 at 22:28):
Re; ODBC driver, that doesn't install for me because one of the dependencies is no longer available. The whole distribution process for that driver seems super sketchy and weird, like bad printer drivers.
Grahame Grieve (Oct 12 2021 at 22:37):
totally agree. it's not a good thing
Grahame Grieve (Oct 12 2021 at 22:47):
but it does work for me. what dependency is no longer available?
Josh Mandel (Oct 12 2021 at 22:54):
I'm not at the computer anymore, but something like mysql-community-blah
Grahame Grieve (Oct 13 2021 at 19:25):
@Josh Mandel some follow up quetsions on all this. First of all, thanks for doing all this - I appreciate it greatly.
- what's Dockerfile.slimmed?
- we still don't have the tests running?
- how does the build work if it executes a process that doesn't finish?
Josh Mandel (Oct 13 2021 at 19:37):
what's Dockerfile.slimmed?
Right now the Docker image you get if you run docker build -f Dockerfile includes the whole fpc toolchain, source code, dev packages, etc. The slimmed package just takes a raw ubuntu image and copies in the compiled output from the build process. If someone wanted a simple way to distribute/run the fhirserver using a Docker registry (i.e., so anyone in the world could just docker run hl7fhir:fhirserver and have it up and running), something like this slimmed image would be the right starting point.
Josh Mandel (Oct 13 2021 at 19:38):
we still don't have the tests running?
Tests are running, so I assume your question is why they're not passing. Current blocker: I don't have a way to install the mysql dependency you said is necessary.
Josh Mandel (Oct 13 2021 at 19:40):
how does the build work if it executes a process that doesn't finish?
Right now, it'll just run until the GH Actions timeout hits (360 min by default; we could set this lower with a param in the GH Actions job).
Josh Mandel (Oct 13 2021 at 19:40):
First of all, thanks for doing all this - I appreciate it greatly.
You're welcome. It has been a learning experience!
Josh Mandel (Oct 13 2021 at 19:54):
I'm thinking it may be easier to install the binary release for mysql odbc rather than the borked ubuntu packages.
Grahame Grieve (Oct 13 2021 at 19:55):
yes indeed, the binary release is what I've been installing
Grahame Grieve (Oct 13 2021 at 19:55):
how are the tests running? the docker ends with :
CMD ["-cmd", "exec", "-cfg", "http://tx.fhir.org/config", "-version", "4", "-local", "$TERMINOLOGY_CACHE"]
Josh Mandel (Oct 13 2021 at 19:56):
- but you pointed me to the ubuntu packes at https://dev.mysql.com/get/Downloads/Connector-ODBC/8.0/mysql-connector-odbc_8.0.26-1ubuntu20.04_amd64.deb rather than the generic release tarball at https://dev.mysql.com/get/Downloads/Connector-ODBC/8.0/mysql-connector-odbc-8.0.26-linux-glibc2.12-x86-64bit.tar.gz :-)
Grahame Grieve (Oct 13 2021 at 19:57):
did I? I'm very sorry if I did that
Josh Mandel (Oct 13 2021 at 19:57):
The CMD line defines the default args that will be passed in when the container starts, if no other CLI args are passed
Grahame Grieve (Oct 13 2021 at 19:57):
hmm what overrides that?
Josh Mandel (Oct 13 2021 at 19:57):
But we run the container in the test script at https://github.com/jmandel/fhirserver/blob/109745215693e144ee645bc3f1a4d3c2db3310f5/.github/workflows/linux-docker-build.yml#L70
Josh Mandel (Oct 13 2021 at 19:58):
Where we call it with:
-tests
Josh Mandel (Oct 13 2021 at 19:59):
At https://chat.fhir.org/#narrow/stream/179281-pascal/topic/Automating.20fhirserver.20build/near/257249473 you did -- but you wrote "I believe" and not "I promise" ;-)
Josh Mandel (Oct 13 2021 at 19:59):
We'll see how the tests at https://github.com/jmandel/fhirserver/runs/3887155777?check_suite_focus=true do -- mysql-odbc is now being installed without errors.
Josh Mandel (Oct 13 2021 at 20:07):
(Well, almost being installed without errors. Tweaking...)
Grahame Grieve (Oct 13 2021 at 20:19):
where do I find all the apt -install stuff?
Josh Mandel (Oct 13 2021 at 20:24):
I don't understand the question.
BTW I just committed https://github.com/jmandel/fhirserver/commit/99b42f04a4db898ebf45b611f060718eedf3be7a because some of these lpk files don't exist (but previously this wasn't causing errors; not sure why.)
Grahame Grieve (Oct 13 2021 at 20:49):
oh. I was getting to that
Grahame Grieve (Oct 13 2021 at 20:53):
no I had fixed it - you want what is in my repo
Grahame Grieve (Oct 13 2021 at 20:58):
where do I find all the apt -install stuff?
we need to install git, mysql, wget, unixodbc etc. Where does this happen in the set up?
Josh Mandel (Oct 13 2021 at 21:18):
we need to install git, mysql, wget, unixodbc etc. Where does this happen in the set up?
https://github.com/jmandel/fhirserver/blob/patch-3/Dockerfile#L5-L12
(Note that mysql itself isn't installed in the docker image; it's a service we're running in a sibling docker container accessible over the network as host mysql, created here.)
Josh Mandel (Oct 13 2021 at 21:22):
Still seeing errors at https://github.com/jmandel/fhirserver/runs/3887632649?check_suite_focus=true#step:10:67 even after installing libs/bins from https://dev.mysql.com/get/Downloads/Connector-ODBC/8.0/mysql-connector-odbc-8.0.26-linux-glibc2.12-x86-64bit.tar.gz
Grahame Grieve (Oct 13 2021 at 21:28):
I don't know what the error means.
Grahame Grieve (Oct 13 2021 at 21:29):
can we get a list of the odbc drivers installed after the mysql driver is installed? It might be that the driver name is slightly different?
Josh Mandel (Oct 13 2021 at 21:29):
Grahame Grieve: can we get a list of the odbc drivers installed after the mysql driver is installed? It might be that the driver name is slightly different?
I have no idea. How do you get a list of ODBC drivers, and how do you tell ODBC drivers from every other library present on the system?
Josh Mandel (Oct 13 2021 at 21:30):
I can get you the library name..
Josh Mandel (Oct 13 2021 at 21:31):
mysql-connector-odbc-8.0.26-linux-glibc2.12-x86-64bit/lib/libmyodbc8w.so
mysql-connector-odbc-8.0.26-linux-glibc2.12-x86-64bit/lib/libmyodbc8a.so
these are copied into /usr/local/lib
Grahame Grieve (Oct 14 2021 at 04:04):
@Josh Mandel what do you think of this?
Grahame Grieve (Oct 14 2021 at 04:04):
echo "## ODBC info"
odbcinst -j
echo "$(</etc/odbcinst.ini)"
Grahame Grieve (Oct 14 2021 at 04:04):
output:
#14 0.054 ## ODBC info
#14 0.056 unixODBC 2.3.6
#14 0.056 DRIVERS............: /etc/odbcinst.ini
#14 0.056 SYSTEM DATA SOURCES: /etc/odbc.ini
#14 0.056 FILE DATA SOURCES..: /etc/ODBCDataSources
#14 0.056 USER DATA SOURCES..: /root/.odbc.ini
#14 0.056 SQLULEN Size.......: 8
#14 0.056 SQLLEN Size........: 8
#14 0.056 SQLSETPOSIROW Size.: 8
#14 0.056 /work/fhirserver/build/linux-fhirserver.sh: line 7: /etc/odbcinst.ini: No such file or directory
Grahame Grieve (Oct 14 2021 at 04:05):
where in the chain does mysql get set up?
Josh Mandel (Oct 14 2021 at 13:52):
I don't know exactly what you are asking. I copy the library files in the first step of the docker file. But I don't do anything that would generate /etc/odbcinst.ini. what is this file and who is responsible for creating it? What should it contain and how should it come to contain that?
I think this is clear, but the doker image does not include any MySQL server components. It only contains the client components that you have pointed me to.
Josh Mandel (Oct 14 2021 at 13:54):
Okay I have one lead anyway.
Josh Mandel (Oct 14 2021 at 13:55):
https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation-binary-unix-tarball.html contains steps three and four which perhaps I should consider following in addition to steps 1 and 2
Josh Mandel (Oct 14 2021 at 15:55):
OK, now there should be something like the following present in the docker environment:
$ cat /etc/odbcinst.ini
[MySQL ODBC 8.0 Driver]
Driver=/usr/local/lib/libmyodbc8w.so
UsageCount=1
[MySQL ODBC 8.0]
Driver=/usr/local/lib/libmyodbc8a.so
UsageCount=1
Josh Mandel (Oct 14 2021 at 15:57):
Indeed your logs show:
#14 [ 9/10] RUN /work/fhirserver/build/linux-fhirserver.sh /work/bootstrap
#14 0.083 ## ODBC info
#14 0.085 unixODBC 2.3.6
#14 0.085 DRIVERS............: /etc/odbcinst.ini
#14 0.085 SYSTEM DATA SOURCES: /etc/odbc.ini
#14 0.085 FILE DATA SOURCES..: /etc/ODBCDataSources
#14 0.085 USER DATA SOURCES..: /root/.odbc.ini
#14 0.085 SQLULEN Size.......: 8
#14 0.085 SQLLEN Size........: 8
#14 0.085 SQLSETPOSIROW Size.: 8
#14 0.087 [MySQL ODBC 8.0 Driver]
#14 0.087 Driver=/usr/local/lib/libmyodbc8w.so
#14 0.087 UsageCount=1
#14 0.087
#14 0.087 [MySQL ODBC 8.0]
#14 0.087 Driver=/usr/local/lib/libmyodbc8a.so
#14 0.087 UsageCount=1
Grahame Grieve (Oct 14 2021 at 19:17):
great thanks
Josh Mandel (Oct 14 2021 at 21:56):
Progress! https://github.com/jmandel/fhirserver/runs/3899833569?check_suite_focus=true#step:10:53 makes it look like some database tests are actually running (and failing, but hey) !
Grahame Grieve (Oct 14 2021 at 22:06):
well, they all pass now, except for MSSQL which is being ignored, but wrongly counted as an error in the wash up. So I have to sort out that, and get to the bottom of the timezone issue causing another failure. And then there's smtp password issue - can we get to that?
Josh Mandel (Oct 14 2021 at 22:11):
SMTP password should be covered. In my fork I'm using a gmail account that I registered for this purpose; we can configure it however you like in your repository.
Grahame Grieve (Oct 14 2021 at 22:14):
"Must provide password for SMTP test in /work/fhirserver/exec/64/test-settings.ini"
Grahame Grieve (Oct 14 2021 at 22:14):
FHIRSERVER_EMAIL_PASSWORD is blank then
Josh Mandel (Oct 14 2021 at 23:50):
Hmm, I may be messing that up. Will review.
Josh Mandel (Oct 15 2021 at 03:25):
image.png
https://github.com/jmandel/fhirserver/runs/3901846542?check_suite_focus=true
Josh Mandel (Oct 15 2021 at 03:26):
And I don't know why you say the email password is blank; I'm getting:
Josh Mandel (Oct 15 2021 at 03:30):
I merged this into your master branch now @Grahame Grieve . You can:
- Update https://github.com/grahamegrieve/fhirserver/blob/master/.github/workflows/linux-docker-build.yml#L49 to set
FHIRSERVER_EMAIL_SENDERwith the gmail account you like - Use https://github.com/grahamegrieve/fhirserver/settings/secrets/actions to add a Repository Secret called
FHIRSERVER_EMAIL_PASSWORDwith the value of your choice, like:
Josh Mandel (Oct 15 2021 at 03:30):
(I can't do this for you without admin access on the repo.)
Grahame Grieve (Oct 15 2021 at 03:35):
done. Hopefully, that'll mean all tests pass
Grahame Grieve (Oct 15 2021 at 04:18):
yay they did! awesome
Grahame Grieve (Oct 15 2021 at 21:48):
one last question... reading about how to release the linux server turns into a typical linux experience - a myriad of ways to do it, most of them probably wrong, and I don't know which. I particularly liked this line in the ubuntu package documentation:
Setting pbuilder up is very easy, run:
$ pbuilder-dist <release> create
where <release> is for example xenial, zesty, artful or in the case of Debian maybe sid or buster.
whatever "xenial, zesty, artful or in the case of Debian maybe sid or buster" might be. No hint as to what they are or why you'd chose one over the other, or maybe you have to do them all. So typical... (or even why 'in the case of debian' since this is a ubuntu guide)
Jose Costa Teixeira (Oct 15 2021 at 22:13):
They are Ubuntu release codenames
Jose Costa Teixeira (Oct 15 2021 at 22:14):
https://wiki.ubuntu.com/Releases
Jose Costa Teixeira (Oct 15 2021 at 22:17):
What are you working on?
Josh Mandel (Oct 15 2021 at 22:23):
I'd consider just offering a dockerized version as the only supported option and see who complains.
Josh Mandel (Oct 15 2021 at 22:24):
(The folks who want support for specific distos may be the best positioned to maintain those ;-))
Rob Hausam (Oct 15 2021 at 22:27):
That might be a reasonable approach to take.
Rob Hausam (Oct 15 2021 at 22:30):
And sid and buster are Debian release names - and Ubuntu and Debian are very close (Ubuntu is based on Debian), so it's not necessarily too strange for them to be mentioned alongside the actual Ubuntu releases.
Grahame Grieve (Oct 15 2021 at 23:09):
so you build different distribution packages for your app depending on which ubuntu version? weird
Grahame Grieve (Oct 15 2021 at 23:10):
the problem with the dockerized version - unless I misunderstand - is the 25 min start up process while everything is compiled
Josh Mandel (Oct 15 2021 at 23:11):
Nonono, we'd just publish the image
Josh Mandel (Oct 15 2021 at 23:12):
That's the intent behind the .slimmed file: something we could push to a Docker registry for easy deployment.
Josh Mandel (Oct 15 2021 at 23:12):
Then anyone can do docker run without having to do the docker build process themselves.
Grahame Grieve (Oct 15 2021 at 23:15):
so one the build was complete
- delete the source + tools directories
- delete all the unnecessary source files
- leaving behind just what is needed for executable?
Grahame Grieve (Oct 15 2021 at 23:16):
because the stuff that's not needed is about 16GB
Josh Mandel (Oct 15 2021 at 23:19):
Yeah that's pretty much the deal. But in a Docker file like this you can't just delete content because Docker needs to save each layer of the image as it builds things up. So adding a gigabyte of content in one layer and deleting it in the next layer creates a 2 gigabyte stack of layers instead of zero. You can go through some kind of compacting step to avoid this but what I'm doing instead is just to build up a fresh Ubuntu container FROM ubuntu... and copying in any requires stuff from the first image, rather than deleting anything.)
Grahame Grieve (Oct 15 2021 at 23:51):
well, I can tell you what's required:
exec/64/fhirserverexec/pack/*.*exec/pack/linux/*.*
And all the linux dependencies and maybe mysql
Josh Mandel (Oct 15 2021 at 23:57):
https://github.com/grahamegrieve/fhirserver/blob/9cae4a5fe8ebfd984daced2d880fbf2b3390d383/Dockerfile.slimmed#L8 captures it pretty closely already, considering that the pack files have been copied into the first path in original build. But I will clean this up.
Josh Mandel (Oct 15 2021 at 23:58):
By the way, if it is possible to remove the dependencies on gtk and X windows, that would save a good chunk of space in the base layers.
Grahame Grieve (Oct 16 2021 at 00:06):
I looked into that. If I removed gtk, we'd still need it because I'd just need to split the executable into something that would still be needed in some configurations
Grahame Grieve (Oct 16 2021 at 00:06):
btw, add to the list above:
Grahame Grieve (Oct 16 2021 at 00:07):
- exec/64/fhirconsole
Jose Costa Teixeira (Oct 20 2021 at 06:04):
I was trying to run the dockerfile, until I got an error. Is that supposed to be working on windows or only a *nix machines?
Grahame Grieve (Oct 20 2021 at 06:15):
I don't know. we only tested in on linux so far. what's the error?
Grahame Grieve (Oct 20 2021 at 06:17):
on windows, you'd be better to try the windows batch files though
Jose Costa Teixeira (Oct 20 2021 at 09:37):
I'm just trying to get a docker image by running docker build on the Dockerfile.
Jose Costa Teixeira (Oct 20 2021 at 09:37):
I'll try in a linux terminal
Jose Costa Teixeira (Oct 20 2021 at 10:19):
same error from a windows powershell or windows WSL2 terminal:
> [ 4/10] RUN /work/bootstrap/linux-toolchain.sh /work/bootstrap:
#8 0.419 /usr/bin/env: 'bash\r': No such file or directory
Grahame Grieve (Oct 20 2021 at 10:44):
that's a @Josh Mandel question
Grahame Grieve (Oct 20 2021 at 19:22):
and Josh, we're not quite finished until the other docker is built correctly, right?
Josh Mandel (Oct 20 2021 at 19:31):
I would only expect this to work on linux; this should WSL on windows, which I'll test from my work PC.
Josh Mandel (Oct 20 2021 at 19:32):
Grahame Grieve: and Josh, we're not quite finished until the other docker is built correctly, right?
"Finished" re: the goal of distributing a built image? Yeah, it'd be good to set up an automated push to a docker registry when certain tags are applied. Do you have a convention for tagging release branches?
Grahame Grieve (Oct 20 2021 at 19:32):
not yet. I have to talk to @Mark Iantorno about how to do releases. But I figured we would just get the release pipeline going before I sorted that out.
Grahame Grieve (Oct 20 2021 at 19:33):
I want to build the windows installer as part of that too. It looks like I can - all the things I need to do can be done on linux.
Josh Mandel (Oct 20 2021 at 19:33):
Cool!
Grahame Grieve (Oct 20 2021 at 19:34):
authenticate signing: https://www.ssl.com/how-to/microsoft-authenticode-code-signing-in-linux-with-jsign/
building the installer: https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd797
The rest of what happens can be done in shell scripts one way or another
Josh Mandel (Oct 20 2021 at 19:35):
just get the release pipeline going
I think we're pretty good here; We'll basically want to do docker build -t ghcr.io/grahamegrieve/fhirserver -f Dockerfile.slimmed . && docker push in whatever deployment action
Josh Mandel (Oct 20 2021 at 19:35):
(Re: the docker image piece; the windows release stuff I will leave to your capable hands :-))
Grahame Grieve (Oct 20 2021 at 19:37):
I don't have a mental picture for what happens after that. The windows executable will end up here: https://github.com/HealthIntersections/fhirserver/releases (well, that's what I think should happen). But what happens with the docker image?
Josh Mandel (Oct 20 2021 at 19:39):
The docker image will end up in the GH container registry so anyone in the world can docker pull ghcr.io/grahamegrieve/fhirserver and get the latest, or specify :latest explicitly as a suffix for the same behavior, or specify :{{some tag}} explicitly as a suffix to fetch a specific version.
Grahame Grieve (Oct 20 2021 at 19:40):
how does the version get into the picture with docker push?
Josh Mandel (Oct 20 2021 at 19:41):
Before you push, you apply tags; the pushed image can be retrieved with those tags using the : syntax as a suffix to the image name. That's following docker standards/conventions.
Grahame Grieve (Oct 20 2021 at 19:42):
well, the server has a semver version on it. When we finish the release pipeline, it will go to 2.x.x, and the tag will simply be the version
Josh Mandel (Oct 20 2021 at 19:45):
Sounds good to me.
Josh Mandel (Oct 20 2021 at 19:45):
Should be easy to meet the requirements.
A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes. A tag name may not start with a period or a dash and may contain a maximum of 128 characters.
Grahame Grieve (Oct 20 2021 at 19:48):
should we do snapshot releases of the current? or just formal releases?
Josh Mandel (Oct 20 2021 at 19:53):
I don't think I'd push an image for every commit, but we could. Would start with releases.
Grahame Grieve (Oct 20 2021 at 19:54):
if we pushed it with the same version, it would replace the last one, yes?
Josh Mandel (Oct 20 2021 at 19:59):
Yes, various combinations possible:
- Tag each image with a git SHA and a semver, and
:latestand push all tags, so every build is available all the time, and:latestalways grabs the latest - Tag each image with some subset of these tags...
Jose Costa Teixeira (Oct 21 2021 at 21:56):
Josh Mandel said:
I would only expect this to work on linux; this should WSL on windows, which I'll test from my work PC.
Still doesn't work. could it be this line ?
Xvfb :99 -screen 0 1024x768x8 -nolisten tcp & \n\
Josh Mandel (Oct 21 2021 at 21:58):
Does it work if you remove this line? (I have not tried this on WSL but can do.)
Jose Costa Teixeira (Oct 21 2021 at 22:49):
I'll try tomorrow. I recall some discussions around enabling graphics so I thought it could be needed
Jose Costa Teixeira (Oct 21 2021 at 22:49):
I don't have a Linux machine, just a Linux terminal prompt on windows. So I don't have X
Josh Mandel (Oct 21 2021 at 23:03):
This doesn't use X as a grpahical environment though. It uses Xvfb, a virtual framebuffer. Headless implementation.
Josh Mandel (Oct 21 2021 at 23:06):
Confirmed that I can run
~/fhirserver$ docker build -t grahamegrieve/fhirserver -f Dockerfile .
in WSL2 on my windows laptop. (Though it ... was not fast.)
Grahame Grieve (Oct 21 2021 at 23:07):
what does not fast mean?
Josh Mandel (Oct 21 2021 at 23:07):
Having done so,
$ docker run --rm -it grahamegrieve/fhirserver
succeeds in starting the server for me
Josh Mandel (Oct 21 2021 at 23:07):
Grahame Grieve: what does not fast mean?
I mean, my work laptop is long in the tooth. But my internet connection is fast. This took me
Building 3848.5s (15/15) FINISHED
Josh Mandel (Oct 21 2021 at 23:07):
(!)
Grahame Grieve (Oct 21 2021 at 23:08):
that's definitely not fast. The full build including tests is taking 30min on github
Grahame Grieve (Oct 21 2021 at 23:09):
sorry ~25min
Josh Mandel (Oct 21 2021 at 23:10):
GH is caching though, keep in mind (it caches the lazarus stuff until/unless the early lines of the dockerfile change)
Grahame Grieve (Oct 21 2021 at 23:11):
hmm. I'll time my linux laptop, but it feels about the same starting from scratch
Josh Mandel (Oct 21 2021 at 23:12):
It may be; the speedup in GH from caching was only about 5min when I clocked it, because the caching itself isn't super fast. We can cut it out for simplicity if you prefer.
Grahame Grieve (Oct 21 2021 at 23:17):
no keep it
Jose Costa Teixeira (Oct 22 2021 at 06:21):
Josh Mandel said:
Confirmed that I can run
~/fhirserver$ docker build -t grahamegrieve/fhirserver -f Dockerfile .in WSL2 on my windows laptop. (Though it ... was not fast.)
Found it. It's a CR/LF thing. It depends on one's git configuration. To fix it, I had to replace all CRLF to LF
Grahame Grieve (Oct 22 2021 at 06:22):
unbelievable
Jose Costa Teixeira (Oct 22 2021 at 06:27):
more unbelievable is how silly I am to fix one file, run it for 10 minutes, and only then realizing that of course I have to do the same for all the other .sh scripts
Jose Costa Teixeira (Oct 22 2021 at 07:01):
Confirmed. It builds ok now.
Jose Costa Teixeira (Oct 22 2021 at 07:04):
1038 seconds on a Ryzen 9 3900x desktop
Jose Costa Teixeira (Oct 22 2021 at 07:08):
i now get a First time, so can't continue.
What do i need to look at to pick up from here?
Grahame Grieve (Oct 22 2021 at 09:36):
where do you get that?
Josh Mandel (Oct 22 2021 at 13:03):
@Jose Costa Teixeira did you clone this repository within wsl, or copied in from a Windows git operation performed outside of WSL? Just trying to figure out where your configuration and mine differed. I believe that the default Windows settings for new lines in git are different than the default Linux settings because the operating systems have different conventions. As you point out, configuring git is one way to resolve this; using default git settings in WSL should be another.
Josh Mandel (Oct 22 2021 at 13:24):
And Grahame for the record what is your
git config core.autocrlf
Josh Mandel (Oct 22 2021 at 13:25):
(https://stackoverflow.com/a/20653073/318206 has a good overview.)
Jose Costa Teixeira (Oct 22 2021 at 15:18):
I got the files in Windows
Jose Costa Teixeira (Oct 22 2021 at 15:18):
So no clone in wsl
Grahame Grieve (Oct 22 2021 at 17:57):
git config core.autocrlf
false
Jose Costa Teixeira (Oct 22 2021 at 19:10):
(Let me RTFM to see if we can prevent others from encountering the same issue)
Jose Costa Teixeira (Oct 22 2021 at 21:32):
Grahame Grieve said:
where do you get that?
@Grahame Grieve I just run the docker image, I don't know if there are any parameters when I do that
Jose Costa Teixeira (Oct 22 2021 at 21:34):
I'm running docker run --rm -it fhirserver
Jose Costa Teixeira (Oct 22 2021 at 21:34):
What should I run to get the DB initialized?
Josh Mandel (Oct 22 2021 at 21:38):
Do you see an error prior to "First time, so can't continue"? (When I saw this once, it was right after a download failed.)
Jose Costa Teixeira (Oct 22 2021 at 21:39):
right, sorry I missed that:
07:07:09 00:00:00 Local Config in /terminology/fhir-server/
07:07:09 00:00:00 Read Zero Config from http://tx.fhir.org/config/config.json
07:07:10 00:00:00 Realm: uv
07:07:10 00:00:00 Download rxnorm-20210208.db. HTTP/1.1 500 Internal Server Error
07:07:10 00:00:00 Zero Configuration Process failed: HTTP/1.1 500 Internal Server Error
Josh Mandel (Oct 22 2021 at 21:41):
So if you try again you may get a different result. Best to mount in a volume so you don't lose the vocabs that have successfully downloaded between each run.
Jose Costa Teixeira (Oct 22 2021 at 21:41):
tried a few times, same result.
Josh Mandel (Oct 22 2021 at 21:42):
OK -- looks like an error in the cloud-hosted sever's stack then. (HTTP/1.1 500)
Jose Costa Teixeira (Oct 22 2021 at 21:44):
mounting in volume: docker run -v ____ ?
Jose Costa Teixeira (Oct 22 2021 at 21:45):
(I created a volume named fhirserver - what is the path where the volume is mounted?)
Josh Mandel (Oct 22 2021 at 21:51):
Let's say you have a host directory like /tmp/term, then you can do
docker run \
--rm -it \
-v /tmp/term:/terminology \
grahamegrieve/fhirserver
For reference
$ docker inspect fhirserver | jq '.[].Config.Volumes'
{
"/terminology": {}
}
or
$ cat Dockerfile | grep -i volume
VOLUME /terminology
Jose Costa Teixeira (Oct 22 2021 at 21:56):
thanks
Josh Mandel (Oct 22 2021 at 21:57):
(I see the same errors as you :-)
Jose Costa Teixeira (Oct 22 2021 at 21:58):
I can't say I'm happy about that, but I'm kind of happy about that :)
Jose Costa Teixeira (Oct 22 2021 at 22:08):
so I guess the server error is no longer a docker issue but in the pascal code?
Josh Mandel (Oct 22 2021 at 22:08):
I think it's an issue with the web server Grahame hosts at tx.fhir.org, which your local server is trying to connect to on startup to fetch vocab filesr
Jose Costa Teixeira (Oct 22 2021 at 22:09):
i'm trying to see if the files are actually on the server, but they're now
Jose Costa Teixeira (Oct 22 2021 at 22:09):
right.
Jose Costa Teixeira (Oct 22 2021 at 22:09):
how do we point it to a different config.json file, instead of getting the config.json online?
Jose Costa Teixeira (Oct 22 2021 at 22:10):
no , let me check that in the code
Grahame Grieve (Oct 22 2021 at 22:12):
oh - first time can't continue in that place - totally my problem. I'll look at it tonight and figure out why - it was broken for a while yesterday but should be good now
Jose Costa Teixeira (Oct 22 2021 at 22:13):
ok meanwhile I see that we can pass a -cfg parameter in the command line.
Jose Costa Teixeira (Oct 22 2021 at 22:14):
Is there a way to pass a parameter to the fhirserver command line when doing docker run?
Josh Mandel (Oct 22 2021 at 22:15):
Just add arguments after "grahamegrieve/fhirserver"
Jose Costa Teixeira (Oct 22 2021 at 22:15):
in the build line, or can also be just in the run?
Josh Mandel (Oct 22 2021 at 22:15):
like docker run grahamegrieve/fhirserver -cfg /tmp/file
Josh Mandel (Oct 22 2021 at 22:16):
(But you'll need to point to a file that exists in the container or mount one in)
Jose Costa Teixeira (Oct 22 2021 at 22:16):
ok perfect i thought I had to rebuild. thanks
Grahame Grieve (Oct 22 2021 at 22:17):
but why do you need to do that? what's actually broken? you need to access the file it says that it can't read...
Jose Costa Teixeira (Oct 22 2021 at 22:19):
while I am getting the 500 error from the server, I want to experiment with the config file,
I want to learn how to run a server with my own config.json
Jose Costa Teixeira (Oct 22 2021 at 22:20):
For now, I just want to see if I can get it to move on when I have a config file that doesn't have the rxnorm db
Grahame Grieve (Oct 22 2021 at 22:20):
well, ok, but why are you getting a 500 error from the server? can you access it in a browser?
Jose Costa Teixeira (Oct 22 2021 at 22:20):
no
The webpage at http://tx.fhir.org/config/rxnorm-20210208.db might be temporarily down or it may have moved permanently to a new web address.
Grahame Grieve (Oct 22 2021 at 22:21):
oh interesting. the server won't download the .db files... I wonder why
Grahame Grieve (Oct 22 2021 at 22:21):
I will look at this tonight
Jose Costa Teixeira (Oct 22 2021 at 22:21):
https://tx.fhir.org/config/loinc-2.71.cache does work
Grahame Grieve (Oct 22 2021 at 22:23):
which reminds me @Josh Mandel I got around to looking into putting this stuff into cloud storage. Is there a cloud storage that doesn't suck? both AWS and GCS, I couldn't even figure out how to start doing it - so many configuration options in language I can't understand, and the hl7 guys tell me that AWS doesn't want new publicly available cloud storages...
Josh Mandel (Oct 22 2021 at 23:49):
Is there a cloud storage that doesn't suck?
I'm not sure what you mean about "new publicly available cloud storages" You can configure S3 public buckets following https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html#block-public-access-intro
Josh Mandel (Oct 22 2021 at 23:50):
(Looks like they have introduced defaults designed to prevent https://www.computerweekly.com/news/252476870/Exposed-AWS-buckets-again-implicated-in-multiple-data-leaks)
Josh Mandel (Oct 22 2021 at 23:52):
Or... I put the snomed.test.cache file (for tests) in https://console.cloud.google.com/storage/browser/ig-build which supports public https access -- e.g., at https://storage.googleapis.com/ig-build/snomed.test.cache
Grahame Grieve (Oct 23 2021 at 01:36):
so I created a sub-folder /tx. now: https://storage.googleapis.com/ig-build/tx/config.json = access denied.
Grahame Grieve (Oct 23 2021 at 01:40):
so I have to explicitly add allUsers for all files in the folder :-(
Grahame Grieve (Oct 23 2021 at 01:42):
https://storage.googleapis.com/ig-build/tx/ucum-essence-2.0.1.xml
Grahame Grieve (Oct 23 2021 at 01:42):
why doesn't access to this work? As I said, sucky. permissions model is impossible to navigate
Josh Mandel (Oct 23 2021 at 02:14):
There is no such thing as a folder in this paradigm. Merely conventions about file blob name prefixes which happened to include slashes :-)
Josh Mandel (Oct 23 2021 at 02:14):
But you can set up a bucket so that all files in our public by default which you might want here.
Grahame Grieve (Oct 23 2021 at 02:31):
it was how it was set up but apparently it doesn't matter how it's set up, only how it was set up when the file was uploaded
Grahame Grieve (Oct 23 2021 at 03:09):
ok sorted that. Uploading will be a nightmare, but... the new zero config URL for the server is https://storage.googleapis.com/tx-fhir-org
Grahame Grieve (Oct 23 2021 at 03:09):
tx.fhir.org will be using that set up from the next time it restarts
Grahame Grieve (Oct 23 2021 at 03:16):
@Jose Costa Teixeira you've seen https://confluence.hl7.org/display/FHIR/Running+your+own+copy+of+tx.fhir.org ?
Jose Costa Teixeira (Oct 23 2021 at 09:41):
Thanks, just did, i'm now downloading
Josh Mandel (Oct 23 2021 at 15:34):
Lovely, I get ~350Mb/s from there
15:30:15 00:00:00 Config: https://storage.googleapis.com/tx-fhir-org
15:30:15 00:00:00 Local Config in /terminology/fhir-server/
15:30:15 00:00:00 Read Zero Config from https://storage.googleapis.com/tx-fhir-org/config.json
15:30:16 00:00:00 Realm: uv
15:30:16 00:00:00 Download rxnorm-20210208.db.................................................. Done (1.3 GB, 29sec)
15:30:45 00:00:29 Download ndc-20210923.db.................................................. Done (60.5 MB, 1sec)
15:30:47 00:00:31 Download unii-20210810.db.................................................. Done (55.2 MB, 6sec)
15:30:54 00:00:38 Download sct_intl_20210731-fixed.cache.................................................. Done (733.0 MB, 23sec)
15:31:18 00:01:02 Download loinc-2.71.cache.................................................. Done (168.0 MB, 4sec)
15:31:22 00:01:06 Download ucum-essence-2.0.1.xml........................................ Done (82.4 KB, 340ms)
15:31:23 00:01:07 Realm: au
15:31:23 00:01:07 Download sct_au_20210630.cache.................................................. Done (898.7 MB, 20sec)
15:31:43 00:01:27 Realm: ca
15:31:43 00:01:27 Download sct_ca_20210331.cache.................................................. Done (0.9 GB, 22sec)
15:32:05 00:01:49 Realm: old
15:32:05 00:01:49 Download sct_intl_20190731.cache.................................................. Done (880.6 MB, 20sec)
15:32:26 00:02:10 Download sct_intl_20200731.cache.................................................. Done (1.0 GB, 24sec)
15:32:50 00:02:34 Download sct_intl_20200131.cache.................................................. Done (1.0 GB, 23sec)
15:33:13 00:02:57 Realm: us
15:33:13 00:02:57 Download sct_us_20210901.cache.................................................. Done (760.3 MB, 17sec)
Josh Mandel (Oct 23 2021 at 15:39):
Is it expected that I see slow steps like the following each time I start the server, even though the config hasn't changed?
15:37:19 00:00:05 Installing Package from https://packages.simplifier.net/hl7.fhir.r4.core/4.0.1 to /var/lib/.fhir/packages
If this is expected: is there an underlying reason why contents from packages.simplifier.org can't be saved locally the way vocabularies are? (I'm thinking that once I have set up the server, or once I have fed in the right volumes with data dependencies... I should be able to start/run it in a totally internal way without it needing to reach to the internet.)
Grahame Grieve (Nov 02 2021 at 22:43):
@Josh Mandel I broke something, and I don't understand what.
Grahame Grieve (Nov 02 2021 at 22:43):
https://github.com/HealthIntersections/fhirserver/runs/4086273976?check_suite_focus=true
Grahame Grieve (Nov 02 2021 at 22:44):
which is because of the changes I made to the dockerfile in the gg-202110-code-scanning branch
Grahame Grieve (Nov 02 2021 at 22:44):
I wanted to run another executable, but why is it blowing up on it?
Josh Mandel (Nov 02 2021 at 23:05):
Let's see...
Josh Mandel (Nov 02 2021 at 23:06):
https://github.com/HealthIntersections/fhirserver/blame/gg-202110-code-scanning/Dockerfile
Josh Mandel (Nov 02 2021 at 23:08):
You've added lines to the entry point script, with two problems:
- They are syntactically invalid (need
\at the end to continue this block, like the lines above and below - They don't make sense; the entry point script executes every time someone does
docker run; it should accept arguments and do one job, but you seem to be trying to do two different
Grahame Grieve (Nov 02 2021 at 23:08):
what entry point script?
Grahame Grieve (Nov 02 2021 at 23:09):
I am trying to run another executable, yes, and run it before the test cases
Josh Mandel (Nov 02 2021 at 23:10):
The comments are also wrong; you've written "run tests" but the function of this line is to execute server with any supplied arguments (tests are passed in via the GH action but default cmd arguments below are just to run the server with tx.fhir.org configuration)
Josh Mandel (Nov 02 2021 at 23:11):
Think of the entry point as a wrapper around the fhirserver executable. The whole job of the entry point is to get configuration in place, pass through any command line args, and get out of the way.
Grahame Grieve (Nov 02 2021 at 23:11):
so how can I do this then? I build this executable in /work/fhirserver/utilities/codescan/codescan, and I want to run it
Grahame Grieve (Nov 02 2021 at 23:11):
before the fhirserver runs
Josh Mandel (Nov 02 2021 at 23:11):
If you want to affect the tests that run in CI..
Josh Mandel (Nov 02 2021 at 23:11):
You'll want to edit https://github.com/HealthIntersections/fhirserver/blob/gg-202110-code-scanning/.github/workflows/linux-docker-build.yml#L69
Josh Mandel (Nov 02 2021 at 23:13):
E.g., add a line like docker run --entrypoint /work/fhir server/.../codescan ... fhirserver
Grahame Grieve (Nov 02 2021 at 23:13):
I suppose I just don't understand the relationship between the dockerfile and this .yml file, and which is done in which
Josh Mandel (Nov 02 2021 at 23:13):
If you need to pass in a a command line arg to the codescan binary, that goes at the end
Josh Mandel (Nov 02 2021 at 23:14):
The Dockerfile builds a docker image with a fhirserver and related tools/libraries inside it
Josh Mandel (Nov 02 2021 at 23:15):
The GH action runs a container based on this image, invoking the executables with whatever arguments are required for the CI process to be happy that this commit is valid
Josh Mandel (Nov 02 2021 at 23:17):
The Dockerfile includes a default entry point that executes fhirserver, so real users can basically treat it as the fhirserver. If you want to execute other binaries inside, you need to specify a different entry point
Grahame Grieve (Nov 02 2021 at 23:42):
so what I don't understand in linux-docker-build.yml is when does the build actually happen?
Grahame Grieve (Nov 02 2021 at 23:42):
is it Buildx? if not, what is Buildx doing?
Grahame Grieve (Nov 02 2021 at 23:44):
and what's the `... fhirserver about in what you put above?
Josh Mandel (Nov 03 2021 at 00:23):
docker buildx build at https://github.com/HealthIntersections/fhirserver/blob/7e072c7e5ab9e2d6e4455f7524c5d0a657be219c/.github/workflows/linux-docker-build.yml#L42 builds the image.
Josh Mandel (Nov 03 2021 at 00:23):
Based on the Dockerfile
Josh Mandel (Nov 03 2021 at 00:24):
The ... was a placeholder for any arguments you might want to supply like if you need to mount any directories into the container or define any ports. I'm still not sure I understand what the codescan is doing; is it meant to scan the source code in your repository for "Trojan Source" contents?
Josh Mandel (Nov 03 2021 at 00:28):
If that's the main reason, you might just run grep outside of all this Dickers stuff as a standalone step -- https://news.ycombinator.com/item?id=29062307 has pointers
Josh Mandel (Nov 03 2021 at 00:29):
(And I expect someone will build this into existing source code scanning GH actions within a few days.)
Grahame Grieve (Nov 03 2021 at 00:29):
that was the trigger for me to get around to doing this, but it does other things in the code as well
Josh Mandel (Nov 03 2021 at 00:30):
Sounds good.
Grahame Grieve (Nov 03 2021 at 01:14):
well, I'm getting there, but still not there yet.
Grahame Grieve (Nov 03 2021 at 01:14):
021-11-03T01:00:30.2283884Z ##[group]Run docker run --entrypoint /work/fhirserver/codescan/codescan /work/bootstrap
2021-11-03T01:00:30.2285434Z [36;1mdocker run --entrypoint /work/fhirserver/codescan/codescan /work/bootstrap[0m
2021-11-03T01:00:30.3214919Z shell: /usr/bin/bash -e {0}
2021-11-03T01:00:30.3215465Z ##[endgroup]
2021-11-03T01:00:30.3956267Z docker: invalid reference format.
2021-11-03T01:00:30.3968559Z See 'docker run --help'.
2021-11-03T01:00:30.3993955Z ##[error]Process completed with exit code 125.
Grahame Grieve (Nov 03 2021 at 01:15):
I don't understand what "invalid reference format" means?
Josh Mandel (Nov 03 2021 at 01:16):
You need to specify an image. Assuming it's the image that we've tagged as "fhirserver":
docker run --entrypoint /work/fhirserver/codescan/codescan fhirserver /work/bootstrap
Grahame Grieve (Nov 03 2021 at 01:17):
Assuming it's the image that we've tagged as "fhirserver"
I don't know what that means.
Grahame Grieve (Nov 03 2021 at 01:17):
/work/fhirserver/codescan/codescan is an executable that should exist on the system, and I want to run it
Josh Mandel (Nov 03 2021 at 01:17):
Josh Mandel (Nov 03 2021 at 01:19):
You need to do "docker run [--entrypoint /path/to/bin] {tag} [cli args]" where {} is a required value and [] is optional
Josh Mandel (Nov 03 2021 at 01:20):
In your case, try the command I listed above
Grahame Grieve (Nov 03 2021 at 01:21):
ok thanks, I think I understand now.
Grahame Grieve (Nov 03 2021 at 01:58):
@Josh Mandel sigh. like fhirserver, the code scanner needs gui support. I tried to rip it out, but it's a huge code change for me. Maybe I'm doing it wrong, but any thing with color reasoning brings in the gui framework
Grahame Grieve (Nov 03 2021 at 01:58):
so the code scanner, since it depends on the same base string library that does colour / string wrangling. and so I get this:
Josh Mandel (Nov 03 2021 at 01:58):
Oy. The code scanner uses colors?
Grahame Grieve (Nov 03 2021 at 01:58):
(codescan:1): Gtk-WARNING **: 01:54:49.280: cannot open display: :99
Grahame Grieve (Nov 03 2021 at 02:00):
it's really hard to fix this, and I thought that we had sorted this out for the FHIRServer, so it should just work?
Grahame Grieve (Nov 03 2021 at 02:00):
I did spend 30 minutes trying to splice the GUI code out, but then I realised just how big a task that is. Might take me 3 or 4 days
Josh Mandel (Nov 03 2021 at 02:01):
(Er, accidentally deleted this msg; can't fix on mobile but you can see the history.)
Josh Mandel (Nov 03 2021 at 02:03):
Or we could keep one entry point file and require users to pass an additional arg telling it which executable to run. But I think that clouds the common case DX
Grahame Grieve (Nov 03 2021 at 04:12):
ok, well, I bit the bullet and reshuffled a little differently, and now my code scanner runs.
Grahame Grieve (Nov 03 2021 at 04:12):
and it tells me that the code in the dependent repositories isn't being updated.
Grahame Grieve (Nov 03 2021 at 04:13):
021-11-03T02:55:00.7044244Z #10 [ 5/10] RUN /work/bootstrap/unix-libraries.sh /work/bootstrap
Grahame Grieve (Nov 03 2021 at 04:13):
that must lead to lines like this running:
Grahame Grieve (Nov 03 2021 at 04:13):
echo "Updating dependencies for linux"
Grahame Grieve (Nov 03 2021 at 04:13):
but no, nothing. So I think that script isn't being executed at all
Grahame Grieve (Nov 03 2021 at 04:13):
@Josh Mandel
Josh Mandel (Nov 03 2021 at 13:57):
That URI is "expired". But what's going on here is caching of docker layers across CI runs, which we've specifically enabled and can turn off if you don't want it, for a build time penalty. Alternatively, you can modify one of the input input files (e.g., add a comment line to unix-libraries that you update when you want to bust this caching) or alternatively we could play some trick to prevent any caching beyond the point at which the tool chain is installed, like copying a temp file with random content into the container right after that step)m
Grahame Grieve (Nov 03 2021 at 17:56):
I don't understand. Why does caching stop git update from being run?
Josh Mandel (Nov 03 2021 at 18:08):
Docker has a "dumb" model for caching layers where:
- Each line of the Dockerfile represents a "step" of the build process, and the output of each step is a new "layer" (i.e., a docker image representing the state after that step has been run)
- Only a few steps (
COPYandADDsteps) directly bring external content into their output layer (other steps likeRUNcan of course fetch files from the network, etc -- but Docker does not attempt to account for this in its caching model) - A step that has already run will never run-run unless its inputs have changed (or the inputs to its predecessors have changed)
So... the way it's currently configured, if the inputs to the first COPY step (build/linux-toolchain.sh and build/unix-libraries.sh) haven't changed, then the lines leading up to the next COPY won't run, since they're cached.
Josh Mandel (Nov 03 2021 at 18:12):
This kind of flexibility can be quite helpful, but you have you be intentional about it. I think the main goal is to prevent re-installing fpclazup on every build, since that's particularly slow. We can accomplish this while still re-fetching dependencies (e.g., using "Option 1" from https://www.keepsecure.ca/blog/2021/advanced-docker-tips-pt2-know-when-to-cache/ to insert a step between the toolchain script and the dependencies script).
Grahame Grieve (Nov 03 2021 at 18:14):
but linux-fhirserver.sh runs each time, right? We just want unix-libraries.sh to run before linux-fhirserver.sh runs - should we just call unix-libraries from linux-fhirserver.sh?
Josh Mandel (Nov 03 2021 at 18:15):
linux-fhirserver.sh runs any time any of the repo contents have changed, except for a few things listed in https://github.com/HealthIntersections/fhirserver/blob/master/.dockerignore -- so that's effectively always.
Josh Mandel (Nov 03 2021 at 18:15):
If you want to rebuild the unix libraries every time, we can indeed move that RUN step so it happens after the big COPY and before linux-fhirserver.sh runs
Josh Mandel (Nov 03 2021 at 18:16):
I just added a commit at https://github.com/HealthIntersections/fhirserver/blob/gg-202110-code-scanning/Dockerfile
Grahame Grieve (Nov 03 2021 at 18:20):
ok thanks. and yes, we do want the latest copes of the libraries each time
Grahame Grieve (Nov 03 2021 at 20:17):
yay we got there, thanks
Jose Costa Teixeira (Nov 04 2021 at 21:56):
I want to launch the server using a local config.json file. How can I do this?
I have a bind mount to a local folder, but I don't know how I can point to a file in that folder:
my local folder is /mnt/c/work/fhirserver/docker/cache. How would the docker command line look like?
docker run --name tx_server --env PORT=80 --mount type=bind,source=/mnt/c/work/fhirserver/docker/cache,target=/root/fhir-server -p 80:80 fhirserver -cfg XXX
Jose Costa Teixeira (Nov 04 2021 at 21:57):
What should I use as XXX?
Josh Mandel (Nov 04 2021 at 21:59):
Why are you mounting a folder into /root/fhir-server? Is that a path that you expect to exist? I would have expected you to mount into something like /my-config.
But in any case for the example, as you have written it, XXX=/root/fhir-server/config.json assuming that /mint/c/work/fhirserver/docker/cache/config.json exists on the host.
Josh Mandel (Nov 04 2021 at 22:00):
I have never supplied a local JSON file, only a URL, so I guess I'm also not sure what the server expects for this argument. I'm just answering your top level question about how to refer to a file on a path that you have mounted into your docker container.
Josh Mandel (Nov 04 2021 at 22:00):
You'll also need an argument like -cmd exec and probably other arguments
Jose Costa Teixeira (Nov 04 2021 at 22:21):
Josh Mandel said:
Why are you mounting a folder into /root/fhir-server? Is that a path that you expect to exist? I would have expected you to mount into something like /my-config.
that is where the server keeps the cache files. If I use another folder, i'd need to tell the server about that other location (and I don't know how)
Jose Costa Teixeira (Nov 04 2021 at 22:22):
I'm starting with something that works and there try to change a few things, so that I can always come back to a working setup
Jose Costa Teixeira (Nov 04 2021 at 22:24):
Josh Mandel said:
But in any case for the example, as you have written it, XXX=
/root/fhir-server/config.jsonassuming that /mint/c/work/fhirserver/docker/cache/config.json exists on the host.
it doesn't work. complains about Unable to find the lang file ""
Jose Costa Teixeira (Nov 04 2021 at 22:25):
Josh Mandel said:
You'll also need an argument like
-cmd execand probably other arguments
This is not needed. The server does start ok (if I use the URL)
Grahame Grieve (Nov 04 2021 at 23:05):
hey @Josh Mandel this has suddenly started happening on the build, running the tests:
(fhirserver:9): Gtk-WARNING **: 23:04:44.912: cannot open display: :99
Error: Process completed with exit code 1.
Josh Mandel (Nov 04 2021 at 23:11):
@Jose Costa Teixeira I'm not sure what that error means from the server
Josh Mandel (Nov 04 2021 at 23:31):
Hmm, that's curious re: display error. Has this happened before? I'll see if I can reproduce locally.
Grahame Grieve (Nov 04 2021 at 23:32):
hadn't happened since you first set it up, then failed for the last two runs
Grahame Grieve (Nov 04 2021 at 23:33):
(master branch, and PR branch)
Josh Mandel (Nov 04 2021 at 23:37):
I can't think of any reason why it should fail transiently. Guess I'm not thinking creatively enough.
Josh Mandel (Nov 05 2021 at 01:27):
Well, I couldn't reproduce locally. On retriggering https://github.com/HealthIntersections/fhirserver/actions/runs/1423271582 succeeded. I'm retriggering the failed branch build too.
Josh Mandel (Nov 05 2021 at 01:28):
I'm puzzled about this failure mode.
Grahame Grieve (Nov 05 2021 at 01:28):
X is having trouble starting? it's a timing thing?
Josh Mandel (Nov 05 2021 at 01:28):
It's possible there's a race condition, yeah.
Josh Mandel (Nov 05 2021 at 01:30):
If this happens again let's follow https://unix.stackexchange.com/a/310688 or just add a sleep in the entrypoint file.
Grahame Grieve (Nov 10 2021 at 20:19):
hey @Josh Mandel this happens for every PR created by someone other than you or me:
testSendEmail [00.000] fail @?#?: Must provide password for SMTP test in work/fhirserver/exec/64/test-settings.ini ([email] ***
(see https://github.com/HealthIntersections/fhirserver/runs/4162397321?check_suite_focus=true)
Grahame Grieve (Nov 10 2021 at 20:20):
I think it can't be co-incidence
Josh Mandel (Nov 10 2021 at 20:38):
Is it specific to you and me, or are the PRs being made from external forks? Just want to narrow down the permissions issues here.
Josh Mandel (Nov 10 2021 at 20:38):
See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ for background
Josh Mandel (Nov 10 2021 at 20:40):
Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository.
Grahame Grieve (Nov 10 2021 at 20:43):
yes could be external PRs - that makes sense. And yes, I can see why they do that.
Grahame Grieve (Nov 10 2021 at 20:44):
... but what's the solution?
Grahame Grieve (Nov 10 2021 at 21:53):
further reading says 'by default' is misleading - there's no non-default here; it's a hard rule
Josh Mandel (Nov 10 2021 at 21:55):
We can run almost all the tests with no secrets at all, right? I think that should be the default, and the tests should pass.
Grahame Grieve (Nov 10 2021 at 21:56):
yes I'm just sucking it up and making that change.
Josh Mandel (Nov 10 2021 at 21:56):
(We can add back email tests more thoughtfully -- like, maybe in the main branch the password will be present, and when present the tests will require this email test to pass.)
Grahame Grieve (Nov 10 2021 at 21:56):
it does spectacularly screw up my plans for tx-cache mgmt though
Josh Mandel (Nov 10 2021 at 21:56):
So just make the email tests conditional
Josh Mandel (Nov 10 2021 at 21:56):
Hmm, what's the interaction with tx-cache management?
Grahame Grieve (Nov 10 2021 at 21:58):
the plan was that the password to commit the updated tx-cache would use a password in the github repo. But, of course, it won't have one
Grahame Grieve (Nov 10 2021 at 21:58):
but even more, if you create a fork in your own gh space, and then work from that, it won't pick up the tx-cache from the server because the org will be different
Josh Mandel (Nov 10 2021 at 21:58):
I'm not quite following. The submission of cache updates happens in the build pipeline (core or IG), right?
Grahame Grieve (Nov 10 2021 at 21:59):
right. the build pipeline, yes
Josh Mandel (Nov 10 2021 at 21:59):
The secrets just need to be present in the build pipeline, then. Don't need to be in any GH actions.
Grahame Grieve (Nov 10 2021 at 21:59):
how do we get them into the build pipeline then? the only way I knew was from a gh repo secret
Josh Mandel (Nov 10 2021 at 22:00):
By "build pipeline" I mean:
- Core: Azure Pipelines maintained by Mark
- IGs: Kubernetes based "auto-ig-builder" maintained by me
... each of these has its own secret management functionality.
Josh Mandel (Nov 10 2021 at 22:02):
Like when I run the IG publisher I inject a ig.builder.keyfile.ini that you gave me.
Grahame Grieve (Nov 10 2021 at 22:03):
oh. great. can you add an entry to it for me?
Josh Mandel (Nov 10 2021 at 22:03):
Um, not readily ;-) Let me see.
Grahame Grieve (Nov 10 2021 at 22:04):
it should be
Grahame Grieve (Nov 10 2021 at 22:04):
[keys]
name=value
Josh Mandel (Nov 10 2021 at 22:04):
This should be a separate file though, right? like ig.builder.keyfile.ini passed in to the publisher as -api-key-file
Josh Mandel (Nov 10 2021 at 22:04):
And this is a different kind of input.
Grahame Grieve (Nov 10 2021 at 22:04):
y
Josh Mandel (Nov 10 2021 at 22:04):
Maybe?
Grahame Grieve (Nov 10 2021 at 22:05):
I want to put an entry in that ini file?
Josh Mandel (Nov 10 2021 at 22:10):
I guess it's empty right now -- we set this up but never used it?
Grahame Grieve (Nov 10 2021 at 22:10):
that makes sense. I want to use it now. So we can add:
Josh Mandel (Nov 10 2021 at 22:10):
Don't tell me secrets here ;-)
Grahame Grieve (Nov 10 2021 at 22:10):
[keys]
tx.fhir.org=XX
Grahame Grieve (Nov 10 2021 at 22:11):
I wasn't going to put it in here :grinning:
Grahame Grieve (Nov 12 2021 at 19:29):
yay: I've redone the existing release process to use github releases
Grahame Grieve (Nov 12 2021 at 19:29):
https://github.com/HealthIntersections/fhirserver/releases
Josh Mandel (Nov 12 2021 at 19:35):
cool! do you apply release tags in git? should we trigger container publication based on this?
Grahame Grieve (Nov 12 2021 at 19:36):
@Josh Mandel a question. I've started releasing my toolkit. It's a bunch of useful stuff in a IDE-lite - a desktop program. It builds and works for windows, linux, and OSX. If I was going to release a linux version, what would be the way to distribute it?
Grahame Grieve (Nov 12 2021 at 19:36):
well, the gh documentation says that it auto-creates a tag for the release
Grahame Grieve (Nov 12 2021 at 19:36):
e.g. https://github.com/HealthIntersections/fhirserver/releases/tag/v2.0.0
Grahame Grieve (Nov 12 2021 at 19:37):
and it would be good to put the linux release there too
Grahame Grieve (Nov 12 2021 at 19:38):
toolkit options - .zip, .tgz, docker, linux package, installer... the simpler options feel more inadequate but the complex ones feel out of reach
Josh Mandel (Nov 12 2021 at 19:42):
I don't have experience packaging linux apps; I tend to lean on docker but you might want to evaluate https://docs.appimage.org/ or snap
Grahame Grieve (Nov 12 2021 at 19:49):
appimage seems like an appropriate option. I can even run it on windows. If only I could do the OSX release process from windows...
Grahame Grieve (Nov 12 2021 at 19:54):
I may be able to do the windows release from linux - need to run several windows cli under wine - maybe they will...
Grahame Grieve (Dec 02 2021 at 23:59):
@Josh Mandel something's gone wrong with the build set up - see https://github.com/HealthIntersections/fhirserver/runs/4400650018?check_suite_focus=true
Josh Mandel (Dec 03 2021 at 00:01):
It looks like the snomed tests are failing;
Josh Mandel (Dec 03 2021 at 00:02):
I can't tell from the logs whether this is an infrastructure issue
Grahame Grieve (Dec 03 2021 at 00:04):
the snomed loading code hasn't changed, and I'm checking that the file is present, and it is, but it's somehow corrupt...?
Josh Mandel (Dec 03 2021 at 00:09):
You mean the cached db file?
Josh Mandel (Dec 03 2021 at 00:10):
In theory it should either be present and correct or absent all together when we run the step that downloads it. And we skip the download if it is present.
Josh Mandel (Dec 03 2021 at 00:11):
We can augment the download step to print out some logging information about file size and hash
Grahame Grieve (Dec 03 2021 at 00:12):
might have to ... I don't know what else could be the problem
Grahame Grieve (Dec 03 2021 at 00:21):
the hex representation of the SHA-256 hash is 'AA2BF154DC360AD5AFED687638CB8DC1EAE831E2EABD4498F327726F2EF92816' for me
Josh Mandel (Dec 03 2021 at 00:22):
Of the correct file?
Grahame Grieve (Dec 03 2021 at 00:22):
my local file that works. Which is the correct file, yes
Josh Mandel (Dec 03 2021 at 00:22):
Okay, and that's what's in the GCP bucket?
Grahame Grieve (Dec 03 2021 at 00:25):
I think so. checking...
Grahame Grieve (Dec 03 2021 at 00:26):
my local file: 914,069,742 bytes
Grahame Grieve (Dec 03 2021 at 00:27):
Error>
<Code>AccessDenied</Code>
<Message>Access denied.</Message>
<Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details>
</Error>
trying to download what's in the cache?
Grahame Grieve (Dec 03 2021 at 00:28):
and I can't see it's metadata... I'm only an admin, wth. permissions have changed?
Grahame Grieve (Dec 03 2021 at 01:00):
yes the hash is different when running on the server.
Josh Mandel (Dec 03 2021 at 01:20):
Okay, so your local file and the one in cloud storage match, and those are both different from the file from the build pipeline today.
Josh Mandel (Dec 03 2021 at 01:22):
If you just want to try clearing the cache you can merge the PR I just created
Josh Mandel (Dec 03 2021 at 01:22):
( but obviously the file shouldn't be corrupted; it could of course be old...)
Grahame Grieve (Dec 03 2021 at 01:27):
I don't know if they match, I can't check. They are suppose to
Josh Mandel (Dec 03 2021 at 01:33):
Were you unable to check the value in Google cloud storage? It should be publicly available.
Grahame Grieve (Dec 03 2021 at 01:34):
I can't access it at all, even logged in as administrator
Josh Mandel (Dec 03 2021 at 01:34):
Well that would be a problem then.
Josh Mandel (Dec 03 2021 at 01:35):
It seems the permissions have indeed been changed.
Josh Mandel (Dec 03 2021 at 01:43):
I am getting the same error as you and I try to view the file even when authenticated. I tried giving myself explicit storage admin permissions in addition to owner permissions and still no dice.
Josh Mandel (Dec 03 2021 at 01:43):
The whole thing is marked public for sure.
Josh Mandel (Dec 03 2021 at 01:52):
It looks like the legacy roles no longer work the way they used to. I added another view all role for all users, which seems to have improved things.
Josh Mandel (Dec 03 2021 at 01:52):
That said, my pull request is failing way before the step where it tries to update the cash, so you might want to check out the compilation error.
Josh Mandel (Dec 03 2021 at 01:52):
(deleted)
Grahame Grieve (Dec 03 2021 at 02:21):
Well, my build succeeded after you made those changes, so that was it
Grahame Grieve (Dec 03 2021 at 02:22):
Thanks
Last updated: Apr 12 2022 at 19:14 UTC
