Bug 1472325 - [RFE] clean up STAGE_BOOT priorities/schedule
[RFE] clean up STAGE_BOOT priorities/schedule
Status: CLOSED CURRENTRELEASE
Product: otopi
Classification: oVirt
Component: Core (Show other bugs)
master
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ovirt-4.2.0
: 1.7.2
Assigned To: Yedidyah Bar David
Jiri Belka
: CodeChange, FutureFeature
Depends On:
Blocks: 1169099
  Show dependency treegraph
 
Reported: 2017-07-18 09:14 EDT by Yedidyah Bar David
Modified: 2017-12-20 06:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-20 06:02:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sbonazzo: ovirt‑4.2?
jbelka: testing_plan_complete-
rule-engine: planning_ack?
sbonazzo: devel_ack+
lsvaty: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 79566 master MERGED Use before/after in STAGE_BOOT 2017-07-20 07:48 EDT
oVirt gerrit 79567 master MERGED packaging: setup: Remove unneeded STAGE_BOOT priorities 2017-08-17 02:11 EDT
oVirt gerrit 79568 master MERGED packaging: setup: Remove unneeded STAGE_BOOT priorities 2017-08-21 10:22 EDT
oVirt gerrit 79570 master MERGED packaging: setup: Remove unneeded STAGE_BOOT priority 2017-08-17 04:36 EDT
oVirt gerrit 79799 master MERGED packaging: spec: Require otopi 1.7.1 2017-08-02 06:23 EDT

  None (edit)
Description Yedidyah Bar David 2017-07-18 09:14:47 EDT
Description of problem:

I am opening this bug because current [1], which is for bug 1169099, fails, because I added there an event SECRETS_FILTERED_FROM_SETUP_ATTRS_MODULES to run before CORE_LOG_INIT but without setting priority.

A later patch [2] adds several new events to run before SECRETS_FILTERED_FROM_SETUP_ATTRS_MODULES.

I'd rather not set priorities to all of these, and instead give names and set before=/after= as needed, which is much cleaner and more transparent.

Priorities were added to otopi as a means to affect order of running the events quite early, and later before/after were added [3]. Some of the then-existing code that used priorities, was not changed to use before/after, and today it's a bit hard to understand the exact reasons for the priorities - as opposed to before/after, which say specifically that some event should run before or after some specific events.

I am opening this bug mainly to document what I currently think/understand about this.

So the following is an analysis of current state, partially a guesswork, with comments about what can/should be done. I am also documenting here the relevant code from engine's packaging/setup, from host-deploy (which is simpler - only two events), ovirt-hosted-engine-setup (only 1 event).

CORE_LOG_INIT
=============
is in otopi:src/plugins/otopi/core/log.py
has PRIORITY_HIGH

Many _BOOT events in the engine and all in host-deploy and hosted-engine-setup that have before=CORE_LOG_INIT also need to have a specific priority.

Plan:
- Drop priority from this and all related events
- Check which events in _BOOT write to the log and either move them to _INIT or make them after=CORE_LOG_INIT

CORE_CONFIG_INIT
================
is in otopi:src/plugins/otopi/core/config.py
is in stage_INIT, not _BOOT
sets a default CONFIG_FILE_NAME if not set yet
sas PRIORITY_HIGH - 10

CONFIG_FILE_NAME is actually set by both engine and host-deploy at stage _BOOT, so no need to have priority for either for it or engine/host-deploy, as _boot runs before _init.

Plan:
- Drop priority from it and events setting CONFIG_FILE_NAME in engine/host-deploy

otopi packagers
===============
dnf has: PRIORITY_LOW
yum has: PRIORITY_LOW+1

It's set so that dnf runs before yum, because if a system has both, we want dnf to be used and not yum.

Plan:
- Drop priority
- Add a name to yum
- Make dnf run before=yum

otopi dialect
=============
is in otopi:src/plugins/otopi/dialog/misc.py
has PRIORITY_HIGH
sets default dialog to be human

machine and human plugins _BOOT events run at PRIORITY_MEDIUM

Plan:
- Remove priorities
- Give misc.py a name
- Run the others after it

other stuff
===========
otopi:src/plugins/otopi/core/misc.py
PRIORITY_LOW
Logs the sequence and the initial environment

otopi:src/plugins/otopi/system/info.py
PRIORITY_LOW
Logs random system info

I guess both are LOW so that they run after the log file is created.

Plan:
- Remove priority
- Run after=CORE_LOG_INIT

[1] https://gerrit.ovirt.org/#/c/79343/4
[2] https://gerrit.ovirt.org/#/c/79344/4
[3] https://gerrit.ovirt.org/11778
Comment 1 Jiri Belka 2017-10-30 04:39:31 EDT
Could you please provide verification steps if there are any? Thank you.
Comment 2 Yedidyah Bar David 2017-10-30 04:46:53 EDT
(In reply to Jiri Belka from comment #1)
> Could you please provide verification steps if there are any? Thank you.

Comment 0 is very detailed, and IIRC the patches actually do exactly what I wrote there. Most of the stuff there would probably have been noticed already by basic sanity tests done elsewhere - e.g. log file in /tmp and not in /var, stuff like that. Feel free to review it and decide to do a few specific tests if you think they make sense. Other than that, can't think of anything specific, setting CodeChange.
Comment 3 Jiri Belka 2017-10-31 05:59:34 EDT
ok, otopi-1.7.2-0.0.master.20170919135351.gitf2bfc9c.el7.centos.noarch
ovirt-host-deploy-1.7.0-0.0.master.20170912090102.git1eeb5a2.el7.centos.noarch

deploying hosts works ok
Comment 4 Sandro Bonazzola 2017-12-20 06:02:04 EST
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.