Re: [BuildStream] Proposal: Add 'remote-execution' project configuration
- From: Ed Baunton <edbaunton gmail com>
- To: Jim MacArthur <jim macarthur codethink co uk>
- Cc: buildstream-list gnome org
- Subject: Re: [BuildStream] Proposal: Add 'remote-execution' project configuration
- Date: Mon, 20 Aug 2018 13:47:10 -0400
On first glance this seems reasonable to me with the below queries; Sander and I discussed a little this morning.
1. How would the config file look if we want a different endpoint for e.g. CAS?
We of course want the UX of "remoting" of builds to be as simple to configure as possible (as you have it now). Do we have a plan on how to add support for customising certain specific aspects to specific endpoints (like ArtifactCache, CAS etc. as noted here
https://gitlab.com/BuildStream/buildstream/issues/454#note_93345286) so that they don't all have to reside behind the same endpoint? Would we add optional overrides for specific services that would otherwise fallback to the remote ex endpoint?
2. Does the entirety of project.conf participate in the calculation of the cache key?
This might be a misunderstanding or lack of knowledge on my part (so please excuse), but if we commit a project.conf that has remote configuration set for an endpoint and port, does that constitute part of the identity of the project itself? Or is it ignored? I.e. If I change the remoting endpoint in project.conf is the whole thing rebuilt because all the cache keys are invalidated? I believe a similar question applies for user.conf. Equally, users might specialise the remoting endpoint based on their location but we wouldn't want that to impact cache hits.
3. Finally, would it be possible to specify overrides for each of these remoting parameters via command line arguments?
It would be useful for debugging (for example) to be able to override this setting from the command line. Is there prior art in BuildStream for overriding project.conf params with command line args? I understand this might invalidate cache keying but would be a real help for usability/UX/prototyping of remote ex. Equally, an option to disable e.g. because I am on an airplane.
Thanks,
Ed
I'd like to add an option to the project and element YAML spec to
control remote execution. In the code, the remote execution part of
BuildStream takes the form of a third sandbox, but I don't think it
makes sense for the user to consider remote execution as a type of
sandbox. Hence, I think this needs a new top-level label. If anyone
thinks it'd fit into an existing top-level label I'd be happy to change
it. Does this look like a reasonable approach?
Problem Statement
=================
We need a means to tell Buildstream when to use remote execution and the
connection details for the build server.
Proposal
========
Add a 'remote-execution' top level label for project.conf and elements.
This would contain a single element, 'url', containing the hostname and
port. For example:
----
remote-execution:
url: buildgridserver.example.com:50051
----
This should be usable in element configuration as well as project.conf,
to enable or disable remote execution per-element. To disable remote
execution in an element when it's enabled by project.config, 'url: ',
'url: null' or 'url: ""' will be accepted.
We expect to add further options to specify SSL keys and certificates in
the future and can raise a new proposal for that.
Implementation
==============
Very similar to current configuration options for the 'sandbox' label.
The resulting value would be checked in element.__sandbox and used to
select the remote sandbox object if present.
--
--
Codethink privacy policy: https://www.codethink.co.uk/privacy.html
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]