[Spacewalk-devel] spacewalk plug-in for apt-get
Hi Spacewalkers, I would like to announce, that I've started work on $subj. Deadline is 1 year ahead, but I would really like to finish it till October. Will keep You informed. best regards Simon Lukasik ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] New records get born in RHNDAEMONSTATE
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? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New records get born in RHNDAEMONSTATE
- Jan Pazdziora jpazdzi...@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@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk plug-in for apt-get
On Tue, Jun 15, 2010 at 03:10:00AM -0400, Simon Lukasik wrote: Hi Spacewalkers, I would like to announce, that I've started work on $subj. Deadline is 1 year ahead, but I would really like to finish it till October. Will keep You informed. Thank you, Simon! Please let me know if/when I can help with testing. Cheers, -- Cristóbal Palmer ibiblio.org metalab.unc.edu ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel