jberry-suse
commented
7 years ago Performed an inventory of the services on packagelists machine.
services
- announcer
- build-fail-reminder
- create-test-dvds
- factory-auto-submit
- facotry-dvl-prj-list
- factoryauto [gnome-review-bot] -> check_source
- leaperbot
- maintbot
- manager_42
- openqa-comments
- osc-check_dups [likely merged into repo_checker]
- repo-checker
- source-checker -> check_source_in_factory
- staging-bot-daily
- staging-bot-regular
- staging-bot-reminder
- suppkg_rebuild
- trigger-rebuilds
- tmm-arm, tmm-leap, tmm-s390, tmm-tumbleweed -> totest-manager
- update-crawler (for leap)
A slight lack of consistency in naming and the template argument being partial or full project name or built into service file. I would suggest the full project name be used for all templated services to allow for easy usage by IBS for SUSE: projects as well.
As for naming and additional configuration, it would seem to make sense to prefix services with an abbreviation of openSUSE-release-tools so osrt- as the prefix, otherwise the full name. A common config location like /etc/openSUSE-release-tools with sub-directories for services requiring them and the project name can be included for templated service files requiring different config per project. This will merge all the random config paths into one location with a standard path setup.
I may also rename some of the services that are a bit misleading or obfuscated to make their role more clear. As an example, I plan to do the official repo_checker deployment via the package from OBS and will submit the PRs for the service files before then. Something along the lines of openSUSE-release-tools-repo-checker@openSUSE:Factory or prefixed if preferred as osrt-repo-checker@openSUSE:Factory.
users
$ grep -hoPR 'User=\K.*' systemd/packagelists/ | sort | uniq- factorymaintainer -> factory-maintainer
- factory-source
- gnome-review-bot
- leaper
- maintbot
- _opensuse.org-factoryauto -> factory-auto
- _opensuse.org-factory-bot -> factory-comment-bot
- _opensuse.org-repo-checker
- _opensuse.org-staging-bot
- _opensuse.org-totest-manager
- repochecker -> factory-repo-checker
The subtle name differences between system and OBS are rather annoying and obfuscating in addition to the lack of consistency on multiple levels.
permissions
factory-staging
- coolo-factory
- dimstar_suse
- factory-auto
- favogt_factory
- jberry_factory
- lnussel_factory
- maxlin_factory
- staging-bot
Not sure why factory-auto is in that list other than perhaps to have access to dashboard, but should likely be demoted. staging-bot being the only tool that should have staging access.
openSUSE:Factory:Staging
<group groupid="factory-staging" role="maintainer"/>openSUSE:Factory:Staging/dashboard
<person userid="ancorgs" role="maintainer"/>
<person userid="aplanas" role="maintainer"/>
<person userid="factory-repo-checker" role="maintainer"/>
<person userid="leaper" role="maintainer"/>
<person userid="totest-manager" role="maintainer"/>The first two users seem like they should be unnecessary at this point. The last three are part of tooling with factory-staging being inherited from the project.
It would seem to make sense to create a new group for tools that need to write to the dashboard, but do not need staging access. The group can then easily be applied to new Leap projects and have an understood meaning. This same workflow can then be used for IBS as well.
Perhaps name the group release-tools since none of the other groups are prefixed with openSUSE or similar. The new repo-checker needs to have dashboard access, but currently does not, but we should add via the new group rather than directly.
coolo
Given there are two variables for most services a single template variable for a service file is likely not enough. As such pointing to an environment variable file/config file might make more sense. It would be nice if the user could be a parameter based on that file, but guessing that it would not be possible to load environment file in that manor. Alternatively, a wrapper script could be provided to start the desired service using the config file as the appropriate user.
As a different approach the users themselves could also be standardized and created by the package so then they simply need to have their credentials setup for the appropriate OBS instance and user. I would imagine the bots/scripts that run as different users on OBS should also be run separately on IBS so this may simplify things.