-
Notifications
You must be signed in to change notification settings - Fork 24
Add 'Improve MicroOS management' RFC #92
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
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,142 @@ | ||
- Feature Name: (fill with a unique ident, my_awesome_feature) | ||
- Start Date: (fill with today's date, YYYY-MM-DD) | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
Improve the management of openSUSE MicroOS in Uyuni. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
MicroOS, or the downstream SLE Micro, is a different operating system than e.g. SLES. It is based on the same tools and packages, with few additions on top. These additions are few, but completely change the operating model. | ||
|
||
The main idea is: **All changes go into a new btrfs snapshot. This new snapshot is "pending" until a reboot activates it.** | ||
|
||
Until now, we tried to hide the differences in Uyuni and relied on Salt to do the *right thing*. This strategy was easy for us to use, but it did not work well. We need to change the approach we take with transactional systems. | ||
|
||
# Detailed design | ||
[design]: #detailed-design | ||
|
||
## Uyuni differentiates between OS-unchanging and OS-altering operations | ||
Instead of using the `transactional_update` executor, Uyuni calls either `state.apply` or `transactional_update.apply`. Uyuni is in full control of which states are applied in a new snapshot and which states are not. The SLS file is the smallest unit Salt can handle, there is no way to apply only parts of an SLS file inside a snapshot. Therefore, we split SLS files that currently mix OS-unchanging and OS-altering operations. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just to clarify, for internal states (example There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, Uyuni maps the internal states (see the mapping below) to either There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nitpick: It would be good to list here as well how |
||
|
||
The operations below map to SLS files. The syntax used for operations in this document is the same that's used in for Salt `top.sls`. | ||
|
||
### Two approaches to run operations | ||
|
||
- `state.apply` and `transactional_update.apply` | ||
- Java code supports both | ||
- UI shows both on pages were users can schedule actions | ||
- API offers a way to choose between the two | ||
|
||
### Uncategorized operations | ||
|
||
- `virt.*`: About to be dropped | ||
- `bootloader`: TODO | ||
- `rebootifneeded` - The way this is written is incompatible with transactional systems | ||
|
||
### OS-unchanging operations | ||
|
||
These operations do not alter the system, i.e. they don't belong in a (new) snapshot. Uyuni applies them with `state.apply` for two reasons: structured output and no concurrency (`queue=True`). | ||
|
||
- `ansible.runplaybook` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is Then again, if we make this a transactional action, that means the playbook files must be present on the transactional filesystem. We should probably make a note somewhere in the doc at least that we don't support Uyuni/SUMA server to alter itself with Ansible. |
||
- `cocoattest.requestdata` | ||
- `hardware.profileupdate` | ||
- `images.*` | ||
- `packages.profileupdate` | ||
- `packages.redhatproductinfo` | ||
- `srvmonitoring.status` | ||
- `util.sync*` | ||
- `util.systeminfo_full` | ||
- `util.systeminfo` | ||
|
||
#### Required Changes | ||
|
||
- Extract installation steps in `cocoattest` to a new SLS | ||
- Extract `dmidecode` installation steps in `hardware.profileupdate` to a new SLS | ||
|
||
### OS-altering operations | ||
|
||
These operations alter the operating system itself, i.e. they belong in a (new) snapshot. Uyuni applies them with `transactional_update.apply`, unless otherwise noted. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you elaborate it please, like in what possible situations this could be the case. |
||
|
||
- `ansible` | ||
- `appstreams.configure` | ||
- `bootstrap` - special case, it's always applied with `state.apply` because Uyuni does not know if the target uses `transactional-update` | ||
- `certs` | ||
- `channels` | ||
- `cleanup_minion` | ||
- `cleanup_ssh_minion` | ||
- `configuration.deploy_files` NOTE: reconfiguring a service through `/etc` is special as there is an overlayfs. | ||
- `distupgrade` | ||
- `packages.patch*` | ||
- `packages.pkg*` | ||
- `packages` | ||
- `reboot` | ||
- `services.docker` | ||
- `services.kiwi-image-server` | ||
- `services.reportdb-user` | ||
- `services.salt-minion` REVIEW: Is all of this still needed? NOTE: `file.managed` in `/etc` | ||
- `srvmonitoring.disable` | ||
- `srvmonitoring.enable` | ||
- `switch_to_bundle` | ||
- `update-salt` | ||
- `uptodate` | ||
- `util.disable_fqdns_grain`: NOTE: configures in `/etc`, restarts a service (currently broken) | ||
- `util.mgr_mine_config_clean_up`: NOTE: configures in `/etc`, restarts a service (currently broken) | ||
- `util.mgr_rotate_saltssh_key` | ||
- `util.mgr_start_event_grains` NOTE: configures in `/etc` | ||
- `util.mgr_switch_to_venv_minion` | ||
|
||
### Either OS-unchanging or OS-altering operations | ||
|
||
These operations can be either OS-unchanging or OS-altering because they are to generic to know ahead of time. Users need to have control over the way these Salt states are applied. | ||
|
||
- `custom` | ||
- `custom_groups` | ||
- `custom_org` | ||
- `recurring` | ||
- `remotecommands` | ||
- `scap` NOTE: `remediate=True` is likely OS-altering | ||
|
||
## Automatic reboots during bootstrapping | ||
|
||
When bootstrapping a new system, Uyuni relies on information present on the client system to know what kind of system it is. This includes finding out if the new system is a transactional system. Bootstrapping happens with Salt SSH and `state.apply`. The bootstrap SLS file contains logic to install our Salt Minion package correctly on both traditionally-managed and transactional systems. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see you're explaining how things are currently working, but reading it in flow, it seems a bit contradictory considering that just a few lines above, we defined |
||
|
||
The bootstrap SLS file installs the Salt Minion package into the next snapshot. We need to reboot the Minion after installing this package. | ||
|
||
### Add Inhibitor Lock to Salt SSH | ||
|
||
Applications can set _inhibitor locks_ to block or delay system shutdown and sleep states. Salt SSH sets a _delay_ inhibitor lock to stop the system from rebooting immediately. Salt SSH has time to return job results back to the Salt Master, unless it takes longer than _InhibitDelayMaxSecs_. This config setting is specified in `logind.conf(5)` and can't be overridden by Salt SSH. The default is 5 seconds. | ||
|
||
### Request a reboot without delay | ||
|
||
With a delay lock taken, `bootstrap/init.sls` can request a reboot from systemd from the main process. The reboot will be delayed until Salt SSH execution terminates and releases the lock. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to evaluate the option where rebootmgr is default but we can override that in special cases when immediate reboot is needed? |
||
|
||
## Make state functions available for transactional systems | ||
|
||
- `service.enabled`: currently needs dbus, we need a way that does not require dbus for enabling the service | ||
- `service.disabled` currently needs dbus, we need a way that does not require dbus for enabling the service | ||
|
||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
Why should we **not** do this? | ||
|
||
* obscure corner cases | ||
* will it impact performance? | ||
* what other parts of the product will be affected? | ||
* will the solution be hard to maintain in the future? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this section complete? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, that's still the template. |
||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
- What other designs/options have been considered? | ||
- What is the impact of not doing this? | ||
|
||
# Unresolved questions | ||
[unresolved]: #unresolved-questions | ||
|
||
- What are the unknowns? | ||
- What can happen if Murphy's law holds true? |
Uh oh!
There was an error while loading. Please reload this page.