Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 456532

Summary:	Systems: Profiles do not utilize package architecture
Product:	[Community] Spacewalk	Reporter:	Brad Buckingham <bbuckingham>
Component:	WebUI	Assignee:	Brad Buckingham <bbuckingham>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	low	Docs Contact:
Priority:	medium
Version:	0.1	CC:	cperry, jremy, pkilambi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-22 16:29:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	456552

Description Brad Buckingham 2008-07-24 13:56:45 UTC

Description of problem:

Systems -> Stored Profile -> Packages & System -> Software -> Profile

Package profiles do not include the package architecture information. As a
result, if an i386 package is removed from an x86_64 client and the users
performs a profile comparison, they will see that the package is missing;
however, performing a sync from the profile to reinstall it on the client
results in the x86_64 package being installed. (Note: package arch information
is not received from the server during rhn_check) 

From initial analysis, impacts to schema and UI are anticipated.

How reproducible:
Always

Steps to Reproduce:
1. select Systems
2. select an x86_64 system
3. select Software -> Packages -> Profiles
4. Create System Profile

5. remove an i386 package (e.g. libjpeg) from the client -> (Note: you might
want to install one before creating the profile above)
6. select System -> Software -> Packages -> Profile -> Compare to compare the
profile previously created to the system
7. you should see the package that was removed as a "difference" between the
profile and the system... select the package and perform "Sync Packages"
8. on the client, perform rhn_check -vvv at the appropriate time to have the
package re-installed on the client
  
Actual results:
- The profile that gets created (in 4) and then the comparison (in 6) do not
account for package architecture.  It is neither stored in the DB nor displayed
to the user.
- The package that is resynced to the client (in 8) will be the x86_64 version
of the package (assuming that both an i386 & x86_64 exist) vs the i386 version
that was previously installed

Expected results:
- When creating a profile, we should have the ability to store the architecture
of the packages that are associated with the system; otherwise, we are not
accurately reflecting the differences when comparing profiles.
- When performing the profile comparisons, we should display to the user details
on the architecture so that they can see if there is such a difference that exists.

Additional info:

https://fedorahosted.org/spacewalk/wiki/MultiArchEnhancements - Refer to wiki
page for more details on this issue. This page contains proposed solution;
however, since the solution details can change as the issue is further
investigated, it is not being included in the bug report.

Comment 1 Brad Buckingham 2008-12-09 16:12:46 UTC

Modifications made to system stored profiles to support arch.  This included changes such as the following:

- ported the following pages to java: 
  /network/profiles/list.pxt 
  /network/profiles/details.pxt
  /network/profiles/package-list.pxt
  /network/profiles/delete.pxt

- added package_arch_id to rhnServerProfilePackage
- profile creation (systems/details/packages/profiles/Create.do) updated to 
  populate package_arch_id
- profile comparisons (systems/details/packages/profiles/CompareProfiles.do & 
  systems/details/packages/profiles/CompareSystems.do) updated to include arch 
  in comparison and show in comparison results
- syncing (rhn/systems/details/packages/profiles/SyncSystems.do & 
  systems/details/packages/profiles/SyncProfiles.do) updated to include arch id 
  in the action that is scheduled and then picked up by rhn_check

- Systems -> Stored Profiles (profiles/List.do) new java pg replacing list.pxt
- Systems -> Stored Profiles -> Profile (profiles/Details.do) new java pg 
  replacing details.pxt
- Systems -> Stored Profiles -> Profile -> Packages (profiles/PackageList.do)
  new java page to replace package-list.pxt.  The new page includes listing of 
  pkg arch.
- Systems ->Stored Profiles -> Profile -> Delete Profile (profiles/Delete.do) 
  new java page to replace delete.pxt

Comment 2 Brad Buckingham 2008-12-17 16:29:10 UTC

Git commits related to this bz include:

36e376667111909d47e5b8a1dbc7891d47f79442
949a5f3304b141fae8c948c90b86e33cb2a5f223
171e3ed99c68b5fe996128b34f5e1948f3ba4a32
6d64814fa80c6def11bf3633cc8e6451b3949fac

Comment 3 Brad Buckingham 2009-01-15 19:56:59 UTC

verified with spacewalk-java-0.4.14-1.el5, spacewalk-schema-0.4.15-1.el5

verified Systems->System->Software->Profiles->Create
verified Systems->StoredProfile - content looks good

verified System->Software->Profiles->Compare profile w/no diff expected
verified System->Software->Profiles->Compare profile w/ diff expected
verified System->Software->Profiles->Compare profile-> Sync Pkgs

verified System->Software->Profiles->Compare systems w/diff expected
verified System->Software->Profiles->Compare systems-> Sync Pkgs

attempting to delete the Stored Profile is generating an ISE.  This BZ will be moved to verified and a separate BZ (480233) has been created to track this failure.  Using this approach, since this BZ (456532) addressed many issues related to stored profiles.

Comment 4 ice 2010-11-22 18:38:23 UTC

It seems that the architecture information in stored profiles is only avaliable for stored profiles taken on EL5 clients or newer, but not on EL4 clients?

reproduction:

1. registering a el4.7 (in my case) desktop client to spacewalk and putting it into el4.7 base channel.
2. creating a stored profile (system -> software -> packages -> profiles -> create profile) like "profile basic"
3. installing some additional packages
4. creating a stored profile again like "profile additional packages"

5. synching the client to the basic profile works fine, cause the rhn_check on the client has only to remove packages.

6. But then! synching the system to "profile additional" will fail after the click on "schedule" button because the stored profile has no architecture information - so in the column "channel" there is "none". I understand it like the package e.g. "gedit.i386" is in the channel 4.7 i386, but the package "gedit" with no architecture information is in no channel, so not findable, so synch is not possible.

hope it's easy to reproduce, if not just ask me :P

cheerio

Comment 5 ice 2010-12-16 16:43:06 UTC

If you have undefined architecture information in the softwre list of a rhel4.x client use the latest up2date package.

In rhel4.8 a working up2date version is already integrated (up2date-4.8.1-33.el4.i386 works fine)

Attention! If you get the spacewalk-client tools from
http://stahnma.fedorapeople.org/spacewalk-tools/4/i386/

REMOVE!! the up2date version (up2date-4.6.2-7.el4.1.i386.rpm) from the client-tools package

It has the architecture bug not fixed and does not send the architecture information to the spacewalk platform.

And by some strage reasons, up2date-4.6.2-7.el4.1.i386.rpm is shown as update for
up2date-4.8.1-33.el4.i386 when the client is attached into spacewalk and has client-tools channel available. "Updating" to 4.6.2... will mess your architecture information again.

hope someone saves his time with that hint :P

cheerio