Spring Boot Centraldogma Loader

[flex-gyeongil]

Disclaimer
This PR contains multiple conceptual things which is on-going development under flex-team.

We affected huge conflict between upstream. so want to resolve some discussion point about our current approach.

Motivation 1
To make centraldogma k8s native

boot-loader, and jib is related

Motivation 2
To support SAML group authorization

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[flex-gyeongil]

To make separated concern for other configurations.
I had some dependency issues by this.

[minwoox]

Not sure which problem you've gone through but make sure not to include the slf4j1 for spring boot3 module.

[flex-gyeongil]

Temporal handling due to known port erasing.

[minwoox]

Oops what's the bug btw?

[flex-gyeongil]

Discussion point 1.

Due to hard coupling between configs and jackson deserialization, I wanna suggest to split configuration spec and it's implementation.

This approach can separate dependencies between jackson and others.

[minwoox]

That's a good suggestion but I prefer dererring the separation until we use a configuration format that JAckson does not support, as Jackson already supports the YAML format:

public static CentralDogmaConfig load(File configFile) throws JsonMappingException, JsonParseException {
    requireNonNull(configFile, "configFile");
    try {
        if (configFile.getPath().endsWith(".yaml")) {
            return yamlMapper.readValue(configFile, CentralDogmaConfig.class);        
        } else {
            return objectMapper.readValue(configFile, CentralDogmaConfig.class);
        }
    } catch (JsonParseException | JsonMappingException e) {
        throw e;
    } catch (IOException e) {
        throw new IOError(e);
    }
}

I also tried a simple PoC to see if it works:

@Test
void foo() throws JsonProcessingException {
    ObjectMapper jsonMapper = new ObjectMapper();
    ObjectMapper yamlMapper = new ObjectMapper(new YAMLFactory());
    final Foo foo = jsonMapper.readValue("{\"a\":\"foo\",\"bar\":{\"b\":\"c\"}}", Foo.class);
    System.err.println(foo);
    final Foo fooYaml = yamlMapper.readValue(
            "a: foo\n" +
            "bar:\n" +
            "  b: c", Foo.class);
    System.err.println(fooYaml);
}

public static class Foo {

    private final String a;
    private final Bar bar;

    @JsonCreator
    public Foo(@JsonProperty("a") String a, @JsonProperty("bar") Bar bar) {
        this.a = a;
        this.bar = bar;
    }

    @Override
    public String toString() {
        return MoreObjects.toStringHelper(this)
                          .add("a", a)
                          .add("bar", bar)
                          .toString();
    }
}

public static class Bar {

    private final String b;

    @JsonCreator
    public Bar(@JsonProperty("b") String b) {
        this.b = b;
    }

    @Override
    public String toString() {
        return MoreObjects.toStringHelper(this)
                          .add("b", b)
                          .toString();
    }
}

[flex-gyeongil]

Discussion Point 2.

configurable token authorizer and auth provider creator.

current implementation has strong coupling between json config file.

to resolve this coupling, I'd extract it

[flex-gyeongil]

In k8s, or container environment, certificates can injected by environment variable and spring boot can handle it as configuration properties

[minwoox]

ConfigValueConverter also supports that:

centraldogma/server/src/main/java/com/linecorp/centraldogma/server/DefaultConfigValueConverter.java

Lines 56 to 57 in 8ca35bf

	case ENV:
	return System.getenv(value);

But it's added recently so it might not be available when you started this implementation. 😓

[flex-gyeongil]

for... some kotlin stuff.

[flex-gyeongil]

Discussion point 3.

From some reason. Plugins have specification for duplication check in plugin group.

It seems weird to check duplication by plugin config class because for that check, some plugins which has no configurations returns itself.

Plugin config may be resuable, then duplication check key should be plugin class, not plugin config.

HDYT?

[minwoox]

That makes sense. 👍

[flex-gyeongil]

related with Discution point 3.

duplication check by plugin class count.

[jrhee17]

I haven't discussed this with the other maintainers, but let me leave my thoughts for now:

Due to hard coupling between configs and jackson deserialization, I wanna suggest to split configuration spec and it's implementation.

I'm neutral about this proposition.

I do think it's possible to add ways to create a CentralDogmaConfig (e.g. CentralDogmaConfig.fromYaml()).

Having said this, in terms of 1) keeping the config in-sync with the cloud-native module 2) deduplication I think the proposal makes sense

configurable token authorizer and auth provider creator.

Ideally, I think I prefer that the CentralDogma.java class provides ways to be configured and other applications cloud-native can consume this.

What do you think of exposing an SPI provider which is analogous to AuthProviderCreator, TokenAuthorizerCreator instead?

From some reason. Plugins have specification for duplication check in plugin group.

Sounds like a bug to me, but it's probably better to check with the original authors @minwoox @ikhoon

[jrhee17]

Question) Have you tried specifying java17? I think it could help avoid manually setting the supported minimum java version in gradle scripts

Suggested change

	includeWithFlags ':cloud-native:boot-loader', 'kotlin', 'spring-boot3'
	includeWithFlags ':cloud-native:boot-loader', 'java17', 'kotlin', 'spring-boot3'

[minwoox]

What do you think of exposing an SPI provider which is analogous to AuthProviderCreator, TokenAuthorizerCreator instead?

I like this approach. 👍