Add result namespaces whitelist
ClosedPublic

Authored by mkrizek on Mar 2 2016, 4:13 PM.

Details

Summary

The patch doesn't solve checking if package can send result to it's namespace (only firefox can send results into pkg.firefox etc.) which will be added with dist-git style tasks support.

Test Plan

Use the following header in task formula:

name: checkname
namespace: qa
desc: download specified Koji build and run rpmlint on it
maintainer: jdoe

If namespace is omitted, scratch is used.

Worked for me.

Diff Detail

Repository
rLTRN libtaskotron
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
mkrizek retitled this revision from to Add result namespaces whitelist.Mar 2 2016, 4:13 PM
mkrizek updated this object.
mkrizek edited the test plan for this revision. (Show Details)
mkrizek added reviewers: tflink, kparal, jskladan.

Code as is looks OK, from the functional standpoint, but:

  1. how about just using checkname (i.e. the name key in the task formula's header) for it - qa.depcheck for example - it is in one place, and we can always just .split the text to separate the checkname and namespace
  2. if we go with separate namespace key, then I'd rather have it in the task's header (i.e. just below name), instead of an argument for resultsdb. I don't thing that it is, or should be resultsdb exclusive, but more of a general concept.
kparal added a comment.Mar 8 2016, 9:55 AM
  1. how about just using checkname (i.e. the name key in the task formula's header) for it - qa.depcheck for example - it is in one place, and we can always just .split the text to separate the checkname and namespace
  2. if we go with separate namespace key, then I'd rather have it in the task's header (i.e. just below name), instead of an argument for resultsdb. I don't thing that it is, or should be resultsdb exclusive, but more of a general concept.

My idea of how this would work was a bit different than current implementation. I thought the namespace would be determined automatically based on the git url, i.e. the user would not need to specify it (neither in checkname nor anywhere else). If we do that automatically, there is no space for user mistakes, and tasks are easier to write. We just need to make sure the final namespace+checkname is printed out visibly during reporting process. Is there a reason why we can't make this automatic?

But thinking more about this, there is definitely a use case for overriding the namespace - when you want to test some changes and submit to scratch or similar namespace. In this case we should make possible to redefine it manually. And in this case adding it as an argument to resultsdb directive makes sense. Or it can be a top-level argument in the formula as @jskladan says, both is fine (something like namespace_override?).

conf/taskotron.yaml.example
54–64 ↗(On Diff #1949)

I think this would deserve a separate config file, this seems similar to e.g. yumrepoinfo.conf - very specific and likely more and more expanding configuration.

Also, maybe we could install the default values into /usr/share, so that we can rely it's always there, and allow overriding this in /etc/, but not install it by default? (Thinking about this, we could do the same for yumrepoinfo.conf, I'd be happy to post a patch). For the moment and keeping this patch simple, we could do the same as the current approach of yumrepoinfo.conf, i.e. /etc/ or nothing, but if people agree with this, I'd then refactor it later.

55–56 ↗(On Diff #1949)

So why exactly is pkg in namespaces_safe? Shouldn't it also be in namespaces_whitelist, and only tasks from distgit be able to post into it?

libtaskotron/config_defaults.py
91–97 ↗(On Diff #1949)

If we go the route similar to yumrepoinfo.conf, we can drop this.

libtaskotron/directives/resultsdb_directive.py
186–187

It's true that this check is no longer needed. If this patch takes a longer time to fine-tune, maybe you can submit this separately, thanks.

209

Now it's just 'task', not 'taskfile'. Sorry :)

tflink requested changes to this revision.Mar 9 2016, 6:09 PM

The approach here seems fine but I'd like to see some more test coverage. Some "happy path" around just the namespace acceptance would be nice but I think that tests around behavior when reporting to an "unauthorized" namespace needs to be in place.

This revision now requires changes to proceed.Mar 9 2016, 6:09 PM
mkrizek updated this revision to Diff 1991.Mar 15 2016, 9:28 AM
  • Address issues in the review
mkrizek updated this object.Mar 15 2016, 9:30 AM
mkrizek edited the test plan for this revision. (Show Details)
mkrizek planned changes to this revision.Mar 15 2016, 9:32 AM
mkrizek edited the test plan for this revision. (Show Details)

Er, namespaces.yaml needs to be added to the spec file.

mkrizek updated this revision to Diff 1995.Mar 15 2016, 12:40 PM
  • Address issues in the review
  • Add namespaces.yaml to the spec file

Overall, looks good to me. I don't understand why you removed those yaml formula tests, though.

libtaskotron/directives/resultsdb_directive.py
225

"Skipping posting the results" sounds weird to me. Maybe "Not posting results"?

testing/test_taskformula.py
16

What's the thought process behind removing these tests?

mkrizek added inline comments.Mar 15 2016, 4:01 PM
libtaskotron/directives/resultsdb_directive.py
225

Thanks. Sounds good.

testing/test_taskformula.py
16

It tested this method:

def parse_yaml(contents):
    return yaml.safe_load(contents)

which I removed in this patch. Why would we want to test a method from yaml library? Did I miss something?

jskladan accepted this revision.Mar 16 2016, 8:20 AM
tflink accepted this revision.Mar 16 2016, 2:39 PM
tflink added inline comments.
testing/test_taskformula.py
16

I wasn't looking closely enough at what the tests were doing, point taken.

This revision is now accepted and ready to land.Mar 16 2016, 2:39 PM
kparal added inline comments.Mar 18 2016, 3:38 PM
libtaskotron/config.py
288

If you try to parse : or %, you'll get ParserError and ScannerError. There might be more. We should document the exceptions, and quite possibly even wrap them into TaskotronValueError or TaskotronConfigError. Unit tests for this would be nice here.

300–306

For both taskotron.yaml and yumrepoinfo.conf we raise TaskotronConfigError and crash when the config file is missing or invalid. I think we should do the same here, in order to have consistent behavior. (Also, if you detect incorrect values, please print out at least a warning).

libtaskotron/directives/resultsdb_directive.py
206–226

Can we get a comment what this whole block is about? Thanks.

217

Can you include the filename you were looking for in the error message? Maybe we could also mention that the remove needs to be named origin.

libtaskotron/executor.py
85

This is nicer:

self.formula.get('namespace', 'scratch')
testing/test_resultsdb_directive.py
86

Can you please explain this? The test suite failed when building rpm, but not when run manually? Do you know why?

mkrizek added inline comments.Mar 21 2016, 4:46 PM
libtaskotron/config.py
288

While true, it's out of scope of this patch. I just moved the method from other file. I'll fix it in different DR.

300–306

If the config is missing or is invalid, parse_yaml_from_file will crash. In my mind, this code has the same purpose as config_defaults.py. Point taken on printing a warning though.

libtaskotron/directives/resultsdb_directive.py
206–226

+1

217

+1

libtaskotron/executor.py
85

Ah, I always forget the get method. :/

testing/test_resultsdb_directive.py
86

Because it didn't find the config file namespace.conf in the building env. I just realized I should have dealt with this the same way as we do with our main config (not touching files in testing profile).

kparal accepted this revision.Mar 23 2016, 2:42 PM
kparal added inline comments.
libtaskotron/config_defaults.py
83 ↗(On Diff #1995)

Hm?

kparal added inline comments.Mar 23 2016, 2:44 PM
libtaskotron/config_defaults.py
83 ↗(On Diff #1995)

Disregard this comment, for some reason I saw it reversed, and now it's not even a part of the diff. /me is confused.

This revision was automatically updated to reflect the committed changes.