profile
viewpoint
Daniel Helfand danielhelfand VMware Chicago https://www.linkedin.com/in/daniel-helfand-068aaa30/ It's all about the experience.

danielhelfand/blog_posts 1

This is a repository for the content for blog posts I write

danielhelfand/chocolatey-tektoncd-cli 1

Chocolately package for the tektoncd-cli (tkn)

danielhelfand/angular-cli 0

CLI tool for Angular

danielhelfand/argo-cd 0

Declarative continuous deployment for Kubernetes.

danielhelfand/azure-cli 0

Command-line tools for Azure.

danielhelfand/azure-sdk-for-go-samples 0

Examples of how to utilize Azure services from Go.

danielhelfand/carvel-kapp-controller 0

Kubernetes controller for installing configuration (helm charts, ytt templates, plain yaml) with kapp as described by App CRD

danielhelfand/cassandra-container 0

Cassandra container images based on Software Collections and intended for OpenShift and general usage. Currently only CentOS based image is available. The Apache Cassandra database is the right choice when you need scalability and high availability without compromising performance.

pull request commentvmware-tanzu/carvel-ytt

Update repository urls

Will not include go module references — for now — as this might well break downstream projects that consume ytt as a library.

joaopapereira

comment created time in 5 hours

push eventvmware-tanzu/carvel-ytt

push time in 5 hours

push eventvmware-tanzu/carvel-ytt

John Ryan

commit sha f5b5700430b9e69884c5599b3820a4bbede95768

Relocate remaining doc references to k14s

view details

John Ryan

commit sha a4c7489609d651fabdee5c5bb94a7c3ac6b527b3

Move go module k14s/ytt to vmware-tanzu/carvel-ytt

view details

push time in 5 hours

issue commentvmware-tanzu/carvel-ytt

[lang] Support for standard YAML comments

Maybe we could also summarize and discuss the expected behavior (along with explanations for those decisions) with regard to # and ytt, in all of its permutations? That is:

# We consider this ambiguous. Did you mean to comment only visible in ytt, emit it in output YAML or miss an @? To ignore (and treat as a ytt comment, pass --ignore-unknown-comments)
#Same as above. Note the lack of space.
## Explicitly intended to be emitted in resulting YAML output (pending issue #63)
#! Explicitly intended to be a comment only visible in ytt.
#@ Explicitly intended for ytt directives

The above is just an example of the expectations, of course. I know that sort of guidance would help me a lot in understanding what ytt expects of me when passing code to it. Once settled, it'd be great to have that somewhere easily visible in documentation early on somehow so it's easier to understand.

Excellent suggestions, @patricknelson; thank you.

Yeah, a straight-forward authoring guide seems in order. A key (and prominent) section would handle exactly this notation.

dpb587-pivotal

comment created time in 6 hours

issue commentvmware-tanzu/carvel-ytt

[lang] Support for standard YAML comments

I presume we'd expect a similar failure scenario as in in @davedittrich's use case as well (e.g. #cloud-config), not just hash-spaces, correct?

Absolutely — in effect, when a YAML file becomes a yaml-template, ytt is taking over the commenting "space" in that document. Any data in that space that isn't recognized by ytt is a potential template coding error.

It appears this has morphed from being "Support standard YAML comments" (I suppose treating # Comment as #! Comment without erroring) into how to treat an entire file (e.g. yaml-plain vs yaml-template).

Yeah, that shift happened. There are a number of use-cases we're solving for simultaneously. In an attempt to keep things as simple as possible, we're chunking down for a more fundamental shift to try to accommodate as many as we can.

For me, my 95% use case will be yaml-template where the full file (or pipe) is originally intended for ytt, so the allowance of # Comment is simply a succinct syntactic sugar that has the side effect of also working normally on plain non-ytt formatted YAML code (be it just a segment of plain YAML or an entire file, a.k.a. yaml-plain).

We hear and appreciate that the original request was asking for allowing YAML comments in ytt templates. We'd love to be able to treat these inputs this way. However, as detailed above, allowing for such comments (unfortunately) also has the side effect of allowing for subtle template code errors (best illustration is where there's a lot of annotations and just one line or another is missing the meta-character: the result is that one line is quietly not executed).

It's hard not to see how when the tool does support plain YAML and that there's a notation for commenting in templates that it's reasonable to require authors to use that notation. It's legit possible we're missing something — if so, please help us understand.

That is, being less "safe" by default but still retaining linting capability by adding a new --use-strict-comments flag (and/or similar file marker).

Being less safe by default is an anti-goal for this project. This recent discussion has been all about how to retain that characteristic while improving the UX around widely held needs (namely, flowing plain YAML through the tool).

Of course, this would be a non-backward compatible change due to the change in default behavior and how it'd affect developer workflows.

It's hard to exaggerate the costs of breaking changes. We'd really want to be making a sweeping improvement that benefits the vast majority of our community to do so.

dpb587-pivotal

comment created time in 6 hours

issue commentvmware-tanzu/carvel-vendir

Bug: Paths don't allow using path names that starts with a string that is used in other path names

Sweeping up: #22 made it into v0.13.0; removing "in-progress" label.

aknysh

comment created time in 6 hours

issue commentkubernetes/kubectl

git-like blame for kubectl

@knight42 will you be able to attend next week's SIG-CLI call or record a demo and I'll re-play that during the call?

soltysh

comment created time in 10 hours

startedwalidshaari/Kubernetes-Certified-Administrator

started time in 11 hours

startedwalidshaari/Kubernetes-Certified-Administrator

started time in 11 hours

issue commentkubernetes/kubectl

drain.Helper defaults to "delete immediately"

@bboreham: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

bboreham

comment created time in 12 hours

issue openedkubernetes/kubectl

drain.Helper defaults to "delete immediately"

The member GracePeriodSeconds defaults to 0, which is interpreted as "delete immediately" by the lower layers called. I'm not sure whether this is a bug or some subtle design I haven't figure out.

IMHO it would have been better to copy metav1.DeleteOptions which makes GracePeriodSeconds a pointer, so the default value is nil.

created time in 12 hours

issue commentkubernetes/kubectl

Autocomplete for container name in kubectl exec

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

thomas-riccardi

comment created time in 18 hours

pull request commenttektoncd/cli

Add --no-headers flag to tkn triggerbinding list command

@vdemeester @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

pratikjagrut

comment created time in a day

pull request commenttektoncd/cli

Add --no-headers flag to tkn triggertemplate list command

@danielhelfand @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

pratikjagrut

comment created time in a day

pull request commenttektoncd/cli

Add --no-headers flag to tkn eventlistener list command

@danielhelfand @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

pratikjagrut

comment created time in a day

pull request commenttektoncd/cli

Add --no-headers flag to tkn condition list command

@pradeepitm12 @piyush-garg Can you review this and give lgtm so this PR can merge?

pratikjagrut

comment created time in a day

startedawslabs/karpenter

started time in 2 days

startedinovex/illuminatio

started time in 2 days

issue commentkubernetes/kubectl

git-like blame for kubectl

Screen Shot 2020-11-23 at 00 30 10

@soltysh Hi! I have almost implemented this interesting feature, it is not that hard as I expected.

soltysh

comment created time in 2 days

created repositoryjustaugustus/artifacts

created time in 2 days

CommitCommentEvent
CommitCommentEvent
CommitCommentEvent

issue commentkubernetes/kubectl

Improve documentation of kubectl top

/remove-lifecycle rotten

serathius

comment created time in 2 days

issue commentvmware-tanzu/carvel-kbld

Can kbld have workaround with manifests (Harbor)

hmm, i was pretty sure harbor support manifest lists. is it an older version of harbor?

your alternative would be to look at manifest list, identify specific image (the one that makes sense for your platform) and then reference that instead of referencing to the manifest list.

mhoshi-vm

comment created time in 2 days

issue commentvmware-tanzu/carvel-vendir

New source idea > java artefacts (ie. java dependencies)

@adriens sounds interesting. tell us more about what you thinking? (im not too familiar with java world workflows)

adriens

comment created time in 2 days

issue commenttektoncd/cli

tkn fails when parsing options with spaces as delimentr

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

kameshsampath

comment created time in 2 days

issue commentkubernetes/kubectl

kubectl create clusterrolebinding don't honor `--user` global flag

@fejta-bot: Closing this issue.

<details>

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

zhouya0

comment created time in 2 days

issue closedkubernetes/kubectl

kubectl create clusterrolebinding don't honor `--user` global flag

<!-- 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 related, please disclose it privately via https://kubernetes.io/security/ -->

What happened: Like this comment said: https://github.com/kubernetes/kubernetes/pull/91372#issuecomment-633467779

What you expected to happen: Find a way to honor both --user in clusterrolebinding and global --user flag.

How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See https://kubernetes.io/docs/setup/release/version-skew-policy for which versions and are currently supported. -->

Anything else we need to know?:

Environment:

  • Kubernetes client and server versions (use kubectl version):
  • Cloud provider or hardware configuration:
  • OS (e.g: cat /etc/os-release):

closed time in 2 days

zhouya0
more