Bug 219519

Making this a blocker as this already was discussed in the RHEL meeting.
Has to happen for Snapshot 4

Created attachment 143537 [details]
patch

rhel-instnum-1.0.6-1.el5 was built today.

A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

dave, this change is the only change i've seen re RHEL5 dictionary data. I'd
like to take one last look and compare the Java dictionaries to the "gold" or
latest python installer code. Can you tell me where to look? Joe.

Dave, I may have some sort of a problem with the options field encoded by the
java  installation number service we use to generate install numbers.  Some
questions:

1. is this the correct format of the install number:
     
KKKK KKKK KKKK KKKK KKKK KKKK CCCC CCCC OOOO OOOO OOOO OOSS SSVV VTTP PPPP PPPP

Note options is 14 bits. 


2. here is a java generated IN for the above format:  f9ec20 b7 f87 3 da20

I decode as follows:

kkkk kkkk kkkk kkkk kkkk kkkk cccc cccc oooo oooo oooo ooss  xxxx xxxx xxxx xxxx
 f     9   e    c    2    0    b    7     f   8    7    3      d    a    2   0
1111 1001 1110 1100 0010 0000 1011 0111 1111 1000 0111 0011  1011 1010 0010 0000

                 xor'd options are:     1111 1000 0111 00  (14 bits)
                 key bits               1111 1001 1110 11 
                 clear txt options:     0000 0001 1001 11 (binary) or 103 decimal

do you agree that the option code encoded is 103 decimal?

joe

more info. output from instnum.py shows wrong options, expecting 103 got
something else:

[jcanton@jcanton-workstation site-packages]$ ./instnum.py f9ec20b7f873da20
Product: RHEL Server
Type: Entitlement
Options: Premium FullProd Virt
Allowed CPU Sockets: Unlimited
Allowed Virtual Instances: Unlimited
Package Repositories: Server VT

key: 16378912 'f9ec20'
checksum: 183 'b7'
options: 784 'Premium FullProd Virt'
socklimit: -1 'Unlimited'
virtlimit: -1 'Unlimited'
type: 1 'Entitlement'
product: 0 'server'

{'Virt': 'VT', 'Base': 'Server'}

f9ec-20b7-f873-da20
[jcanton@jcanton-workstation site-packages]$

Here's how it works:

We decode the options portion of the IN. In this case, we end up with 103
decimal. That number is then used as an index into a table of all possible
combinations of options (combinationsMap in instnum.py). 

Here is an interactive python session that shows roughly the path from raw IN
string to actual options:

[dave@purdy rhel-instnum]$ python
Python 2.4.4 (#1, Oct 23 2006, 13:58:18) 
[GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from instnum import *
>>> in_string = 'f9ec-20b7-f873-da20'
>>> inum = InstNum(in_string)
>>> rawOpts = inum.getRaw(IN_OPTIONS)
>>> product = inum.getRaw(IN_PRODUCT)
>>> print rawOpts
103
>>> print combinationsMap[product][rawOpts]
784
>>> print "0x%x" % combinationsMap[product][rawOpts]
0x310
>>> print inum.get_options_string()
Premium FullProd Virt
>>> 

Does this help?

Created attachment 149564 [details]
rhel-opts-combs spreadsheet used to define products

Dave, the python code options map indicates 'Standard' as 0x8, but spreadsheet
used to define products seems to indicate 'Standard' is 0x2.  Seems like a
mismatch in spreadsheet definitions. Please look at row 106 in spreadsheet. This
row is for combination  103. Seems like wrong spreadsheet was used for product
definition. Do you concur?

Joe

optionsMap = {
	 PROD_SERVER : {
		0x1     : 'NoSLA',
		0x4     : 'Basic',
		0x8     : 'Standard',
		0x10    : 'Premium',
		0x20    : 'Devel',
		0x40    : 'Eval',
		0x80    : 'Level3',
		0x100   : 'FullProd',
		0x200   : 'Virt',
		0x400   : 'Cluster',
		0x800   : 'ClusterStorage',
		0x2000  : 'VirtPlatform',
		0x4000  : 'HPC',
		0x8000  : 'Directory',
		0x10000 : 'SMB' },:

There was a spreadsheet update in December which was distributed to Joe and me,
but not to Matt. So once he updates according to the current spreadsheet these
issues should be resolved.

The most current one is 20061019riek0, which one I sent out on December 12, 2006
(forgetting to cc Matt. Sorry for that.)

Here is 20061019riek1, which I sent out today to Matt. It has no change in the
combiantions from the riek0 one.

Created attachment 149588 [details]
rhel-opts-combs-planning-20061019riek1.ods - Possible Option combinations for RHEL5 GA