Re: Fedora infra development Streaming session

[Ken Dreyer]

On Wed, Jul 5, 2023 at 5:54 AM Aurelien Bompard
 wrote:
>
> Hey folks!
>
> This Friday at 13:00 UTC I'll be steaming on Twitch[1] about the development 
> of Fedora infrastructure apps. I'll start on a clean env, checkout one of our 
> apps, setup a dev env, fix a small bug, test it, and create a PR.
>
> [1] https://twitch.tv/ohwellien

I watched the recording today. Thanks for starting all the way at the
beginning with the easyfix page. It was interesting to see your dev
environment with VS Code at the beginning and OpenShift GitHub
automation at the end, plus the tiny-stage concept. I learned a few
things!

- Ken
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: automating SCM requests (again)

[Ken Dreyer]

On Wed, Jan 5, 2022 at 3:14 PM Matthew Miller  wrote:
>
> Okay, this is making me _very_ sure that we should automate these:
>
> https://pagure.io/fedora-infrastructure/issue/10441
>
> That's because even though a human is spending time running the script,
> there does not seem to be any opportunity for human intervention... this
> happened: https://pagure.io/releng/fedora-scm-requests/issue/39869

We give users a web form (Pagure) that invites human input, and then
an automatic-but-human-sounding-response that gives the same response
over and over, or eternal silence. There's no indication in the
comment that this is not a human, or a clear link to the source code
to improve anything about the situation.

See my comment in
https://pagure.io/releng/fedora-scm-requests/issue/19865 . I hit a
despairing moment like you did. Interesting that you're able to
re-open your ticket, because I don't think my account has permission
to do that in this Pagure project.

Imagine if this was as easy as GitHub or GitLab, where I just click a
button to create a new repo, or I run "git push" to create a new
branch.

I miss the clarity and simplicity of Pkgdb.

I've mentored a new Fedora contributor through this process a while
ago, and this scm-admin part was the point at which they gave up.

- Ken
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What is our technical debt?

[Ken Dreyer]

On Mon, Jul 6, 2020 at 7:11 PM Neal Gompa  wrote:
> This sort of worries me though: abusing Ansible to do this sort of
> thing is not what it was made for. It also makes mentally modeling how
> everything works so much harder because the sequencing (or execution
> flow) of actions is non-obvious.

You're right that Ansible originally only operated on systems with
SSH. However, there are a lot of modules and plugins now that do many
more things.

I completely agree that it's possible to make a mess and make Ansible
non-obvious. The sequencing and execution flow must be obvious or
we're not making the world better. I've found that when I implement
loops or complex conditionals in Ansible playbooks, that does get hard
to read and understand. Ansible shines when the modules are easy to
use for non-programmers. The essential complexity should live inside
the modules or plugins.

At a high level, we're talking about "configuration management", and
whether it's SSH or other systems, I've found Ansible is a good fit.

This script reads and executes top-to-bottom:
https://pagure.io/releng/blob/master/f/scripts/branching/make-koji-release-tags
, and a corresponding Ansible playbook would also read and execute
top-to-bottom.

> And Ansible's own APIs are horrifically unstable, to the point that
> I've had *bar conversations* about how people have to pin to specific
> Ansible releases because all the crap they build on top of it to bend
> Ansible to their needs relies on the part of Ansible that's
> deliberately *not* stable: the Python module extension interface.

I can't speak to or defend the decisions Ansible's made in the past,
and I can't say that they'll never break us again. There are two
things to consider though:

1. The Ansible core engineers are more incentivized than ever before
to make the Python API for out-of-tree modules stable, because they've
pulled almost all of the modules out of the ansible monorepo in 2.10.
https://www.ansible.com/resources/webinars-training/collections-future-of-how-ansible-content-is-handled
explains more about where RH's Ansible product managers intend to go
strategically here.

