but we shouldn’t overlap (or diverge) with any existing configuration used at LI

@Felix GV @Zac Policzer any suggestions ?

can we implement it ? or do you have some code to share ?

Ok. Glancing at it, it looks like what we do in production is we pass and build an sslFactory to the constructor of RouterServer and wrap and run it. So we don't run run(routerConfigFilePath, boolean runForever) in production. But it should be a pretty easy patch to just extract the properties if they're present.

Hrm. Although. Maybe theres an opportunity here to make progress on your VIP

My initial thought was to do the quick patch and just add a property like 'use local ssl params' and then add a branch to

Optional<SSLFactory> sslFactory = Optional.of(SslUtils.getVeniceLocalSslFactory());

Where when it's set to false, sslFactory gets built from whatever properties are in the config file. But maybe we can get a bit fancier and include a property that lists the authentication class?

What do you think @Enrico Olivelli?

Something like:

Optional<AuthorizerFactory> authorizerFactory; // New class proposed in VIP-1 (I forgot the name)
    if (props.getBoolean(ConfigKeys.USE_LOCAL_SSL_ENGINE, true)) {
      authorizerFactory = Optional.of(SslUtils.getVeniceLocalSslFactory()); // Default class which exists
    } else {
      authorizerFactory = buildSomethingElse(props); // can use reflection to build whatever impl we want and extract relevant configs
    }

    RouterServer server = new RouterServer(props, new ArrayList<>(), Optional.empty(), authorizerFactory);

In that case, I'll cut a quick patch that does the above minus any fanciness

Upon further inspection, it actually already has the utility that I mentioed. You can specify a fully specified class that implements SSLFactory and build whatever engine you would like.

this is merged in @Nicolò Boschi, let me know if you need anything else to get unblocked

so quick !

Left a few comments