Re: Deleting old AMIs in AWS

[Dusty Mabe]

On 4/23/24 12:04, Miroslav Suchý wrote:
> Dne 23. 04. 24 v 3:31 odp. Dusty Mabe napsal(a):
>> If you don't mind give us until next week to finish up loose ends on this. 
>> We are already
>> adding the FedoraGroup=coreos tag to our snapshots/AMIs as we create them 
>> now, but we are
>> working on a script to go apply that tag to our existing images.
>>
>> https://github.com/coreos/fedora-coreos-tracker/issues/1605#issuecomment-2052373124
> 
> Sure no problem.
> 
> And thank you for working on this.

OK. This should now be done!

https://github.com/coreos/fedora-coreos-tracker/issues/1605#issuecomment-2080346216
--
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deleting old AMIs in AWS

[Dusty Mabe]

On 4/4/24 05:11, Miroslav Suchý wrote:
> Dne 04. 04. 24 v 4:06 dop. Dusty Mabe napsal(a):
>> If you don't mind let me try to get the FedoraGroup tag added to our CoreOS 
>> AMIs first.
>>
>> I'll try to set up something to get that done this week. 
> 
> Sure. I pause any deletion till end of the current freeze (scheduled to 
> 2024-04-16).

Hey Miroslav,

If you don't mind give us until next week to finish up loose ends on this. We 
are already
adding the FedoraGroup=coreos tag to our snapshots/AMIs as we create them now, 
but we are
working on a script to go apply that tag to our existing images.

https://github.com/coreos/fedora-coreos-tracker/issues/1605#issuecomment-2052373124

Dusty
--
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Different owner of some Fedora-Cloud-Base images in AWS?

[Dusty Mabe]

On 2/12/24 05:14, Miroslav Suchý wrote:
> I was wondering why I cannot tag some images in AWS and I found that some GA 
> images in AWS have different owner.
> 
> I.e. all our images has
> 
> Owner account ID 125523088429
> 
> But e.g. ami-0e4e634d022c1a3f8 in ap-southeast-4 region has owner id 
> 569228561889. There are more such cases, but it seems quite random.
> 
> To see this AMI in WebUI you have to switch from "AMIs owned by me" to 
> "Public images".
> 
> Is this expected? Is this some malicious thing?

We have a community cloud AWS account (predates the official AWS account used 
today) with ID 013116697141, so if you see any
from that account they aren't malicious, but we should probably clean them up.

We use the community cloud AWS account for dev (occasionally) and for testing 
created Cloud and CoreOS images. Nothing "official" should be produced by that 
account.

569228561889 could be just a individual/company/org that makes copies of our 
images they are using as a hedge in case we ever delete the images. So it's not 
necessarily malicious, but not ideal. Ideally we'd get our official images into 
the AWS marketplace and it would be easier to tell which were official and 
which aren't. 
--
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP - deletion of Fedora Atomic Hosts AMIs

[Dusty Mabe]

On 2/7/24 13:39, Miroslav Suchý wrote:
> Dne 09. 12. 23 v 9:21 Miroslav Suchý napsal(a):
>> As mentioned in previous thread - I plan to delete from AWS all Fedora 
>> Atomic Hosts and related snapshots.
>>
>> Atomic Host EOLed at 2019 and we have the images stored elsewhere too.
>>
>> To protect Christmas calm period. I will delete is no sooner than 2024-01-09.
> 
> It took a bit longer, but I finally get to this.
> 
> All AMIs with name 'Fedora-AtomicHost-*' are deleted. It was 12 074 AMIs.

May they rest in peace!

Dusty
--
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AWS Snapshots without FedoraGroup tag

[Dusty Mabe]

On 11/3/23 03:00, Miroslav Suchý wrote:
> Dne 03. 11. 23 v 2:06 Dusty Mabe napsal(a):
>> We'll clean up the ones we do not need soon. I'm sorry it is taking longer 
>> than we thought it would to
>> get garbage collection implemented.
> 
> Thank you.
> 
> 
>> * Fedora-Cloud-Base-29-20190729.0.x86_64-hvm-us-east-1-standard-0 - is this 
>> snapshots used to generate AMIs for
>>> getfedora.org? Do we still need it?
>>>
>>> If you have snapshots that are important, please check that it have tag 
>>> FedoraGroup=*
>> Hmm. Is that required? If so, is it new? 
> 
> It is in our SOP for ages
> 
> https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/aws-access/#_ec2
> 
> but so far no ones checked it and enforced.

Does that mean we should set ours to FedoraGroup=coreos ?

> 
>> When we (Fedora CoreOS Group) create AMIs we don't add tags
>> like this to our AMIs.
> 
> I am now focusing on Snapshots, but please add it to any resource.
> 
> When we started we have few resources there and it was easy to clean up 
> leftovers and identify owners. Now we have there thousands resources in dozen 
> regions. And it is hard to garbage collect resources and identify who is 
> responsible for consuming expensive resources. While this account is 
> sponsored by AWS it does not mean that we can misuse it and leave garbage 
> behind and let Amazon pay for that.
> 
> Miroslav
> 
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
> 
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AWS Snapshots without FedoraGroup tag

[Dusty Mabe]

On 11/2/23 05:32, Miroslav Suchý wrote:
> We have (almost) all instances and volumes properly tagged. Now let check 
> Snapshots.
> 
> OMG - there are A LOT of them. The list has 97k lines! Because of the size I 
> will not attach it and instead provide link 
> to download it: https://k00.fr/8p59mvcw
> 
> If you help me to identify something, I can either delete or tag it for you.
> 
> Few things I spotted:
>   * snapshots of volumes that no longer exists. Can it be deleted?
>   * lots of snapshots like fedora-coreos-36.20221030.2.3-aarch64 - do we 
> still need 36 and older?

We'll clean up the ones we do not need soon. I'm sorry it is taking longer than 
we thought it would to
get garbage collection implemented.

>   * Fedora-Cloud-Base-29-20190729.0.x86_64-hvm-us-east-1-standard-0 - is this 
> snapshots used to generate AMIs for 
> getfedora.org? Do we still need it?
> 
> If you have snapshots that are important, please check that it have tag 
> FedoraGroup=*

Hmm. Is that required? If so, is it new? When we (Fedora CoreOS Group) create 
AMIs we don't add tags
like this to our AMIs.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Meeting Agenda Item: Introduction Blake Ridgway

[Dusty Mabe]

On 10/11/23 09:13, Blake Ridgway wrote:
> Good day Fedora Infrastructure team,
> 
> I'm Blake Ridgway. My IRC alias is /Zormak/ and my Matrix alias is 
> /@blakeridgway:fedora.im. /I am reaching out to introduce myself to the 
> Fedora Infrastructure team and express my enthusiasm for collaboration.
> 
> I serve as a System Administrator in the Agribusiness sector, where my role 
> is diverse and vital for the organization's operational efficiency. My 
> responsibilities encompass the maintenance of our Windows Server, Office 365 
> environment, Asterisk PBX system running on CentOS, and Ubuntu Server 
> infrastructure. Beyond my professional duties, I'm actively engaged in 
> crafting a custom application suite for a non-profit organization based in 
> Oklahoma.
> 
> I run Fedora on all of my hardware, which includes two servers, my desktop, 
> and a variety of laptops. This comprehensive setup enables me to thoroughly 
> test and verify the Operating System's compatibility across diverse hardware 
> configurations.
> 
> While I've been quietly observing and familiarizing myself with how the team 
> operates and communicates, I'm not approaching this with a blank slate. I 
> plan to explore the open issues and Easyfix tasks to identify areas where I 
> can make a valuable contribution before tackling more longstanding challenges.
> 
> I'm genuinely eager to contribute to the Fedora community. I am excited to 
> both help offer my assistance and learn from the experienced members of the 
> Fedora Infrastructure team.
> 
> I look forward to hearing from you all.

Nice. Thanks for the introduction and welcome!

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Migration from registry.fp.o to quay.io

[Dusty Mabe]

On 9/5/23 06:56, Jakub Čajka wrote:
> I have one concern about quay.io, more of a double check that quay supports 
> manifest lists for/in image formats that fedora is using. IIRC there have 
> been some limitations on how manifest lists can be used, created in quay.io.
> 

We are using manifest lists for our FCOS images/containers and it's working 
well:

quay.io/coreos/coreos-assembler
quay.io/fedora/fedora-coreos

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Lot of snapshots in AWS Sydney region

[Dusty Mabe]

On 7/12/23 19:03, Miroslav Suchý wrote:
> Dne 13. 07. 23 v 0:26 Dusty Mabe napsal(a):
>> If you say it's an issue then hopefully we can give this some priority and 
>> get to it soon.
>>
>> Removing the "old ones" isn't that easy to do. Our production AMIs and 
>> development AMIs are all mixed together so it would be hard to come up with 
>> a criteria without implementing the garbage collection I linked to above.
> 
> But AWS will not allow you to delete snapshot that is associated with AMI 
> (you said). So we can delete everything older 
> than one year. And these that will errors are these that we still want to 
> keep. So we will just ignore the errors.
> 

Indeed. Thanks for clarifying. Yes that should be OK I think. though it would 
be good to test your process against a few
snapshots that back AMIs we know we don't care about first to make sure it 
fails. I tried in the web interface and it
wouldn't let me so I'm pretty sure that's the case.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Lot of snapshots in AWS Sydney region

[Dusty Mabe]

On 7/12/23 16:17, Miroslav Suchý wrote:
> Dne 11. 07. 23 v 15:53 Dusty Mabe napsal(a):
>> Apologies for not responding sooner. Actually for some reason this is the 
>> first email I've seen
>> in the thread so maybe I need to check my spam filters. Either way, 
>> apologies.
>>
>> The reason you are seeing snapshots but no volumes is because these 
>> snapshots are used as backing
>> storage for AMIs. If the snapshot is still associated with an AMI AWS won't 
>> let you delete it.
>>
>> On the Fedora CoreOS side we need to implement garbage collection so that we 
>> delete all AMIs and
>> snapshots from our development streams. For our production streams we'll 
>> probably take a more
>> conservative approach to garbage collection, but we'll need to start garbage 
>> collecting those too.
>>
>> For Fedora Cloud, that working group will also need to look at their 
>> processes and implement garbage
>> collection too. It could either be a separate process or it could be working 
>> with you to set a
>> policy directly in AWS to clean up after some time.
>>
>> For Fedora CoreOS we'd like to implement the GC outside of AWS since we'd 
>> like to have the same GC
>> policy for all clouds we create resources in.
> 
> Can you create issue for each of the case. So it does not get lost.

For Fedora CoreOS we have this issue to track: 
https://github.com/coreos/fedora-coreos-tracker/issues/99

For the cloud working group we'd need to reach out to them to see how they want 
to proceed. 

> 
>> Does this make sense?
> 
> Sure. Do you expect this soonish? Or should I manually remove the old ones 
> now?

If you say it's an issue then hopefully we can give this some priority and get 
to it soon.

Removing the "old ones" isn't that easy to do. Our production AMIs and 
development AMIs are all mixed together so it would be hard to come up with a 
criteria without implementing the garbage collection I linked to above.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Lot of snapshots in AWS Sydney region

[Dusty Mabe]

On 7/11/23 04:21, Miroslav Suchý wrote:
> Dne 05. 07. 23 v 21:17 Kevin Fenzi napsal(a):
>> On Mon, Jul 03, 2023 at 04:02:02PM +0200, Fabian Arrotin wrote:
>>> On 03/07/2023 06:39, Miroslav Suchý wrote:
 I was going through our spending in AWS and I found that we spent a lot
 in Sydney region (?). In details most of the bill there is because of
 stored snapshots. There is 7508 of them dated to back to 2013. For
 volumes that does not exists any more.

>> Yeah, lets get the Fedora coreos folks to look, it seems like those are
>> their images. Perhaps they are making them, but not cleaning up old ones
>> in that region?
>>
> 
> It has been week with no response (I know holiday season...). I will give it 
> one more week. If no one raise a voice, I 
> will create Recycle-bin rule that will automatically delete **ALL** volume 
> snapshots older than one year. In ALL AWS 
> regions where we have some snapshots. I will work on that next Monday.
> 
> If you need to preserve some snapshot longer than one year, please let me 
> know.


Apologies for not responding sooner. Actually for some reason this is the first 
email I've seen
in the thread so maybe I need to check my spam filters. Either way, apologies.

The reason you are seeing snapshots but no volumes is because these snapshots 
are used as backing
storage for AMIs. If the snapshot is still associated with an AMI AWS won't let 
you delete it.

On the Fedora CoreOS side we need to implement garbage collection so that we 
delete all AMIs and
snapshots from our development streams. For our production streams we'll 
probably take a more
conservative approach to garbage collection, but we'll need to start garbage 
collecting those too.

For Fedora Cloud, that working group will also need to look at their processes 
and implement garbage
collection too. It could either be a separate process or it could be working 
with you to set a
policy directly in AWS to clean up after some time.

For Fedora CoreOS we'd like to implement the GC outside of AWS since we'd like 
to have the same GC
policy for all clouds we create resources in.

Does this make sense?
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Freeze break request: moving /mnt/koji/compose/

[Dusty Mabe]

