Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cna] schema for CNA external resources #355

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

geoberle
Copy link
Contributor

@geoberle geoberle commented Dec 9, 2022

this schema change introduces the external-resources extension for CNA

it covers the following modules

  • null - for simple testing purposes without any prereqs on AWS accounts or clusters etc.
  • aws-assume-role - for testing AWS assume-role access by CNA
  • aws-rds - create an AWS RDS database

cna-experimental services as the provider, indicating the experimental nature of the integration and the CNAExperimentalProvisioner_v1 serves as the provisioner, wrapping an OCM organization and potentially adding additional config data (we will add a API URL override to this soon so we can target CNA API instances living outside of api.openshift.com)

Provisioner

$schema: /cna/experimental-provisioner-1.yml

name: app-sre
description: CNA provisioner for the app-sre OCM organization

ocm:
  $ref: /dependencies/ocm/stage.yml

<<<--- potential additional config options go here

Example RDS

The defaults files for CNA are now datafile schemas as well. As such they enable us to use references, e.g. a VPC

Here is the example of a defaults file for a production DB

$schema: /cna/aws-rds-config-1.yml
engine: postgres
username: postgres
engine_version: '14.2'
instance_class: db.m6.large
backup_retention_period: 7
db_subnet_group_name: default
allocated_storage: 200
max_allocated_storage: 1000
multi_az: true
vpc:
  $ref: /aws/some-account/vpcs/default-vpc.yml

and the external resource declaration that leverages it

$schema: /openshift/namespace-1.yml
...
externalResources:
- provider: cna-experimental
  provisioner:
    $ref: /cna/app-sre.yml
  resources:
  - provider: aws-rds
    identifier: my-db
    defaults:
      $ref: the-defaults-file.yml
    overrides:
      backup_retention_period: 14

design doc: https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/53097
ref: https://issues.redhat.com/browse/APPSRE-6295

geoberle and others added 8 commits December 20, 2022 14:16
temporarily add support for the `example-aws-assumerole` CNA type.

```
  - provider: aws-assume-role
    identifier: test
    aws_assume_role:
      slug: test
      account:
        $ref: /aws/some-acc/account.yml
```

the role ARNs this and other kinds require, are stored in the `/aws/account-1.yml` schema. a default role ARN can be defined but module specific ones are supported as well. while we iterate we might drop support for the defaultRoleARN or revamp the way of providing module/context specific default parameters

```
---
$schema: /aws/account-1.yml

cna:
  defaultRoleARN: arn:aws:iam::xxx:role/RH-CNA
  moduleRoleARNS:
  - module: aws-rds
     arn: arn:aws:iam::xxx:role/RH-CNA-RDS
```

Signed-off-by: Gerd Oberlechner <[email protected]>
* CNA aws-rds provider

```
  - provider: aws-rds
    identifier: cna-test-rds
    vpc:
      $ref: /aws/acc/vpcs/vpc.yml
    default: /path/to/default.yml
    override:
      db_subnet_group_name: default
```

Signed-off-by: Gerd Oberlechner <[email protected]>
* override and default schema represented by same schema objects

all CNA assets must have a `defaults` and an `overrides` section, as a lot of the terraform-resources do.
the difference is, that each CNA type declares a special `XXXConfig_v1` type that is used for both fields.

```yaml
  name: CNARDSInstance_v1
  interface: CNAsset_v1
  fields:
  - { name: provider, type: string, isRequired: true }
  - { name: identifier, type: string, isRequired: true, isUnique: true }
  - { name: name, type: string }
  - { name: defaults, type: CNARDSInstanceConfig_v1 } <--
  - { name: overrides, type: CNARDSInstanceConfig_v1 } <--
```

having defaults following a strict schema and overrides being able to override all of the defaults, makes writing testable and verifiable code a lot easier.
revert experiment where overrides and defaults are exactly the same schema. the result was that all fields in overrides and defaults needed to be optional so they can be used in both places without making overrides mandatory.

in this PR, overrides are now all optional, follow a schema in jsonschema but none in GQL where they are just JSON
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants