Difference between revisions of "100817 DMSU Weekly Assigner Meeting"

From EGIWiki
Jump to: navigation, search
imported>Krakow
(No difference)

Revision as of 16:22, 12 December 2014

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


DMSU menu: Home Interactions Ticket priorities Ticked followup Documentation Internals



- 13:59 -

gronager: Its 14

gronager: at least in Kastrup, DK

gronager: so lets start the meeting

gronager: I managed to send around an agenda

jens: A short one!

gronager: so... lets start with _the_ ticket

gronager: Ales - do you have anything to add on this ?

ljocha: it's difficult for me, wearing my double hat

gronager: could you elaborate (on the hat)

gronager: (hats even)

ljocha: the user requests a fix for a deprecated baseline, the fix _is_ already in the new one, and I know that EMI will not be very pleased to fix this in the old basline

gronager: so, what you say is that he requests support for sometihng unsupported

ljocha: on the other hand, I suspect the problem is with the "metapackage" (the RPM which contains nothing but dependencies) only. therefore we can make an easy workaround, just regenerate this empty RPM

ljocha: on unsupported -- this is sort of grey area

ljocha: the relationships with EMI are not strictly specified, I'm not sure what's the current level of support of glite 3.1


- 14:05 -

gronager: Question is if the deciding EGI organ for currently deployed stuff would like us to promote support for 3.1

ljocha: I've already emailed Zdenek Sustr, who is resposible for LB in EMI, what is his view, but he is on vacation.

gronager: or to encourage him to upgrade

jens: At least it's hard to call 3.1 deprecated when not all services are released in 3.2. Or perhaps they are now? I saw that FTS showed up not long ago.

ljocha: I thing they are not

gronager: OK, then I think we should provide him the fix, and note that it is not very nice to have these big chunks of releses (3.1, 3.2) of everything

gronager: So, something to note to the TCB: the middleware providers should release components, not tied to 3.1 / 3.2 etc - and ensure that components works with the currently deployed components...

gronager: otherwise we should switch to a monolith one rpm for everything and just install glite3.1 or 3.2

ljocha: this is not quite so. there are two major releases of glite, 3.1 and 3.2. components in each are independent but there are problems combining 3.1 and 3.2 ones, obviously

gronager: (and I mean a real rpm - not a pointer to a lot of stuff... - ugly it would indeed be...)

ljocha: the metapackage is LB, not entire glite ...

gronager: (I know...)


- 14:10 -

ljocha: there used to be (until glite 3.1) rather bad practice to put the dependencies into the metapackage, not into the real RPMs which require them

gronager: however, if we want to support a situation of two releases floating around, we need to support combinations as well

ljocha: this is cleaned up in 3.2

gronager: ok

jens: Combining 3.1 and 3.2 packages sound bad though. Noone wants to support that. You can't roll in CentOS4 packages on a CentOS 5 machine without getting pain.

gronager: I still, think we should provide him a fix, and deal with the policy around that at another level

ljocha: sure.

ljocha: I will try to repack glite-LB RPM (the metapackage) without the problematic voms-api-noglobus requirement.

ljocha: If it works, we can push it to EMI.

gronager: OK - great, and I will take a note on the policy of how to support these things...

ljocha: Btw, have we got a web site where to release such fixes?

gronager: I think you should notify mario

ljocha: OK

gronager: Next agenda point...

gronager: Awareness

gronager: So far the number of ticksets recieived has been quite low


- 14:15 -

gronager: I think it is more a result of unawareness and other practices than due to high quality-no-bugged middleware

gronager: I will contact Tiziana and Ron to ensure we get an improved awareness and to ask what the actual procedures are

gronager: I guess a phonecon would be good

gronager: will send out an invitation - great if some of you could join

Rebecca Breu: i'll be away the next week and the week after

gronager: OK...

ljocha: This is the top-down part of the activity. I'd also suggest push on rearrangement of the GGUS support units to reflect the current (theoretical) support structure

ljocha: I'm available for the phoneconf this and next week, in general.

gronager: Yes, I agree - and we should discuss that with Torsten - inviting him for the phonecon as well

gronager: Fine - I don't have anything else on the agenda - aob, anyone?

ljocha: congratulations to your son

gronager: Thanks!

ljocha: the first one?

gronager: Nope number 3 - all boys


- 14:21 -

gronager: OK - so long for now - talk to you at the phonecon!