)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"2526aafe1fc18a7bd50102e0944e5f8d98493e4f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4d0de560_d7f5cc09","updated":"2023-11-20 03:14:27.000000000","message":"I\u0027m not really -1 on this, but just though I\u0027d use it to point out why from my POV 😊\n\nThe concern has always been opendev building bionic, which at this stage it still does ...\n\nThis tox has been keeping some things python3.6 \"clean\" ... from a quick look elements/package-installs/tests/test_package_squash.py is running package-installs-squash which I\u0027m pretty sure runs in the chroot environment; meaning it has to still run on 3.6 to build bionic.  There may be others if we look closer...  \n\nPerhaps it is time to just \"freeze\" the opendev bionic image and stop trying to do daily builds, tag one last dib release and drop support from diskimage-builder all together?  I don\u0027t think infra/system-config gate is even bionic free for various reasons ...\n\nI understand that\u0027s the old problem of a reviewer dumping \"please do may hours of unrelated bitrot fixup work to get a gate going again\" :)  I\u0027m not proposing we do any sort of radical surgery to maintain this -- it\u0027s a small chance we even merge anything that does break things this would have found.  But it would be great to have this as part of a consolidated plan to remove bionic.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"26941696d7afb4b2ef289b2b0fa15fa772cfeaab","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"06edecef_719e70a0","updated":"2024-05-22 13:58:26.000000000","message":"recheck curious to see what the status of dib gate is, and this is a convenient patch to do so.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"f4125e0c40c4292739cfe0f404030719eaff4804","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"69b47664_4a44b15f","updated":"2023-12-05 20:00:58.000000000","message":"we discussed this in https://meetings.opendev.org/meetings/infra/2023/infra.2023-12-05-19.00.log.html\n\nWe are generally OK with dib dropping py36 when it comes to the point we need to\n\nHowever, it looks like the original issue (https://022b288dc214810f18c3-8156621505f6355ffb6896f9b15e0b7a.ssl.cf5.rackcdn.com/899885/1/check/tox-py36/fa89ce1/job-output.txt) seems to be related to https://github.com/mtreinish/stestr/issues/347 (missing run command) which is now fixed.  Mind you, stestr has a cap \u003e\u003d3.7 (https://github.com/mtreinish/stestr/commit/cc66736df90968126585540b220fea663b124bbf)\n\nSo for now, I don\u0027t think we need this; but we have a conversation on record for when we do","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"5ef6963fe690ef5225e9ee046d3d13fbd6f8ca08","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e79df1e7_dd18a7b0","in_reply_to":"0c77dcb0_fdc018c9","updated":"2023-11-30 21:52:49.000000000","message":"@clarkb points out that this will be painful if cloud providers change.\n\nA second option, after thinking on it even more, is that we still run a bionic build in the dib-functests.  I feel like this is a subset of the full unit-testing (doesn\u0027t use any elements) but probably enough to keep the basic build from totally exploding.\n\nI think we should still tag a pre-py36-drop release (and probably add a release note), but I\u0027m happy with that too.\n\nI put it on the meeting agenda for next week and we can decide","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"e921b0ad1f1f6476709868f6070b4be0ef4d395d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9905476c_35a1cc04","in_reply_to":"2d29df97_fd653ac3","updated":"2023-11-21 01:09:10.000000000","message":"I feel realistically we can merge this, unless somebody wants to work on that; but I did just want to point out the caveat and make sure we at least are knowingly dropping the testing 😊  Bionic has to go some time, I guess ...","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"9f1bb14dbab8d1fd4a996b27702426fec26316ae","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2d29df97_fd653ac3","in_reply_to":"4d0de560_d7f5cc09","updated":"2023-11-20 17:34:54.000000000","message":"I wonder if there is a good way to avoid python version issues with the python bits that run within the image. Like maybe we can do something like linting specific files under old interpreter versions an rely on that to catch if we introduce a syntax incompatibility?\n\nMostly I\u0027m thinking we don\u0027t need the full python3.6 test suite to ensure that specific tools can run within a python3.6 environment. And maybe that is a reasonable path forward to balance the needs here.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b64e63b764bc94ba968abf57aa6db3e145434552","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0c77dcb0_fdc018c9","in_reply_to":"648c7dd4_97ee287e","updated":"2023-11-28 17:41:42.000000000","message":"I think that is a reasonable approach, as long as it unblocks DIB at some point in the next month or so.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"633c3781a29c5cc3d580cb18d48836af0c90e38a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9e2753cd_5f9a15f5","in_reply_to":"6eec62bd_aad57b3d","updated":"2023-11-22 22:56:23.000000000","message":"I think we should drop it -- but thinking on it, I think we should we should probably try and do a smooth exit.  This would be, IMO\n\n* put bionic images on pause in the nodepool builder config\n* notify people opendev images are no longer updating and they have been placed on a \"do not resuscitate\" list (this is the hard part -- pulling all the job config that still uses this.  if we make this a pre-requisite for dropping, we\u0027ll never do it 😊)\n* make a release\n* drop \u003c python 3.8 from tox/setup.cfg etc., and various bionic tests; add release notes\n* maybe add a \"if ${DIB_RELEASE} \u003d\u003d \u0027bionic\u0027; then exit 1\" at an appropriate place? (I don\u0027t think we did this for trusty ... so maybe not necessary.  People can use it till it breaks, but we won\u0027t fix anything...)\n\nI think that is tractable without having to fix too much external cruft?\n\nIf anyone desperately needs a bionic image (opendev included for some reason) we can do a manual build with the last known good tag for the foreseeable future.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a07eadd90318a21fd20b461a1530d666833ed771","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6eec62bd_aad57b3d","in_reply_to":"9905476c_35a1cc04","updated":"2023-11-22 19:46:13.000000000","message":"I\u0027m really not in a position to have an opinion or propose a plan on Bionic, but forward movement is generally good. And paying down the debt we build up is often painful. Is there really a need to do daily rebuilds? I don\u0027t know, but it does seem sort of excessive and a good starting point to start to unwind/remove support.\n\nI guess it also sort of goes back to the age old question, how long are we going to support something after we should have stopped supporting it anyway.","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"},{"author":{"_account_id":7118,"name":"Ian Wienand","email":"iwienand@redhat.com","username":"iwienand"},"change_message_id":"b2e307119d9966559caa6ece4f530c165f021bc2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"648c7dd4_97ee287e","in_reply_to":"9e2753cd_5f9a15f5","updated":"2023-11-22 23:12:28.000000000","message":"https://review.opendev.org/c/openstack/project-config/+/901692 I think should do the pause bits","commit_id":"81900e15b3a628c563755f6b0d522a18e47110f6"}]}