Meeting notes Overall structure needs to reflect the MN deployment checklist phases (Planning, developing, testing, operating) For example: Task: Planning Determine feasibility = Establish contact with potential MN organization Join DataONE = Create DataONE identity In the tasks: SSL Certificates --> SSL Certificates for Development, rename 'urn:node:KUBI' to 'urn:node:mnTestKUBI' since this is the convention we're following now http://mule1.dataone.org/OperationDocs/member_node_deployment/mn_checklist.html http://www.dataone.org/member-node-deployment-process - "How to become a member node" is non-technical overview of the Member Node Deployment Checklist. - Each doc references the other. In the tickets, link back to the checklist. Would it make sense to have each MN deployment be its own project in Redmine? - Anonymous accounts may not be a good idea. ###################################### created. Story: Title: "MNDeployment: {{NodeID}}" Description: "This issue is to track deployment of member node:\n\n **Node ID**: {{NodeID}}\n **BaseURL**: {{BaseURL}}\n **Deployment Contacts**: {{DeploymentContacts}}\n **Software**: {{Software}}\n **Tier**: {{Tier}}\n **Content Volume**: {{Content.VolumeGB}} GB\n # ^^^^ what is content volume?? LM **Deployment Notes**:\n {{DeploymentNotes}} " Tasks: # Initial preparation. - Title: Initial preparation Description: When potential MN expresses interest, or when DataONE identifies a potential MN, evaluate suitability of the relationship (value to both parties). Create top-level redmine ticket. If a decision is made to move forward, create detailed redmine tickets, otherwise move top-level ticket to deferred or closed. Tasks: - Title: Establish contact with potential MN organization Description: Establish contact with the developers and/or administrators who will be responsible for developing and/or deploying the new MN. - Title: Integrate MN representatives with community Description: Add MN representatives to MNF/developers/community, other lists as needed. - Title: Create DataONE identity Description: Create DataONE identities for one or more of the MN contacts, to enable access to docs.dataone.org, Redmine, etc. - Title: Create MN description document and logo Description: Work with MN POC to create MN description document. Attach here when complete; store PDF in docs.dataone.org. Identify/create MN logo; attach file to ticket. - Title: Scope and plan implementation Description: Select the MN Tier, determine which software stack to use, etc. # Development cycle (only for new MN implementation) - Title: Design, code and test a new MN implementation. Description: If a new MN is being developed from scratch, tickets in this section will track progress. # Certificates. - Title: SSL Certificates Description: Set up and verify correct operation of SSL client and server side certificates Tasks: - Title: SSL Certificates for Development Description: Client (and depending on Tier, server) certificates must be created and installed. Tasks: - Title: Generate {{NodeID}} client certificate for development. Description: Create the test client certificate, and send it to {{DeploymentContacts}}. When the certificate has been installed on the MN, the MN contacts should notify DataONE. - Title: Verify successful installation of client side certificate (development) Description: After notification from the MN that the client side certificate has been installed, verify that it is working correctly. - Title: Verify successful installation of server side certificate (development) Description: After notification from the MN that the server side certificate has been installed, verify that it is working correctly. - Title: SSL Certificates for Staging Description: Client (and depending on Tier, server) certificates must be created and installed. Tasks: - Title: Generate {{NodeID}} client certificate for staging. Description: Create the test client certificate, and send it to {{DeploymentContacts}}. When the certificate has been installed on the MN, the MN contacts should notify DataONE. - Title: Verify successful installation of client side certificate (staging) Description: After notification from the MN that the client side certificate has been installed, verify that it is working correctly. - Title: Verify successful installation of server side certificate (staging) Description: After notification from the MN that the server side certificate has been installed, verify that it is working correctly. - Title: SSL Certificates for Production Description: Client (and depending on Tier, server) certificates must be created and installed. Tasks: - Title: Generate {{NodeID}} client certificate for production. Description: Create the test client certificate, and send it to {{DeploymentContacts}}. When the certificate has been installed on the MN, the MN contacts should notify DataONE. - Title: Verify successful installation of client side certificate (production) Description: After notification from the MN that the client side certificate has been installed, verify that it is working correctly. - Title: Verify successful installation of server side certificate (production) Description: After notification from the MN that the server side certificate has been installed, verify that it is working correctly. # Node document. - Title: Set up Node document Description: Check that the Node document used during testing looks the same as it will in production. # ^^^ what's a Node document? Is it that thing that you see when you do this: https://cn.dataone.org/cn/v1/node ?? # Content Review - Title: Content Review Description: Verify that all content on the MN appears correctly. Tasks: # Science Data content. - Title: Science Data Description: Tasks related to ensuring that the Science Data is correctly represented on the MN. Tasks: - Title: Verify that the Science Data is returned with the correct HTTP Content-Type Description: The HTTP Content-Type header should correctly represent the Science Data when downloaded. For instance, EML , TIFF, and RDF documents should have Content-Type of text/xml, image/tiff, and application/rdf+xml respectively. - Title: Science Metadata Description: Tasks related to ensuring that the Science Metadata is correctly represented on the MN. Tasks: - Title: Verify that the Science Metadata is returned with the correct HTTP Content-Type Description: The HTTP Content-Type header should correctly represent the Science Metadata when downloaded. For instance, EML , TIFF, and RDF documents should have Content-Type of text/xml, image/tiff, and application/rdf+xml respectively. - Title: Science Metadata is available in Solr index Description: Verify that Science Metadata appears correct in the Solr index after synchronization. - Title: Verify Science Metadata Description: Review the MNs Science Metadata. This is to make sure that the metadata is complete, correctly formatted and is processed correctly by CNs. - Title: Create Resource Maps for the data and metadata Description: DataONE uses Resource Maps to associate Science Data with Science Metadata. Generate the required Resource Maps. There are DataONE libraries and commands that can help with this task. # Authentication and Authorization - Title: Authentication and Authorization Description: Tasks related to ensuring that permissions are correct on Science Data, Science Metadata and log records and that the permissions are correctly enforced by the MN. Tasks: - Title: Science Data access Description: Verify that Science Data has the correct read, write and updatePermissions permissions. Verify that Science Data can be accessed only by users who have the required permissions. - Title: Science Metadata access Description: Verify that Science Metadata has the correct read, write and updatePermissions permissions. Verify that Science Metadata can be accessed only by users who have the required permissions. - Title: Log Record access Description: Verify that Log Records can be accessed only as allowed by the MN policy. # Synchronization - Title: Synchronization Description: TODO # ^^^ do we do this in staging first to see if it works as expected, then do the same steps in production? Tasks: - Title: Register new Science Metadata formats Description: All Science Objects on the MN should be of types that are known to the CN. Any unknown types should be registered. - Title: Synchronization Description: Setting the MN up for synchronization and verifying that it works correctly. - Title: Set up synchronization of the MN Description: Enable synchronization for the MN. - Title: Review synchronization results Description: After initial synchronization, review the representation of the data in DataONE and make sure that it accurately reflects that of the MN. - Title: Resolve any synchronization related issues Description: Resolve any issues found when reviewing the synchronization results. # Transition to production - Title: Transition to production. Description: Tasks related to moving the new MN into production. Tasks: - Title: Update "Current MNs" webpage Description: Update the Current MNs webpage with information about the new MN (logo and MN description document). - Title: Mutual acceptance Description: Change to "approved" in production. - Title: Production verifications Description: All the items that were verified when the MN was in development and/or staging should be verified again for production. # Final steps to go live. - Title: Final steps to go live Description: The final steps required to bring the new Member Node online in the production environment. Tasks: - Title: Create legal documents Description: Legal language (any partnership agreements, MOUs, etc.) - Title: Create news item Description: Draft news item for public release and coordinate with MN for any announcements they wish to do from their perspective # ^^^^^ actual execution of this step probably should happen earlier in the process with the completed document ready to go here. Not sure where to stick it, unless at MN desc doc??? - Title: Formal announcement Description: Announce the new MN on DataONE website, press release, ListServ, Twitter, etc.