Just an idea:

Currently, we have only templates for development.

Maybe we could create a template for docker image build purpose.
I would say that an app isn't always a single module in a namespace.
A template to configure IRIS, create namespaces, install modules, etc ... and publish to the user docker registry might be useful.

Perhaps, a better way to do this exists (maybe by using workflow, I don't know). I'm not up to date with all existing possibilities. So, If you have resources about that, I'm interested.

Thank you @Guillaume Rongier 
 

The link allows keeping all ZPM benefits.  It's more powerful than a simple `LoadDir` .

Thank you @Robert Cemper .
Glad to hear that!

The original CachéParameterFile iris.cpf does a mimic of versioning.
But it is buried deep into the installation directory and as cryptic as the
Egyptian Book of the Dead. [reserved to the priest of IRIS cultus]

;-) Yes, I guessed that there is an existing feature for cpf versionning when I see classmethod parameters in Config.CommonSingleMethods :
classmethod Get(ByRef Properties As %String, ByRef CPFFile As %String = "", Flags As %Integer = $$$CPFSave+$$$CPFWrite+$$$CPFActivate) as %Status [ Language = objectscript ]

Hi @Guillaume Rongier ,

I added a feature in version 1.0.2 to call zpm directly.

The forked repository objectscript-docker-template is up to date. See commit.

So, now for a complex application, we can create multiple namespaces and execute zpm command on freshly created namespaces. I am still open to any suggestions.

Documentation up to date here

I created an issue about that.

intersystems-iris-dev-template is also forked on my GitHub with config-api usage.
You can see the differences on this commit.
I'll keep this repo up to date for testing purposes if there is any change.

@Evgeny Shvarov, @Guillaume Rongier

Hi @Guillaume Rongier ,

Thank you for this very interesting question.

Indeed, you can't tell directly zpm to load the classes in the freshly installed namespace.

You need to perform:

zn "irisapp"
zpm "install module-name"

I consider loading the code is the role of ZPM.
In my opinion congi-api shouldn't have an option to load the code.
We could add an option to call ZPM. Something like this :

{
    "ZPM" : {
        "IRISAPP" : {
            "install" : "module-name"
        }
    }
}

Execute zpm "install module-name" in namespace IRISAPP

Obviously this is subject to discussion. Community feedback would be appreciated.

About CPF module, I agree, my library has an overlap with all classes related to %SYS Config package.
For these operations the only difference is the REST expose. So, no added value if developers don't need REST expose.
However, config-api implement a part of %SYS Security package and also %Library SQLConnection.
You can configure users, roles, resources, ssl configuration, web application, enable services, sql connexions, set SQL Privileges and you don't with CPF module.

Hope answered to your questions.

This is the correct usage.

To deploy a large application divided into several modules, using many namespaces, databases, web applications can be complex. The best way is to write a script to configure your environment and then deploy the code as you did in this simple example with zpm.

Nice !

> I need to have two entries: SYS.Databases and Databases.

Yes, perhaps should I think to implement a short way to avoid two entries when we use default settings.

 

Sure, to discuss.

@Evgeny Shvarov ,
If there is an interest, this module could be an extension for ZPM client. 

Thank you @Evgeny Shvarov !

iris-config.json - empty?
Yes, this is template. Loading this file do nothing.

For testing purposes, you should fill this file with the content in this article.

Yes, that's it.
 

Thank you @Evgeny Shvarov 
So, the main goals are REST expose and the rupture between config and code. 

%Installer allows to create, users, roles, mapping too, but it's not possible to configure SQL Privileges, SSL Configuration, SQL Connexion (config-api can do).

There are a few features existing in %Installer and not in config-api, but we have a good base to implement if needed.