On 2/22/23 12:51, Kevin Fenzi wrote:
> Greetings.
> 
> As some of you may know, our fedora_koji volume is hitting up against
> some limits (namely the netapp 100TB per volume limit). If it hits 100TB
> used, the netapp folks tell me it will go offline and we will need to do
> special things to free up any space and get it working again. 
> Obviously, we wish to avoid that. 
> 
> So, I think we can move /mnt/fedora_koji/koji/compose with minimal
> disruption and give us a bunch of room and actually make things faster.
> 
> Here's my tenative plan:
> 
> * create ~15-20TB volume on one of our ssd aggregates.
> * rsync all of /mnt/fedora_koji/koji/compose/ to it.
> * Schedule a changeover time/date.
> * Make sure no composes or updates pushes are running.
> (This should be possible after branched/rawhide, but before updates
> and before we are making rc's)
> * Do another sync of content so the new copy is up to date.
> (I am not sure how long a rsync will take, but we can figure it out)
> * move the old directory to compose.old
> * mount the new space on koji01/02, kojipkgs01/02, all compose channel
> builders, compose-x86-01. Nothing else should need it.
> * Wait a short while
> * delete compose.old
> 
> This should free up about 13TB or so on the main volume, reduce snapshot
> churn on it, make composes faster because they will be on ssd instead of
> sas drives, and all around be nicer.
> 
> I think this can be done during some day without really causing much
> outage. Because the koji space is so tight I would like to do it soon,
> and I think it best to do it before we are too close to release. 
> So, later this week or early next week?
> 
> Thoughts? +1s? alternative ideas?

I just want to make sure our ostree use cases are considered here. I think we
are already on our own separate volume, so maybe this has no impact, but I do
know at least the mount paths include `compose` in them so I'll list out what
we do and the desire for it to continue to work:

1. pungi composes - composing into compose/ostree/repo
2. coreos-ostree-importer - importing into /mnt/koji/compose/ostree/repo
- 
https://github.com/coreos/fedora-coreos-releng-automation/blob/main/coreos-ostree-importer/coreos_ostree_importer.py#L50
3. fedora-ostree-pruner - pruning /mnt/koji/compose/ostree/repo
- 
https://github.com/coreos/fedora-coreos-releng-automation/blob/main/fedora-ostree-pruner/fedora-ostree-pruner#L27
4. the `fedora-compose` ostree repo (accessible via clients for testing 
purposes)
- 
https://src.fedoraproject.org/rpms/fedora-repos/blob/rawhide/f/fedora-compose.conf

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedimg

[Dusty Mabe]

We have/(had?) an effort to replace fedimg in the cloud WG. 
https://pagure.io/cloud-sig/issue/301

Some people have worked on it off and on but it's stalled.

Dusty


On 6/7/21 1:38 PM, Kevin Fenzi wrote:
> Hey everyone. 
> 
> We have a application called fedimg that takes our images and uploads
> them to AWS. We have talked about replacing it, but we haven't done so. 
> 
> However, we now have a request to also upload the ELN images:
> https://pagure.io/fedora-infrastructure/issue/9944
> 
> Would there be anyone who would like to investigate how to add ElN image
> uploads to fedimg? I can do it, but I have a bunch of other things too,
> so this might be a nice thing for others to work on to get involved. 
> 
> https://github.com/fedora-infra/fedimg
> 
> Any takers?
> 
> kevin
> 
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[PATCH 2/2] openshift-apps/compose-tracker: switch to Fedora 31

[Dusty Mabe]

---
 .../openshift-apps/compose-tracker/templates/imagestream.yml  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roles/openshift-apps/compose-tracker/templates/imagestream.yml 
b/roles/openshift-apps/compose-tracker/templates/imagestream.yml
index 9c889c0af..fed50e16f 100644
--- a/roles/openshift-apps/compose-tracker/templates/imagestream.yml
+++ b/roles/openshift-apps/compose-tracker/templates/imagestream.yml
@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: List
 items:
-# ImageStream for Fedora 30 image
+# ImageStream for Fedora 31 image
 - apiVersion: image.openshift.io/v1
   kind: ImageStream
   metadata:
@@ -15,7 +15,7 @@ items:
 - name: "30"
   from:
 kind: DockerImage
-name: registry.fedoraproject.org/fedora:30
+name: registry.fedoraproject.org/fedora:31
   importPolicy: 
 scheduled: true
   referencePolicy:
-- 
2.24.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

openshift-apps/compose-tracker: add cverna to app owners, switch to Fedora 31

[Dusty Mabe]

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 1/2] openshift-apps/compose-tracker: add cverna to app owners

[Dusty Mabe]

---
 playbooks/openshift-apps/compose-tracker.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/playbooks/openshift-apps/compose-tracker.yml 
b/playbooks/openshift-apps/compose-tracker.yml
index 72691f592..bcb6d8a8b 100644
--- a/playbooks/openshift-apps/compose-tracker.yml
+++ b/playbooks/openshift-apps/compose-tracker.yml
@@ -17,6 +17,7 @@
 - mizdebsk
 - mohanboddu
 - humaton
+- cverna
 
   - role: openshift/object
 app: compose-tracker
-- 
2.24.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] openshift-apps/docsbuilding: add dustymabe to owners

[Dusty Mabe]

On 1/16/20 8:42 AM, Clement Verna wrote:
> I have applied and deployed this patch.
> 
> You should be all set now.

Thanks All!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] openshift-apps/docsbuilding: add dustymabe to owners

[Dusty Mabe]

Considering we have CoreOS documentation. I'd like to be able to
see the build processes to know when/if they are failing for any
reason.
---
 playbooks/openshift-apps/docsbuilding.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/playbooks/openshift-apps/docsbuilding.yml 
b/playbooks/openshift-apps/docsbuilding.yml
index 431e14392..b3f4f10be 100644
--- a/playbooks/openshift-apps/docsbuilding.yml
+++ b/playbooks/openshift-apps/docsbuilding.yml
@@ -15,6 +15,7 @@
 appowners:
 - asamalik
 - jibecfed
+- dustymabe
 tags:
   - apply-appowners
   - role: openshift/imagestream
-- 
2.24.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] aws-iam-policies: fcos-upload-amis: add ability to DescribeRegions

[Dusty Mabe]

On 11/30/19 3:21 PM, Kevin Fenzi wrote:
> On Wed, Nov 27, 2019 at 09:26:09AM -0500, Dusty Mabe wrote:
>> pushed, can you update the policy in AWS?
> 
> Done. 
> 

Thanks Kevin! Can we look at getting Mohan the permissions to do this too?

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] aws-iam-policies: fcos-upload-amis: add ability to DescribeRegions

[Dusty Mabe]

pushed, can you update the policy in AWS?

On 11/27/19 9:22 AM, Mohan Boddu wrote:
> LGTM +1
> 
> On Wed, Nov 27, 2019 at 9:19 AM Dusty Mabe  wrote:
>>
>> Need this since we recently changed to dynamically detect regions
>> to upload to. See https://github.com/coreos/coreos-assembler/commit/ab3cae5
>> ---
>>  files/aws/iam/policies/fcos-upload-amis.json | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/files/aws/iam/policies/fcos-upload-amis.json 
>> b/files/aws/iam/policies/fcos-upload-amis.json
>> index 03999c6b0..266074522 100644
>> --- a/files/aws/iam/policies/fcos-upload-amis.json
>> +++ b/files/aws/iam/policies/fcos-upload-amis.json
>> @@ -22,6 +22,7 @@
>>  "ec2:DescribeImageAttribute",
>>  "ec2:DescribeVolumes",
>>  "ec2:CreateSnapshot",
>> +"ec2:DescribeRegions",
>>  "ec2:DescribeConversionTasks"
>>  ],
>>  "Resource": "*"
>> --
>> 2.20.1
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] aws-iam-policies: fcos-upload-amis: add ability to DescribeRegions

[Dusty Mabe]

Need this since we recently changed to dynamically detect regions
to upload to. See https://github.com/coreos/coreos-assembler/commit/ab3cae5
---
 files/aws/iam/policies/fcos-upload-amis.json | 1 +
 1 file changed, 1 insertion(+)

diff --git a/files/aws/iam/policies/fcos-upload-amis.json 
b/files/aws/iam/policies/fcos-upload-amis.json
index 03999c6b0..266074522 100644
--- a/files/aws/iam/policies/fcos-upload-amis.json
+++ b/files/aws/iam/policies/fcos-upload-amis.json
@@ -22,6 +22,7 @@
 "ec2:DescribeImageAttribute",
 "ec2:DescribeVolumes",
 "ec2:CreateSnapshot",
+"ec2:DescribeRegions",
 "ec2:DescribeConversionTasks"
 ],
 "Resource": "*"
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] robosignatory.toml.j2: bump FCOS artifacts signing key to f31

[Dusty Mabe]

On 11/25/19 9:47 AM, Jonathan Lebon wrote:
> From: Jonathan Lebon 
> 
> FCOS is now rebased to f31. Bump the signing key accordingly.
> 
> Signed-off-by: Jonathan Lebon 
> ---
>  roles/robosignatory/templates/robosignatory.toml.j2 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/roles/robosignatory/templates/robosignatory.toml.j2 
> b/roles/robosignatory/templates/robosignatory.toml.j2
> index 8126648c9..520ec72ee 100644
> --- a/roles/robosignatory/templates/robosignatory.toml.j2
> +++ b/roles/robosignatory/templates/robosignatory.toml.j2
> @@ -476,7 +476,7 @@ handlers = ["console"]
>  
>  [consumer_config.coreos]
>  bucket = "fcos-builds"
> -key = "{{ (env == 'production')|ternary('fedora-30', 'testkey') }}"
> +key = "{{ (env == 'production')|ternary('fedora-31', 'testkey') }}"
>  
>  [consumer_config.coreos.aws]
>  access_key = "{{ fcos_builds_releng_aws_access_id }}"


LGTM
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR bodhi-pungi: only run multi-arch SB on f31+

[Dusty Mabe]

pushed and ran playbook

Thanks!

On 10/29/19 3:09 PM, Stephen John Smoogen wrote:
> +1 .. now I found it.
> 
> On Tue, 29 Oct 2019 at 14:19, Stephen John Smoogen  wrote:
>>
>> I didn't see anything patched on there so I am not sure what to review.
>>
>> On Tue, 29 Oct 2019 at 09:49, Dusty Mabe  wrote:
>>>
>>> [PATCH] bodhi-pungi: only run multi-arch SB on f31+
>>> ___
>>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>>> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
>>
>>
>>
>> --
>> Stephen J Smoogen.
> 
> 
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] bodhi-pungi: only run multi-arch SB on f31+

[Dusty Mabe]

This is a fixup for d7713e6 where mulit-arch was enabled.
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 640ddf058..b83c9f4f5 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -193,8 +193,13 @@ ostree = {
 "ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/testing/silverblue",
 [% endif %]
 "tag_ref": False,
-"arches": ["x86_64", "ppc64le", "aarch64" ],
-"failable": ["x86_64", "ppc64le", "aarch64" ]
+[% if release.version_int <= 30 %]
+"arches": ["x86_64"],
+"failable": ["x86_64"]
+[% else %]
+"arches": ["x86_64", "ppc64le", "aarch64" ],
+"failable": ["x86_64", "ppc64le", "aarch64" ]
+[% endif %]
 },
 ]
 }
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

FBR bodhi-pungi: only run multi-arch SB on f31+

[Dusty Mabe]

[PATCH] bodhi-pungi: only run multi-arch SB on f31+
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH 1/2] bodhi-pungi: F32 will be the next "branched"

[Dusty Mabe]

Thanks! pushed!

On 10/24/19 5:10 PM, Rick Elrod wrote:
> +1 for the same reason.
> 
> -re
> 
> On 2019-10-24 16:23, Mohan Boddu wrote:
>> Since rawhide is not uses pungi, I think we are okay with this change.
>>
>> +1 LGTM
>>
>> On Thu, Oct 24, 2019 at 4:13 PM Mohan Boddu  wrote:
>>>
>>> No, with rawhide gating we are using bodhi to push rawhide builds as
>>> updates, I think it might call it and cause some issues.
>>>
>>> On Thu, Oct 24, 2019 at 4:05 PM Dusty Mabe  wrote:
>>>>
>>>>
>>>>
>>>> On 10/24/19 4:02 PM, Mohan Boddu wrote:
>>>>> Just wondering, doesn't it affect rawhide composes, since rawhide is 
>>>>> still 32?
>>>>>
>>>>
>>>> IIUC the first time this will take any effect is when we start calling 
>>>> bodhi with '32'
>>>> as the number (i.e. after we have branched and rawhide is now 33).
>>>>
>>>> Dusty
>>>>
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
>>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] new-updates-sync: sync multiarch silverblue ostree content

[Dusty Mabe]

Thanks! Fixed the syntax error and pushed!

