Improve Elektra's default behaviour

[markus2330]

Elektra should make sure that following global plugins are always mounted:

• [ ] spec plugin
• [ ] all plugins that were already there before

Furthermore following plugins should be in every mountpoint:

• [ ] sync, see #423
• [ ] all plugins as specified by spec/<mountpoint>
• [ ] all plugins as specified by kdb tools' options.

[markus2330]

@kodebach: is it better to add gopts by default or only by kdbEnsure (or hopefully kdbOpen soon)

[kodebach]

For now using kdbEnsure is better. In the long term I don't see why we shouldn't mount gopts by default. But that requires changes to kdb (already discussed somewhere), since gopts should not run when the kdb tool accesses another application's configuration.

[markus2330]

Ok, I think we can also add more global default plugins during 1.0. So lets move this for after 1.0.

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[markus2330]

@kodebach I think this should be fixed with the new backend plugin.

[kodebach]

The spec plugin will be fixed by #3693, because it won't be a real plugin that can be mounted anymore.

I'm not sure what "all plugins that were already there before" is supposed to mean.

Always mounting sync will be the responsibility of any file-based backend plugin. For the backend plugin I will implement this.

The other two points are purely a tools issue.

[markus2330]

The spec plugin will be fixed by #3693, because it won't be a real plugin that can be mounted anymore.

Did you describe this somewhere?

I'm not sure what "all plugins that were already there before" is supposed to mean.

It is about the bug that @mpranj currently rediscovered: after mounting dbus the cache disappears and similar.

Always mounting sync will be the responsibility of any file-based backend plugin. For the backend plugin I will implement this.

:+1:

The other two points are purely a tools issue.

The tooling is very important so that mounting works properly for users.

[kodebach]

Did you describe this somewhere?

Not in detail, but in kdb-operations.md I wrote about explicitly calling spec/gopts and not about general global plugins.

after mounting dbus the cache disappears and similar

That is a problem of the tools. But this should also be solved by removing the concept of general global plugins.

The tooling is very important so that mounting works properly for users.

Yes, but if I touch the tools at all in #3693 (it is big enough already), it will only be the bare minimum to make things work. Fixing other tooling problems should be a separate PR.

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[markus2330]

Most of this actually should be fixed with the new-style global plugins in new-backend? (@atmaxinger)

Other parts, however, should be new behavior for mounting: #423 (@flo91)

[atmaxinger]

@markus2330 yes that should be fixed

[kodebach]

Other parts, however, should be new behavior for mounting: #423 (@flo91)

As stated above:

Always mounting sync will be the responsibility of any file-based backend plugin. For the backend plugin I will implement this.

So just to be clear: The sync plugin issue must be handled by the backend plugin (because e.g. a DB backend doesn't need sync). There should not be some logic somewhere in the kdb mount code (or the library behind) that adds sync to backends. Such code must only exist in the backend plugin. Maybe in a function called by kdb mount, or maybe in kdbOpen/kdbInit to just load the plugin no matter what the config says.

[markus2330]

We should make sure to always write a correct config (e.g. with sync) unless explicitly requested otherwise. The problem described here is that the default behavior surprises. Imho it would be wrong trying to fix backend configs.

[kodebach]

I have no idea what you wanted to say... But: sync is only needed, if the backend is file-based. It wouldn't even work, if the backend isn't file-based. That's also why I suggested moving the sync into the resolver, another thing that's only relevant to file-based backends and already a required part of them.

If we don't combine them it still be the obligation of the backend plugin to check that sync (or an alternative) is present. It's exactly the same with the resolver. This is not a tooling issue, and not a general issue. This is an issue only relevant to file-based backend plugins (e.g. backend).

[markus2330]

Yes, after #4187 sync is obviously only for file-based backends. I updated the top post.

[kodebach]

Do we really need a separate sync at all? The plugin literally just calls fsync (or the windows equivalent). A separate plugin is a lot of overhead for a single function call (*).

A better option would be to combine sync with either backend or even better resolver. The resolver plugin is what implements the commit phase for file-based backends, so it should call fsync. If there is a use-case where fsync is not wanted, that should just be a config option for resolver.

---

(*) Please don't ask for benchmarks again. Yes, we can debate whether the technical impact (runtime, memory use) is actually significant. IMO allocating a whole Plugin * and all that comes with it, for just one fsync call is stupid, but that's just my opinion. What is clear, is that it is definitely unnecessary and a further source of errors.

[markus2330]

Do we really need a separate sync at all?

Yes, as people might want to not call sync. Plugins give you the possibility to easily remove functionality.

Nothing new was added in the statements above. Please create a decision if you really think changing sync is something worth doing. I don't recommend to do it, it is imho better if people work on decisions their work is focused on. Then they also have more insight in the topic.

I close this issue as it gets more and more unclear what this issue is actually about.

[kodebach]

Yes, as people might want to not call sync.

Then make a config option. The resolver is complex enough that having config option for this makes sense. Then the default is also much clearer. The config option simply defaults to "use fsync", but can be disabled. The "add sync plugin automatically" is very much hidden and not obvious to users.

Also IMO it is a ludicrous exaggeration of the "everything is a plugin" stance to have a plugin that literally just does open; fsync; close. IMO this overhead simply cannot be worth it. No I won't benchmark it. Yes, it might not be significant in the grand scheme of things. It is still totally unnecessary overhead.

create a decision if you really think changing sync is something worth doing

This is exactly, I why I dislike the idea "just start a decision PR". I absolutely do not see how this would change anything here. I have already explained my view on this. Opening a PR just to here you once again say, "I don't think we should do this", would only be frustrating. It would serve no purpose and only waste time. And yes, writing this comment was much faster than crafting a decision PR.