[Halld-controls] JInventory and slot number

[Elliott Wolin]

Hi,

After discussions with Hovanes (and his note below) it seems to make 
sense to just add fields to the JInventory system and not worry if they 
are not used for a lot of equipment.  An example is MAC address.  We can 
still keep the Telecom field, or I can rename it to something else when 
I add more fields.

Please send me suggestions for additional fields.  Note that some 
devices may have more than one value for the field, e.g. two MAC addresses.

Also, I think we've all agreed that slots should appear as entries in 
the JInventory system, so we don't need a field for the slot number.  
Note that currently every entry needs a unique "Property Tag,"  which 
just needs to be any type of unique string.  We'll need to come up with 
a scheme for slots and other items.  Or I can just eliminate the unique 
requirement, but this may cause problems, not sure.

Thanks,



On 05/14/2012 09:17 AM, Hovanes Egiyan wrote:
> I just realized that the "Telecom" field is now used for the slot 
> number, while
> I was thinking it keeps  it's IP address or/and port name on the
> console server.  Defining slot number as a part of the location and 
> using controls
> hierarchy will should define where it is and who is using it.
>
> Going back to "Telecom", I think we need some telecommunications 
> related fields like MAC address
> etc.  We probably  need to keep track of the IP names (addresses can 
> be found on
> the name servers) for the devices using Ethernet, and the name of the 
> ports on
> the terminal server for the devices using serial console. Some devices 
> have more than
> one Ethernet ports. Keeping track of all this is extra work, but 
> number of such devices is not
> very large, but large enough to create mess without being tracked.
> For modules that do not have Ethernet or serial ports we can use "N/A" 
> for these fields.
> The web page can have a section called "Telecom" where these fields 
> are shown or
> entered for the new items. I do not know if it is better to input the 
> IP name ourselves or use
> the MAC address to get the information from the computer center database.
>
> Hovanes.
>
>
> On 05/10/2012 11:20 AM, Elliott Wolin wrote:
>> Hi,
>>
>> Hovanes makes a very good case for doing what I at first thought 
>> wasn't a good idea.  It's also less work for me from a development 
>> point of view, but means more work for everyone else, i.e. having to 
>> enter more information into the database (not a big deal in my 
>> opinion, especially given the "save as new" feature).
>>
>> So, if you have an opinion, what do you think..should we include 
>> slots as separate items in the database, with housing parent, power 
>> parent, etc, supplying housing, power, etc. to a module?
>>
>> Thanks,
>>
>>
>>
>>
>> On 05/10/2012 10:19 AM, Hovanes Egiyan wrote:
>>> Hi Elliott,
>>>
>>> when I was exercising with IRMIS I actually used slot as
>>> a location type housed by the chassis, powered by the chassis,
>>> and controlled by the controller in the crate. Note that
>>> controller may or may not be housed by a slot, so it was one
>>> of the cases of different ordering of items in the three hierarchies.
>>> Same inversion applied for instance to the power supply of the crate 
>>> which can
>>> be considered to be inside the crate, controlled by something else,
>>> powered from the power strip, while the crate is powered by the 
>>> power supply.
>>>
>>> I do not see why "slot" is not a good item like a crate.  The housing
>>> hierarchy for A-B channel would be something like this:
>>> Bldg->[Floor]->Rack->Crate->Slot->Signal
>>>
>>> Hovanes.
>>>
>>>
>>> On 05/10/2012 09:50 AM, Elliott Wolin wrote:
>>>> Hi,
>>>>
>>>> Josh asked for a telecom field in the JInventory system, which I 
>>>> added.  In discussion with him we realized we need a place to put a 
>>>> slot number or range of slot numbers.
>>>>
>>>> The housing hierarchy holds the parent id, so e.g. the parent of an 
>>>> A-B module will be an A-B chassis.  But where to keep the slot 
>>>> number?  I was planning to eliminate the five location tables.  I 
>>>> could replace it with a single "location" field, but one that 
>>>> wouldn't be unique (there will be many slot 5's).  I could add a 
>>>> "slot" field specifically for this where you could enter a slot or 
>>>> range of slots (e.g. "5" or "1-2").
>>>>
>>>> Specifying a parent is adequate for many but not all cases.  E.g. 
>>>> the parent of an A-B chassis will be another entry corresponding to 
>>>> a rack.  But there is no point in entering "slots" as independent 
>>>> entries in the database.  Thus the need for an additional field.  
>>>> "Slot" may suffice, maybe "location" is better, not sure...
>>>>
>>>> Thoughts?  Suggestions?
>>>>
>>

-- 

				Sincerely,
					Elliott


================================================================================


  Those raised in a morally relative or neutral environment will hold
		    no truths to be self-evident.
				

Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365

================================================================================