erp5: new 'id-store-interval' instance parameter

See nexedi/erp5@5169f193

software/erp5/instance-erp5-input-schema.json

@@ -21,6 +21,10 @@
       "description": "Business Template to install at automatic site creation. By default, all configurators are installed.",
       "type": "string"
     },
+    "id-store-interval": {
+      "description": "Set Store Interval of default SQL Non Continuous Increasing Id Generator at automatic site creation. If unset, the value from the erp5_core Business Template is not touched.",
+      "type": "integer"
+    },
     "timezone": {
       "description": "Zope's timezone. Possible values are determined by host's libc, and typically come from a separate package (tzdata, ...)",
       "default": "UTC",

stack/erp5/buildout.hash.cfg

@@ -39,7 +39,7 @@ md5sum = 76f9e8c8cdc352081e34539d8fc17026
 
 [template-zope-conf]
 filename = zope.conf.in
-md5sum = bbea91bc8f0b2d455d9824928abfad5b
+md5sum = 3524ef2e14cea4a5bd40fdc9e95cfc0c
 
 [site-zcml]
 filename = site.zcml
@@ -79,7 +79,7 @@ md5sum = d41d8cd98f00b204e9800998ecf8427e
 
 [template-erp5]
 filename = instance-erp5.cfg.in
-md5sum = 33c8f97afe58058d428108fb933523ac
+md5sum = 2465af81147af322056cee9f6c7de14f
 
 [template-zeo]
 filename = instance-zeo.cfg.in
@@ -87,7 +87,7 @@ md5sum = d1f33d406d528ae27d973e2dd0efb1ba
 
 [template-zope]
 filename = instance-zope.cfg.in
-md5sum = 27d26c6380883cf3bd7b2f003f7888d8
+md5sum = fd7e8c507cef1950e6c0347ce2a01021
 
 [template-balancer]
 filename = instance-balancer.cfg.in

stack/erp5/instance-erp5.cfg.in

@@ -155,6 +155,7 @@ config-deadlock-debugger-password = ${publish-early:deadlock-debugger-password}
 config-developer-list = {{ dumps(slapparameter_dict.get('developer-list', [inituser_login])) }}
 config-hosts-dict = {{ dumps(slapparameter_dict.get('hosts-dict', {})) }}
 config-hostalias-dict = {{ dumps(slapparameter_dict.get('hostalias-dict', {})) }}
+config-id-store-interval = {{ dumps(slapparameter_dict.get('id-store-interval')) }}
 config-inituser-login = {{ dumps(inituser_login) }}
 config-inituser-password = ${publish-early:inituser-password}
 config-kumofs-url = ${request-memcached-persistent:connection-url}

stack/erp5/instance-zope.cfg.in

@@ -230,6 +230,7 @@ sql-connection-string = {{ '%s@erp5-catalog-0:%s %s %s' % (
     mysql.path.split('/')[1], mysql.port, mysql.username, mysql.password) }}
 bt5 = {{ slapparameter_dict['bt5'] }}
 bt5-repository-url = {{ slapparameter_dict['bt5-repository-url'] }}
+id-store-interval = {{ dumps(slapparameter_dict['id-store-interval']) }}
 home = ${buildout:directory}
 # We only want to change the hostname to 'erp5-cloudooo' if we use the internal
 # cloudooo. We plan to remove the ability to have an internal one, so this

stack/erp5/zope.conf.in

@@ -86,6 +86,9 @@ products {{ parameter_dict['instance-products'] }}
   cmf_activity_sql_connection_string {{ sql_connection_string }}
   bt5_repository_url {{ ' '.join(bt5_repository_url) }}
   bt5 {{ parameter_dict['bt5'] }}
+{%- if parameter_dict['id-store-interval'] != None %}
+  id_store_interval {{ parameter_dict['id-store-interval'] }}
+{%- endif %}
   cloudooo_url {{ parameter_dict['cloudooo-url'] }}
 </product-config>
 

[Rafael Monnerat]

This change breaks initialisation of SlapOS Master (and tests fail the whole weekend) as we have custom some instance-*.cfg because of few certificate authority entries which we cannot avoid for now.

As this is the third time at least that it happens, and I don't expect anyone to learn slapos master itself... Could we all in @nexedi use MR and ask review once change API on slapos instantiation of ERP5? and if possible "/cc @rafael" , in this way I can check and apply the changes for SlapOS master on the same MR, preventing tests to get broken.

Thanks in advance (Fix was applied for slapos master already)

[Julien Muchembled]

Sorry for having missed but the problem is elsewhere: code duplication. It is a recurring problem that people copies things instead of doing a minimum of refactoring. Copying instance-erp5.cfg.in is not maintainable and slows down everyone. We can't all review everything.

(this is also one of the reasons for which I regret the move to jinja2 templating)

[Vincent Pelletier]

the problem is elsewhere: code duplication

I fully agree.

Work to find sustainable ways to extend without duplication is long overdue, and will have to answer questions of internal API between instanciation buildout files - a topic which I see as very hard. So hard that I do not see how it could be done without concrete example. So such work must happen when one considers copying buildout files around, in order to avoid that.

Here, it was not done, so to me the burden of checking and adapting to upstream changes belongs to maintainers of the duplicated code, not the other way around.

(this is also one of the reasons for which I regret the move to jinja2 templating)

It is probably just a poor word choice, but I do not think you have anything to regret, as you were not active on slapos development by the time it was introduced. You probably intended to say you are disappointed by some jinja limitations. Limitations which I fail to see: if anything, jinja allows more ways of including "stuff" (code or buildout config, hence reuse) than anything else we have (like old-style buildout templating: no inclusion, only variable expansion, or just buildout itself which is orthogonal to jinja). Could you explain more ?

[Rafael Monnerat]

Copying instance-erp5.cfg.in is not maintainable and slows down everyone.

Sure, Can you propose a better approach so (you can check the small diff comparing the 2 times.)? I think you can propose something as, those changes are also required for setup shacache.org without hardcoded ad-hoc apache setup like we have today.

[Julien Muchembled]

Unfortunately, I don't have a nice approach to propose, hence my parenthesis about the move to jinja2 (I already wrote about this at !196 (merged)). Several ways have been tried so far:

• e.g. ERP5 extending NEO: macros are used a lot and the resulting code is complicated
• for wendelin-scalability scenarios, I do on-the-fly patching, plus some obscure dance with template-foo/template-foo-base/template-foo-patched, and all this is not great

I wish I had more time to improve slapos framework so that SR are easier to write and extend. And like always when it's not the time to do beautiful things, it can be acceptable to do dirty things but then one assumes.

Noone to blame here.