Move OpenShift apps from deploymentconfig to deployment #12142
Labels
No labels
announcement
anubis
authentication
aws
backlog
blocked
bodhi
ci
cloud
communishift
copr
database
day-to-day
dc-move
deprecated
dev
discourse
dns
downloads
easyfix
epel
firmitas
forgejo_migration
Gain
High
Gain
Low
Gain
Medium
gitlab
greenwave
hardware
help wanted
high-trouble
koji
koschei
lists
low-trouble
medium-trouble
mirrorlists
monitoring
Needs investigation
odcs
OpenShift
ops
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
release-monitoring
releng
request-for-resources
s390x
security
SMTP
sprint-0
sprint-1
src.fp.o
staging
unfreeze
waiverdb
websites-general
wiki
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
10 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
infra/tickets#12142
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
OpenShift is going to be dropping deploymentconfig at some point in favor of the vanilla k8s deployment
So, we need to migrate our apps away from deploymentconfig and to deployment.
List of apps using deploymentconfig:
We don't have to do them all at once, but we should try and make steady progress on them.
A few other groups should be involved: QE, CoreOS, etc.
Metadata Update from @phsmoura:
Metadata Update from @phsmoura:
Here's some documentation:
Reading those I see two possible migration issues:
deployments don't support more triggers than the ConfigChange. We usually have triggers on ImageChange: when a new image is built, a rollout is triggered. But this use case seems so natural that I would be surprised if there was no way to do it without DeploymentConfigs.
deployments don't support lifecycle hooks. We've used those in a few apps to upgrade the database if necessary during an update. What's the recommended way to do that without DeploymentConfigs?
Oh, apparently the upgrade can be done with Deployments only. Maybe they were talking about other lifecycle hooks? Nevermind.
Well, it doesn't look like it's in the k8s object actually. We'll have to test this.
I've already migrated Koschei, see commit 99a62cc.
Triggers on image change are not supported and I had to replace them with explicit deployment rollouts in manual playbooks, see e9993b5
I thought you could use annotations for image changes:
https://docs.openshift.com/container-platform/4.16/openshift_images/triggering-updates-on-imagestream-changes.html
Metadata Update from @ryanlerch:
I have made a board to track the progress on this:
https://github.com/orgs/fedora-infra/projects/37
Thank you for putting this together @ryanlerch!
Hey @ryanlerch, any updates on this work? Thanks!
@jskladan is this the ticket you were talking about picking up?
@smilner yes!
@ryanlerch I can't edit the github board, but I've moved all the FedoraQA stuff over to deployment:
Could you mark it as done, please?
Only thing I'm not able to do is removing the old DC pods in production. I've worked around this by scaling all of them down to 0 replicas, but the "delete DeploymentConfig" button is greyed-out and the
oc delete podcommand also says I can't (works fine on stg).Anyway, since I now (at least remotely) understand what I'm doing with the deploymentconfig -> deployment changes, I'm happy to help with some of the rest of the stuff too.
Initial attempt at migrating flatpak-updater based on following the documentation, but not sure how to test it.
@yselkowitz This is usually tested on staging deployment.
[backlog refinement]
This is still being worked on.
I opened some PRs creating
deployment.yml, but some of those apps already had it when I was working on it, some apps doesn't exist in asible anymore and there are others that still need to be done. Here is the list updated:The PRs I opened:
./roles/openshift-apps/asknot/files/deploymentconfig.yml: 3144
./roles/openshift-apps/bugzilla2fedmsg/templates/deploymentconfig.yml: 3145
./roles/openshift-apps/compose-tracker/templates/deploymentconfig.yml: 3146
./roles/openshift-apps/datagrepper/templates/deploymentconfig.yml: 3147
./roles/openshift-apps/discourse2fedmsg/templates/deploymentconfig.yml: 3148
./roles/openshift-apps/fasjson/templates/deploymentconfig.yml: 3149
./roles/openshift-apps/fedocal/files/deploymentconfig.yml: 3150
./roles/openshift-apps/fedora-packages-static/templates/deploymentconfig.yml: 3151
./roles/openshift-apps/flatpak-indexer/templates/deploymentconfig.yml: 3166
./roles/openshift-apps/greenwave/templates/deploymentconfig.yml: 3153
./roles/openshift-apps/kerneltest/files/deploymentconfig.yml: 3155
./roles/openshift-apps/mdapi/files/deploymentconfig.yml: 3156
./roles/openshift-apps/noggin/templates/deploymentconfig.yml: 3157
./roles/openshift-apps/the-new-hotness/templates/deploymentconfig.yml: 3158
./roles/openshift-apps/transtats/files/deploymentconfig.yml: 3159
./roles/openshift-apps/zezere/templates/deploymentconfig.yml: 3160
./roles/openshift-apps/easyfix/templates/deploymentconfig.yml: 3161
./roles/openshift-apps/mirrormanager/templates/deploymentconfig.yml:3162
./roles/openshift-apps/poddlers/templates/deploymentconfig.yml 3163
./roles/openshift-apps/webhook2fedmsg/templates/deploymentconfig.yml 3164
./roles/openshift-apps/flask-oidc-dev/templates/deploymentconfig.yml: 3167 REMOVED APP
./roles/openshift-apps/ipsilon-website/templates/deploymentconfig.yml: 3154 REMOVED APP
These already had
deployment.yml:./roles/openshift-apps/blockerbugs/templates/deploymentconfig.yml
./roles/openshift-apps/coreos-cincinnati/templates/deploymentconfig.yml
./roles/openshift-apps/coreos-koji-tagger/templates/deploymentconfig.yml
./roles/openshift-apps/fedora-ostree-pruner/templates/deploymentconfig.yml
./roles/openshift-apps/oraculum/templates/deploymentconfig.yml
./roles/openshift-apps/testdays/templates/deploymentconfig.yml
./roles/openshift-apps/maubot/files/deploymentconfig.yml
./roles/openshift-apps/kanban/templates/deploymentconfig.yml
These still need to be done:
./roles/openshift-apps/bodhi/templates/deploymentconfig.yml
./roles/openshift-apps/coreos-ostree-importer/templates/deploymentconfig.yml
./roles/openshift-apps/datanommer/templates/deploymentconfig.yml
./roles/openshift-apps/elections/files/deploymentconfig.yml
./roles/openshift-apps/release-monitoring/files/deploymentconfig.yml
./roles/openshift-apps/waiverdb/templates/deploymentconfig.yml
./roles/openshift-apps/fmn/templates/deploymentconfig.yml
./roles/openshift-apps/badges/templates/deploymentconfig.yml
Here are the ones that doesnt exist anymore:
./roles/openshift-apps/messaging-bridges/files/deploymentconfig.yml
./roles/openshift-apps/monitor-dashboard/templates/deploymentconfig.yml
./roles/openshift-apps/monitor-gating/templates/deploymentconfig.yml
./roles/openshift-apps/toddlers/templates/deploymentconfig.yml
I think the non existant ones we can delete those apps/projects...
All the PRs seem to add
deployment.ymlbut not delete thedeploymentconfig.yml.j2template they seem to replace. Is that intentional?Yes, it was. Just to have a reference in case the new deployment doesnt work
We have git history for that. Getting removed files back is a trivial operation. Leaving them around runs the risk that nobody ever remembers to get rid of them and they just sit there, being confusing, forever.
Yeah, I'm fine just removing them as part of this...
ok. I merged and deployed a number. Will try and do some more tomorrow as time permits.
I think some of these don't probably need to care about the freeze (ie, they have no affect on the release), but a few do.
I finished opening PRs to move deployment files, except for apps that already had
deployment.yml. Here they are:While working on blockerbugs today, another thing occurred to me: just wiping the deploymentconfig files on disk won't delete the actual deployment configs from openshift.
How do we want to handle this? Just do it manually as it should be a one-time thing? Write a special ansible play that spots apps with a deployment config but no deploymentconfig file, and automatically deletes the deployment config?
I have been treating it as a one off... so:
ok. I finished up deploying almost all of these.
Here is what is left:
roles/openshift-apps/kanban/templates/deploymentconfig.yml.j2
roles/openshift-apps/oraculum/templates/deploymentconfig.yml.j2
roles/openshift-apps/resultsdb-ci-listener/templates/deploymentconfigs.yml.j2
roles/openshift-apps/resultsdb/templates/backend/deploymentconfigs.yml.j2
roles/openshift-apps/resultsdb/templates/frontend/deploymentconfigs.yml.j2
roles/openshift-apps/waiverdb/templates/deploymentconfig.yml.j2
I think kanban is retired and can be deleted?
oraculum seems to have both deployment and deploymentconfig in use. ;( I can try and clean up the dc's monday.
resultsdb still needs doing. Would any Quality folks have time for that?
Waiverdb has a pr: infra/ansible#3270 which I was waiting to try and hear if the db init stage was ok to run concurrently. I guess we could just try it in staging too.
Thanks everyone (especially @phsmoura for getting this almost done).
resultsdb is supposed to be owned by another team these days - @lholecek . I don't know if we decided who owns fedora infra side, though. I can try and find some time, or we could make it a learning task for @jgroman ...
infra/ansible#3330 for resultsdb and resultsdb-ci if anyone would care to review.
Mostly from our friend claude, but it looks reasonable.
waiverdb and compose-tracker are done.
ok. I finished resultsdb* now.
Thats everything!
Thanks for all the work from @phsmoura here...