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

[9.0] Optimising PilotWrapper size? #7820

Open
sfayer opened this issue Oct 9, 2024 · 0 comments
Open

[9.0] Optimising PilotWrapper size? #7820

sfayer opened this issue Oct 9, 2024 · 0 comments
Assignees

Comments

@sfayer
Copy link
Member

sfayer commented Oct 9, 2024

Hi,

While looking into why v9 pilots fail on the cloud with @marianne013, one of the issues we're running into is the cloud user_data sometimes overflows the default 64k limit of OpenStack (unfortunately there is a lot of base64-inside-base64 on the cloud that's somewhat unavoidable). Now that the PilotWrapper includes its own proxy, there is an outer proxy that can probably be removed at the cloud-init level, which we'll look at doing soon.

The runner up on "pilot wrapper space use" is this construct:

if sys.version_info < (3,):
fd.write(bz2.decompress(base64.b64decode(\"\"\"%(encodedPf)s\"\"\")))
else:
fd.write(bz2.decompress(base64.b64decode(b'%(encodedPf)s')))

The encodedPf variable expands to around a ~8k string so having two copies is somewhat suboptimal (the entire pilot wrapper is 25k, 16k of that is the two proxy copies). Do you think there is some trick we can do to support py2 & py3 with only a single copy of the actual long string? (Alternately I guess dropping py2 support here at this point would also be an easy fix, but I'm not sure what people think about that...)

Regards,
Simon

@fstagni fstagni self-assigned this Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants