Changes between Version 2 and Version 3 of Meetings/Workshops/20071029

Timestamp:

Oct 30, 2007, 12:54:18 PM (17 years ago)

Author:

jouvin

Comment:

--

Meetings/Workshops/20071029

@@ -4 +4 @@
 [[TOC(inline)]]
 
+Agenda : http://indico.cern.ch/conferenceTimeTable.py?confId=20479
 
 == Site Reports ==
@@ -185 +186 @@
  * Deprecate include with literal name in v8 : the change required is compatible with panc v6. Agreed.
  * Introduce include DML without braces at the same time former include syntax is unsupported (v9).
+ * CERN / CNAF agree to migrate to  panc v7 asap. For CERN, mainly the problem of assessing performance problems are fixed.
+ * Interval of 6 months minimum between major releases. Support version N-1.
+
+=== CDB ===
+
+Changes in the last 6 months
+ * cdb-cli : support for user-defined procedures, minimal support for disconnected operations, preparation for namespace support
+  * CDB deployer : ease setup of a test configuration on a set of nodes.
+    * Previously involved a lot of manual operations (mainly copy back and forth from production templates).
+    * Take advantages of namespaces and loadpaths : a ''stage'' (area) is prepend to the template name by defining the appropriate loadpath
+    * A (non-staged) meta-template defines the appropriate loadpath
+    * CDB deploy command (template replication) allow to move a configuration from one stage to another one (e.g. : test, preprod, prod)
+
+Not done yet :
+ * Visualization/navigation tool : PAN parser available but not yet integrated. Another option is to wait for panc v8.
+ * SOAP eating too much memory..
+ * Fine-grained locking
+ * Common authentication service
+ * Reverting committed changes
+
+Other issues :
+ * ME leaving CERN in a couple of months...
+
+=== SCDB ===
+
+http://indico.cern.ch/materialDisplay.py?contribId=7&sessionId=3&materialId=slides&confId=20479
+
+Discussion :
+ * Add script for generating HW templates from a CSV file into SCDB utilities
+ * Allow Google to index Trac LCGQWG site
+
+=== Other Core Modules ===
+
+NotD : framework which allows users to authenticate using different mechanism and configure notifification using wassh-ssm
+
+No progress foreseen on CDB2SQL
+ * Plan is to rewrite with a direct XML DB backend to avoid reparsing XML
+ 
+Generic, plug-in based, login and authentication library : no real progress
+ * Mainly for CDB, SWrep
+
+CCM :
+ * Support for fetching foreign profiles added
+ * De privilege CCM execution still pending
+
+NCM : lot of pending issues/requests. No progress.
+ * cdispd :
+   * Global activation switch
+   * Restard after changes in modules
+   * Improve handling of pre dependencies (Savanah 23814)
+ * ncm-ncd :
+    * Generic 'requirement' like package manager to allow a site to use its preferred package manager (Savanah 17681)
+    * 'NOACTION_SUPPORTED' to allow dry run of a component (Savanah 20040)
+    * --skip option to run all components except a few ones (Savanah 20619)
+    * Support for RPM-less components (Savanah 21204)
+
+NCM components :
+ * ncm-filesystems by Luis
+   * Used at CERN for Xen-based vitrualization
+ * lib/blockdevices : generic support for managing block devices in other components
+ * ncm-rac for managing Oracle RAC
+
+PAN temmplates :
+ * New schema for enclosures released
+ * Fixes in set_partitions() for logical partitions
+ * Support gLite WMS in schema
+ * Support for md devices
+ * Document Quattor standard PAN functions (push, npush,...) in some wiki page.
+
+SPMA/rpmt
+ * SPMA should upgrade and not deinstall/install a package if arch and version is changed (Savanah 19934)
+ * SPMA gives up at the first IO error (Savanah 29029) : let rpmt run until the end to get the full list of errors
+
+
+== Other Developments ==
+
+=== QWG Templates ===
+
+See http://indico.cern.ch/materialDisplay.py?contribId=17&sessionId=4&materialId=slides&confId=20479
+
+
+=== Xen Support ===
+
+Main tool for Xen support is ncm-xen :
+ * Several updates since March
+ * Actual configuration done by several variables (to be documented on QWG wiki) :
+   * `XEN_GUESTS` : list of VMs to manage, corresponding to profiles
+   * `XEN_BOOTLOADER` : pypxeboot, pygrub... 
+   * `XEN_BOOTARGS` : e.g. vif strings required to boot with pypxeboot..
+   * `XEN_RAM`....
+ * Future plans : delegate filesystem management to ncm-filesystems, support for other use cases (downloading images, use copy on write...)
+ * Any need for supporting other VMMs (VMware...) ? Or a generic component ncm-virt ?
+
+Grid-Ireland experience :
+ * PXE/KS install of host + guests : `install_server` machine type added. To be committed into standard templates
+
+=== Enclosures ===
+
+Enclosure description is required to address ore complex system configuration : multiple motherboards per case, blades, VMs...
+ * Required to manage interventions : all nodes within an enclosure must be powered down
+ * Generation of KS config file for all systems into the enclosure
+ * '/hardware/enclosure' used to describe enclosure : CERN uses '/system/enclosure'. Agreement to use /system rather than /hardware as this is not necessarily real HW. 
+
+2 options : 
+ * parent references children : already in use in Xen VMs
+ * children reference parent
+ * Both options are more or less incompatible : need to identify the main use cases.
+   * For VMs, parent has to know about children : generate Xen config files, set up local backing store for VM FS...
+   * For VMs, children don't car about their parents
+   * The same apply to AII
+ * "parent references children" seems to be the appropriate approach : CERN also uses it. Is there any missed use case for the other option ?
+
+=== Filesystems and Blockdevices ===
+
+See http://indico.cern.ch/materialDisplay.py?contribId=1&sessionId=5&materialId=slides&confId=20479
+
+Current layout (organized per HW disk) has several limitations :
+ * Poor control of advanced options (tuning, raid spanning several disks)
+ * SW raid is very difficult to describe with current schema
+ * HW raid is impossible to control
+
+Design for proposed new model (Tim Bell/Andras Horvath) :
+ * Separation between filesystems and block devices descriptions
+ * Filesystems reference block devices
+ * Several kind of block devices : block, hw_raid
+ * Partitions are described inside block devices
+ * LVM and SW raid defined separatly from block devices, referencing block devices
+
+Drawbacks and problems of proposed new model :
+ * Too complex to implement : bi-directional inter-dependencies
+ * Too close to "natural approach"
+
+New proposal (Luis) : pure top-down model
+ * Filesystems referencing block devices
+ * Block devices can be LVM volumes groups, SW raid, HW Raid, partitions, disks... Under /system/blockdevices. Several types of block devices available
+ * A SW or LVM refers to another set of block devices (partitions, HW raid, disks...)
+ * Partitions are a king of block devices referencing HW devices they seat in.
+ * Very flexible and easy to extend
+ * Currently allocated size is not checked against the (declared) disk size. Need to be added.
+
+This model has been implemented into ncm-filesystems and AII v2. Ready for integration into the main schema.
+ * Need to confirm agreement from Tim and Andras
+
+=== ncm-filesystems ===
+
+Handles creation and modification of filesystems after installation
+ * Required for several use cases, in particular VM management
+ * Currently filesystems and blockdevices are described into component configuration : will be changed as soon as they have been included into the standard schema under /system.
+
+Uses a Perl class library (lib/blockdevices) to do the real jobs.
+ * Same library is used by AII v2
+
+Future plans :
+ * Quota management
+ * Resizing operations
+ * HW raid management
+
+=== AII ===
+
+AII 1.x status and problems :
+ * KS support embedded into AII : difficult to support other installation systems (like JumpStart)
+ * SW raid difficult
+ * LVM support buggy
+ * Current schema structure limits possibility for any improvement
+
+AII 2.0 design goals :
+ * Support for installation method other than KS+PXE
+ * Easier maintenance of Kickstart template : allow for easy integration of site customization
+ * Support for complex device schemes
+ * Command line (aii-shellfe) interface unchanged (only --notify has not been reimplemented)
+ * AII is now just a plug-in loader (ncm-ncd model). 3 available plug-ins :
+   * osinstall plug-in : KS installation
+   * NBP plug-in : PXE configuration
+   * DHCP plug-in : DHCP configuration
+ * AII plug-ins inherit from NCM::Component and fetch profiles directly from (S)CDB
+ * KS generator :
+   * Uses ncm-lib-blockdevices, blockdevices/filesystems configured during %pre installation phase (better control of what is created/destroyed)
+   * Uses hooks for local site customization : no more KS template. Ability to use and combine an arbitrary number of hooks. Organized by Kickstart phase (pre_install, post_install, post_reboot). Hooks must be implement as new methods for a NCM object subclass.
+ * PXE generator : replaces PXE template and nbp-aii. Backward compatible, configuration relocated to /system/aii/nbp/pxelinux.
+ 
+Future plans : 
+ * Privilege dropping : AII doesn't need to run as root for the most part.
+ * Enclosure support : --recursive ?
+
+First production version may be ready by end of 2007.
+