[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spacewalk-devel
Subject:    [Spacewalk-devel] New records get born in RHNDAEMONSTATE
From:       tlestach () redhat ! com (Tomas Lestach)
Date:       2010-06-15 15:44:55
Message-ID: 17633424.141276616689328.JavaMail.tlestach () tml ! brq ! redhat ! com
[Download RAW message or body]

----- "Jan Pazdziora" <jpazdziora at redhat.com> wrote:

> Hello,
> 
> while diffing schema contents of Spacewalk which was installed and
> started and Spacewalk which was never started (actually, just an old
> database schema upgraded to latest version), I came across the
> following inconsistence:
> 
> select LABEL from RHNDAEMONSTATE order by LABEL
> < channel_repodata
> < clean_current_alerts
> < compare_config_files
> < daily_summary
> < errata_cache
> < errata_engine
> < errata_queue
> < kickstart_session_check
> < last_task_completed
> < package_cleanup
> < repo_sync
> < sandbox_cleanup
> < satcert_check
> < session_cleanup
> < summary_populator
> < sync_from_cobbler
> < synch_probe_state
> 
> While the schema which never had Spacewalk (and most probably,
> taskomatic) running only has four records there:
> 
> entitlement_run_me
> email_engine
> payloader_engine
> pushed_users
> 
> Which also matches the content of
> schema/spacewalk/common/data/rhnDaemonState.sql
> which populates the table with four records. So the table is
> considered to be a "register" or "lookup table", having some specific
> list of records from installation time, and then we put more data
> there during runtime.
> 
> What I don't like here is the fact that we go into some trouble
> populating the table with four records (and I believe that the
> intention was that whatever processes are using that table would only
> update the last_poll column for existing records), and then the
> application logic adds 17 more records there. For example, I've found
> summary_populator in
> 
> 	java/code/src/com/redhat/rhn/taskomatic/task/SummaryPopulation.java
> 
> Therefore I believe it's the application code which inserts new
> records.
> 
> I believe that we should either populate the schema with the full
> list of labels that we are going to need, and never insert just
> update
> in the application code; or we should not populate anything (and I
> will remove this table from the list of tables that we verify the
> schema for). Or maybe the code cannot be prevented from doing insert
> to the table RHNDAEMONSTATE (maybe it does delete + insert), in which
> case we probably want different table holding the list of allowed
> labels and having RHNDAEMONSTATE.LABEL a foreign key to that table,
> so
> that the application code does not insert completely random labels.
> 
> Thoughts?

Right, this approach is really not the best one.
As this is a part of the taskomatic, I'll investigate it more in detail. I'd touch \
the code anyway. Not sure if somebody makes use out of the rhnDaemonState table \
content, but if not (what I suppose), I'd remove the table and the appropriate code.

Regards,
Tomas
--
Tomas Lestach
RHN Satellite Engineering, Red Hat

> 
> -- 
> Jan Pazdziora
> Principal Software Engineer, Satellite Engineering, Red Hat
> 
> _______________________________________________
> Spacewalk-devel mailing list
> Spacewalk-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel


[prev in list] [next in list] [prev in thread] [next in thread]