Meeting agenda 2020-02-20 15:00 UTC
The infrastructure team will be having its weekly meeting tomorrow, 2020-02-20 at 15:00 UTC in #fedora-meeting-1 on the freenode network. We have a document at https://board.net/p/fedora-infra Please try and review and edit that document before the meeting and we will use it to have our agenda of things to discuss. A copy as of today is included in this email. If you have something to discuss, add the topic to the discussion area with your name. If you would like to teach other folks about some application or setup in our infrastructure, please add that topic and your name to the learn about section. ## Introduction We will use it over the week before the meeting to gather status and info and discussion items and so forth, then use it in the irc meeting to transfer information to the meetbot logs. ### Meeting start stuff ``` #startmeeting Infrastructure (2020-02-20) #meetingname infrastructure #chair nirik pingou relrod smooge tflink cverna mizdebsk mkonecny abompard bowlofeggs #info Agenda is at: https://board.net/p/fedora-infra #topic aloha ``` ### Determine who the next chair is #topic Next chair #info magic eight ball says: #info 2020-02-20 - bowlofeggs #info 2020-02-27 - ??? ### Let new people say hello ``` #topic New folks introductions #info This is a place where people who are interested in Fedora Infrastructure can introduce themselves #info Getting Started Guide: https://fedoraproject.org/wiki/Infrastructure/GettingStarted ``` ### Status / Information / Trivia / Announcements (We put things here we want others on the team to know, but don't need to discuss) (Please use ```#info (the thing - your name)``` ``` #topic announcements and information #info ops folks are trying a 30min ticket triage every day at 19UTC in #fedora-admin #info Fedora Infrastructure will be moving in 2020-06 from its Phoenix Az datacenter to one near Herndon Va. A lot of planning will be involved on this. Please watch out for announcements on changes. #info Old openstack cloud is being decommissioned 2020-03-01. Working with instance owners to make sure everyone is migrated off. #info New blog post about release-monitoring.org is now out https://communityblog.fedoraproject.org/stories-from-the-amazing-world-of-release-monitoring-org-9/ ``` ### Things we should discuss We use this section to bring up discussion topics. Things we want to talk about as a group and come up with some consensus /suor decision or just brainstorm a problem or issue. If there are none of these we skip this section. (Use ```#topic your discussion topic - your username)``` ``` #topic Oncall #info https://fedoraproject.org/wiki/Infrastructure/Oncall #info nirik is oncall 2020-02-13 -> 2020-02-20 #info cverna is oncall 2020-02-20 -> 2020-02-27 #info pingou is oncall 2020-02-28 -> 2020-03-05 ## .oncalltakeeu .oncalltakeus #info Summary of last week: (from current oncall ) #info #topic Monitoring discussion [nirik] #info https://nagios.fedoraproject.org/nagios #info Go over existing out items and fix #topic Tickets discussion [nirik] #info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket #topic backlog discussion #info go over our backlog and discuss and determine priority ``` Go thru each ticket one by one ### Put all topics for discussion under here Here we will discuss any apprentice questions, try and match up people looking for things to do with things to do, progress, testing anything like that. ### Learn about some application or setup in infrastructure (This section, each week we get 1 person to talk about an application or setup that we have. Just going over what it is, how to contribute, ideas for improvement, etc. Whoever would like to do this, just add the i/nfo in this section. In the event we don't find someone to teach about something, we skip this section and just move on to open floor.) ``` #info ``` ### Meeting end stuff ``` #topic Open Floor #endmeeting ___ 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
Meeting agenda 2020-01-23 15:00 UTC
The infrastructure team will be having its weekly meeting tomorrow, 2020-01-23 at 15:00 UTC in #fedora-meeting-1 on the freenode network. We have a document at https://board.net/p/fedora-infra Please try and review and edit that document before the meeting and we will use it to have our agenda of things to discuss. A copy as of today is included in this email. If you have something to discuss, add the topic to the discussion area with your name. If you would like to teach other folks about some application or setup in our infrastructure, please add that topic and your name to the learn about section. signature.asc Description: This is a digitally signed message part ___ 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: The packages app has a short runway
On Fri, 2019-10-25 at 15:50 -0400, Neal Gompa wrote: > a lot of Fedora-specific information isn't > present. Though true for the entire packages app, I think this site does do the one use case I described at a quick glance. signature.asc Description: This is a digitally signed message part ___ 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: The packages app has a short runway
On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote: > It's not a bad feature to have in fedpkg, but it fundamentally does > not help *other people* discover what we have in the distribution. Yeah I've discussed this a bit with some people, and I agree. Fedora *users* might use the packages app to find out the same info that packagers want to find out. However, I think that even though users and packagers are coming to this app for the same purpose, only one of those purposes maps to the CPE team's mission statement: the packager's. If you are a packager, you *need* to know what versions are where at a glance, especially when dealing with something high priority like a CVE. That's not to say that the end-user story isn't a valuable use case, but our team is overburdened and we need to drop most of what we do right now, and we have to be specific about what our purpose is. This means dropping some valuable use cases. Of course, this is also my own opinion, and I welcome disagreement. signature.asc Description: This is a digitally signed message part ___ 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: The packages app has a short runway
On Fri, 2019-10-25 at 21:00 +0200, Mikolaj Izdebski wrote: > I am planning to deploy Package Version Matrix in communishift [1]. > Example how it can look like: [2] > > [1] https://pagure.io/fedora-infrastructure/issue/8314 > [2] https://koji.kjnet.xyz/kojifiles/versions/ Oh that could be a good replacement. Does it support searching, or displaying a particular package rather than the full set (since there are a lot of packages in all of Fedora)? If not, it's probably not hard to add. signature.asc Description: This is a digitally signed message part ___ 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: The packages app has a short runway
On Fri, 2019-10-25 at 21:47 +0200, Clement Verna wrote: > https://pkgs.org/ might be a good replacement for that. Does anybody > have used or is using this website ? Any feedback on it ? I haven't seen this before, but if it does a good job staying up to date then it seems like a good replacement to me, and someone else already did it and even hosts it. Nice. signature.asc Description: This is a digitally signed message part ___ 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: The packages app has a short runway
On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote: > The packages app (https://apps.fedoraproject.org/packages/) was > originally running on RHEL6, I tried to move it to RHEL 7 but they > were some dependencies missing there so we decided to move it to > Fedora. I don't remember which dependencies were missing tho. One of > the pain point is that the frontend is rendered using moksha/tosca > widgets (http://toscawidgets.org/) and this is pretty much a dead > upstream project. Removing these dependencies is not going to be > trivial. OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app. However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL. I think we should do *something* to continue to provide that particular feature to packagers. I have a proposal: What if we make a fedpkg subcommand that prints that table? I think it could get all the needed data by querying Koji. I suggest this instead of a webapp or service, because webapps and services increase the burden on the CPE team, and also because creating an entire application just to print a table is a lot of boilerplate. Adding it to fedpkg feels clean to me, because it seems like a sensible place for such a feature to exist, and because it *should* be simple and easy. Simple is good! I may be able to find the time to make this happen before April too. Thoughts? signature.asc Description: This is a digitally signed message part ___ 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: ansible-report git hook design
On Fri, 2019-10-25 at 19:04 +0200, Clement Verna wrote: > I think the main reason why we don't already have it on Pagure is > that we don't want to be dependent of our own infrastructure to host > this repo. It currently lives on the batcave01 host which is the box > we use to deploy our infrastructure. So to me if we are going to host > this repository on a git forge I think using an external service > would make sense. +1 > Of course we would then be dependent on a third party Well, since git itself is a distributed scm, we aren't really dependent. I bet there are many many copies of the Ansible repo on all of our laptops (I have it on my laptop and on a local repospanner forge in my house right now!). So even if we had it on Git* and that thing went down, we still have like a hundred other copies of it. > I think that the % of availability of GitHub or GitLab is much higher > than ours, they have dedicated teams working on making sure their > service is available when we struggle to keep all our infra running. > Also their main business and expertise is to run a git forge service, > they have the infrastructure and the hardware for that, while our > main business is to build and release a Linux distribution (A really > good one :-) +1 > After I am not really interested in a long debate in regards of where > that repo should be hosted, to me what matters is that we should have > the Fedora Community in only one place be it GitLab like the Gnome > community or GitHub where we already have fedora-infra, fedora-cloud, > fedora CoreOS. Yeah GitHub and GitLab are both great. signature.asc Description: This is a digitally signed message part ___ 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
The packages app has a short runway
Greetings! The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it. This means it has about 7 months before we need to do something about it, or shut it off. Do we know if it can run on RHEL 7? signature.asc Description: This is a digitally signed message part ___ 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: Big Freeze Break Request: replicate db-koji01
On Mon, 2019-10-21 at 11:48 -0700, Kevin Fenzi wrote: > Personally, I am willing to try 1 (will need more +1's for freeze > break), I don't really like 2 and 3 seems a bit scary, but I guess it > could be ok until after freeze. > > Thoughts? I think #1 is fine, and we could even bump it to a very long time. The goal is to get a consistent *historical* snapshot, and it sounds like the DB is trying to get us a consistent *current* snapshot. As long as we can get the consistent snapshot for the backup, it's OK if the replica lags production by minutes or even hours, as long as it can also recover. I think tuning it for that use case is sensible. signature.asc Description: This is a digitally signed message part ___ 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 1/1] Enable new mirrorlist server on proxy14
On Fri, 2019-10-18 at 09:13 +0200, Adrian Reber wrote: > Thanks for that recommendation. Can you point me to a place in > ansible > where you are using this? For this FBR I would rather not change it > and > go with the current solution. The goal is to completely remove the > conditionals because it either works (everything uses the new > approach) > or it does not work at all (keep on using the current approach). If > we > would actually go the way to slowly switch more proxies one after > another I would change the conditionals to how you described it. For > now > I would rather try it the way I currently have it. Hey Adrian! I am not sure that I have used the technique I describe in this Ansible project, but I have been using it in some other Ansible projects I work on. Unfortunately, none are public at the moment. Sure, I'm not opposed to the patch as-is, just a suggestion for improvement. signature.asc Description: This is a digitally signed message part ___ 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: Big Freeze Break Request: replicate db-koji01
I'm a +1 to doing this. The change to production is not too huge, so I think it's low risk. As I've said elsewhere, I've used this technique to do backups and analytics before to avoid putting load on production and it worked well. I personally think going without backups is a higher risk than the changes to production. Maybe it's a lower chance of failure, but I say higher risk because the consequence of not having backups when you need them is greater than the consequence of needing to roll back the config changes if something goes wrong. signature.asc Description: This is a digitally signed message part ___ 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 1/1] Enable new mirrorlist server on proxy14
On Wed, 2019-10-16 at 10:50 +0200, Adrian Reber wrote:
> {% if env == "staging" or inventory_hostname ==
> "proxy14.fedoraproject.org" %}
Rather than inlining host names like this, why not use host vars to
define a boolean variable like "enable_cool_new_rust_mirrorlist". Then
you can make that true in staging, true on proxy 14, and false
everywhere else and make this if statement simpler and more "permanent"
(i.e., you don't to touch this or the other two places with similar
adjustments later when you want to add the other proxies.
I'm guilty of doing the above in my Ansible too, but recently I've been
thinking that it would be better to use the host and group vars
instead. And honestly this is pretty similar to what a lot of our
playbook does, so I am not opposed.
Anyways, I'm +1 to the change as-is, but would prefer a change that
uses vars over this one, if you are so inclined.
signature.asc
Description: This is a digitally signed message part
___
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 0/1] Enable new mirrorlist server on proxy14
On Wed, 2019-10-16 at 14:58 -0400, Stephen John Smoogen wrote: > This was requested by me as we usually get a spike of traffic in the > 8 > days after a release compared to the rest of the time. This would > mean > we would not be able to test the code's viability against load until > May when we are in the middle of move issues. I felt getting this > tested now in RL on 1 node we can take out of circulation if needed > versus 12->14 nodes in May. > > Does that make sense? Yeah, especially with the thought about May. signature.asc Description: This is a digitally signed message part ___ 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: repoSpanner sprint report
Greetings! On Mon, 2019-10-14 at 21:05 +0300, Benson Muite wrote: > The tool seems useful. I wish there was a high level description of > the design. Seems like many issues are common with distributed nosql > databases. Are there any common techniques one can use to have good > performance? We should expand the project's documentation. The performance issues I have identified as being most significant in repoSpanner are unique to repoSpanner, so at the moment I don't think we're quite at the point of having similar issues to nosql databases in terms of performance. Perhaps we will once we've removed the current bottlenecks. > Is the typical use case in a single data center or for repositories > across multiple data centers? The intention of the project is to allow it to be used in geographically diverse datacenters. In particular, we plan to use this to bring the CentOS and Fedora dist-git projects together into a single git forge. CentOS is already using it, and that deployment is currently in three different datacenters in the United States (Phoenix, Raleigh, and Chapel Hill). signature.asc Description: This is a digitally signed message part ___ 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
repoSpanner sprint report
Greetings ya'll, I spent the last few weeks studying repoSpanner with the goal of developing a plan to improve its performance. I started by testing its performance with a few common git operations with a couple repos (our Infrastructure Ansible repository since it is on the large side, and Bodhi since I had it cloned already and is perhaps a "typical" medium sized project). I wrote an initial report about those tests here[0]. Since the time of that report, I have done some performance profiling on the git push for the Bodhi repository, since that by far was the slowest operation that I tested[1]. I found that the most significant time was spent interacting with sqlite. sqlite is used today by repoSpanner as a task queue. There are two different workflows. The first is that it creates a table per repoSpanner node, and each row of the table represents a git object ID that needs to be pushed to that node. The second is that there is another table that tracks each object ID along with how many nodes that particular object ID has been successfully pushed to. Early on in my sprint, I was able to find an easy way to gain a speed boost - I found that the query to retrieve a node table's object ID was being called once per node per object ID, resulting in very large numbers of read queries (as an example, the Bodhi repo has 40k objects, so if I had a 3 node cluster, this would result in 80k SELECT statements, since there will be tables to sync those objects to the other two nodes). It was relatively easy to refactor the code to retrieve a group of object IDs per query and get a quick win. I posted up a pull request with a patch that does this that achieved a 51% boost on pushing Bodhi into repoSpanner[2]. After achieving that gain, I attempted to continue down a similar path as the next significant block seemed to be the code that wrote the data into that table. However, it quickly became clear that it was a more significant refactor to alter the writing code to batch insert than it had been to alter the reading code to batch select. If I was going to have to do a larger refactor, it became clear that it would be worth exploring designs that avoid or reduce the use of sqlite. I had reached a "local minima", so to speak. I had a few calls with Patrick Uiterwijk, and it turned out that he had also been thinking about ways to solve this problem, and he was in favor of removing sqlite from the project. He gave me the background on why sqlite had been used in the first place[3], and suggested that we could create a file backed go chan to achieve similar goals with higher performance. Last week I put together a prototype of the "file backed chan" that he and I designed together and I also refactored the repoSpanner code to use the new chan. This is very much prototype and not at all pull request worthy code (at the time of writing, it contains a git commit with the message "Test", if that tells you anything), so please be forgiving of its messy state, but for those who are curious, you can see what I've been experimenting with at [4]. I've found that I am able to push the Bodhi repository into repoSpanner in about 25 minutes with that patch, where it took about 58 minutes before. This is approximately a 57% speed improvement, which is a little bit better than the 51% speed improvement of the other patch. There is still one remaining use of sqlite - the table that records how many nodes that each object has been synced to. This is now the largest bottleneck in repoSpanner push performance and is the next obvious thing to eliminate. I've talked to Patrick about some ideas around this, and we are considering eliminating the feature of tracking each object individually and instead tracking the entire operation - i.e., consider a push successful only if all objects made it together to the same majority of nodes. This is in contrast to today's feature, where each object is considered individually successfully pushed if it made it to a majority of nodes - i.e., it allows the objects not to have to make it to the *same* majority of nodes. If we eliminate that feature, we no longer have to perform individual tracking of which git objects made it to which nodes and we can eliminate sqlite entirely. I expect this will make the most significant difference to the performance of git push, though it is difficult to estimate how much of a difference it will make without prototyping it. Another area that is known to be problematic is the speed of a git pull. Today repoSpanner builds gitpack files for the repo every time it is pulled. I haven't done very much profiling here, but Patrick has suggested caching git pack files to help in this area. I think it's an area we should focus on improving in the future. As for the immediate future, I plan to clean up my patches for the sqlite changes I have been experimenting with this week so I can propose them in a pull request. They will supercede my existing pull request, so I plan
Re: New docs project: Onboarding the community to Communishift
On Tue, 2019-09-24 at 16:55 -0400, Randy Barlow wrote: > On Tue, 2019-09-24 at 15:20 +0200, Petr Bokoc wrote: > > Sure! You guys are the experts and you know all about what people > > need to do and how to do it, so it's best if you do most of the > > actual content writing; I'm happy to help you with markup, > > structure > > and that sort of stuff. Some basic info about how the docs site > > works > > is in the template repo README: > > https://pagure.io/fedora-docs/template > > > > Once we have something publishable I'll add it to the site and link > > it from https://docs.fedoraproject.org/en-US/engineering/ > > Great! > > Do you have a suggestion for a particular git repository to be used > for > this, or should we start a new git repository just for these docs? Or do you recommend using the repo that pingou suggested: https://pagure.io/infra-docs-fpo signature.asc Description: This is a digitally signed message part ___ 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: New docs project: Onboarding the community to Communishift
On Tue, 2019-09-24 at 15:20 +0200, Petr Bokoc wrote: > Sure! You guys are the experts and you know all about what people > need to do and how to do it, so it's best if you do most of the > actual content writing; I'm happy to help you with markup, structure > and that sort of stuff. Some basic info about how the docs site works > is in the template repo README: > https://pagure.io/fedora-docs/template > > Once we have something publishable I'll add it to the site and link > it from https://docs.fedoraproject.org/en-US/engineering/ Great! Do you have a suggestion for a particular git repository to be used for this, or should we start a new git repository just for these docs? signature.asc Description: This is a digitally signed message part ___ 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
New docs project: Onboarding the community to Communishift
Hey Kevin and Petr (and anyone else on the list who is interested), I've been talking with Ben Cotton about moving the elections application into Communishift[0]. We had a few back and forth e-mails, and it became clear that it would be helpful if we had quality documentation describing how community members can use Communishift. I think there may need to be a balance between documenting how to use OpenShift, and linking to already existing resources regarding the use of OpenShift. Perhaps some simple hello world type examples would be good to document, but it would probably be best to link to official OpenShift documentation for details on how to use OpenShift. On the other hand, there are likely to be some particularities with how we have deployed/configured Communishift that should be documented. Since we are hoping to hand off several infrastructure applications to the community, there may be some common patterns among those apps that would be good to document as well. It would also be good to document best practices suggestions for some common problems our users will need to solve: * How can they use persistent storage? * How can they use a database? * How can they back up the applications, persistent storage, and database? We do have a wiki page[1] for Communishift already that we can use as a starting point, but we probably want to move it to our documentation project as we extend it. Let me know if you are interested in participating in this project. [0] Communishift is an OpenShift instance hosted by Fedora Infrastructure for the community to use to host applications for Fedora. Fedora Infrastructure does not maintain or administrate any applications in Communishift, but rather administers the OpenShift deployment itself. [1] https://fedoraproject.org/wiki/Infrastructure/Communishift signature.asc Description: This is a digitally signed message part ___ 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: Agenda for Thursday's meeting
Here are the meeting minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-19/infrastructure.2019-09-19-15.00.html signature.asc Description: This is a digitally signed message part ___ 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: repospanner and our Ansible repo
On Tue, 2019-09-17 at 19:01 -0400, Neal Gompa wrote: > Out of curiosity, do we know where the bottlenecks are in > repoSpanner? > In theory, the architecture of repoSpanner isn't supposed to be too > different from gitaly, so I'm curious where we're falling down. I believe it needs a more efficient way to store the git objects. As I understand it, it currently stores each one in its own file, resulting in a large number of small files. signature.asc Description: This is a digitally signed message part ___ 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: repospanner and our Ansible repo
stickster asked me today how these numbers would compare to
Git{Hub,Lab}. I did a bit of testing with GitLab just now.
Note that this isn't a particularly apples to apples test, because my
repospanner nodes were on the same virtual host, and my git client was
on a 1 Gbps LAN with them. My GitLab test results are from my house,
where I only have a 60x6 Mbps connection to the Internet, and of
course, higher latency.
I considered testing from batcave01 to get higher bandwidth, but I
didn't want to try to figure out a safe way to use my GitLab
credentials on a shared server and I didn't want to make a throw away
account just to test this.
On Mon, 2019-09-16 at 18:51 -0400, Randy Barlow wrote:
> I pushed the Ansible repository into it. This took a very long time:
> 298m2.157s!
This took 6m44.705s to get to GitLab. However, since I only have 6 Mbps
outbound and the repository is 268.43 MiB, I calculate that almost all
of this time was just due to waiting on my outbound pipe.
> The next test was to see how long it takes to clone our repo. I did
> this on another machine on the same LAN (so again, ideal network
> latency) and it took 2m27.433s.
This took 0m40.359s, and again, almost all of the time was just due to
how long it would take to send that much data over a 60 Mpbs link.
> Next, I made a small commit (just added/deleted some lines) and
> pushed
> it into the cluster. This went reasonably quick at 0.366s, which I
> think we would be OK with.
This took 1.443s to GitLab, and I bet most of it was just latency/round
trip crypto setup time.
> The last test I performed was to see how quickly another checkout
> could
> pull that commit, and this was again a speed I might consider to be a
> bit slow at 4.931s, especially considering that the commit was small
> and was only one.
This took 0m1.523s to GitLab, and I bet most of it was just
latency/round trip crypto setup time.
I don't expect it would be useful to perform this test with GitHub
since I'd expect essentially the same results (bottlenecked on my home
internet connection).
signature.asc
Description: This is a digitally signed message part
___
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
Agenda for Thursday's meeting
nirik suggested trying out board.net for the weekly meeting agenda, so I created a meeting agenda there: https://board.net/p/fedora-infra Feel free to add your own material to the agenda. Here is what it looks like at the time of this writing: --- title: Infrastructure Meeting template tags: Fedora, Infra, CPE --- # Infrastructure Meeting Send on IRC a day before meeting (#fedora-noc #fedora-admin #fedora-releng #fedora-apps) ``` REMINDER: There will be a Fedora Infrastructure meeting tomorrow (2019-09-19) at 15:00 UTC in #fedora-meeting-1. Please check the agenda at https://board.net/p/fedora-infra and mail updates to sysadmin-main members. ``` On the day of the meeting send the following ``` REMINDER: There will be a Fedora Infrastructure meeting today (2019-09-19) at 15:00 UTC in #fedora-meeting-1. Please check the agenda at https://board.net/p/fedora-infra and mail updates to sysadmin-main members. ``` ## Preamble The infrastructure team will be having its weekly meeting tomorrow, 2019-09-19 at 15:00 UTC in #fedora-meeting-1 on the freenode network. We have a document at https://board.net/p/fedora-infra Please try and review and edit that document before the meeting and we will use it to have our agenda of things to discuss. A copy as of today is included in this email. If you have something to discuss, add the topic to the discussion area with your name. If you would like to teach other folks about some application or setup in our infrastructure, please add that topic and your name to the learn about section. ## Introduction We will use it over the week before the meeting to gather status and info and discussion items and so forth, then use it in the irc meeting to transfer information to the meetbot logs. ### Meeting start stuff ``` #startmeeting Infrastructure (2019-09-19) #meetingname infrastructure #topic aloha #chair nirik pingou puiterwijk relrod smooge tflink cverna mizdebsk mkonecny abompard bowlofeggs ``` ### Let new people say hello ``` #topic New folks introductions #info This is a place where people who are interested in Fedora Infrastructure can introduce themselves #info Getting Started Guide: https://fedoraproject.org/wiki/Infrastructure/GettingStarted ``` ### Status / Information / Trivia / Announcements (We put things here we want others on the team to know, but don't need to discuss) (Please use ```#info (the thing - your name)``` ``` #topic announcements and information #info We are looking for people to maintain Fedocal and Nuancier - mkonecny ``` ### Things we should discuss We use this section to bring up discussion topics. Things we want to talk about as a group and come up with some consensus /suor decision or just brainstorm a problem or issue. If there are none of these we skip this section. (Use ```#topic your discussion topic - your username)``` ``` #topic Oncall #info https://fedoraproject.org/wiki/Infrastructure/Oncall #info Summary of last week: (from relrod ) #topic Monitoring discussion #info https://nagios.fedoraproject.org/nagios #info Go over existing out items and fix #topic Tickets discussion #info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket ``` Go thru each ticket one by one ### Put all topics for discussion under here ``` #topic Where to put these docs in the future? #info infinote is going away #info a new central doc place would be good. can someone set this up? ``` Here we will discuss any apprentice questions, try and match up people looking for things to do with things to do, progress, testing anything like that. ### Learn about some application or setup in infrastructure (This section, each week we get 1 person to talk about an application or setup that we have. Just going over what it is, how to contribute, ideas for improvement, etc. Whoever would like to do this, just add the i/nfo in this section. In the event we don't find someone to teach about something, we skip this section and just move on to open floor.) ``` #info ``` ### Meeting end stuff ``` #topic Open Floor #endmeeting ``` signature.asc Description: This is a digitally signed message part ___ 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
+1 signature.asc Description: This is a digitally signed message part ___ 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
repospanner and our Ansible repo
Greetings! Kevin asked me last week whether we are ready to move our infrastructure Ansible repository into repospanner. The benefit of moving it into repospanner is that it is one way to enable us to allow pull requests into the repository, which I think would be nice. repospanner seems to work correctly as a git server, but it does need improvements in its performance, so I offered to do a little benchmarking with our Ansible repo and repospanner to see what kind of performance we might see. I deployed a 3-node repospanner cluster today on fairly high performance hardware (SSD storage). It was three VMs on the same physical machine. Note that due to my test setup, network latency was about as good as it could get, and so was storage iops. I believe the performance bottlenecks will depend heavily on storage iops. Thus, this hardware is not really a great way to predict how the performance might be if we deployed into our infra, but it was easy for me to do and get a "best case" performance benchmark. I am willing to attempt to replicate this test on more realistic hardware in our infra if we want more realistic data for our own use case. I pushed the Ansible repository into it. This took a very long time: 298m2.157s! If we were to deploy nodes in different geos and use NAS storage, I believe this would take longer. The good thing is that we'd only need to do this operation once, if we were to decide to proceed. The next test was to see how long it takes to clone our repo. I did this on another machine on the same LAN (so again, ideal network latency) and it took 2m27.433s. That's a pretty long time too I'd say, but maybe liveable? This would impact every contributor who wanted to clone us, so I'll let the list debate whether that is acceptable. Next, I made a small commit (just added/deleted some lines) and pushed it into the cluster. This went reasonably quick at 0.366s, which I think we would be OK with. The last test I performed was to see how quickly another checkout could pull that commit, and this was again a speed I might consider to be a bit slow at 4.931s, especially considering that the commit was small and was only one. I would expect this to be somewhat proportional to the amount of change that has happened since the user last fetched, and this repo does see a lot of activity. So I might expect git pull to take 10's of seconds for contributors who are fairly active and pull once every few days or so, and maybe longer for users who pull less frequently. The repo copy I tested with has 199717 objects and 132918 deltas in it. repospanner performance seems to be fairly proportionally correlated with these numbers, as the bodhi repo pushed into it in about an hour and has 50kish objects, iirc (didn't write it down, so from memory). I personally am on the fence about whether we should proceed at this time. I am certain that people will notice the speed issues, and I also expect that it will be slower than the numbers I listed above since my tests were done on consumer hardware. But it would also be pretty sweet if we had pull requests on the repo. Improving repospanner's performance is a goal I am focusing on, so if we deployed it now I would hopefully be able to get it into better shape soon. Alternatively, we hopefully wouldn't have to wait that long if we wanted to wait for performance fixes before proceeding. I could see either decision being reasonable. To reiterate, I'd be willing to replicate the tests I did above on infra hardware if we are on the fence about the numbers I've reported here and want to see more realistic numbers to make a final decision. I think that would give us more realistic numbers since the tests I did here were on a much more ideal situation, performance wise. What do others think? signature.asc Description: This is a digitally signed message part ___ 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] bodhi-backend / pungi: drop i386 trees for f31+
+1 signature.asc Description: This is a digitally signed message part ___ 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] bodhi-backend / pungi: drop i386 trees for f31+
+1 signature.asc Description: This is a digitally signed message part ___ 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] basessh: Always run the keygen shell command if needed, even in check mode.
+1 signature.asc Description: This is a digitally signed message part ___ 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] loopabull: add rhosp13 repo to install newer rabbitmq.
+1 signature.asc Description: This is a digitally signed message part ___ 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: add f31/f32 infra tags and f31-gnome side tag to be signed.
+1 signature.asc Description: This is a digitally signed message part ___ 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: Relaxing the AMQP broker permissions for authenticated users
On Tue, 2019-06-18 at 14:06 +, Jeremy Cline wrote: > the problems we hit were things like not knowing you had to add some > extra Ansible steps to create your queue in the first place (and then > asking the obvious question of why you have to repeat yourself in the > config in Ansible and then separate roles), accidentally delegating > the > creation of the queue (but not the user) to the production broker > instead of the staging broker, forgetting to set passive_declares = > true, and so on. Every single one of these issues happened to me too, and I also had to interrupt jcline to get help. I don't think the permissions model we are using is actually preventing a real problem, but it certainly is causing one. signature.asc Description: This is a digitally signed message part ___ 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: I am no longer watching the infra repo
On Mon, 2019-06-17 at 14:02 -0700, Kevin Fenzi wrote: > Can you clarify what repo you mean here? > https://pagure.io/fedora-infrastructure/issues ? > Or ? Yep, that's the one! The Pagure bug has made it hard to follow that repo even during normal working schedule, as there are a lot of issues filed that I cannot do anything about. But I usually do watch it because there's no other way to know if people @bowlofeggs me. However, I know I can't look at 9 weeks of e-mails from it in case someone mentioned me, so I'm just sending a heads up that you can't mention me there. signature.asc Description: This is a digitally signed message part ___ 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
I am no longer watching the infra repo
Notice: I am no longer watching the infrastructure repo, because it results in a huge volume of mail most of which is not relevant to me, and I am about to take an extended leave of absence and don't want to return to thousands of e-mails. However, due to a long-standing Pagure bug[0], this means that mentioning me with @bowlofeggs will also not result in an e-mail, nor will assigning an issue to me. Thus, if you need my attention on something, you should contact me via some other means. I plan to watch the repo again once my extended leave ends. [0] https://pagure.io/pagure/issue/2324 signature.asc Description: This is a digitally signed message part ___ 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
Bodhi stakeholder's meeting
There will be a Bodhi stakeholder's meeting on June 26 at 15:00 UTC in #fedora-meeting on Freenode. https://apps.fedoraproject.org/calendar/infrastructure/2019/6/24/#m9545 signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 4.0.0 deployed, one known issue so far
On Wed, 2019-05-29 at 11:58 -0400, Josh Boyer wrote: > Could you make a container image based on F30 that can be run on > F29/EPEL 7/8? That offers users a way to use the new tool on the OS > of their choice and avoids you having to write new code or bring back > a bunch of dependencies to the Fedora release itself. Yeah anyone could easily do this (just a FROM line [note: it's in Rawhide, not F30] and a RUN dnf install line), but there are also dependencies on bodhi-client in EPEL 7 and F29/30 so it wouldn't fully address the issue. Any end user who wants to work around it could do this though, and I have also provided a Copr[0] that has the new Bodhi client that you can use too. I also considered modularity, but there's currently a stay on adding new packages to the default stream since RPMs can't currently depend on modules (and things do depend on Bodhi). Miro and I have proposed on the FESCo ticket to create a bodhi3-client package and upgrade F29/30 to Bodhi 4. [0] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 4.0.0 deployed, one known issue so far
On Tue, 2019-05-28 at 20:22 -0600, Orion Poplawski wrote: > Perhaps this is the source of: > > # /etc/cron.hourly/0yum-hourly.cron > Updateinfo file is not valid XML: '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1 > 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', > mode 'rt' at 0x7fa11cc331e0> > > https://pagure.io/releng/issue/8392 I am working on a bodhi-4.0.1 release today to address this particular issue. signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 4.0.0 deployed, one known issue so far
On Tue, 2019-05-28 at 17:41 -0400, Dan Čermák wrote: > I just tried to submit an update via `fedpkg update` but got a > failure > via the cli: > $ fedpkg update > Could not execute update: Could not generate update request: > 'anonymous' > A copy of the filled in template is saved as bodhi.template.last > > Nevertheless the update got submitted and is available on Bodhi (it's > this one: > https://bodhi.fedoraproject.org/updates/FEDORA-2019-16433c312e). Hi Dan! I presume you are using a Bodhi 2 or 3 client there? This is a known compatibility issue between the Bodhi 3 client and the Bodhi 4 server: https://bugzilla.redhat.com/show_bug.cgi?id=1714950 There's a FESCo ticket where we are discussing what to do about it. I'm kind of undecided between putting Bodhi 4 into Fedora 29+ (and maybe even EPEL 7, which may be tricky due to dependencies) and making a Bodhi 3.15 that can talk to Bodhi 4 server (downside is that this will require more effort on my part, and I have a lot on my plate ☹). Feel free to voice your opinions on the FESCo ticket! signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 4.0.0 deployed, one known issue so far
On Tue, 2019-05-28 at 20:22 -0600, Orion Poplawski wrote: > Perhaps this is the source of: > > # /etc/cron.hourly/0yum-hourly.cron > Updateinfo file is not valid XML: '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1 > 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', > mode 'rt' at 0x7fa11cc331e0> > > https://pagure.io/releng/issue/8392 Yeah, that's a possibility since this version of Bodhi introduced zchunked updateinfo files. Maybe jdieter can shed some light on it for us in the ticket. signature.asc Description: This is a digitally signed message part ___ 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
Bodhi 4.0.0 deployed, one known issue so far
Greetings! I have just deployed Bodhi 4.0.0 to production: https://bodhi.fedoraproject.org/docs/user/release_notes.html One known issue has been found[0] so far: after creating an update, your browser will be redirected to a URL that does not exist. The update was created, however, and you should receive an e-mail with the URL to it (and can also see it on your user page in Bodhi). Let me know if you find any other problems! [0] https://github.com/fedora-infra/bodhi/issues/3248 signature.asc Description: This is a digitally signed message part ___ 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-backend: Make sure zchunk dicts are installed
On Thu, 2019-05-23 at 22:07 +0100, Jonathan Dieter wrote: > Unless I'm mistaken, that patch is specific to updateinfo.xml. The > other metadata in updates and updates-testing is currently zchunked, > just without a zdict at the moment. Ah yes, that's correct! signature.asc Description: This is a digitally signed message part ___ 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-backend: Make sure zchunk dicts are installed
On Thu, 2019-05-23 at 10:33 -0700, Kevin Fenzi wrote: > Applied. Thanks. One note: The patch to do zchunking is part of Bodhi 4.0.0, which is not yet in production; we plan to deploy it on Tuesday. signature.asc Description: This is a digitally signed message part ___ 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
Bodhi 4.0.0 beta deployed to staging
Greetings! Back in December, I sent out a threat^Wannouncement that I would be making a lot of backwards incompatible changes to Bodhi in an upcoming 4.0.0 release[0]. I didn't expect it to take this long at the time, but five months later we finally have a beta built[1] and deployed to staging[2]. Please peruse the release notes[3] to make sure you are familiar with how these changes might impact you, particularly if you integrate programmatically with Bodhi. One notable change I will highlight is that Bodhi's masher fedmsg topics have all changed to use the word "compose" instead of "mash". Also, Bodhi has stopped using fedmsg and uses the new (and fantastic, I might add) fedora-messaging library, and as a result you can try out Bodhi's new bodhi.messages Python library if you are receiving Bodhi's messages in Python - it's a much more convenient way to access Bodhi's messages from Python. Bodhi now also has documented schemas for the messages it sends[4]. [0] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/AC4HNMU2OD7K7OJVBLMIDNJXZI355G72/#BGPNKYRL7H62U3QXOQPWMVCT2LOZ2W5K [1] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi-pre-release [2] https://bodhi.stg.fedoraproject.org/ [3] https://bodhi.stg.fedoraproject.org/docs/user/release_notes.html [4] https://bodhi.stg.fedoraproject.org/docs/server_api/index.html#message-api signature.asc Description: This is a digitally signed message part ___ 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: Backwards incompatible updates to Fedora 29
On Mon, 2019-04-29 at 14:49 -0700, Adam Williamson wrote: > I also find it significant that libdnf still has, so far as I can > tell, > absolutely no interface documentation - > https://github.com/rpm-software-management/libdnf links to "the > hawkey > documentation page", which is obviously wildly outdated at this point > - > and that this API-breaking change was not even mentioned in the > libdnf > release notes: > https://github.com/rpm-software-management/libdnf/blob/master/docs/release_notes.rst I filed issues about this: https://github.com/rpm-software-management/libdnf/issues/719 https://github.com/rpm-software-management/libdnf/issues/720 signature.asc Description: This is a digitally signed message part ___ 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: Backwards incompatible updates to Fedora 29
On Mon, 2019-04-29 at 21:46 +0200, Daniel Mach wrote: > I'll discuss the issue with my team and we will reach back to > you with a solution soon. Thanks Daniel! signature.asc Description: This is a digitally signed message part ___ 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: Backwards incompatible updates to Fedora 29
Also, I cannot find documentation on the new version of hawkey as distributed with libdnf. Since the change is in Rawhide, I will need to adjust Bodhi's code[0] so that it works with the new version of hawkey. Can you advise me about what I should use in place of the cited code with the new version of hawkey? [0] https://github.com/fedora-infra/bodhi/blob/cb07ce2c82385a186245f1c6dbef0c2f2566f0e2/bodhi/server/util.py#L274 signature.asc Description: This is a digitally signed message part ___ 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
Backwards incompatible updates to Fedora 29
Hi Pavla, I noticed today that a backwards incompatible update was pushed to Fedora 29 stable for libdnf[0]. This breaks Bodhi[1], which uses hawkey.Repo which was removed in that version. The update notes did not mention a backwards incompatible API, and in general backwards incompatible updates should not be pushed to stable Fedora versions[2]. This causes problems for Fedora users who may be using your library, but it also causes issues in this case for the Fedora Infrastructure team[3]. Please do not push backwards incompatible updates in the future. That said, we now need to take some action to solve the problem. Ideally, we would revert the libdnf in Fedora 29 since that update should not have happened. I also noticed the Fedora 30 does not have this version of libdnf (so, Fedora 29 has the backwards incompatible change, but Fedora 30 does not.) This means that users upgrading from Fedora 28 to Fedora 31 will experience 3 backwards breaking changes, instead of just one (which should happen in Fedora 31 only). Can we revert this change? [0] https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba [1] https://github.com/fedora-infra/bodhi/issues/3193 [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases [3] https://pagure.io/fedora-infrastructure/issue/7748 signature.asc Description: This is a digitally signed message part ___ 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: Add knowledge of branch freezes to the Release model
On Tue, 2019-04-16 at 15:35 +0200, Sebastian Wojciechowski wrote: > The initial plan was to just add some argument to cli "bodhi releases > create/edit", something like: > > >> bodhi releases edit --name F29 --frozen true) Releases have states - it might be nice to just reuse that machinery since we already have code to edit those. signature.asc Description: This is a digitally signed message part ___ 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: Manually unlock FEDORA-CONTAINER-2019-3e42a55b54
This change is in place now. signature.asc Description: This is a digitally signed message part ___ 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: Manually unlock FEDORA-CONTAINER-2019-3e42a55b54
FEDORA-CONTAINER-2019-3e42a55b54[0] references a container that has been deleted from the candidate registry. As a result, the compose has failed. Since the update is locked, it cannot be edited to replace it with a build that exists. To fix this, I propose to unlock the update like this: $ sudo -u apache bodhi-shell 2019-04-02 15:24:43,617 INFO [bodhi.server][MainThread] Bodhi ready and at your service! Python 3.7.2 (default, Mar 21 2019, 10:09:12) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux Type "help" for more information. Environment: app The WSGI application. registry Active Pyramid registry. request Active request object. root Root of the default resource tree. root_factory Default root factory used to create `root`. Custom Variables: mbodhi.server.models sbodhi.server.Session >>> u = m.Update.query.filter_by(alias='FEDORA-CONTAINER-2019-3e42a55b54').one() >>> u.locked = False >>> s().commit() After this, I will use the Bodhi web UI to swap the build for fedora- toolbox:28-5. [0] https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2019-3e42a55b54 signature.asc Description: This is a digitally signed message part ___ 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: Greenwave increase gunicorn worker timeout
On Fri, 2019-03-15 at 15:17 +0100, Clement Verna wrote: > Hi all, > > So after setting higher timeout to the openshift route, it seems that > now we are hitting gunicorn worker default timeout (30s). > > The following patch increase this value. > > +1s ? -1 to this too. Now Bodhi's cron job is slower, but still times out, as mentioned in my other e-mail. We should revert all of these timeout changes. signature.asc Description: This is a digitally signed message part ___ 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: Increase the openshift route timeout for greenwave
On Fri, 2019-03-15 at 12:11 +0100, Clement Verna wrote: > I would like to increase this timeout to 330 seconds, greenwave will > timeout after 300 seconds. I don't think we should do this. Two problems immediately come to mind. Bodhi still gets timeout errors from Greenwave, because Bodhi will not wait forever for a response. Now instead of 500 error e-mails from Greenwave, I get just as many timeout error e-mails. Secondly, there are currently 1,717 updates in the testing status in Bodhi. This means that Bodhi's cron job will make that many queries each time it runs. We do want to limit how much time Greenwave can take to respond, otherwise we will just pile up cron jobs. This change effectively made Bodhi's cron job slower, but did not lower the error rate. signature.asc Description: This is a digitally signed message part ___ 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: Rebuild Bodhi frontend containers
Thanks for the +1's. This change has been deployed and I've confirmed that I can push F30 updates between the 3 and 7 day mark. signature.asc Description: This is a digitally signed message part ___ 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: Rebuild Bodhi frontend containers
Greetings! The Bodhi frontend container was not rebuilt when the Fedora 30 configurations were added to production.ini. This means that the frontend is not aware of the policy of 3 days to stable, while the backend is aware. This means that the backend is adding comments to updates to tell packagers they can push their packages, but the frontend is not allowing them to push the packages. To fix this, I will run this command: $ sudo rbac-playbook openshift-apps/bodhi.yml I will also send a patch to the releng SOP which doesn't explicitly mention this step - it really should just link to the Bodhi SOP where this is mentioned. signature.asc Description: This is a digitally signed message part ___ 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: A short reminder on commit messages, freezes and hotfixes
On Wed, 2019-03-06 at 14:17 -0800, Kevin Fenzi wrote: > * add ansible play to copy files from our repo to the filesystem > * commit all the files you are going to touch. > * commit in a second commit the changes for the hotfix. > * push both with a comment about it. > * run playbook. * Make sure the patch makes it upstream, and preferrably in the next release of the software ☺ signature.asc Description: This is a digitally signed message part ___ 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: Future of fedora-packages
On Tue, 2019-02-26 at 20:38 +0100, Clement Verna wrote: > Should we approach the Council to see if we can get founding to have > this service hosted by Elastic ? If we use the service hosted by Elastic that's a nice way to support development of an open source project with some cold hard cash. signature.asc Description: This is a digitally signed message part ___ 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: Future of fedora-packages
On Wed, 2019-02-27 at 10:48 +0100, Pierre-Yves Chibon wrote: > We look at Elasticsearch at one point (I believe Aurélien was even > looking at > setting up an instance in our cloud) but it came down to two aspects: > - setting it up is another application to maintain > - an application we have no expertise on > > On the other side, fedora-search is: > - setting up another application to maintain > - an application we have expertise on Well, fedora-search is also: - an application we have to create. - an application we have to maintain the code and the deployment, where elasticsearch is just maintaining the deployment. signature.asc Description: This is a digitally signed message part ___ 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
Bodhi stakeholder's meeting
Greetings! I've scheduled another quarterly Bodhi stakeholder's meeting for March 22 at 15:00 UTC in #fedora-meeting-2. There will be an agenda in Gobby by March 20. We will talk about what's been going on in Bodhi, and what is planned future. https://apps.fedoraproject.org/calendar/infrastructure/2019/3/22/#m9485 signature.asc Description: This is a digitally signed message part ___ 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
bodhi-3.13.3 deployed
Bodhi 3.13.3 is deployed to production, and test gating is enabled again: https://bodhi.fedoraproject.org/docs/user/release_notes.html#v3-13-3 signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 3.13.0 released
On Fri, 2019-02-15 at 14:46 -0500, Randy Barlow wrote: > Bodhi 3.13.0 is released and deployed to staging: > > https://bodhi.stg.fedoraproject.org/docs/user/release_notes.html > > I plan to deploy it to production on Monday. It was deployed today (hooray), but it had a regression (booo): https://github.com/fedora-infra/bodhi/issues/3016 I've almost got a fix ready for a 3.13.1 (hooray). signature.asc Description: This is a digitally signed message part ___ 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
Bodhi 3.13.0 released
Bodhi 3.13.0 is released and deployed to staging: https://bodhi.stg.fedoraproject.org/docs/user/release_notes.html I plan to deploy it to production on Monday. signature.asc Description: This is a digitally signed message part ___ 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: interesting article on commit messages
On Sun, 2018-12-16 at 15:43 -0800, Kevin Fenzi wrote: > I think this might be a good rule of thumb to apply to our commits, > at > least in ansible repo. I'm as guilty as the next person on useless > commits, but I'm gonna try and do better. ;) I will say that I find the whimsical nature of some of the Ansible commit messages to be entertaining. I do try to employ meaningful commit messages in Bodhi's git log, and sometimes even write a couple paragraphs detailing the reasoning behind it when appropriate. signature.asc Description: This is a digitally signed message part ___ 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: Enabling zchunk metadata generation in F30
On Fri, 2018-12-14 at 19:02 +, Jonathan Dieter wrote: > Hey Randy, at the moment the --zck option *only* applies to > primary.xml, filelists.xml and other.xml. It should be pretty > straightforward to add it to the others, but I wanted to get those > three working first. Cool, sounds good to me. > As for python bindings, they can read zchunk metadata just fine, but > I > don't think I hooked up creating the metadata. Where exactly does it > generate updateinfo in bodhi? I'd like to see how the function is > used > so I can implement it. Bodhi's updateinfo code lives here: https://github.com/fedora-infra/bodhi/blob/3.11.3/bodhi/server/metadata.py signature.asc Description: This is a digitally signed message part ___ 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: Enabling zchunk metadata generation in F30
On Thu, 2018-12-13 at 22:56 +, Jonathan Dieter wrote: > The call to createrepo_c or mergerepo_c > (whichever is run last to generate the final metadata) would need to > be > run with the new zchunk arguments: > > --zck --zck-dict-dir=/usr/share/fedora-repo-zdicts/f30 Hey Jonathan! Bodhi uses createrepo_c both through pungi (to create the bulk of the repository) and through the createrepo_c Python bindings (to generate the updateinfo.xml file). Is there a way to ask the Python bindings to do this? The Fedora 29 updateinfo.xml file looks like it's only about 1 MB for x86_64 right now, so maybe it's not as crucial. (F28 is 2.1 MB.) signature.asc Description: This is a digitally signed message part ___ 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
Bodhi stakeholders' meeting next week
Greetings! I have planned an IRC meeting for Bodhi stakeholders for Tuesday 2018- 12-18 at 17:00 UTC in #fedora-meeting on Freenode: https://apps.fedoraproject.org/calendar/infrastructure/2018/12/17/#m9429 Feel free to drop by and say hi! signature.asc Description: This is a digitally signed message part ___ 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
Bodhi 3.11.1
Bodhi 3.11.1 was released and deployed to production today: https://bodhi.fedoraproject.org/docs/user/release_notes.html signature.asc Description: This is a digitally signed message part ___ 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: Bodhi 3.11.0 beta deployed to staging
Bodhi 3.11.0 is now released: https://github.com/fedora-infra/bodhi/releases/tag/3.11.0 I plan to deploy it to production on Monday. signature.asc Description: This is a digitally signed message part ___ 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
Bodhi 3.11.0 beta deployed to staging
Greetings! bodhi-3.11.0 beta has been deployed to staging: https://bodhi.stg.fedoraproject.org/docs/user/release_notes.html#v3-11-0 This deployment uses Python 3 only! signature.asc Description: This is a digitally signed message part ___ 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: Fedora 29 Final freeze now over
On Wed, 2018-10-31 at 09:22 -0700, Kevin Fenzi wrote: > With the release of Fedora 29 yesterday, we are out of final freeze. /me takes off his jacket and puts sunglasses on. signature.asc Description: This is a digitally signed message part ___ 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
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? signature.asc Description: This is a digitally signed message part ___ 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: [Freeze Break Request: ] Switch anitya backups to use --exclude-table-data rather than excluding entire tables
On Wed, 2018-10-10 at 00:17 +, ke...@scrye.com wrote: > +/usr/bin/pg_dump --exclude-table-data users --exclude-table-data > tokens --exclude-table-data 'social*' --exclude-table-data sessions > -C $DB | /usr/bin/pxz -T4 > /backups/$DB-public-$(date +%F).dump.xz It might be good to add a comment over this line that explains that it's excluding the data since it has personally identifiable info, so that nobody removes it in the future not knowing what it was for. signature.asc Description: This is a digitally signed message part ___ 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
Jenkies
Greetings! I just wrote up a blog post about the recent work I've been doing to get Bodhi's CI setup to be much nicer, in case that interests any of you: https://blog.electronsweatshop.com/goodbye-jjb-hello-jenkies-pipeline.html signature.asc Description: This is a digitally signed message part ___ 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: Automating bodhi daily pushes
On Thu, 2018-10-04 at 17:09 -0700, Kevin Fenzi wrote: > And secondly: > > https://github.com/fedora-infra/bodhi/issues/2579 > > we probibly need at least that bug fixed, although we could put a > lock > wrapper around it so it only runs one at a time ever. Mohan's code did ensure that the len() on the composes was 0, which is the same thing I would do if I fixed #2579, so I think his code will work without fixing #2579 (though of course, we should still fix #2579 because that's the right place to fix it ultimately). +1 to the suggestion of using the Frozen variable. signature.asc Description: This is a digitally signed message part ___ 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: Move python-blivet-3.1.0-2.fc29 from FEDORA-2018-85853d46b5 to FEDORA-2018-f16a71bc92
This FBR is applied on production. signature.asc Description: OpenPGP digital signature ___ 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: Move python-blivet-3.1.0-2.fc29 from FEDORA-2018-85853d46b5 to FEDORA-2018-f16a71bc92
Also the formatting on this e-mail was terrible. Sorry for that. Next time I'll just attach a file so Thunderbird doesn't try to get too smart. signature.asc Description: OpenPGP digital signature ___ 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: Move python-blivet-3.1.0-2.fc29 from FEDORA-2018-85853d46b5 to FEDORA-2018-f16a71bc92
On 9/18/18 12:22 PM, Stephen John Smoogen wrote: > I see this removing it from 85853d46b5 but how does it connect to the > other update? Hi Smooge! I'm trying to do the minimum amount needed in the FBR, so I plan to use Bodhi's normal features after doing this to add the build to the other update, using my proven packager privileges (i.e., I'll just use the pointy-clicky web UI to do that part). I *could* do that here too, but in the spirit of the freeze I thought it'd be better to minimize what I do on a Python shell like this. Unfortunately, there isn't a way to use Bodhi's normal features to do this bit, so this part just has to be done in this kinda ugly way. signature.asc Description: OpenPGP digital signature ___ 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: Move python-blivet-3.1.0-2.fc29 from FEDORA-2018-85853d46b5 to FEDORA-2018-f16a71bc92
Context: https://pagure.io/releng/issue/7825 In order to fix that issue, I propose running the following commands on bodhi-backend01: $ sudo -u apache pshell /etc/bodhi/production.ini 2018-09-18 16:09:51,892 INFO [bodhi][MainThread] Using the FakeBugTracker 2018-09-18 16:09:51,892 DEBUG [bodhi][MainThread] Using DevBuildsys 2018-09-18 16:10:26,842 INFO [bodhi.server][MainThread] Bodhi ready and at your service! Python 3.6.6 (default, Jul 19 2018, 14:25:17) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)] on linux Type "help" for more information. Environment: app The WSGI application. registry Active Pyramid registry. request Active request object. root Root of the default resource tree. root_factory Default root factory used to create `root`. Custom Variables: mbodhi.server.models sbodhi.server.Session >>> blivet = m.Build.query.filter_by(nvr='python-blivet-3.1.0-2.fc29').one() >>> >>> >>> >>> update = m.Update.query.filter_by(alias='FEDORA-2018-85853d46b5').one() >>> >>> >>> >>> update.builds.remove(blivet) >>> update.comment(m.Session(), "python-blivet-3.1.0-2.fc29 has been removed >>> from this update.", author='bowlofeggs') >>> m.Session().commit() The output above was taken from a practice run I did in Bodhi's development environment. +1's? signature.asc Description: OpenPGP digital signature ___ 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: Moving forward with Fedora's PDC
On 09/12/2018 04:01 AM, Clement Verna wrote: > [0] https://github.com/dhatim/python-license-check This looks useful, thanks for sharing! signature.asc Description: OpenPGP digital signature ___ 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: Please take packages that used to be maintained by Luke Macken
On 09/03/2018 07:15 AM, Miro Hrončok wrote: > Hi. As per the consensus reached in nonresponsive maintainer: lmacken [0], I > offer this list of packages to be taken over by infra. Any takers? I took a few of them: https://pagure.io/releng/issue/7764 signature.asc Description: OpenPGP digital signature ___ 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: Manually delete the Fedora 29 compose that is failed in Bodhi's DB
This change has been made. signature.asc Description: OpenPGP digital signature ___ 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: Manually delete the Fedora 29 compose that is failed in Bodhi's DB
On 08/29/2018 03:44 PM, Stephen John Smoogen wrote: > The original is fine. Thank you for the training. I just wanted to make > sure there weren't more objects in the DB, that the query wouldn't give > you a random return from a hashtable etc. > > +1 Excellent. I will make it so. -- Number One signature.asc Description: OpenPGP digital signature ___ 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: Manually delete the Fedora 29 compose that is failed in Bodhi's DB
On 08/29/2018 03:26 PM, Stephen John Smoogen wrote: > Can you give me more information on what this will due, what could go > wrong and how to recover? If not I don't think I can give an answer. I have two +1's now, but I wanted to make sure you are satisfied too before I take action. Shall I proceed? signature.asc Description: OpenPGP digital signature ___ 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: Manually delete the Fedora 29 compose that is failed in Bodhi's DB
On 08/29/2018 03:26 PM, Stephen John Smoogen wrote: > Can you give me more information on what this will due, what could go > wrong and how to recover? If not I don't think I can give an answer. Bodhi has a database model called a Compose, which is used to keep track of each of its daily compose jobs (formerly called mashes): https://github.com/fedora-infra/bodhi/blob/3.9.0/bodhi/server/models.py#L3637-L3667 The code snippet I pasted will delete the first Compose object found in the database. There is currently only one, and it's the one I want to delete. To be fully honest, my shell snippet was a little lazy in this way because I could have written a more formal query to target the specific one, but since there is only one it's pretty easy to just say "delete it!". I could do this instead actually: >>> c = m.Compose.query.one() That will fail to retrieve it if there's more than one. So I'll do it that way if I get my +1's, so I can be lazy *and* more precise at the same time ☺ Since the backend isn't running any composes right now, I don't know of any particular risk to deleting it. The Compose models are short-lived objects in the database anyway, as they exist purely to track the state of those jobs. When the jobs finish successfully, these Compose objects are deleted. This particular one has stuck around because the previous job failed. Unfortunately, every single update has been kicked out too, so I'm not sure what would even happen if we resumed it (which would be the typical thing to do now). This is why I'd rather just delete it so bodhi-push can start a new one. signature.asc Description: OpenPGP digital signature ___ 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: Manually delete the Fedora 29 compose that is failed in Bodhi's DB
There is a Fedora 29 Compose in Bodhi's DB that has gotten into a weird state due to being run when the process didn't know about Fedora 29. To fix it, I wish to use pshell on bodhi-backend01 to delete it: $ sudo -u apache pshell /etc/bodhi/production.ini >>> c = m.Compose.query.first() >>> m.Session().delete(c) >>> m.Session().commit() +1's? signature.asc Description: OpenPGP digital signature ___ 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: Freeze Break: some more bodhi config for f29
On 08/29/2018 02:07 PM, Kevin Fenzi wrote: > Also we need to restart fedmsg-hub on bodhi-backend01 for this and other > things to take effect. > > +1s? My vote doesn't count, but I support this ☺ signature.asc Description: OpenPGP digital signature ___ 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: hotfix - Don't clean old mashes
On 08/29/2018 11:43 AM, Randy Barlow wrote: > -clean_old_mashes.remove_old_composes() OK, this is now in place on backend01 - Mohan if you resume the failed mash I think it'll succeed now. I am preparing a better fix upstream today: https://github.com/fedora-infra/bodhi/issues/2561 signature.asc Description: OpenPGP digital signature ___ 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: hotfix - Don't clean old mashes
This replaces the other FBR I filed today. I would like to manually apply (i.e., hotfix) this patch to bodhi-backend01 as a temporary workaround for #7194[0]: diff --git a/bodhi/server/consumers/masher.py b/bodhi/server/consumers/masher.py index ecf88fd3..43c2ac5f 100644 --- a/bodhi/server/consumers/masher.py +++ b/bodhi/server/consumers/masher.py @@ -432,7 +432,6 @@ class ComposerThread(threading.Thread): # Clean old composes self.save_state(ComposeState.cleaning) -clean_old_mashes.remove_old_composes() self.save_state(ComposeState.success) self.success = True For a longer term fix, I will wrap the above dropped line in an if statement that checks a new setting for whether Bodhi should auto-cleanup old composes, and I will include that patch in Bodhi 3.10.0 (planned for release after the current freeze). [0] https://pagure.io/fedora-infrastructure/issue/7194 signature.asc Description: OpenPGP digital signature ___ 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: workaround for #7194
On 08/29/2018 09:57 AM, Randy Barlow wrote: > The number is not specified, so it will also change for when Bodhi calls it. Ugh, which actually means it won't work. signature.asc Description: OpenPGP digital signature ___ 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: workaround for #7194
On 08/29/2018 09:56 AM, Dusty Mabe wrote: > So basically the solution is to run clean_old_mashes.py as root and change > it so that it deletes "more than" what the bodhi run will delete when it runs > as non-root, thus rendering the bodhi run clean_old_mashes.py as a no-op ? Yes. > Is the number to keep specified when bodhi calls clean_old_mashes.py or would > it also change to 5 as part of this? The number is not specified, so it will also change for when Bodhi calls it. signature.asc Description: OpenPGP digital signature ___ 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: workaround for #7194
On 08/29/2018 09:19 AM, Randy Barlow wrote: > Basically, the current script deletes the most recent 10. Correction: the script deletes *all but* the most recent 10. signature.asc Description: OpenPGP digital signature ___ 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: workaround for #7194
Fedora 28 will always fail to compose with Bodhi 3.9.0 because of a recent change that is causing some ostree files to be root owned in /mnt/koji/compose/updates/[0]. I filed a ticket to ask for help in deciding a solution to the problem, but we need an immediate solution because the current compose is marked as failed. For a short term workaround, I would like to hot patch bodhi-backend01 with this: diff --git a/bodhi/server/scripts/clean_old_mashes.py b/bodhi/server/scripts/clean_old_mashes.py index f812c6d9..e69de3e1 100644 --- a/bodhi/server/scripts/clean_old_mashes.py +++ b/bodhi/server/scripts/clean_old_mashes.py @@ -27,7 +27,7 @@ from bodhi.server import config # How many of the newest mash dirs to keep during cleanup -NUM_TO_KEEP = 10 +NUM_TO_KEEP = 5 @click.command() Additionally, I would like to run the above as root on a regular basis (perhaps daily) until we decide on a proper solution to #7194. Basically, the current script deletes the most recent 10. This script is run at the end of the compose and is what is failing. At that point, there are going to be 11. If I change the script to some number less than 10 (5 is arbitrary), I can get ahead of what the composer is going to do and cause it to no-op, which will make it succeed. This is not a long term solution. [0] https://pagure.io/fedora-infrastructure/issue/7194 signature.asc Description: OpenPGP digital signature ___ 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
Bodhi 3.9.0 released
Bodhi 3.9.0 is released upstream, and i plan to deploy it to production on Monday. https://bodhi.stg.fedoraproject.org/docs/user/release_notes.html Happy updating! ___ 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/message/QKJNRJWGZYZT4T54FJX6AGDBF2KW6LTO/
Re: python2 and fedora deployed applications
On 07/23/2018 05:05 PM, Kevin Fenzi wrote: > bodhi-backend - ? > bodhi-web - ? Both of these are close to ready. Theoretically they should work with Python 3 right now, but there are a few tests that fail (they are skipped so the test suite passes) in Python 3 (most likely due to the test code itself not working, but I need to get in there and investigate to be sure). Once all the tests pass with no skips on Python 3 I will be ready to declare Bodhi Python 3 ready. I think this should be achievable this summer. > docker registry - ? This is in go. signature.asc Description: OpenPGP digital signature ___ 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/message/ZHL7UHBQUIK6FDIFGQPDQILDYBYDEHNG/
Re: Fedora and PDC, road forward
On 06/13/2018 08:04 PM, Kevin Fenzi wrote: > I can take it to them, I just wanted to see if there was a general sense > that it was useful and we should keep it, or it was pointless and we > should drop it. Perhaps I'll post to devel about it to see what the > general feeling is. I only have a slight "intuition" that it seems useful to me, but that's a rather weak statement and I certainly wouldn't argue about it. If you feel more strongly about it, +1 to raising it for discussion! signature.asc Description: OpenPGP digital signature ___ 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/message/Z4H3D2ZUSFQS4UO5SS3DL34TKOUOMV27/
Re: Fedora and PDC, road forward
On 06/13/2018 03:03 PM, Kevin Fenzi wrote: > ok. Note that this data changes over time, and releng needs a script to > update it (or better a automatic updating of it). Yeah there is a Bodhi ticket about this and I noted that we will need to make sure we still work with releng's script if we make the change: https://github.com/fedora-infra/bodhi/issues/2433 > We might want to bring up the bigger topic of if we want to bother > keeping this. The only current use of it is some rules about going > stable in bodhi... are those actually useful? This sounds like a policy decision, so perhaps the question could be posed to FESCo or possibly the packaging committee. It does make some intuitive sense to me that we would treat certain packages more stringently than we do others, but I don't have data to say one way or the other whether the current policies are beneficial. I will say that I would feel uncomfortable changing the policy without the blessing of a governing body. signature.asc Description: OpenPGP digital signature ___ 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/message/UV5EB5BGLQE7KMAFPQ7AOBDAHAZNVBLE/
Re: Fedora and PDC
On 06/07/2018 12:20 PM, Pierre-Yves Chibon wrote: > I propose that we meet up next week on Monday at 14:00 UTC. Works for me. > What do you prefer, IRC or video (bluejeans)? I have a slight preference for IRC. signature.asc Description: OpenPGP digital signature ___ 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/message/42J73LGGBXD7LWE4Y7LTDEOGUSIVBQYH/
Re: Factory2/Infra sync up meeting - May 2018
On 05/17/2018 05:02 PM, Randy Barlow wrote: > I don't > think it's reasonable to state that it's the only valid means. After re-reading your message, I realized that I may have misinterpreted your words a bit more strongly than perhaps they were intended to be. Please accept my apology if you hadn't intended to convey what I quoted here. ___ 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/message/I7YBRIKMD76ZXGTO4LCRIUNMICPJEOYE/
Re: Factory2/Infra sync up meeting - May 2018
On 05/17/2018 01:10 PM, Pierre-Yves Chibon wrote: > We went over the event that lead to disabling gating in bodhi last week > (see fesco ticket: https://pagure.io/fesco/issue/1872) > If this situation happens again we encourage a stronger reach out for help > from > the folks involved (in this case Ralph or Dan Callaghan (dcallagh) who hangs > on > #fedora-admin and was around while the discussion was happening), by stronger > we are putting down a phone call or a text as valid means. The use of the word valid seems to imply that we did not reach out in a valid way. I don't think IRC should be considered invalid - it's one of the primary ways our community operates. Consider that packagers don't all have the phone numbers of the people who can help. I also don't think admins should be burdened with phone calls every time a packager has trouble with this. About 7% of updates needed to be waived as of last week[2] - it would have been quite a burden to resolve those via phone calls. I appreciate the offer to support problems via personal cell phones, and I may even take that offer up one day, but I don't think it's reasonable to state that it's the only valid means. Further, we need a system that packagers can use without needing admin help - supporting the current system is not scalable (especially if phone calls are needed). I don't think a phone call would have changed the outcome here - even if we had been able to get that one update through, the experience[3] was ample evidence that the system places an unreasonable burden onto packagers, and that disabling it was in the best interest[1] of the Fedora project. We do have a solid plan going forward. In the next days I plan to fix one Bodhi bug[0] that blocks it from integrating with Greenwave. Once that is in place, Bodhi's test gating setting can be turned back on. Greenwave is currently configured to pass all updates. Soon, Greenwave will gain a feature that will let packagers opt-in to test gating in Greenwave. We will use this to gain feedback from packagers who have opted in (I plan to opt in some of my packagers). Once we believe the packager experience around test gating is reasonable based on this feedback, we plan to enforce tests across all packages as we did before. [0] https://github.com/fedora-infra/bodhi/issues/2368 [1] https://pagure.io/fesco/issue/1872#comment-511238 [2] https://pagure.io/fesco/issue/1872#comment-511305 [3] https://pagure.io/fesco/issue/1872#comment-511253 ___ 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/message/THRYW3N7KPMWM3ZRBZQWZ43C5PK7VCGB/
Modularity WG + f2 + Infra
Greetings! At the hackathon we did recently, we talked about the need for one of us to attend the Modularity WG meetings so we could be more aware of what work is coming our way before it's a surprise, and I volunteered to be that person. For $reasons, today was the first of the WG meetings I was able to attend. There were two items of interest: New service === I learned that Factory 2 is developing a new service called Ursa Major. I gathered that its mission is to make it so that RPMs that depend on modules can get those modules pulled into their buildroot. Ralph, is the above correct? If so, what time frame do you anticipate us needing to get this service deployed to infrastructure? Meetings The modularity WG suggested that it was probably not that beneficial for me to attend their meetings as an infra liason, as they are not actually particularly familiar with the infrastructure side of things. They suggested instead that we interface with Factory 2. A suggestion was made that perhaps we could have an agenda item on *our* meeting, perhaps once a month, where we invite modularity WG and factory 2 to talk with us about what is coming our way, or about issues that need dealing with. I thought this was a fine suggestion, so I wanted to ask you all what you thought about it? ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Bodhi stakeholders' meeting
Greetings! I would like feedback from you about the usefulness and/or format/schedule of the Bodhi stakeholders' meeting. I've been holding this meeting about once every 4 weeks. It started off pretty well with lots of seemingly interested participation, but over time it seems that fewer people attend. I would like to identify why the attendance is lower so I can adjust to it. Here are some thoughts: Is the meeting too often? = I've thought perhaps about reducing it to once every 3 months instead of once every 4 weeks. Perhaps this way there would be more to discuss? Is the time of the meeting bad? === I know it is a bad time for our west coast North America friends. Is it also a bad time for others? I could try to move it to be later in the day if that would help. Is it boring? = Is the meeting just not relevant to you? Does it lack purpose? Other = Other thoughts? Proposal I've been considering reducing it to once every 3 months and making it later in the day for west coast people. I've also considered if it would be good to make it be part of the weekly infrastructure meeting on that 3 month schedule (i.e., just have an agenda item once every 3 months to focus on Bodhi in the established infra meeting). Thoughts on this? ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Re: Bodhi 3.7.0-0.0.beta deployed to stg
On 05/09/2018 12:07 PM, Randy Barlow wrote: > Aaand it also doesn't work in production. I tested the Greenwave API > just yesterday and it did return the data that Bodhi looks for. Today > the exact same query omits the specific data that Bodhi looks for, which > means that Bodhi does *not* tell users which tests are missing. https://pagure.io/greenwave/issue/169#comment-511247 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
