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

is_not_rw_storage broken #2423

Closed
2 tasks
markus2330 opened this issue Feb 16, 2019 · 19 comments
Closed
2 tasks

is_not_rw_storage broken #2423

markus2330 opened this issue Feb 16, 2019 · 19 comments
Assignees
Labels
Milestone

Comments

@markus2330
Copy link
Contributor

markus2330 commented Feb 16, 2019

As @kodebach reported in #2419:

Yes, but that is broken, because is_not_rw_storage doesn't work. Not even dump is recognized as a storage plugin.

Fix is_not_rw_storage in include_common.sh.in tests/shell/check_export.sh so we detect problems like this in future.

  • fix is_not_rw_storage
  • fix testscr_check_import
@markus2330
Copy link
Contributor Author

@kodebach Can you elaborate what exactly is broken in is_not_rw_storage?

@kodebach
Copy link
Member

kodebach commented Feb 16, 2019

I just looked at the output of testscr_check_export (called with ctest -R testscr_check_export --verbose inside the build directory):

108: Check if script tests the correct version
108: base64 not a read-write storage
108: boolean not a read-write storage
108: c not a read-write storage
[...]
108: dump not a read-write storage
[...]

The test prints one line for each plugin that was compiled and then exits successfully. (Should probably fail if no read-write storage plugin was found, because at least one is required for Elektra to function properly)

Which has to correspond to these lines from tests/shell/check_export.sh:

	if is_not_rw_storage; then
		echo "$PLUGIN not a read-write storage"
		continue
	fi

So is_not_rw_storage always returns true.

@markus2330
Copy link
Contributor Author

Thank you for reporting!

I agree it should fail if no plugins can be found.

@kodebach
Copy link
Member

This issue also applies to testscr_check_import.

@markus2330 markus2330 modified the milestones: 0.8.26, 0.8.27 Feb 19, 2019
llukask added a commit to llukask/libelektra that referenced this issue Mar 18, 2019
is_not_rw_storage now checks if the output of "kdb info {plugin}
provides" contains the word "storage" instead of checking if it is equal
to storage.

 ElektraInitiative#2423
llukask added a commit to llukask/libelektra that referenced this issue Mar 18, 2019
check_export did not expect the quotes around the value in the output of
"kdb set". It now does.

 ElektraInitiative#2423
@llukask
Copy link
Contributor

llukask commented Mar 19, 2019

The problem with is_not_rw_storage is that it checks if the output of kdb info $PLUGIN provides is equal to storage, but for a plugin to be a storage plugin the output only has to contain the word storage.

When I fixed this in my fork all of the tests that use is_not_rw_storage (that is check_export, check_import, check_get_set and check_kdb_internal_suite) started to fail.

Most of the check_export and check_import tests fail because the necessary files in tests/shell/shell don't exist, but some fail for other reasons: the mmapstorage and mmapstorage_crc plugins fail because of permission stuff and the tcl plugin check_export tests fail because the output is incorrect. Those tests produce a lot of output so I might have missed something. I didn't look at check_get_set and check_kdb_internal_suite yet.

@kodebach
Copy link
Member

Most of the check_export and check_import tests fail because the necessary files in tests/shell/shell don't exist

If you uncomment this line:


you can run the testcase testscr_generate_data to generate the files in tests/shell/shell. Some plugins however shouldn't be tested because they are not normal read-write-storage plugins (e.g. c, cpptemplate, specload), so you should first exclude the ones that shouldn't run.

