[Go-essp-tech] Transition to CMIP5 production status
Eric Nienhouse
ejn at ucar.edu
Wed Feb 9 12:23:26 MST 2011
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
>
More information about the GO-ESSP-TECH
mailing list