As a user i can manage modular content

[ipanova]

Sync/publish scenario

1. create and sync modular repo
2. validate that in the repo there are identified modulemd and modulemd_defaults.
3. publish repo.
4. validate that compressed modules.yaml doc is available in the repodata
5. test dnf client is able to install module from the metadata produced by pulp

Sync/copy scenario ( modulemd)

1. create and sync modular repo
2. copy module A , ensure destination repo has module A
3. copy recursively module B, ensure destination repo has modulee B + its rpms( artifacts)

Sync/remove scenario ( modulemd)

1. create and sync modular repo
2. remove module A, ensure its rpms are removed from the repo as well. Only not cross referenced rpms in other modules within the repo should be removed. This way we ensure we do not leave after us ursine modular rpm. ( ursine == modular rpm not belonging to any module)

Sync/copy scenario ( modulemd_defaults)

1. create and sync modular repo
2. copy modulemd-defauls A , ensure destination repo has modulemd-defaults A. Nothing else is carried over.

1 defaults per repo scenario ( modulemd_defaults)

1. create and sync modular repo
2. copy modulemd-defauls A , ensure destination repo1 has modulemd-defaults A. Nothing else is carried over.
3. upload modulemd-defaults A( same unit key, different content) yaml file. Ensure destination repo1 has just one modulemd-defaults A (we can have just one defaults of module A per repo).

Sync/remove scenario ( modulemd_defaults)

1. create and sync modular repo
2. remove modulemd-defaults A, ensure it was removed from the repo, Nothing else is removed.

Upload scenario ( modulemd and defaults)

1. upload a modules.yaml doc file that would containt 1+ of modulemd and 1+ of modulemd_defaults.
2. Ensure that pulp was able to parse the document by identifying correct content type modulemd and modulemd_defaults

[daviddavis]

A couple notes to add.

We set up a dnf repository that QE can use to test. There's a modules.yaml file in the repo data.

https://repos.fedorapeople.org/repos/pulp/pulp/fixtures/rpm-with-modules/

Also, here's the epic for modularity in redmine: https://pulp.plan.io/issues/3206

[daviddavis]

There's an issue we worked on as part of the modularity work that's rather hard to test so I probably wouldn't bother:

https://pulp.plan.io/issues/3874

If you do decide to create a smash test, I can help write out a scenario to test it.

[ragabala]

Hi @daviddavis , @ipanova

For Sync/remove scenario ( modulemd) :

On calling the actions/unassociate api, should the rpms also be removed from the repo along with modulemd? or just the modulemd data?

On calling /pulp/api/v2/repositories/<repo-id>/actions/unassociate/ with
{ 'override_config': {'recursive': True}, 'criteria': {'filters': {}, 'type_ids': ['modulemd']} }
The modulemd count became 0. But the rpm count remain unaltered after the action.
Is this as expected or am I missing anything here?

note:

I used the module (fixtures)[https://repos.fedorapeople.org/pulp/pulp/fixtures/rpm-with-modules/] url for the above repo.

[daviddavis]

@ragabala I don't know what the expected behavior is. Will have to look into the code and let you know.

[nixocio]

@daviddavis, I think @ragabala filed this issue https://pulp.plan.io/issues/3985 related to his question.

[daviddavis]

@kersommoura great, thanks.