For mmapstoarge to work the tests cannot use stdin/stdout (see #2401). DON'T try to fix the problem by running the test with sudo, this breaks /dev/stdout (see here).

llukask added a commit to llukask/libelektra that referenced this issue Apr 7, 2019
is_not_rw_storage now checks if the output of "kdb info {plugin}
provides" contains the word "storage" instead of checking if it is equal
to storage.

 ElektraInitiative#2423
llukask added a commit to llukask/libelektra that referenced this issue Apr 7, 2019
check_export did not expect the quotes around the value in the output of
"kdb set". It now does.

 ElektraInitiative#2423
llukask added a commit to llukask/libelektra that referenced this issue Apr 7, 2019
is_not_rw_storage now checks if the output of "kdb info {plugin}
provides" contains the word "storage" instead of checking if it is equal
to storage.

 ElektraInitiative#2423
llukask added a commit to llukask/libelektra that referenced this issue Apr 7, 2019
check_export did not expect the quotes around the value in the output of
"kdb set". It now does.

 ElektraInitiative#2423
@llukask
Copy link
Contributor

llukask commented Apr 8, 2019

In the process of fixing this a few problems occured, which is why i had to exclude some plugins (tcl, mini, simpleini) from the tests that probably should not be excluded.

The problems are all very similar, they all boil down to the same sequence of commands:

kdb set user/test hello
kdb export user/test $PLUGIN | kdb import user/test_other $PLUGIN

With the mini and tcl plugins this produces an error because the key name is empty (e.g. just =hello in ini).

The simpleini seems to not read anything from stdin and does nothing if you import = hello. The dini plugins seem to not read anything from stdin but can deal with importing = hello. Meaning the following works for dini (and for simpleini if the key name is not empty),

kdb set user/test hello
kdb export user/test $PLUGIN > test.ini
kdb import user/test_other $PLUGIN test.ini

@kodebach
Copy link
Member

kodebach commented Apr 8, 2019

You could also try this:

kdb set user/test hello
kdb export user/test $PLUGIN test.ini
kdb import user/test_other $PLUGIN test.ini

Some plugins might have problems with writing to stdout as well as reading from stdin, because they need to read the file out of order.

@llukask
Copy link
Contributor

llukask commented Apr 8, 2019

Yes, I am doing that for dini

@markus2330 markus2330 modified the milestones: 0.9.0, 0.9.1 Aug 2, 2019
llukask added a commit to llukask/libelektra that referenced this issue Aug 7, 2019
is_not_rw_storage now checks if the output of "kdb info {plugin}
provides" contains the word "storage" instead of checking if it is equal
to storage.

 ElektraInitiative#2423
llukask added a commit to llukask/libelektra that referenced this issue Aug 7, 2019
check_export did not expect the quotes around the value in the output of
"kdb set". It now does.

 ElektraInitiative#2423
@markus2330 markus2330 modified the milestones: 0.9.1, 0.9.* Nov 15, 2019
@markus2330
Copy link
Contributor Author

(Assigned as already agreed in #2595)

@markus2330
Copy link
Contributor Author

@kodebach is it still feasible that you solve this issue?

@kodebach
Copy link
Member

I'll look at #2595 and see what needs to be done..

mpranj pushed a commit that referenced this issue Oct 1, 2020
is_not_rw_storage now checks if the output of "kdb info {plugin}
provides" contains the word "storage" instead of checking if it is equal
to storage.

 #2423
mpranj pushed a commit that referenced this issue Oct 1, 2020
check_export did not expect the quotes around the value in the output of
"kdb set". It now does.

 #2423
@mpranj mpranj closed this as completed in 5f88177 Oct 1, 2020
@mpranj
Copy link
Member

mpranj commented Oct 1, 2020

If this was not completely resolved by #2595 please reopen.

@mpranj mpranj modified the milestones: 0.9.*, 0.9.3 Oct 1, 2020
@mpranj
Copy link
Member

mpranj commented Oct 2, 2020

@mpranj mpranj reopened this Oct 2, 2020
@kodebach
Copy link
Member

kodebach commented Oct 2, 2020

Only the version with the ini plugin as default storage failed. I don't the problem is with is_not_rw_storage, it probably is just another bug in ini. Maybe we should just disable this build job, since it will be removed soon anyway.

@mpranj
Copy link
Member

mpranj commented Oct 2, 2020

Thank you for looking into it. Yes, ini is about to be removed very soon. If I remove it now we will have a merge conflict with #3491. We can't cherry-pick since the commit also changes other files. @markus2330 is it ok if you resolve the conflict in your PR?

@markus2330
Copy link
Contributor Author

Thank you both 🎆

@mpranj yes, it would be appreciated if you do fixes in the PR!

Having a fixed master has of course the highest priority 🚀

@mpranj mpranj modified the milestones: 0.9.3, 0.9.4 Oct 30, 2020
@markus2330
Copy link
Contributor Author

Everything should be fixed now. @kodebach Can we close this issue?

@kodebach
Copy link
Member

kodebach commented Dec 6, 2020

AFAIK everything is fixed

@kodebach kodebach closed this as completed Dec 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants