Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

consistent hook names #677

Closed
4 tasks
markus2330 opened this issue Apr 29, 2016 · 12 comments
Closed
4 tasks

consistent hook names #677

markus2330 opened this issue Apr 29, 2016 · 12 comments
Assignees
Labels

Comments

@markus2330
Copy link
Contributor

markus2330 commented Apr 29, 2016

  • think about hook placement
  • consistently use them
  • fix cleanup of spec plugin
  • fix semlock plugin
@markus2330 markus2330 added this to the 0.8.17 milestone Apr 29, 2016
@tom-wa
Copy link
Contributor

tom-wa commented Apr 29, 2016

spec does a cleanup then placed with the postget or preset cleanup placement though

@markus2330
Copy link
Contributor Author

@tom-wa yes, but its not yet done by the mount tool. We should first get consistent names, and then do the integration.

@mpranj
Copy link
Member

mpranj commented Jun 23, 2016

I have some questions regarding the hook names/semantics (from decisions/).
Firstly, I have this table of placements. Some were not self-explanatory for me, marked with a ?.

hook name placement/semantics
prerollback before rollback
rollback ?
postrollback after rollback
getresolver ?
pregetstorage start of kdbGet()
getstorage ?
postgetstorage end of kdbGet()
setresolver ?
presetstorage start of kdbSet()
setstorage ?
precommit before commit
commit ?
postcommit after commit

Notes:

  • seems like postsetstorage is missing, or was this intentional?
  • most of pre- post- functions is clear, but when should e.g. rollback hook be executed?
  • when does e.g. getresolver happen, on kdbGet() when the resolver itself is called (backend->getplugins[RESOLVER_PLUGIN]->kdbGet..)?

@markus2330
Copy link
Contributor Author

No, if something is missing, please add it to the proposal. Also if there are too many (which might be the case for the ones marked with ?), you can propose to remove them.

Rollback is for the case when one of the set-plugins failed. Docu is in elektra-algorithm.md and elektra-plugins-ordering.md (in doc/help).

About the exact placement: it is difficult to discuss it without code, maybe you can mark the positions in a PR for further discussions?

@markus2330
Copy link
Contributor Author

E.g. the commit-phase is a done by plugin, the idea is to have a global hook before and after it. But I did not look into the details. Note that if a global hook is pre/post to some place is decided by /before and /after, not directly by its name -- as described in the decision.

@mpranj
Copy link
Member

mpranj commented Aug 15, 2016

One more thing: I misled myself into thinking that infos/placements was where we would configure global plugin positions via contract.

I now realized that - I think - this is merely the configuration for the list plugin.
Should we add a new entry in the contracts for the positions of global plugins, or was the plan to configure them manually (i.e. setting the keys in system/elektra/globalplugins programmatically inside the plugin code).

@markus2330
Copy link
Contributor Author

One more thing: I misled myself into thinking

Wait, not so fast ;)

infos/placements was where we would configure global plugin positions via contract.

No, you are right, currently that is the case. The kdb global-mount looks at infos/placments. That it additionally uses the list plugin, is basically "implementation detail" so that more than one plugin per global placement can be used.

The backend mounting (kdb mount) will later also be converted to use the list plugin. This brings some nice features such as lazy mounting without complicating the core even more.

From the global hooks point of view it does not matter if it is a single plugin or a list plugin. You invoke the function, the keyset might get modified and you get a return value in either way.

Should we add a new entry in the contracts for the positions of global plugins

If it is needed (ergo: a hybrid plugin that actually needs different plugins for global and backend placement), we can add it.

@mpranj
Copy link
Member

mpranj commented Aug 15, 2016

If kdb global-mount honors placements from infos/placments, then I found a bug/inconsistency.

Take the dbus plugin. It has infos/placements = postgetstorage postcommit. Both positions qualify for a global position.

When I run kdb global-mount dbus it mounts dbus only to the postcommit placement, but not to postgetstorage. (when I say mount I mean kdb export system/elektra/globalplugin shows some configuration for it)

@markus2330
Copy link
Contributor Author

Cannot reproduce (at least not by looking at kdb export), please open a separate issue for it (Ideally with some tracing plugin or similar showing the problem). Note that the list plugins gets added at all placements, that does not necessarily mean that that it gets executed for every placement.

@markus2330 markus2330 removed this from the 0.8.18 milestone Sep 15, 2016
@mpranj mpranj mentioned this issue Jun 24, 2019
@stale
Copy link

stale bot commented May 6, 2020

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 💖

@stale stale bot added the stale label May 6, 2020
@mpranj mpranj removed the stale label May 6, 2020
@stale
Copy link

stale bot commented May 7, 2021

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 💖

@stale stale bot added the stale label May 7, 2021
@stale
Copy link

stale bot commented May 22, 2021

I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

@stale stale bot closed this as completed May 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants