Greetings everyone.
On 2019-11-26 fedora 29 will go end of life and no longer supported.
We still have a number of things that are f29 (or older for various reasons). I'd like everyone to look this over and see if you can't move things to f31 (or at least f30) before the f29 eol.
builders: I am working on this, builders right now are mostly f29, but should be all moved before the eol date I hope.
openshift apps:
modernpaste: fedora-27. :) But I don't think it was ever moved to openshift, so we should delete this.
joystick: we should fix this up, I think jdoss was going to take it over?
the-new-hotness: can we move to f31?
qa-stg01.qa.fedoraproject.org: f24? can we retire?
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
mdadpi: f27, but it moved to openshift, can we clean up the non openshift instances and files please?
modernpaste: f27. It goes eol soon, so I guess we just wait
notifs-backend: f27. I don't know what to do here. We need a replacement, which we don't have. I'm afraid that upgrading will blow it up, but I guess we could try and rollback?
qa-prod01: f27. can we retire?
ci-cc-rdu01: f28. Can we retire soon?
copr-frontend01/02.stg: f28 and I don't think we need them anymore, can I nuke them?
db-qa03: f28. Can we upgrade please?
osbs: f28, but I think cverna was moving it to newer? any status?
f29's:
aarch64-test01/02 - can be redone as f31 anytime composer.stg - should be moved to f31 db-koji01.stg - should be moved to f31 and a prod->stg sync kojipkgs01/02 - I should do these soon to f31, adding to my list. os-proxy01 - I should do this one, on my list packages03/04 - No idea here. Can we upgrade? proxy* - we need to start working on this asap. relepel01 - do we need this one anymore? resultsdb/taskotron - can qa folks upgrade these?
old cloud instances:
glittergallery-dev: f23, should be nuked fedora-bootstrap: f25, should be nuked waiverdb-dev: f25, still needed? commops: f27, still needed? telegram-irc: ? still needed? copr*stg: f28, can copr folks upgrade? developer: f28, still needed? libravatar: f28, should ask them to move to communishift simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift?
I think thats all of them.
kevin
On Wed, Nov 13, 2019 at 02:32:37PM -0800, Kevin Fenzi wrote:
Greetings everyone.
On 2019-11-26 fedora 29 will go end of life and no longer supported.
We still have a number of things that are f29 (or older for various reasons). I'd like everyone to look this over and see if you can't move things to f31 (or at least f30) before the f29 eol.
[...]
the-new-hotness: can we move to f31?
There is some upcoming work on the-new-hotness, we should look at doing the upgrade at the same time
mdadpi: f27, but it moved to openshift, can we clean up the non openshift instances and files please?
+1 to nuke this one
notifs-backend: f27. I don't know what to do here. We need a replacement, which we don't have. I'm afraid that upgrading will blow it up, but I guess we could try and rollback?
I may be able to port it to F30 but F31 will likely blow up because of py3 :(
ci-cc-rdu01: f28. Can we retire soon?
Let's give this one until the end of the month and then nuke it :)
simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift?
Moving this one to communishift sounds like a good idea
Pierre
On Wed, 13 Nov 2019 at 23:43, Kevin Fenzi kevin@scrye.com wrote:
Greetings everyone.
On 2019-11-26 fedora 29 will go end of life and no longer supported.
We still have a number of things that are f29 (or older for various reasons). I'd like everyone to look this over and see if you can't move things to f31 (or at least f30) before the f29 eol.
builders: I am working on this, builders right now are mostly f29, but should be all moved before the eol date I hope.
openshift apps:
modernpaste: fedora-27. :) But I don't think it was ever moved to openshift, so we should delete this.
joystick: we should fix this up, I think jdoss was going to take it over?
the-new-hotness: can we move to f31?
qa-stg01.qa.fedoraproject.org: f24? can we retire?
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
mdadpi: f27, but it moved to openshift, can we clean up the non openshift instances and files please?
modernpaste: f27. It goes eol soon, so I guess we just wait
notifs-backend: f27. I don't know what to do here. We need a replacement, which we don't have. I'm afraid that upgrading will blow it up, but I guess we could try and rollback?
qa-prod01: f27. can we retire?
ci-cc-rdu01: f28. Can we retire soon?
copr-frontend01/02.stg: f28 and I don't think we need them anymore, can I nuke them?
db-qa03: f28. Can we upgrade please?
osbs: f28, but I think cverna was moving it to newer? any status?
I have a cluster in staging on rhel7, so it mostly seems to be working correctly. I still need to do a bit more testing but I think this will be moving with the work needed for the IOT objective.
f29's:
aarch64-test01/02 - can be redone as f31 anytime composer.stg - should be moved to f31 db-koji01.stg - should be moved to f31 and a prod->stg sync kojipkgs01/02 - I should do these soon to f31, adding to my list. os-proxy01 - I should do this one, on my list packages03/04 - No idea here. Can we upgrade?
In theory we should be able to update to f30. I can give it a try in staging. It also should not be too complicated to move to OpenShift or even maybe Communishift.
proxy* - we need to start working on this asap.
relepel01 - do we need this one anymore? resultsdb/taskotron - can qa folks upgrade these?
old cloud instances:
glittergallery-dev: f23, should be nuked fedora-bootstrap: f25, should be nuked waiverdb-dev: f25, still needed? commops: f27, still needed? telegram-irc: ? still needed? copr*stg: f28, can copr folks upgrade? developer: f28, still needed? libravatar: f28, should ask them to move to communishift simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift?
I think thats all of them.
kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote:
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
No, it isn't. It also tests the regular cloud images:
https://apps.fedoraproject.org/autocloud/jobs/
the tests with family 'Base' are tests of non-Atomic images. The regular Cloud base images are still release-blocking until whenever we decide to switch over to CoreOS. At some point this testing was meant to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images.
We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here.
On Thu, Nov 14, 2019 at 08:13:52AM -0800, Adam Williamson wrote:
On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote:
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
No, it isn't. It also tests the regular cloud images:
Sigh. :(
https://apps.fedoraproject.org/autocloud/jobs/
the tests with family 'Base' are tests of non-Atomic images. The regular Cloud base images are still release-blocking until whenever we decide to switch over to CoreOS. At some point this testing was meant
Well, or decide to just make the Cloud base image not blocking.
to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images.
We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here.
yeah, keeping autocloud is really not an option. It's running on a eol OS.
We have no upstream developers anymore.
It takes up 2 large hardware boxes we can't use for anything else that are idle most of the time.
So, yes, we should come up with something here. ;(
kevin
On Thu, 2019-11-14 at 10:34 -0800, Kevin Fenzi wrote:
On Thu, Nov 14, 2019 at 08:13:52AM -0800, Adam Williamson wrote:
On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote:
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
No, it isn't. It also tests the regular cloud images:
Sigh. :(
https://apps.fedoraproject.org/autocloud/jobs/
the tests with family 'Base' are tests of non-Atomic images. The regular Cloud base images are still release-blocking until whenever we decide to switch over to CoreOS. At some point this testing was meant
Well, or decide to just make the Cloud base image not blocking.
to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images.
We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here.
yeah, keeping autocloud is really not an option. It's running on a eol OS.
We have no upstream developers anymore.
It takes up 2 large hardware boxes we can't use for anything else that are idle most of the time.
So, yes, we should come up with something here. ;(
welp, if no-one else has a plan, I can take a look at migrating the tests it runs into openQA maybe next week. (That might also mean we'd pay more attention to the results - the autocloud tests haven't passed on Rawhide for like two months, but I didn't know that until I looked this morning...)
I still don't know what automated testing CoreOS has in place either...that might be useful to know...
On Thu, 2019-11-14 at 12:44 -0800, Adam Williamson wrote:
On Thu, 2019-11-14 at 10:34 -0800, Kevin Fenzi wrote:
On Thu, Nov 14, 2019 at 08:13:52AM -0800, Adam Williamson wrote:
On Wed, 2019-11-13 at 14:32 -0800, Kevin Fenzi wrote:
autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host).
No, it isn't. It also tests the regular cloud images:
Sigh. :(
https://apps.fedoraproject.org/autocloud/jobs/
the tests with family 'Base' are tests of non-Atomic images. The regular Cloud base images are still release-blocking until whenever we decide to switch over to CoreOS. At some point this testing was meant
Well, or decide to just make the Cloud base image not blocking.
to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images.
We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here.
yeah, keeping autocloud is really not an option. It's running on a eol OS.
We have no upstream developers anymore.
It takes up 2 large hardware boxes we can't use for anything else that are idle most of the time.
So, yes, we should come up with something here. ;(
welp, if no-one else has a plan, I can take a look at migrating the tests it runs into openQA maybe next week. (That might also mean we'd pay more attention to the results - the autocloud tests haven't passed on Rawhide for like two months, but I didn't know that until I looked this morning...)
Well that turned out to be not too hard!
https://openqa.stg.fedoraproject.org/tests/674207
So I briefly looked at whether I wanted to take over autocloud but there's a lot of it, and it looks to me like ultimately all it really *does* is boot the image and then do this:
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/autoclo...
where ## means "this shouldn't fail the overall test if it fails", @@ means "this is expected to fail" and POLL means "wait till the system reboots" (per https://github.com/kushaldas/tunir/blob/master/docs/usage.rst). So I just taught openQA to be able to boot Cloud_Base qcow2 images and do basically the same:
https://openqa.stg.fedoraproject.org/tests/674207/modules/autocloud/steps/1/...
I'll get this cleaned up in various ways and deployed to production over today and tomorrow. It doesn't replicate *all* of autocloud - most notably for now it'll only test the Cloud_Base qcow2 images, not the vagrant images which autocloud also tested - but I think that's good enough for now. I'm not sure if it makes more sense to try and make openQA mimic the fedmsgs that autocloud currently publishes and the resultsdb results it reports, or just find anything that uses either of those and make it work with the openQA messages and results instead, I'll look into that.
On Fri, Nov 15, 2019 at 12:04 AM Kevin Fenzi kevin@scrye.com wrote:
<snipped>
to move to Taskotron, then there was some talking of moving it to Fedora CI, but I don't know if anyone has actually done any work on either of those things. AFAIK we have no other system currently for doing automated testing on the Cloud base images.
We could probably run the tests in openQA without too much trouble if desired (though I can't guarantee it as I haven't looked into it in any detail), but we should probably do *something* here.
yeah, keeping autocloud is really not an option. It's running on a eol OS.
We have no upstream developers anymore.
I was particularly asked not to develop it anymore to give time to Taskotron to catch up in features, and also was asked later to kill the project.
I would happily maintain the project, but, when the management asked not to develop, I could not do much.
Kushal
infrastructure@lists.fedoraproject.org
-
Adam Williamson -
Clement Verna -
Kevin Fenzi -
Kushal Das -
Pierre-Yves Chibon