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

Fluxcd fixes #814

Conversation

zjaco13
Copy link
Contributor

@zjaco13 zjaco13 commented Aug 8, 2023

Issue #, if available:

Description of changes:
Added a new fluxcd repository object, and array of those objects to fluxcd props to allow for multiple repositories and multiple paths.

Changes are breaking changes

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Copy link
Collaborator

@shapirov103 shapirov103 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, refactoring makes sense and there should not be first/second class citizen between bootstrap and workload repos - that consistency improves the design.
However, I have a couple of comments on the specific design choices for the structure, please take a look.

*/
version?: string;

export interface FluxCDGitRepo {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should derive from GitopsApplicationDeployment and add fields that are flux specific.

*/
version?: string;

export interface FluxCDGitRepo {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is bootstrapRepository optional here? Does this structure make sense without bootstrap repo? See my other comment that it should really extend GitOpsApplicationDeployment

@@ -61,7 +39,7 @@ export interface FluxCDAddOnProps extends HelmAddOnUserProps {

/**
* Flux Kustomization Target Namespace.
* Note: when set, this parameter will override all the objects that are part of the Kustomization, please see https://fluxcd.io/flux/components/kustomize/kustomization/#target-namespace */
* Default `default` */
fluxTargetNamespace?: string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this namespace ever different for these apps? my assumption is that this is the namespace where the GitRepository CR will be created, please confirm. If my assumption is correct, this namespace is going to be the same for all of them.
If it is something else let's discuss.

Copy link
Contributor Author

@zjaco13 zjaco13 Aug 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The target namespace is where we want the kustomizations to be deployed. This can be specified per kustomization, whereas the gitrepositories are deployed in the same namespace that flux is deployed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name doesn't convey it, should be fixed, e.g. kustomizationNamespace or kustomizationTargetNamespace.
If there is a particular set of attributes specific to kustomizations then it would make more sense to have an interface for Kustomization with path, namespace, etc.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this namespace ever different for these apps? my assumption is that this is the namespace where the GitRepository CR will be created, please confirm. If my assumption is correct, this namespace is going to be the same for all of them. If it is something else let's discuss.

I think we might want NOT to make the assumption of a single namespace. E.g. in this case https://github.com/aws-observability/aws-observability-accelerator/blob/main/artifacts/grafana-operator-manifests/eks/infrastructure/amg_grafana-amp-datasource.yaml we use grafana-operator as a namespace, but we might want to add another path, with other manifests related to another operator and so likely another namespace.
I agree on the name. The parameter is finally going to be applied to https://fluxcd.io/flux/components/kustomize/kustomization/#target-namespace and like mentioned elsewhere, it should be optional, to avoid forcing override.

Copy link
Collaborator

@elamaran11 elamaran11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few minor comments.


/**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation issues and the comment is incomplete.

* Flux Kustomization Prune.
* Default `true` */
fluxPrune?: boolean;
/**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation issues and the comment is incomplete.

@freschri
Copy link
Collaborator

freschri commented Aug 9, 2023

kustomizations?: FluxKustomizationProps[];
}

export interface FluxKustomizationProps {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to move this interface and the repo interface to the related files?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I clearly remember replying to this, but my comment does not show up. We keep contracts together as customers will need all of them exported. so rather than creating dependencies between files, i suggest that we keep all contracts related to the addon either in the index or in a separate file called contracts.ts, types.ts and such.

/**
* Options for a FluxCD repository
*/
export interface FluxCDGitRepo extends Omit<spi.GitOpsApplicationDeployment, "repository">{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we probably need to review namings and make consistent choices, e.g. flux vs fluxcd. also do we want the flux prefix on kustomizations? then use everywhere... e.g. I see kustomizations and fluxKustomizationPath and fluxPrune in Kustomization props...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flux in the name of the interface is enough to remove the prefix from each field. The interfaces should be publicly exported, and if they are part of the addon contract, they should stay with the add-on.

@@ -6,23 +6,23 @@ import { setPath } from "../../utils";
*/
export class FluxGitRepository {

constructor(private readonly bootstrapRepo: spi.GitOpsApplicationDeployment) {}
constructor(private readonly bootstrapRepo: spi.ApplicationRepository) {}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe bootstrap in the name can be removed now?


public generate(namespace: string, fluxSyncInterval: string, fluxSecretRefName: string) {
public generate(name: string, namespace: string, fluxSyncInterval: string, fluxSecretRefName: string) {

const repository = this.bootstrapRepo!;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need the exclamation mark here? it is not an optional...

* Flux Kustomization Prune.
* Default `true` */
fluxPrune?: boolean;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there should be another interval property here for Kustomization. it is different than GitRepository.

const manifest =fluxKustomization.generate(
fluxcdGitRepo.name + "-" + index,
fluxcdGitRepo.namespace ?? namespace,
fluxcdGitRepo.fluxSyncInterval!,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to check we are using the kustomization interval and not the repo interval

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to this comment but generally speaking the intervals are coded the same across GitRepository and Kustomization


public generate(name: string, namespace: string, fluxSyncInterval: string, fluxPrune: boolean, fluxTimeout: string, bootstrapValues: spi.Values, fluxKustomizationPath: string, fluxTargetNamespace?: string) {
public generate(name: string, namespace: string, fluxSyncInterval: string, fluxPrune: boolean, fluxTimeout: string, bootstrapValues: spi.Values, fluxKustomizationPath: string, fluxTargetNamespace?: string) {
Copy link
Collaborator

@freschri freschri Aug 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should aim for a generate() without params, all should be already in self.
also, would it be a better naming generateManifest?
same considerations for gitrepository

Copy link
Collaborator

@elamaran11 elamaran11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comment.

const manifest =fluxKustomization.generate(
fluxcdGitRepo.name + "-" + index,
fluxcdGitRepo.namespace ?? namespace,
fluxcdGitRepo.fluxSyncInterval!,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to this comment but generally speaking the intervals are coded the same across GitRepository and Kustomization

targetRevision: "master",
},
values: {
"region": "us-east-2"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Region can be consistent.

@zjaco13
Copy link
Contributor Author

zjaco13 commented Aug 9, 2023

Copy link
Collaborator

@shapirov103 shapirov103 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, we will need a PR to the main branch

@elamaran11 elamaran11 merged commit 05cb2b3 into aws-quickstart:809-fluxcd-fails-to-deploy-multiple-kustomizations-following-pr-794 Aug 10, 2023
@elamaran11
Copy link
Collaborator

@zjaco13 Please PR to main

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.

4 participants