Project

Profile

Help

Issue #7666

traceback when creating a repository on empty Pulp system

Added by bmbouter about 2 months ago. Updated about 2 months ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 83
Quarter:

Description

I am using pulpcore and pulp_file with source checkouts in a dev system.

I run `(pulp) [vagrant@pulp3-source-fedora32 pulpcore]$ pulp --no-verify-ssl file repository create --name file_repo1

I get this error:

/usr/local/lib/pulp/lib64/python3.8/site-packages/urllib3/connectionpool.py:981: InsecureRequestWarning: Unverified HTTPS request is being made to host 'localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn(
/usr/local/lib/pulp/lib64/python3.8/site-packages/urllib3/connectionpool.py:981: InsecureRequestWarning: Unverified HTTPS request is being made to host 'localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn(
Traceback (most recent call last):
  File "/home/vagrant/devel/pulp-cli/pulpcore/cli/openapi.py", line 182, in parse_response
    response_spec = method_spec["responses"][str(response.status_code)]
KeyError: '200'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/pulp/bin/pulp", line 11, in <module>
    load_entry_point('pulp-cli', 'console_scripts', 'pulp')()
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/pulp/lib64/python3.8/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/vagrant/devel/pulp-cli/pulpcore/cli/file/repository.py", line 52, in create
    result = ctx.obj.call(ctx.obj.create_id, body=repository)
  File "/home/vagrant/devel/pulp-cli/pulpcore/cli/common.py", line 23, in call
    result = self.api.call(operation_id, *args, **kwargs)
  File "/home/vagrant/devel/pulp-cli/pulpcore/cli/openapi.py", line 230, in call
    return self.parse_response(method_spec, response)
  File "/home/vagrant/devel/pulp-cli/pulpcore/cli/openapi.py", line 185, in parse_response
    response_spec = method_spec["responses"][
KeyError: '200'

The repository is not created since after that I show no repositories

(pulp) [vagrant@pulp3-source-fedora32 pulpcore]$ pulp --no-verify-ssl file repository list
/usr/local/lib/pulp/lib64/python3.8/site-packages/urllib3/connectionpool.py:981: InsecureRequestWarning: Unverified HTTPS request is being made to host 'localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn(
/usr/local/lib/pulp/lib64/python3.8/site-packages/urllib3/connectionpool.py:981: InsecureRequestWarning: Unverified HTTPS request is being made to host 'localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn(
{
  "count": 0,
  "next": null,
  "previous": null,
  "results": []
}

Associated revisions

Revision 553ede44 View on GitHub
Added by mdellweg about 2 months ago

Change default url to https://localhost

Document redirection issue with PUT and POST requests.

Fixes #7666 https://pulp.plan.io/issues/7666

Co-authored-by: bmbouter

History

#2 Updated by bmbouter about 2 months ago

I checked, and I pulled the latest pulpcore checkout and it reproduced for me. I reproduced it on 4ce5839868abbed6e6175777fdd1021343fd5c4c

#3 Updated by daviddavis about 2 months ago

From the server side on bmbouter's box, here are the logs:

Oct 07 19:01:18 pulp3-source-fedora32.localhost.example.com gunicorn[74594]: 127.0.0.1 - admin [07/Oct/2020:19:01:18 +0000] "GET /pulp/api/v3/docs/api.json HTTP/1.0" 200 389875 "-" "python-requests/2.24.0"                 
Oct 07 19:01:18 pulp3-source-fedora32.localhost.example.com gunicorn[74594]: 127.0.0.1 - admin [07/Oct/2020:19:01:18 +0000] "GET  /pulp/api/v3/repositories/file/file/ HTTP/1.0" 200 443 "-" "python-requests/2.24.0"    

Which differs from what I see:

Oct 07 19:07:51 pulp3-source-fedora gunicorn[21037]: 127.0.0.1 - admin [07/Oct/2020:19:07:51 +0000] "GET /pulp/api/v3/docs/api.json HTTP/1.0" 200 862405 "-" "python-requests/2.23.0"
Oct 07 19:07:51 pulp3-source-fedora gunicorn[21037]: 127.0.0.1 - admin [07/Oct/2020:19:07:51 +0000] "POST /pulp/api/v3/repositories/file/file/ HTTP/1.0" 201 402 "-" "python-requests/2.23.0"

#4 Updated by daviddavis about 2 months ago

  • Sprint set to Sprint 83

#5 Updated by mdellweg about 2 months ago

The best i could find is that requests is changing a POST to a GET on redirect. https://github.com/sindresorhus/got/issues/568

So what we can do:

  • disable redirects and deliver a proper error message; additionally change the default url to https://localhost
    • users need to specify http if they really want to
  • Always try https first and fall back to http (this sounds either inconsistent or insecure)

I'd opt for the first one to give full control to the user while defaulting secure (https and verify-ssl).

#6 Updated by mdellweg about 2 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to mdellweg

#7 Updated by bmbouter about 2 months ago

mdellweg wrote:

The best i could find is that requests is changing a POST to a GET on redirect. https://github.com/sindresorhus/got/issues/568

So what we can do:

  • disable redirects and deliver a proper error message; additionally change the default url to https://localhost
    • users need to specify http if they really want to
  • Always try https first and fall back to http (this sounds either inconsistent or insecure)

I'd opt for the first one to give full control to the user while defaulting secure (https and verify-ssl).

This not automatically working is surprising to me. I think every http tool I know handles this correctly, including requests which is the library in use here (I think). How can we understand more about why this isn't working automagically?

#8 Updated by mdellweg about 2 months ago

I do not want it to work automatically, as the user should explicitly use http if needed. If we do the lazy redirect to https, we send possibly sensitive data over plain http before getting the redirect to https. Therefore I prefer to fail in a way that the user uses the right address from the beginning. (Let's hope, his first command is status without authentication...)

#9 Updated by bmbouter about 2 months ago

mdellweg wrote:

I do not want it to work automatically, as the user should explicitly use http if needed. If we do the lazy redirect to https, we send possibly sensitive data over plain http before getting the redirect to https. Therefore I prefer to fail in a way that the user uses the right address from the beginning. (Let's hope, his first command is status without authentication...)

I agree with the use case you're saying, but this affects more than just http/https. For example, a reverse proxy redirects from https to https due to existing clients using one location, but the server side legitimately using it. This would also prevent that from working and that's legit. What do you think?

#10 Updated by pulpbot about 2 months ago

  • Status changed from ASSIGNED to POST

#11 Updated by ggainey about 2 months ago

  • Status changed from POST to ASSIGNED

State-change was due to me associating a PR with the wrong issue, apologies

#12 Updated by mdellweg about 2 months ago

  • Status changed from ASSIGNED to MODIFIED

Oh that was obfiscating then, that the association to my PR didn't work.

https://github.com/pulp/pulp-cli/pull/8

Please register to edit this issue

Also available in: Atom PDF