develop examples for general purpose applications

dweomer commented 4 years ago

If it's really a general purpose upgrade controller it should work with (and provide examples for):

[x] ubuntu (see #19)
[x] suse/sles (see #128)
[ ] centos
[ ] alpine

For each system above provide:

a reasonably secure, default installation for the controller
- should include an enumeration of the rbac needs for the default user in the controller namespace (aka whatever drain needs; delete pods, edit nodes)
a useable Plan
kubectl snippets (or other script assets) for managing application of Plan(s)

tobru commented 4 years ago

I'll gladly help on this over the next days / weeks.

dweomer commented 4 years ago

I'll gladly help on this over the next days / weeks.

PRs welcome

mitchellmaler commented 4 years ago

I wonder if this can be used to orchestrate upgrades for Fedora Core OS as well?

tobru commented 4 years ago

I wonder if this can be used to orchestrate upgrades for Fedora Core OS as well?

Why not? As long as Fedora Core OS can be upgraded on the shell - which it certainly can - then there is a way to do it with SUC :rocket:

tobru commented 4 years ago

@dweomer I consider opening a documentation PR for Ubuntu. Where do you want to see this documentation go: In the README? In a separate file f.e. under docs/example_ubuntu.md? Do you have any guidelines regarding style (f.e. a boilerplate)?

schmitch commented 4 years ago

btw. it would also be great if centos/ubuntu, etc will only be restarted if a certain script renders true or has an exit code of 0, like the centos one: needs-restarting -r.

this also means that it would be possible to use yum check-update and maybe apt list --upgradable to check for new versions. so mabe it should be possible to either provide a version or a versionCheck and restartCheck command.

tobru commented 4 years ago

@schmitch As the reboot is invoked by the script executed on the node by the Pod started via the Plan, you're absolutely free to implement any logic to decide when to reboot and when not. TL;DR: Yes, it's possible to do what you suggest.

dweomer commented 4 years ago

@tobru how does examples/ubuntu/ directory with a README.md and sample manifest(s) sound?

(In general, I am fine with folks making their best guess and putting new content where they imagine it belongs and then submitting a PR. For maintainers this can relay useful insight into how users (and other contributors) make use of the project.

dweomer commented 4 years ago

@tobru at your convenience, please take a look at the ubuntu example plan and let us know what you think.

tobru commented 4 years ago

@dweomer Thanks, I'll have a look. It will take me at least another week until I can work on our internal project (which uses SUC) again, unfortunately.

schmitch commented 4 years ago

btw. I think that the ubuntu example plan is a little bit too much effort for general purpose systems. I would rather prefer a versionCheck command that invokes something like yum check-update or apt list --upgradable. With the current version it will be a pita to always list all packages.

billimek commented 4 years ago

Regarding the ubuntu example, something I've been thinking about is this:

It is currently possible for ubnutu to automate security updates, and someone can choose to run kured in their cluster to automatically cordon & reboot when Ubuntu creates the /var/run/reboot-required signal file.

What do you think about a Plan that does more than apt-get --assume-yes update and instead does a full-blown apt --assume-yes dist-upgrade in order to automatically upgrade all of the installed components as well as the kernel. In some cases, the node will need to be rebooted to pick up changes. Should system-upgrade-controller handle the cordon and reboot of the node when this occurs, or is it better to leverage something external like kured?

ref, difference between apt-get upgrade and apt dist-upgrade:

upgrade
    upgrade is used to install the newest versions of all packages
    currently installed on the system from the sources enumerated in
    /etc/apt/sources.list. Packages currently installed with new
    versions available are retrieved and upgraded; under no
    circumstances are currently installed packages removed, or packages
    not already installed retrieved and installed. New versions of
    currently installed packages that cannot be upgraded without
    changing the install status of another package will be left at
    their current version. An update must be performed first so that
    apt-get knows that new versions of packages are available.

dist-upgrade
    dist-upgrade in addition to performing the function of upgrade,
    also intelligently handles changing dependencies with new versions
    of packages; apt-get has a "smart" conflict resolution system, and
    it will attempt to upgrade the most important packages at the
    expense of less important ones if necessary. So, dist-upgrade
    command may remove some packages. The /etc/apt/sources.list file
    contains a list of locations from which to retrieve desired package
    files. See also apt_preferences(5) for a mechanism for overriding
    the general settings for individual packages.

dweomer commented 4 years ago

Regarding the ubuntu example, something I've been thinking about is this:

It is currently possible for ubnutu to automate security updates, and someone can choose to run kured in their cluster to automatically cordon & reboot when Ubuntu creates the /var/run/reboot-required signal file.

What do you think about a Plan that does more than apt-get --assume-yes update and instead does a full-blown apt --assume-yes dist-upgrade in order to automatically upgrade all of the installed components as well as the kernel. In some cases, the node will need to be rebooted to pick up changes. Should system-upgrade-controller handle the cordon and reboot of the node when this occurs, or is it better to leverage something external like kured?

ref, difference between apt-get upgrade and apt dist-upgrade:
upgrade
    upgrade is used to install the newest versions of all packages
    currently installed on the system from the sources enumerated in
    /etc/apt/sources.list. Packages currently installed with new
    versions available are retrieved and upgraded; under no
    circumstances are currently installed packages removed, or packages
    not already installed retrieved and installed. New versions of
    currently installed packages that cannot be upgraded without
    changing the install status of another package will be left at
    their current version. An update must be performed first so that
    apt-get knows that new versions of packages are available.

dist-upgrade
    dist-upgrade in addition to performing the function of upgrade,
    also intelligently handles changing dependencies with new versions
    of packages; apt-get has a "smart" conflict resolution system, and
    it will attempt to upgrade the most important packages at the
    expense of less important ones if necessary. So, dist-upgrade
    command may remove some packages. The /etc/apt/sources.list file
    contains a list of locations from which to retrieve desired package
    files. See also apt_preferences(5) for a mechanism for overriding
    the general settings for individual packages.

This implies a reasonably straight-forward example and I would encourage folks to consider using it if it meets their use-case(s).

rancher / system-upgrade-controller

develop examples for general purpose applications #22