2. In the spirit of "trust-but-verify", we also test against multiple
versions of Ansible (and Python, etc). The CI system for koji-ansible
runs unit tests and integration tests for all the Ansible modules on
every pull request. The integration tests are a series of playbooks
that we run against ephemeral Koji hubs and assert that the hub's data
looks the way we expect. Today we run the integration tests against
the latest GA version of Ansible on PyPI (2.9) and the latest
pre-release on PyPI (2.10). It's important to do this because the
blast radius for bugs is pretty high. The Ansible pre-release testing
in particular gives us an early heads' up if something problematic is
coming.

- Ken
___
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: What is our technical debt?

[Ken Dreyer]

On Wed, Jul 1, 2020 at 12:57 PM Stephen John Smoogen  wrote:
>
> On Wed, 1 Jul 2020 at 14:46, Miroslav Suchý  wrote:
> >
> > Dne 30. 06. 20 v 9:44 Pierre-Yves Chibon napsal(a):
> > > What are you talking about here? The Fedora release process? The 
> > > mass-branching
> > > in dist-git?
> >
> > This. And creating new gpg keys, new mock configs, new tags in Koji, add 
> > release to retrace.f.o, Copr, ... I have a
> > dream where you just bump up number in - let say - PDC and everything else 
> > will happen automagically. At right time.
> >
>
> I think choosing the one tool which is so end of life to do it in.. is
> a sign of why we can't do this. Every release some set of tools in
> Fedora get added by some team who have been working on their own
> schedules and their own API without any idea of any other teams
> working on.
> We then have to do a lot of integration and make it work
> before the release deadline to make it work. Then usually after 1 or 2
> releases that software team is no longer in existence and we have to
> continue with it waiting for the promised replacement which will do
> all those things you list above.. but instead get some other tool
> which has to be shoved in.

This is an excellent summary of the problem over the past couple of years.

I think one of the problems with PDC was that so many teams had to
adapt all their *giant* tools to it, and this integration effort was
unsustainable when we have natural contributor turnover. Everything
ended up tightly coupled together so that it was really difficult to
remain agile as tools and business requirements (naturally) changed.
Also we never drew the line and wrote a list of things that PDC was
*not* going to do, so the Second Syndrome effect just kept growing
until it collapsed.

Instead of having everything having to talk to PDC to determine its
configuration, I'm approaching this problem from the other end -
making Ansible talk to all the services according to each service's
API. Here are some things I like about this approach:

1. Ansible is really simple and well-documented.

2. It's easy to start small and get value incrementally.

3. The playbooks can (and do) change independently from the APIs. This
   kind of agility is essential because SOPs must be able to change over
   time.

4. If we haven't completely implemented something in Ansible yet, the
   service itself is not completely broken. The workaround does not
   require multiple teams of developers (like with PDC). The workaround
   is that the administrator simply does the thing they used to do
   manually (and file tickets for the missing RFEs in the Ansible modules)

For the koji-ansible project, we're using it to configure some large
products internally. Now we have to expand this concept to the rest of
the pipeline (Bodhi, Pungi configuration, etc.)

Clement started on https://github.com/cverna/bodhi-ansible but I think
that's abandoned at this point. I do think this is the way to go,
though. In some ways this is the point - it should be possible for
these Ansible modules to be isolated so that when contributor turnover
happens, the whole system does not fall apart.

- Ken
___
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 future of loopabull

[Ken Dreyer]

On Thu, May 28, 2020 at 10:31 AM Adam Williamson
 wrote:
>
> Why, though?
>
> I quite like the design of small consumer components to do specific
> jobs in response to messages. Lots of the bits I maintain work that
> way. Why is it necessarily better for Koji to grow the ability to
> change stuff in dist-git than to have a little go-between to do the
> job?

One nice property of doing these things as separate services is that
they are more resilient to cascading failures.

