What is probably of particular interest to this audience are the services that are being decommissioned pending any input from the project. The necessity of these services is not clear; they appear to be legacy cruft. NCSA is capable and willing to extend operations of any of these services as necessary given that the need is identified. The most up-to-date version of the list is on the page mentioned above but an initial list is provided below for convenience. Please review and notify me of any concerns.
Note that any data sets distributed by discontinued services below may be available via the new /datasets file system. That plan is forthcoming.
The following hardware is being replaced
The replacement for that service will be https://pipelines.lsst.io; I’m just working on the integration of Sphinx into the build process right now.
If that doesn’t happen in time, I could work with @josh on modifying our build pipeline to upload the current doxygen builds to LSST the Docs rather than copying files onto lsst-web.ncsa.illinois.edu as we currently do.
Please note that we should not agree to retire a service at NCSA with the expectation that it will be re-hosted at the same (or worse) support level at another institution. If the service provides a function, leaving it at NCSA should be the default.
Thanks for tackling this – I wouldn’t be surprised to find things running that were set up in the past decade
Below are my annotations. I also took a stab at an initial definition of which project role should be the contact point for questions on retirement, changes, or continued maintenance of each service. Hope this helps you with change control going forward.
Database Account Signup (web based)
Is this for accessing the Stripe 82 reprocessed catalog? If so, it will be needed until superseded by the catalog in PDAC. [contact: DMPS]
Current change control process: once you cull the above list based on all comments, issue RFCs for retirement of individual services. The contact points above should sign-off on changes. Full TCT may need to weigh in on some (I tried to annotate those I thought fall into that category). In particular, ***don’t decommission a service w/o an RFC (our current equivalent of a CAB procedure)***. Omnibus RFCs are fine for dealing with multiple services at once.