Skip to content
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

Merged
merged 1 commit into from
Oct 17, 2023
Merged

Conversation

oliver-sanders
Copy link
Member

Check List

  • I have read CONTRIBUTING.md and added my name as a Code Contributor.
  • Contains logically grouped changes (else tidy your branch by rebase).
  • Does not contain off-topic changes (use other PRs for other changes).
  • Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
  • Tests are included (or explain why tests are not needed).
  • CHANGES.md entry included if this is a change that can affect users
  • Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
  • If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

@oliver-sanders oliver-sanders added this to the cylc-8.3.0 milestone Aug 8, 2023
@oliver-sanders oliver-sanders self-assigned this Aug 8, 2023
@@ -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;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dwsutherland

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?

Copy link
Member

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..

_globals['_ALLDELTAS']._serialized_start=8687
_globals['_ALLDELTAS']._serialized_end=8896
_PBMETA._serialized_start=34
_PBMETA._serialized_end=184
Copy link
Member

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

Copy link
Member Author

@oliver-sanders oliver-sanders Aug 9, 2023

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?

Copy link
Member

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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.

Copy link
Member Author

@oliver-sanders oliver-sanders Oct 5, 2023

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.

Copy link
Member

@MetRonnie MetRonnie Oct 6, 2023

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

Copy link
Member

@MetRonnie MetRonnie left a 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

Copy link
Member

@dwsutherland dwsutherland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@dwsutherland
Copy link
Member

dwsutherland commented Sep 7, 2023

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

As long as the UIS/UI/TUI never specifically asked for the field, I think we're fine.
The reason for for reserving the field is to not break clients (UIS) that were specifically asking for that field (which we just need to confirm we weren't (which I don't think we are

def apply_delta(key, delta, data):
).

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..

  • Load up new (this branch) version of UIS
  • Switch flow to not this branch, and run a workflow

UIS shouldn't break.

@dwsutherland
Copy link
Member

dwsutherland commented Sep 7, 2023

Tested it,

  • UIS this branch (regenerated the data_messages_pb2.py)
  • Scheduler running master

and found working:
image

@oliver-sanders
Copy link
Member Author

Right so, conclusions:

  • Compiling with an older protobuf version is fine and possibly safer.
  • Removing the field is ok so long as we were never using it.

@oliver-sanders
Copy link
Member Author

I've tested this with the UIS/Scheduler running this-branch/8.2.1 and vice versa, it seems to be working fine.

@MetRonnie
Copy link
Member

Thinking this through, I would imagine we still wouldn't want to be in the position where:

  1. We've added a new field with this same field number
  2. A new UIS asks for this field number from an old scheduler, thus getting the old extra_log_files result instead of whatever it was actually asking for

@oliver-sanders
Copy link
Member Author

Enough to jam a comment in to "reserve" the old field number?

@MetRonnie
Copy link
Member

I think all that's needed is

 message PbJob {
+  reserved 29;
   optional string stamp = 1;
   optional string id = 2;

https://protobuf.dev/programming-guides/proto3/#deleting,

* Closes cylc#5610
* Remove residual code leftover from the obsolete `extra log files`
  runtime configuration option.
@oliver-sanders
Copy link
Member Author

Ok, reserved

@MetRonnie
Copy link
Member

Did you regenerate the pb2 file after reserving the field?

@oliver-sanders
Copy link
Member Author

Copy link
Member

@MetRonnie MetRonnie left a 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

@MetRonnie MetRonnie merged commit 653317f into cylc:master Oct 17, 2023
21 of 23 checks passed
wxtim added a commit to wxtim/cylc that referenced this pull request Oct 18, 2023
* upstream/master:
  speed up import time (cylc#5770)
  graphql: remove extraLogs field (cylc#5672)
  give a more useful error message if remote init fails (cylc#5720)
  clarify SLURM job handler docs (cylc#5748)
@MetRonnie MetRonnie added the schema change Change to the Cylc GraphQL schema label Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema change Change to the Cylc GraphQL schema
Projects
None yet
Development

Successfully merging this pull request may close these issues.

extra log files: remove legacy
3 participants