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?
On 05/15/2018 08:08 AM, Randy Barlow wrote:
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.
Makes sense.
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?
I think thats a fine idea, but do we know who we can contact to invite? And will we remember?
Thanks for going to the meeting and keeping us informed!
kevin
On Tue, May 15, 2018 at 05:01:56PM -0700, Kevin Fenzi wrote:
On 05/15/2018 08:08 AM, Randy Barlow wrote:
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?
It is kinda correct. We developed ursa-major specifically not-for-Fedora... and now that it exists, folks are asking if we can also use it in Fedora. I have nothing in my current plans (up through F29) to do anything with ursa-major in Fedora.. but, since people have started asking for it I guess we should talk about it.
Can I explain it?
First, some context on the name: rpms in a module are called "modular" rpms. RPMS not in a module are "bare". Sync "bare" is a homophone with "bear", and "ursine" means relating to or resembling bears, we jokingly call bare rpms "ursine" rpms......
So ursa-major does something with ursine rpms (bare, non-modular rpms). The problem is how to transition from our current mostly-bare-rpms-with-a-few-modules state to a future still-some-bare-rpms-but-with-many-more-modules state. There are some packages in Fedora that make sense to always be in the non-modular core. There are other packages in Fedora that make sense to modularize, of which we should provide multiple parallel versions. There is an intersection between these two groups that ursa-major tries to address: packages which should be modularized, but which are needed *in the buildroot for the non-modular core*. These are things like higher level language stacks which are used to build the docs or run the %check tests of lower level components -- all at build time.
The flow:
- ursa-major is a script that runs on message bus trigger. - It has a config that defines some set of module streams that should be tagged into the core buildroot. Releng maintains this config, as it affects the whole distro. - When ursa-major fires, it takes a new module (or a module that has passed testing, or which has gone stable) and adds its tag to the tag inheritance of the base build tag - say, the f30-build tag. - Then, when new ursine rpms are built in the traditional way, they have some subset of what would otherwise be modular rpms available.
To say again, I have no plans to seek to deploy this atm, but people have started asking for it... so, maybe we need some solution to the problem. It could be this tool or some other tool -- perhaps as a part of Bodhi's workflow: as modules get promoted, a select releng-maintained subset could be tagged into the base tag.
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.
Makes sense.
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?
I think thats a fine idea, but do we know who we can contact to invite? And will we remember?
Thanks for going to the meeting and keeping us informed!
I can come, and bring some others. :) If it is recurring, then a calendar thingie will help make us not forget.
I'd say let's not rely only on my team (Factory2) as an intermediary between you guys and the modularity-wg. Let's invite them too.
On Fri, May 18, 2018 at 9:42 AM Ralph Bean rbean@redhat.com wrote:
On Tue, May 15, 2018 at 05:01:56PM -0700, Kevin Fenzi wrote:
On 05/15/2018 08:08 AM, Randy Barlow wrote:
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?
It is kinda correct. We developed ursa-major specifically not-for-Fedora... and now that it exists, folks are asking if we can also use it in Fedora. I have nothing in my current plans (up through F29) to do anything with ursa-major in Fedora.. but, since people have started asking for it I guess we should talk about it.
Can I explain it?
First, some context on the name: rpms in a module are called "modular" rpms. RPMS not in a module are "bare". Sync "bare" is a homophone with "bear", and "ursine" means relating to or resembling bears, we jokingly call bare rpms "ursine" rpms......
So ursa-major does something with ursine rpms (bare, non-modular rpms). The problem is how to transition from our current mostly-bare-rpms-with-a-few-modules state to a future still-some-bare-rpms-but-with-many-more-modules state. There are some packages in Fedora that make sense to always be in the non-modular core. There are other packages in Fedora that make sense to modularize, of which we should provide multiple parallel versions. There is an intersection between these two groups that ursa-major tries to address: packages which should be modularized, but which are needed *in the buildroot for the non-modular core*. These are things like higher level language stacks which are used to build the docs or run the %check tests of lower level components -- all at build time.
The flow:
- ursa-major is a script that runs on message bus trigger.
- It has a config that defines some set of module streams that should be tagged into the core buildroot. Releng maintains this config, as it affects the whole distro.
- When ursa-major fires, it takes a new module (or a module that has passed testing, or which has gone stable) and adds its tag to the tag inheritance of the base build tag - say, the f30-build tag.
- Then, when new ursine rpms are built in the traditional way, they have some subset of what would otherwise be modular rpms available.
To say again, I have no plans to seek to deploy this atm, but people have started asking for it... so, maybe we need some solution to the problem. It could be this tool or some other tool -- perhaps as a part of Bodhi's workflow: as modules get promoted, a select releng-maintained subset could be tagged into the base tag.
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.
Makes sense.
The above was a slight mischaracterization. The modularity-wg provides requirements to the Factory-2 team for things needed to support modularity. We then, sometimes, build things for the Factory-2 team. However, in order to avoid x-ing wires or making mistakes, we (modularity-wg) do not provide schedules/timelines/etc for the work (even if we think we know them).
So, in the general sense, of course we are aware of the things we are asking for but we leave it to F2, Fedora Infra, and releng for when we are going to get them or coordinating how they will be released. The last thing we need is the modularity-wg promising, for example, ursa-major to fedora-infra when F2 has never even heard the decision.
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?
I think thats a fine idea, but do we know who we can contact to invite? And will we remember?
Thanks for going to the meeting and keeping us informed!
I can come, and bring some others. :) If it is recurring, then a calendar thingie will help make us not forget.
I'd say let's not rely only on my team (Factory2) as an intermediary between you guys and the modularity-wg. Let's invite them too.
And, to be clear, that was my original suggestion :). I think it is definitely necessary for both teams to have reps there. So, +1? :)
langdon
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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.fedorapro...
On Tue, May 15, 2018 at 11:08:14AM -0400, Randy Barlow wrote:
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
The fact that they are not familiar with Infra seems to me like a very good reason to be "involved" in their discussions to ensure new things aren't going to unforeseeably impact us (double negative are hard).
suggested instead that we interface with Factory 2.
I know that at least Patrick and I have regular meetings with Ralph to discuss the Factory 2/Infra interactions. I remember sending a report about such meeting once, I didn't do it much since, maybe I should start this again and stick with it (we had our latest meeting just the past Monday so I should just go ahead and send a report for this discussion).
Overall I am not against this, I just don't want to add more meetings to Ralph's agenda. So if we change format, then maybe Patrick and I's meetings should be reconsidered.
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
This is a good idea with the caveat that Kevin pointed out :)
Pierre
infrastructure@lists.fedoraproject.org