Finishing modularity for Satellite

This is a tracking issue for the satellite folks.

In an email conversation with @ehelms, we discussed the satellite team need to build modules in Copr. An example of such module was - http://yum.theforeman.org/nightly/el8/x86_64/repodata/modules.yaml

We already fixed the first issue #2703 and it is now possible to submit your module for EPEL chroots. But there are follow-up issues that need to be fixed:

When I submit your YAML file, it creates the module in Copr but it doesn't submit any builds and therefore doesn't produce any results. When I implemented modularity support in Copr, there was no documentation on what it actually means to "build a module" (AFAIK it is still not documented and the reference manual is still "what MBS does"). I understood the concept as submitting builds from components.rpms and creating a repository from their results. So this is the only use-case that works. If I understand your use-case properly, your artifacts.rpms come solely from your dependencies.buildrequires, correct? We will need to implement this as well.
1576 - Each module is stupidly placed in its own repository, therefore it is not possible to enable a module repository on a user machine, and then update to a new module version once it is out. There is now an easy way to implement this in Copr, it just wasn't done yet.
1484 Modular dependencies (i.e. dependencies.buildrequires) are completely ignored. I think it should be easy to implement enabling them but it wasn't done yet.
There are some other unfinished things. For example it is not possible to delete modules and there is no API support for querying them

We can implement all of these for you @ehelms but it won't be cheap for us, so I wanted to ask you how much you are invested in building modules in Copr, what are your expectations, when do you need it, and anything that might be important to know.

Thank you

fedora-copr / copr

Finishing modularity for Satellite #2782

1576 - Each module is stupidly placed in its own repository, therefore it is not possible to enable a module repository on a user machine, and then update to a new module version once it is out. There is now an easy way to implement this in Copr, it just wasn't done yet.

1484 Modular dependencies (i.e. `dependencies.buildrequires`) are completely ignored. I think it should be easy to implement enabling them but it wasn't done yet.

fedora-copr / copr

Finishing modularity for Satellite #2782

1576 - Each module is stupidly placed in its own repository, therefore it is not possible to enable a module repository on a user machine, and then update to a new module version once it is out. There is now an easy way to implement this in Copr, it just wasn't done yet.

1484 Modular dependencies (i.e. dependencies.buildrequires) are completely ignored. I think it should be easy to implement enabling them but it wasn't done yet.

1484 Modular dependencies (i.e. `dependencies.buildrequires`) are completely ignored. I think it should be easy to implement enabling them but it wasn't done yet.