Bug 1649901 - Creating OSTree repository requires `--publish-via-http no`, but `yes` is assumed by default
Summary: Creating OSTree repository requires `--publish-via-http no`, but `yes` is ass...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hammer - Content
Version: 6.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-14 18:12 UTC by Mirek Długosz
Modified: 2020-01-15 20:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Mirek Długosz 2018-11-14 18:12:30 UTC
Since Bug 1315877 , OSTree repositories are required to be protected (published through HTTPS instead of HTTP). When creating new repository using hammer, this is achieved by `--publish-via-http no` flag.

This essentially makes that flag useless, as any other value will result in hammer command failure. Moreover, default value is not accepted as well.

Could we set this flag value to false automatically when repository of type ostree is created? This should improve user experience.


Version:
Satellite 6.5 snap 3
pulp-server-2.17.1-1.el7sat.noarch
katello-3.9.0-0.11.rc2.el7sat.noarch
foreman-1.20.0-0.17.RC2.el7sat.noarch
satellite-6.5.0-3.beta.el7sat.noarch
tfm-rubygem-hammer_cli-0.15.1-1.el7sat.noarch


Steps to reproduce:
1. Create product and remember its id
2. `hammer repository create --product-id :id --name ostree-test --content-type ostree --url 'http://mirror.centos.org/centos/7/atomic/x86_64/repo/'`


Actual results:
Could not create the repository:
  Validation failed: OSTree Repositories cannot be unprotected.


Expected results:
Repository is created; publish-via-http property of repository is set to false.

Comment 1 Brad Buckingham 2018-11-16 16:39:52 UTC
Is this a regression from 6.4?

Comment 2 Mirek Długosz 2018-11-19 12:53:13 UTC
No. It was also present in 6.4 and 6.3.

Comment 4 Bryan Kearney 2019-12-03 16:34:32 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 5 Bryan Kearney 2020-01-15 20:30:08 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

Comment 6 Bryan Kearney 2020-01-15 20:30:12 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.


Note You need to log in before you can comment on or make changes to this bug.