TMB 25/02/09
cal (CL)
vangelis (VF)
xavier (XJ)
maite (MB)
francesco (FG)
oliver (OK)
steven (SN - chair)
massimo (ML)
nick (NT)
patricia (PM)
* minutes of last meeting
no comments
* action list
nothing discussed
* proposed changes to DoW for next year
steven goes through the doc
SN - will circulate revised version to AMB today, will be presented to
PMB in Catania. After PMB endorsement details changes to pow happen in
April for the commission to then be presented at the review
ML - it's an entirely EGEE process? who syncs with LCG?
SN - we'll take input now, and formally at the AMB
SN - EGI activities - not clear where these activities will be in
15months. This doc will feed into EGI design study deliverable. That doc
has changed its date to end of June. EGEE's transition plan will be
defined before EGI has defined its transition plan. By end of summer EGI
should have set up a transition team.
SN - PMB has to endorse strongly and give a full mandate to do these
deep changes
MB - if we don't manage to do this now that we're all working together
it's less realistic in a year.
FG - agree more or less with approach and priorities. it's ambitious.
plan foresees additional work, so either we can save some resources to
do the work, or we have to deprioritise other things.
OK agrees - better to manage this upfront than to drop things
subsequently
SN - are there any components which can be put into maintenance only?
SN - product manager will have to balance resources between maintenance,
testing and certification. could shrink maintenance to as little as
possible. take feedback from Ops and experiments on this. Could fix
major bugs but otherwise this is dormant.
FG - there are inefficiencies in how we develop software, if we reduce
these we can add tasks to the workplan.
OK - SA3 might not be able to handle the current change rate while
implementing deep changes to the process
FG - should aim at more scheduled patches. plan in advance how many
releases they envisage for components.
ML - on page 4 there is the list of areas of software maintenance
SN - these are product groupings. dev teams with functional synergy
which means they have to work together.
ML - these are areas for maintenance.
SN - come from JRA1 description of work.
ML - but there are things which have not yet been delivered. eg a
functional backend to glexec.
FG - SCAS is not in JRA1 DoW.
SN - dev activities will carry on where appropriate. Maintenance should
be reviewed to see if there are components in a maintenance mode to find
out how much effort they need.
ML - experiments see glexec not working properly without SCAS. Same
group has responsibility for this as for other things. risk is that we
get Auth service for end of project. don't want SCAS to slow down
because they concentrate on Auth service. there are other mixtures of
maintenance and long term stuff.
SN - we can change the groupings and see where dev effort is committed
to ensure this is ring fenced so things don't slip. then prioritise
which components are stable except for bugfixes, and which need
functionality.
ML - have heard glexec/SA3 interaction was not great. will you have a
list of things you drop?
FG - can go through down list and see if anything has to be removed.
SN - one thing we could do is decide we do CREAM/GAServ but we don't do WMS.
action on SN/FG to look at this
CL - monitoring service is not there (ActiveMQ)
SN - this is operations work
MB - but there is no milestone to get applications to move. there is no
effort beyond EGEE to further development of this.
SN - cal, do you have preference for RGMA or ActiveMQ?
CL - we want something that works
ML - there are eg dashboards which rely on diverse sources of info. we
should ensure new tools can serve the entire community
SN - ActiveMQ is where we want to go. a new milestone is to establish an
interface a clear API across all services. we can include messaging into
this.
ML - job monitoring is a specific example. CMS/atlas need this for
debugging. don't want to lose this info.
SN - what is used now?
ML - imperial college monitor from LB.
MB - we are discussing with them to use ActiveMQ
ML - have to agree what data will be available so existing apps can
continue to work.
SN - makes sense to have a core messaging system which everyone can
subscribe to.
MB - some tools may have to change
ML - we an adapt to new interfaces but they must provide the data we need
OK - LCG-CE, Apel, dCache not there
SN - can potentially add these
SN - EGI has dev, test and prod experience all in same product team, so
prod experience should feed back earlier into dev process. Can foresee
collaboration between prod teams and sites. gets realistic prod
requirements from experience with mature prototypes.
SN - can move effort from PPS to NGI/ROCs. deployment
debate on PPS pre-deployment testing PPS use-by-users.
SN - when UMD announces a release, this will typically not have already
been deployed by an NGI. we need managed rollout afterwards.
ML - for SCAS we don't use PPS infrastructure,
OK - we do use the pre-production activity.
ML - value comes from Antonio etc
SN - pilot service seems effective. should not restrict interaction
between developers and production.
PM - this is very flexible for the experiments. if we can put a
middleware change into the computing model of an experiment, you will
get feedback immediately.
NT - NB there was a change in the last year, there is no PPS
infrastructure any more.
ML - the developers mustn't do this coordination, it needs people like
Antonio.
SN - EGI mu has an 'Antonio' role.
FG - this was born with the experimental services of WMS/LB. model was
adopted for EGEE-iii. sometime you need a population of nodes (eg CREAM)
for proper early user testing, developers can't do this.
ML - WMS was not really 'alpha', it was advanced and brought this
service into production.
** training infrastructure
SN -assumption is training infra is part of the prod infrastructure.
propose for next year that the t-inf is brought into the same monitoring
environment as the prod infrastructure.
NT - NB monitoring is strict, otherwise they will be kicked out.
MB - are these separate sites? or resources within sites?
SN - in EGI there are no separate resources unless an NGI wants to do it.
NT - if it's just another VO it won't make any difference.
SN - I spoke to robin on Monday and he didn't object
CL - i think they are talking about creating an SSC for training. check
their plans
**
SA2 migration
XJ - i haven't read all EGI definition, but as i see there is not much
manpower for this in EGI. Do we have to produce all this detail for the
transition?
SN - the reason why the blueprint is so light on networking is that they
see this as being undertaken by NGIs or by existing NRENs. Therefore
only thing in EGI.org is the coordination.
XJ - the NGIs can contribute. to give to NRENs is to have a conflict of
interests - you ask them to check themselves.
XJ - you propose 3 milestones for a small activity. i propose to merge
PM12 with ENOC deliverable on PM11 and to merge PM15 and PM18 into
milestone on PM17. it will be easier for us to handle like this
SN - I'm flexible. concern is to make sure that something documents
availability of software is done early so tools are buildable and
deployable outside current environment.
XJ - i propose to move from PM15 to PM17.
SN - send me back a proposed set of changes
XJ - if you agree, we should modify the purpose of the milestones. their
descriptions.
SN - idea is to change 2nd year DoW, not add stuff to 1st. put this into
2nd year.
* SSCs
SN - what I put was was drawn from Cal's presentation at the AA.
CL - various clusters are trying to form their SSCs. all clusters have
expressed an interest in doing so. 4 have done quite a lot already.
astro, hep, life science, earth sciences. what is written is fine. what
is missing is what to do at the next user forum. should make it an EGI
style one with Nordugrid and Unicore?
PM - do all those roles you mention have to be different?
SN - depends on SSC. they could all be one person if appropriate.
PM - should we establish this model during year 2?
SN - need to move to an 'EGI like mode'.
PM - practically, the structure will not change?
SN - yes, more a relabelling...
CL - support activities will change (do they become SSCs?). Not much
else will change. Once the EGI people are known they should contribute.
OK - would we have names?
SN - there is a commitment by EGI that there is a transition team in
place. these people may or may not take on equivalent roles in EGI.org.
cannot know because EGI will have no budget.
OK - so we cannot necessarily train them...
CL -- this needs to be discussed in detail. If they expect me to do it
they're mistaken! I'm planning to hand these responsibilities over.
SN - understood. they have not budget to hire unless the host nation
puts up funds.
VF - local NGI application support. does this need to be included
explicitly? leave as NGI responsibility?
* MCB
SN - can be seen as a subset of the TMB. As part of process, look at
setting up what EGI calls MCB to coordinate middleware. includes reps
from middleware providers, Ops and user activity. Not sure about
inviting members of Unicore and ARC, open to advice. would there then be
a role from the TMB?
FG - i see an almost perfect overlap.
SN - only difference is participation of other MCs, and TMB deals with
policy issues like a new security policy. TMB should maybe delegate this
to Ops unit within EGI org. This may result with an empty TMB.
OK - relation between MCB and m/w providers is different to TMB's. could
be contractual. could experiment with possibilities.
FG - could do more monitoring, not enforcement.
**
FG - next year starts at PM13, so PM12 milestones should be PM13.
SN - agree
FG - as a m/w prov, would like input from Ops and Apps if the contents
of the JRA1 milestones are acceptable.
* stuff on software provider (page 3).
SN - will discuss with Fran/Oliver. Are there more general comments?
SN - one assumption in combining cert/dev is that process is highly
automated. ETICS is default tool in this space. we're working on a list
of what we as a project need for ETICS to support this.
SN - once activity management has agreed on tools an process, it's
essential that this is fully adopted. These changes need the full
support of the PMB otherwise this won't work. Must buy in 100%. There
are deep organisational changes, and some people have 5 years of doing
things one way.
SN - will be discussed at PMB on ?? in Catania.
**
AOB
NT - on milestones, PM12, remove RGMA. we know that APEL will be
earliest ready at July.
NT - need to follow up on proposal for service removal/obsolescence.
needs TMB involvement.
SN - let's check offline and provide feedback on the list. If
necessary, can discuss at next meeting.
There are minutes attached to this event.
Show them.
