-
Notifications
You must be signed in to change notification settings - Fork 37
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
feat: add apcupsd #147
base: main
Are you sure you want to change the base?
feat: add apcupsd #147
Conversation
Need opinions on whether this is too opinionated for ucore. Thoughts welcome. I personally think this is classed as a hardware enablement feature. |
I love it. I didn't realize we don't have this. |
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.
@bsherman this is a really good idea for bare metal servers.
I've also been thinking about UPSs that aren't manufactured by APC but honestly it's a bit of a mess. I've used Network UPS Tools https://networkupstools.org before but it's a much heavier tool, instead more designed for networks of multiple machines and UPSs. IMO if someone is going down that rabbithole, they're probably better off baking their own images. apcupsd on the other hand is simple and just hooks into any directly connected APC UPS. Generally though APC and Eaton brands are the main 2 that have proper vendor support for Linux, so maybe I'll take a look into Eaton support also |
I think apcupsd also works with CyberPower brand UPS |
I agree, this is clearly hardware enablement, but I also think it could be too opinionated. I like to push back and see if things like this can be done in containers instead. I'm not suggesting existing implementations are perfect, but there are examples of UPS software being run in docker: If there's no GOOD solution, maybe that's something the ucore community could build? some good container images for UPS management? |
Setting up a container for hardware enablement is cumbersome, and if the docker container isn't running and power is lost, now the system will not seamlessly shut down. |
Honestly, I consider proper power failover and safe shutdown of bare-metal machines to be mission-critical, so wouldn't want to risk it with a container solution. One would still need to run sudo systemctl enable --now apcupsd to activate the unit. |
Is there a reason why this couldn't just be a quadlet? |
What's a quadlet? |
https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html |
My take on this - the actions of apcupsd don't fit the container model, as it is a requirement to break out of the container simply by the fact that it needs to shutdown the host. While it may be certainly possible to give a container privileges to shutdown the host, I don't think it is a good idea to encourage that model - containers should be contained. I'm very happy to have some debate on this point :)
I think a fully thought-out UPS management solution for ucore would be awesome, and it's not something I've seen around in other server builds. But before committing to something like that we'd need to see what kind of uptake/adoption we see, so adding this in would be a nice way to start it off and see how it goes. |
The main pushback you are getting is more due to the fact that things added as part of the build process cannot be easily removed. Layering and/or composing FROM ucore is a valid strategy for adding things like an additional package. One of the things you can do with your ignition file is to run an rpm-ostree install as part of the first boot if composing a package is not needed/necessary. My pushback about thinking that it should not be on the host is that containers provide a wealth of flexibility. Poking holes at the sandbox is a way to solve problems at hand and not compromise the entirety of the system. You mention interaction via passing a serial device but that isn't any different from passing other hardware resources in my mind. I personally don't use the HCI images because virtualization and passthrough of hardware devices is quite possible inside of a container. |
Add the
apcupsd
package toucore
to allow bare metal servers to manage connected APC UPSes and gracefully shutdown when power runs low.Also in a separate commit I sorted all packages alphabetically to tidy things up.