Add a client for sending internal events #48
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the client that should be used together with the SSE v2 server Also updated the rabbitmq log handler to send using this client instead The logger will now publish all logs, not only user logs. Note that the client is written in go, exported as a shared C library and then loaded into python. The client can be built using make build and is stored in the bindings directory. To enable these bindings when testing locally an environment variable called BINDINGS must be set to the bindings directory. The reason for deciding to use Go -> C -> Python instead of using the python library that exists is because the Python library is lackluster in my opinion. Error messages were unclear and it was quite slow. It is also written with asyncio which causes it to infect everything else and made the client a lot more difficult to create. With Go we get a reliable, and fast, publisher and we can use it for our Go code as well and since we are going the route (at some point) in re-writing ETOS into Go I don't see this as a problem. This solution is not ready and there are TODOs. I just want feedback on the approach.
t-persson
requested review from
fredjn and
andmat900
and removed request for
a team
With more knowledge comes cleaner code. Instead of managing the state in global variables we now pass a pointer to a handler back to the Python code. The Python code is expected to pass this pointer back when it calls subsequent methods.
Added the code back for the v1 protocol. Created a common interface that all publisher clients must adhere to. Also added the ability for the etos library to publish events on the v1 protocol.
Pass connection string as string instead if []string Add directory to reports and artifacts Make datestring a datetime object instead of string
|
What's missing here now is building the C shared library when building python |
Fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Applicable Issues
Description of the Change
This is the client that should be used together with the SSE v2 server Also updated the rabbitmq log handler to send using this client instead The logger will now publish all logs, not only user logs.
Note that the client is written in go, exported as a shared C library and then loaded into python. The client can be built using make build and is stored in the bindings directory. To enable these bindings when testing locally an environment variable called BINDINGS must be set to the bindings directory.
The reason for deciding to use Go -> C -> Python instead of using the python library that exists is because the Python library is lackluster in my opinion. Error messages were unclear and it was quite slow. It is also written with asyncio which causes it to infect everything else and made the client a lot more difficult to create. With Go we get a reliable, and fast, publisher and we can use it for our Go code as well and since we are going the route (at some point) in re-writing ETOS into Go I don't see this as a problem.
This solution is not ready and there are TODOs. I just want feedback on the approach.
Alternate Designs
Possible Drawbacks
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Tobias Persson [email protected]