Bug 1726457

Summary:	Unable to export content-view that has atleast one non-yum type repo
Product:	Red Hat Satellite	Reporter:	Chris Roberts <chrobert>
Component:	Inter Satellite Sync	Assignee:	Chris Roberts <chrobert>
Status:	CLOSED DUPLICATE	QA Contact:	Perry Gagne <pgagne>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.5.0	CC:	arahaman, dvoss, hk, mmccune, spetrosi, zhunting
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-09-13 20:07:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Roberts 2019-07-02 22:04:34 UTC

Description of problem:
Currently hammer checks all content view repos to see if they are a yum type and if they are not exit out with an error message. We need to be more flexible with the repos so in case a user wants to still export that content view with yum but ignore the other non-yum content

Version-Release number of selected component (if applicable):

Red Hat Satellite 6.5
tfm-rubygem-hammer_cli_katello-0.16.0.11-1.el7sat.noarch


How reproducible:


Steps to Reproduce:
1. Sync a yum repo and create a product/repo of a non-yum type
2. Put that all into a content view and publish
3. Try to export

Actual results:
hammer -u admin content-view version export --id 44  --export-dir /root/

Could not export the content view:
  Error: The Repository 'demo-file' is a non-yum repository. Only Yum is supported at this time. Please remove the repository from the Content View, republish and try the export again.

Expected results:
Have Hammer have the ability to be able to only grab the yum units out of those content views and be more relaxed on the checks

Additional info:

Comment 6 Chris Roberts 2019-09-13 20:07:36 UTC


*** This bug has been marked as a duplicate of bug 1671319 ***