Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

load_templates: Create groups that do not exist #2770

Merged
merged 1 commit into from
Feb 26, 2020

Conversation

kalikiana
Copy link
Member

@kalikiana kalikiana commented Feb 25, 2020

The new code uses form => syntax to post without making use of the query and also is_success to bail out.

Fixes: poo#60118

@kalikiana kalikiana self-assigned this Feb 25, 2020
@kalikiana kalikiana changed the title load_templates: Create gropus that do not exist load_templates: Create groups that do not exist Feb 26, 2020
@kalikiana kalikiana force-pushed the load_templates_create_group branch 3 times, most recently from 54b301d to a7a931e Compare February 26, 2020 13:46
@kalikiana
Copy link
Member Author

There was a TODO block in the unit test, which used an OOO dump because of the following type of error:

ERROR: Group openSUSE Argon created but no id returned at ~/dev/openQA/repos/openQA/script/load_templatesline 162, <> line 8261.

The server seemed to create an OK response with no JSON.

@andrii-suse pointed me towards MOJO_MAX_LINE_SIZE which seemed to work around the problem until finally with the assistance of @perlpunk it was revealed that the query calls cause values like version= to be merged into the top-level query. This wasn't clear because our API has no guards against unexpected values.
The solution finally was to use the signature form => of Mojo::UserAgent without the use of the query.

I'm going to propose another PR to update other code paths with the more reliable API uses. This branch is now back to the original fix.

@kalikiana kalikiana marked this pull request as ready for review February 26, 2020 13:55
Copy link
Contributor

@perlpunk perlpunk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would still propose to use a local $url variable, instead of modifying the global one.

There can be other manipulations to that variable that are not wanted.

So wherever the $url variable is used, replace that with:

my $copy = $url->clone;
# work with $copy

Move from query to form => syntax and use is_success in new code.

Fixes: https://progress.opensuse.org/issues/60118
Copy link
Contributor

@andrii-suse andrii-suse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added comments with two observations, otherwise the change is fine with me

# Create the group first
my $job_groups_url = $url->clone->path($options{'apibase'} . '/job_groups');
my $res = $client->post($job_groups_url, form => {name => $entry->{group_name}})->res;
print_error $res unless $res->is_success;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we intentionally continue on error here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't anymore. In another branch I made print_error fatal and I'm changing other call sites bit by bit.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #2776 for the follow-up branch

@@ -58,22 +58,16 @@ is $ret, 255, 'error because of insufficient permissions';
$apikey = 'ARTHURKEY01';
$apisecret = 'EXCALIBUR';
$args = "--host $host --apikey $apikey --apisecret $apisecret $filename";
combined_like sub { $ret = run_once($args); }, qr/Job group.+not found/, 'Invalid job group';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks we removed scenario when 'Job group not found' is returned. (just observation)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. This is because we do handle the case of creating the group now.

kalikiana added a commit to kalikiana/openQA that referenced this pull request Feb 26, 2020
This is a follow-up to os-autoinst#2770. Re-using the URL can lead to problems
which are difficult to diagnose. Instead we should always use the form
style which works for get, put and post.
@codecov
Copy link

codecov bot commented Feb 26, 2020

Codecov Report

Merging #2770 into master will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #2770      +/-   ##
=========================================
- Coverage   92.21%   92.2%   -0.01%     
=========================================
  Files         190     190              
  Lines       11821   11821              
=========================================
- Hits        10901   10900       -1     
- Misses        920     921       +1
Impacted Files Coverage Δ
lib/OpenQA/WebAPI/Controller/API/V1/JobGroup.pm 98.01% <ø> (ø) ⬆️
lib/OpenQA/Worker/Settings.pm 84.9% <0%> (-13.21%) ⬇️
lib/OpenQA/Worker/WebUIConnection.pm 84.12% <0%> (-0.43%) ⬇️
lib/OpenQA/Scheduler/Model/Jobs.pm 91.49% <0%> (+2.83%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a487f6...a291931. Read the comment docs.

@okurz okurz merged commit d500881 into os-autoinst:master Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants