-
Notifications
You must be signed in to change notification settings - Fork 207
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
Fluxcd fixes #814
Conversation
There was a problem hiding this 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.
lib/addons/fluxcd/index.ts
Outdated
*/ | ||
version?: string; | ||
|
||
export interface FluxCDGitRepo { |
There was a problem hiding this comment.
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.
lib/addons/fluxcd/index.ts
Outdated
*/ | ||
version?: string; | ||
|
||
export interface FluxCDGitRepo { |
There was a problem hiding this comment.
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
lib/addons/fluxcd/index.ts
Outdated
@@ -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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor comments.
lib/addons/fluxcd/index.ts
Outdated
|
||
/** |
There was a problem hiding this comment.
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.
lib/addons/fluxcd/index.ts
Outdated
* Flux Kustomization Prune. | ||
* Default `true` */ | ||
fluxPrune?: boolean; | ||
/** |
There was a problem hiding this comment.
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.
Please @zjaco13 confirm the changes have been tested with https://github.com/aws-observability/cdk-aws-observability-accelerator/tree/main/lib/single-new-eks-opensource-observability-construct |
kustomizations?: FluxKustomizationProps[]; | ||
} | ||
|
||
export interface FluxKustomizationProps { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
lib/addons/fluxcd/index.ts
Outdated
/** | ||
* Options for a FluxCD repository | ||
*/ | ||
export interface FluxCDGitRepo extends Omit<spi.GitOpsApplicationDeployment, "repository">{ |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
lib/addons/fluxcd/gitrepository.ts
Outdated
@@ -6,23 +6,23 @@ import { setPath } from "../../utils"; | |||
*/ | |||
export class FluxGitRepository { | |||
|
|||
constructor(private readonly bootstrapRepo: spi.GitOpsApplicationDeployment) {} | |||
constructor(private readonly bootstrapRepo: spi.ApplicationRepository) {} |
There was a problem hiding this comment.
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?
lib/addons/fluxcd/gitrepository.ts
Outdated
|
||
public generate(namespace: string, fluxSyncInterval: string, fluxSecretRefName: string) { | ||
public generate(name: string, namespace: string, fluxSyncInterval: string, fluxSecretRefName: string) { | ||
|
||
const repository = this.bootstrapRepo!; |
There was a problem hiding this comment.
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; | ||
|
There was a problem hiding this comment.
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.
lib/addons/fluxcd/index.ts
Outdated
const manifest =fluxKustomization.generate( | ||
fluxcdGitRepo.name + "-" + index, | ||
fluxcdGitRepo.namespace ?? namespace, | ||
fluxcdGitRepo.fluxSyncInterval!, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
lib/addons/fluxcd/kustomization.ts
Outdated
|
||
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comment.
lib/addons/fluxcd/index.ts
Outdated
const manifest =fluxKustomization.generate( | ||
fluxcdGitRepo.name + "-" + index, | ||
fluxcdGitRepo.namespace ?? namespace, | ||
fluxcdGitRepo.fluxSyncInterval!, |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Region can be consistent.
@freschri can confirm it works |
There was a problem hiding this 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
05cb2b3
into
aws-quickstart:809-fluxcd-fails-to-deploy-multiple-kustomizations-following-pr-794
@zjaco13 Please PR to main |
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.