Hi Tristan, Le jeu. 28 janv. 2021 à 09:12, Tristan Van Berkom <[email protected]> a écrit : > > Hi all, > > Since there was no activity on this thread for a very long time, I > decided to go ahead and take a crack at this. > > I have a good branch now that is ready for review. The MR is up here: > https://github.com/apache/buildstream/pull/1453 > > > I'm sending a detailed email because it's a large proposal and I would > like this to be visible, so that people can chime in incase we've > missed an important use case.
This is something I've been meaning to reply to for a long time, but never found the time. I've now gone through your proposal, and I must say I like it. A couple remarks inline: > Authentication > -------------- > For all of the authentication related properties, `server-cert`, > `client-cert` and `client-key`, these have been split out into a > subdictionary named "auth" for any remote configuration. > > This may allow better extensibility for alternative authentication > methods in the future, however right now it serves us very well to be > able to document the "auth" dictionary in one central place in the > documentation. I think it's better to keep `server-cert` out of the sub-dictionary. The server certificate is needed when the server is using an untrusted certificate regardless of whether we want to authenticate with the server and regardless of the method we use to authenticate (currently client certificate, but we may want to support some kind of access token in the future like buildbox) > Artifact and Source cache configuration > --------------------------------------- > Projects are still allowed to provide recommendations for artifact and > source cache servers. > > User configuration now has the ability to override them, i.e. disregard > artifact and source cache servers declared in projects. > > Also, it is no longer possible to declare an artifact/source cache > server as a dictionary, it MUST be a list. > > This choice is simply because it the dict-or-list tactic here does not > buy us any convenience whatsoever, and clarity that it is in fact a > list of dictionaries is more worthwhile. I think this makes sense. > Project Configuration > ~~~~~~~~~~~~~~~~~~~~~ > > # > # This is mostly unchanged, except for the `auth` > # > artifacts: > - url: https://pony.com:9999 > type: both > push: false > instance-name: this-shard > auth: > server-cert: server.crt I assume `both` here means index+storage? (as in CAS + RA) > User Configuration > ~~~~~~~~~~~~~~~~~~ > We can declare global artifact configuration, which either > overrides or augments project recommended cache servers. > > When "augmenting", the user configuration is still at a higher priority > than the project recommendations (as in: user configuration caches will > be consulted *first* when interacting with remotes). I think this makes a lot of sense, but is the reverse of what bst1 does. I hope there won't be objections to changing it. > # > # Global artifact configuration > # > artifacts: > > # > # Here we decide whether user configuration overrides > # project recommendations. > # > override-project-caches: true This would be useful as a command line argument too. Regards, Abderrahim
