-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extra log files: remove legacy #5672
Conversation
@@ -144,7 +144,6 @@ message PbJob { | |||
optional float execution_time_limit = 14; | |||
optional string platform = 15; | |||
optional string job_log_dir = 17; | |||
repeated string extra_logs = 29; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This field is no longer needed, is it safe to remove a "repeated string"?
Could this cause compatibility problems between cylc-flow and cylc-uiserver at different versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine, since I don't think we ask for this field anywhere.. And as long as we don't reuse 29
..
cylc/flow/data_messages_pb2.py
Outdated
_globals['_ALLDELTAS']._serialized_start=8687 | ||
_globals['_ALLDELTAS']._serialized_end=8896 | ||
_PBMETA._serialized_start=34 | ||
_PBMETA._serialized_end=184 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI it looks like you may have used an older version of protoc, if that matters. I tried the latest version 24.0 and it put back all of these _globals
bits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I'll regenerate this based on the outcome of the above comment.
Is it actually sensible to generate this file with the latest version, should we be generating it with the oldest supported version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's safe to use within and up to the minor version, i.e. with pip freeze
version:
protobuf==4.21.12
I used protoc
version:
sutherlander@cortex:~$ protoc --version
libprotoc 3.21.12
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably upgrade at some point lol .. might put up a PR after a few of these (including the no-rewalk) has gone in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can upgrade whenever, the only reason we pin this dependency so hard is that we haven't found out what the protobuf compatibility policy is yet, i.e. the span of versions should be inter-compatible.
After [a lot of] digging we were able to confirm that slackening the ZMQ dependency bounds was safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Frustrating lack of info on the compatibility of protoc versions - protocolbuffers/protobuf#11123
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually after looking at the docs a little, it seems we need to reserve the deleted field number: https://protobuf.dev/programming-guides/proto3/#deleting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
As long as the UIS/UI/TUI never specifically asked for the field, I think we're fine. cylc-flow/cylc/flow/data_store_mgr.py Line 289 in 5b76dba
If the field is set/sent (in an older scheduler), it just won't be read into the new object definition on the UIS end.. Can always test this..
UIS shouldn't break. |
Right so, conclusions:
|
I've tested this with the UIS/Scheduler running this-branch/8.2.1 and vice versa, it seems to be working fine. |
Thinking this through, I would imagine we still wouldn't want to be in the position where:
|
Enough to jam a comment in to "reserve" the old field number? |
I think all that's needed is message PbJob {
+ reserved 29;
optional string stamp = 1;
optional string id = 2; |
* Closes cylc#5610 * Remove residual code leftover from the obsolete `extra log files` runtime configuration option.
abf2d03
to
840096b
Compare
Ok, reserved |
Did you regenerate the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing with mixed versions of scheduler/UIS didn't bring up any problems
extra log files
runtime configuration option.Check List
CONTRIBUTING.md
and added my name as a Code Contributor.setup.cfg
(andconda-environment.yml
if present).CHANGES.md
entry included if this is a change that can affect users?.?.x
branch.