On Thursday, February 28, 2019 1:24:04 PM CST Chenxiong Qi wrote: > On Tuesday, February 26, 2019 3:32:01 AM CST Mikolaj Izdebski wrote: > > On Thu, Feb 21, 2019 at 6:42 AM Chenxiong Qi <cqi@xxxxxxxxxx> wrote: > > > This mail is for a new micro-service called Message-Tagging-Service (aka > > > MTS). It serves to tag module build triggered by specific MBS event. > > > More detailed information is provided inside RFR ticket[1]. > > > > Thanks for working on this. In the ticket I agreed to be a sponsor for > > this > > RFR. > > > > > MTS works with a series of predefined rules to see if a module build > > > should be tagged with one or more tags. There is requirement coming from > > > module maintainers to ensure a module build is tagged into correct > > > platforms to fulfill the dependencies of module metadata. Comment[2] has > > > a specific use case for that. > > > > As a packager and module maintainer I agree that currently there are > > problems with tagging modules into appropriate tags. From what I heard > > there are no plans for MBS to fix this and we are expected to use MTS > > instead. > > > > > So far, MTS has been containerized and deployed in internal. The image > > > is available from quay.io[3]. We would love to run MTS in Fedora as well > > > in order to make it easier to manage module build tag for module > > > maintainers and rel-eng. > > > > I believe that using containers is allowed and expected these days and > > that the part of RFR process that relates to having the software > > packaged for EPEL 7 can be skipped. > > > > > If anything is missed for this mail thread, please point out. Questions > > > welcome! Thanks for your time. > > > > I have a couple of questions: > > > > 1. As I understand, MTS is driven by a configuration file > > (mts-rules.yaml) that specifies which modules should be tagged with > > which Koji tags. Where is this configuration going to be stored? > > Upstream image on quay.io? Fedora ansible.git? A different git > > repository? > > Technically, the rule file could be anywhere that is accessible by a HTTP > GET operation to get the content. In practice to deploy MTS to Fedora, from > my point of view, it would be good for rule maintainers to use a git > repository so that they can review every changes to the rules. > > @infra and @rel-eng guys, which way do you prefer to maintain the rule file, > and what is your opinion of which git repository should be used for storing > the rule file? > > > 2. Who is going to maintain the above rules configuration? MTS > > maintainers listed in the ticket? Release engineering? > > I have the same question actually. My understand of "Maintainership > contacts" is just for the service maintenance. I think rel-eng could be > able to determine which tag(s) should be applied to a specific module > build. Hopefully, rel-eng could help to maintain the content of rule file. > @rel-eng, what do you think? > > > 3. MTS requires a Koji user (and corresponding Kerberos keytab) with > > no special permissions, which it would use to tag module builds. Koji > > users are managed by release engineering. Does release engineering > > agree to have MTS used in Fedora? I think it would be good to open a > > releng ticket for them to explicitly agree on the proposal. > > I wasn't aware of this yet. I'll file an ticket to ask for agreement. Ticket is created https://pagure.io/releng/issue/8176 > > > 4. Do the people listed as MTS maintainers agree to sign-up for its > > maintenance? It would be good if they at least acknowledged this in > > the ticket. > > @Luzi @Valerij Can you please ack in the ticket? > > > -- > > Mikolaj > > _______________________________________________ > > infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to > > infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedorap > > r > > oject.org _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
