[[TOC(depth=0)]] [part of a [wiki:developers-meetings series of meetings]] = Participants = = Agenda = [see box to the side] = Postcards = Up to two minutes (uninterrupted) per person where they can answer two questions: * What I did last week (since the last meeting), * What I plan to do in the next week. No questions until we get through everyone :) = Status of work for 1.9.5 = A (quick?) review of activity needed for the 1.9.5 release = Status of work for 1.9.6 = A (quick?) review of activity needed for the 1.9.6 release Owen: commit a patch to not mounting anything. Then do a release Find out how to support full Kerberos. Don't have a solution for this yet. Ticket from Dima about GSI that Timur assigned to Jon is not using Kerberos any more. Kerberos is only used at Fermi CDF and public dCache instance. In dcap you can specify which user to be using a "nasty way": -x -roll with dcap and ftp, the kerberos username is different. Unify with "ftp"-way: principle= user@domain = Status of work for Trunk (a.k.a future 1.9.7) = A (quick?) review of activity needed for the 1.9.7 release Current plan is to branch Thursday and release 1.9.7-1 Friday. In the new configuration system there is no way to specify Java location. One option is to have an /etc/defaults-like file. Is this a show-stopper? Timur: yes. Tigran: no, we fire a bug against trunk, but release anyway. Another issue is getting the Kerberos doors. Is this a show-stopper? Timur: yes. Tigran: yes: if there's no K. support, DESY won't install it. Timur can work on this on Friday, after the upgrade has completed. We need to think how to get Terracotta into Jetty. Most likely this only needs some configuration changes. Is this a show-stopper? Show-stopper for dropping tomcat instance. As soon as we have Terracotta integrated with jetty we can drop tomcat. Do we know if tomcat can be started with the new configuration system? If not then it needs fixing: either fix tomcat, or drop tomcat and get terracotta working in Jetty. Tigran to have a look tomorrow if he has time. Gerd wants that when you start Chimera is creates database on-the-fly, if not already present. Tigran is looking at doing this with a schema-migration tool (something like "liqui-base"). This uses an abstract XML language to describe the SQL that the back-end database understands. This would be a nice-to-have feature. It isn't a show-stopper. Pool auto-config facility: it takes a bit less than 100%. The idea is to allow out-of-box configuration. It's not meant for production use; there, people should configure their pools correctly. Who's writing documentation? Gerd is writing some documentation: evident from his questions to Tigran about NFS server. We should also move dCacheBook into trunk. This must happen before branching 1.9.7 so the Book will be in the branch. Books have to be published per-dCache branch and make this available. Issue with StorageInfo.clone (current a shallow copy, should be a deep copy). This is not a show-stopper but Tigran will look into it longer-term. Lot of patches marked "ship it" but not committed. = Issues from [wiki:developers-meeting-20100302 yesterday's Tier-1 meeting] = = Outstanding RT Tickets = [This is an [wiki:TicketActions auto-generated] item. Don't add items here directly] == [http://rt.dcache.org/Ticket/Display.html?id=5461 RT 5461]: pool startup problem - out of memory == Not discussed due to Gerd not being present. Do we continue discussing this? Gerd was going to run a regression test, going from 1.9.2-9 to see which version triggers the out-of-memory problem. We don't know how much the increase was actually: Fermi increased from 256MiB to 512MiB without trying all the numbers in between. == [http://rt.dcache.org/Ticket/Display.html?id=5482 RT 5482]: GGUS-Ticket-ID: #55507 TICKET SUBMITTED - dCache/gLite problems with last version of dcache-srmclient-1.9.5-3 == == [http://rt.dcache.org/Ticket/Display.html?id=5489 RT 5489]: kerberos-dcap, gplazma == Already discussed. He got this to work, but the principle is different for the same user. This will be fixed by changing k.dcap so Tigran to point Timur at the point where k.dcap door drops the domain in the user-principle. Timur can check whether this is a problem. Fermi uses dcap talking to gPlazma but this then uses kpwd file. == [http://rt.dcache.org/Ticket/Display.html?id=5490 RT 5490]: kerberos, encryption == Right solution is to get the right security provider for these algorithms. Alter the ktab file on the server so it doesn't use a security algorithm that Java doesn't support out-of-the-box. DESY sys-admin people rejected this solution. == [http://rt.dcache.org/Ticket/Display.html?id=5502 RT 5502]: Peculiar problem == Paul & Tigran to investigate further. == [http://rt.dcache.org/Ticket/Display.html?id=5518 RT 5518]: Re: "No write pools configured" error == Configured two linkgroups with the same parameters, each with a single link. User can write into one link(-group) or the other. One succeeds and the other fails. The issue comes because space-manager doesn't know into which link the user's write request will end up, as the PoolManager makes that decision. This is an architecture issue. If we don't need to fix this tomorrow, we are slowly moving towards distributing functionality from PoolManager to other components and making it more module. This may allow space-manager to run a pool-manager inside. For now the sites can live with the current behaviour. Keep ticket, but don't need to discuss in team meeting any longer. Think about passing PoolManager an order list of linkgroups and poolmanager chooses one. == [http://rt.dcache.org/Ticket/Display.html?id=5523 RT 5523]: transfer failures "No transfer markers received for more than 120 seconds" == One possible explanation is that checksumming is taking too long. When there's no mover any more, the door send no further transfer markers. = Review of RB requests = = DTNM = Proposed: same time, next week.