On 10/24/19 5:06 PM, Rick Elrod wrote:
> +1 after the syntax fix I mentioned inline.
> 
> -re
> 
> On 2019-10-24 15:56, Dusty Mabe wrote:
>> ---
>>   roles/bodhi2/backend/files/new-updates-sync | 10 ++
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/roles/bodhi2/backend/files/new-updates-sync 
>> b/roles/bodhi2/backend/files/new-updates-sync
>> index d08c89301..9ad7628b8 100755
>> --- a/roles/bodhi2/backend/files/new-updates-sync
>> +++ b/roles/bodhi2/backend/files/new-updates-sync
>> @@ -25,8 +25,9 @@ RELEASES = {'f31': {'topic': 'fedora',
>>   'modules': ['fedora', 'fedora-secondary'],
>>   'repos': {'updates': {
>>   'from': 'f31-updates',
>> -'ostrees': [{'ref': 
>> 'fedora/31/x86_64/updates/silverblue',
>> - 'dest': OSTREEDEST}],
>> +'ostrees': [{'ref': 
>> 'fedora/31/%(arch)s/updates/silverblue',
>> + 'dest': OSTREEDEST,
>> + 'arches': ['x86_64', 'ppc64le', 
>> 'aarch64']},
> 
> I think this is missing another ] at the end before the comma (to match 
> with the [ after 'ostrees':
> 
>>   'to': [{'arches': ['x86_64', 'armhfp', 'aarch64', 
>> 'source'],
>>   'dest': os.path.join(FEDORADEST, '31', 
>> 'Everything')},
>>  {'arches': ['ppc64le', 's390x'],
>> @@ -34,8 +35,9 @@ RELEASES = {'f31': {'topic': 'fedora',
>> ]},
>> 'updates-testing': {
>>   'from': 'f31-updates-testing',
>> -'ostrees': [{'ref': 
>> 'fedora/31/x86_64/testing/silverblue',
>> - 'dest': OSTREEDEST}],
>> +'ostrees': [{'ref': 
>> 'fedora/31/%(arch)s/testing/silverblue',
>> + 'dest': OSTREEDEST,
>> + 'arches': ['x86_64', 'ppc64le', 
>> 'aarch64']},
> 
> Same here.
> 
>>   'to': [{'arches': ['x86_64', 'aarch64', 'armhfp', 
>> 'source'],
>>   'dest': os.path.join(FEDORADEST, 
>> 'testing', '31', 'Everything')},
>>  {'arches': ['ppc64le', 's390x'],
>>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH 1/2] bodhi-pungi: F32 will be the next "branched"

[Dusty Mabe]

On 10/24/19 4:02 PM, Mohan Boddu wrote:
> Just wondering, doesn't it affect rawhide composes, since rawhide is still 32?
> 

IIUC the first time this will take any effect is when we start calling bodhi 
with '32'
as the number (i.e. after we have branched and rawhide is now 33).

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] new-updates-sync: sync multiarch silverblue ostree content

[Dusty Mabe]

---
 roles/bodhi2/backend/files/new-updates-sync | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/roles/bodhi2/backend/files/new-updates-sync 
b/roles/bodhi2/backend/files/new-updates-sync
index d08c89301..9ad7628b8 100755
--- a/roles/bodhi2/backend/files/new-updates-sync
+++ b/roles/bodhi2/backend/files/new-updates-sync
@@ -25,8 +25,9 @@ RELEASES = {'f31': {'topic': 'fedora',
 'modules': ['fedora', 'fedora-secondary'],
 'repos': {'updates': {
 'from': 'f31-updates',
-'ostrees': [{'ref': 
'fedora/31/x86_64/updates/silverblue',
- 'dest': OSTREEDEST}],
+'ostrees': [{'ref': 
'fedora/31/%(arch)s/updates/silverblue',
+ 'dest': OSTREEDEST,
+ 'arches': ['x86_64', 'ppc64le', 
'aarch64']},
 'to': [{'arches': ['x86_64', 'armhfp', 'aarch64', 
'source'],
 'dest': os.path.join(FEDORADEST, '31', 
'Everything')},
{'arches': ['ppc64le', 's390x'],
@@ -34,8 +35,9 @@ RELEASES = {'f31': {'topic': 'fedora',
   ]},
   'updates-testing': {
 'from': 'f31-updates-testing',
-'ostrees': [{'ref': 
'fedora/31/x86_64/testing/silverblue',
- 'dest': OSTREEDEST}],
+'ostrees': [{'ref': 
'fedora/31/%(arch)s/testing/silverblue',
+ 'dest': OSTREEDEST,
+ 'arches': ['x86_64', 'ppc64le', 
'aarch64']},
 'to': [{'arches': ['x86_64', 'aarch64', 'armhfp', 
'source'],
 'dest': os.path.join(FEDORADEST, 'testing', 
'31', 'Everything')},
{'arches': ['ppc64le', 's390x'],
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

FBR new-updates-sync: sync multiarch silverblue ostree content

[Dusty Mabe]

[PATCH] new-updates-sync: sync multiarch silverblue ostree content
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 2/2] bodhi-pungi: enable aarch64 and ppc64le for silverblue updates

[Dusty Mabe]

---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 28b524a10..640ddf058 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -193,8 +193,8 @@ ostree = {
 "ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/testing/silverblue",
 [% endif %]
 "tag_ref": False,
-"arches": ["x86_64"],
-"failable": ["x86_64"]
+"arches": ["x86_64", "ppc64le", "aarch64" ],
+"failable": ["x86_64", "ppc64le", "aarch64" ]
 },
 ]
 }
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

FBR: updates Silverblue in bodhi pungi config

[Dusty Mabe]

[PATCH 1/2] bodhi-pungi: F32 will be the next "branched"
[PATCH 2/2] bodhi-pungi: enable aarch64 and ppc64le for silverblue

Now that F31 is a go we need to do a few things. One of them
is enabling other architectures, which was done in rawhide and f31.
This propagates it into bodhi.

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 1/2] bodhi-pungi: F32 will be the next "branched"

[Dusty Mabe]

Now that f31 is go we can use the final location for ostree repo input.
Bump the variable so that it will only look at branched for f32.
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 688badeee..28b524a10 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -179,8 +179,8 @@ ostree = {
 # In the case of testing, also inject the last stable 
updates
 "https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/updates/f[[ release.version_int 
]]-updates/compose/Everything/$basearch/os/",
 [% endif %]
-# For f31 the compose location is going to be under 
/compose/branched/
-[% if release.version_int == 31 %]
+# For F32 the compose location is going to be under 
/compose/branched/
+[% if release.version_int == 32 %]
 "https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
]]/compose/Everything/$basearch/os/"
 [% else %]
 "https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/[[ release.version_int ]]/latest-Fedora-[[ 
release.version_int ]]/compose/Everything/$basearch/os/"
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: communishift reinstall

[Dusty Mabe]

On 10/19/19 7:49 PM, Kevin Fenzi wrote:
> Greetings communishift group (and infrastructure list). 
> 
> I was working on the communishift cluster trying to fix it's failing to
> upgrade as well as some cert issues, and managed to munge up the cluster
> but good. ;( It's a tribute to the resillance of OpenShift that it's up
> and serving applications still. :) 
> 
> In any event, I think the easiest way to clean things up and get back to
> normal is for us to just reinstall it. With that in mind, I am planning
> to do so starting at 21UTC on 2019-10-21 (monday).

Fine by me. I don't have anything critical in there for now. What should
people do with data in any volumes they have? Will that be lost? 

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: CPE Weekly: 2019-10-11

[Dusty Mabe]

  
  
Thanks again for putting this out! The brief updates are really
  nice!
Dusty 

On 10/11/19 1:57 PM, Aoife Moloney
  wrote:


  
  
  Hi everyone,
  
  Welcome to the CPE team weekly project update mail!
  
  
  Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give.
  For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done.  
  
  
  
  Fedora:
  
  Rawhide Gating: 
  
  
5.0 pre-release is ue in staging by hopefully the end of this week
New Koji has been deployed in production

  https://pagure.io/fedora-infrastructure/issue/8244

Requests for side-tags via fedpkg seems to work

  https://pagure.io/fedora-infrastructure/issue/8280

Createrepo for side tag in koji is now 45-seconds for a side-tag - this is lower than before, so making progress!

  https://pagure.io/fedora-infrastructure/issue/8245

Fedora Messaging:

  Ci-resultsdb-listener is waiting on ci.centos.org to be finished/deployed.
  Fedora-messaging code has been merged
  New release will support new message from the CI system

  
  
  repoSpanner
  
  
Increased push performance by 51%!
  
  
  CentOS:
  
  
 The team is working with CERN about koji upgrade process for cbs.centos.org
CentOS CI 

  JMS messaging  plugin now in testing
  
Ack of messages is still missing but the fix is in progress
Both publishing & consuming are working
  

Mirrorlist code change for CentOS 8
Investigating a phpbb upgrade for www.centos.org/forums and fr.centos.org/forums hosts
  
  
  
  
  Application Handover to Community
  
  
Elections: Blocked by this issue - PostgreSQL database is missing in application catalogue https://pagure.io/fedora-infrastructure/issue/8253
Badges: Thread has been started to get a decision with new maintainers
Packagedb-cli: Retired.
Pastebin: Ongoing conversations with future maintainer, expecting an update in the next week
Elections: Move to CommuniShift underway but blocked by this issue before complete

   https://pagure.io/fedora-infrastructure/issue/8253

Fedocal:  Possible maintainer found & the team are/will engage to finalize

  https://pagure.io/fedora-infrastructure/issue/8274
  Deadline for commitment to maintain is still 15th October

Nuancier: Maintainer(s!) are identified and the team are engaging in a conversation :)

  There is also a conversation happening in Fedora infra channel about changes in Nuancier.

Documentation for onboarding contributors to Community OpenShift still ongoing with a good mail thread on Fedora Devel
  
  
  
  Misc highlights from various parts of the ecosystem:
  
  
FPDC: No Update
CI Initiative: Disg-git test of CentOS infra conversation happening here https://pagure.io/fedora-infrastructure/issue/8279
Bug in Koji plugin was resolved so sending signing messages has resumed.
  
  https://pagure.io/fedora-infrastructure/issue/8158
  
cpe/infra-docs repo is being removed from pagure and we are now going to use infra-docs-pagure instead. Working with an active contributor in the repo to make sure there are no problems.
Final freeze started on Tuesday 8th October
  







As always, comments and feedback are more than welcome and
  we hope you are finding these updates informative! 




Have a great weekend!
Aoife


-- 

  

  

  

  
Aoife Moloney
  
  Feature
Driver
  Community
  

Re: CPE Team Weekly Update

[Dusty Mabe]

On 9/27/19 9:18 AM, Aoife Moloney wrote:
> Hi everyone,
> 
> 
> I’d like to introduce myself first, my name is Aoife Moloney and I recently 
> started with the Community Platform Engineering (CPE) team. My role within 
> this team is going to be a hybrid role of a Product Owner / Project Manager.
> 
> As part of that, I want to send a weekly update to the lists to give an 
> insight into what the CPE team have worked on over the past week or so. This 
> will also be mirrored as a higher level blog to give maximum visibility.
> 
> We, as a team, welcome your input and comments and please do let us know how 
> we can improve this community facing information segment!
> 
> As you know, the CPE team looks after interests in both Fedora and CentOS, so 
> this update is also going to include work done on areas that are not your 
> Community, but for transparency, we are including it :)

Hi Aoife, Great to virtually meet you!

I think this report is great! Thank you so much for sending it and for
committing to doing so in the future!

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] openshift/rbac: allow project owners to cancel-builds

[Dusty Mabe]

On 9/30/19 9:24 AM, Luca BRUNO wrote:
> This tweaks project-owners RBAC to allow updating a build, in order
> to make `cancel-build` work.
> 
> Ref: https://pagure.io/fedora-infrastructure/issue/8005
> Signed-off-by: Luca BRUNO 
> ---
>  roles/openshift/project/templates/role-appowners.yml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/roles/openshift/project/templates/role-appowners.yml 
> b/roles/openshift/project/templates/role-appowners.yml
> index bb4db5d9e..3cb94c542 100644
> --- a/roles/openshift/project/templates/role-appowners.yml
> +++ b/roles/openshift/project/templates/role-appowners.yml
> @@ -79,8 +79,10 @@ rules:
>attributeRestrictions: null
>resources:
>- buildconfigs/instantiate
> +  - builds
>verbs:
>- create
> +  - update
>  - apiGroups:
>- "*"
>attributeRestrictions: null
> 


From a trivial review this LGTM but it would be really nice to get
someone who wrote this file to review the change!

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Freeze Break Request: update openssl on proxy servers

[Dusty Mabe]

On 9/17/19 1:46 PM, Kevin Fenzi wrote:
> Greetings.
> 
> I'd like to apply:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-d51641f152
> 
> to our proxy servers and restart httpd on them.
> 
> This is to fix:
> 
> https://pagure.io/fedora-infrastructure/issue/8173
> https://bugzilla.redhat.com/show_bug.cgi?id=1737471
> 
> (basically newer podman (in f31+) cannot pull images from our registry
> due to a openssl bug.
> 
> Id like to get this out today since beta went out today and people are
> going to start trying to use it. If I don't get enough +1's I'll just
> apply it tomorrow after freeze.
> 

+1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: State/future of the packages app

[Dusty Mabe]

On 9/12/19 4:16 PM, Kevin Fenzi wrote:
> On 9/12/19 1:12 PM, Adam Williamson wrote:
>> On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote:
>>> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna  
>>> wrote:


 On Wed, 11 Sep 2019 at 15:06, Ankur Sinha  wrote:
> Hello,
>
> I was looking for information on the future of the packages
> application[1]. I didn't see it mentioned in the commblog post[2].

 Currently the application is in a kind of maintenance mode (in reality I 
 don't have much time to look at tickets). This application is really 
 valuable and used a lot, but the big problem is the technology stack it is 
 built on TurboGears2 and making an heavy use of Moksha 
 (https://moksha.readthedocs.io/en/latest/), while TG2 is still active 
 upstream, this is not the case with Moksha and some of the TG2 
 dependencies the application has. The effort to move away from these 2 
 framework is quite high and I don't think we currently have the cycles for 
 it.

 My personal opinion is that we should really try to consolidate on 
 src.fp.o and instead of investing time in porting packages to more recent 
 technologies we should put that effort in adding the missing features to 
 src.fp.o.

>>>
>>> If we lose the packages app, we'll lose the only way to search for
>>> binary packages. src.fp.o only shows source package names, and most
>>> people aren't going to know what those are.
>>
>> FWIW, a feature of the packages app I use *all the time* is
>> bugz.fedoraproject.org/ . I can do everything I use that
>> for in other ways, sure, but it's a fantastically helpful shortcut for
>> finding and reporting bugs in .
>>
> mee too. ;(
> 
> I also used 'pkgwat releases packagename' a lot. (pkgwat was the
> packages command line app, but it's python2 only, so it went away I
> fear. That was a nice easy way to see what release of a thing was in
> each of the supported branches...
> 

Wow. I never even knew about `pkgwat`. I have an alias in my shell that
will pop open the packages app for any rpm name:

```
fpkgpage ()
{ 
xdg-open https://apps.fedoraproject.org/packages/${1}
}
```

So I use `fpkgpage dnf` or whatever anytime I need to get to a good launch point
to find all the information about a package. I really like the packages app and 
will
be really sad to see it go. I use it all the time. 

I'm just another one of those freeloaders that can't commit to maintaining it 
though.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Freeze Break Request: Fix typo in bodhi status variable

[Dusty Mabe]

On 9/9/19 2:34 PM, Kevin Fenzi wrote:
> Greetings.
> 
> We have a variable in:
> vars/all/FedoraBranchedBodhi.yaml
> 
> thats used in our bodhi config to set the proper policies.
> The template uses 'predeta' and 'postbeta'... but the variable was
> updated to 'preBeta', which isn't going to work.
> 
> I'd like to apply the following and run the bodhi backend playbook:
> 
> diff --git a/vars/all/FedoraBranchedBodhi.yaml
> b/vars/all/FedoraBranchedBodhi.yaml
> index 91f82f2..f0cca9a 100644
> --- a/vars/all/FedoraBranchedBodhi.yaml
> +++ b/vars/all/FedoraBranchedBodhi.yaml
> @@ -1,2 +1,2 @@
> -#options are: preBeta, postBeta, current
> -FedoraBranchedBodhi: preBeta
> +#options are: prebeta, postbeta, current
> +FedoraBranchedBodhi: prebeta
> 

+1 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Meeting Agenda 2019-09-05

[Dusty Mabe]

On 9/4/19 2:00 PM, Stephen John Smoogen wrote:

> 
> ```
> #topic Where to put these docs in the future?
> #info infinote is going away and this is my 'private hackmd'
> #info a new central doc place would be good. can someone set this up?
> ```

More topics to discuss from the CoreOS teams:

https://github.com/coreos/fedora-coreos-tracker/blob/master/Fedora-Requests.md#existing-requests-for-fedora-infra
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

FBR: hotfix robosignatory to fix ostree signing issue

[Dusty Mabe]

We hit a bug every release where the directories haven't yet been
created for the refs we want to sign [1]. The bug has been fixed in
the latest code [2] but hasn't been deployed to prod yet.

We'd like to deploy that small patch to prod so we can make sure
we never hit this again.

Dusty

[1] https://pagure.io/robosignatory/issue/19
[2] 
https://pagure.io/robosignatory/c/f462fc2c81b7cad15acb2da630c69114b30ef3d9?branch=master
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Fedora 31 Beta freeze now in effect

[Dusty Mabe]

On 8/27/19 3:38 PM, Kevin Fenzi wrote:
> On 8/27/19 11:50 AM, Dusty Mabe wrote:
>>
>>
>> On 8/27/19 2:21 PM, Kevin Fenzi wrote:
>>> Greetings.
>>>
>>> we are now in the infrastructure freeze leading up to the Fedora 31
>>> Beta release. This is a pre release freeze.
>>>
>>> We do this to ensure that our infrastructure is stable and ready to
>>> release the Fedora 31 Beta when it's available.
>>>
>>> You can see a list of hosts that do not freeze by checking out the
>>> ansible repo and running the freezelist script:
>>>
>>> git clone
>>> https://infrastructure.fedoraproject.org/infra/ansible.git
>>> ansible/scripts/freezelist -i inventory
>>
>> I had a problem with this because I didn't have python2 libraries
>> for ansible installed so the `import ansible.inventory` failed.
> 
> Ah, it's expected to run on batcave01... where it does work.
> 
>>
>> Switching the script to python3 worked. Should we apply this?
> 
> That would break it on batcave01... :(

We can't get the newer version there?

> 
>> $ git diff
>> diff --git a/scripts/freezelist b/scripts/freezelist
>> index 89856ea09..b1c99054c 100755
>> --- a/scripts/freezelist
>> +++ b/scripts/freezelist
>> @@ -1,4 +1,4 @@
>> -#!/usr/bin/python
>> +#!/usr/bin/python3
>>  # skvidal
>>  # doteast: porting to ansible 2.0
>>  # dump out the hosts marked with 'freezes: true' in their vars
>>
>>
>>>
>>> Any hosts listed as freezes is frozen until 2019-09-17 (or later if
>>> release slips or uses the secondary target). Frozen hosts should have no
>>> changes made to them without a sign-off on the change from at least 2
>>> sysadmin-main or rel-eng members, along with (in most cases) a patch of
>>> the exact change to be made to this list.
>>
>>
>> I see the openshift nodes listed as frozen. What about applications that
>> are running in openshift? Can I commit changes to my apps that are for
>> CoreOS without a review? 
> 
> I think thats up to you all... since those are not directly related to
> the Fedora release, I'd say we wouldn't need to. Perhaps we would want
> to have a seperate (more targeted) freeze before the next FCOS release?
> Or perhaps it doesn't make sense? There are some things we do that are
> related to your release... signing artifacts, the updater app, etc.
> 
> I'm open to whatever works best for you all here.

I just want to know that I'm doing things that are allowed. If you feel 
comfortable
that I'm within my rights, then I'm happy.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Fedora 31 Beta freeze now in effect

[Dusty Mabe]

On 8/27/19 2:21 PM, Kevin Fenzi wrote:
> Greetings.
> 
> we are now in the infrastructure freeze leading up to the Fedora 31
> Beta release. This is a pre release freeze.
> 
> We do this to ensure that our infrastructure is stable and ready to
> release the Fedora 31 Beta when it's available.
> 
> You can see a list of hosts that do not freeze by checking out the
> ansible repo and running the freezelist script:
> 
> git clone
> https://infrastructure.fedoraproject.org/infra/ansible.git
> ansible/scripts/freezelist -i inventory

I had a problem with this because I didn't have python2 libraries
for ansible installed so the `import ansible.inventory` failed.

Switching the script to python3 worked. Should we apply this?

$ git diff
diff --git a/scripts/freezelist b/scripts/freezelist
index 89856ea09..b1c99054c 100755
--- a/scripts/freezelist
+++ b/scripts/freezelist
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 # skvidal
 # doteast: porting to ansible 2.0
 # dump out the hosts marked with 'freezes: true' in their vars


> 
> Any hosts listed as freezes is frozen until 2019-09-17 (or later if
> release slips or uses the secondary target). Frozen hosts should have no
> changes made to them without a sign-off on the change from at least 2
> sysadmin-main or rel-eng members, along with (in most cases) a patch of
> the exact change to be made to this list.


I see the openshift nodes listed as frozen. What about applications that
are running in openshift? Can I commit changes to my apps that are for
CoreOS without a review? 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: A few patches for bodhi pungi compose

[Dusty Mabe]

On 8/23/19 12:19 PM, Kevin Fenzi wrote:
> On 8/23/19 5:07 AM, Dusty Mabe wrote:
>> [PATCH 1/3] bodhi-pungi: get rid of < f29 logic
>>
>> Some cleanup
>>
>> [PATCH 2/3] bodhi-pungi: branched is now f31
>>
>> This fixes a compose issue: 
>> https://pagure.io/releng/failed-composes/issue/53
>>
>> [PATCH 3/3] bodhi-pungi: add the f32 signing key
>>
>> Future proofing.
> 
> Sure, looks ok to me. +1 to merge and I can run the playbook if you like.

Pushed and playbook ran! That's one button I'm able to push!

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 3/3] bodhi-pungi: add the f32 signing key

[Dusty Mabe]

---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index bd8ec6526..688badeee 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -31,6 +31,8 @@ sigkeys = [
 'cfc659b9',
 [% elif release.version_int == 31 %]
 '3c3359c4',
+[% elif release.version_int == 32 %]
+'12c944d0',
 [% elif release.version_int == 6 %]
 '0608b895',
 [% elif release.version_int == 7 %]
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

A few patches for bodhi pungi compose

[Dusty Mabe]

[PATCH 1/3] bodhi-pungi: get rid of < f29 logic

Some cleanup

[PATCH 2/3] bodhi-pungi: branched is now f31

This fixes a compose issue: 
https://pagure.io/releng/failed-composes/issue/53

[PATCH 3/3] bodhi-pungi: add the f32 signing key

Future proofing.


___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 1/3] bodhi-pungi: get rid of < f29 logic

[Dusty Mabe]

We are no longer building f28 so we can remove these if statements.
---
 .../bodhi2/backend/templates/pungi.rpm.conf.j2 | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 93638c4ef..477fe14da 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -168,11 +168,7 @@ ostree = {
 # Fedora Silverblue
 {
 "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
-[% if release.version_int >= 29 %]
-"treefile": "fedora-silverblue.yaml",
-[% else %]
-"treefile": "fedora-atomic-workstation-updates-[[ request.name 
]].json",
-[% endif %]
+"treefile": "fedora-silverblue.yaml",
 "config_url": "https://pagure.io/workstation-ostree-config.git;,
 "config_branch": "f[[ release.version ]]",
 "repo": [
@@ -189,14 +185,10 @@ ostree = {
 [% endif %]
 ]
 "ostree_repo": "/mnt/koji/compose/ostree/repo",
-# For f29+ we are changing the ref to silverblue. For f28/f27 let 
the files
-# still specify the workstation ref.
-[% if release.version_int >= 29 %]
-[% if request.name == 'stable' %]
-"ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/updates/silverblue",
-[% else %]
-"ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/testing/silverblue",
-[% endif %]
+[% if request.name == 'stable' %]
+"ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/updates/silverblue",
+[% else %]
+"ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/testing/silverblue",
 [% endif %]
 "tag_ref": False,
 "arches": ["x86_64"],
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Access for dusty to sysadmin-main

[Dusty Mabe]

On 8/20/19 11:52 AM, Clement Verna wrote:
> 
> 
> Yes just to make sure there is no misunderstanding I am not trying to blame 
> anyone too and I am also keen on finding a better ways for these work to move 
> smoothly without the need for you to bug someone every day and without having 
> someone bugging us every day :-D.
> 
> I think in that particular case, the problem is that your needs went under 
> our radar, and the work that you needed was not visible, hence not 
> prioritized at our team level. This means that we have been busy with X other 
> initiatives (Rawhide Gating, EPEL-8, Community OpenShift, + usual keeping the 
> lights on work). Unfortunately it is almost impossible for you to see how 
> busy we are and what are our current priorities and work in progress. We hope 
> to improve in that area, so that I believe it would be easier for you to see 
> what the team is busy with. Then it should be easier for you to raise your 
> hand  and say that you have something urgent coming in.
> In the same time we don't really have visibility to your planning and to your 
> milestones, so it is also difficult for us to make a good call without 
> knowing the expected timeline and what is your critical path.
> 
> All that to say I think the main problem here is lack of communication and 
> lack of sharing information.


We are totally in agreement. My request here was trying to short circuit the 
process
since I know what our priorities are and you know what your priorities are we 
can make
sure we sync up on the overall goals (i.e. high level sessions where we discuss 
what we
want to do and how to do it, like the sesions we had with mohan, patrick, kevin 
before)
and then someone from our team executes on those goals.

I understood from the beginning that it might not work. Just wanted to have the 
conversation.

Thanks for everything you do cverna!
Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Access for dusty to sysadmin-main

[Dusty Mabe]

On 8/20/19 10:33 AM, Stephen John Smoogen wrote:
> 
> That 5 minute session isn't a 5 minute session to us. For us it is
> usually 40-60 minutes of context swapping from what we were doing to
> fixing your 5 minute thing to try to get back to the other thing to
> going back to you.. but after someone sees we answered you.. they go
> and ping us expecting us to give them the same level of service we
> gave you. Then we never get back to the thing and you end up with us
> getting more and more frustrated by your 5 minute sessions. You are
> worried about waiting a week? Try waiting 2 years to complete a
> project because your ability to focus on it is constantly broken up by
> 5 minute sessions.
> 
> You having sysadmin-main is not going to fix this. It just means you
> are seen as responsible as everyone else who has sysadmin-main to fix
> every problem. You will now be getting the 5 minute pings that
> mizdebsk and the other non-Fedora Infrastructure people get all the
> time to fix all the 'little problems'. You will probably end up doing
> the same thing they do which is go off IRC completely for days at a
> time because it is the only way to get work done. You will also find
> that saying 'you can't help' doesn't get you anywhere.. we just get
> pinged asking why we have someone who can't do everything in
> sysadmin-main. [This has happened several times in the past with other
> people who have been in main so I am going from experience here.]
> 
> Please realize that you are one of multiple important customers who
> all want as much time from a sysadmin-main person as you do. We could
> triple the number of people in sysadmin-main and still not have enough
> time to deal with the irqs.. we would just find that a lot of them
> have just been paused indefinitely to spring up when more people are
> available. Slowing things down by more careful planning, processes and
> controls is usually the only way to deal with it because it is a human
> complexity problem.
> 
> I realize that sometimes this answer is not what works for a customer.
> 

I sympathize (empathize?) with everything you're saying smooge. I really hope
this request isn't felt as being a pointed audit of anyone in sysadmin-main.
I'm incredibly humbled to work with each of you every day. This request to me
is more me saying "can I help by reducing the number of times we ping you?".
But you're saying that what I'm asking for is different or actually won't 
help, which I accept.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Access for dusty to sysadmin-main

[Dusty Mabe]

On 8/20/19 10:18 AM, Clement Verna wrote:
> On Tue, 20 Aug 2019 at 15:30, Dusty Mabe  wrote:
>>
>>
>>
>> On 8/19/19 6:09 PM, Kevin Fenzi wrote:
>>>
>>> Well, this I think is related to our "agile transformation" (or if you
>>> prefer "reorganizing how we work"). Right now, you find it hard to get
>>> stuff done because everyone is busy on other things, so you have to nag
>>> us to get stuff done which makes things worse for us, etc.
>>
>> Right. It has been this way for a long time. It's not your fault and it's
>> not my fault, but both of us feel like we've got the short end of the stick.
>>
>>>
>>> Ideally I think we can get to a place where we do a lot more scheduling
>>> and a lot less having to yell for cycles. You note a few things were
>>> just 5 min for someone to do... but the way we are working now someone
>>> does that thing for you finally, but then goes back to the other stuff
>>> they were working on, meaning in 30min you need another thing... repeat.
>>>
>>> If you can come to us and say "hey, this is my project, I need it
>>> deployed by X" we can look at it, gather info we need, put it in our
>>> queue and then tell you "hey, we can work on that next tuesday". Then
>>> next tuesday we can devote a block of time to getting everything done. I
>>> think thats a win for everyone in the end and I would really like to get
>>> there. Can we? I sure hope so
>>
>>
>>>
>>> In fact perhaps we could start doing this now somewhat: block off say...
>>> wed into 2 hour blocks. Sign up people who have projects or pet
>>> bugs/issues they want to get solved for those blocks and work on them?
>>
>>
>> I think blocking off time and doing some scheduling is a great idea. My 
>> advice
>> here is that we have a shared calendar with blocks that people can sign up 
>> for
>> automatically (i.e. if the block is open anyone can reserve it as long as 
>> they
>> have a FAS account).
>>
>> The only counter point that I have is that sometimes a "block of time" isn't
>> always what's needed. Sometimes it will be something very small, but rather
>> fundamental, that requires quite a bit of rework by the end user. For 
>> example,
>> you and I have a 5 minutes session where some revelation comes to light and I
>> need to go rewrite a portion of my application. I then spend two hours doing
>> that and have to wait a week for the next block of time.
>>
> 
> I think this is the symptom of a lack of upfront cooperation and
> design. This is what we are currently putting in place, if you need
> something consequent from us you come up with a spec that explain the
> WHAT and the WHY.  Then we work together on the HOW and WHEN, once we
> have a good idea of the HOW and WHEN the work will be prioritized on
> our side (might have a dedicated team assigned to it) which I think
> will make cooperation easier.
> 
> It is never too late to start, so maybe we should spend some time to
> write down everything that is needed for Fedora CoreOS, write down HOW
> this will be done and what the work being Done means. That way we
> could probably dedicated a few people to focus on that work until
> completion.
> 
> How does that sounds ?

We certainly haven't done as good as we could here but we have written down
our overall design [1] and had several sessions with core members of releng and
infra (mohan, patrick, kevin) to discuss the feasibility of it all. Once we
got to a point where we were ready to formally ask for help we have done that
in tickets to the infra repo [2-6]:

We're definitely not doing the best job here, but we have done some 
communication.
I do want to say that I'm not complaining about the job anyone has done! Just
trying to find a better move forward for everyone.

Dusty

[1] 
https://github.com/coreos/fedora-coreos-tracker/blob/master/stream-tooling.md
[2] https://pagure.io/fedora-infrastructure/issue/7884
[3] https://pagure.io/fedora-infrastructure/issue/7870
[4] https://pagure.io/fedora-infrastructure/issue/7821
[5] https://pagure.io/fedora-infrastructure/issue/8064
[6] https://pagure.io/fedora-infrastructure/issue/7997
[7] https://pagure.io/fedora-infrastructure/issue/7719
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Access for dusty to sysadmin-main

[Dusty Mabe]

On 8/19/19 6:09 PM, Kevin Fenzi wrote:
> 
> Well, this I think is related to our "agile transformation" (or if you
> prefer "reorganizing how we work"). Right now, you find it hard to get
> stuff done because everyone is busy on other things, so you have to nag
> us to get stuff done which makes things worse for us, etc.

Right. It has been this way for a long time. It's not your fault and it's
not my fault, but both of us feel like we've got the short end of the stick.

> 
> Ideally I think we can get to a place where we do a lot more scheduling
> and a lot less having to yell for cycles. You note a few things were
> just 5 min for someone to do... but the way we are working now someone
> does that thing for you finally, but then goes back to the other stuff
> they were working on, meaning in 30min you need another thing... repeat.
> 
> If you can come to us and say "hey, this is my project, I need it
> deployed by X" we can look at it, gather info we need, put it in our
> queue and then tell you "hey, we can work on that next tuesday". Then
> next tuesday we can devote a block of time to getting everything done. I
> think thats a win for everyone in the end and I would really like to get
> there. Can we? I sure hope so


> 
> In fact perhaps we could start doing this now somewhat: block off say...
> wed into 2 hour blocks. Sign up people who have projects or pet
> bugs/issues they want to get solved for those blocks and work on them?


I think blocking off time and doing some scheduling is a great idea. My advice
here is that we have a shared calendar with blocks that people can sign up for
automatically (i.e. if the block is open anyone can reserve it as long as they
have a FAS account).

The only counter point that I have is that sometimes a "block of time" isn't
always what's needed. Sometimes it will be something very small, but rather
fundamental, that requires quite a bit of rework by the end user. For example,
you and I have a 5 minutes session where some revelation comes to light and I
need to go rewrite a portion of my application. I then spend two hours doing
that and have to wait a week for the next block of time.

One thing that we might be able to do for that is have separate blocks of
time the next day that is specifically for follow ups to the previous day. 

> 
> Anyhow, I think the answer is in working better/smarter rather than
> granting people more perms in general. Of course increasing the pool of
> people who can do specific things might also help, but also those people
> will need to learn when to do things and when to ask about doing things.

I think working smarter is definitely going to be what we need to do over time
to support the rest of Fedora and "initiatives" better. For Fedora CoreOS, for
right now I really do think it would help if one of the Fedora CoreOS team were
given more access so we can self service better. Right now we either need more
access or we need more dedicated attention for the various needs we have. If we
could get a one hour a day scheduled commitment I think that would help us quite
a bit. We won't always need help (i.e. we cancel) and we won't always need the
whole hour, but right now it would really make a difference in our progress.

WDYT?

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Access for dusty to sysadmin-main

[Dusty Mabe]

On 8/16/19 5:04 PM, Stephen John Smoogen wrote:
> On Fri, 16 Aug 2019 at 16:40, Dusty Mabe  wrote:
>>
>> I suspect this request might fall short, but I figure I'll start a dialog.
>>
> ...
>>
>> I'd like to help if possible, but I understand if my request isn't granted.
>>
> 
> I have a counter idea which probably won't fly well either. My main
> thing I would like is that people who are in main are doing the
> following:
> 1. Regularly taking IRC oncall for a week
> 2. Regularly taking 'pager' duty for a week.At the moment this means
> taking all the pages all the time but just listening to it when
> oncall. I would love a way that pages was just 1-2 people for a week..
> which would make that more possible.
> 3. Let people know what their areas of expertise are and take those tickets.
> 
> I am less inclined to have people on main who are just doing it for
> one set of things because it doesn't help us lower our overall
> workload.. it just allows that person fix their problem.
> 


Honestly this may help address my problem as well, just approaching it from
a different direction. Having more people around who are capable of "doing
things" would certainly help. I guess my proposal includes me being around
and capable of doing things, but "yes" with a focus on FCOS related tasks.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Access for dusty to sysadmin-main

[Dusty Mabe]

I suspect this request might fall short, but I figure I'll start a dialog.

With Fedora CoreOS needing some different services set up and more and more
requests getting opened every day on the infra issue tracker, it would be nice
if I could gain some more access within Fedora Infra to be able to help support
the Fedora CoreOS efforts as well as possibly help lighten the load (i.e. 
perform
simple privileged tasks for unprivileged people when appropriate) of Fedora's
infra team.

I've had a few services that I recently got all the way through the RFR process.
I was admittedly out for a month during that time on leave, but if you subtract
that month it still took a rather long time to make it to completion. The long 
times
aren't necessarily anyone's fault, just happens to be how the requests landed 
and
also my projects not necessarily being on anyone's priority list.

That being said, I have learned a lot by getting these apps into prod and I feel
like I can help our future apps along if I had more access to debug things 
myself
(i.e. inconsistencies in stage) rather than waiting on someone from infra.

I am not requesting this access to abuse it. I am typically conservative and 
don't
do things that I'm not comfortable doing or that I know would be frowned upon. 
As
an example I was granted access to the releng group a while back and I think 
that
has worked out well.

I'd like to help if possible, but I understand if my request isn't granted.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Bot Account for Bodhi Karma

[Dusty Mabe]

On 8/15/19 2:49 PM, Pierre-Yves Chibon wrote:
> On Thu, Aug 15, 2019 at 08:41:53AM -0400, Dusty Mabe wrote:
>>
>>
>> On 8/15/19 5:16 AM, Tim Flink wrote:
>>> After the Flock talk from the Facebook folks, they approached QA about
>>> the idea of submitting karma and/or test results from their internal
>>> testing as a bot account.
>>>
>>> Is this something that is possible? I know that we have done bot
>>> accounts at various points in time but I don't remember if automated
>>> karma is allowed or what the other restrictions on that were.
>>>
>>
>> +1 for this. In the Fedora CoreOS working group we have a few packages
>> where we'll be testing them extensively via automated tests and we'd like
>> to have those passing tests satisfy karma requirements for the packages to
>> be passed through to bodhi stable. Some packages we own and most likely
>> no one else cares about (like ignition) and others we'll test and simply add 
>> a
>> karma point such that it's a piece of data used to determine if the package
>> should be submitted to stable.
> 
> Would you be open to the idea of gating your packages on these tests? (I 
> figure
> this question applies to both Dusty and the facebook folks)
> 
> Down the road, I think we may want to lower the human element in our workflow 
> in
> favor of automated test systems that packages are gated on, so while this idea
> is still very young and thus karma may be easier to implement today, it may be
> something to keep in mind and consider for the future.
> 
> What do you think?
> 

I might be using terms wrong here so forgive me if the terminology is slightly 
off.
Basically the goal is the allow for tests to contribute a vote in some way that 
allows
a package to be accepted to stable sooner. Some packages could be fully 
automated (if
automated tests pass then they go to stable). Some packages could be partially 
automated
(if automated tests pass then it contributes some to it going to stable). 
Whether it 
be "karma" or "gating" it doesn't matter to me.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Bot Account for Bodhi Karma

[Dusty Mabe]

On 8/15/19 5:16 AM, Tim Flink wrote:
> After the Flock talk from the Facebook folks, they approached QA about
> the idea of submitting karma and/or test results from their internal
> testing as a bot account.
> 
> Is this something that is possible? I know that we have done bot
> accounts at various points in time but I don't remember if automated
> karma is allowed or what the other restrictions on that were.
> 

+1 for this. In the Fedora CoreOS working group we have a few packages
where we'll be testing them extensively via automated tests and we'd like
to have those passing tests satisfy karma requirements for the packages to
be passed through to bodhi stable. Some packages we own and most likely
no one else cares about (like ignition) and others we'll test and simply add a
karma point such that it's a piece of data used to determine if the package
should be submitted to stable.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: A Friday with Infra

[Dusty Mabe]

On 8/8/19 6:29 AM, Michal Konecny wrote:
> Good Morning Everyone,
> 
> As you may remember from [1] the CPE team has started categorizing its 
> applications into the following categories:
> 
>  1. We maintain it, we run it
>  2. We don’t maintain it, we run it
>  3. We don’t maintain it, we don’t run it
>  4. We turn it off
> 
> In this process we picked the following four applications that we want to 
> move from the first category to the third:
> 
>   * elections [2]
>   * fedocal
>   * nuancier
>   * badges

If someone were willing to manage something like badges, could it not stay in 
fedora infra? i.e. the 2nd category?

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Sunset of infinote (Gobby) service

[Dusty Mabe]

On 8/2/19 6:37 AM, Clement Verna wrote:
> On Thu, 1 Aug 2019 at 19:46, Justin W. Flory  wrote:
>>
>> On 8/1/19 3:34 AM, Clement Verna wrote:
>>> Dear all,
>>>
>>> The Fedora Infrastructure is planning to retire the infinote [0]
>>> service. This service allows text collaboration using the Gobby
>>> client[1] and was mainly used by the Infrastructure team to coordinate
>>> our weekly meeting and the mass update & reboot of the machines.
>>>
>>> The service will be taken offline on August 30th 2019. If you wish to
>>> backup some of the document currently hosted, you should make sure
>>> that you have downloaded them locally before that date.
>>>
>>> The Infrastructure team will most likely use the service provided by
>>> hackmd.io [2] for their needs. Other alternatives like public etherpad
>>> can also be used to replace this service.
>>>
>>
>> Hi, to clarify, will the online cgit interface at infinote.fp.o also be
>> taken offline or only the Infinote server connected from Gobby client?
>> Will documents hosted there disappear from the public Internet?
> 
> Yes the cgit interface will be taken offline and yes the documents
> will not be available anymore.
> 
> We can make a backup of the documents, but a infra ticket will be
> required to access them.
> 

Could you just archive the git repo into pagure so people who really wanted
to dig could try to find what they were looking for?

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Congrats to our new sysadmin-mainers

[Dusty Mabe]

On 8/5/19 3:25 PM, Kevin Fenzi wrote:
> I'm happy to announce that We have approved several folks into the
> sysadmin-main group:
> 
> mohanboddu 'Mohan Boddu'
> cverna 'Clement Verna'
> bowlofeggs 'Randy Barlow'
> 
> This is the core group of trusted folks that high level access to most
> everything in fedora infrastructure.
> 
> All these folks have done great work over the last few years on various
> big projects, proving their dedication, trustworthiness, and ability.
> 
> Congrats to them all!
> 
> Use your powers for good! :)
> 

Thanks for all the hard work everyone has done. Congrats! 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [Fedocal] Reminder meeting : Fedora Infrastructure

[Dusty Mabe]

I've added a topic to the Gobby for tomorrow's meeting:


```
#topic options for release artifact signing for Fedora CoreOS - dustymabe

We are exploring options for signing our release artifacts for Fedora CoreOS.
We have an open ticket where we have defined various options and narrowed down
the options to ones we'd like to explore with Fedora Infrastructure. The ticket
and all context can be found here: 
https://github.com/coreos/fedora-coreos-tracker/issues/187
The TL;DR is that we'd like to deliver an artifact and a detached signature:
i.e. `fcos.iso` and `fcos.iso.sig`. We'd like to discuss with infra to see what
the limitations are in the infra for achieving this goal and if we can make it 
happen.
```
On 6/5/19 11:00 AM, smo...@gmail.com wrote:
> Dear all,
> 
> You are kindly invited to the meeting:
>Fedora Infrastructure on 2019-06-06 from 15:00:00 to 16:00:00 UTC
>At fedora-meetin...@irc.freenode.net
> 
> The meeting will be about:
> Weekly Fedora Infrastructure meeting. See infrastructure list for agenda a 
> day before or view it at 
> https://infinote.fedoraproject.org/cgit/infinote/tree/fedora-infrastructure-meeting-next
> 
> 
> Source: https://apps.fedoraproject.org/calendar/meeting/22/
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] robosignatory: add aarch64 and ppc64le signing for silverblue

[Dusty Mabe]

On 5/7/19 5:48 PM, Kevin Fenzi wrote:
> On 5/7/19 11:24 AM, Dusty Mabe wrote:
>> ---
>>  roles/robosignatory/files/robosignatory.production.py | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/roles/robosignatory/files/robosignatory.production.py 
>> b/roles/robosignatory/files/robosignatory.production.py
>> index a15b1e448..daeb9b876 100644
>> --- a/roles/robosignatory/files/robosignatory.production.py
>> +++ b/roles/robosignatory/files/robosignatory.production.py
>> @@ -474,6 +474,14 @@ config = {
>>  'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
>>  'key': 'fedora-30'
>>  },
>> +'fedora/rawhide/aarch64/silverblue': {
>> +'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
>> +'key': 'fedora-31'
>> +},
>> +'fedora/rawhide/ppc64le/silverblue': {
>> +'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
>> +'key': 'fedora-31'
>> +},
>>  'fedora/rawhide/x86_64/silverblue': {
>>  'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
>>  'key': 'fedora-31'
>>
> Looks ok to me.
> 

Thanks! Pushed. Can you run the playbook?
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] robosignatory: add aarch64 and ppc64le signing for silverblue

[Dusty Mabe]

---
 roles/robosignatory/files/robosignatory.production.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/roles/robosignatory/files/robosignatory.production.py 
b/roles/robosignatory/files/robosignatory.production.py
index a15b1e448..daeb9b876 100644
--- a/roles/robosignatory/files/robosignatory.production.py
+++ b/roles/robosignatory/files/robosignatory.production.py
@@ -474,6 +474,14 @@ config = {
 'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
 'key': 'fedora-30'
 },
+'fedora/rawhide/aarch64/silverblue': {
+'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
+'key': 'fedora-31'
+},
+'fedora/rawhide/ppc64le/silverblue': {
+'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
+'key': 'fedora-31'
+},
 'fedora/rawhide/x86_64/silverblue': {
 'directory': '/mnt/fedora_koji/koji/compose/ostree/repo/',
 'key': 'fedora-31'
-- 
2.20.1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Deprecating Autocloud

[Dusty Mabe]

On 5/2/19 12:53 PM, Adam Williamson wrote:
> On Thu, 2019-05-02 at 10:15 -0400, Dusty Mabe wrote:
>>
>> On 5/2/19 12:08 AM, Neal Gompa wrote:
>>> On Wed, May 1, 2019 at 10:48 PM Dusty Mabe  wrote:
>>>> We plan to have testing at various stages of the CoreOS build and delivery
>>>> pipeline. We definitely plan to have FCOS taken care of using the existing
>>>> kola testing utility [1] that was in use previously for container linux.
>>>>
>>>> With that said, one thing that has previously been out of scope for kola is
>>>> testing instances that aren't provisioned with ignition (i.e. they use 
>>>> cloud-init
>>>> instead). Today the Fedora Cloud base images are not provisioned using 
>>>> ignition so
>>>> we'll either need to consider adding ignition as an option there OR 
>>>> consider running
>>>> automated tests against the Fedora Cloud base images in OpenQA (if that's 
>>>> possible).
>>>>
>>>
>>> It's all possible with OpenQA, the tests just have to be written. :)
>>
>> I don't know a whole lot about OpenQA but I'm interested to know:
>> Is it easy to start a VM and attach metadata to it (i.e. support 
>> cloud-init)? 
> 
> I'd have to look into it, but it shouldn't be hard. Starting VMs is
> what it *does*, and if it can't support cloud-init already, I can add
> it. I'm on vacation till the 19th, will follow up on this later.

Sounds good.

> 
> It would be a good idea if the actual tests can be shared between test
> systems as much as possible. I know the tests Autocloud ran were
> basically just bash scripts - openQA could easily use those. What do
> the tests run in kola look like?

They are embedded in kola itself. It's very much a focused tool for a
single purpose.

> 
> There's also the question of whether we still want to ship/support the
> Cloud Base images. For now they are still release-blocking
> deliverables, but their status feels a little vague to me. It would be
> good to figure out for sure whether we still consider them important,
> if so why, and if so who is in charge of them.
> 

I think so. Some effort has been made to consolidate cloud/server, but for
right now nothing is broke and people are working on other things so it is
the status quo. You can talk to me or Joe Doss about cloud images if you
have issues.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Deprecating Autocloud

[Dusty Mabe]

On 5/2/19 12:08 AM, Neal Gompa wrote:
> On Wed, May 1, 2019 at 10:48 PM Dusty Mabe  wrote:

>> We plan to have testing at various stages of the CoreOS build and delivery
>> pipeline. We definitely plan to have FCOS taken care of using the existing
>> kola testing utility [1] that was in use previously for container linux.
>>
>> With that said, one thing that has previously been out of scope for kola is
>> testing instances that aren't provisioned with ignition (i.e. they use 
>> cloud-init
>> instead). Today the Fedora Cloud base images are not provisioned using 
>> ignition so
>> we'll either need to consider adding ignition as an option there OR consider 
>> running
>> automated tests against the Fedora Cloud base images in OpenQA (if that's 
>> possible).
>>
> 
> It's all possible with OpenQA, the tests just have to be written. :)

I don't know a whole lot about OpenQA but I'm interested to know:
Is it easy to start a VM and attach metadata to it (i.e. support cloud-init)? 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Deprecating Autocloud

[Dusty Mabe]

On 5/1/19 10:20 PM, Adam Williamson wrote:
> On Mon, 2019-04-29 at 18:57 +0530, Sinny Kumari wrote:
>> On Mon, Apr 29, 2019 at 4:47 PM Kamil Paral  wrote:
>>
>>> On Mon, Apr 29, 2019 at 11:39 AM Sinny Kumari  wrote:
>>>

 On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi  wrote:

> Or could we move f29+ all to whatever is replacing it? (taskotron?)
>

 It will be nice but I am not aware of any other system in place which
 would
 replace checks performed by autocloud.

 (CC'ed tflink and kparal)
 Does taskotron provides capability to perform tests on Fedora cloud
 Images like booting images and other basic checks?

>>>
>>> Theoretically it is possible using nested virt. However, Taskotron is
>>> going away as well. The replacement is Fedora CI:
>>> https://docs.fedoraproject.org/en-US/ci/
>>>
>>
>> Thanks kamil! yeah, it doesn't make sense to move to Taskotron if it is
>> going to be deprecated as well.
>>
>>
>>> I recommend to ask in the CI list:
>>> https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/
>>>
>>> It should be possible for them to provide the infrastructure you need.
>>>
>>
>> Hmm, I am not very sure if we should spend time investigating and setting
>> up alternative
>> to autocloud unless we have usecases for long run. Fedora Atomic Host Two
>> Week releases ends with F29 EOL.
> 
> We could run these tests in openQA pretty easily, I think. The question
> is, I guess, whether they will still be of value for Fedora CoreOS.
> 
> I guess to me the real job Autocloud is doing is this: "make sure the
> images we intend people to use to run Fedora instances in the cloud
> basically work and can do some simple tasks people tend to do with such
> images". If the Fedora CoreOS team already is covering this some other
> way, or intends to cover it some other way before Fedora CoreOS becomes
> a supported thing, then we probably don't need to preserve the
> Autocloud tests. If this is not in scope for the Fedora CoreOS
> team...we probably still need to do it somewhere else.
> 
> So...has anyone asked the Fedora CoreOS team what the plans here are?
> :)

We plan to have testing at various stages of the CoreOS build and delivery
pipeline. We definitely plan to have FCOS taken care of using the existing
kola testing utility [1] that was in use previously for container linux.

With that said, one thing that has previously been out of scope for kola is
testing instances that aren't provisioned with ignition (i.e. they use 
cloud-init
instead). Today the Fedora Cloud base images are not provisioned using ignition 
so
we'll either need to consider adding ignition as an option there OR consider 
running
automated tests against the Fedora Cloud base images in OpenQA (if that's 
possible).

Dusty

[1] https://github.com/coreos/mantle#kola
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: PATCH: Setup for coreos-pool and coreos-release tags

[Dusty Mabe]

On 5/1/19 1:24 PM, Mohan Boddu wrote:
> CoreOS needs coreos-pool and coreos-release tags to build backported builds 
> and tag the builds that go into the release.
> 
> More info: https://pagure.io/releng/issue/8294
> 
> Please review the following patch and let me know if it needs any changes.


LGTM - but two questions below: 

> 
> diff --git a/roles/koji_hub/templates/hub.conf.j2 
> b/roles/koji_hub/templates/hub.conf.j2
> index 0bf00ce..db8df35 100644
> --- a/roles/koji_hub/templates/hub.conf.j2
> +++ b/roles/koji_hub/templates/hub.conf.j2
> @@ -97,6 +97,8 @@ tag =
>      fromtag *infra* :: deny
>      # CoreOS continuous builds, https://pagure.io/releng/issue/8165
>      tag f{{FedoraRawhideNumber}}-coreos-continuous 
> f{{FedoraBranchedNumber}}-coreos-continuous 
> f{{FedoraCycleNumber}}-coreos-continu

this line looks truncated - caused my patch to not apply (copy/paste error?)

> +    # CoreOS coreos-pool and coreos-release tags, 
> https://pagure.io/releng/issue/8294
> +    tag coreos-pool coreos-release && has_perm coreos-continuous :: allow
>      all :: allow
>  
>  channel =
> @@ -149,5 +151,7 @@ package_list =
>      tag *infra* && has_perm infra && match action add unblock block :: allow
>      # CoreOS continuous builds, https://pagure.io/releng/issue/8165
>      tag f{{FedoraRawhideNumber}}-coreos-continuous 
> f{{FedoraBranchedNumber}}-coreos-continuous 
> f{{FedoraCycleNumber}}-coreos-continu

line truncated like above

> +    # CoreOS coreos-pool and coreos-release tags, 
> https://pagure.io/releng/issue/8294
> +    tag coreos-pool coreos-release && has_perm coreos-continuous && match 
> action add unblock block :: allow
>      # Catch-all rule.
>      all :: deny
> diff --git a/roles/robosignatory/files/robosignatory.production.py 
>  
> b/roles/robosignatory/files/robosignatory.production.py 
> 
> index 196243a..e2a6b23 100644
> --- a/roles/robosignatory/files/robosignatory.production.py 
> 
> +++ b/roles/robosignatory/files/robosignatory.production.py 
> 
> @@ -111,6 +111,14 @@ config = {
>                      "keyid": "47dd8ef9"
>                  },
>  
> +                # Gated coreos-pool tag
> +                {
> +                    "from": "f30-coreos-signing-pending",
> +                    "to": "coreos-pool",
> +                    "key": "fedora-30",
> +                    "keyid": "cfc659b9"
> +                },
> +
>                  # Gated rawhide and branched
>                  {
>                      "from": "f31-pending",
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Deployment of plume in Fedora Infrastructure

[Dusty Mabe]

On 4/22/19 4:19 AM, Sayan Chowdhury wrote:
> Hi all,
> 
> Over the last few months, I was working on integrating Fedora as a
> sub-system to plume. This is to migrate from fedimg to plume, and
> finally deprecating plume.
> 
> The work on plume has been completed and over the next few days, I
> prepare for the deployment of plume. I've prepared a spec document for
> the same[1]. I plan to move this to Fedora wiki in some time but if
> someone wants to do a review can have a look at it and post comments.
> 
> [1] https://hackmd.io/fpDWrtuJT7-jt8jy2yJC1Q?view
> 


Nice writeup Sayan! Let me know how I can help.

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: Deprecating Autocloud

[Dusty Mabe]

On 4/29/19 9:27 AM, Sinny Kumari wrote:
> 
> 
> On Mon, Apr 29, 2019 at 4:47 PM Kamil Paral  > wrote:
> 
> On Mon, Apr 29, 2019 at 11:39 AM Sinny Kumari  > wrote:
> 
> 
> 
> On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi  > wrote:
> 
> Or could we move f29+ all to whatever is replacing it? 
> (taskotron?)
> 
> 
> It will be nice but I am not aware of any other system in place which 
> would
> replace checks performed by autocloud.
> 
> (CC'ed tflink and kparal)
> Does taskotron provides capability to perform tests on Fedora cloud 
> Images like booting images and other basic checks?
> 
> 
> Theoretically it is possible using nested virt. However, Taskotron is 
> going away as well. The replacement is Fedora CI:
> https://docs.fedoraproject.org/en-US/ci/
> 
> 
> Thanks kamil! yeah, it doesn't make sense to move to Taskotron if it is going 
> to be deprecated as well.
> 
> 
> I recommend to ask in the CI list:
> 
> https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/
> 
> It should be possible for them to provide the infrastructure you need.
> 
> 
> Hmm, I am not very sure if we should spend time investigating and setting up 
> alternative
> to autocloud unless we have usecases for long run. Fedora Atomic Host Two 
> Week releases ends with F29 EOL.

I would say let's keep it around until we EOL f29 Atomic Host. Let's not put 
any investment into it or migrating
it elsewhere.

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR: update python-tag2distrepo on bodhi-backend02

[Dusty Mabe]

bump - can we get some votes on this? I would vote but my vote doesn't count :) 

On 4/16/19 5:10 PM, Mikolaj Izdebski wrote:
> Problem: tag2distrepo fails to generate dist-repo for CoreOS
> continuous builds [1] bacause CoreOS tags contain unsigned packages
> and tag2distrepo can't handle them.
> 
> Fix: to fix the problem I would like to install
> python-tag2distrepo-1-0.10.fc29 [2] on
> bodhi-backend02.phx2.fedoraproject.org and restart
> fedmsg-hub-3.service. The build backports upstream patch [3]
> 
> $ koji move f29-infra-stg f29-infra python-tag2distrepo-1-0.10.fc29
> # dnf --refresh update python3-tag2distrepo
> # systemctl restart fedmsg-hub-3
> 
> [1] https://pagure.io/releng/issue/8165
> [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1251150
> [3] https://pagure.io/releng/tag2distrepo/pull-request/3
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR: upgrade oz on builders

[Dusty Mabe]

On 3/14/19 9:58 AM, Stephen John Smoogen wrote:
> On Thu, 14 Mar 2019 at 09:55, Peter Robinson  wrote:
>>
>> To deal with the cloud image issue I was originally going to resolve
>> it slightly differently, I've not dealt with it in oz. the current
>> "Fedora version" that pungi specifies (F-22) now retains BIOS by
>> default, to use UEFI you can specify F-30 and if edk2 is available it
>> will use that by default.
>>
>> So I'd like to upgrade the builders to oz-0.17.0-0.2.fc29
> 
> This will need to be coordinated on the 2 ppc builders that do image
> builds because they require an older kernel/libvirt/someother stuff
> and when I was doing updates on them oz would not upgrade because it
> was built against the newer versions (I am not sure if it was directly
> or a dependency chain issue).

For context here is the ticket that led to the downgrade:
https://pagure.io/fedora-infrastructure/issue/7598

It has an associated bug I think:
https://bugzilla.redhat.com/show_bug.cgi?id=1676475

Would love to have whatever issues there are there to be resolved so we
don't need to do this in the future. I'll add a comment to the issue to
see if we can get any more info.

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Adjust bodhi pungi config to build AH only for <= F29

[Dusty Mabe]

On 2/18/19 2:18 PM, Dusty Mabe wrote:
> 
> On 2/18/19 12:29 PM, Sinny Kumari wrote:
>> Updated patch with keeping repos list on separate lines and removed comma.
> 
> LGTM
> 


pushed and playbook ran
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Adjust bodhi pungi config to build AH only for <= F29

[Dusty Mabe]

On 2/18/19 12:29 PM, Sinny Kumari wrote:
> Updated patch with keeping repos list on separate lines and removed comma.

LGTM
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Adjust bodhi pungi config to build AH only for <= F29

[Dusty Mabe]

Mostly LGTM.. A few comments inline. 

On 2/18/19 11:40 AM, Sinny Kumari wrote:
> We recently announced [1] that with upcoming FCOS, last major release of 
> Fedora Atomic Host is Fedora 29. This patch (avilable in email attachment) 
> contains changes in bodhi pungi config to build Fedora Atomic related content 
> only till F29. Also, we shouldn't be needing robosignatory signing for Atomic 
> Host rawhide  refs.
> 
> 
> [1] 
> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2019-February/msg4.html
> 
> 0001-Adjust-bodhi-pungi-config-to-build-AH-only-for-F29.patch
> 
> From 085c14eac01f79d7482863f3292e757a73141adb Mon Sep 17 00:00:00 2001
> From: Sinny Kumari 
> Date: Mon, 18 Feb 2019 21:53:08 +0530
> Subject: [PATCH] Adjust bodhi pungi config to build AH only for <= F29
> 
> Also remove rawhide ref from robosignatory
> Related: https://github.com/coreos/fedora-coreos-tracker/issues/145
> 
> Signed-off-by: Sinny Kumari 
> ---
>  .../backend/templates/pungi.rpm.conf.j2   | 37 +--
>  .../files/robosignatory.production.py | 12 --
>  2 files changed, 9 insertions(+), 40 deletions(-)
> 
> diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
> b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> index be1e7..7a57b9ba9 100644
> --- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> +++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
> @@ -122,6 +122,9 @@ createiso_skip = [
>  ostree = {
>  "^Everything$": [
>  # Atomic Host
> +# Atomic Host will be avilable till F29 EOL
> +# See https://github.com/coreos/fedora-coreos-tracker/issues/145
> +[% if release.version_int <= 29 %]
>  {
>  "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
>  "force_new_commit": True
> @@ -130,16 +133,11 @@ ostree = {
>  "config_branch": "f[[ release.version ]]",
>  "repo": [
>  "Everything",
> +"https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/[[ release.version_int ]]/latest-Fedora-[[ 
> release.version_int ]]/compose/Everything/$basearch/os/",
>  [% if request.name == 'testing' %]
>  # In the case of testing, also inject the last stable 
> updates
>  "https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/updates/f[[ release.version_int 
> ]]-updates/compose/Everything/$basearch/os/",

Do we need to remove the comma at the end of this line since it is now the last 
item in the list?

>  [% endif %]
> -# For f30 the compose location is going to be under 
> /compose/branched/
> -[% if release.version_int == 30 %]
> -"https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
> ]]/compose/Everything/$basearch/os/"
> -[% else %]
> -"https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/[[ release.version_int ]]/latest-Fedora-[[ 
> release.version_int ]]/compose/Everything/$basearch/os/"
> -[% endif %]
>  ]
>  "ostree_repo": "/mnt/koji/compose/ostree/repo",
>  [% if request.name == 'stable' %]
> @@ -151,6 +149,7 @@ ostree = {
>  "arches": ["x86_64", "ppc64le", "aarch64" ],
>  "failable": ["ppc64le", "aarch64"],
>  },
> +[% endif %]
>  # Fedora Silverblue
>  {
>  "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
> @@ -192,7 +191,7 @@ ostree = {
>  }
>  [% endif %]
>  
> -[% if release.id_prefix == 'FEDORA' and release.version_int >= 29 %]
> +[% if release.id_prefix == 'FEDORA' and release.version_int == 29 %]
>  global_ksurl = 'git+https://pagure.io/fedora-kickstarts.git?#origin/f[[ 
> release.version_int ]]'
>  global_release = '!RELEASE_FROM_LABEL_DATE_TYPE_RESPIN'
>  image_name_format = 
> '%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s-%(date)s%(type_suffix)s.%(respin)s.iso'
> @@ -229,13 +228,7 @@ image_build = {
>  'disk_size': 6,
>  'target': 'f[[ release.version_int ]]',
>  'arches': ['x86_64', 'aarch64', 'ppc64le'],
> -'install_tree_from': 
> -# For f30 the compose location is going to be under 
> /compose/branched/
> -[% if release.version_int == 30 %]
> -"https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
> ]]/compose/Everything/$arch/os/",
> -[% else %]
> -"https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/[[ release.version_int ]]/latest-Fedora-[[ 
> release.version_int ]]/compose/Everything/$arch/os/",
> -[% endif %]
> +'install_tree_from': 'https://kojipkgs{{ env_suffix 
> 

Re: Re-enable updates-testing ostree for Silverblue

[Dusty Mabe]

On 1/8/19 4:25 PM, Kevin Fenzi wrote:
> Looks fine to me. +1

Thanks Kevin

> 
> If you can get it in before tonights push that would be great.
> 

pushed and playbook ran!

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re-enable updates-testing ostree for Silverblue

[Dusty Mabe]

Now that pungi has been updated on the bodhi backend machines
(https://pagure.io/fedora-infrastructure/issue/7484) I can re-enable
updates-testing for silverblue. Also added some removal of code
specific to f27.

- bodhi-pungi: re-enable testing ostree for silverblue
- bodhi-pungi: simplify now that f27 is EOL
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 2/2] bodhi-pungi: simplify now that f27 is EOL

[Dusty Mabe]

Removes conditional logic that considers f27.
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index f2f058771..4757153fd 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -118,14 +118,12 @@ createiso_skip = [
 ]
 
 {% if env != "staging" %}
-[% if release.id_prefix == 'FEDORA' and release.version_int >= 26 %]
+[% if release.id_prefix == 'FEDORA' %]
 ostree = {
 "^Everything$": [
 # Atomic Host
 {
-[% if release.version_int >= 28 %]
-"version": "!VERSION_FROM_VERSION_DATE_RESPIN",
-[% endif %]
+"version": "!VERSION_FROM_VERSION_DATE_RESPIN",
 "force_new_commit": True
 "treefile": "fedora-atomic-host.json",
 "config_url": "https://pagure.io/fedora-atomic.git;,
@@ -150,26 +148,17 @@ ostree = {
 "ostree_ref": "fedora/[[ release.version_int 
]]/${basearch}/testing/atomic-host",
 [% endif %]
 "tag_ref": False,
-"arches": ["x86_64",
-   [% if release.version_int >= 27 %]
-   "ppc64le", "aarch64"
-   [% endif %]
-  ],
-[% if release.version_int >= 27 %]
-"failable": ["ppc64le", "aarch64"],
+"arches": ["x86_64", "ppc64le", "aarch64" ],
+"failable": ["ppc64le", "aarch64"],
 [% endif %]
 },
 # Fedora Silverblue
 {
-[% if release.version_int >= 28 %]
-"version": "!VERSION_FROM_VERSION_DATE_RESPIN",
-[% endif %]
+"version": "!VERSION_FROM_VERSION_DATE_RESPIN",
 [% if release.version_int >= 29 %]
 "treefile": "fedora-silverblue.yaml",
-[% elif release.version_int == 28 %]
-"treefile": "fedora-atomic-workstation-updates-[[ request.name 
]].json",
 [% else %]
-"treefile": "fedora-ostree-workstation-updates-[[ request.name 
]].json",
+"treefile": "fedora-atomic-workstation-updates-[[ request.name 
]].json",
 [% endif %]
 "config_url": "https://pagure.io/workstation-ostree-config.git;,
 "config_branch": "f[[ release.version ]]",
-- 
2.14.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH 1/2] bodhi-pungi: re-enable testing ostree for silverblue

[Dusty Mabe]

This re-enables updates-testing composes for silverblue that were
stopped in df5009d because of https://pagure.io/pungi/issue/1092
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 7a061b5b0..f2f058771 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -160,7 +160,6 @@ ostree = {
 [% endif %]
 },
 # Fedora Silverblue
-[% if request.name == 'stable' %]
 {
 [% if release.version_int >= 28 %]
 "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
@@ -201,7 +200,6 @@ ostree = {
 "arches": ["x86_64"],
 "failable": ["x86_64"]
 },
-[% endif %]
 ]
 }
 [% endif %]
-- 
2.14.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Add CDN testing cloudfront redirect for atomic repo

[Dusty Mabe]

On 1/3/19 10:40 AM, Sinny Kumari wrote:
> Hi,
> 
> Currently, we are using two different cloudfront distributions to CDN content 
> for
> /atomic/repo/objects/ and /atomic/repo/deltas/ . With the current setup we see
> an issue https://github.com/ostreedev/ostree/issues/1541 . To overcome this
> issue and provide faster delivery of ostree content, we have created a
> cloudfront distribution where we CDN /atomic/repo/ .
> 
> This patch (available in attachment) adds some redirect rules to use new
> cloudfront urls for testing purpose and see how much improvement we get in
> content delivery. This patch shouldn't impact existing infra setup.
>

I'd like to highlight this is for testing purposes only and should have a short
life. We just wanted to make sure the "redirect penalty" that we experience with
our prod redirects is also reflected in our testing so we can get more accurate
results.

Sinny,

One thing we might want to do is use https for the cloudfron URLs like we are 
for
the prod redirects. Otherwise LGTM. 

Dusty

___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] bodhi-pungi: don't run silverblue compose for testing

