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

type plugin not mounted #2384

Open
markus2330 opened this Issue Feb 8, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@markus2330
Copy link
Contributor

markus2330 commented Feb 8, 2019

Steps to Reproduce the Problem

Do as instructed in examples/highlevel:

cd examples/highlevel
sudo kdb mount spec.ini 'spec/sw/example/highlevel/#0/current' ni
sudo kdb import 'spec/sw/example/highlevel/#0/current' ni < spec.ini
sudo kdb spec-mount '/sw/example/highlevel/#0/current'

and then try to set an invalid value:

kdb set /sw/example/highlevel/#0/current/myint abc

Expected Result

That it fails with an type error.

Actual Result

It succeeds.

System Information

  • Elektra Version: master

Further Log Files and Output

It seems like the type plugin is not mounted and #2377 did not improve the situation:

kdb mountpoint-info /sw/example/highlevel/#0/current
Version: 0.8.25
Default resolver: resolver_fm_hpu_b
Default storage: dump
Mountpoint: /sw/example/highlevel/#0/current
File: highlevelexamples.conf
        config:
        fcrypt/textmode = 0
        path = highlevelexamples.conf
getplugins:
        #0#resolver
        #5#dump#storage#
        #9#hexnumber#hexnumber#
setplugins:
        #0#resolver
        #1#hexnumber
        #5#storage
        #6#sync#sync#
        #7#resolver
errorplugins:
        #5#resolver_fm_hpu_b#resolver#
@kodebach

This comment has been minimized.

Copy link
Contributor

kodebach commented Feb 9, 2019

I observed the same behaviour. Weirdly the hexnumber plugin is mounted instead although none of its metadata is used.

@markus2330

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 9, 2019

Yes, it is weird but understandable: the hexnumber plugin also provides "type" as meta data. It is preferred because it has a better score in info/status.

So we either:

  • improve the type plugin to have the better score
  • remove the "type" specifier in hexnumber
  • improve the spec-mount tools to understand the meta-value of type.
  • finish the type dispatcher #1373 (which would be the only plugin to take care of type and dispatches the information to other plugins)
@kodebach

This comment has been minimized.

Copy link
Contributor

kodebach commented Feb 9, 2019

Shouldn't we just mount all plugins that use a certain metadata? If certain plugins would conflict with each other, we should have a way to state that in the infos of those plugins. Only in conflicting cases the plugin with the better score should be chosen.

  • improve the type plugin to have the better score
  • remove the "type" specifier in hexnumber

One of these would be the quick solution. Type dispatcher seems like a good idea, but would probably take some time. If we want to elektrify LCDproc without C++ dependencies, we need to rewrite the type plugin anyways, so I guess improving the type would be the best way to go for now.

@markus2330

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 9, 2019

Shouldn't we just mount all plugins that use a certain metadata?

No, a plugin providing metadata means that the plugin fulfills this property. Otherwise non-idempotent actions like renaming would not work.

If certain plugins would conflict with each other, we should have a way to state that in the infos of those plugins.

This is quite problematic because then you need an NP-complete solver to find the correct plugins. It is also quite error-prone to specify all conflicts correctly. (and assumes a closed world)

If we want to elektrify LCDproc without C++ dependencies, we need to rewrite the type plugin anyways, so I guess improving the type would be the best way to go for now.

Yes, a type plugin written in C that checks for the basic types and calls other validation plugins if type is not supported (like hexcode) should be viable. Most of the complexity in #1373 is not needed for LCDproc. But let us see what @Piankero says. Validation is low-priority work for you (only if everything else already works.)

@kodebach

This comment has been minimized.

Copy link
Contributor

kodebach commented Feb 9, 2019

a plugin providing metadata means that the plugin fulfills this property

Well in that case hexnumber doesn't provide type... We should also make the documentation of CONTRACT.ini more specific, so that developers know this is what happens when you add metadata to your infos/metadata.

markus2330 added a commit that referenced this issue Feb 9, 2019

markus2330 added a commit that referenced this issue Feb 10, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 10, 2019

A wrote a bit about spec-mount and specifications in 7d6b724

Well in that case hexnumber doesn't provide type

I fixed it in df3409c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment