| 1 | = Quattor Workshop - 17-19/3/10 - Thessaloniki = |
| 2 | [[TracNav]] |
| 3 | |
| 4 | [[TOC(inline)]] |
| 5 | |
| 6 | [http://indico.cern.ch/conferenceTimeTable.py?confId=84432#20100317 Agenda]. |
| 7 | |
| 8 | == Site Reports == |
| 9 | |
| 10 | === LAL === |
| 11 | |
| 12 | See slides. |
| 13 | |
| 14 | === MS === |
| 15 | |
| 16 | Configuration changes: |
| 17 | * Still one configuration server |
| 18 | * 2 set of boot servers (Europe, US) |
| 19 | * 20K managed machines (+5K) |
| 20 | * Virtual machines with ESX: 1200 ESX server, 1700 managed machines |
| 21 | * AII rebuild time still 3h |
| 22 | * Compile time increased from 10 to 18 minutes |
| 23 | * Using MS-specific version of 8.2.9 |
| 24 | * 8 people involved in template development maintenance (+2) |
| 25 | * LEMON used: 2x2 servers |
| 26 | |
| 27 | Issues: |
| 28 | * No code submissions recently: legal issues with SF... |
| 29 | * aqd scalaibility: priority for next year |
| 30 | * Pending open-source: |
| 31 | * AII, CCM patches: in prod at MS |
| 32 | * FUSE interface to configuration browsing: ready for distribution |
| 33 | * Aquilon: RAL interested, still a significant MS-dependencies |
| 34 | |
| 35 | |
| 36 | === AUTH === |
| 37 | |
| 38 | Migration from cfg/local to SCDB sites still in progress |
| 39 | |
| 40 | Included monitoring information at profiles |
| 41 | |
| 42 | Attempt to use Quattor as a central DB for all assets (KVM, StorageArrays...) |
| 43 | * Implemented as a separate cluster group |
| 44 | |
| 45 | SCDB clusters by machine criticality |
| 46 | |
| 47 | Xen configuration now based on QWG with a few developments |
| 48 | * Removed host dependency on guests |
| 49 | * Trying to remove the use of DHCP |
| 50 | |
| 51 | Templates for new machine types |
| 52 | * Message broker, in production at AUTH |
| 53 | * egee-NAGIOS/egee-SNAGIOS: work in progress, not based on previous Nagios templates from QWG |
| 54 | |
| 55 | QAD: Nagios interface almost completed |
| 56 | |
| 57 | JRuby added to SCDB to add task written in Ruby |
| 58 | * Used for QAD integration |
| 59 | |
| 60 | Issue: sync with QWG, how other sites are doing? |
| 61 | |
| 62 | === CERN === |
| 63 | |
| 64 | ''Note: report about Quattor in computing center only.'' |
| 65 | |
| 66 | CDB 2.2.5 and panc 8.2.11: 10K machines |
| 67 | * panc 8.3.0 tested |
| 68 | |
| 69 | New development: Django-based search tool for CDBSQL |
| 70 | * Using sqlalchemy: Oracle independent |
| 71 | |
| 72 | Test of SCDB: work done by Daniel with the help of Luis |
| 73 | * Test done with one profile and the CERN template structure |
| 74 | * Observations: |
| 75 | * profile location is a big change for CERN |
| 76 | * Decoupling of commit and deploy may lead to potential problems |
| 77 | * SVN ACLs are only at the directory level: having them at the file level is an advantage in CDB |
| 78 | * +: build-in ACLs, local panc compilation giving access to log files |
| 79 | |
| 80 | RFE: pkg_add/pkg_repl based on date to ensure people are not installing obsolete version. Is it feasible? |
| 81 | |
| 82 | Can we agree on a policy for announcements of new components? Exact rules for using quattor-discuss rather than quattor-grid? Do we really need 2 lists? |
| 83 | |
| 84 | |
| 85 | === NIKHEF === |
| 86 | |
| 87 | 5 clusters, 500 managed machines |
| 88 | * 350 clones |
| 89 | * SCDB 2.3.1 + local changes |
| 90 | * panc 8.2.8 |
| 91 | * Compilation time: ~30s |
| 92 | |
| 93 | 6 people involved in Quattor maintenance (4 active) |
| 94 | |
| 95 | Virtualization: 13 hosts, 48 guests |
| 96 | |
| 97 | Nagios: 1 master, 3 slaves |
| 98 | |
| 99 | Refactoring of templates for easier usage: not using QWG |
| 100 | * VO configuration, VOMS |
| 101 | * Batch system access control, VOViews |
| 102 | * User banning |
| 103 | |
| 104 | Virtualization: currently not used with grid clusters, investigating KVM |
| 105 | |
| 106 | === Grid Ireland === |
| 107 | |
| 108 | 18 sites, some have expanded. |
| 109 | |
| 110 | SCDB with bzr and Git clients and an old version of QWG (r4921) |
| 111 | * Not up-to-date in particular with errata and VO config |
| 112 | |
| 113 | === RAL === |
| 114 | |
| 115 | 90% of T1 Quattor managed. T1 fully committed to Quattor. |
| 116 | * Mostly WNs (700 already, 400+ soon) |
| 117 | * Also other machine types: bdii, vobox, .... |
| 118 | * Disk servers: OS + all package management operations, CASTOR config still relying on Puppet |
| 119 | * Nagios servers: OS only |
| 120 | |
| 121 | 9 sysadmins involved + 6 more coming |
| 122 | |
| 123 | SINDES on the point of deployment to ease server certificates handling. |
| 124 | |
| 125 | Ready to start experimenting with Aquilon |
| 126 | |
| 127 | Using SCDB+QWG (up-to-date with standard templates) |
| 128 | * Happy with performances: 4 minutes for a full compile, without profile cloning |
| 129 | * Would like to slim down RPM list used by various machine types. Is anyone else interested? |
| 130 | |
| 131 | Very positive with Quattor so far |
| 132 | * Much more consistent |
| 133 | * Batch service much easier to manage |
| 134 | * Errata deployment much easier |
| 135 | * Much more agile: easier to deploy new versions |
| 136 | |
| 137 | |
| 138 | === CERN LHCb Online Farm === |
| 139 | |
| 140 | Online computing |
| 141 | * Event filtering farm: currently 700 nodes, 500 to 1000 to be added in the future |
| 142 | * Diskless systems |
| 143 | * Credit card PCs |
| 144 | * Various control PCs and infrastructure nodes (Web servers, DNS, ....) |
| 145 | * Also some Windows nodes (120) but mainly running Linux SLC4/SLC5/RHEL5 |
| 146 | |
| 147 | Linux machines managed by Quattor |
| 148 | * Original setup done in 2006 with CDB/panc v6/aii v1 |
| 149 | * SWrep replaced by scripts |
| 150 | * ViewVC web interface to templates and XM files |
| 151 | * Problems with Krb authentication in CDB and the fact author of commit is always Apache |
| 152 | * Decided to give a try to SCDB... see presentation |
| 153 | |
| 154 | Maintainer of ncm-diskless_server and ncm-pvss |
| 155 | * Also developped ncm-checklines as an improved ncm-filecopy |
| 156 | |
| 157 | Plans for the future: |
| 158 | * Finish move to SCDB |
| 159 | * Cleanup of tempates |
| 160 | * Update/rewrite the 2 components maintained as part of this use + ncm-network |
| 161 | * Several issues with ncm-network: see presentation tomorrow |
| 162 | |
| 163 | Some extensions made on Quattor schema |
| 164 | * Additions to /system |
| 165 | * /hardware/ipmi |
| 166 | |
| 167 | === LAPP === |
| 168 | |
| 169 | 5 SCDB clusters |
| 170 | * 1 machine acting both as SVN and SCDB server, still running SL4 |
| 171 | |
| 172 | 10 Gb/s support: with Chelsio interfaces, found a way to do PXE |
| 173 | * No more need to use 1 Gb/s for Quattor (PXE) boot |
| 174 | |
| 175 | Install and configuration of GPFS through Quattor |
| 176 | * Strongly depending of kernel and require to build RPM for each new version of the kernel |
| 177 | * Unfortunatly hard to make generic, thus not contributed to standard templates |
| 178 | |
| 179 | |
| 180 | === CNAF === |
| 181 | |
| 182 | Very positive after the move to SCDB, despite a few problems |
| 183 | * Error caused by users who commit before compiling, planning a wrapper |
| 184 | |
| 185 | 3900 machines managed. |
| 186 | |
| 187 | Working on improving QWG errata management. |
| 188 | |
| 189 | Main versions deployed |
| 190 | * SL5 (no longer SLC) |
| 191 | * gLite 3.2 |
| 192 | * Grid services configured with YAIM |
| 193 | |
| 194 | Virutalization |
| 195 | * Using KVM, phasing out Xen |
| 196 | * No connection between hypervisor and VMs in templates: not clear we want to do it |
| 197 | * Hypervisors and VMs managed by Quattor |
| 198 | |
| 199 | Issue: complexity is increasing a lot |
| 200 | * Bug tracking is very difficult |
| 201 | |
| 202 | |
| 203 | == Developments == |
| 204 | |
| 205 | === Pan Compiler - C. Loomis === |
| 206 | |
| 207 | v8.2 in production: only serious bug will be fixed |
| 208 | |
| 209 | v8.3 (development version): 8.3.1 is a release candidate |
| 210 | * Dependency file format change, annotation syntax |
| 211 | * Will become 8.4.0 when production version is released |
| 212 | |
| 213 | v9 planned before next workshop |
| 214 | * Will remove support for all deprecated syntax/features |
| 215 | * See previous list |
| 216 | * Will require .pan instead of .tpl |
| 217 | * 8.4 will support both |
| 218 | * Issue: CVS history cannot track renames... |
| 219 | * Would probably be easier to add an option to change the default extension to avoid the penalty of trying both for every template |
| 220 | |
| 221 | panc release management moved from ant to maven |
| 222 | |
| 223 | Current work: |
| 224 | * Allows sources from non-file locations (eg https) |
| 225 | * Will enable an XML-based syntax imported as a structure template |
| 226 | |
| 227 | Code refactoring: |
| 228 | * clean up, internationalization |
| 229 | * Make AST more accessible (e.g. editors, code formatters...) |
| 230 | * Easier tight control by external tools (e.g. debugger) |
| 231 | |
| 232 | Annotations: open the path for automatic documentation generation |
| 233 | * Need to agree on tags used |
| 234 | |
| 235 | Another issue: auto-escaping of nlist keys |
| 236 | * Possible to look at it but potentially a huge work to take advantage of it |
| 237 | |
| 238 | === QWG Update - M. Jouvin === |
| 239 | |
| 240 | See slides. |
| 241 | |
| 242 | === SCDB Update - M. Jouvin === |
| 243 | |
| 244 | See slides. |
| 245 | |
| 246 | === Diskless Servers Support - L. Barda === |
| 247 | |
| 248 | For LHCb online farm |
| 249 | * Filtering tasks can be done in memory, disk not used |
| 250 | * Credit-card PC have no disks; still SLC4, i386 |
| 251 | |
| 252 | Initial diskless support in Quattor started in 2005 and taken over by LHCb end of 2007. |
| 253 | * Read-only NFS shared root filesystem configured on the server and copied to the diskless server at the end of kickstart |
| 254 | * RW files for each client in a specific file system (`/.snapshot`) remounted with -bind on the diskless server |
| 255 | * 2 templates to describe a node configuration |
| 256 | * Proto node: shared root FS content, main part of the configuration |
| 257 | * Real node: node-specifc configuration |
| 258 | |
| 259 | `ncm-diskless_server` is used to generate the boot image, manage DHCP/PXE for the managed systems, configure the `ccm.conf` on the node-specific file system. |
| 260 | |
| 261 | Current status |
| 262 | * In production for several years |
| 263 | * Moved farm from SLC4 32-bit to SLC5 64-bit: was pretty easy |
| 264 | * A student should work on SLC5 i386 for CCPC |
| 265 | |
| 266 | Issues with the current solution |
| 267 | * Very large mount table on nodes |
| 268 | * Issues when modifying a RW file on a RO file system |
| 269 | * List of RH RW files is too large |
| 270 | * Lack of debug info in system-config-netboot used to generate images and initrd generation is not flexible enough |
| 271 | * Shared root file system can only be a copy of the server file system |
| 272 | |
| 273 | Plan is to rewrite `ncm-diskless_server` and use UnionFS to replace the NFS mounts and bind tricks. |
| 274 | |
| 275 | Several issues with `ncm-network` too, in particular inappropriate restart of the network breaking the NFS access. Will start a rewrite (`ncm-network_NG`) |
| 276 | * Should separate each part of the configuration: interfaces, routes, bonding.... Code restructuring. |
| 277 | * Should use network utils to modifiy the running system |
| 278 | * Modify sysconfig files for persistent modifications |
| 279 | |
| 280 | Try to interact with the community during the design phase to ensure it could be used at some points in replacement of the current `ncm-network`. |
| 281 | |
| 282 | == Migration to SCDB at CERN LHCb Online - L. Barda == |
| 283 | |
| 284 | Motivations: |
| 285 | * Wanted to have real names in commits |
| 286 | * CVS too much hidden in CDB: no more conflict resolution |
| 287 | * CDB2SQL too heavy |
| 288 | |
| 289 | SCDB installation using standard documentation, but no QWG. A few modified components: |
| 290 | * LDAP authentication to SVN |
| 291 | * Next Apache will allow subgroups |
| 292 | * svnperms.py to restrict who can do commits |
| 293 | * DHCPD config / aii-dhcp |
| 294 | * quattor.build.xml: no cluster used, profiles located in /profiles/* |
| 295 | * New target added |
| 296 | * Post-commit: added the ability to send an email before running post-commit.py |
| 297 | * build-tag.py run under Apache rather than root without sudo or ssh |
| 298 | * Also added the ability to run quatview as part of build-tag.py (new section in config file) |
| 299 | |
| 300 | Also AII v1 to v2 migration. |
| 301 | |
| 302 | Special use case: allow sub-detector people to change their CCPC Mac address |
| 303 | * Allow them to commit only in the subfolder corresponding to their CCPC and make a deploy |
| 304 | * Rely on svnperms.py precommit hook to restrict their right to commit |
| 305 | |
| 306 | Currently a test instance, in production soon. |
| 307 | |
| 308 | |
| 309 | == Monitoring == |
| 310 | |
| 311 | === NCG-Monitoring and Quattor - R. Starink === |
| 312 | |
| 313 | Quattor implementation at NIKHEF based on `standard/monitoring/quattor` but a lot have changed and merge is challenging. |
| 314 | * Changes both in QWG and NIKHEF templates |
| 315 | |
| 316 | Enhancement at NIKHEF: |
| 317 | * Hierarchy of Nagios servers |
| 318 | * Slaves schedule probes and return result to master through passive checks. Uses `ncm-nsca` on master+slaves |
| 319 | * Master monitors slaves with active checks |
| 320 | * Master and slaves with the same host/service definition but with slightly different parameters. Quattor helps to keep things consistency. |
| 321 | * Master is the only one to run Apache: configured with `ncm-filecopy` |
| 322 | * pnp4nagios: RRD-based graphs (like Ganglia) integrated with Nagios, usable with any probe |
| 323 | * Service checks: generic checks + grid-specific ones (DPM, WMS, Torque, MAUI...) |
| 324 | |
| 325 | Grid monitoring: wanted to enable NCG-based grid monitoring solution for site |
| 326 | * SAM test results |
| 327 | * Local grid checks |
| 328 | * Ideally entirely Quattor-managed but potential conflict: NCG implements a dynamic detection of tests to run where Quattor describes tests in a static configuration |
| 329 | * NCG: risk (happened!) of Nagios killed by a dynamic update of the configuration |
| 330 | * Requirements: co-exist with existing Quattor+Nagios setup, no gLite on Nagios server |
| 331 | * Incompatibilities fed back to developers |
| 332 | |
| 333 | Grid monitoring layout: |
| 334 | * Master werver can either submit grid tests directly or through a separated gLite UI |
| 335 | * NCG used to generate Nagios configuration but not to enable/configure Apache, sudo... (done by Quattor) |
| 336 | * Files generated by NCG included as `cfg_file` in `ncm-nagios` |
| 337 | * Potential conflict between Quattor config and NCG config (duplicated hosts...) preventing Nagios to start |
| 338 | * Master has a check (delivered by NCG) to push checks generated on master on the gLite UI |
| 339 | |
| 340 | Status |
| 341 | * Started early in pre-OAT times where many manual steps were required |
| 342 | * Deployed recently the Jan2010 release and now configuration almost fully automated |
| 343 | * Many perl-xxx dependencies: better to use `checkdeps` |
| 344 | * Setup is not straightforward: NCG is still work in progress |
| 345 | * Not completely happy with NGC-magic but aternative is to describe services in Quattor configuration. Is it maintainable? |
| 346 | |
| 347 | === Monitoring based on OAT Work - C. Triantafillidys === |
| 348 | |
| 349 | See slides. |
| 350 | |
| 351 | Prototype not ready for distribution, based on QAD and NCG |
| 352 | * Both still under developments |
| 353 | * QAD used as a management interface to add MetricSets and select nodes which they are applied to based on `/monitoring/features`. |
| 354 | |
| 355 | |
| 356 | === NagiosBox for Biomed - M. Jouvin === |
| 357 | |
| 358 | See slides. |
| 359 | |
| 360 | |
| 361 | === Monitoring Discussion === |
| 362 | |
| 363 | TCD still using QWG templates but short of manpower. |
| 364 | * TCD should update QWG trunk so that we can understand/assess difference with NIKHEF |
| 365 | * QWG templates for describing monitoring configuration for local resources |
| 366 | * Must allow AUTH usage pattern where all the configuration of Nagios is done outside Quattor (through QAD) |
| 367 | * RAL will not necessarily use it but could provide feedback on what is done/planned in QWG templates |
| 368 | |
| 369 | Grid service monitoring will try to rely on NCG as much as possible |
| 370 | * Need input from AUTH about possible usage patterns of NCG API, how to integrate it in components... |
| 371 | |
| 372 | First step: 2 wiki pages describing NIKHEF configuration and NCG potential |
| 373 | * Location to be discussed later |
| 374 | |
| 375 | Should plan a Nagios node in future test cluster. |
| 376 | |
| 377 | |
| 378 | == StratusLab - C. Loomis == |
| 379 | |
| 380 | Goal: enhancing grid infrastructure with virtualization and cloud technologies by incorporating could innovation into existing grid infrastructures |
| 381 | * Simplify and optimize its use and operation |
| 382 | * Enhance existing computing infrastructure with "Iaas" |
| 383 | * Grid services will remain the glue among distributed resources |
| 384 | * Possibility to scale out to commercial clouds |
| 385 | * Deliver an open cloud API (à la Amazon EC2) to enable community services to take advantage of cloud resources |
| 386 | |
| 387 | StratusLab aims to deliver a toolkit that can be easily installed by existing sites. |
| 388 | * All the software produced will be openSource (exact license to be decided) |
| 389 | |
| 390 | Interaction with Quattor community |
| 391 | * Several partners member of Quattor community: TCD, LAL |
| 392 | * Major goal is to make the life of sysadmins easier: need to ensure that it is easy to install and configure with automated tools |
| 393 | * Want to leverage Quattor community's expertise with grid deployment: don't want to reinvent the wheel.. |
| 394 | * Would like to use Quattor to build appliance configurations |
| 395 | |
| 396 | |
| 397 | Project should start beginning of June. |
| 398 | * Still in negociation |
| 399 | |
| 400 | == SF Migration and Build Tools - C. Loomis == |
| 401 | |
| 402 | Current situation |
| 403 | * Need to converge to using tools on SF and having a sustainable set of build tools |
| 404 | * Was planned to be done within QUEST and now we need to move forward ourselves |
| 405 | * Need to have concrete relaistic plans |
| 406 | * Build tools unmaintained(able) since ME left |
| 407 | |
| 408 | Current tools: |
| 409 | * Wiki |
| 410 | * MediaWiki on SF |
| 411 | * Trac on SF enabled but not used |
| 412 | * Trac@lal: used extensively for QWG documentation |
| 413 | * SVN: SF for Quattor core, QWG for QWG+SCDB |
| 414 | * Bug/feature tracking |
| 415 | * SF: Pan compiler only (based on Bugzilla, working well) |
| 416 | * Trac@LAL: QWG todo list |
| 417 | * Savanah@CERN: main place for user bugs |
| 418 | |
| 419 | Build tools: |
| 420 | * Current set of tools very complex and basically unmaintainable |
| 421 | * Attempt with Ant but not clear there is a real gain as Ant config file is rather complex |
| 422 | * Maven solution may be possible: many attractive features (dependency management, multi-level project configuration, RPM packaging), more language neutral than Ant |
| 423 | * Willing to do limited test but will need help from others |
| 424 | |
| 425 | Wiki future |
| 426 | * Trac on SF is lacking to many features (plugins) to allow an easy migration from Trac@LAL |
| 427 | * A temporary option could be to move current MediaWiki content to Trac@LAL until we have a usable Trac@SF |
| 428 | * Then we could migrate with export/import of Trac DB |
| 429 | * We gain some time for SF to install the same Trac version as LAL |
| 430 | * Agreed but import of MediaWiki contents to Trac@LAL must be the occasion of restructuring current contents to be more generic and ready for import to SF |
| 431 | |
| 432 | SVN future |
| 433 | * Move SCDB to SF asap (and other generic tools if any) |
| 434 | * QWG part kept at LAL temporarily |
| 435 | |
| 436 | Bug/feature tracking |
| 437 | * Current SF bug tracking is functional and fairly usable, only missing bit is ability to link to SVN |
| 438 | * Moving all bug tracking of to SF would have the benefit to remove one of many places where users have to go |
| 439 | * Agreement to close Savanah |
| 440 | * Review exact requirements and issues in monthly meetings |
| 441 | * Configure SF with appropriate tickets |
| 442 | * Communicate with the community |
| 443 | * Implement the change. Target: 2-3 months |
| 444 | |
| 445 | Mailing list |
| 446 | * quattor-grid: only QWG-related stuff |
| 447 | * quattor-discuss: everything related to core components, including NCM components |
| 448 | * quattor-nagios: discussion to Nagios bit and bytes (development list) |
| 449 | * Announcements: evaluate SF announcement features as they are more appropriate than a mailing list |
| 450 | |
| 451 | Build tools: |
| 452 | * Cal ready to do a mini test with Maaven |
| 453 | * Should try to remove the too many externals |
| 454 | |
| 455 | |
| 456 | |
| 457 | == Quattor Future == |
| 458 | |
| 459 | Agreement on a monthly meeting. |
| 460 | * Doodle to find the convenient time slot (if possible allow participation from US but not a strong requirement) |
| 461 | * Between 1 and 2h |
| 462 | * Possible facility: Dutch, BELNET, IN2P3 |
| 463 | * Do a test asap: end of next week/beginning of the week after |
| 464 | * First meeting: first week of April |
| 465 | * ~10 people ready to participate |
| 466 | |
| 467 | Work plan |
| 468 | * Panc debugger: not in the short term |
| 469 | * Panc editor: try to find a student who could do the work to have something basic but complete |
| 470 | * Not scheduled until we find one |
| 471 | * Component tooling + ability to run non-Perl components |
| 472 | * Need to understand costs and benefits |
| 473 | * Concentrate on a review of what this involves |
| 474 | * Ask Nick; first goal may be to produce a list of issues as a FAQ (reasons why it is not possible) |
| 475 | * Support for package managers other than RPM |
| 476 | * SPMA replacement on other platforms |
| 477 | * May also impact the build tools (ability to package Quattor as something else than RPM) |
| 478 | * Not first priority for many sites but support for YUM/APT may be valuable for many sites |
| 479 | * CERN had plans to use YUM of SPMA |
| 480 | * Concentrate first on a review of what is exactly involved, potential benefits, minimum YUM version to use, understand APT and YUM differences |
| 481 | * Aquilon integration: RAL will work on this anyway and expect progress before next workshop |
| 482 | * Will depend a little bit on MS availability to help: MS cannot commit to spend much time but agrees to help |
| 483 | * Ian taking this in charge but limited to getting it usable at RAL |
| 484 | * IPv6: not a short-term requirement but needs to be done |
| 485 | * NIKHEF could commit to try to install a test quattor server that will use IPv6 and check what is working/not working |
| 486 | * Some expertise available in EGEE3 and several NRENs |
| 487 | * Make a clear list of what are the changed required |
| 488 | * Hooks for interoperation with management frameworks |
| 489 | * Code review and best-practices |
| 490 | * Define best-practices and recommended API for components and rewrite a documentation for developping components on this (Luis) |
| 491 | * Set up of build and test infrastructure |
| 492 | * Cal volunteers for the build tools and for adding unit tests |
| 493 | * Do a review of the existing build system at LAPP and make proposal to have it more useful and more used (Eric) |
| 494 | * Review existing components, identifying obsolete/duplicate, and possibly contributing to a documentation page about existing components and their coverage |
| 495 | * No volunteer but remains an important action |
| 496 | * QWG templates |
| 497 | * Other MW support: wait for EMI to see if there is a real need |
| 498 | * generic service support: Christos ready to work on it in the coming months |
| 499 | * VM support: to be done in collaboration with StratusLab |
| 500 | * Integration with monitoring: see previous discussion |
| 501 | |
| 502 | Dissemination |
| 503 | * Must remain/be a strong activity for the community: enlarging the community is a way to pave the way for the future |
| 504 | * Proposal to make presentations at the EGI conferences and establish contact with NGIs |
| 505 | * A booth/demo, a poster or a presentation? |
| 506 | * Could take the opportunity of doing something in common with StratusLab at the first EGI conference |
| 507 | * A presentation based on RAL experience? |
| 508 | * Try to be present in NGI meetings |
| 509 | * Increase our visibility: be present on sites like Oloho |
| 510 | * Make a list of conference useful to attend, in particular sysadmins conference |
| 511 | * Wiki page about events and conferences of interest |
| 512 | * Training harder without funding, will also require work to get the appropriate material |
| 513 | * Appliance: StratusLab has a need for it, may come as an outcome of the collaboration |
| 514 | * COSTS project: possibility to get funding for dissemination actions but deadline very close (26/3) |
| 515 | * 1st application only 4 pages (10K words), more detailed application later |
| 516 | * Up to 100KE/year during 4 years |
| 517 | * People (not institutions) from 5 countries |
| 518 | * 3/4 of proposal passing the 1st stage being funded |
| 519 | * Attempt to apply based on QUEST proposal and members + BELNET (Cal/Michel) |
| 520 | |
| 521 | Documentation |
| 522 | * Clarify the different targets for the documentation |
| 523 | * General communication: a basis exists on MediaWiki, need to develop, in particular use case study |
| 524 | * User documentation: mainly concentrated on QWG templates, missing bits (in particular components) |
| 525 | * Need to ask users/NGIs what they need |
| 526 | * Lack of step-by-step guides |
| 527 | * Documentation for developpers |
| 528 | * Many things missing |
| 529 | * Need to document the build tools when we agreed on which ones to use |
| 530 | * Existing documentation review (Andrea) |
| 531 | |
| 532 | Commercial support and consultancy |
| 533 | * No big interest in the community right now |
| 534 | |
| 535 | Long-term organization of the community |
| 536 | * Legal entity behind the name to support the branding with official logos, presentation layouts... |
| 537 | * Probably not a short-term action |
| 538 | * Licensing cleanup: ask PLUME people if they are still ready to contribute without funding |
| 539 | |
| 540 | Quattor toolkit component status |
| 541 | * AII: nothing major, maintained by Luis |
| 542 | * Nick has some contributions pending |
| 543 | * SPMA: still maintained, minor modifications |
| 544 | * ncm-spma review and enhancements: schema adjustements (repository), function rewrite (Victor) |
| 545 | * rpmt-py: no maintainer but no maintenance needed so far... German is the author. |
| 546 | * panc: see discussion, maintained/developped by Cal |
| 547 | * CCM: last contributor/maintainer was Nick |
| 548 | * Need to enhance CCM to be able to handle gzip profiles without ungizipping them at Apache level |
| 549 | * ncm-cdispd/ncm-ncd: Nick is the last one who had a look at it |
| 550 | * Also the new daemon written by Nick to act a proxy for managing non Linux boxes |
| 551 | * Add ability to run dependendy only if there was a config change affecting them |
| 552 | * Tracking/querying status of last component run: mod may be already done by Nick |
| 553 | * ncm-query: Michel maintainer but no change foreseen |
| 554 | * FUSE file system to browse configuration on client (`ncm-query` alternative) |
| 555 | * CDB: maintenance done to use last panc compiler (CERN) |
| 556 | * cdb-sync may be of broader use: SCDB may have to use it to take benefit of ncm-cdispd alternative |
| 557 | * ncm-templates: a template processor used in components, not really maintained but works! |
| 558 | * perl-CAF/perl-LC: actively maintained by Luis |
| 559 | |
| 560 | SINDES: an external potentially useful component, should check the status and the accessibility outside CERN |
| 561 | * No longer any maintenance at CERN, frozen |
| 562 | * Any possibility to add it to Quattor repository? |
| 563 | * RAL to drive the effort, Veronique to check with CERN |
| 564 | |
| 565 | Worshop preparation is now the responsibility of monthly meeting. |
| 566 | |
| 567 | == Conclusion == |
| 568 | |
| 569 | Next meeting |
| 570 | * Several proposals: Philips (Eindhoven), RAL, Strasbourg |
| 571 | * After a vote, RAL choosen if they confirm they can organize it |
| 572 | * Sites are welcome to express their interest in hosting a workshop |
| 573 | * 2+1 days |
| 574 | |
| 575 | |
| 576 | |