[Dusty Mabe]

This is a temporary hack to workaround https://pagure.io/pungi/issue/1092.
Note this also just re-uses the f27 logic, which is no longer needed.
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index ee1edb6ed..74c0378ec 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -153,8 +153,8 @@ ostree = {
 "failable": ["ppc64le", "aarch64"],
 [% endif %]
 },
-# Atomic Workstation
-[% if release.version_int >= 27 %]
+# Fedora Silverblue
+[% if request.name == 'stable' %]
 {
 [% if release.version_int >= 28 %]
 "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
-- 
2.14.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] bodhi-pungi: pass in ostree_oskey to fedora-lorax-templates

[Dusty Mabe]

On 12/1/18 2:43 PM, Stephen John Smoogen wrote:
> patch looks good. should apply ok.

Merged and playbook ran. Thanks smooge
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] bodhi-pungi: pass in ostree_oskey to fedora-lorax-templates

[Dusty Mabe]

This is needed because of a recent change to parameterize
the key. https://pagure.io/fedora-lorax-templates/pull-request/30
---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index baed32f3f..ee1edb6ed 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -312,6 +312,7 @@ ostree_installer = [
 
'ostree_install_repo=https://kojipkgs.fedoraproject.org/compose/atomic/repo/',
 'ostree_update_repo=https://dl.fedoraproject.org/atomic/repo/',
 'ostree_osname=fedora-atomic',
+'ostree_oskey=fedora-[[ release.version_int ]]-primary',
 'ostree_install_ref=fedora/[[ release.version_int ]]/[[ arch 
]]/[% if request.name == "testing" %]testing[% else %]updates[% endif 
%]/atomic-host',
 'ostree_update_ref=fedora/[[ release.version_int ]]/[[ arch 
]]/atomic-host',
 ],
