linki / cloudformation-operator Goto Github PK

The template for the Cloudformation yaml is currently inline string and difficult to maintain. Can we allow template to be fetched from config map or an env variable please. This will allow separating the stack yaml with cloud formation. Thanks

It would be nice if this could generate/Manage a K8s configMap (or a k8s secret) with all the outputs
of the cloudFormation (instead of only keeping those in the "status" section)

This would permit to mount directly the config map to a deployment for example and help automatically "glue" things.

I know k8s doesn't support auto-"reloading" services that consumes a configMaps that has changed, but even knowing that, it's would still be a real nice feature...

Hi, can this be used to delete the stacks besides creating them? If so, can you please guide me? I couldn't find anything online nor in this repo.

That's how we create a stack and I would like to remove it when a speific condition is met.

&cloudformation.Stack{
		TypeMeta:   TypeMeta("cloudformation.linki.space/v1alpha1", "Stack"),
		ObjectMeta: i.objectMeta,
		Spec: cloudformation.StackSpec{
			Parameters: i.Parameters,
			Tags:       i.Tags,
			Template:   i.Template,
		},
	}

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/operator-framework/[email protected] requires
	vbom.ml/[email protected]: unrecognized import path "vbom.ml/util" (https fetch: Get https://vbom.ml/util?go-get=1: EOF)

View the update logs.

Hi,
Under helm/c-o/templates/deployment.yaml, the tolerations section should be under spec (currently it's under containers), pls kindly help fix.

Also, is it possible to open the permission so we could create branches and raise PR?

Cheers,

The operator-sdk has recently added the pass in flags feature via operator-framework/operator-sdk#264 on the master branch. Feel free to check that out.

There is a nice Cloudformation feature called "detect stack drifts" which allow us to see if the resources deployed by CF drifted from the CF definition's state (like if someone changed an s3 option by hand/cli).

How i see it working for this operator?

• We could have an option in the k8s stack resource that looks like:

  ensureNoDrift: true|false
  driftCheckFrequency: "24h"

A parallel "worker" would trigger CF drift checks on time.

• it would then queue in CF a "detect drift request" and poll for it's results.
• If a drift is detected, it would trigger an update of the CF using the previous definition (only if no other operation is already in progress updates or something else)

There's a work in progress in this fork 😄

Events from AWS especially when CF stack creation failed should be surfaced to the Stack CRD via events or something similar.

I can see the stack getting created,

But when i'm trying to access it in the AWS Console i don't see any available stacks.

And is it a personal project, or used in a professional context?

It looks nice, and trying to understand the level of effort that will be put there later on.
If I use it, I'll obviously help you then. (But it is not clear yet the direction we are taking in our company).

Basically, we need to provide RDS to our multitenant openshift cluster, and provide day 2 operation as well.

Thanks for your insight!

related to sorenmat/k8s-rds#44

When deploying to a Kubernetes cluster with RBAC enabled, the follow error occurs in the cloudformation-operator logs:

time="2018-03-27T06:36:28Z" level=fatal msg="stacks.cloudformation.linki.space is forbidden: User \"system:serviceaccount:default:default\" cannot list stacks .cloudformation.linki.space at the cluster scope"

Will send a pull request shortly to add an RBAC policy to the repo/readme.

Add some notes regarding similar projects:

• AWS's Service Operator
• Google's Config Connector