profile
viewpoint

manute/gorepl-mode 18

A minor emacs mode for Go REPL

manute/emacs.d 3

My emacs config

manute/api-workflow-template 0

Skeleton project for work with aleph, bidi, component, yesql

manute/awesome-emacs 0

A community driven list of useful Emacs packages, libraries and others.

manute/aws-node-termination-handler 0

A Kubernetes Daemonset to gracefully handle EC2 instance shutdown

manute/boot-cljs-example 0

Example application using boot, boot-cljs, boot-cljs-repl, and boot-reload.

manute/bootstrap 0

Sleek, intuitive, and powerful front-end framework for faster and easier web development.

manute/compojure 0

A concise routing library for Ring/Clojure

manute/courses 0

repo for assigments on courses

issue commentkubernetes/cli-runtime

Inconsistency in the field `envs` for secretGenerator between the CLI and this pkg

Thanks for the info, I was referrering to the inconsistency running this (with k8s.io/cli-runtime v0.19.0) ->


import "k8s.io/cli-runtime/pkg/kustomize"
..

kustomize.RunKustomizeBuild(...)

Because it's failing for the field envs and only accepts env, and on the other hand the kustomize CLI (3.8.2) it's using the correct field envs.

So I'm not completely sure that the issue you mentioned will fix this.

manute

comment created time in 4 days

issue openedkubernetes/cli-runtime

Inconsistency in the field `envs` for secretGenerator between the CLI and this pkg

Hello,

It seems that the latest version of kustomize CLI (3.8.2) requires for the field envs in a secretGenerator a list of the possibles files. And the latest version of this pkg, requires for that field, the property env with a string.

It would be nice if this pkg is aligned with the cli, and I can work on a PR if that's ok.

created time in 11 days

issue closedkubernetes-sigs/kustomize

Inconsistency between API and CLI in the field `env` for SecretGenerator

Hi,

In the SecretGenerator's docs there's a field called env that apparently can be used for data entries.

Although , running the kustomize build via CLI (v3.8.1) for this yaml produces this error -> Error: json: unknown field "env

resources:
- deployment.yaml
- service.yaml
- hpa.yaml

secretGenerator:
- name: env-api-secrets-platform-deployment
  env: envs.txt
  type: Opaque

And running it via golang API programatically :

       var kustomizeOutput bytes.Buffer
	if err := kustomize.RunKustomizeBuild(&kustomizeOutput, fs.MakeRealFS(), path); err != nil {
		return nil, errors.Wrapf(err, "failed to run kustomize build over path: %s", path)
	}

, it works fine with these versions (go.mod) :

	sigs.k8s.io/kustomize/api v0.5.1 // indirect
	sigs.k8s.io/kustomize/kyaml v0.7.0

closed time in 11 days

manute

issue commentkubernetes-sigs/kustomize

Inconsistency between API and CLI in the field `env` for SecretGenerator

ah my bad, the issue should have been opened here https://github.com/kubernetes/cli-runtime

manute

comment created time in 11 days

push eventmanute/emacs.d

manute

commit sha 5b35d4155c957b4ee5fe01502516688aa8accb36

fixing the real problem with the lsp releases

view details

push time in 13 days

push eventmanute/emacs.d

manute

commit sha 0e94fb93e389807b90869c852592585a15439a02

commenting some pkg problems

view details

push time in 14 days

issue commentkubernetes-sigs/kustomize

Inconsistency between API and CLI in the field `env` for SecretGenerator

ok makes sense.

And Do you happen to know why calling the API directly with kustomize.RunKustomizeBuild is also failing for envs?

manute

comment created time in 16 days

delete branch manute/kube-no-trouble

delete branch : patch-1

delete time in 17 days

starteddoitintl/kube-no-trouble

started time in 19 days

issue commentdoitintl/kube-no-trouble

panic: runtime error: invalid memory address or nil pointer dereference

I have the same error, in mac osx and version 0.3.0 and I think is due to a bad kube config, so I've created a PR to avoid the panic and the error is showing up like:

> ./bin/kubent                                                                                                                                                                                (use1-test-4/default)
3:32PM INF >>> Kube No Trouble `kubent` <<<
3:32PM INF version dev (git sha dev)
3:32PM INF Initializing collectors and retrieving data
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM ERR Failed to initialize: <nil> error="invalid configuration: [context was not found for specified context: test-cluster, cluster has no server defined]"
3:32PM INF Loaded ruleset name=deprecated-1-16.rego
3:32PM INF Loaded ruleset name=deprecated-1-22.rego
san360

comment created time in 19 days

push eventmanute/kube-no-trouble

manute

commit sha 14f2d7ef9a5ccb5e231f438d97eda953a1e5fb0a

fixing fmt

view details

push time in 19 days

PR opened doitintl/kube-no-trouble

Fixing panic when collector name is nil

https://github.com/doitintl/kube-no-trouble/issues/25

+2 -1

0 comment

1 changed file

pr created time in 19 days

push eventmanute/kube-no-trouble

Manuel Alonso

commit sha f9c6986115e49040ef9aed9af1cbaeb166b5f803

fixing panic when collector name is nil

view details

push time in 19 days

fork manute/kube-no-trouble

Easily check your cluster for use of deprecated APIs

fork in 19 days

issue openedericchiang/k8s

Update Release

The latest release is v1.2.0 ( on 23 Aug 2018 ) and it has not got all the master changes. Is it possible to create a new release with all the master changes?

created time in a month

issue openedkubernetes-sigs/kustomize

pkg API is using `env` rather than `envs` field for SecretGenerator

Hi,

I'm using the kustomize golang API programatically with these versions (go.mod) :

	sigs.k8s.io/kustomize/api v0.5.1 // indirect
	sigs.k8s.io/kustomize/kyaml v0.6.0

And I've observed that is still using the old env field for SecretGenerator, because setting it like the list envs within the kustomization.yaml produces the error json: unknown field "envs", but setting it like env: envs.txt it works perfectly.

commonLabels:
  app.kubernetes.io/name: platform-test
  owner: platform-sre-eng

resources:
- deployment.yaml
- service.yaml
- hpa.yaml

secretGenerator:
- name: blabla
  envs:
  - envs.txt
  type: Opaque

Running it with the cli (v3.8.1) the opposite happens, working for the envs list and failing for the env property (which I think it's the proper way).

I think this is the latest version, so it would be nice if it can be aligned with the cli. I can work on a PR if that's ok.

created time in a month

push eventmanute/emacs.d

manute

commit sha 7b02e3e2c88f56518b9fd090918cbfac3c33afa5

comment and ensure

view details

push time in 3 months

push eventmanute/emacs.d

manute

commit sha 70b9c58dc4123115e9709106910a16558b44531d

adding locally a lsp stable version

view details

push time in 3 months

push eventmanute/emacs.d

manute

commit sha e1319ac1124d1be75a6446a8c0363b11eac64098

moar improvements

view details

push time in 3 months

startedemacs-lsp/lsp-mode

started time in 3 months

push eventmanute/emacs.d

manute

commit sha 564b7728a4b4b6ad59b62146efd239e55fdf8b80

extending doc

view details

push time in 3 months

more