-- 
2.14.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Silverblue manifest is now fedora-silverblue.yaml

[Dusty Mabe]

On 11/30/18 11:29 AM, Mohan Boddu wrote:
> LGTM +1
> 

pushed and playbook ran. thanks mohan
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] Silverblue manifest is now fedora-silverblue.yaml

[Dusty Mabe]

---
 roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index 3f2608099..baed32f3f 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -160,7 +160,7 @@ ostree = {
 "version": "!VERSION_FROM_VERSION_DATE_RESPIN",
 [% endif %]
 [% if release.version_int >= 29 %]
-"treefile": "fedora-silverblue.json",
+"treefile": "fedora-silverblue.yaml",
 [% elif release.version_int == 28 %]
 "treefile": "fedora-atomic-workstation-updates-[[ request.name 
]].json",
 [% else %]
-- 
2.14.4
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

ostree: silverblue manifest is now fedora-silverblue.yaml

[Dusty Mabe]

Corresponding configs change is in:
https://pagure.io/workstation-ostree-config/pull-request/115#

This will require the bodhi machines to have the hotfixed
pungi rpm with this fix: https://pagure.io/pungi/pull-request/1088
This was already hotfixed on the composer machines.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Pull OSTree repo from compose/atomic/repo during AH ISO creation

