Open mbrysa opened 9 years ago
Sound good to me. I'd call it msg2releases(msg, **config)
, but what should the return value look like?
I suggest a list of dicts:
[
{
"name": "Fedora",
"release": "22",
"arch": "x86_64",
},
{
"name": "CentOS",
"release": "7",
},
]
where any of the fields is optional. This would nicely fit the FAF use case, but we should probably think about others as well :-)
That works for me. I thought for a little bit about trying a dict of lists (instead of a list of dicts) and I think it might be nicer to use at first. Something like this:
{
"Fedora": {
"releases": ["22", "21"],
"arches": ["x86_64"],
},
"CentOS": {
"releases": ["7"],
}
}
You could easily check that a message is about Fedora by writing:
if "Fedora" in msg2releases(msg, **config):
print "Yes"
Whereas checking that a message is "about Fedora" with your proposed message format is a little more cumbersome:
if any([r.get("name") == "Fedora" for r in msg2releases(msg, **config)]):
print "Yes"
.. but we lose some information with my format.
Say we have a FAF message that's about Fedora 22 x86_64 and Fedora 21 arm. The "easy to use" format I suggested above can't express that, but yours can... so, let's use yours. :)
From Fedora infrastructure, I can also imagine these using it as publishers:
As consumers:
Can you come up with something else?
I'd say the list of dicts approach should work reasonably well for all. A single dict could even be enough for all publishers except for FAF.
Apparently, for the purposes of FAF, it's useful to further filter notifications by OS name (and while we're at it also release and architecture): https://github.com/abrt/faf/issues/432
Do you think it would make sense elsewhere as well? Would it warrant creating a
os_releases
method inmeta.base.Base
similar topackages
andusernames
, and a general filter in FMN? (E.g. filtering out EOL releases, focusing on rawhide, CentOS etc.)Note that the message might have multiple OS names+releases associated with it.