How to model dependencies

[benkeil]

I have 2 CRDs, AwsAccount and GitHubRepository.

The GitHubRepository controller must do something for every AwsAccount that it is related to it via a label called team. (that's the easy part)

But when a team gets a new AwsAccount, the GitHubRepository controller must do something for this new account.

let github_repository_api = Api::<GitHubRepository>::all(client.clone());
let aws_account_api = Api::<AwsAccount>::all(client.clone());
let (account_store, writer) = reflector::store();
let account_stream = watcher(aws_account_api, Config::default())
    .default_backoff()
    .reflect(writer)
    .touched_objects()
    .map_ok(|a| {
        ObjectRef::new(a.name_any().as_str()).within(a.metadata.namespace.as_ref().unwrap())
    });

Controller::new(github_repository_api.clone(), Config::default())
    .reconcile_on(account_stream)
    .shutdown_on_signal()
    .run(
        reconcile,
        error_policy,
        Arc::new(Context {
            client: client.clone(),
            account_store,
        }),
    )

I thought the reconcile_on is just a trigger, but it sends a AwsAccount object ref.

What is the recommended way to do this? Can I make a query inside the map_ok function to get a list of related GitHubRepositorys? Or do I need 2 separate GitHubRepository controllers?

[clux]

This sounds like a watches relation. You should end up with something like:

Controller::new(github_repository_api, cfg)
    .watches_stream(account_stream, mapper)

where mapper is a fn that goes from an AwsAccount to an objectref for the GitHubRepository (looks like you kind of have the mapper inside the map_ok, but then you're not calling .watches on the controller). and the account_stream is a flattened stream (after touched_objects) but without the map_ok part. See https://docs.rs/kube/latest/kube/runtime/struct.Controller.html?search=watches#method.watches and the watches_stream docs.

[benkeil]

Maybe I tell more about the use case.

Teams have x AWS accounts and y GitHub repositories. Every time a team create a new repository, OIDC must be configured for all team accounts. If a team creates a new account, for all team repositories OIDC must be configured.

I came up with:

Controller::new(github_repository_api.clone(), Config::default())
    .watches_stream(
        account_stream,
        map_aws_account_to_github_repositories(github_repository_api.clone()),
    )

async fn query(api: Api<GitHubRepository>, aws_account: AwsAccount) -> Vec<GitHubRepository> {
    let labels = format!("team={}", aws_account.labels().get("team").unwrap());
    let list_params = ListParams::default().labels(&labels);
    api.list(&list_params).await.unwrap().items
}

fn map_aws_account_to_github_repositories(
    api: Api<GitHubRepository>,
) -> impl Fn(AwsAccount) -> Vec<ObjectRef<GitHubRepository>> {
    move |aws_account| {
        futures::executor::block_on(async { query(api.clone(), aws_account.clone()).await })
            .iter()
            .map(|repository| ObjectRef::from_obj(repository))
            .collect::<Vec<_>>()
    }
}

But I think my concept is wrong.

• Now I can't specify an order (repositories must be deleted before accounts, but created after accounts)
• Delete account events does not lead to a Delete repository events.

[clux]

i guess your label use is not precise and so you are looking for more semi-related objects than a normal watches setup with a precise objectref embedded.

repositories must be deleted before accounts

if the repositories have a ref to all the aws accounts then you could put a finalizer on the github repo so that your controller can clean up the accounts.

but if you need to create a githubrepo as a result of an account creation it sounds like you might want a controller on awsaccount as well and you are kind of mudding the waters of what owns what.
i would ideally model this based on what is created first (as the core object), and what is incidentally created (as the watched), but if you don't have that (and the user can technically create both out-of-band) then you probably need two controllers.

Delete account events does not lead to a Delete repository events

it is possible to could store the last_managed_accounts or something like that on the status object of your githubrepo, then you could diff that with what's in the world by querying for aws accounts with your label whenever you get a githubrepo reconcile request.