[Dusty Mabe]

On 11/12/18 10:26 AM, Mohan Boddu wrote:
> +1 LGTM
> 
> On Mon, Nov 12, 2018 at 9:50 AM Dusty Mabe  <mailto:du...@dustymabe.com>> wrote:
> 
> 
> 
> On 11/12/18 9:48 AM, Sinny Kumari wrote:
> > We recently noticed inconstancy in OSTree version for ppc64le ISO in 
> compose
> > 
> https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20181112.0/compose/
>  .
> > OSTree version for ppc64le ISO was 29.2018.0 while expected was 
> 29.20181112.0.
> >
> > This patch (available in email attachment) is to fix inconsistency in 
> OSTree
> > version which may occur during AH artifacts creation.
> > pull ostree content from repo 
> https://kojipkgs.fedoraproject.org/compose/atomic/repo/
> > instead of https://kojipkgs.fedoraproject.org/atomic/repo/.
> >
> 
> patch LGTM


pushed and playbook ran.

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] Pull OSTree repo from compose/atomic/repo during AH ISO creation

[Dusty Mabe]

On 11/12/18 9:48 AM, Sinny Kumari wrote:
> We recently noticed inconstancy in OSTree version for ppc64le ISO in compose
> https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20181112.0/compose/
>  .
> OSTree version for ppc64le ISO was 29.2018.0 while expected was 
> 29.20181112.0.
> 
> This patch (available in email attachment) is to fix inconsistency in OSTree
> version which may occur during AH artifacts creation.
> pull ostree content from repo 
> https://kojipkgs.fedoraproject.org/compose/atomic/repo/
> instead of https://kojipkgs.fedoraproject.org/atomic/repo/.
> 

