hannesm
commented
2 years ago Take P as a metavariable of a platform.
the revised plan is:
- script_job will be extended with a platform
- orb_build_job will be left untouched, but there can be multiple orb-builder.template.P
Internally, the server will have a queue for each platform (i.e. mutable queue is a map keyed by platform).
The add_to_queue will add the job to all queues that are suitable.
When a worker connects, it sends a Job_requested P, and there is no queue for that worker (i.e. the map above does not carry a binding for P):
- the schedule is investigated for P-only (script-)jobs
- the orb-build.template.P is checked to exist If any of the above is true, a new queue is created (and added to the map with P as key).
The job_to_script now uses P (to select the template).
The client schedule requires a platform name, the client execute optionally gets a platform name.
The (platform) queues are never deleted, which means the server may consume more and more memory (and does more and more work in add_to_queue [which checks that a job with the same name does not already exist - that is good:)]).
after a discussion with @reynir, the plan is as follows:
To retain backwards compatibiity, the platform should be optional (also useful for unikernel builds). this should then as well clean up some bits and pieces in builder-web. I don't think a more elaborated thing than a string makes sense here.
I.e. the ASN.1 of client_hello2 (atm sequence2 (typ, version)) should be sequence3 (typ, version, optional utf8_string platform). Similar change for exec -- add an optional string to the sequence.
At the same time, we can remove the client_hello/server_hello (earlier versions) since we have upgraded our builders (woker & server) to the most recent versions anyways :)