You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

About BOX

The incoming developer is always responsible for all BOX activities. And for some of the EOX activities. 

This just describes the ship based activities. It assumes that things were done on shore to prepare for this.

For repository of shipboard developer resources see Developer space on shipboard Confluence:  http://confluence.ship.iodp.tamu.edu:8090/display/RAADND/Random+Access%3A+Application+Developer+Notes+and+Documentation+Home


Checklist / Overview

  1. Make sure you are connected in your new home.
  2. Relieve your counterpart. Take charge.
  3. Courier duties: transfer and deliver any IT content in your possession.
  4. Apply database and web-service updates.
  5. Reset database defaults for expedition and projects.
  6. Create user accounts, manage application roles & privileges.
  7. Clean & preen the database.
  8. Check that database triggers are enabled.
  9. Publications specialist! Start the Virtual Photo Table compositer.
  10. Pull the current list of core catcher types LIST_ENTRY where LIST='CC_TYPE'. Chat with the Core Techs.
  11. Change developer and programmer email distribution lists.
  12. Check with the DESC tech to see if DESC value list entries need to be made available to the SEM uploader.

Reset your credentials for your DBA account on SHIPTEST. See if your credentials will expire before you return. The conventional name is now yourname_dba--as a reminder that you are wearing that hat.

1. Make sure you are connected

Your duties require information technology connectivity. A lot of change happens in our environment between expeditions. Verify your tools and access:

  • Laptop connectivity to the network? Internet?
  • Email account on ship active?
  • Able to access file systems? Printers?
  • Can you get to the password safe? The database?
  • Update the jr_programmers email list to reflect the location of the programmers on deck.
  • Can you get to your account on the BUILD box and DEV test workstation? The dev account (for as long as we continue to do that).


2. Relieve your counterpart

Read the tech report. Exchange information. What's changed?

3. Courier duties

Deliver all transported media and equipment to their responsible parties. Stage any software-related components and tools in the appropriate locations. Make sure our own content survived the trip by connecting the media.

Examples

  • If shore sends out desktop/server software distributions with you, ensure the media is turned over to the MCS.
  • If you have Moisture and Density container information, make sure it is staged in a location you can find it when you are ready to process those containers.
  • If the science party requested legacy data to be available for the on-coming expedition, you should have that data and a plan for making it available.
  • If you have software updates, there's a place to file them:
    • disk connected to DEV-PC for a (ship-)local stash--once-upon-a-time \\DEV-PC\Volumes\ozy\dml; and
    • \\CLEVELAND\VOL??\TAS\dml


4. Apply database and web-service updates

Perform any database upgrades to implement changes from shore. Do this on the test system FIRST. This will confirm the scripts are good before you work on the ship databases.

Perform any web service updates to implement changes from shore. Do this on the test system FIRST. Run applications which use these services to confirm nothing is broken before upgrading the ship web services.

Upgrade any applications for changes from shore. Typically this should be done by the developer on the ship as these changes are created, but sometimes the incoming developer brings new things with them. Follow build, deployment, distribution procedures that exist--create documentation for those procedures if they don't exist--follow existing patterns.

Thoroughly test all upgrades and changes.

5. Reset database defaults for expedition and projects

Use sqlplus or SQLDeveloper to make these database changes for the newly started expedition.

1. Set the default expedition for LIMS.

update lims.lims_constants set constant_value='&currentExp' where name='EXPEDITION';

2. If legacy data has been loaded run the appropriate compute procedure to generate display content for the OVERVIEW report.

In SQLDeveloper browse LIMS.LIST_ENTRY where LIST='MENU'.
Edit the record with NAME set to the previous expedition.
Change the expedition name in the NAME column from the previous expedition to the current expedition.
Change all the instances in the VALUE column from the previous expedition to the current expedition.

3. Add a new project list entry for PROJECT.

In SQLDeveloper browse LIMS.LIST_ENTRY where LIST='PROJECT'.
Edit the existing record to reflect the current expedition or add a new record.

Auther privileges

Per the LIME team.

  • All scientist accounts are removed (just like with Oracle).
  • New scientist accounts are added.
  • No changes will be made to "tech" accounts.
  • New scientist accounts will have Only the generic Scientist Role assigned.  Any special roles needed are handled by Curator..

Are there any new personnel who require updates to application access privileges?

Curator handles privs and Roles.

Cumulus accounts

This is managed by the MCS. Do verify that your account still works so you can access documentation.
20220212 df Not relevant since moving to DAM MerlinOne circa 2021 Oct. Cumulus instance on ship is retired.

Change application authorization

