profile
viewpoint
Alena Varkockova alenkacz Prague http://twitter.com/alenkacz developer, traveller, foodie

alenkacz/gradle-scalafmt 18

Gradle plugin for scalafmt

alenkacz/gradle-json-validator 9

Gradle plugin for json validation

alenkacz/gradle-marathon-deployer 8

Gradle plugin that can deploy your application to Marathon (https://mesosphere.github.io/marathon/)

alenkacz/ci-signal-report 7

generating report for CI signal release team

alenkacz/Expanze 3

XNA game

alenkacz/Colorific 2

HTML5 game

alenkacz/Bookfan 1

Bookfan Android client

alenkacz/akka 0

Build highly concurrent, distributed, and resilient message-driven applications on the JVM

alenkacz/blozinek.cz 0

Github pages for blozinek.cz

alenkacz/bookshelf 0

Distribuovaná knižnica priateľov Rubyslavy

PR opened kubernetes-sigs/controller-runtime

✨ (:sparkles, minor) Make it possible to monitor readiness for webhook

<!-- please add a icon to the title of this PR (see VERSIONING.md), and delete this line and similar ones --> <!-- the icon will be either ⚠ (:warning:, major), ✨ (:sparkles, minor), 🐛 (:bug:, patch), 📖 (:book:, docs), or 🌱 (:seedling:, other) -->

<!-- What does this do, and why do we need it? -->

This is a very minimal implementation of #723

With this in place, one can define a readiness check for webhook like this:

err = mgr.AddReadyzCheck("ready", func(_ *http.Request) error {
		if mgr.GetWebhookServer().Started {
			return nil
		}
		return errors.New("Webhook server not yet started")
	})

there's still a possibility for a very small race because technically all the paths for webhook are bound when srv.Serve is done. But the possibility of hitting it is very small considering that the readiness check has to pick it up, return ready and someone has to make a request over network to that webhook - that will be definitely slower than the processing inside srv.Serve.

If anyone has better idea, I am all ears.

+3 -0

0 comment

1 changed file

pr created time in 4 days

create barnchalenkacz/controller-runtime

branch : av/webhook-readiness-prepare

created branch time in 4 days

pull request commentkudobuilder/kudo

Health module should also use pod conditions

I'll investigate the failures tomorrow

alenkacz

comment created time in 7 days

PR opened kudobuilder/kudo

Reviewers
Health module should also use pod conditions

Signed-off-by: Alena Varkockova varkockova.a@gmail.com

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Not only --wait, also the health module should read the ready property, not phase == running.

See https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ for more context.

+6 -22

0 comment

2 changed files

pr created time in 7 days

create barnchkudobuilder/kudo

branch : av/health-ready-pod

created branch time in 7 days

Pull request review commentkudobuilder/kudo

Add --output parameter to plan status to allow json/yaml output

 func Status(options *Options, settings *env.Settings) error { 	return status(kc, options, settings.Namespace) } +func statusFormatted(kc *kudo.Client, options *Options, ns string) error {+	instance, err := kc.GetInstance(options.Instance, ns)+	if err != nil {+		return err+	}+	if instance == nil {+		return fmt.Errorf("instance %s/%s does not exist", ns, options.Instance)+	}++	var o []byte+	if strings.ToLower(options.Output) == "yaml" {+		o, err = yaml.Marshal(instance.Status)

shouldn't we aim for something more user friendly then just serialized CRD status? 🤔

ANeumann82

comment created time in 7 days

Pull request review commentkudobuilder/kudo

Wait until the manager is actually gone before continuing the upgrade

 func UninstallStatefulSet(client *kube.Client, options kudoinit.Options) error { 		PropagationPolicy: &fg, 	}) 	if err != nil {-		if !kerrors.IsNotFound(err) {-			return fmt.Errorf("failed to uninstall KUDO manager %s/%s: %v", options.Namespace, kudoinit.DefaultManagerName, err)+		if kerrors.IsNotFound(err) {+			// Stateful set was already delete, we can return

deleted

ANeumann82

comment created time in 7 days

Pull request review commentkudobuilder/kudo

Simplify waiting for the instance to be done

 func Package( 		return nil 	} -	if err := install.Instance(client, resources.Instance); err != nil {+	installed, err := install.Instance(client, resources.Instance)

hmm why is this better than what was here before? 🤔

zen-dog

comment created time in 7 days

Pull request review commentkudobuilder/kudo

Simplify waiting for the instance to be done

 func status(kc *kudo.Client, options *Options, ns string) error { 		} else { 			break 		}-		done, err := kc.IsInstanceDone(instance, nil)+		done, err := kc.IsInstanceDone(instance, instance.Spec.PlanExecution.PlanName)

why are you passing in instance as well as field on that instance? 🤔 should we just pass in an instance?

zen-dog

comment created time in 7 days

issue openedkudobuilder/kudo

Kudo init --upgrade should wait on deletion before proceeding with upgrade

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: Currently, when uninstalling stuff as a first step of upgrade, we use foreground delete propagation https://github.com/kudobuilder/kudo/blob/5c68af2007d6e165d3a9627f12aa9584dc16782c/pkg/kudoctl/kudoinit/manager/manager.go#L73 and we falsely assumed that's blocking until it gets deleted which is not true. API server returns response when object is marked to be deleted but then it could take a substantial amount of time until object gets deleted (depending on the finalizers).

When deleting something as part of upgrade, we should always "block" and wait until really deleted (probably with some timeout) and not proceed with upgrade until that's done.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
  • Kudo version (use kubectl kudo version):
  • Operator:
  • operatorVersion:
  • Cloud provider or hardware configuration:
  • OS (e.g. from /etc/os-release):
  • Kernel (e.g. uname -a):
  • Install tools:
  • Others:

created time in 7 days

issue openedkudobuilder/kudo

Panic while running `kudo init --upgrade`

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./bin/kubectl-kudo init --upgrade --version 0.15.0
$KUDO_HOME has been configured at /Users/alenavarkockova/.kudo
Verify that 0 required migrations can be applied
Upgrade KUDO
Run 0 migrations
✅ installed crds
✅ installed namespace
✅ installed service account
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x189198c]

goroutine 1 [running]:
k8s.io/apimachinery/pkg/apis/meta/v1/unstructured.(*Unstructured).GetAPIVersion(...)
	/Users/alenavarkockova/go/pkg/mod/k8s.io/apimachinery@v0.18.6/pkg/apis/meta/v1/unstructured/unstructured.go:218
k8s.io/apimachinery/pkg/apis/meta/v1/unstructured.(*Unstructured).GroupVersionKind(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/Users/alenavarkockova/go/pkg/mod/k8s.io/apimachinery@v0.18.6/pkg/apis/meta/v1/unstructured/unstructured.go:426 +0x6c
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.installUnstructured(0x2925220, 0xc0006a2960, 0x0, 0xc000000180, 0x200000003)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:340 +0x43
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.(*KudoWebHook).installWithCertManager(0xc000648140, 0xc00036ab10, 0x1, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:125 +0x64
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.(*KudoWebHook).Install(0xc000648140, 0xc00036ab10, 0xc0009cfa80, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:158 +0x6c
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup.(*Installer).Install(0xc0006e1080, 0xc00036ab10, 0xc0009cfb40, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup/setup.go:143 +0x92
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup.(*Installer).Upgrade(0xc0006e1080, 0xc00036ab10, 0x0, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup/setup.go:118 +0x292
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.(*initCmd).runUpgrade(0xc00034c0d0, 0xc0006e1080, 0xc00036ab10, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:262 +0xcb
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.(*initCmd).run(0xc00034c0d0, 0x26989dc, 0x9)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:207 +0x1e3
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.newInitCmd.func1(0xc0000fcb00, 0xc00036b980, 0x0, 0x3, 0x0, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:104 +0x128
github.com/spf13/cobra.(*Command).execute(0xc0000fcb00, 0xc00036b950, 0x3, 0x3, 0xc0000fcb00, 0xc00036b950)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:842 +0x453
github.com/spf13/cobra.(*Command).ExecuteC(0xc0000fc580, 0x0, 0x0, 0xc0000ae058)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950 +0x349
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
main.main()
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/cmd/kubectl-kudo/main.go:24 +0x27

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
  • Kudo version (use kubectl kudo version):
  • Operator:
  • operatorVersion:
  • Cloud provider or hardware configuration:
  • OS (e.g. from /etc/os-release):
  • Kernel (e.g. uname -a):
  • Install tools:
  • Others:

created time in 7 days

issue commentkudobuilder/kudo

Add Controller and Webhook Ready Kube Event

I think the container ready and webhook ready is captured in "pod phases" so it's already exposed by kubernetes. I don't see much value in duplicating those into events as one already has this information on every kubernetes cluster.

I would personally be inclined to close this.

kensipe

comment created time in 7 days

IssuesEvent

issue closedkudobuilder/kudo

Upgrade (init) to Capture Verify Readiness of the Correct StatefulSet

Previous to https://github.com/kudobuilder/kudo/pull/1629 there was a check to verify image name when looking for kudo readiness. As well commented on the PR: https://github.com/kudobuilder/kudo/pull/1629#discussion_r465482145 We need to make sure that upgrades are managed correctly. Part of that is making sure we are looking at the status on the right object.

As pointed out as a response to the comment, we likely need to either:

  1. wait for deletes to complete before install or
  2. capture any statefulset prior to init and work with revision changes to ensure that we are capturing the progress on the correct statefulset.

closed time in 7 days

kensipe

Pull request review commentkudobuilder/kudo

Introduce readiness check and proper wait in `init --wait`

 spec:         - containerPort: 443           name: webhook-server           protocol: TCP+        readinessProbe:

we did but I removed it again so we're 1.15 :)

alenkacz

comment created time in 7 days

issue closedkudobuilder/kudo

Looks like `--wait` on `kudo init` does not wait for webhook to be ready

What happened:

Our tests run kudo init --wait and `kudo install in quick succession, which fails due to webhook not being ready.

      kuttl: logger.go:42: 13:10:24 |  | running command: [kubectl kudo init --wait]
      kuttl: logger.go:42: 13:10:24 |  | $KUDO_HOME has been configured at /root/.kudo
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed crds
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed namespace
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed service account
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed webhook
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed kudo controller
      kuttl: logger.go:42: 13:10:24 |  | ⌛Waiting for KUDO controller to be ready in your cluster...
      kuttl: logger.go:42: 13:10:31 |  | running command: [kubectl kudo install /.../blah --instance blah-instance --namespace blah ... --wait --wait-time 750]
      kuttl: logger.go:42: 13:10:31 |  | operator blah/blah created
      kuttl: logger.go:42: 13:10:31 |  | operatorversion blah/blah-0.3.1 created
      kuttl: logger.go:42: 13:10:31 |  | Error: failed to install instance blah/blah-instance: installing Instance: Internal error occurred: failed calling webhook "instance-admission.kudo.dev": Post https://kudo-controller-manager-service.kudo-system.svc:443/admit-kudo-dev-v1beta1-instance?timeout=30s: dial tcp 10.0.11.58:443: connect: connection refused

What you expected to happen:

The former command should only return once KUDO is fully ready for action.

How to reproduce it (as minimally and precisely as possible):

See above.

Anything else we need to know?:

https://kubernetes.slack.com/archives/CG3HTFCMV/p1596122874213100

Environment:

  • Kudo version (use kubectl kudo version): 0.15.0

closed time in 7 days

porridge

issue commentkudobuilder/kudo

Looks like `--wait` on `kudo init` does not wait for webhook to be ready

this was fixed by #1629

porridge

comment created time in 7 days

push eventkudobuilder/kudo

Marcin Owsiany

commit sha 0f5c2df43ef5cc2b5c769380580c68ec6a6a584d

Fix implicit list for package create. (#1630)

view details

push time in 7 days

delete branch kudobuilder/kudo

delete branch : porridge/operatorversion

delete time in 7 days

PR merged kudobuilder/kudo

Reviewers
Add a missing implicit.

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it:

The allowlist in verifier got out of sync with reality and package create rejects an otherwise valid package.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #

+12 -14

0 comment

2 changed files

porridge

pr closed time in 7 days

Pull request review commentkudobuilder/kudo

Introduce readiness check and proper wait in `init --wait`

 spec:         - containerPort: 443           name: webhook-server           protocol: TCP+        readinessProbe:

yeah, the startup probe is 1.16+

alenkacz

comment created time in 8 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha e811dadc6811f6f53d6b0783931364f611613c2b

Introduce a TCP readineess check Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 9 days

PR opened kudobuilder/kudo

Reviewers
Introduce a TCP startup check

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This is part of the solution for #1625

I ended up using startup probe instead of readiness because that's run only when manager starts, we don't need to poll the endpoint when manager is running.

+7 -0

0 comment

1 changed file

pr created time in 9 days

create barnchkudobuilder/kudo

branch : av/readiness-tcp

created branch time in 9 days

issue commentkudobuilder/kudo

Looks like `--wait` on `kudo init` does not wait for webhook to be ready

so the solution I am leaning to here is:

  • introduce a startup check waiting for webhook port to be bound
  • change the --wait behavior so that it reads for pod phase 'ready'
porridge

comment created time in 9 days

issue commentkubernetes-sigs/controller-runtime

Add default readiness check for webhook server?

@ncdc are you still working on this? I've just spent many hours trying to figure out a nice way how to create such readiness check from outside that I am starting to think it would be easier to implement it within controller-runtime

ncdc

comment created time in 9 days

create barnchkudobuilder/kudo

branch : av/add-readiness-check

created branch time in 9 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha f2c620d7cb85b484e78acda82ae372c82b960e98

Add e2e test for apply-delete-apply bug (#1623)

view details

push time in 10 days

delete branch kudobuilder/kudo

delete branch : av/delete-apply-delete-test

delete time in 10 days

PR merged kudobuilder/kudo

Reviewers
Add e2e test for apply-delete-apply bug

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This covers regression in #1596

It had to be e2e because in integration, the deletion actually never happens because the GC controller is not running.

+79 -0

1 comment

5 changed files

alenkacz

pr closed time in 10 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha fe0f581034effff907805783025c644dd84031bc

Merge two steps Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 10 days

startedomrikiei/ktunnel

started time in 11 days

issue commentkudobuilder/kudo

Add Controller and Webhook Ready Kube Event

@kensipe what's the use case, just wondering? why using k8s built in readiness + pod states are not enough?

I think the correct solution is to add readiness/liveness check and then correctly assert --wait on phase == ready not pod running as it's doing right now (incorrectly).

kensipe

comment created time in 13 days

issue openedkudobuilder/kudo

Better checks in kudo init for namespaces

<!-- Please only use this template for submitting enhancement requests. Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/main/keps/0001-kep-process.md -->

What would you like to be added:

kudo git:(av/delete-apply-delete-test) ✗ ./bin/kubectl-kudo init --version 0.15.0
$KUDO_HOME has been configured at /Users/alenavarkockova/.kudo
:white_check_mark: installed crds
:white_check_mark: installed namespace
Error: error installing: service account: serviceaccounts "kudo-manager" is forbidden: unable to create new content in namespace kudo-system because it is being terminated

This should ideally fail pre-install and not end up being partial install that one needs to manually clean up.

Why is this needed:

created time in 13 days

issue commentkudobuilder/kudo

KUDO init --dry-run Should Succeed Regardless of Cluster has CRDs or Not

this really bugs me a lot, I am used to being able to get the yaml out of the CLI and hitting this all the time :(

./bin/kubectl-kudo init --version 0.15.0 -o yaml --dry-run
Errors
CRD operators.kudo.dev is already installed. Did you mean to use --upgrade?
Error: failed to verify installation requirements
kensipe

comment created time in 13 days

pull request commentkudobuilder/kudo

Add e2e test for apply-delete-apply bug

@nfnt oh right, there could be multiple resources in an assert, correct? Yeah, let's change that

alenkacz

comment created time in 13 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha d5ca5d0427361c746eb09b1b484f6fa153ab1e45

Move this to e2e test Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 15 days

issue openedkudobuilder/kudo

Improve experience of local integration test run

<!-- Please only use this template for submitting enhancement requests. Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/main/keps/0001-kep-process.md -->

What would you like to be added: Integration tests currently run following command:

commands:
  - command: |-
      sh -c '
      KUDO_CERT_DIR="./test/cert" ./bin/manager
      '
    background: true
  - command: sleep 5

If this command fails, e.g. because of Unable to run the manager: listen tcp :443: bind: permission denied the test suite is still run and this error is burried somewhere.

Two enhancements from this:

  • do not use sleep and introduce a proper wait on manager being up
  • change the port from 443 to something an unprivileged used can bind to

Why is this needed:

created time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha f78cf0d93d5a8727df79dade30a7016aaaa87277

Wait for resource being deleted, retry reconciliation (#1621) Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

Alena Varkockova

commit sha 84cc1da1150720e1f6bcfbac7726f0aff28e4c54

Merge branch 'main' into av/delete-apply-delete-test Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha f78cf0d93d5a8727df79dade30a7016aaaa87277

Wait for resource being deleted, retry reconciliation (#1621) Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

delete branch kudobuilder/kudo

delete branch : av/no-change-lastupdate

delete time in 16 days

PR merged kudobuilder/kudo

Reviewers
Wait for resource being deleted, retry reconciliation

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This fixes a bug when a sequence of apply-delete-apply meant that the resource did not exist in the end because we did not wait for item to be deleted out of the cache of the client we're using. Details are in #1596

The solution introduces "health check" for deletion which queries client until it's deleted. Instead of poll & wait and blocking the worker thread we're relying on reconciliation loop being re-trigerred. We now reschedule reconciliation when plan is running to prevent stalling. A simple backoff mechanism implemented as well.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #1596

+117 -7

1 comment

5 changed files

alenkacz

pr closed time in 16 days

issue closedkudobuilder/kudo

ConfigMap not being re-apply with simple plan

What happened: I have a plan where I want to reapply a pod and it’s configmaps, My steps are:

  1. Delete a Pod
  2. Delete a ConfigMap
  3. Apply a ConfigMap
  4. Apply the Pod The problem is that step 3 doesn’t reapply my ConfigMap, so then step 4 never runs but yet my operator plan reports a full COMPLETED steps and plan. All phases and steps in my plan are set to serial.

What you expected to happen: Step 3 above to reapply my ConfigMap

How to reproduce it (as minimally and precisely as possible): Create two tasks for a Pod and ConfigMap, one to Apply and one to Delete the same Kube manifest.

Then a plan like this:

  redeploy-connectors:
    strategy: serial
    phases:
    - name: connectors-stop
      strategy: serial
      steps:
      - name: stop-connectors
        tasks:
        - connectors-stop
      - name: delete-bootsrap
        tasks:
        - connectors-bootstrap-delete
    - name: connectors-redeploy
      strategy: serial
      steps:
      - name: redeploy-connector-configmaps
        tasks:
        - connectors-bootstrap
      - name: restart-connectors
        tasks:
        - connectors-start

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version): Client v1.17.0, Server v1.18.3
  • Kudo version (use kubectl kudo version): 0.15.0
  • Operator: Custom
  • Cloud provider or hardware configuration: minikube running in VirtualBox on Mac

closed time in 16 days

dboyleitrs

Pull request review commentkudobuilder/kudo

Wait for resource being deleted, retry reconciliation

 func (r *Reconciler) Reconcile(request ctrl.Request) (ctrl.Result, error) { 		r.Recorder.Event(instance, "Normal", "PlanFinished", fmt.Sprintf("Execution of plan %s finished with status %s", newStatus.Name, newStatus.Status)) 	} -	return reconcile.Result{}, nil+	return computeTheReconcileResult(instance, time.Now), nil+}++// computeTheReconcileResult decides whether retry reconciliation or not+// if plan was finished, reconciliation is not retried+// for others it uses LastUpdatedTimestamp of a current plan+// for plan updated less than a minute ago, the backoff would be a second, 10 minutes would be 10 seconds

I tried to clarify, let me know if it's better

alenkacz

comment created time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha 49790f59a44b475a4f014751c8a678d11bd3fa5f

Wait for resource being deleted, retry reconciliation Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha 66d369ab52d6399bbb2125750ae0bf3ec4180722

Add integration test for apply-delete-apply bug Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha 28421a0a7599d94f2c8a26b9eccaa7a97045f7e6

Add integration test for apply-delete-apply bug Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha d035c1fc2f3315dc8d43853339a9c40329f45798

Add integration test for apply-delete-apply bug Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 16 days

PR opened kudobuilder/kudo

Reviewers
Add integration test for apply-delete-apply bug

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This covers regression in #1596

+78 -0

0 comment

6 changed files

pr created time in 16 days

create barnchkudobuilder/kudo

branch : av/delete-apply-delete-test

created branch time in 16 days

pull request commentkudobuilder/kudo

Update the default community repository URL

@nfnt so what is the plan for older CLIs? Will the old repo still be updated for a while? Or are we pretty much decommissioning it?

nfnt

comment created time in 16 days

pull request commentkudobuilder/kudo

Wait for resource being deleted, retry reconciliation

@nfnt oh yeah, integration test covering the regression is definitely a good idea. I'll work on that!

alenkacz

comment created time in 17 days

delete branch kudobuilder/kudo

delete branch : ken/fix-clean

delete time in 20 days

push eventkudobuilder/kudo

Ken Sipe

commit sha 4ada4e2f365063433c0efbcf39489001b3f6477e

deploy-clean should not be part of clean (#1620) Signed-off-by: Ken Sipe <kensipe@gmail.com>

view details

push time in 20 days

PR merged kudobuilder/kudo

Reviewers
deploy-clean should not be part of clean

deploy-clean is broken now. I hesitate to remove it but it has been broken for some time which signals that it isn't used. IF we want it than... what is recommended to add for the controller version?

Regardless... deploy-clean should NOT be apart of clean IMO.

Signed-off-by: Ken Sipe kensipe@gmail.com

+1 -5

0 comment

1 changed file

kensipe

pr closed time in 20 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha d224c788aa91d561874610332feacdca2151e01a

Wait for resource being deleted, retry reconciliation Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 20 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha f149fc677440492d8ff11972b2109fb612a8711a

Wait for resource being deleted, retry reconciliation Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 20 days

PR opened kudobuilder/kudo

Reviewers
Wait for resource being deleted, retry reconciliation

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This fixes a bug when a sequence of apply-delete-apply meant that the resource did not exist in the end because we did not wait for item to be deleted out of the cache of the client we're using. Details are in #1596

The solution introduces "health check" for deletion which queries client until it's deleted. Instead of poll & wait and blocking the worker thread we're relying on reconciliation loop being re-trigerred. We now reschedule reconciliation when plan is running to prevent stalling. A simple backoff mechanism implemented as well.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #1596

+117 -7

0 comment

5 changed files

pr created time in 21 days

create barnchkudobuilder/kudo

branch : av/no-change-lastupdate

created branch time in 21 days

startedfluxcd/helm-controller

started time in 21 days

Pull request review commentkudobuilder/operators

Fix package verification

 parameters:   - name: DISK_SIZE     description: "Disk size for the RabbitMQ servers"     default: "1Gi"-    trigger: "not-allowed"

oh I see, so I think the proper fix then is to create a plan with this task https://github.com/kudobuilder/operators/pull/283/files#diff-03f33d8320fe5aa10c3409ce4fc7189bL37

nfnt

comment created time in 21 days

Pull request review commentkudobuilder/operators

Fix package verification

 parameters:   - name: DISK_SIZE     description: "Disk size for the RabbitMQ servers"     default: "1Gi"-    trigger: "not-allowed"

how come you can drop this? 🤔

nfnt

comment created time in 21 days

create barnchkudobuilder/kudo

branch : av/stable-last-update

created branch time in 22 days

Pull request review commentkudobuilder/kudo

Chore: Update third-party dependencies to their latest releases

 func TestGetResources(t *testing.T) { 		t.Run(tt.name, func(t *testing.T) { 			dc := newDependencyCalculator(tt.client, tt.taskObjects) 			obj, err := dc.resourceDependency(resourceDependency{gvk: typeConfigMap, name: "configmap", namespace: "namespace"})-			assert.NilError(t, err, "resourceDependency return error")+			assert.NoError(t, err, "resourceDependency return error") 			cmResult := &corev1.ConfigMap{} 			_ = runtime.DefaultUnstructuredConverter.FromUnstructured(obj.UnstructuredContent(), cmResult)-			assert.DeepEqual(t, cm.Data, cmResult.Data)+			assert.Equal(t, cm.Data, cmResult.Data)

is Equal and DeepEqual the same thing?

nfnt

comment created time in 22 days

Pull request review commentkudobuilder/kudo

Chore: Update third-party dependencies to their latest releases

 linters-settings:   dupl:     threshold: 400   goimports:-    # Don't use 'github.com/kudobuilder/kudo', it'll result in unreliable output!-    local-prefixes: github.com/kudobuilder+    local-prefixes: github.com/kudobuilder/kudo

what changed here? that we can do it now...

nfnt

comment created time in 22 days

push eventkudobuilder/kudo

Alena Varkockova

commit sha 9666e0158045fd8993c572b24c061b4871bbcec1

Do not trigger non-existing plan (#1616) Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in 22 days

delete branch kudobuilder/kudo

delete branch : av/reject-nonexisting

delete time in 22 days

PR merged kudobuilder/kudo

Reviewers
Do not trigger non-existing plan

Signed-off-by: Alena Varkockova varkockova.a@gmail.com

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Fixes #1612

+18 -0

0 comment

2 changed files

alenkacz

pr closed time in 22 days

issue closedkudobuilder/kudo

kudo plan trigger does not fail on non-existing plan

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: ./bin/kubectl-kudo plan trigger --instance=test-operator-instance --name=xxx Triggered xxx plan for default/test-operator-instance instance

It also updates the CRD which it should not

What you expected to happen: Get an error that plan does not exist.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

closed time in 22 days

alenkacz

startedahmetb/kubectx

started time in 23 days

PR opened kudobuilder/kudo

Reviewers
Do not trigger non-existing plan

Signed-off-by: Alena Varkockova varkockova.a@gmail.com

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Fixes #1612

+18 -0

0 comment

2 changed files

pr created time in 23 days

create barnchkudobuilder/kudo

branch : av/reject-nonexisting

created branch time in 23 days

Pull request review commentkudobuilder/kudo

Create NS Annotation label Made a Constant

 const (  	// Last applied state for three way merges 	LastAppliedConfigAnnotation = "kudo.dev/last-applied-configuration"++	CreatedByAnnotation = "kudo.dev/created-by"

Just came by this PR. Why did we introduce new annotation, just wondering? Can't we use something that we already. use for all the other objects in enhancer? Like e.g. kudo.HeritageLabel ? 🤔 sorry if you already had this discussion in the past :)

kensipe

comment created time in 23 days

issue commentkudobuilder/kudo

ConfigMap not being re-apply with simple plan

I am no sure that's a good idea or that would be my last resort. We could reschedule reconciliation after failed delete check and even maybe leverage the RequeueAfter https://github.com/kubernetes-sigs/controller-runtime/blob/fc39662443b99ad0dcab22001571ccb9bc5b7960/pkg/reconcile/reconcile.go#L32 🤔

dboyleitrs

comment created time in 24 days

issue openedkudobuilder/kudo

kudo plan trigger does not fail on non-existing plan

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: ./bin/kubectl-kudo plan trigger --instance=test-operator-instance --name=xxx Triggered xxx plan for default/test-operator-instance instance

What you expected to happen: Get an error that plan does not exist.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

created time in 24 days

issue commentkudobuilder/kudo

ConfigMap not being re-apply with simple plan

@ANeumann82 oh yeah, that part... I was also wondering what would be a good solution to that as we should be watching everything that package creates and it can create pretty much anything 🤔

dboyleitrs

comment created time in 24 days

issue commentkudobuilder/kudo

ConfigMap not being re-apply with simple plan

@ANeumann82 isn't that basically what controller-runtime is doing though? it watches the resources and schedules reconciliation when the watch happens. What do you picture the watch triggering other than reconciliation? Just wondering 🤔

dboyleitrs

comment created time in 24 days

issue commentkudobuilder/kudo

ConfigMap not being re-apply with simple plan

Okay, I think I understand what's going on. We have a plan that basically does this:

  • create resource A1
  • delete resource A1
  • create resource A1

For resource deletion, we don't check for health, we assume that happened https://github.com/kudobuilder/kudo/blob/9db03a9f2be3d7bfe457ebc000881ad4433a27d4/pkg/engine/task/task_delete.go#L55

But I see that's not the case, I see that when I run in a debug it's actually doing:

  • create resource A1
  • delete resource A1
  • PATCH resource A1 (it thinks A1 still exists!)

By the way - if I do sleep for couple of seconds after deletion, it all works so it's really about all that happening asynchronously and us proceeding to the next step too fast.

As a solution I would propose:

  • add healthcheck for DeleteTask (it will query client.Get until it gets 404)
  • add ConfigMap to Owns here so we get reconciliation request after it got deleted https://github.com/kudobuilder/kudo/blob/f2142a9e672b40dad0daac158b4572adcf6a7308/pkg/controller/instance/instance_controller.go#L112

Question: should we do the same for create? 🤔 or is that synchronous and can you always do client.Get after create and always get your object?

dboyleitrs

comment created time in 24 days

issue closedkudobuilder/kudo

kudo init --dry-run -o yaml should work even without valid cluster connection

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./kubectl-kudo_0.15.0_darwin_x86_64 init -o yaml --dry-run
Errors
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

What you expected to happen: Dry run to pass

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

closed time in a month

alenkacz

issue commentkudobuilder/kudo

KUDO init --dry-run Should Succeed Regardless of Cluster has CRDs or Not

there's challenge with cert-manager related resources. @ANeumann82 can fill in the details since he pointed it out

kensipe

comment created time in a month

issue commentkudobuilder/kudo

ConfigMap not being re-apply with simple plan

@dboyleitrs okay it looks like I was able to reproduce, thanks for reporting it! I'll let you know once I know more :)

dboyleitrs

comment created time in a month

issue openedkudobuilder/kudo

kudo init --dry-run -o yaml should work even without valid cluster connection

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./kubectl-kudo_0.15.0_darwin_x86_64 init -o yaml --dry-run
Errors
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

What you expected to happen: Dry run to pass

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

created time in a month

delete branch kudobuilder/kudo

delete branch : av/v1-apiext

delete time in a month

push eventkudobuilder/kudo

Alena Varkockova

commit sha 352f47cb36bbcc3d9ac1afa74327ed0f8b1a2977

Switch back from apiext v1 to v1beta1 (#1597) Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in a month

PR merged kudobuilder/kudo

Reviewers
Switch back from apiext v1 to v1beta1

With this change we support even k8s < 1.16 but at the same time we also support all following k8s versions. We should do this change when v1beta1 is not available and then talk about the support matrix.

Fixes #1577

Signed-off-by: Alena Varkockova varkockova.a@gmail.com

+8 -8

0 comment

3 changed files

alenkacz

pr closed time in a month

issue closedkudobuilder/kudo

apiextensions.k8s.io/v1 not available until Kubernetes 1.16.0.

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

When trying to run kubectl kudo init -v4 on Kubernetes 1.15.11, I get the following logs:

...
Try to retrieve cert-manager CRD certificates.cert-manager.io
Try to retrieve cert-manager CRD certificates.certmanager.k8s.io
Errors                                                                 
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

This is caused here because apiextensions.k8s.io/v1 isn't available until Kubernetes 1.16.0.

What you expected to happen:

w00p w00p it init'd properly!

How to reproduce it (as minimally and precisely as possible):

Run kubectl kudo init against a 1.15 cluster.

Environment:

  • Kubernetes version (use kubectl version): client 1.16.6-beta.0, server 1.15.11-eks-af3caf
  • Kudo version (use kubectl kudo version): 0.14.0
  • Cloud provider or hardware configuration: EKS

closed time in a month

adamgoose

push eventkudobuilder/kudo

Marcin Owsiany

commit sha 8ce2007eb29841ad81233bba0e069ae13e04dc94

Clarify `kudo install` examples. (#1600) Signed-off-by: Marcin Owsiany <mowsiany@D2iQ.com>

view details

push time in a month

delete branch kudobuilder/kudo

delete branch : porridge/clarify-install-examples

delete time in a month

PR merged kudobuilder/kudo

Reviewers
Clarify `kudo install` examples.

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it:

Follow-up to https://github.com/kudobuilder/kudo/pull/1579

+7 -5

0 comment

2 changed files

porridge

pr closed time in a month

push eventkudobuilder/kudo

Alena Varkockova

commit sha 594ae5dfb371d4291f1ce6f53b5965863533302a

Mark instance as required parameter for diagnostics (#1598) Signed-off-by: Alena Varkockova <varkockova.a@gmail.com>

view details

push time in a month

delete branch kudobuilder/kudo

delete branch : av/diag-instance-required

delete time in a month

PR merged kudobuilder/kudo

Reviewers
Mark instance as required parameter for diagnostics

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
  2. Make sure you have added and ran the tests before submitting your PR
  3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Currently it is not required and yields the following error:

./bin/kubectl-kudo diagnostics collect
Collect Logs for 1 pods
Error: failed to get instance default/: resource name may not be empty
+2 -0

0 comment

1 changed file

alenkacz

pr closed time in a month

push eventkudobuilder/kudo

Andreas Neumann

commit sha 441f1f8cad6885c65905f19ec5e98e350090ec05

Don't log anything when validating dummy task (#1604) Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>

view details

push time in a month

delete branch kudobuilder/kudo

delete branch : an/ignore-dummy-task-validation

delete time in a month

PR merged kudobuilder/kudo

Reviewers
Don't log anything when validating dummy task

Signed-off-by: Andreas Neumann aneumann@mesosphere.com

What this PR does / why we need it:

There's no need for this log - it might confuse people that this is something they need to fix or adjust. Maybe we should add a warning in the package verify if a Dummy Task is used, as it should be only used for debugging though.

+1 -2

0 comment

1 changed file

ANeumann82

pr closed time in a month

Pull request review commentkudobuilder/kudo

Improve UX of kudo package new

 func newPackageNewCmd(fs afero.Fs, out io.Writer) *cobra.Command { 	return cmd } +func (pkg *packageNewCmd) validateOperatorArg(args []string) error {+	if pkg.interactive {+		if len(args) > 1 {+			return errors.New("expecting at most one argument - name of the operator")+		}+		return nil+	}++	if len(args) != 1 {+		return errors.New("expecting exactly one argument - name of the operator. Or use -i for interactive mode")+	}+	return nil+}+ // run returns the errors associated with cmd env func (pkg *packageNewCmd) run() error {  	// defaults 	pathDefault := "operator" 	opDefault := packages.OperatorFile{-		Name:            pkg.name,-		APIVersion:      reader.APIVersion,-		OperatorVersion: "0.1.0",-		KUDOVersion:     version.Get().GitVersion,+		Name:              "myoperator",+		APIVersion:        reader.APIVersion,+		OperatorVersion:   "0.1.0",+		AppVersion:        "0.1.0",+		KUDOVersion:       version.Get().GitVersion,+		KubernetesVersion: "0.16.0", 	} -	if !pkg.interactive {+	if pkg.name != "" {+		opDefault.Name = pkg.name+	} +	if !pkg.interactive {+		opDefault.Maintainers = []*v1beta1.Maintainer{+			{+				Name:  "My Name",+				Email: "MyEmail@invalid",

is it good idea to have a default with invalid email address? 🤔 should we at least go for something valid but nonexistent (probably?)

ANeumann82

comment created time in a month

Pull request review commentkudobuilder/kudo

Improve UX of kudo package new

 func newPackageNewCmd(fs afero.Fs, out io.Writer) *cobra.Command { 	return cmd } +func (pkg *packageNewCmd) validateOperatorArg(args []string) error {+	if pkg.interactive {

could you just put a comment here that interactive does not need name because we use default name that can be changed or sth like that? It was not obvious to me and I actually had to test it to understand what's going on

ANeumann82

comment created time in a month

pull request commentkudobuilder/kudo

update for goreleaser based on deprecation

should we note somewhere which version of goreleaser we currently support? Is there a way to somehow "fix" it like if we would be using go.mod or other dependency resolution thing?

kensipe

comment created time in a month

more