Story #3927
closedAs a user, I can upload information about Consumer
100%
Description
As a result of this story the user will be able to upload a set of reports about a consumer. The payload will look like this:
{
"content_type": "modulemd",
"profile": [{"name": "duck",
"stream": 0,
"version": "20180730233102",
"context": "deadbeef",
"arch": "noarch"},
{"name": "flipper",
"stream": 0.71,
"version": "20180707144203",
"context": "c0ffee42",
"arch": "x86_64"}
]
}
{
"content_type": “rpm",
"profile": [ {"name": "duck_the_second",
"version": 2,
"release”: "livebeef",
"arch": "noarch",
"epoch": "default",
“vendor”:”RH”},
]
}
The "profiles" field on the actual module object reflects the enabled profiles for that module.
Pulp's applicability APIs will then be able to use this profile to calculate applicability to a consumer.
Profile for rpm type seems to be the same as before, so no migration is needed.
Related issues
Updated by dkliban@redhat.com about 6 years ago
- Sprint/Milestone deleted (
2.18.0)
Updated by ttereshc about 6 years ago
- Blocks Story #4058: As a user, I can calculate applicability for modular content added
Updated by ttereshc about 6 years ago
- Subject changed from As a user, I can upload a Consumer Profile for 'modulemd' content type. to As a user, I can upload information about Consumer
- Description updated (diff)
Updated by ttereshc about 6 years ago
- Description updated (diff)
How/where to store info about enabled modules?
I think that enabled modules semantically are closer to enabled repositories.
We have a consumer_bindings collection. We can create a new collection for mapping of a consumer and modules.
Alternatively, profile for modulemd type can be stored on the consumer_profiles collection, just under different type, not rpm.
But then repo_profile_applicability would need to refer to both of these profiles (or to hash from two profile hashes).
I think the former option is more clear and straightforward.
Any preference or other suggestions?
Updated by jortel@redhat.com about 6 years ago
ttereshc wrote:
Alternatively, profile for modulemd type can be stored on the consumer_profiles collection, just under different type, not rpm.
But then repo_profile_applicability would need to refer to both of these profiles (or to hash from two profile hashes).
This ^ is why the profiles collection supports type. It is intended to store more than just installed rpms and I think would be the appropriate place to inventory enabled modules.
Updated by ttereshc about 6 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
Updated by ttereshc about 6 years ago
- Related to Test #4158: Test applicability for modular or mixed content added
Added by ttereshc about 6 years ago
Updated by ttereshc about 6 years ago
- Status changed from ASSIGNED to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulp_rpm:3a9a314b0bceb1ddcff0edf91a0d54f5e75f9878.
Updated by ttereshc almost 6 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
Applicability calculation supports modularity content
closes #4058 https://pulp.plan.io/issues/4058
closes #3925 https://pulp.plan.io/issues/3925
closes #3927 https://pulp.plan.io/issues/3927