Changes between Version 1 and Version 2 of Meetings/Workshops/20111011

Timestamp:

Oct 14, 2011, 8:59:11 AM (14 years ago)

Author:

/O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin

Comment:

--

Meetings/Workshops/20111011

@@ -148 +148 @@
    * Use stand-up/review meetings to decide merging into trunk
    
+
+== Round Tables ==
+
+=== Kickstart / AII === #AII
+
+Disk partitionning: current scheme has advantages (full control) but doesn't allow to format large boot disks (> 2GB)
+ * Support for GPT partitions: need to check if Anaconda supports it
+ * Using standard Anaconda partitionning features would help taking advantage of new features but should accept to give up some control
+ * Need to check that reinstallation works in all configuration
+ 
+Kickstart configuration is done by an AII plugin: could if necessary replace the plugin or add a hook
+ * NIKHEF already ignores pre-script and produces the kickstart instructions required to use standard Anaconda formatting features
+ * NIKHEF has written a hook disklayout that could be used as an alternative to aii-ks call to lib-blockdevices
+ * In fact `aii-ks`/`lib-blockdevices` already generates (almost) the required information for Anaconda, just with `noformat`
+ 
+Need to add as a standard AII function the function allowing to add a new hook whatever are the hooks already defined
+ * Such an helper function already exists in hook for SINDES
+ 
+`aii-ks`: really fix pbs mentionned in ticket #235 (See #235#comment4)
+
+`aii-pxelinux`: see if it possible to specify the MAC address to use rather than the interface name
+ * From http://wiki.centos.org/TipsAndTricks/KickStart:
+ {{{
+ A third method works if you are doing PXE based installations. Then you add IPAPPEND 2 to the PXE configuration file and use ksdevice=bootif. In this case anaconda will use the interface that did the PXE boot (this does not necessarily needs to be the first one with a active link).
+ }}}
+ 
+=== SL/RHEL6 Support ===
+
+MAC address binding to interfaces: now done by `udev` rather than the interface config file.
+ * May be a source of problems as `udev` config is done by Kickstart before interface config files are configured by Quattor with some risk of inconsistency
+ * 1 possibility to explore: use non standard name in Quattor config and define `udev` rules appropriatly
+   * Check impact on apps and operations
+   
+On compute nodes running a RHEL6 derivative, kernel option `nohz` should be turned `off`(`nohz=off`) in Grub config to get better performances (Stijn)
+ * Scheduler option to make it more responsive on desktops
+ * Define by defaults for RHEL6 derivative?
+ 
+=== SPMA vs. YUM ===
+
+See Steve Traylen's https://twiki.cern.ch/twiki/bin/view/Main/SteveTraylen/Spma2Yum.
+ * All SPMA features can now be implemented with YUM
+ * Main drawback is the cost of the migration...
+ 
+Several open questions
+ * `ncm-yum requires some extensions not handled by anybody
+ * What is the right level of detail in package list: proposed use of repository snapshots will probably not work accross sites to implement things like OS errata
+ * We need to implement some kind of metadependency for a packager: something like a componenent alias name implemented in `ncm-ncd`
+   * This may replace the need for SPMA as an abstract layer to the packager, something that doesn't work properly as the package description is quite tightly coupled with the actual packager, making a common schema difficult.
+
+=== Change Scheduling ===
+
+MS use cases
+ * `spma` not allowed to run on a running host, can only run at reboot
+   * `ncm-spma` runs but with the flag to run `spma` disabled to avoid preventing other components to run
+ * Some actions cannot be scheduled without reinstalling: would be great to let the user knows that his changes will not be applied immediatly
+   * May be handled at Aquilon (SCDB?) level: will require a partial diff of XML profiles: need to find a tool to do this
+ 
+Partial configuration changes look difficult as Quattor is really designed to enforce consistency on a "all or nothing" basis.
+
+The most important feature would be the implementation of changes at controlled time.
+
+For SPMA, it'd be nice to establish a black list of packages that should not be upgraded except at boot time.
+
+`ncm-ncd`: add a mechanism to blacklist some components if some conditions are not met.
+
+List of possibile conditions/states (local time, boot context...) shoud be well defined and a library/common method should be available for all components to evaluate the state/condition the same way.
+ * Exact actions done if a condition is met will remain the responsability of the components or `ncm-ncd`
+ 
+Would be useful to let a component advertize that a change will require a reboot
+ * Could be implemented through the status file produced when the component is run
+ 
+=== Network Configuration ===
+
+MS main requirements
+ * Bonding
+ * policy routing
+ * ethertools parameters
+ 
+Some patches contributed for current `ncm-network` to handle this but would be good to rethink the schema
+ * In particular the component configuration should be moved to `/software/components` and most of the things currently under `/system/network` should be moved there to allow an easier support of appliances and non Linux boxes
+   * In particular most things currently under `/system/network/interfaces`
+   * Some children of interfaces in the configuration should be probably at the same level (bonds, vlans...) in the same way we have blockdevices and filesystems
+   * Gabor will initiate the discussion on the mailing list with a proposal
+   
+`ncm-network` rewrite: a basic version is available in SVN, ready for code review
+ * https://quattor.svn.sourceforge.net/svnroot/quattor/branches/ncm-network-rewrite-maven
+ * Try to deploy on test machines after initial code review
+
+=== QWG Global Variables ===
+
+Hot discussion about use of global variables in QWG
+ * Contents unvalidated
+ * Request to put them in the profile to get them validated
+   * Michel strongly opposed as the state value at one point in time may be misleading: what is important is the value in the context of a given template, something that cannot be tracked in the XML profile
+ * Side discussion: filecopy unvalided contents
+ 
+Until we have a pan debugger (no concrete project anymore), some possibilities:
+ * Ensure there is the appropriate debug statements in the template
+ * Consider as bugs templates using a variable without any content validation (when it makes sense) and fix them!
+ * See with Cal if a `dump_global_variables()` function would make sense in PAN to dump all global variable at one point in time
+   * If only a subset of the variables are needed, can probably be done with a `debug()` statement
+   * `dump_global_variable` could accept as an arguement a regexp to match the variable name to restrict to variables used in the template
+   
+Discuss with call the possibility to dislay with a Pan option the name of the template entered and wheter it is executed or ignored because it has the `unique` tag.
+
+Document the global variable "namespaces" used in QWG variables.
+
+=== Configuration Component Logging ===
+
+Document/agree on what is the expected level of default verbosity for a component (log/info) and what is the debug level to use for what.
+
+== Sprint 3 Review ==
+
+