IGWN Alert Client issueshttps://git.ligo.org/computing/igwn-alert/client/-/issues2024-02-23T21:44:36Zhttps://git.ligo.org/computing/igwn-alert/client/-/issues/43Discrepancy between bytes vs str when launching igwn alert client; does not e...2024-02-23T21:44:36ZDeep Chatterjeedeep.chatterjee@ligo.orgDiscrepancy between bytes vs str when launching igwn alert client; does not exist in version 0.5In gwcelery, igwn-alert version 0.5 works as expected, but version 0.6 gives the follow error at startup.
```
Traceback (most recent call last):
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/worker/worker.py...In gwcelery, igwn-alert version 0.5 works as expected, but version 0.6 gives the follow error at startup.
```
Traceback (most recent call last):
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/worker/worker.py", line 202, in start
self.blueprint.start(self)
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/bootsteps.py", line 116, in start
step.start(parent)
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/bootsteps.py", line 365, in start
return self.obj.start()
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/worker/consumer/consumer.py", line 340, in start
blueprint.start(self)
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/celery/bootsteps.py", line 116, in start
step.start(parent)
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/gwcelery/igwn_alert/bootsteps.py", line 104, in start
self._client = IGWNAlertClient(
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/gwcelery/igwn_alert/bootsteps.py", line 22, in __init__
super().__init__(*args, **kwargs)
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/igwn_alert/client.py", line 139, in __init__
self.base_url_prefix = self._construct_base_url()
File "/home/emfollow-playground/.local/lib/python3.9/site-packages/igwn_alert/client.py", line 195, in _construct_base_url
path=old.path + self.group_prefix,
TypeError: can't concat str to bytes
```https://git.ligo.org/computing/igwn-alert/client/-/issues/39Clarify supported Python versions2024-02-05T19:16:10ZDaniel WysockiClarify supported Python versionsThe package metadata lists support for Python 3.6 to 3.9 [here](https://git.ligo.org/computing/igwn-alert/client/-/blob/285836059b9c6a73daf7b420f538a22e3f8ab09d/setup.py#L80-83).
However, it also specifies support for Python >=3.6 [here...The package metadata lists support for Python 3.6 to 3.9 [here](https://git.ligo.org/computing/igwn-alert/client/-/blob/285836059b9c6a73daf7b420f538a22e3f8ab09d/setup.py#L80-83).
However, it also specifies support for Python >=3.6 [here](https://git.ligo.org/computing/igwn-alert/client/-/blob/285836059b9c6a73daf7b420f538a22e3f8ab09d/setup.py#L89).
Is 3.10 still unsupported? If so, we should add an upper limit in that second reference. Otherwise, we should add 3.10 (and I suspect _not_ 3.11) to the first list, and add the appropriate upper limit to the second reference.Daniel WysockiDaniel Wysockihttps://git.ligo.org/computing/igwn-alert/client/-/issues/19Igwn-alert listener should retry error codes that are not fatal2024-02-05T19:28:53ZDeep Chatterjeedeep.chatterjee@ligo.orgIgwn-alert listener should retry error codes that are not fatalCertain error codes from confluent-kafka/adc-streaming can be retried. From talking to Patrick Godwin, it seems like errors like this https://sentry.io/organizations/ligo-caltech/issues/3860496106/?query=is%3Aunresolved+KafkaException&re...Certain error codes from confluent-kafka/adc-streaming can be retried. From talking to Patrick Godwin, it seems like errors like this https://sentry.io/organizations/ligo-caltech/issues/3860496106/?query=is%3Aunresolved+KafkaException&referrer=issue-stream&statsPeriod=14d could be retried. The igwn-alert listener should handle such cases.https://git.ligo.org/computing/igwn-alert/client/-/issues/14igwn-alert client only considers the first entry in the .config/hop/auth.toml...2023-02-27T05:09:59ZLeo P. Singerigwn-alert client only considers the first entry in the .config/hop/auth.toml file, regardless of hostnameThe igwn-alert client always uses the first entry in the .config/hop/auth.toml file, even if the hostname indicates that it is for a different Kafka broker. For example, if the auth.toml file looks like this:
```
[[auth]]
username = ".....The igwn-alert client always uses the first entry in the .config/hop/auth.toml file, even if the hostname indicates that it is for a different Kafka broker. For example, if the auth.toml file looks like this:
```
[[auth]]
username = "..."
password = "..."
protocol = "SASL_SSL"
mechanism = "OAUTHBEARER"
token_endpoint = "https://auth.gcn.nasa.gov/oauth2/token"
hostname = "kafka.gcn.nasa.gov"
ssl_ca_location = "..."
[[auth]]
username = "..."
password = "..."
protocol = "SASL_SSL"
mechanism = "SCRAM-SHA-512"
ssl_ca_location = "..."
```
then igwn-alert will read and erroneously use just the first section, and attempt to use OAUTHBEARER authentication, which of course fails:
```
%3|1668050501.055|FAIL|rdkafka#consumer-2| [thrd:sasl_ssl://kafka.scimma.org:9092/bootstrap]: sasl_ssl://kafka.scimma.org:9092/bootstrap: SASL OAUTHBEARER mechanism handshake failed: Broker: Unsupported SASL mechanism: broker's supported mechanisms: PLAIN,SCRAM-SHA-512 (after 151ms in state AUTH_HANDSHAKE)
```
Switching the order of the entries in the auth.toml file fixes it:
```
[[auth]]
username = "..."
password = "..."
protocol = "SASL_SSL"
mechanism = "SCRAM-SHA-512"
ssl_ca_location = "..."
[[auth]]
username = "..."
password = "..."
protocol = "SASL_SSL"
mechanism = "OAUTHBEARER"
token_endpoint = "https://auth.gcn.nasa.gov/oauth2/token"
hostname = "kafka.gcn.nasa.gov"
ssl_ca_location = "..."
```https://git.ligo.org/computing/igwn-alert/client/-/issues/2Perform network benchmarking2021-12-08T20:35:46ZAlexander PacePerform network benchmarkingWay back in the [way back](https://dcc.ligo.org/LIGO-T1800079), I (@alexander.pace) had done some benchmarking work with XMPP LVAlert client and server and produced curves, ex:
![Screen_Shot_2021-12-08_at_2.54.10_PM](/uploads/fc4754635f...Way back in the [way back](https://dcc.ligo.org/LIGO-T1800079), I (@alexander.pace) had done some benchmarking work with XMPP LVAlert client and server and produced curves, ex:
![Screen_Shot_2021-12-08_at_2.54.10_PM](/uploads/fc4754635f3b09229ec6b15de3cae98f/Screen_Shot_2021-12-08_at_2.54.10_PM.png)
of round-trip latency and throughput as a function of message size. Later I used them to inform and substantiate my claims that LVAlert could "handle" larger message sizes. Apache/Confluent [claims](https://www.confluent.io/blog/kafka-fastest-messaging-system/) about maximum attainable throughput and minimum latencies, but it would be informative to have real-world results with our client and server to back it up.
In particular I'm thinking about supporting the gracedb/igwn_alert/superevent_manager issue (https://git.ligo.org/lscsoft/gracedb/-/issues/210).
Afterwards, check in the script for the future and put the chart in a gitlab wiki page or something.Alexander PaceAlexander Pace