7:28 a.m.
Hi Ralph,
sorry for late reply. We never really standardized what namespaces are used
for and how they should look like. My original idea (but not all of us
agreed on that) is that there's dual purpose:
a) quickly identify ownership of the test
b) allow to implement write permissions into that namespace
So, there could be namespaces like these:
qa. - tasks maintained by our team
pkg.firefox. - tasks maintained by packagers for firefox
group.workstation. - tasks maintained by workstation group members
fas.threebean. - tasks maintained by FAS user threebean
scratch. - free-for-all playground
With this, we'd be able to restrict write access to these namespaces only
to certain git repos (for pkg.firefox, it would be
distgit/rpms/firefox.git, for qa, it would be pagure/qa/*, etc).
But we ended up with dist instead of qa, meaning something like
distribution generic tasks (mainly under our ownership or supervision, but
not always), and the permissions are not fully strictly checked - we can't
give abicheck access to just dist.abicheck., so it has full access to qa.
right now. OpenQA now submit results without identifying itself in the
namespace+testcase string, exactly because we haven't agreed on namespace
standards. So that's the current state.
The item_type is supposed to distinguish what got tested (sometimes it's
somewhat obvious from the namespace, like pkg., sometimes not, like qa.).
But the granularity hasn't been decided either, so we don't really know if
we want to have just *git_commit* type or *pagure_git_commit*,
*github_git_commit*, etc. Or whether we want to have type *image*, or
*cloud_image*, *atomic_image*, etc. I hope that now the interest surged for
taskotron and we don't really keep up with requests, people will help us
out in defining these blank spots (and maybe even implementing some of
those:)).
As for your particular usage, I think these sound reasonable:
- <team>.dva namespace, where <team> is the team responsible for these
kind of checks, like qa, infra, releng
- dist.dva namespace meaning it's a distribution generic task (running
on just certain distribution artifacts, but still generic), and it's
obvious who cares for these dist tasks or you don't care about permissions
- cloud.dva namespace if you want to put all cloud-related tasks into
the same namespace (so that you can query it easily afterwards), and are
going to limit access more granularly (dva tool could only write into
cloud.dva namespace), or don't care about permissions
- item_type=ami for all of the above, or perhaps item_type=image if it
looks the same as any other image and the tasks should be able to run on
any image type
From your email I got the impression that you're going to post the results
into an internal database. If I misunderstood and this is intended to be
submitted to Fedora's ResultsDB, I think I'd prefer dist.dva namespace,
because that's where all our existing tests are. Once we have a clearer
view how we want to organize namespaces, we can shuffle all of them at the
same time.
On Fri, Mar 31, 2017 at 9:14 PM, Ralph Bean <rbean(a)redhat.com> wrote:
Looking for opinions here. We're putting together something
internally to put results about AMIs in resultsdb and the question
arose: what should we use for the top-level namespace?
- ami.sometool.sometest.somesubtest
- cloud.sometool.sometest.somesubtest with item_type=ami
- something else?
Ralph
p.s., the test tool here is "dva" https://github.com/RedHatQE/dva
p.p.s., how should I interpret the "dist" namespace? I've always read
it as "distro level check", i.e., something that fedora-qe enforces
distro-wide.
_______________________________________________
Resultsdb-users mailing list -- resultsdb-users(a)lists.fedoraproject.org
To unsubscribe send an email to resultsdb-users-leave@lists.
fedoraproject.org