11:41 p.m.
Hi all,
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].
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.
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.
If anything is missed for this mail thread, please point out. Questions
welcome! Thanks for your time.
[1] https://pagure.io/fedora-infrastructure/issue/7563
[2] https://pagure.io/fedora-infrastructure/issue/7563#comment-553774
[3] https://quay.io/repository/factory2/message-tagging-service
--
Regards,
Chenxiong Qi
1:32 p.m.
On Thu, Feb 21, 2019 at 6:42 AM Chenxiong Qi <cqi(a)redhat.com> 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?
2. Who is going to maintain the above rules configuration? MTS
maintainers listed in the ticket? Release engineering?
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.
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.
--
Mikolaj
11:24 p.m.
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(a)redhat.com>
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.
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(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)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.fedorapr
oject.org
12:17 a.m.
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(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-leave(a)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.fedorap
> r
> oject.org
3:23 p.m.
On 2/27/19 9:24 PM, 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(a)redhat.com> 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?
I guess the easiest would be the fedora infrastructure ansible repo.
We could use releng repo too I suppose. Mohan: any thoughts?
>
> 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?
I think releng makes sense to maintain this yes.
Is it likely to change a lot?
kevin
1:41 a.m.
On Sunday, March 3, 2019 5:23:20 AM CST Kevin Fenzi wrote:
On 2/27/19 9:24 PM, 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(a)redhat.com> 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?
I guess the easiest would be the fedora infrastructure ansible repo.
We could use releng repo too I suppose. Mohan: any thoughts?
>> 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?
I think releng makes sense to maintain this yes.
Is it likely to change a lot?
I'm not sure if I'm a right person to answer this question. :) But, base on
the experience of internal usage so far, I guess once a set of rules are
determined to tag specific module builds, it should not be changed a lot
except new rules to be added. It should be case by case for the use in Fedora.
We could learn more after MTS is up to serve the tagging.
Regards,
Chenxiong Qi
kevin
8:53 p.m.
On Sunday, March 3, 2019 5:23:20 AM CST Kevin Fenzi wrote:
On 2/27/19 9:24 PM, 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(a)redhat.com> 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?
I guess the easiest would be the fedora infrastructure ansible repo.
We could use releng repo too I suppose. Mohan: any thoughts?
Hi Mohan, any thoughts so far?
What should I do to request a repo in whatever releng repo or the fedora
infrastructure ansible repo?
>> 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?
I think releng makes sense to maintain this yes.
Is it likely to change a lot?
kevin
5:17 p.m.
On 3/18/19 6:53 PM, Chenxiong Qi wrote:
On Sunday, March 3, 2019 5:23:20 AM CST Kevin Fenzi wrote:
> On 2/27/19 9:24 PM, 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(a)redhat.com> 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?
>
> I guess the easiest would be the fedora infrastructure ansible repo.
> We could use releng repo too I suppose. Mohan: any thoughts?
Hi Mohan, any thoughts so far?
What should I do to request a repo in whatever releng repo or the fedora
infrastructure ansible repo?
Well, it wouldn't be a seperate repo, it would just be some content
added to our ansible repo. :)
So, once you have content, I guess open a fedora-infrastructure ticket
and we can get it added. We hope to have PR support soon, so if thats
ready you could also just submit a PR with the new files.
kevin
1857
days inactive
1884
days old
infrastructure@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Chenxiong Qi -
Kevin Fenzi -
Mikolaj Izdebski