-
Notifications
You must be signed in to change notification settings - Fork 148
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
Add foreman_ygg_migration package #11317
base: rpm/develop
Are you sure you want to change the base?
Add foreman_ygg_migration package #11317
Conversation
d9b72c8
to
7eb8bf7
Compare
[test rpm-copr] |
4fdcd1d
to
2d765be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just gathering my thoughts on this.
This is because today we ship packages/client/yggdrasil
but future EL versions will ship this instead. Those future EL versions are 0.4 which has a different architecture, but most importantly a different service name.
I'm worried that if systemctl is-enabled yggdrasild
could be unreliable to detect this. I don't know exactly what the ordering will be, but perhaps the old service file is already cleaned up and systemd doesn't know about it anymore.
|
||
if grep -q FOREMAN_YGG_WORKER_WORKDIR /etc/systemd/system/yggdrasild.service.d/* 2>/dev/null; then | ||
mkdir -p /etc/systemd/system/com.redhat.Yggdrasil1.Worker1.foreman.service.d/ | ||
cp -r /etc/systemd/system/yggdrasild.service.d/* /etc/systemd/system/com.redhat.Yggdrasil1.Worker1.foreman.service.d/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this, you may need to run systemctl daemon-reload
.
cp -r /etc/systemd/system/yggdrasild.service.d/* /etc/systemd/system/com.redhat.Yggdrasil1.Worker1.foreman.service.d/ | ||
fi | ||
|
||
systemctl disable --now yggdrasild |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the old service get uninstalled and thus removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I've seen, we're missing systemd scriptlets in our yggdrasil spec, so while the old package gets uninstalled and the yggdrasild
service definition goes away, it seems to stay enabled.
%post | ||
if systemctl is-enabled yggdrasild >/dev/null 2>/dev/null; then | ||
grep -Pq '^server' /etc/yggdrasil/config.toml || sed -i 's/broker.*=/server =/' /etc/yggdrasil/config.toml | ||
grep -Pq '^prefix' /etc/yggdrasil/config.toml || echo 'prefix = "yggdrasil"' >>/etc/yggdrasil/config.toml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't look idempotent. Perhaps grep
should be stricter to check if the prefix isn't correct? Same below for data-host
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was operating under the assumption that the configuration was generated by foreman. That would mean that the data-host
and prefix
either aren't there at all or are generated correctly (after theforeman/foreman#10340 gets in). I could tighten it down, but I'm not sure if that's worth it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I misread it and you're right, it is idempotent: either the line is there or it's added.
fi | ||
|
||
systemctl disable --now yggdrasild | ||
systemctl enable --now yggdrasil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may need to restart yggdrasil
if it's already running.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would mean that someone installed new-enough yggdrasil, started it and then installed the migration package, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, though I also wonder if that use case would be one to error out on. And you really shouldn't error out on RPM scriptlets. Still not entirely sure what's best here and currently my mind is exploring the various paths a user could take.
Correct
I tested it and it seemed to work, probably because of us not being diligent enough about service handling in the specfile of yggdrasil we ship. |
IIRC with EL9 there were some serious changes how systemd RPM packaging worked. The operations are now much more batched than on EL8 with the use |
[test rpm-copr] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack from the functional side, tested together with theforeman/katello-pull-transport-migrate#8
84698c4
to
7be2074
Compare
License: MIT | ||
|
||
%if 0%{?rhel} >= 8 | ||
Supplements: yggdrasil >= 0.4.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People can (and do 😢) disable weak dependencies.
For such setups it will mean that this package won't be automatically installed once they upgrade to 0.4.
This is not a blocker (and there is no better package relationship to fix this), but something we should keep in mind and document somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly should we document and where?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should document that if people have weak dependencies disabled, they should install this package explicitly. As to where, I'm not sure if we already have a procedure or something where this would fit well or we'll need to write a new one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I am not aware of a good place for this (maybe at least release notes?)
@@ -0,0 +1,34 @@ | |||
Name: foreman_ygg_migration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am debating with myself whether this needs to be an own package, vs a sub-package of foreman_ygg_worker
(smth like foreman_ygg_worker_migration
or so).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be cleaner, but at the same time it is not a migration of foreman_ygg_worker
This package should get pulled in when yggdrasil >=0.4.z is installed. When installed, it checks whether yggdrasild.service is enabled. If not, it does nothing. If enabled, this package tweaks yggdrasil's config file to account for the newly needed config options and migrates service overrides from the old service to the new worker. Additionally, it disables the yggdrasild service and enables yggdrasil.service. Our worker is left to be activated through dbus.
We don't expect yggdrasil >= 0.4.0 to land there
in an attempt to pass repoclosure
7be2074
to
bc6a38a
Compare
This package should get pulled in when yggdrasil >=0.4.z is installed.
When installed, it checks whether yggdrasild.service is enabled. If not, it does nothing. If enabled, this package tweaks yggdrasil's config file to account for the newly needed config options. Additionally, it disables the yggdrasild service and enables yggdrasil.service.
Our worker is left to be activated through dbus.