Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 FIX: Add broker_* parameters to default test config. #4831

Merged
merged 1 commit into from
Mar 26, 2021

Conversation

greschd
Copy link
Member

@greschd greschd commented Mar 24, 2021

Fixes #4830.

In the TestProfileManager, set the broker_* parameters only if they are explicitly present in the profile_info.

Previously, these were set to None by default, which caused the config validation to fail because only string values are allowed.

I think the "root cause" why this wasn't caught is because there is validation in the Config constructor, but not the Profile constructor. This is the code constructing the profile:

config = configuration.get_config(create=True)
profile = Profile(profile_name, self.profile_dictionary)
config.add_profile(profile)
config.set_default_profile(profile_name).store()

Another option for fixing this issue would be explicitly setting the broker_* parameters in _DEFAULT_PROFILE_INFO:

_DEFAULT_PROFILE_INFO = {
'name': 'test_profile',
'email': '[email protected]',
'first_name': 'AiiDA',
'last_name': 'Plugintest',
'institution': 'aiidateam',
'database_engine': 'postgresql_psycopg2',
'database_backend': 'django',
'database_username': 'aiida',
'database_password': 'aiida_pw',
'database_name': 'aiida_db',
'repo_dir': 'test_repo',
'config_dir': '.aiida',
'root_path': '',
}

@codecov
Copy link

codecov bot commented Mar 24, 2021

Codecov Report

Merging #4831 (b1c05b7) into develop (a8ee41d) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #4831   +/-   ##
========================================
  Coverage    79.52%   79.52%           
========================================
  Files          519      519           
  Lines        37087    37087           
========================================
  Hits         29490    29490           
  Misses        7597     7597           
Flag Coverage Δ
django 74.26% <ø> (ø)
sqlalchemy 73.17% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
aiida/manage/tests/__init__.py 88.54% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8ee41d...b1c05b7. Read the comment docs.

Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks a lot for the fix @greschd

just one comment

'repository_uri': f'file://{self.repo}',
}
for key in ['broker_protocol', 'broker_username', 'broker_password', 'broker_host', 'broker_port']:
Copy link
Member

@ltalirz ltalirz Mar 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess currently these are the only ones regarded as optional, but one could also imagine e.g. the database_port having a default value in the future.

Why not use this loop for all keys of the dictionary?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to note,
for the broker defaults, they currently come from BROKER_DEFAULTS:

