RFC 5 Extension RSS DB

Authors: M. Ubeda Garcia

Last Modified: 11.VI.2012

The mapping between CS and RSS database schema design must be done in such way that is completely transparent. In order to cope with it, and given that the CS Resources section design has been agreed, the RSS DB will follow its structure.

Before defining the Database schema, few comments.

a) The RSS databases rely on the ( badly named ) MySQLMonkey module which works on top of the MySQL DIRAC module. The latest functionalities added to the latest take care of most of the extra properties on the first, its a matter of time to have them converging.

b) Database definition will be written on python.

c) The database module will have only four methods:

• insert
• update
• get ( select would make more sense )
• delete

d) StatusType, defined in the CS. Whatever makes sense for the element ( e.g. ReadAccess, WriteAccess, empty... )

RSS needs one set of tables per resource level. The sets of tables are identical, the only difference can be found on the information hosted. Having said that, we can have a UNIQUE set of tables where all information can be hosted, or keep the first approach, with a set of tables per resource level. The UNIQUE set approach is discarded, it makes much easier and cleaner design having a set of tables per resource.

As the set of tables is identical, tables will be defined as Element ( e.g. ElementStatus ). Then, tables will be created using CREATE Resource LIKE Element ( e.g. CREATE SiteStatus LIKE ElementStatus ).

The proposed set of tables is:

• a) ElementStatus
• b) ElementLog
• c) ( ElementHistory )
• d) ElementPresent
• e) ( ElementScheduled )
• f) ( Element )

a) ElementStatus

Without any doubt, the most important table. It keeps the status of the element, plus further information mainly used by RSS internally.

• ElementStatus
  • Name
  • StatusType
  • Status
  • Reason ( human readable reason )
  • DateEffective ( status dateEffective )
  • LastCheckTime
  • TokenOwner ( owner of the status, can be RSS or a human )
  • TokenExpiration

b) ElementLog

This table is only interesting for monitoring and debugging purposes, I'd make it a ARCHIVE table indeed, instead of InnoDB. It is mainly a logs table. Every time there is a change in the ElementStatus table, a new entry is registered here ( if the appropriated flag in the CS is Active ).

• ElementLog
  • UID
  • Name
  • StatusType
  • Status
  • Reason
  • DateEffective
  • DateEnd
  • TokenOwner
  • TokenExpiration

c) ElementHistory

A variant of this table, ElementHistory can be also put into place. This table would keep entries that have a different status for a given name, statusType pair than the previous entry. The information in this table is used by the web portal mainly.

d) ElementPresent

Can be a table or a VIEW as it is now. It turns to be very handy to have in the same row the current and the former status of an element. It exists because it is convenient to have such table.

• ElementPresent
  • Name
  • StatusType
  • Status
  • FormerStatus
  • DateEffective
  • FormerDateEffective

e) ElementScheduled

DownTimes are a good use case for the ElementScheduled table. If we know beforehand the status for an element, we enter it on the system, and it will handle it. ( This part is not active currently ).

• ElementScheduled
  • Name
  • StatusType
  • Status
  • Reason
  • DateEffective
  • DateEnd
  • TokenOwner

f) Element

The existence of this table is uncertain. We can get the same information from the CS. Is it worth ? The prize to pay for having it is very low.

• Element
  • Name
  • Parent
  • Type