Tomas found some problems recently with Koji failing to retry sending
messages when a messagebus connection gets into a certain (rare) state
where it is unavailable but proton is confused. Koji ends up dropping
those messages on the floor, but in the meantime there is more
pressure on the koji-hub application. I could envision a worse
scenario where Koji has to send even more "events" reliably to a bunch
of other services that could be responding very slowly, etc.

The same thing happens with Pagure Git hooks - unfortunately the more
we pile in there, the slower everything becomes.

- Ken
___
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 playbook to create koji tags

[Ken Dreyer]

On Tue, Apr 14, 2020 at 8:21 AM Clement Verna  wrote:
>
> I ll keep working on this and see if I can turn it in a role that
> could be used to create all the tags for each release, in the mean
> time if you have ideas or feedback please share them with me :-).

Thanks Clement for doing this!

If you run into issues in the code or ideas for doc improvements,
please open tickets in GitHub!
https://github.com/ktdreyer/koji-ansible/

- Ken
___
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: Koji 1.17.0 and Python 3

[Ken Dreyer]

On Mon, Mar 11, 2019 at 8:32 AM Neal Gompa  wrote:
> Sorry all. I've learned my lesson. I'm not going to touch
> infrastructure in Fedora directly again.

It sounds like you were being careful (disabling autokarma) and this
was just a corner-case. Your work on Koji and infrastructure is
important, and this was an honest mistake. I make mistakes all the
time.

Hopefully you continue to make contributions, because more we need
more people working on these things.

- Ken
___
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 plans about fedmsg

[Ken Dreyer]

On Thu, Feb 7, 2019 at 11:59 AM Jeremy Cline  wrote:
>
> 3. Expose a consume-only AMQP broker to the public.
>
> The advantage here is everything can use the same fedora-messaging
> APIs (or any AMQP client) inside or outside infrastructure. The downside
> is the service is exposed to the harsh world of the Internet.
>
> Talking with Patrick before DevConf, I think this is the direction we
> will ultimately go, but there are a number of deployment configurations
> to consider so this isn't something you'll see tomorrow. I plan to do
> some more research and present the options in detail in the coming
> weeks.

This would be fantastic to have the broker publicly accessible.
Looking forward to seeing more information about this.

- Ken
___
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: do we use mash any more?

[Ken Dreyer]

On Thu, Jan 3, 2019 at 11:15 AM Neal Gompa  wrote:
>
> On Thu, Jan 3, 2019 at 1:11 PM Ken Dreyer  wrote:
> >
> > I was going to update the Mash README at https://pagure.io/mash to
> > indicate that the Fedora Project no longer uses this software, but I
> > wanted to be sure that's really true.
> >
>
> Mash is dead. We killed it a little over a year ago.

Thank you Neal. I've updated the README in
https://pagure.io/mash/pull-request/17 with this information.
___
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

do we use mash any more?

[Ken Dreyer]

I was going to update the Mash README at https://pagure.io/mash to
indicate that the Fedora Project no longer uses this software, but I
wanted to be sure that's really true.

- Ken
___
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: Introducing Luiz Carvalho

[Ken Dreyer]

On Wed, Nov 14, 2018 at 6:36 PM Ralph Bean  wrote:
>
> Hi all,
>
> Just an FYI - I've moved off of the Factory 2 team inside Red Hat to
> take a different role in the internal devops organization there.
>
> Luiz Carvalho (lucarval in both FAS and irc) takes my place leading
> the Factory 2 team!  He's a good point of contact for greenwave, MBS,
> ODCS and freshmaker along with giulia, jkaluza, and mprahl.  Say hi
> in channel sometime.

Hi Luiz :)

- Ken
___
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 and PDC

[Ken Dreyer]

On Thu, Jun 7, 2018 at 10:20 AM, Pierre-Yves Chibon  wrote:
> >
> I propose that we meet up next week on Monday at 14:00 UTC.

Thanks. That works for me.

- Ken
___
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/G6GI5XVXEGQ63IDT36XKJ3POT3OJQ3YC/

Re: Migrating fedmsg to AMQP: a proposal