BROKER_DEFAULTS = AttributeDict({
, and then the database defaults come from somewhere else.

But really I think all the defaults should derive from the schema defaults (in https://github.com/aiidateam/aiida-core/blob/develop/aiida/manage/configuration/schema/config-v5.schema.json), as happens for the options, i.e. the schema would be the "source of truth" for all defaults.

I just didn't have time to do this with the configuration refactor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use this loop for all keys of the dictionary?

If null is invalid for all keys I agree that makes more sense.

Maybe getting the defaults for both the broker and the other options from the schema can be a separate PR?

@ltalirz
Copy link
Member

ltalirz commented Mar 24, 2021

I think the "root cause" why this wasn't caught is because there is validation in the Config constructor, but not the Profile constructor.

This is a bug, right?
At least at the point where the config with the new profiles is written to disk, we should validate.
It should not be possible for AiiDA to write an invalid config file.

This can be fixed in another PR if you prefer but I think this should be addressed.

@chrisjsewell
Copy link
Member

This is a bug, right?
At least at the point where the config with the new profiles is written to disk, we should validate.

I'm sure we discussed this in #4712 and agreed not to validate (I can't find exactly where now though)

Note whenever you alter individual configuration options or when you use verdi setup/quicksetup these values are already validated then.
So in principle the config in memory will always be valid, because you validate on read then validate on modification. But in this test code you go through the "non-standard" route of generating the configuration

@greschd
Copy link
Member Author

greschd commented Mar 24, 2021

This can be fixed in another PR if you prefer but I think this should be addressed.

I'm not so up-to-date on the configuration code, so yeah it would probably be easier for someone else to address this in a separate PR.

@greschd greschd force-pushed the fix/test_fixtures_configuration branch from c82b591 to 4961d93 Compare March 24, 2021 11:48
ltalirz
ltalirz previously approved these changes Mar 24, 2021
Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @greschd

@greschd
Copy link
Member Author

greschd commented Mar 24, 2021

Aah, seems some parts of the test suite require those keys to be there (even if they're None I guess).

Maybe the simplest way to fix this then is to add the broker_* parameters to _DEFAULT_PROFILE_INFO?

@greschd
Copy link
Member Author

greschd commented Mar 25, 2021

Alright, next try: Now I simply added the configuration values to _DEFAULT_PROFILE_INFO.

Initially I had them extracted programmatically from the config schema, but then I noticed not all keys are the same in profile_info as they are in the schema (e.g., the AIIDADB_* keys are renamed to database_*). So now I'm not sure if extracting them directly is reliable, or where this key mapping comes from.

In the `TestManager`, set the `broker_*` parameters by adding
them to the `_DEFAULT_PROFILE_INFO`.

The default values were copied from the config schema. They could
be extracted directly, but since some keys (e.g. `AIIDADB_*`)
are named differently in the `profile_info` compared to the
config schema, this may be unreliable.

Previously, these were set to `None` by default, which caused the
config validation to fail because only string values are allowed.
@greschd greschd force-pushed the fix/test_fixtures_configuration branch from 0ab25f1 to b1c05b7 Compare March 25, 2021 09:55
@greschd greschd changed the title 🐛 FIX: Remove null broker_* parameters from test config. 🐛 FIX: Add broker_* parameters to default test config. Mar 25, 2021
@chrisjsewell
Copy link
Member

cheers

So now I'm not sure if extracting them directly is reliable, or where this key mapping comes from.

The key mapping comes from:

_map_config_to_internal = {

We also discussed removing this mapping in #4712 (but as with #4831 (comment), that PR was already big enough, so didn't want to add any more complexity)

@greschd
Copy link
Member Author

greschd commented Mar 25, 2021

Thanks @chrisjsewell - do you think it'd be better in this PR to hard-code things (and clean up together with further config refactoring), or go through the mapping and get these values from the schema?

I think, since there's a test checking that the test config validates, we should at least notice when things are broken now.

@greschd greschd requested a review from ltalirz March 26, 2021 08:12
Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @greschd - sorry for the back & forth

@ltalirz ltalirz merged commit 5b3e555 into aiidateam:develop Mar 26, 2021
@greschd
Copy link
Member Author

greschd commented Mar 26, 2021

No problem, and thanks for the review @ltalirz!

@greschd greschd deleted the fix/test_fixtures_configuration branch March 26, 2021 09:09
zhubonan pushed a commit to zhubonan/aiida-core that referenced this pull request Mar 28, 2021
)

In the `TestManager`, set the `broker_*` parameters by adding
them to the `_DEFAULT_PROFILE_INFO`.

The default values were copied from the config schema. They could
be extracted directly, but since some keys (e.g. `AIIDADB_*`)
are named differently in the `profile_info` compared to the
config schema, this may be unreliable.

Previously, these were set to `None` by default, which caused the
config validation to fail because only string values are allowed.
@zhubonan
Copy link
Contributor

Thanks for the fix! The original bug appears to break plugin tests that involve running processes with the daemon.
Is there any plan to have a bug fix release? This would help with CI tests since we use the last released AiiDA version. Alternatively, we have to pin the tests to a patched AiiDA version.

@chrisjsewell
Copy link
Member

yes there will be a release

@espenfl
Copy link
Contributor

espenfl commented Apr 8, 2021

Thanks for fixing this folks. Any ETA on the release?

@greschd
Copy link
Member Author

greschd commented Apr 8, 2021

I think it's already released in 1.6.1.

@chrisjsewell
Copy link
Member

Yep 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Config created by aiida_profile fixture does not pass validation
5 participants