Changes between Initial Version and Version 1 of developers-meeting-20140702


Ignore:
Timestamp:
07/02/14 16:47:55 (5 years ago)
Author:
karsten
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • developers-meeting-20140702

    v1 v1  
     1[[TOC(depth=0)]] 
     2 
     3[part of a [wiki:developers-meetings series of meetings]] 
     4 
     5= Participants = 
     6Al, Karsten, Christian, Paul, Dmitry 
     7 
     8 
     9= Agenda = 
     10 
     11[see box on the right-hand side] 
     12 
     13= Postcards = 
     14 
     15Up to two minutes (uninterrupted) per person where they can answer two questions: 
     16 *  What I did last week (since the last meeting), 
     17 *  What I plan to do in the next week. 
     18 
     19No questions until we get through everyone :) 
     20 
     21Karsten: Reviewing, some tickets, further setting up of the small files system 
     22Christian: Setting up IPv6 Hypervisor, still having some issues with infrastructure 
     23Paul: WebDAV 3rd Party Copy patches readying and now feature complete, they are in RB  
     24      when they're committed we will have the functionality.  
     25      Now focussing on some other patches that should go into 2.10. 
     26      Releases. 
     27Dmitry: preparing 2.6 upgrade and looking at the OOM issue. 
     28Al: ReplicaManager is pretty stable, but still needs more testing during hot replication 
     29    There are a couple of timeout issues with NFS. Updated documentation for ReplicaManager, 
     30    Flow Charts, refactored some interfaces to be able to decouple functionality  
     31    (and to enable smaller patches). Waiting for some stuff from Gerd 
     32    - Alarms patch issue... see below. 
     33 
     34= Plans for patch-releases = 
     35 
     36Should we make a new patch release? 
     37 
     38patches need to be committed today for them to go into next releases.  
     39They will be out tomorrow. 
     40 
     412.10.: Is there anything that keeps up from branching? 
     42  Christian: Bug-Reporting would be nice to have in. 
     43 
     44= Trunk activity = 
     45 
     46Progress with new features... 
     47 
     48== Alarms == 
     49Al: 1) The issue is that our checksum alarm filter did not match the log message. So the suggestion 
     50    we mix alarms defined in the code and defined in the alarms definition file. 
     51    Alarms depend on Exception messages. 3rd party code is hard to react on 
     52    -> We could use AspectJ or wrap the relevant classes in an "alarm aware" subclass.      
     53 
     54    2) Could we get rid of the XML database  
     55    -> needs more investigation 
     56 
     57== CRC Checksums == 
     58The script that writes the file does not get the checksum. 
     59-> We can pass it as a parameter 
     60 
     61Gerd's changes to the HSM could also offer a nice way solve this. 
     62 
     63== Globus online == 
     64Dmitry: Cannot do bulk transfers.  
     65Paul: Their test system had two problems with master, one is fixed now. 
     66      The remaining one was that GO would immediately ask for a checksum after the 
     67      transfer started, dCache would not reply to this and the transfer ultimately 
     68      fail. 
     69      There is a patch in RB addressing this by delaying the answer to the 
     70      checksum request until the transfer is finished. 
     71        
     72Dmitry: You can use GO from the CLI instead of the web interface.  
     73 
     74Paul: At KIT they used a stock GO server 
     75      Will check  
     76 
     77== Documentation of ACL in dCache == 
     78Seems to be incomplete/wrong 
     79 
     80= Issues from [FIXME: Add link to yesterday's Tier-1 meeting] = 
     81 
     82Thurday: 
     83 
     84Tuesday: Xavier, Marc 
     85  Nothing to report (mostly) 
     86  Marc: Upgraded to 2.6 with enstore and did not see any problems 
     87  Xavier: About the Brazilian CA: A patch went in and complaints stopped... 
     88    Also opened a ticket about various parameters in admin interface 
     89 
     90== Marisa's sticky bit ticket #8372 == 
     91These situations need admin intervention. We could add a functionality to have dCache 
     92to react on sudden hardware failures to save as much data using cached copies on other 
     93pools. 
     94 
     95Paul: It would be good to have a recipe ready for those cases.  
     96 
     97Christian: Our documentation on this issue about flagging copies as sticky that isn't honored 
     98  anywhere. 
     99 
     100= Issues from EMI = 
     101 
     102= New or noteworthy = 
     103 
     104= Outstanding RT Tickets = 
     105 
     106[This is an [wiki:TicketActions auto-generated] item.  Don't add items here directly] 
     107 
     108= Review of RB requests = 
     109 
     110Paul: 2 patches  
     111 
     112= DTNM = 
     113 
     114Proposed: same time, next week.