asgs-lint warn if length of INSTANCENAME + " " + ASGSADMIN exceeds a length that'd make the email subject > 99 (~51 chars)

[wwlwpd]

• Due to the discover that the subject length affects email reliability, we must warn (or die as critical) when INSTANCENAME + " " ASGSADMIN > 51 characters, which pushes the subject > 99 characters when NAM forcing is being used.

Also add:

• a check ASGSADMIN_ID in asgs-lint

TODO - determine what's the limit when TROPICALCYCLONE is active?

[jasonfleming]

1. For this particular case, can asgs-lint pre-construct the worst-case email subject line and issue a warning if it will be too long?
2. In general, the interface between ASGS and data consumers has always been ad-hoc, for better or worse, with metadata being embedded in the
   1. thredds/nginx url path
   2. ASGS instance name
   3. email subject line for results notification
   4. netcdf global attributes and variable-level attributes
   5. ASGS instance status (asgs.instance.status.json) files
   6. initialization/nowcast/forecast cycle status (hook.status.json) files
   7. scenario status (scenario.status.json) files
   8. scenario metadata (run.properties)
3. The ASGS Interface Guide wiki page is a nice start but it is incomplete and out of date

Is it possible to rationalize all these sources and channels of metadata so that we don't have to pack redundant metadata into e.g. an email subject line with a strict limit on the number of characters?

Is there interest in having an updated and definitive ASGS Interface Guide that can act as a contract between ASGS and data consumers?

[wwlwpd]

1. For this particular case, can asgs-lint pre-construct the worst-case email subject line and issue a warning if it will be too long?

Yes, good idea.

2. In general, the interface between ASGS and data consumers has always been ad-hoc, for better or worse, with metadata being embedded in the
   
   1. thredds/nginx url path
   2. ASGS instance name
   3. email subject line for results notification
   4. netcdf global attributes and variable-level attributes
   5. ASGS instance status (`asgs.instance.status.json`) files
   6. initialization/nowcast/forecast cycle status (`hook.status.json`) files
   7. scenario status (`scenario.status.json`) files
   8. scenario metadata (`run.properties`)

3. The [ASGS Interface Guide](https://github.com/StormSurgeLive/asgs/wiki/ASGS-Interface-Guide) wiki page is a nice start but it is incomplete and out of date

Is it possible to rationalize all these sources and channels of metadata so that we don't have to pack redundant metadata into e.g. an email subject line with a strict limit on the number of characters?

The answer is yes, but this seems like it warrants a discussion to break this down and plan it out.

Is there interest in having an updated and definitive ASGS Interface Guide that can act as a contract between ASGS and data consumers?

Not sure what you mean, exactly - let's talk about this also. A problem (or advantage) ASGS has is its behavior is defined by the implementation, and not the other way around.

[jasonfleming]

Ok I've created a Discussion topic for this: #1127

[wwlwpd]

I am going to close this since the line length actually turned out to be a red herring. The max line has been updated to 120, which should be enough for anyone's current use.