Thanks for clarifying this, Mario.
By Occam's razor, I'm absolutely certain that the simplest process model
that can do the task will always survive the test of time, be it EMI or
UMD.
Cheers,
Steve
> dear all
>
> I just add a few clarifications
>
> UMD is presently a collection of EMI and IGE middleware components, that
> have passed through a verification and after a staged rollout process
> as such, the "only difference between umd releases and emi releases are
> these additional processes.
>
> it's true that in the past, there was a rather long time lag between the
> release of a given component in emi and it's release in umd
> we have changed the so called UMD software provisioning workflow to deploy
> publicly available repositories called respectively
> "untested" containing packages undergoing the verification process
> "testing" containing packages undergoing the staged rollout process
>
> we (EGI) make available yum conf repo files that have the "base" and
> "updates" repositories for production, that are enabled by default
> as well as the "untested" and "testing" repositories that are disabled by
> default.
>
> the current time lag between release into EMI and availability in the umd
> "untested" repositories is currently a few hours to at most 1 day
>
> we have watched for many years a large range in site policies, from the
> ones that don't upgrade no matter what, and (if happy) will stay with a
> given version
> for as long as they can, to sites that want to upgrade everyday if
> possible (c.f. the lcg-CE saga for example)
> (Note that sites also mean user communities)
>
> any given site is thus able to configure only UMD repositories, and have
> access to all that is released in EMI if they wish to through those
> additional repos.
> (also of course depends on the service)
>
> all problems and issues found in these processes are turned into ggus
> tickets and assigned to EMI, EMI will then follow the procedures to fix
> and release them
> also depending on priorities and criticality of the tickets.
>
> as you may guess, we don't aim to find "all" problems with this process,
> but surely aim at finding all we can before any given release, or it can
> happen that we decide
> not to release at all a given version of a given component (or service).
> this process allows a contribution as well for emi in terms of problems
> with possible/reasonable workarounds, that are then publish by emi after
> the an official release or update.
>
> all in all, in the end it's up to the site (or user community) to decide
> from where to fetch the middleware
> our aim and the aim of this mail is to clarify what we (EGI) do
> additionally to any given release of EMI in particular.
>
> with kind regards
>
> Mario David
>
>
> On Nov 13, 2012, at 4:51 PM, Stephen Jones wrote:
>
>> On 11/12/2012 10:55 AM, Tomáš Kouba wrote:
>>> I would like to ask other sites about their decision between EMI and
>>> UMD - what
>>> you considered and why did you choose the one you run?
>>
>> Tomáš,
>>
>> we decided to settle on the EMI process model, which closely follows the
>> industry standard
>> V-model (requirements, design, code, unit test, integration test ,
>> release...)
>>
>> The UMD "waterfall" extension may (or may not?) add to the EMI model,
>> but it's certainly
>> expensive in terms of time-lag, and I'm not sure if defects found in UMD
>> V&V get
>> back to the product teams (or perhaps the whole lots needs to go again
>> through EMI!)
>>
>> Perhaps it's a bit mysterious to everyone, so we chose EMI - it's very
>> straight and simple.
>>
>> Steve
>>
>>
>> --
>> Steve Jones [log in to unmask]
>> System Administrator office: 220
>> High Energy Physics Division tel (int): 42334
>> Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
>> University of Liverpool
>> http://www.liv.ac.uk/physics/hep/
>>
>
|