patch LGTM
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/30/2018 04:26 PM, Kevin Fenzi wrote:
> On 10/30/18 1:05 PM, Dusty Mabe wrote:
>>
>>
>> On 10/30/18 1:47 PM, Kevin Fenzi wrote:
>>> On 10/30/18 8:26 AM, Dusty Mabe wrote:
>>>>
>>>>
>>>> On 10/29/18 2:43 PM, Kevin Fenzi wrote:
>>>>> Just FYI, we should completely redo these configs using the release
>>>>> variables, but that doesn't have to be today. ;)
>>>>>
>>>>> I assume the check for f30 and using branched is only going to get used
>>>>> once we branch off f30 right (since this config doesn't compose rawhide)?
>>>>>
>>>>> +1
>>>>
>>>> +1 from me too? 
>>>>
>>>> can i push this? 
>>>
>>> Sure, please do... but make sure and coordinate with updates pushes.
>>>
>>
>> I've been told in the past I don't need to coordinate because pungi only 
>> reads this
>> file once during a run. Is that not the case?
> 
> Oh, thats likely the case, but still you might want to know when exactly
> your changes are being used to help debugging problems, etc.
> 

+1
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/30/18 1:47 PM, Kevin Fenzi wrote:
> On 10/30/18 8:26 AM, Dusty Mabe wrote:
>>
>>
>> On 10/29/18 2:43 PM, Kevin Fenzi wrote:
>>> Just FYI, we should completely redo these configs using the release
>>> variables, but that doesn't have to be today. ;)
>>>
>>> I assume the check for f30 and using branched is only going to get used
>>> once we branch off f30 right (since this config doesn't compose rawhide)?
>>>
>>> +1
>>
>> +1 from me too? 
>>
>> can i push this? 
> 
> Sure, please do... but make sure and coordinate with updates pushes.
> 

I've been told in the past I don't need to coordinate because pungi only reads 
this
file once during a run. Is that not the case?

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/30/18 11:26 AM, Dusty Mabe wrote:
> 
> 
> On 10/29/18 2:43 PM, Kevin Fenzi wrote:
>> Just FYI, we should completely redo these configs using the release
>> variables, but that doesn't have to be today. ;)
>>
>> I assume the check for f30 and using branched is only going to get used
>> once we branch off f30 right (since this config doesn't compose rawhide)?
>>
>> +1
> 
> +1 from me too? 
> 
> can i push this? 

pushed and playbook ran
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/29/18 2:43 PM, Kevin Fenzi wrote:
> Just FYI, we should completely redo these configs using the release
> variables, but that doesn't have to be today. ;)
> 
> I assume the check for f30 and using branched is only going to get used
> once we branch off f30 right (since this config doesn't compose rawhide)?
> 
> +1

+1 from me too? 

can i push this? 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [PATCH] new-updates-sync: no longer sync stable refs for ostrees

[Dusty Mabe]

pushed. can one of you run the playbook?

Dusty

On 10/29/2018 02:57 PM, Mohan Boddu wrote:
> LGTM +1
> 
> On Mon, Oct 29, 2018 at 2:44 PM Kevin Fenzi  > wrote:
> 
> Sure. +1
> 
> kevin
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org 
> 
> To unsubscribe send an email to 
> infrastructure-le...@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.fedoraproject.org
> 
> 
> 
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org
> 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

[PATCH] new-updates-sync: no longer sync stable refs for ostrees

[Dusty Mabe]

Now that we are releasing f29, no longer sync the stable refs.
The atomic host stable ref will be controlled by two week releases.
The silverblue stable ref will be aliased to the updates ref.
---
 roles/bodhi2/backend/files/new-updates-sync | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/roles/bodhi2/backend/files/new-updates-sync 
b/roles/bodhi2/backend/files/new-updates-sync
index cbc8b9300..b9b9fa634 100755
--- a/roles/bodhi2/backend/files/new-updates-sync
+++ b/roles/bodhi2/backend/files/new-updates-sync
@@ -28,14 +28,7 @@ RELEASES = {'f29': {'topic': 'fedora',
 'ostrees': [{'ref': 
'fedora/29/%(arch)s/updates/atomic-host',
  'dest': ATOMICDEST,
  'arches': ['x86_64', 'ppc64le', 
'aarch64']},
-# sync base ref for now until f29 is 
released
-{'ref': 'fedora/29/%(arch)s/atomic-host',
- 'dest': ATOMICDEST,
- 'arches': ['x86_64', 'ppc64le', 
'aarch64']},
 {'ref': 
'fedora/29/x86_64/updates/silverblue',
- 'dest': ATOMICDEST},
-# sync base ref for now until f29 is 
released
-{'ref': 'fedora/29/x86_64/silverblue',
  'dest': ATOMICDEST}],
 'to': [{'arches': ['x86_64', 'armhfp', 'aarch64', 
'source'],
 'dest': os.path.join(FEDORADEST, '29', 
'Everything')},
-- 
2.14.4
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

FBR: [PATCH] new-updates-sync: no longer sync stable refs for ostrees

[Dusty Mabe]

Can I get some votes to no longer sync stable ostree refs using
new-updates-sync?

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/29/2018 11:57 AM, Sinny Kumari wrote:
> 
> 
> On Mon, Oct 29, 2018 at 9:25 PM Dusty Mabe  <mailto:du...@dustymabe.com>> wrote:
> 
> 
> 
> On 10/29/2018 11:16 AM, Sinny Kumari wrote:
> >

> >
> > With RC 1.2 being Gold, does it make sense to make this 
> https://kojipkgs{{ env_suffix }}.fedoraproject.org/compose/[[ 
> <http://fedoraproject.org/compose/%5B%5B> 
> <http://fedoraproject.org/compose/[[ 
> <http://fedoraproject.org/compose/%5B%5B>> release.version_int 
> ]]/latest-Fedora-[[ release.version_int ]]/compose/Everything/[[arch]]/os/ ?
> 
> 
> I think probably we should just change the "if conditions" to `== 30` in 
> places where it makes sense now that f29 is going to be released, which 
> should achieve the same goal right?
> 
> Yeah, I will be doing same code wise

+1 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/29/2018 11:16 AM, Sinny Kumari wrote:
> 
> 
> On Fri, Oct 26, 2018 at 7:07 PM Dusty Mabe  <mailto:du...@dustymabe.com>> wrote:
> 
> 
> 
> On 10/25/2018 01:25 PM, Sinny Kumari wrote:
> > Hi,
> >
> > Here is a patch (available in email attachment) to include 
> updates-testing repo
> > as well during Atomic Host ISO creation in bodhi updates-testing run. 
> Specifying
> > multiple repos to lorax should work fine on Fedora >=29 -
> > https://github.com/weldr/lorax/issues/368 .
> >
> > Can I get +1 for the patch?
> >
> > Thanks,
> > Sinny
> 
> 
> Suggested change below. I think we just need to uncomment out the 
> commented out code right
> above the lines you changed.
> 
> 
> Thanks Dusty for reviewing it!
> 
> - updates run will run lorax against
>     - Everything
>         - the current updates run
> 
> +1
> 
>     - https://kojipkgs{{ env_suffix 
> }}.fedoraproject.org/compose/branched/latest-Fedora-[[ 
> <http://fedoraproject.org/compose/branched/latest-Fedora-%5B%5B> 
> release.version_int ]]/compose/Everything/[[arch]]/os/
>         - the release day repo
> 
> 
> With RC 1.2 being Gold, does it make sense to make this https://kojipkgs{{ 
> env_suffix }}.fedoraproject.org/compose/[[ 
> <http://fedoraproject.org/compose/[[> release.version_int ]]/latest-Fedora-[[ 
> release.version_int ]]/compose/Everything/[[arch]]/os/ ?


I think probably we should just change the "if conditions" to `== 30` in places 
where it makes sense now that f29 is going to be released, which should achieve 
the same goal right? 

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: [FBR] Include updates-testing repo during bodhi u-t run

[Dusty Mabe]

On 10/25/2018 01:25 PM, Sinny Kumari wrote:
> Hi,
> 
> Here is a patch (available in email attachment) to include updates-testing 
> repo
> as well during Atomic Host ISO creation in bodhi updates-testing run. 
> Specifying
> multiple repos to lorax should work fine on Fedora >=29 -
> https://github.com/weldr/lorax/issues/368 .
> 
> Can I get +1 for the patch?
> 
> Thanks,
> Sinny


Suggested change below. I think we just need to uncomment out the commented out 
code right
above the lines you changed.
- updates run will run lorax against
- Everything 
- the current updates run
- https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
]]/compose/Everything/[[arch]]/os/
- the release day repo

