Greetings everyone.
I thought I would send a short note on something I put in place before the freeze. Basically it seems, even though we have SOPs and docs, we spend a lot of time around release milestones changing files in ansible, realizing we forgot something and changing another one, etc.
I'd like to minimize that.
To that end I have created some variables in ansible. You can see them in the ansible/vars/all/ directory. Every file in this directory tree is included via the virt_instance_create and persistent_cloud tasks (so most of our machines, exclusing bare metal ones).
00-FedoraCycleNumber.yaml is the number only of the current stable Fedora. So, right now it's 28, but soon when f29 is released it will change to 29. This is used for many of the later variables so it's 00- to be loaded first.
FedoraBranchedBodhi.yaml - indicates is we are using Bodhi in a new branch.
FedoraBranchedNumber.yaml - Number of the curret branched version.
FedoraBranched.yaml - If there is a branched or not.
FedoraPreviousCycleNumber.yaml - This is the 'older' stable release. Right now 27.
FedoraPreviousPreviousCycleNumber.yaml - This is the 'older' 'older' stable release. Right now we don't have one, but after f29 releases, f27 will be this until it EOLs in a month.
FedoraPreviousPrevious.yaml - If there is a 'older' 'older' release.
FedoraRawhideNumber.yaml - number of current rawhide (30)
Frozen.yaml - If infrastructure is frozen.
We can add things as we go, but some rules:
* I think for these CamelCase is easiest to read, so keep to that. * If you can base the variable on others so you never have to edit it, great! * It should be of general use.
So, given these, I updated the bodhi config to use them. So, when f29 is released:
* 00-FedoraCycleNumber.yaml - edit and change to 29 * FedoraPreviousPrevious.yaml - edit and change to true * FedoraBranched.yaml - edit and set to false * Frozen.yaml - edit and set to false a day after release.
Then we just need to run playbooks and everything adjusts. There are a number more places we could leverage this, so I encourage people to look for those and submit patches to enable them. In particular the new-updates-sync script could use these so we don't have to edit it all the time.
Hope that makes sense and feedback welcome.
kevin
On Fri, Oct 12, 2018 at 4:01 PM Kevin Fenzi kevin@scrye.com wrote:
Greetings everyone.
I thought I would send a short note on something I put in place before the freeze. Basically it seems, even though we have SOPs and docs, we spend a lot of time around release milestones changing files in ansible, realizing we forgot something and changing another one, etc.
I'd like to minimize that.
To that end I have created some variables in ansible. You can see them in the ansible/vars/all/ directory. Every file in this directory tree is included via the virt_instance_create and persistent_cloud tasks (so most of our machines, exclusing bare metal ones).
00-FedoraCycleNumber.yaml is the number only of the current stable Fedora. So, right now it's 28, but soon when f29 is released it will change to 29. This is used for many of the later variables so it's 00- to be loaded first.
FedoraBranchedBodhi.yaml - indicates is we are using Bodhi in a new branch.
FedoraBranchedNumber.yaml - Number of the curret branched version.
FedoraBranched.yaml - If there is a branched or not.
FedoraPreviousCycleNumber.yaml - This is the 'older' stable release. Right now 27.
FedoraPreviousPreviousCycleNumber.yaml - This is the 'older' 'older' stable release. Right now we don't have one, but after f29 releases, f27 will be this until it EOLs in a month.
FedoraPreviousPrevious.yaml - If there is a 'older' 'older' release.
FedoraRawhideNumber.yaml - number of current rawhide (30)
Frozen.yaml - If infrastructure is frozen.
Then I think we should use another variable (probably RelengFreeze) to indicate releng freeze, as they dont actually end on the same day. Also, we are using it for automated bodhi pushes, and we start pushing stable updates once we are a GO which we generally know on Thu itself. WDYT?
We can add things as we go, but some rules:
- I think for these CamelCase is easiest to read, so keep to that.
- If you can base the variable on others so you never have to edit it,
great!
- It should be of general use.
So, given these, I updated the bodhi config to use them. So, when f29 is released:
- 00-FedoraCycleNumber.yaml - edit and change to 29
- FedoraPreviousPrevious.yaml - edit and change to true
- FedoraBranched.yaml - edit and set to false
- Frozen.yaml - edit and set to false a day after release.
Then we just need to run playbooks and everything adjusts. There are a number more places we could leverage this, so I encourage people to look for those and submit patches to enable them. In particular the new-updates-sync script could use these so we don't have to edit it all the time.
Hope that makes sense and feedback welcome.
kevin
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On 10/15/18 12:21 PM, Mohan Boddu wrote:
Then I think we should use another variable (probably RelengFreeze) to indicate releng freeze, as they dont actually end on the same day. Also, we are using it for automated bodhi pushes, and we start pushing stable updates once we are a GO which we generally know on Thu itself. WDYT?
Yeah, more states. ;(
I wonder if we could look at aligning the infrastructure and releng freezes. (Either by setting a new time like 15:00UTC to start both of them, or by moving both to the same time). I know many people find "00:00 UTC on tuesday" confusing. If we moved both to say 15:00UTC tuesday it might work better?
As for pushing after GO, but before unfreeze, we could just do those manually until freeze is up? At least the first one we need to watch very carefully because it's the first set of packages going to the 'updates' repo instead of just being tagged in and getting composed on the next night.
If those don't work, we can of course add a RelengFreeze and a MileStoneGo, but that means more things to modify.
kevin
On Thu, Oct 18, 2018 at 3:05 PM Kevin Fenzi kevin@scrye.com wrote:
On 10/15/18 12:21 PM, Mohan Boddu wrote:
Then I think we should use another variable (probably RelengFreeze) to indicate releng freeze, as they dont actually end on the same day. Also, we are using it for automated bodhi pushes, and we start pushing stable updates once we are a GO which we generally know on Thu itself. WDYT?
Yeah, more states. ;(
I wonder if we could look at aligning the infrastructure and releng freezes. (Either by setting a new time like 15:00UTC to start both of them, or by moving both to the same time). I know many people find "00:00 UTC on tuesday" confusing. If we moved both to say 15:00UTC tuesday it might work better?
+1 but what do you think of late UTC time on a Monday like 20:00 UTC?
As for pushing after GO, but before unfreeze, we could just do those manually until freeze is up? At least the first one we need to watch very carefully because it's the first set of packages going to the 'updates' repo instead of just being tagged in and getting composed on the next night.
+1
If those don't work, we can of course add a RelengFreeze and a MileStoneGo, but that means more things to modify.
kevin
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On 10/19/18 7:00 AM, Mohan Boddu wrote:
On Thu, Oct 18, 2018 at 3:05 PM Kevin Fenzi kevin@scrye.com wrote:
On 10/15/18 12:21 PM, Mohan Boddu wrote:
Then I think we should use another variable (probably RelengFreeze) to indicate releng freeze, as they dont actually end on the same day. Also, we are using it for automated bodhi pushes, and we start pushing stable updates once we are a GO which we generally know on Thu itself. WDYT?
Yeah, more states. ;(
I wonder if we could look at aligning the infrastructure and releng freezes. (Either by setting a new time like 15:00UTC to start both of them, or by moving both to the same time). I know many people find "00:00 UTC on tuesday" confusing. If we moved both to say 15:00UTC tuesday it might work better?
+1 but what do you think of late UTC time on a Monday like 20:00 UTC?
Well, it would change the schedule some, since we now always say we freeze on tuesdays. I'd perfer something like 20:00UTC on tuesday as that would give (at least usa folks) another morning to wrap up any bugfixes. I guess we might ask fesco...
kevin
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Mohan Boddu