Nav-dev Mai 2010

nav-dev@lister.sikt.no

3 participants
3 discussions

Database version control
by Morten Brekkevold 26 Mai '10

26 Mai '10

In reference to my database related mess during the first beta release of 3.6.0, I want to propose a few changes to how we manage schema changes in NAV. We do version control our schema, which is good, but the process has some weaknesses. The fact that we maintain a baseline and change scripts separately at the same time has repeatedly caused inconsistencies. Usually, I catch these problems with a simple schema diffing tool, but since we still have no automated tests going on, this is a tedious manual task and prone to being forgotten. I found a series of articles about database version control via the Coding Horror blog. These describe many of the ideas I was having as I was fixing the b1 release: http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-co… Basic summary of the changes I'm suggesting: * We keep the sql scripts, doc/sql/*.sql, as they are - these are our baseline. * Instead of everyone maintaining both doc/sql/upgrades/trunk.sql and the baseline scripts: Whenever a developer needs to change the schema, he/she should check in a new sql scrip which contains only the ALTER/UPDATE statements needed to migrate to the new schema. * Schema initialization and upgrade are merged into one automatic process that applies the baseline, and then consecutively the change scripts committed since the baseline. * To keep track of which schema changes have been installed, a new schema_change_log table in the database is updated by the automagic schema install/upgrade process. * Every once in a while, typically at a new feature release, the schema change files can be summarized into a new baseline. This process would also make it easier to install an arbitrary revision from a Mercurial repo and ensure that one has the correct schema for that revision. I guess we will be busy prepping the final 3.6.0 for some time yet, but we should be looking into this post 3.6 (not to mention all the automatic testing I'm dreaming of putting togheter post 3.6). Feedback/comments are appreciated, though I know many of you are busy with non-NAV-related stuff this time of year. -- Morten Brekkevold UNINETT

1 0

Notes on the beta release and branch changes
by Morten Brekkevold 21 Mai '10

21 Mai '10

Hi all devs, Just a quick note on the ongoing changes in relation to the 3.6 series. The staging/3.6 branch has now been merged to default. A new series/3.6.x branch has been created. The series/3.6.x is not considered stable yet, so all current devs have push access to this repository. * If you need to commit changes to the 3.6 development series, please clone the series/3.6.x repo to do so. Remember that this is a named branch. Also, for those who haven't noticed yet, the entire build system has switched from pure autoconf to the automake+autoconf combination. All Makefile.inS have been rewritten to Makefile.amS, reducing heaps of redundancies and making the Makefiles more readable. Please refer to the GNU autotools manuals for further info (or start a discussion here or offline if you have comments/questions). -- Morten Brekkevold UNINETT

2 1

Meeting minutes from 2010-05-03
by Kristian Klette 18 Mai '10

18 Mai '10

Here are the meeting minutes from the last NAV developer meeting. Sorry about the delay. NAV Meeting May 3 2010 -- NAV 3.6 Release ========================================= Present: - Vidar - John Magne - Morten - Kristian - Thomas - Magnus Discussions regarding NAV 3.6 ============================= Deadline 2010-05-14 moved to 2010-05-21. Beta release: 2010-05-21 LP has: * 36 blueprints * 13 bugs targeted for 3.6 Blueprints ---------- - ipdevpoll - Beta is just around the corner. - Some plugins aren't ready yet. These will be included during the beta period. - GetBoksMacs - Good progress, needs more testing before released into the wild. - Replace Ip info by extending IP Device Info - Feedback from Jørgen needed. - Device History - Done. The toolbox description still has the "beta"-mark. Should be removed. - Magnus wants to clean up the code, but not critical for 3.6 - API for adding custom event/alert type hierarchy - Done. - Add names to identify modules - Done. - Modules uses the new "name" attribute for identifying the module. - The old numeric ids are kept and used for sorting. - CSV export - Done - ThresholdMon refactor - Done - Refactor nav.auth to be django aware - Almost done. - LDAP authentication needs testing. - Should switch session cookie identifier for smoother upgrade path for users. - Remove SQL parsing from report generator - Done - Remove psycopg1 dependency in favor of pyscopg2 - Done - Might be some issues regarding unicode in legacy code. - Rewrite pping and servicemon to use nav.deamon - Done - Rewrite makecricketconf to python / Rename RRD-files when changing target name - Ready for beta. - Upgrade paths regarding rrd files must be tested. - Check and refactor statTools to support consolidated interface table - Obsolete - Collect WeatherGoose statistics with cricket - Started - Soon ready, but there are some issues with detecting weathergoose devices thats needs to be sorted out. - Rewrite status page to django - Done. - Needs code-review and testing Bugs ---- - Prefixes not removed - Should be fixed in ipdevpoll. - Missing alertmsg.conf for cisco AP trap - Fixed in JM's staging branch. - Fix should be cherry-picked into 3.5.x - Alert when mac-address connects to the network (wishlist) - Moved to NAV 3.7 - Default location and organisation in install (wishlist) - Installations that only has one organization (or simply doesn't need org.-tracking) wants to have a default dummy organization for easier seeding of the database. -- Mvh Kristian Klette «Programs for sale: Fast, Reliable, Cheap: choose two.»

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Nav-dev Mai 2010