- updates-testing will run lorax against
- Everything 
- the current updates-testing run
- https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
]]/compose/Everything/[[arch]]/os/
- the release day repo
- https://kojipkgs{{ env_suffix }}.fedoraproject.org/compose/updates/f[[ 
release.version_int ]]-updates/compose/Everything/[[arch]]/os/
- the last updates run



diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 
b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index af3f5ea29..91f8535aa 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -292,13 +292,11 @@ ostree_installer = [
 [% for arch in ['x86_64', 'aarch64', 'ppc64le'] %]
 '[[ arch ]]': {
 "repo": [
-# For now we need to only provide one repo to lorax 
-# See https://github.com/weldr/lorax/issues/368
-#   "Everything",
-#   [% if request.name == 'testing' %]
-#   # In the case of testing, also inject the last 
stable updates
-#   "https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/updates/f[[ release.version_int 
]]-updates/compose/Everything/[[arch]]/os/",
-#   [% endif %]
+"Everything",
+[% if request.name == 'testing' %]
+# In the case of testing, also inject the last stable 
updates
+"https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/updates/f[[ release.version_int 
]]-updates/compose/Everything/[[arch]]/os/",
+[% endif %]
 # For f29 the compose location is under /compose/branched/
 [% if release.version_int == 29 %]
 "https://kojipkgs{{ env_suffix 
}}.fedoraproject.org/compose/branched/latest-Fedora-[[ release.version_int 
]]/compose/Everything/[[arch]]/os/"
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: apache and php7 container

[Dusty Mabe]

On 10/15/2018 05:11 PM, Wagner Marques wrote:
> Hi folks,
> 
> I have been trying to make php7 works on my apache container. 
> This is my Dockerfile: 
> https://github.com/wagnermarques/Fedora-Dockerfiles/blob/master/apache/Dockerfile
> 
> When I access php_info page, I get the logs below:
> 
> [Mon Oct 15 18:28:53.09 2018] [proxy:error] [pid 223:tid 140654374008576] 
> (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix 
> domain socket /run/php-fpm/www.sock (*) failed
> [Mon Oct 15 18:28:53.444500 2018] [proxy_fcgi:error] [pid 223:tid 
> 140654374008576] [client 192.168.0.142:36490] AH01079: failed to make 
> connection to backend: httpd-UDS
> 
> 
> I suppose that the fastcgi php-fpm deamon is not running... If so, what 
> should I do to start such process in docker container?
> Or could someone shed some light about this issue, please?
> 
> best regards
> 
> Wagner
> 

You might find a partial answer in this BZ: 
https://bugzilla.redhat.com/show_bug.cgi?id=1586332
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR: Stop building F28 AH image artifacts during bodhi run

[Dusty Mabe]

On 10/12/2018 01:14 PM, Dusty Mabe wrote:
> 
> 
> On 10/12/2018 01:03 PM, Sinny Kumari wrote:
>> We have 2 +1(assuming that Dusty's vote count for FBR).
>> @dustymabe Can you please push this patch to ansible repo and run playbook?
>>
>> Thanks in advance!
> 
> I don't think my vote officially counts :( - but I will push it once we
> get another +1 :) 
> 

pushed and playbook ran!

Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR: Stop building F28 AH image artifacts during bodhi run

[Dusty Mabe]

On 10/12/2018 01:03 PM, Sinny Kumari wrote:
> We have 2 +1(assuming that Dusty's vote count for FBR).
> @dustymabe Can you please push this patch to ansible repo and run playbook?
> 
> Thanks in advance!

I don't think my vote officially counts :( - but I will push it once we
get another +1 :) 

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org

Re: FBR: Stop building F28 AH image artifacts during bodhi run

[Dusty Mabe]

On 10/12/2018 11:54 AM, Randy Barlow wrote:
> On Fri, 2018-10-12 at 13:43 +0530, Sinny Kumari wrote:
>> Next Fedora Atomic Host TwoWeek release will be based on F29
>> stream and same will be followed in future releases.
>> So, building F28 AH artifacts during bodhi run is
>> not needed.
> 
> Shouldn't we wait until Fedora 29 is released to stop producing Fedora
> 28 content?

We're still producing Fedora 28 Atomic Host OSTree content, just no longer
producing qcow2 and ISO images since we don't plan to do any more two week
releases of Fedora 28.

Does that answer the question? 

Dusty 
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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.fedoraproject.org