SampleMaster

  • If a new ALO or Curator is participating, ensure they have the SampleMaster curatorial role.
  • If a new Driller is participating, ensure they have the SampleMaster driller role.

Desclogik

  • Participant roles for Desclogik users are managed by the Desclogik Admin.
  • If a new Desclogik Admin is participating, ensure they are setup with the necessary permissions.

Catwalk

  • If a new ALO or Curator is participating, ensure they have the CURATOR role. This is to provide access to the Template Manager and Settings.


Other accounts

Crossover with off-going developers to verify if any significant access changes were made. See the development password safe for credentials . If you make any credential change relevant to development work, please update the safe to reflect the change.

6. Update user application accounts

See Subversion for the last created versions of the script: https://build.ship.iodp.tamu.edu/svn/wapps/Tools/DbScript/participants

Best source of user names: the expedition science party email list maintained by the staff scientist for on-going project communications. The MCS will have a list of the accounts the created and since we use the same names get their list when they are done.

Delete the accounts for those who are leaving the ship. Use - participants_remove.sql.

7. Clean the database

Previous Expedition.

CONFIRM WITH THE OUTGOING DEVELOPER THAT A GOOD COPY OF THE PREVIOUS EXPEDITION DATA HAS BEEN OBTAINED AND IS VERIFIED ON TAPE.
THIS INCLUDES

    database dumps,

    ASMAN file content,

    image tiles,

    lithology patterns, and

    data1 -- raw expedition data, some of which is not cataloged in LIMS.

    OVERVIEW menus & content: remove items no longer carried on ship

DO NOT PROCEED UNTIL CONFIRMATION RECEIVED.

Prior expedition content is to be removed to enforce moratorium. Use this reference until you are comfortable with the process.

8. Check that database triggers are enabled

This step is dependent on the completion of (7). Via SQLDeveloper, log into the LIMS account. Ensure that no triggers, functions, procedures, views are flagged by a red 'X' (indicates invalid or disabled content).


9. Start the Virtual Photo Generator

Help the Publications Specialist set it up on their machine. This should be the ONLY location that runs it.


10. Core Catcher Types

Chat with the Core Technicians--are there any changes to the list of Core Catcher Types LIST_ENTRY where LIST='CC_TYPE'?
The goal is to keep the list short. Most often used items should be pushed to the top by use of the ORDER_NUMBER field.
Keep core entry simple. Drill-floor safety and core recovery take precedent over this small thing.

11. Change developer and programmer email distribution lists


When the out-going developers leave ship, update the Exchange distribution lists for jr_programmers and jr_developer to reflect their location changes.
This procedure received from the MCS should work for the shipboard environment.

  1. Log onto the Exchange management site at https://exchange.ship.iodp.tamu.edu/ecp (similarly for shore!)
  2. Select “groups” in the navigation pane
  3. Under the column “distribution groups I own”, double-click JR Programmers.  A new window opens
  4. Click on “membership” in the navigation pane
  5. Click on the “+” or ”-“ button to add or remove recipient(s)
  6. Search for the recipient to add or remove, then click on the “+” next to their name
  7. Click “OK”
  8. Click “Save”

Please note that because there may be a small delay after every change to Active Directory due to replications between the domain controller, and it may take some time for changes to arrive at the offline copy of your mailbox, you may have to wait a minute or restart Outlook to refresh.

12. Check with the DESC tech to see if DESC value list entries need to be made available to the SEM uploader.

This step involves updating the DESCINFO2.X_SIEM_HERARCHY table.  If this is needed:

  1. In SQL Developer, look at the table, sorted by HIER_KEY.  At the bottom, you might find one or more expedition-specific entries (they'll have an expedition number in their names).  Delete these.
  2. This documentation describes the process of adding new values for your expedition:  SEM uploader X_SEM_HIERARCHY table.
  3. If the above documentation is confusing, here are some notes:
    1. The data in this table represents a hierarchy, and the PARENT value for each record links back to the HIER_KEY of that item's parent.   
    2. For example, "igneous rock names", "sediment names" and "metamorphic rock names" (HIER_KEY = 80, 90, 100) all link back to "LITHOLOGY" (HIER_KEY = 10).  On expedition 396, we added three entries, with each one linking back to one of the three lithology items just mentioned, so their PARENT values were 80, 90, 100.
    3. If you've done this properly, you should be able to run the SEM uploader and (after selecting an image, which can be anything), see the name(s) you added when you pick the parents (e.g. Category = LITHOLOGY → General subcategory = igneous rock names → Exp. specific subcategory = [your entry or entries]).


  • No labels