-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Damian Krzeminski Sent: Friday, June 26, 2009 1:47 AM To: [email protected] Subject: Re: [sipX-dev] sipXconfig audit log
Andy Spitzer wrote: > Woof! > > On Thu, 25 Jun 2009 13:30:58 -0400, Kevin Thorley > <[email protected]> wrote: > >> Now, the real trick would be to add some sort of change tracking so we >> could have a numeric id that would follow all steps of a change, > > Check generated files into a local git repository on the sipXconfig > system before replication. Every change can be tracked using git log > (including diffs). Comments would include which logged in user made the > change, what "page" they were on, etc. > > Alternately, sipXsupervisor would checkin each config file on each > system when it gets it for replication. > > --Woof! > > sipXconfig - in most cases - does not actually generate the files locally before pushing them to sipXsupervisor: it's writing data streams directly. That said the idea of keeping snapshots of all config files in a version control system sounds appealing. I am watching discussion on this issue closely. It looks like some people suspect that sipXconfig is little more than a fancy DB front-end and that every admin action can be easily and linearly translated into a log entry. This is a very misleading view. For example when sipXconfig decides to replicate a configuration file it knows that something has been changed but it does not know who and why changed it (using which page, which API etc.). The way sipXconfig works is that you have one set of threads handling UI and API requests that change underlying data model and separate set of threads that observe the data model and if needed generate the files or using config APIs to affect real world entities. The fact that data model is persisted in relational DB is an implementation detail. The audit log will try to approximate it, but you will not always get the correct answers. So let's get this audit in place: just as we agreed. If it proves to be a useful tool we'll keep on extending and improving it. If it does not we'll drop it. D. My apologies, as I did not follow this thread entirely. Just to interject from a user/admin perspective. Sometimes just having a log that identifies something was done and by whom and data and time is very important in understanding an issue. Even minimum information in a log can be effective when information is needed. From an end user / deployment perspective, I look forward to seeing anything in a log, thanks for your efforts. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
