[Go-essp-tech] Transition to CMIP5 production status

[Eric Nienhouse]

Bryan, All,

Agreed on the below.  Deployment and support plan(s) are crucial to the 
initial success of our federated system.

I feel we've all spent a lot of good effort on development planning and 
integration system testing in anticipation of the CMIP5 production 
activity.

We need to spend more focused effort on deployment, operations and end 
user support.  Working quickly to get a user support system in place is 
one critical piece IMO.  Bob started a thread on this recently with 
little feedback.  Let's continue to discuss this and work quickly toward 
an initial proposal.

Further, a number of the problems raised involve *usability* of the 
federated system.  (A sincere thank you to Karl for detailing your 
recent experiences.)  User experience has highlighted difficulty with 
Wget using MyProxy certificates, confusion about OpenID and login and at 
least one technical issue related to SSL certificates.  Tiger teams are 
forming to work on these areas.

I believe we'll need some true user observation and usability study to 
resolve this well.  In other words, we need to spend more effort on the 
usability of the federated work flows and the system overall.

Note that a number of Data Nodes are configured (only) with token based 
file access.  This makes certain Node file access easier for some users 
(IMO), however, we're not achieving the benefit of re-usable Wget 
scripts in these cases.  Token based access is a possible fall-back 
option for the near term in my mind.

A deployment schedule during this phase will greatly help as there may 
be rapid change in need of end-user evaluation.  In fact, there have 
already been a number of changes since Karl's work that address some of 
the Wget/MyProxy problems.

We need to look carefully at what we as a federation can accomplish 
given the needs to develop, test, release and deploy multiple software 
components.  Routine upgrades will involve Gateway and Data Node 
deployments and a coordinated release schedule.  A one week cycle may 
not be do-able.  However, agreement/commitment to a deployment (upgrade) 
plan is critical.

Let's continue to discuss and formalize a near term deployment plan.

Apologies for long email - more "thoughts" and "observations" than plans 
- we're meeting to discuss this further at NCAR today.

-Eric

Bryan Lawrence wrote:
> hi Folks
>
> I think there are two levels of problems being discussed.
>
> A: We need to "deploy", and have in place a mechanism to "upgrade", and 
>
> B: We need "tiger teams" to nail problems.
>
> A number of instances of B are under way. Good.
>
> However, I'd like us also to have
>
> 1) a clear an unabiguous method for "users" to report problems, and 
> 2) a clear plan for when and how we upgrade during the next few weeks.
>
> I know Stephen has suggested using footprints for 1) (and I'm fine with 
> that, and recommend we do that ... now! ... even if we replace the 
> system for user support later - which we may need to, since it costs 
> real money to deploy), and
>
> We agree something like:  "we will do simultaneous upgrades every 
> wednesday during the next couple of months (allowing us to agree on 
> details on a tuesday)."  I don't mind if that's not the plan folks agree 
> on, but I want a plan ...
>
> All of this is of course independent of  "announcements".
>
> Bryan
>
> --
> Bryan Lawrence
> Director of Environmental Archival and Associated Research
> (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
> STFC, Rutherford Appleton Laboratory
> Phone +44 1235 445012; Fax ... 5848; 
> Web: home.badc.rl.ac.uk/lawrence
>