GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2018-06-13T23:13:13Zhttps://git.ligo.org/computing/gracedb/server/-/issues/4Removing an event from a superevent does not unset it as the preferred event2018-06-13T23:13:13ZTanner PrestegardRemoving an event from a superevent does not unset it as the preferred eventSee original post at https://git.ligo.org/lscsoft/gracedb-client/issues/4.See original post at https://git.ligo.org/lscsoft/gracedb-client/issues/4.https://git.ligo.org/computing/gracedb/server/-/issues/6Superevent lvalert messages must contain valued value for "self" field2018-06-14T15:34:38ZLeo P. SingerSuperevent lvalert messages must contain valued value for "self" fieldSince we multiplex traffic from several different GraceDb servers to the single LVAlert server `lvalert-test.cgca.uwm.edu`, it is necessary for all LVAlert messages to identify the GraceDb server of origin. I have been using the `self` a...Since we multiplex traffic from several different GraceDb servers to the single LVAlert server `lvalert-test.cgca.uwm.edu`, it is necessary for all LVAlert messages to identify the GraceDb server of origin. I have been using the `self` attribute for this purpose. However, `superevent` LVAlert messages set this attribute to `null`. They need to set this attribute to a valid URL. This is a prerequisite of emfollow/gwcelery#21.
```
{
"object": {
"comment": "Set as preferred event for superevent: S180613bw",
"file_version": null,
"tag_names": [
],
"file": null,
"created": "2018-06-13T17:53:37.431668+00:00",
"self": null,
"issuer": "emfollow",
"filename": "",
"tags": null,
"N": 6
},
"uid": "M3404",
"labels": [
],
"alert_type": "update",
"file": "",
"description": "LOG: Set as preferred event for superevent: S180613bw"
}
```
CC @tanner.prestegard.https://git.ligo.org/computing/gracedb/server/-/issues/7Superevent 'new' and 'update' LVAlert messages have inconsistent structure2018-06-25T15:19:38ZLeo P. SingerSuperevent 'new' and 'update' LVAlert messages have inconsistent structureThe `new` and `update` LVAlert messages have very different structures. For the `new` message, the `uid` is the GraceDb ID of the superevent, whereas for the `update` message the `did` is the GraceDb ID of the subevent.
In fact, the upd...The `new` and `update` LVAlert messages have very different structures. For the `new` message, the `uid` is the GraceDb ID of the superevent, whereas for the `update` message the `did` is the GraceDb ID of the subevent.
In fact, the update messages do not even contain the superevent ID in a machine-friendly field; it is only present in the English comment field (e.g. `Set as preferred event for superevent: S180613bw`).
It would make it easier to deal with this LVAlert messages if they shared the same structure: the superevent ID and the preferred event ID should always be found in the same machine-friendly fields.
## New superevent
```json
{
"object": {
"superevent_id": "S180613bw",
"created": "2018-06-13 17:53:37 UTC",
"submitter": "emfollow",
"preferred_event": "M3404",
"t_start": 1212947423.09,
"t_0": 1212947433.09,
"t_end": 1212947443.09,
"gw_events": [
"M3404"
],
"em_events": [
],
"labels": [
],
"links": {
"files": "/apibasic/superevents/S180613bw/files/",
"logs": "/apibasic/superevents/S180613bw/logs/",
"self": "/apibasic/superevents/S180613bw/",
"labels": "/apibasic/superevents/S180613bw/labels/",
"voevents": "/apibasic/superevents/S180613bw/voevents/",
"emobservations": "/apibasic/superevents/S180613bw/emobservations/",
"events": "/apibasic/superevents/S180613bw/events/"
}
},
"uid": "S180613bw",
"labels": [
],
"alert_type": "new",
"file": "",
"description": "NEW: superevent S180613bw"
}
```
## Updated superevent
```json
{
"object": {
"comment": "Set as preferred event for superevent: S180613bw",
"file_version": null,
"tag_names": [
],
"file": null,
"created": "2018-06-13T17:53:37.431668+00:00",
"self": null,
"issuer": "emfollow",
"filename": "",
"tags": null,
"N": 6
},
"uid": "M3404",
"labels": [
],
"alert_type": "update",
"file": "",
"description": "LOG: Set as preferred event for superevent: S180613bw"
}
```
CC @tanner.prestegard.https://git.ligo.org/computing/gracedb/server/-/issues/10Some floats cast as strings in LVAlerts and response JSONs2018-06-26T21:46:26ZTanner PrestegardSome floats cast as strings in LVAlerts and response JSONsAs reported in https://git.ligo.org/emfollow/gwcelery/merge_requests/94, there are situations in which certain float variables are being sent as strings in LVAlert JSONs and even in some response JSONs from gracedb-client.
I believe thi...As reported in https://git.ligo.org/emfollow/gwcelery/merge_requests/94, there are situations in which certain float variables are being sent as strings in LVAlert JSONs and even in some response JSONs from gracedb-client.
I believe this is happening because in some of the old code in the events API, the event is converted to a dictionary BEFORE it is saved in the database. Thus, some variables which are extracted from the event file (as strings) are still in memory as strings. If we did the save first, that would cast those variables to the correct type.
I will submit some test events for the active pipelines (gstlal, gstlal-spiir, pycbc, mbtaonline, cwb, lib, swift, fermi, and snews) and check the LVAlert content, as well as the response in gracedb-client.https://git.ligo.org/computing/gracedb/server/-/issues/13createVOEvent() no longer returns the VOEvent text2018-06-28T12:21:23ZLeo P. SingercreateVOEvent() no longer returns the VOEvent textOn gracedb.ligo.org, the `createVOEvent()` method returns a JSON data structure that includes a key called `text` whose value is the contents of the VOEvent. This is gone on gracedb-playground.ligo.org.On gracedb.ligo.org, the `createVOEvent()` method returns a JSON data structure that includes a key called `text` whose value is the contents of the VOEvent. This is gone on gracedb-playground.ligo.org.https://git.ligo.org/computing/gracedb/server/-/issues/5superevents() query not returning complete set of superevents2018-06-28T12:22:14ZTanner Prestegardsuperevents() query not returning complete set of supereventsSee original post at https://git.ligo.org/lscsoft/gracedb-client/issues/6See original post at https://git.ligo.org/lscsoft/gracedb-client/issues/6https://git.ligo.org/computing/gracedb/server/-/issues/12Broken sky map image links on superevent pages (followup from !8)2018-06-28T17:45:09ZLeo P. SingerBroken sky map image links on superevent pages (followup from !8)Images in superevent pages are showing up with the URL `"undefined"`, so the links and `<img>` tags are broken. See, for example:
https://gracedb-playground.ligo.org/superevents/S180628r/view/Images in superevent pages are showing up with the URL `"undefined"`, so the links and `<img>` tags are broken. See, for example:
https://gracedb-playground.ligo.org/superevents/S180628r/view/https://git.ligo.org/computing/gracedb/server/-/issues/9sub-second time strings dropping leading zeros2018-07-03T16:44:01ZPeter Couvaressub-second time strings dropping leading zerosAs Jacob Lange reports on the CBC list, the event time in the event.log on Gracedb is wrong for 170818/G298171. The event time should be 1187058327.0815086 but the event.log says 1187058327.815086. It looks like the leading zero of the ...As Jacob Lange reports on the CBC list, the event time in the event.log on Gracedb is wrong for 170818/G298171. The event time should be 1187058327.0815086 but the event.log says 1187058327.815086. It looks like the leading zero of the sub-second string is being dropped somewhere.https://git.ligo.org/computing/gracedb/server/-/issues/14LVAlert messages for labels do not have a self link2018-07-11T18:28:43ZLeo P. SingerLVAlert messages for labels do not have a self link@deep.chatterjee found this one:
```
[2018-06-29 13:07:17,894: ERROR/ForkPoolWorker-1] gwcelery.tasks.lvalert.listen[5f526064-5919-425a-b17c-029b20cb5b72]: LVAlert message does not contain an API URL: {'labels': ['SKYMAP_READY'], 'alert...@deep.chatterjee found this one:
```
[2018-06-29 13:07:17,894: ERROR/ForkPoolWorker-1] gwcelery.tasks.lvalert.listen[5f526064-5919-425a-b17c-029b20cb5b72]: LVAlert message does not contain an API URL: {'labels': ['SKYMAP_READY'], 'alert_type': 'label', 'uid': 'S180629cb', 'file': '', 'description': 'LABEL: SKYMAP_READY added'}
```
@tanner.prestegard, would you please take a look?https://git.ligo.org/computing/gracedb/server/-/issues/31Intermitter server gateway timeouts2018-08-20T14:29:09ZTanner PrestegardIntermitter server gateway timeoutsCreated on April 5, 2017. Copied from redmine (https://bugs.ligo.org/redmine/issues/5418)
Several follow-up processes (approval processor, event supervisor, probably others) and one search pipeline (cWB) have reported receiving 504 gat...Created on April 5, 2017. Copied from redmine (https://bugs.ligo.org/redmine/issues/5418)
Several follow-up processes (approval processor, event supervisor, probably others) and one search pipeline (cWB) have reported receiving 504 gateway timeout errors when attempting to write log messages to GraceDB. Peter S reports that it happens for approval processor about once per day. It seems as though the log is still written, but the correct response is not sent, as the connection hangs for 2 minutes, then terminates.
The server also accumulates lingering threads owned by the wsgi_daemon user over time. It's not clear if these two issues are related.
I upgraded the production server to mod_wsgi 4.5.11 on 28 Mar 2017 in the hopes that it would take care of the lingering threads (tests on the development servers indicated that it cleared up lingering threads caused by overloading the server with log write processes), but it hasn't.https://git.ligo.org/computing/gracedb/server/-/issues/58Add backup IdP to GraceDB2018-09-06T15:30:27ZTanner PrestegardAdd backup IdP to GraceDBThe issues with login.ligo.org last week clearly demonstrate the need to allow authentication through GraceDB with the backup IdPs. I played around with it a bit but was not able to get it working in production, due to the fact that we ...The issues with login.ligo.org last week clearly demonstrate the need to allow authentication through GraceDB with the backup IdPs. I played around with it a bit but was not able to get it working in production, due to the fact that we don't pull the base LIGO metadata (we get it from InCommon).https://git.ligo.org/computing/gracedb/server/-/issues/18Change pipeline names for LIB and gstlal-spiir2018-09-19T15:13:53ZTanner PrestegardChange pipeline names for LIB and gstlal-spiirRequest from Reed Essick on January 20, 2017 (from https://bugs.ligo.org/redmine/issues/5043)
> In all our publications and internal documents, the pipeline is referred to as "oLIB." Therefore, it is the name "oLIB" that should be assoc...Request from Reed Essick on January 20, 2017 (from https://bugs.ligo.org/redmine/issues/5043)
> In all our publications and internal documents, the pipeline is referred to as "oLIB." Therefore, it is the name "oLIB" that should be associated with significance estimates and be allowed to create events in GraceDb. The name "LIB" commonly refers to the parameter estimation follow-up done for all burst events. While oLIB uses the LIB pipeline, they are nonetheless separate concepts. LIB PE results do not contain significance estimates in the same way that LALInference PE results do not.
>
> To minimize/mitigate possible confusion (which appears to be common), we propose changing the pipeline name in GraceDb. However, this will have many repercussions which we should carefully consider. An incomplete list includes
>
> * the need to update all historical events in GraceDb to follow the new nomenclature
> * the need to update all LVAlert nodes so they follow the new nomenclature
> * the need to update all follow-up processes so they listen to the new LVAlert nodes
>
> This change will almost certainly have to wait until a break between observing runs.
Request from Qi Chu on July 9, 2018 (from https://bugs.ligo.org/redmine/issues/6191)
> Dear Tanner,
>
> I would like to request the name for the SPIIR pipeline on the gracedb to be changed to "spiir" in order to remove the possible confusion that triggers from this pipeline are dependent on the that of gstlal pipeline. The connection with the gstlal pipeline is that the code of this pipeline is packed in the gstlal dev packages.
>
> Cheers!Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/8Reworking LVAlert types and contents2018-09-21T19:18:37ZTanner PrestegardReworking LVAlert types and contentsThere is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of al...There is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of alert JSON packet
Currently, LVAlert JSON packets include the following keys:
* object: dict representation of a database row; typically an event, superevent, or log object. Note that these should be identical to the representation of these object available from the API.
* description: text description of the action which triggered the alert
* uid: event graceid or superevent id
* alert_type: either "new", "label", "update", or "signoff"
* labels: list of label names attached to the event or superevent
* file: filename string (optional and relative)
## Actions for which GraceDB issues alerts
GraceDB issues LVAlerts when the following actions are taken:
### Events
Constants:
* uid: always the related event's graceid
* labels: always a list of the related event's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Event creation | "new" | event | Link to initial event file | "" |
| Event log creation (no file) | "update" | log | "" | "LOG: comment" |
| Event log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Label added to event | "label" | Not included in dict | "" | H1OK |
| Label removed from event | "update" | Not included in dict | "" | "Label H1OK removed" |
| VOEvent created for event | "update" | voevent | G0001-3-Update.xml | "VOEVENT: G0001-3-Update.xml" |
| EM observation created for event | "update" | emobservation | "" | "New EMBB observation record." |
| EMBB event log created for event | "update" | embb event log | "" | "New EMBB event log entry." |
| Event added to superevent | "update" | log | "" | "LOG: Added to superevent S180614b" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed from superevent S180614b" |
| Event selected as preferred event for superevent | "update" | log | "" | "LOG: Set as preferred event for superevent: S180614b" |
| Event removed as preferred event for superevent | "update" | log | "" | "LOG: Removed a preferred event for superevent: S180614b" |
| Operator or advocate signoff (initial or update) on event | "signoff" | signoff | "" | "OK" or "NO" |
### Superevents
Constants:
* uid: always the related superevent's superevent_id
* labels: always a list of the related superevent's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Superevent creation | "new" | superevent | "" | "NEW: superevent S180614a" |
| Superevent update (preferred event, t_start, t_0, t_end) | "update" | log | "" | "LOG: Updated superevent parameters: t_0: 1 -> 2, preferred_event: G0001 -> G0002" |
| Log creation (no file) | "update" | log | "" | "LOG: comment" |
| Log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Event added to superevent | "update" | log | "" | "LOG: Added event: G0001" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed event: G0001" |
| Label added to superevent | "label" | Not included in dict | "" | "LABEL: H1OK" |
| Label removed from superevent | "update" | Not included in dict | "" | "UPDATE: H1OK removed" |
| Confirm superevent as GW | "update" | log | "" | LOG: Confirmed as a gravitational wave." |
| Create VOEvent for superevent | "update" | voevent | S180614b-3-Update.xml | "VOEVENT: S180614b-3-Update.xml" |
| Create EMObservation for superevent | "update" | emobservation | "" | "New EMBB observation record for DESGW." |
| Operator or advocate signoff (initial or update) on superevent | "signoff" | signoff | "" | "OK" or "NO" |
| Operator or advocate signoff deleted | "update" | log | "" | "LOG: operator signoff for H1 deleted: H1OK removed and H1OPS reapplied" |
Note that there are no EMBB event logs for superevents since they seem to have fallen out of use (there were only ever 31 of them created and the last one was applied for events in ~2015).
## Actions for which GraceDB does not issue alerts
LVAlerts are *not* issued when the following actions occur:
* Event created with labels attached ("new" alert goes out but no "label" alert; this probably should happen)
* Note that superevents created with labels first issue "new" alerts and then "label" alerts
* Event "replaced" with new event file (should probably send an "update" alert)
* An event signoff is deleted.
* An event log or superevent log has a tag applied or removed (I don't think anyone wants to get this alert)
* A log message is generated to document the above action (I don't think anyone wants to get this alert)
# Development action items
We want to do the following:
* Define some new alert_type categories and what actions they should be used for.
* Add alerts for some of the actions listed above.
* Change what type of serialized object is included with certain alerts
* Add documentation of alert contents and actions which trigger them
We might want to:
* Add entirely new information to alerts (i.e., new dict key(s) and value(s))Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/15Rework permissions structure2018-09-21T19:22:21ZTanner PrestegardRework permissions structureWe need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no long...We need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no longer going to cover redoing the events permission structure; it will only focus on creating the superevents permission structure.
# Creation
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| create event | Specific LVK users only | Currently allowed for pipeline accounts and specific users; remove individual users? |
| create test event | All LVK users | |
| create superevent | emfollow/superevent manager | |
| create test superevent | All LVK users | |
| create MDC superevent | emfollow/superevent manager | |
# Updates
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| update/replace event | Only the user who originally submitted the event | Or should it be anyone who is allowed to submit events for the given pipeline? |
| update/replace test event | All LVK users | |
| update superevent | emfollow/superevent manager | Applies to production and MDC superevents |
| update test superevent | All LVK users | |
| add/remove event from superevent | emfollow/superevent manager | Production and MDC |
| add/remove event from test superevent | All LVK users | |
| confirm superevent as gw | Some special people | Should emfollow/superevent manager be on this list? |
| confirm test superevent as gw | All LVK members | |
| confirm mdc superevent as gw | emfollow/superevent manager | |
# Annotations
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| add log message/file | All LVK (all events/superevents); LV-EM (only exposed events/superevents) | Not allowed for public users (?) |
| tag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| untag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| add label | Specific LVK members can add specific labels | Needs some thought and a finalized list of labels to define this |
| remove label | Specific LVK members can remove the same specific labels | |
| create voevent | emfollow | Are others needed? |
| create emobservation | All LVK (all events/superevents) and all LV-EM (all exposed events/superevents) | This is a little weird because as far as I know, only LV-EM people should be uploading EM observations |
| add/update/remove operator signoff | LVK members in control rooms | Control room groups controlled by IP address |
| add/update/remove advocate signoff | LVK members in em_advocates group | |
# Viewing
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| view event | All LVK (all events/superevents); LV-EM/Public (exposed events/superevents? Or just superevents?) | Applies equally to production and test events. Note to self: need to consider event subtypes and permissions on those as well |
| view logs | All LVK (all event/superevent logs); LV-EM/Public (exposed logs only) | Logs will be exposed via a tag ('lv-em' or 'public'); files associated with exposed logs will also be exposed | |
| view voevents | All LVK (all voevents); not sure about LV-EM or public | Currently, all VOEvents are viewable to anyone who can view the event|
| view emobservations | All LVK (all emobservations); not sure about LV-EM or public | Currently, all EMObservations are viewable to anyone who can view the event |
# Main questions
1. Who can add/remove which labels? Or should all LVK users be able to add/remove all labels?
2. Who can expose/hide events and superevents?
3. Who can expose/hide logs with the 'lv-em' and 'public' tags?
4. Does exposing a superevent to external users mean that we should expose all of the individual events as well?
5. Who can confirm superevents as GWs?Move superevents branch onto production GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/70Critical unit tests2018-09-25T15:13:14ZTanner PrestegardCritical unit testsWe need unit tests for checking permissions for superevents. We have to check all API "actions", views, etc. and all web views.We need unit tests for checking permissions for superevents. We have to check all API "actions", views, etc. and all web views.Move superevents branch onto production GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/72Policy for alerts2018-10-05T17:01:56ZTanner PrestegardPolicy for alertsWe should define a policy for alerts and post it at least on a page on GraceDB, possibly in the DCC as well. The main questions to be answered by this policy are:
1. Should any alerts (phone, email, LVAlert) be sent out outside of obse...We should define a policy for alerts and post it at least on a page on GraceDB, possibly in the DCC as well. The main questions to be answered by this policy are:
1. Should any alerts (phone, email, LVAlert) be sent out outside of observing runs?
2. How should we handle existing alerts when beginning a new observing run?
There is potential for an issue to occur due to people leaving the collaboration, but still having alerts set up. But as long as the LDAP is kept up-to-date, that shouldn't be a problem, since we already have a nightly cron job which deletes all Contacts and Triggers for users who are no longer in the LVC.https://git.ligo.org/computing/gracedb/server/-/issues/85Clean up access options for userprofile pages2018-11-15T20:22:44ZTanner PrestegardClean up access options for userprofile pagesCheck on access for userprofile pages for unauthenticated users, may want to create unit testsCheck on access for userprofile pages for unauthenticated users, may want to create unit testsPublic-facing GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/84Unit tests for event web urls2018-11-19T17:23:38ZTanner PrestegardUnit tests for event web urlsAdd unit tests to check access/authorization for web URLs in the events app.
Things which need to be tested:
* [x] Event detail pages
* [x] Event file list pages
* [x] Event file download pages
* [x] Event creation page
* [x] Event neig...Add unit tests to check access/authorization for web URLs in the events app.
Things which need to be tested:
* [x] Event detail pages
* [x] Event file list pages
* [x] Event file download pages
* [x] Event creation page
* [x] Event neighbor pages
* [x] ~~Event VOEvent creation pages~~ **(deleted)**
* [x] Modify t_90 pages
* [x] Modify permissions pages
* [x] Modify signoff pages
* [x] Log entry creation page
* [x] Log entry tag page
* [x] ~~Process EMBB event log page~~ **(deleted)**
* [x] Process EMObservation pagePublic-facing GraceDB2018-11-19https://git.ligo.org/computing/gracedb/server/-/issues/89Make documentation accessible2018-11-19T20:18:19ZTanner PrestegardMake documentation accessibleCurrently, the documentation is built by Sphinx and served by apache. We need to serve it separately so that we can easily handle authentication for it.
Might be possible to just serve the files via X-Sendfile and write some simple views.Currently, the documentation is built by Sphinx and served by apache. We need to serve it separately so that we can easily handle authentication for it.
Might be possible to just serve the files via X-Sendfile and write some simple views.Public-facing GraceDB2018-11-30https://git.ligo.org/computing/gracedb/server/-/issues/90Remove log and emobservation creation boxes from public event/superevent pages2018-11-19T21:31:15ZTanner PrestegardRemove log and emobservation creation boxes from public event/superevent pagesPublic users can't create logs or emobservations, so those forms should not be shown.Public users can't create logs or emobservations, so those forms should not be shown.Public-facing GraceDB