[Ken Dreyer]

On Mon, Jun 4, 2018 at 8:30 AM, Jeremy Cline  wrote:
> I had a hard time justifying choosing STOMP over AMQP because most
> brokers just map the other protocol they focus on onto STOMP. It's true
> the the spec is short, but it leaves a lot up to individual
> implementations as far as I can tell (like how topic matching works, for
> example).

It's nice to give the flexibility to clients by exposing both. I
haven't seen a problem with topic matching in my experience so far.

One thing I found with AMQP vs STOMP is that it's possible for AMQP
clients to (accidentally) emit "binary" message bodies, and then
ActiveMQ does not translate or expose these as plaintext JSON for
STOMP clients. It just looks like an empty message body to STOMP
clients, or possibly garbage. The solution was for clients to
translate the messages to text/json prior to sending. (Of course if
you never enable STOMP on your broker at all, maybe this won't be a
problem :)

- Ken
___
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/FRYQYBO77JKRERTEOCSIF77RG2HCIERS/

Re: Migrating fedmsg to AMQP: a proposal

[Ken Dreyer]

On Thu, May 24, 2018 at 10:16 AM, Aurelien Bompard
 wrote:
> What do you think of this proposal? Any blind spots?
> Thanks!

This sounds like a great idea. I use ActiveMQ and RabbitMQ at work,
and both are good choices for brokers. Sounds like you're going
towards RabbitMQ.

- Ken
___
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/EBAU23TNSVBPNGEXJVVSMEGD7KCCAW6J/

Re: Fedora and PDC

[Ken Dreyer]

On Sat, Apr 21, 2018 at 5:06 PM, Ken Dreyer <ktdre...@ktdreyer.com> wrote:
> On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon
> <pin...@pingoured.fr> wrote:
>> I propose we start the discussion on the list and plan for a meeting sometime
>> late next week to discuss it further with the interested parties (please 
>> signal
>> yourself)
>
> I am reimplementing a small piece of PDC as well, because the RH Ceph
> Storage product uses/used PDC's
> v1/releases/{release_id}/rpm-mapping/{package}/ endpoint.

For reference, this project to replace PDC's rpm-mappings endpoint is
now open-source at
https://github.com/ktdreyer/product-listings-manager

I'm not sure if Fedora's currently using the rpm-mappings part of PDC,
but I figured I'd mention that this is where we're heading with RH
product variant rpm mappings.

- Ken
___
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/E2CDUZSDXGWB4YBAMYF33LZCMLU3XGPG/

Re: Fedora and PDC

[Ken Dreyer]

On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
 wrote:
> The difference is that PDC rpm-mappings API endpoint was result of two
> sources:
>  * Manual per-rpm mappings (overrides) - this is sort of suitable if you
>have a product with just a couple source packages so it's manageable
>this way (i.e Ceph case)
>  * Results of compose metadata import - this is what Fedora/RHEL uses
>because several thousands of source packages are not manageable
>one-by-one by humans manually.
>
> You could still make a system that would create "PRs" for the generated
> files for second case, but then querying the current state will still be
> a bit tricky. I guess...

Yeah, the fact that we have (at least) two different input and storage
methods there is a lot of complexity. I'm not sure that's a good
design in 2018.

Regardless, you're right, I'm envisioning that we'd have a tool to
generate the data commits and PRs (or just commit + push directly).
PDC had included its own rudimentary form of version control for
auditing and message bus integration. Git's experience is much richer.

- Ken
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Fedora and PDC

[Ken Dreyer]

On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon
 wrote:
> I propose we start the discussion on the list and plan for a meeting sometime
> late next week to discuss it further with the interested parties (please 
> signal
> yourself)

I am reimplementing a small piece of PDC as well, because the RH Ceph
Storage product uses/used PDC's
v1/releases/{release_id}/rpm-mapping/{package}/ endpoint.  I'd be
interested in hearing where Fedora may be heading with their
replacement ideas. Please let me know the time of the meeting :)

