Good point, Rubens! Now we'll see the real case of using Import directive )

But I see this as a good problem to have - to the moment the number of libraries available on ZPM is very few.

And I updated the post and added the part on packages names - thanks!

Hi Rubens! Thanks for the valuable input.

Yes, freedom is a great thing as soon as nobody harms you upon freedom concepts. What I mean everybody should enjoy the freedom and that's why we perhaps need some community rules to avoid chaos. 

E.g. what if some developer will introduce another module Frontier then Rubens Silva's Frontier?  And if I want these modules to run both in one namespace? 

It's not rocket science, people already have invented naming conventions that's what I'm going to talk and agree about.

Sure!

just add the volume mapping in docker-compose.yml file which maps folder /csp in sources into /csp directory in docker.

Hi @Warlin Garcia !

I pushed the commit into the repo which fixes Namespace and README issue, thanks!

- The notes/documentation say that code will be loaded into USER namespace, however it's actually being loaded into IRISAPP (as configured in docckerfiles).  

Because I made an update to the code recently) And not to the documentation) PR is welcome, or I'll change it by myself soon. Or add an issue!

- The jason.config is pointing to USER namespace so any new files and changes to existing will be actually loaded into USER instead of IRISAPP

Yes, it's a bug from previous version. Need to be fixed, thanks!

- The webapp (irisweb) is missing a config for the directory where to store files. I fixed this by modifying the app in management portal. Need to address the installation file/dockerfile

Cool!

Do you want to make a PR?

- Haven't been able to make CSPs flow to the container the same as classes. I'm sure I'm missing something but haven't figured out what yet. Any tips? Maybe I'm placing files in the wrong location? Right now I created a csp/irisweb folder under src folder.  

You need to COPY this files from /csp in sources to /usr/irissys/mgr/csp/yourwebapp  in Dockerfile
 

Hi @Conor Walsh! Thanks for sharing Container tools! Cool stuff!

Hi Vitaly!

Thanks for the idea!

Please submit a task and vote for it.

If we have a lot of votes will consider to add it.

I have one problem with it - if we introduce Russian Community, will you stop answering questions in English? )

Hi Conor!

Thanks for really wise suggestions.  Agreed with everything. Two cents/comments:

1. I think we never want to code a lot of ObjectScript inside Dockerfile. Only a few lines to make some necessary configurations and the intention is to make the code more readable paying with some coding conditions (like sc hard-coded sc for error handling). 

2. I am very supportive about putting all the possible setup activity into Installer.cls. But the issue is that not all the actively used setup tweaks are supported by %Installer format, e.g. RESTFul Web app. If you suggest to use <Invoke> - it's better to call method directly. So, here I'm putting some wishes for %Installer format approvements.

Always open for improvements.

Well, here are some comments:

do ##class(%SYSTEM.Process).CurrentDirectory("$PWD")

This is to make WORKDIR /opt/irisapp current for IRIS.

$@

Here we run the arbitrary ObjectScript in Dockerfile

if '\$Get(sc) do ##class(%SYSTEM.Process).Process.Terminate(, 1)

Here we check the status of the sc variable changed with status from ObjectScript in Dockerfile if it has an error and terminate IRIS in this case and fail the build.

do ##class(SYS.Container).QuiesceForBundling()
do ##class(SYS.Container).SetMonitorStateOK("irisowner")

Two methods to prepare IRIS operate in a container mode properly. I'm pinging @Luca Ravazzolo to provide more details on it.

Do ##class(Security.Users).UnExpireUserPasswords("*")

This removes the password expiration because it's very annoying to change the password on every build. This line could be used for DEVELOPMENT MODE only. Please remove the line if you build the image for PRODUCTION.