Merge ~hyask/autopkgtest-cloud:skia/fix_push_amqp into autopkgtest-cloud:master

Proposed by Skia
Status: Merged
Merged at revision: d20f6b4e1c11f02555524b6a709c033d6e0073df
Proposed branch: ~hyask/autopkgtest-cloud:skia/fix_push_amqp
Merge into: autopkgtest-cloud:master
Diff against target: 35 lines (+17/-0)
1 file modified
charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/push-amqp (+17/-0)
Reviewer Review Type Date Requested Status
Paride Legovini Approve
Tim Andersson Approve
Review via email: mp+463919@code.launchpad.net

Description of the change

Fix pull/push-amqp workflow.

To post a comment you must log in.
Revision history for this message
Tim Andersson (andersson123) wrote :

LGTM, looks like there's a typo in the commit msg (red->read) but other than that this looks great to me :)

review: Approve
Revision history for this message
Paride Legovini (paride) wrote :

Hmm, I think we should figure out a way to keep the escapes literal on the pull-amqp side, and avoid printing the b'...'. Dealing with the literal b'...' doesn't feel right to me.

Revision history for this message
Skia (hyask) wrote :

Yes, I agree, but as I explained in the commit log, I don't see a simple way forward to do this right now. Would you prefer that I give a try to the `\0` solution? That's way less common in a shell pipeline, although not completely non-existing, with `find -print0`.

Revision history for this message
Skia (hyask) wrote :

I've found a way to print the strings with escaped endline **and** without converting to bytes: `repr()`. We could indeed use that in `pull-amqp` to avoid printing bytes, but then I couldn't solve the problem of interpreting the `\n` as a real single character endline. We could in the end hack that with a `.replace("\\n", "\n")` (or `.replace(r"\n", "\n")`, it's the same), but I find it even more hacky since we don't really cover everything, and I think passing the information with bytes is more robust.

As we discussed, we need to build a plan to change the message format to be easier to work with.

Also discussed, I've added a log and a skip condition if the heuristic for bytes fails, meaning the message is probably malformed.

Revision history for this message
Paride Legovini (paride) wrote :

Thanks for trying the alternative approaches. This is hacky but good enough for now, as mentioned already the right thing to fix is the weird format of the queue entries.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1diff --git a/charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/push-amqp b/charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/push-amqp
2index ecc1355..dff98a7 100755
3--- a/charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/push-amqp
4+++ b/charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/push-amqp
5@@ -1,6 +1,7 @@
6 #!/usr/bin/python3
7
8 import argparse
9+import ast
10 import configparser
11 import sys
12
13@@ -67,6 +68,22 @@ def main():
14 else:
15 while True:
16 message = sys.stdin.readline()
17+ if message.startswith("b'") and message.endswith("'"):
18+ # this is most likely bytes that we need to interpret as a string
19+ # `literal_eval` is far safer than a true `eval`: the warnings
20+ # around it in the documentation mostly mention denial of
21+ # service, and possible huge memory consumption with evil
22+ # content, but that function should be safe from a code
23+ # execution point of view.
24+ # DoS is no big deal in a CLI tool
25+ message = ast.literal_eval(message).decode("utf-8")
26+ else:
27+ print(
28+ "WARNING: Message was not detected as bytes, it may be malformed. "
29+ f"Skipping. (msg: `{message}`)",
30+ file=sys.stderr,
31+ )
32+ continue
33 if not message:
34 break
35 try:

Subscribers

People subscribed via source and target branches