Prior to PDC, we had/have another internal solution that used a
PostgreSQL database for what PDC calls rpm-mappings. We thought PDC
would eventually replace this database. With this sytem, it was
impossible to submit changes to the data store unless you were one of
the few people who had rights to submit changes in postgres. Even
reading the data out into something a mere mortal can understand was a
chore.

Obviously there are many orthogonal problems there, and we could solve
them with better APIs, docs, etc and still keep the Postgres backend.
However it does strike me that flat YAML files in Git are an
attractive backing store. It would make make it easier to submit and
approve data changes, because anyone can submit pull requests to the
flat files, and a CI system could test the changes before merging (or
even auto-merge), etc.

- Ken
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: integrate dist-git and bugzilla more tightly

[Ken Dreyer]

Side note, ... it would be great to use a standard that many groups
use for Git commit logs:

"Resolves: rhbz#"

I agree with you Dusty this should be technically possible, and it
sounds like a neat idea. We have something a little bit like this for
RH Ceph Storage but it is not tied into Pagure/fedmsg.

- Ken


On Wed, Jan 10, 2018 at 12:26 PM, Dusty Mabe  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 01/10/2018 05:50 AM, Vít Ondruch wrote:
>>
>>
>> Dne 10.1.2018 v 01:09 Dusty Mabe napsal(a):
>>>
>>> I go to a dist-git repo and find a bug when browsing the source code.
>>> I can
>>> open a PR to fix it, but what if I don't know how to fix it? I open an
>>> issue, right?
>>>
>>> Except, there's no issue tracker for dist-git pagure repos. That's
>>> what bugzilla
>>> is for. Now I need to go to bugzilla, find the component, fill out a
>>> bug, yada yada.
>>>
>>> I understand the need for bugzilla and that it's not going away
>>> anytime soon, but could
>>> we possibly integrate dist-git pagure issue tracking and bugzilla in a
>>> way that makes
>>> the whole process more seamless for this workflow. We could even use
>>> the bugzilla API
>>> and display things differently in pagure if we wanted.
>>>
>>> These are just suggestions. I feel like this can be improved.
>>>
>>> Dusty
>>
>> On the overview page, there is  "bug reports" link, is this not enough?
>>
>
> That does help but I'm thinking something a little more integrated. For 
> example:
>
> An issue is filed in dist-git pagure (which is linked to bugzilla, a BZ is 
> automatically
> created). Then in a PR in the commit message it says closes #123459 (the BZ 
> #). and then
> the issue state changes once merged to "merged pending release". Then once an 
> rpm with that
> commit hits stable the issue (BZ 123459) is closed and a comment is added to 
> the issue that
> links to the bodhi update that made it to stagble. The issue no longer 
> appears in the
> issue tracker.
>
> Dusty
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlpWaMsACgkQMwLb1zlS
> 5nGapg/+Ki9HXY1Zj7kEb1kmMWh3iN+LmUkMWStGqShZ2oK9qtGKH+kp/PvIRqB2
> AK02eOdRD5A++U6cbVxkETkv3oucfKEbW/q9VrhqnT3Tjjhexc9TU+bEjVTvgoId
> A8R5185ZtghHrRcT7VwuBD9+qrWDUcUy8IcA9Gx/NlnKMc2sBYmrLDRo1nMWCLfq
> Dl7sylHMZ0OyFKtE7pUquC4om+RfprJrwtTfF22suYdk9dOgwd97gaeDwvIlQqfB
> zjOobU+ykdO2ECR20WP/iyOyby7+riTTbuE+07O4bLDKiKtjzPBbBLyzPasO/tQg
> /nld570ENfI/CVv/3vOFq881XOxk+WUCplVXYeNlB8uGJY97U9Hy2aLjUqIo/F+N
> yfH4ZsYGA8Gua756vqT4lE/X8nHt6q8Y1d/MK5Oh+zgSUXpcWmTHuFQS4SPvRDWf
> 2bSoBfL+XXVfItrU2Rqna6Jf4e+xg0wYDClXTuO/iBWmd2LyyBrfRF7eCf/cNWd6
> M4wmowhJ53/MMkjzpCQ1RZlY1PEDRkTsK3KQZ5S5S4tyAmSEXT0b7LIEOFn6jebm
> gCWxLVCl60HDJXFPhaclzluMd6s0mNDEX6Ev2kHdxe/btOTxrX5zoqBP66j6Ew8i
> 3yp8IQ2SQ+tsr3fAMJ8mc+1W9pnadDdzOEMJMYPORrjIyQNibQo=
> =pzIl
> -END PGP SIGNATURE-
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Self Introduction: Dusty Mabe

