Spinnaker microservices can be configured to use SQL instead of Redis as the backing datastore. This issue serves as a place to track changes to be made to the SQL proto config as well as the respective Spinnaker microservices for SQL support.

SQL configuration is introduced to Kleat in #143 to enable it for Keel but it requires adding extra properties for it to work with other microservices.

If kleat generate is invoked with a dir an output dir that doesn't exist, you get the following error.

Error: stat ./generated: no such file or directory

Proposed solutions:

1. Notify the user that they need to create that directory
2. Make that directory for the user
3. Something else I didn't think of?

Which would you prefer in the PR?

Looks like the new securityContext introduced for a deck deployment here breaks it for me. I got the following error when trying to deploy deck and had to disable the security context for it to work. thoughts?

cp: cannot create regular file 'spinnaker.conf': Permission denied
sed: can't read spinnaker.conf: No such file or directory
sed: can't read spinnaker.conf: No such file or directory
sed: can't read spinnaker.conf: No such file or directory
mv: cannot stat 'spinnaker.conf': No such file or directory
ERROR: Site spinnaker does not exist!
Could not remove /etc/apache2/sites-enabled/000-default.conf: Permission denied
cp: cannot create regular file 'ports.conf': Permission denied
sed: can't read ports.conf: No such file or directory
sed: can't read ports.conf: No such file or directory
mv: cannot stat 'ports.conf': No such file or directory
cp: cannot create regular file 'passphrase': Permission denied
sed: can't read passphrase: No such file or directory
chmod: cannot access 'passphrase': No such file or directory
mv: cannot stat 'passphrase': No such file or directory
cp: cannot create regular file '/opt/deck/html/settings.js': Permission denied
chown: changing ownership of '/var/lock/apache2.g9wrlkWKEk': Operation not permitted```

What

When kleat generates Deck's setting.js, it is missing Kubernetes default configuration.

Which version

• kleat: 0.4.0
• Spinnaker: 1.20.8

How to reproduce

$ kleat generate <any_halconfig>
(see `settings.json`)

kleat will generate a file like this.

window.spinnakerSettings = JSON.parse('{"gateUrl":"https://spinnaker-api.something.domain.com","authEnabled":true,"authEndpoint":"https://spinnaker-api.something.domain.com/auth/user","bakeryDetailUrl":"https://spinnaker-api.something.domain.com/bakery/logs/{{context.region}}/{{context.status.resourceId}}","canary":{"defaultJudge":"NetflixACAJudge-v1.0","featureDisabled":false,"showAllConfigs":true,"templatesEnabled":true},"notifications":{"slack":{"enabled":false,"botName":"spinnakerbot","token":"${SLACK_TOKEN}"}},"providers":{"kubernetes":{}},"defaultTimeZone":"America/Los_Angeles","feature":{"pipelineTemplates":true,"chaosMonkey":false,"fiatEnabled":true,"managedPipelineTemplatesV2UI":true}}');

Here, the provider.kubernetes is {}. But it should be provider.kubernetes: {default:{}} to define the default property which the deck requires. If I apply the manifests generated by kleat, it will run into error in the deck.

Workaround

I'm currently configuring this manually is settings-local.json.

$ echo "window.spinnakerSettings.providers.kubernetes = { defaults: {} }" >> settings.json

When using the kleat + kustomize deployment path, traffic from gate gets sent to clouddriver-rw instead of clouddriver-ro-deck.

This is because there is no override in the gate config file; traffic just goes to the generic clouddriver service, which points to clouddriver-rw. We'll likely need to add an override in the gate config (or come up with a more generic solution).

I'm trying to set up basic auth for tools to interact with Gate without needing a heavier auth flow. Following the existing docs, I have

security:
  authn:
    enabled: true
    basic:
      enabled: true
      user:                                                                                   
        username: basic-user
        password: basic-password

Running the latest kleat generates a gate.yml file with the following:

security:                                                                                                                                     
  basic:                                                                                                                                      
    enabled: true                                                                                                                             
    user:                                                                                                                                     
      password: basic-user                                                                                                                 
      username: basic-password

However, Gate itself does not seem to accept this format; from the logs:

2021-09-29 18:24:54.449 ERROR 1 --- [           main] o.s.b.c.p.m.PropertiesMigrationListener  : 
The use of configuration keys that are no longer supported was found in the environment:

Property source 'applicationConfig: [file:/opt/spinnaker/config/gate.yml]':
        Key: security.basic.enabled
                Line: 3
                Reason: The security auto-configuration is no longer customizable.


Please refer to the migration guide or reference guide for potential alternatives.

From looking at Gate's test suite, it seems a basic auth setup might look more like

security.basicform.enabled=true
spring.security.user.name=basic-user
spring.security.user.password=basic-password

and it's possible this changed at 70024a3.

Am I correct in thinking that changes need to be made to kleat to support Gate's newer basic auth configuration format?

When Kleat generates the echo.yml file, it should additionally generate the field spinnaker.baseUrl which it might be okay to infer from security.uiSecurity.overrideBaseURL in the halconfig.

The result should be something like this in the head of echo.yml:

spinnaker:
  baseUrl: https://spinnaker.my.domain

For more context. Slack thread.

Thanks @nimakaviani and @kskewes for your help.

We're transforming to use kleat to deploy our spinnaker.
Currently, we configure trustStore and trustStorePassword for some of our jenkins masters.
ci: jenkins: enabled: true masters: - name: pc-cpc permissions: {} address: https://jenkins.url/ username: spinn-user password: xxxxxxxxxxxxxxxx csrf: false trustStore: /home/spinnaker/.hal/production/staging/dependencies/1176791443-EGADIssuingCA3.jks trustStorePassword: cxiSqS5NFxxxxxx

But there're no trustStore and trustStorePassword in the kleat config page. https://github.com/spinnaker/kleat/blob/master/docs/docs.md#proto.ci.JenkinsAccount

From here, to enable Fiat, need to configure a service discovery overrides file in the fork of spinnaker-config.

But I couldm't find a way to configure the overrides. Could someone please provide some help on this.

Keel is the microservice required to enable Managed Delivery for Spinnaker. As part of our efforts to make Managed Delivery available to the larger community, we would like to have Kleat generate the config file for Keel and also to add the required adjustments to the config files for other Spinnaker microservices.

Here is a PoC implementation: https://github.com/nimakaviani/kleat

The implementation introduces a feature flag --enable-keel that once set, makes the required config changes. From our discussions in the k8s sig meeting, @ezimanyi suggested we might be able to remove the feature flag and instead pre-populate the config files with acceptable defaults.

Any other changes to the above implementation that you see appropriate?

We can start working on the PR once we settle on the final design. thanks!

/cc @queueburt

Proposal

It would be better to use Git tag's versioning in kustomization-base for the users.

kustomize has already supported the use of Git refs so all we need to do is to create Git tags.

Related repositories

• spinnaker/kustomization-base

Background

kleat would work well with kustomization-base, though it's not necessary. So I guess many kleat's users would use the base kustomization.

Currently, the users need to specify bases in this way, in order to use kustomization-base:

bases:
- github.com/spinnaker/kustomization-base/core

This way might break the user's configurations because it always references master (or main) branch so the user's configurations will be affected if kustomization-base is broken.

With versioning like below:

bases:
- github.com/spinnaker/kustomization-base/core?ref=v1.2.3

It allows users to use the specific version with conviction, after examining if the version works with their configurations.

References

• kustomization.yaml · The Kubectl Book