testFunctionalConfigurator: Fix failures.
* Instead of Person.reference, Person.user_id is now used to log in (fe27a9c3). * Fields text were renamed to follow naming conventions (329c196d).
-
OwnerThis introduces a new "Proxy Error" failure (maybe only on slow test machines)
https://nexedi.erp5.net/test_result_module/20181015-54E69FE5/244?
This is related to slapos!374 (merged)
Apparently the tests sometimes timeout on apache. For example this test. In that case where we don't consume resource on shared frontend, I don't really see the point of having apache defaults 300 second timeout and I'm considering using a much larger
Timeout, maybe still coupled withRequestReadTimeoutto protect from buggy / malicious clients (if this is really enough to replacemod_antiloris. This will be for later if this appear to really be a problem.So this confirms that we should set a larger timeout on this apache.
-
mentioned in merge request slapos!377
-
Owner
In fact it's not a timeout problem, on the Standard Output field, we can see :
ERROR ID : 1539593663.390.876482574794 TRACEBACK : Traceback (innermost last): Module Products.CMFActivity.ActivityTool, line 357, in __call__ result = method(*self.args, **self.kw) Module Products.ERP5Type.Base, line 2600, in fixConsistency return self.checkConsistency(fixit=True, filter=filter, **kw) Module Products.ERP5Type.Core.Folder, line 1356, in checkConsistency error_list += Base.checkConsistency(self, fixit=fixit, filter=filter, **kw) Module Products.ERP5Type.Base, line 2562, in checkConsistency error_list = UnrestrictedMethod(self._checkConsistency)(fixit=fixit) Module Products.ERP5Type.UnrestrictedMethod, line 70, in unrestricted_apply return function(*args, **kw) Module Products.ERP5Configurator.Document.StandardBT5ConfiguratorItem, line 84, in _checkConsistency activate=True) Module Products.ERP5.Tool.TemplateTool, line 1210, in installBusinessTemplateListFromRepository template_list) Module Products.ERP5.Tool.TemplateTool, line 1157, in resolveBusinessTemplateListDependency with_test_dependency_list): Module Products.ERP5Type.Cache, line 373, in wrapper cache[subkey] = result = function(*args, **kw) Module Products.ERP5.Tool.TemplateTool, line 837, in getDependencyList raise BusinessTemplateMissingDependency, 'While analysing %s the following dependency could not be satisfied: %s (%s)\nReason: Business Template could not be found in the repositories'%(bt[1], dependency, version_restriction or '') BusinessTemplateMissingDependency: While analysing erp5_dhtml_style the following dependency could not be satisfied: erp5_xhtml_style () Reason: Business Template could not be found in the repositories -
Developer
I think this is a problem we talked about at the office last time, namely that product/ERP5/bootstrap is not set properly in the test instance.
-
Owner
Ah yes I remember we talked a bit about this. From the traceback it also looks this can be the reason.
-
DeveloperEdited by Arnaud Fontaine
More precisely, in my instance
product/ERP5/bootstrapis not inin erp5_tests_bt5_pathenvironment variableSOFTWARE_RELEASE/bin/runUnitTest(which in turn callsproduct/ERP5Type/tests/runUnitTest.pysettingTemplateTool.updateRepositoryBusinessTemplateList()based on this environment variable value). It seems that currentstack/erp5/buildout.cfgstill has this issue. What about this (completely untested):diff --git a/stack/erp5/buildout.cfg b/stack/erp5/buildout.cfg index fcfd940ba..6dae063e6 100644 --- a/stack/erp5/buildout.cfg +++ b/stack/erp5/buildout.cfg @@ -405,12 +405,9 @@ initialization = os.environ['SOFTWARE_HOME'] = os.path.abspath(imp.find_module('Zope2')[1]) os.environ['ZOPE_SCRIPTS'] = '' parts_directory = '''${buildout:parts-directory}''' - repository_id_list = \ - '''${erp5_repository_list:repository_id_list}'''.split()[::-1] os.environ['erp5_tests_bt5_path'] = ','.join(sum(( [bt5_path, os.path.join(bt5_path, '*')] - for bt5_path in (os.path.join(parts_directory, x, 'bt5') - for x in repository_id_list)), [])) + for bt5_path in ${bt5-repository:list}.split()),[])) extra_path_list = '''${:extra-paths}'''.split() sys.path[:0] = sum(( glob.glob(os.path.join(x, 'tests'))Not sure why we need 'BT5_REPOSITORY_PATH/*' though, will check later.
-
Owner
Thanks
There's also
erp5_tests_bootstrap_paththat should default togetBootstrapDirectory(), so theupdateRepositoryBusinessTemplateListdone here should be OK.I have a runUnitTest instance and it includes
...parts/erp5/product/ERP5/bootstrapas expected.Why does
testFunctionalConfiguratorneeds to callupdateRepositoryBusinessTemplateListin setup ? Maybe @rafael remembers ? This might be the problem here.Note that there's also same pattern in
testFunctionalConfiguratorConsulting, so if we fix we can fix both.What we can try is to remove this and see if it make the test pass.
Also, after looking at this code, I feel the way our test framework manages business template repository does not have to be so complex.
Not sure why we need 'BT5_REPOSITORY_PATH/*' though, will check later.
You are right, this is probably not needed, because
runUnitTestalways issue warning like:Ignoring non existing bt5 path None Ignoring non existing bt5 path /srv/slapgrid/slappart8/srv/runner/software/287375f0cba269902ba1bc50242839d7/parts/erp5/bt5/* -
Owner
@jerome I don't remember exactly but I think yes. The configuration process assume that portal_templates are well configured and updateRepositoryB...T... was called before (maybe I'm wrong but I'm nearly from sure that yes).
test...ConfiguratorConsulting is a variation of the testFuncionalConfigurator, so they follow the same pattter to boostrap.
-
Owner
I tried that patch again 9212f985 with a longer apache timeout and it does not finish either https://nexedi.erp5.net/test_result_module/20181024-10AFB6BC/244
@arnau we'll try to look at this tomorrow.
-
OwnerEdited by Jérome Perrin
Wow. With 9212f985 , when running test locally, in the log we can see:
2018-10-25 10:01:20.708 INFO TemplateTool.updateBusinessTemplateFromUrl Updated erp5_mysql_innodb_catalog from http://www.erp5.org/dists/snapshot/bt5//erp5_mysql_innodb_catalog.bt5configurator is installing business templates from http://www.erp5.org/dists/snapshot/bt5/ , but this is not updated.
There are a few others
"www.erp5.org/dists/snapshot"in the code... One is in testBusinessTemplate and seems needed to prove that we can install bt5 over http, so it would be hard to change this.for others:
- https://lab.nexedi.com/nexedi/erp5/blob/b955dbe00fee6e0afdb4187399376ba9747c0575/bt5/erp5_configurator_standard_ui_test/SkinTemplateItem/portal_skins/erp5_configurator_standard_ui_test/Zuite_setUpConfigurationTest.py#L27-30 I think we should drop and raise error if repository list is empty. We still have to find out why it's empty.
- There's also this script, which sets the template repository https://lab.nexedi.com/nexedi/erp5/blob/b955dbe00fee6e0afdb4187399376ba9747c0575/bt5/erp5_demo_smb/SkinTemplateItem/portal_skins/erp5_demo_smb/Alarm_installBusinessTemplateList.py I think it's no longer needed to set the repositories here, when using slapos it should be OK.
- https://lab.nexedi.com/nexedi/erp5/blob/b955dbe00fee6e0afdb4187399376ba9747c0575/bt5/erp5_ui_test/SkinTemplateItem/portal_skins/erp5_ui_test/BTZuite_reset.py I think is also needed for functional tests of template tool.
[ edit: fix indentation ]
-
Owner
Ah and http://www.erp5.org/dists/snapshot/bt5/ is not updated the files modification dates are today, but the business templates are maybe from svn, maybe from git.erp5.org.
-
Owner
There's also
erp5_tests_bootstrap_paththat should default togetBootstrapDirectory(), so theupdateRepositoryBusinessTemplateListdone here should be OK.This is done only for tests in from business templates (is there a reason ?), that's why test is still failing.
One simple fix could be 9212f985 + moving the test to business template.
-
Owner
cc @xiaowu.zhang this might be the OSOE tests you are looking for
-
Developer
Ah and http://www.erp5.org/dists/snapshot/bt5/ is not updated the files modification dates are today, but the business templates are maybe from svn, maybe from git.erp5.org.
It seems to be from SVN considering that the are not hashes but integers. @nexedi so if we still need support for remote bt5 repositories, who has access to www.erp5.org/dists/snapshot/bt5/ and could update the script to use git.erp5.org and not SVN?
-
Owner
I guess this "www.erp5.org/dists/snapshot/bt5/" can be dropped. No one uses it.
Better setup a new location with a new URL if needed.
-
Developer
testFunctionalConfigurator now passes with 5be8733c and jerome/slapos@7671b6ff.
-
Owner
The slapos change to increase test runner's apache timeout was applied to master as slapos@fce3c74a this test should be OK next time.
-
mentioned in commit jerome/slapos@7671b6ff
-
Owner
So, if I understand correctly, the timeout was increased to make the test pass because one query take an "infinite" time? But, when this functionnality will be really used on a production environnment, it will not work, because the frontend will raise a timeout. What is the improvement in such case?
-
Owner
@romain: If we look at a failing test ( example https://nexedi.erp5.net/test_result_module/20181024-10AFB6BC/244 ) we can see that the failing step was on waiting for
Zuite_waitForActivities, which is the script we use (only) in functional test to wait for all pending activities to be processed, as they are not executed automatically in the background. So it's just the "synchronously wait for all activities" (which only exist in tests) that takes more than the default 1 minute timeout.For "real users" there is no timeout, because activities happens in the background. There's even a nice progress bar displayed during this step based (if I remember coreclty) on the number of remaining activities.
-
Owner
Also about the "What is the improvement in such case?", even though it was agreed (if I understand correctly) that ERP5's default timeout of 1 minute was a bug and there should be no timeout on POST requests, this does not change anything regarding this situation. This apache configuration only applies for the "apache in front of test runner's zserver" introduced in slapos!374 (merged) in other words, only for tests.
For reference, the patch was extracted from slapos!377 which also have some other changes to apache ( but is on hold waiting for new Zope release), does not change the "default" timeout either.