[Ken Dreyer]

Hi Dusty, thanks for the intro! Great work on Atomic and elsewhere :)

- Ken

On Mon, Nov 27, 2017 at 8:56 AM, Dusty Mabe  wrote:
>
> I can't remember if I ever sent one of these in the past so I'm going to send 
> it again.
>
> Hello everyone! My name is Dusty Mabe and I help manage/release Fedora Atomic 
> Host on
> a bi-weekly cadence. You've probably seen patches/FBRs/issues from me on the 
> lists/issue
> trackers. I'm continuously learning more about Infra and contributing to help 
> us prepare
> for and manage changes for Atomic Host users. Before working on Fedora and on 
> Atomic Host
> I was a consultant for a few years in NYC and before that I worked on the 
> linux platform
> for a Telecommunications company.
>
> If you see me in IRC say hey!
>
> Dusty
>
>
> P.S If you haven't tried out Fedora Atomic Host you should give it a go! To 
> learn more you
> can run through the lab here: 
> https://dustymabe.com/2017/08/29/atomic-host-101-lab-part-0-preparation/
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Infra tags repos moved, delay REmoved

[Ken Dreyer]

On Fri, Oct 6, 2017 at 6:52 PM, Patrick Uiterwijk  wrote:
> This is the repo compose by koji, which is done anytime something gets
> tagged in by tag2distrepo (https://pagure.io/tag2distrepo/), runnin on
> bodhi-backend02.

Thanks Patrick!

I'm just learning about Koji's distrepo feature, so I was curious
about tag2distrepo, and its URL turns out to be
https://pagure.io/releng/tag2distrepo

- Ken
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Introduction Ken Dreyer

[Ken Dreyer]

Hi folks,

My name is Ken Dreyer (ktdreyer on IRC), I live in Denver CO (US) and
I'm interested in following along (and eventually contributing!) to
the Fedora Infra team.

I work on the Ceph engineering team at Red Hat, and my main role is
shepherding the releases of our downstream product. I work a lot on
Jenkins and automating as much of our release pipeline as possible.
Internally at my employer (Red Hat) we have a message bus that we use
to trigger events. Some of the things I've worked on:

- automatic patch applications in dist-git with rdopkg
  (hope to merge rdopkg with rpkg one day)
- building after each dist-git push event
- attaching builds to "updates" (Red Hat's erratas)
- automatically composing when new updates are ready
- building containers in OSBS from those new composes as they are
announced on the bus

I'm familiar with Python and I've contributed some small patches to
Koji and Pungi over the years. I've also helped a tiny bit with the
CVS -> Git conversion over in RPM Fusion.

I'm really interested in sharing as much infra tooling between Ceph
and Fedora as possible. When we switched to using Pungi for our
composes, we were then able to take advantage of the tools at
https://pagure.io/compose-utils, which made me excited :)

The Freshmaker project in particular looks like a much
larger-encompassing solution to what I've done for the automatic image
rebuilds, so when that stabilizes I want to dig into that more.

I have put the infra team meeting on my calendar, and I currently have
some conflicting meeting at that time, but I will try to listen in and
understand more about what is going on week-to-week.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org