Re: What is our technical debt? (fedora integration service)
On Thu, Jul 9, 2020 at 6:03 PM Pavel Raiskup wrote: > > On Thursday, July 9, 2020 4:51:29 PM CEST Tomas Tomecek wrote: > > The biggest problem is that on github or gitlab, one needs to explicitly > > install the app or integration so the downstream service can receive the > > events. Exactly what github2fedmsg is supposed to do. > > Exactly :-/ what I think would be nice to have one common integration in > each forge on common "Fedora level". So we don't have to have > team-specific integration apps (I'm just refering to the component graph I > cited in original mail). But the problem here is if the specific (CI) system wants to take advantage of the forge app identity - e.g. set a commit status on PR identified by the "Fedora app". We'd need to figure out identity federation, somehow. > > Our team should have quarterly planning in a month. Pavel, if this is > > important to you, we can bring this up on the planning session and start > > with the refactor/unification so that we can at least share the code for > > parsing and processing of the event payloads. > > Sure, I mean .. it depends on how you found this useful for Packit service > itself, if you think that it makes sense to define the unified event > format - and if you could consume it? > > > Or we can set up a call and discuss directly so we all would understand > > the requirements. > > I'll try to ping you on irc, thanks. I'm not using IRC much lately as you found out :D For anyone interested in this, we've set up a meeting to discuss this on Mon, July 27th - ping me if you wanna join. As for the usefulness - I personally don't see much of a use of such service for us. My only point here is to share code, expertise and experience we've gained so far in this field. Tomas ___ 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? (fedora integration service)
On Thursday, July 9, 2020 4:51:29 PM CEST Tomas Tomecek wrote: > On Thu, Jul 9, 2020 at 4:21 PM Pavel Raiskup wrote: > > > > On Thursday, July 9, 2020 3:13:47 PM CEST Tomas Tomecek wrote: > > Do you expose some library which makes the conversion of various formats > > of events from various forges into uniformly looking events, like: > > > > event_type: source_change > > change: > > old_code: > > code_location: git > > clone_url: > > committish: > > new_code: > > code_location: git > > clone_url: > > committish: > > > > The format is to be discussed (with potential consumers, or anyone > > interested), but this is what we need on Copr side basically and I suppose > > that's something everyone else needs who wants to process the code change. > > > > I think we need a precisely defined set of events which is able to handle > > not only git locations, changes, change requests (it should be flexible > > enough to reference e.g. tarballs + patches, when we needed it in future). > > > > This is basically what we need on the "event reader" side. > > This is really interesting. So far we've been only discussing > unification of webhook or message payloads on our side. All of this is > baked directly in packit-service's codebase [1] right now. Yeah, the very same situation is on our side. > The biggest problem is that on github or gitlab, one needs to explicitly > install the app or integration so the downstream service can receive the > events. Exactly what github2fedmsg is supposed to do. Exactly :-/ what I think would be nice to have one common integration in each forge on common "Fedora level". So we don't have to have team-specific integration apps (I'm just refering to the component graph I cited in original mail). > Our team should have quarterly planning in a month. Pavel, if this is > important to you, we can bring this up on the planning session and start > with the refactor/unification so that we can at least share the code for > parsing and processing of the event payloads. Sure, I mean .. it depends on how you found this useful for Packit service itself, if you think that it makes sense to define the unified event format - and if you could consume it? > Or we can set up a call and discuss directly so we all would understand > the requirements. I'll try to ping you on irc, thanks. Pavel > [1] > https://github.com/packit-service/packit-service/blob/master/packit_service/service/events.py ___ 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? (fedora integration service)
On Thu, Jul 9, 2020 at 4:21 PM Pavel Raiskup wrote: > > On Thursday, July 9, 2020 3:13:47 PM CEST Tomas Tomecek wrote: > Do you expose some library which makes the conversion of various formats > of events from various forges into uniformly looking events, like: > > event_type: source_change > change: > old_code: > code_location: git > clone_url: > committish: > new_code: > code_location: git > clone_url: > committish: > > The format is to be discussed (with potential consumers, or anyone > interested), but this is what we need on Copr side basically and I suppose > that's something everyone else needs who wants to process the code change. > > I think we need a precisely defined set of events which is able to handle > not only git locations, changes, change requests (it should be flexible > enough to reference e.g. tarballs + patches, when we needed it in future). > > This is basically what we need on the "event reader" side. This is really interesting. So far we've been only discussing unification of webhook or message payloads on our side. All of this is baked directly in packit-service's codebase [1] right now. The biggest problem is that on github or gitlab, one needs to explicitly install the app or integration so the downstream service can receive the events. Exactly what github2fedmsg is supposed to do. Our team should have quarterly planning in a month. Pavel, if this is important to you, we can bring this up on the planning session and start with the refactor/unification so that we can at least share the code for parsing and processing of the event payloads. Or we can set up a call and discuss directly so we all would understand the requirements. [1] https://github.com/packit-service/packit-service/blob/master/packit_service/service/events.py Cheers, Tomas ___ 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? (fedora integration service)
On Thursday, July 9, 2020 3:13:47 PM CEST Tomas Tomecek wrote: > Pavel, thanks for bringing this up! > > Funny thing is that you just described a lot of functionality of packit as a > service :) Yes, I believe. Same as the github2fedmsg, which is somewhat close as well, I even mentioned you in the original email ;) > getting events from multiple sources (fedora-messaging, CentOS' > mqtt, GitHub webhooks, GitLab webhooks, prod/stg) and then have a mechanism to > process those and provide updates. Big heads-up to everyone - it took us year+ > to get such functionality, polish it, make it secure, scalable, auditable, > maintainable. It's a ton of work. > > If there is anything we can do to help, please let us know. Do you expose some library which makes the conversion of various formats of events from various forges into uniformly looking events, like: event_type: source_change change: old_code: code_location: git clone_url: committish: new_code: code_location: git clone_url: committish: The format is to be discussed (with potential consumers, or anyone interested), but this is what we need on Copr side basically and I suppose that's something everyone else needs who wants to process the code change. I think we need a precisely defined set of events which is able to handle not only git locations, changes, change requests (it should be flexible enough to reference e.g. tarballs + patches, when we needed it in future). This is basically what we need on the "event reader" side. > (one of the core components of packit's architecture is our library ogr > [1], which serves as an abstraction layer on top of gitforge APIs - > pagure, github, gitlab) I've seen that one... That sounds like library for actively communicating over APIs with forges. That's surely one part needed for sending back the reaction results. Pavel > [1] https://github.com/packit-service/ogr/ > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: What is our technical debt? (fedora integration service)
Pavel, thanks for bringing this up! Funny thing is that you just described a lot of functionality of packit as a service :) getting events from multiple sources (fedora-messaging, CentOS' mqtt, GitHub webhooks, GitLab webhooks, prod/stg) and then have a mechanism to process those and provide updates. Big heads-up to everyone - it took us year+ to get such functionality, polish it, make it secure, scalable, auditable, maintainable. It's a ton of work. If there is anything we can do to help, please let us know. (one of the core components of packit's architecture is our library ogr [1], which serves as an abstraction layer on top of gitforge APIs - pagure, github, gitlab) [1] https://github.com/packit-service/ogr/ ___ 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? (fedora integration service)
On Tue, 7 Jul 2020 at 05:23, Pavel Raiskup wrote: > > Hi all, > > as a Copr contributor, I am missing a _standard_ design for integrating > our cool infrastructure into the _upstream_ work-flows. We have a lot of > teams trying to implement the same thing: > I think we need to work out what technical debt means. When I think of technical debt, I am thinking of: 1. All our infrastructure relies on PDC which has a dead upstream, no working replacement and more stuff needing to work from it. 2. Our mailing lists run on a beta of mailman3 and the current tools are not packaged completely 3. mailman3 vm has possible disk issues 4. We have other servers we found we could not install to newer versions but have to run on dead OS versions 5. Our account system, FAS2 runs on RHEL-6 (but is happier on RHEL5) 6. Our openshift is running on an older version but the newer version needs a lot of planning of what hardware is going where. 7. ... etc etc etc I expect there are other items of technical debt but a lot of these take up most of my 50 to 60 hour weeks so it is what I think of versus new workflows or other items. -- Stephen J Smoogen. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: What is our technical debt? (fedora integration service)
Hi all, as a Copr contributor, I am missing a _standard_ design for integrating our cool infrastructure into the _upstream_ work-flows. We have a lot of teams trying to implement the same thing: 1. Catch some upstream event (like push, pull-request, release, tag, ...) 2. React to the event. Do something with this event, (e.g. do CI build, Copr build, do some scratch build using Jenkins, etc.) 3. Ideally report back upstream, somehow, the results. By _standard_ I mean that (a) it should be absolutely trivial to start the Fedora Infra <-> Upstream interaction (to integrate) from the package contributor POV, and (b) that it should be _fairly simple_ to implement the reaction (point 2 and 3) inside our infra. Namely, consider that we in Copr want to trigger builds by the events from GitHub (PRs, tags, pushes, ...), GitLab (MRs, ...), Pagure, BitBucket, etc. We sort of are able to do so (it is far from complete support!), but for this to happen -- we had to implement pretty complicated webhook interface on Copr side for all the services, and for Pagure we have to listen on fedora-messaging bus. The real challenge though is _how to notify_ upstream projects that something inside our infra (eg Copr) happened. Nothing dramatic happened in Copr so far. We "only" have support for notifying Pagure ATM (we are able to set "commit status" for PRs and pushes). To be able to communicate with other forges, it would be an equivalent amount of repetitive work.. (we'd have to store somewhere the access "tokens", know how to/where contact the upstream, etc.). Quite some work, ... worth doing only once in whole Fedora? What I think we could have is something like a central gateway between Fedora and Upstream, let's say "Fedora Integrator"? That thing should cut out and provide the part of Copr code which does this integration steps: - It should "listen" on several forges (webhooks, on our bus, atm.), and translate the variously formatted event payloads into well-defined, uniform events. Say "change", "change request", etc. - Such an event would be dumped (back) on the fedora-messaging bus, through well-defined (schema) message. The bus part is important because it is (a) asynchronous and (b) even services behind corporate VPN can react on them. - Each such event would have its own ID, so **any** Fedora service can react on it by posting ReactsOn=EventID (again well-defined) "reaction" on fedora-message bus. - The Integrator service would be able to translate the "reactions" on bus to forge responses -- e.g., when CI passes, notify Pagure/GitHub/GitLab/... commit status, send an email to upstream, etc. I sketched a simple component graph how that could look like [1]. Feel free to comment here or there... the webhook/message payload translation mechanism should be somehow wrapped into a library, so we could still get the unified format of events without the integrator service (iff needed). This way we would build a single place for collaboration on such things (parsing the webhooks, forge interaction, etc.). But we would have a single orientation points for people who use our services for CI/CD (single "Fedora Integrator" GitHub app, GitLab.com "Fedora Integration", etc.). Not only that would be super easy to find -- such forge apps are also pretty privileged things (they can do various stuff with the repositories), so people might not be very confident they should enable them. If we had one blessed Fedora place to enable those things per forge, I think it would be more "trusted". Where to start? E.g. by using parts of github2fedmsg, copr and Packit service? We need to find a way to get the events on our bus easily, so I e.g. asked GitLab people [1] how to easily implement this. Do you think such initiative makes sense? [1] https://github.com/praiskup/fedora-integration-service [2] https://gitlab.com/gitlab-org/gitlab/-/issues/225151 Pavel On Thursday, June 25, 2020 9:27:24 PM CEST Pierre-Yves Chibon wrote: > Good Morning Everyone, > > Just like every team we have technical debt in our work. > I would like your help to try to define what it is for us. > > So far, I've come up with the following: > - python3 support/migration > - fedora-messaging > - fedora-messaging schema > - documentation > - (unit-)tests > - OpenID Connect > > What else would we want in there? > > > Looking forward to your thoughts, > Pierre > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list --
