Bug 1303642

Summary:	[RFE] Create a single errata for all external dependencies for RHEV
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Eyal Edri <eedri>
Component:	Build Subsystem	Assignee:	Eyal Edri <eedri>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.0.0	CC:	asabadra, eedri, fdeutsch, lsurette, rbalakri, Rhev-m-bugs, sbonazzo, srevivo, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-30 12:32:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Rel-Eng	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1303638

Description Eyal Edri 2016-02-01 14:50:03 UTC

Description of problem:

Up until now (3.6) RHEV release was dependent on several packages that aren't built by the team but are crucial for RHEV release.

These packages are delivered within the RHEV channel and not RHEL, and are built 
usually by the KVM team.

The idea of this bug is to increase visibility of those pkg and increase control over their release date, so that they will be released as part of RHEVM channel rather than RHEV.

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

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Eyal Edri 2016-07-13 14:23:12 UTC

All packages that are tagged with rhevm-4.0-rhel-7-candidate in brew.
I would like to fetch it from errata instead of brew by using rhevm-4.0-rhel-7-pending tag.

Comment 3 Eyal Edri 2016-07-13 14:26:24 UTC

sorry, this one is related to another bug.
This is about creating another errata to manage external deps from platform so we'll have more control over what goes out or nor with RHEV releases.

not relevant for 4.0, moving to future.

Comment 5 Yaniv Kaul 2016-07-24 06:57:22 UTC

(In reply to Eyal Edri from comment #3)
> sorry, this one is related to another bug.
> This is about creating another errata to manage external deps from platform
> so we'll have more control over what goes out or nor with RHEV releases.
> 
> not relevant for 4.0, moving to future.

Is 4.1 a reasonable candidate for this? What needs to be done?

Comment 8 Yaniv Kaul 2017-03-12 08:27:38 UTC

(In reply to Yaniv Kaul from comment #5)
> (In reply to Eyal Edri from comment #3)
> > sorry, this one is related to another bug.
> > This is about creating another errata to manage external deps from platform
> > so we'll have more control over what goes out or nor with RHEV releases.
> > 
> > not relevant for 4.0, moving to future.
> 
> Is 4.1 a reasonable candidate for this? What needs to be done?

What's the latest on this?

Comment 9 Eyal Edri 2017-03-12 08:55:21 UTC

I am not sure we'll have a single ET for all dependencies, but I know Sandro has created one for 4.1 with RCM to hold all the pkg from optional.

So maybe its best to rename this RFE to an ET that will hold all the multi product pkg that were dropped from optional.

Sandro?

Comment 10 Sandro Bonazzola 2017-03-31 06:29:32 UTC

(In reply to Eyal Edri from comment #9)
> I am not sure we'll have a single ET for all dependencies, but I know Sandro
> has created one for 4.1 with RCM to hold all the pkg from optional.
> 
> So maybe its best to rename this RFE to an ET that will hold all the multi
> product pkg that were dropped from optional.
> 
> Sandro?

I haven't created an errata for all the packages. I've created one errata for each package. We have now a channel for RHV-M dependencies so we won't need to redo the optional packages tagging in 4.2.
I think we can close this bug wontfix.

Comment 11 Aviv Sabadra 2017-10-30 12:07:14 UTC

Can we close this as wontfix? Eyal? (trying to do some cleanup for rel-eng queue)

Comment 12 Eyal Edri 2017-10-30 12:25:05 UTC

Yes, we can close as won't fix as Sandro mentioned we're using a different approach for it, and for now still using multi-product errata mappings for external pkgs.