profile
viewpoint
Kazuki Suda superbrothers @pfnet Tokyo, JAPAN and the Internet https://text.superbrothers.dev/ CNCF Ambassador / Kubernetes Active Contributor / Kubernetes Meetup Tokyo and Kubernetes Community Days Tokyo co-organizer

superbrothers/capturejs 270

Full webpage capture command-line tool with PhantomJS and NodeJS

cloudnativedevops-ja/demo 15

オライリー・ジャパン「Kubernetes で実践するクラウドネイティブ DevOps」に付属するサンプルコード

pfnet-research/asdf-clusterctl 9

clusterctl plugin for the asdf version manager

superbrothers/close-pull-request 9

A GitHub Action to automatically close pull requests.

superbrothers/ansible-bootstrap-devenv 3

Ansible playbooks for bootstrapping development environment

asdf-community/asdf-getenvoy 2

GetEnvoy plugin for the asdf version manager

asdf-community/asdf-tridentctl 1

tridentctl plugin for the asdf version manager

superbrothers/200m 0

200m radius circles on the map

startedevansm7/vftool

started time in 5 hours

pull request commentkubernetes/enhancements

fix broken link:https://github.com/kubernetes/kubernetes/blob/master/…

@fejta-bot: Closed this PR.

<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>

CriaHu

comment created time in 11 hours

PR closed kubernetes/enhancements

Reviewers
fix broken link:https://github.com/kubernetes/kubernetes/blob/master/… cncf-cla: yes kind/kep lifecycle/rotten needs-ok-to-test sig/architecture sig/cloud-provider size/XS

…pkg/cloudprovider/cloud.go

+1 -1

5 comments

1 changed file

CriaHu

pr closed time in 11 hours

pull request commentkubernetes/enhancements

fix broken link:https://github.com/kubernetes/kubernetes/blob/master/…

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

CriaHu

comment created time in 11 hours

startedOAuthSwift/OAuthSwift

started time in 13 hours

Pull request review commentkubernetes/enhancements

Apiserver namespace labels

+# KEP-2161 : Immutable label selectors for all namespaces++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [User Stories (Optional)](#user-stories-optional)+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring Requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+<!-- /toc -->++## Release Signoff Checklist++Items marked with (R) are required *prior to targeting to a milestone / release*.++- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [ ] (R) Design details are appropriately documented+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [ ] (R) Graduation criteria is in place+- [ ] (R) Production readiness review completed+- [ ] Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++Today to select a Namespace by its name is not possible because the NamespaceSelector is only+possible to deal with labels.++The idea of this KEP is to propose that namespaces have an immutable label when created, created+by the APIServer that represents the metadata.name of the object and turn namespaces selectable +by the name.++## Motivation++In https://github.com/kubernetes/enhancements/issues/2112 , we discussed several +ways to implement network policies that select namespaces by name, rather than by +relying on labels which may be unknown, or uneditable by people writing policies, +or untrustworthy.++This was inspired by a broad community ask to target namespaces in this manner, +as evidenced by issues such as [kubernetes #88253](https://github.com/kubernetes/kubernetes/issues/88253), +and the larger set of user feedback obtained in  [user stories](https://github.com/jayunit100/network-policy-subproject/blob/master/p0_user_stories.md).++It turns out all solutions:+Break the old API in fundamental ways that are questionably WRT cost/benefit OR+Add nesting complexity to the network policy API, wherein certain “subsets” of +the API were not usable together.  This is not “bad”, but it is suboptimal and +introduces redundant semantics.  For example, you may need a way to declare +namespaceAsName selectors, which is distinct from namespace label selectors.++It’s also worth noting that there are at least 2 other NamespaceSelector APIs in +k/k - Validating and Mutating webhooks.  They will inevitably need similar API +evolution, but we don't need to do that as part of this KEP.++Example:  The obvious API, when combined with a podSelector, decreases security +of a pod - an old client would be more open than users would expect them to be. +This is thoroughly debated in the KEP.  Fail-closed is a requirement.++If a podSelector is an enabled for a network policy peer, then currently, nil +values for namespace selectors mean *any* namespace is allowed:++|                         | old api client   | new api client |+|-------------------------|------------------|----------------|+| namespaceAsNameSelector | ANY              | AND            |+| namespaceSelector       | AND              | AND            |+| ipBlock                 | NOT ALLOWED      | NOT ALLOWED    |++Thus, adding a *new* namespace selector field would result in  old api clients +assuming that ANY namespace is allowed when namespaceAsNameSelectors are utilized +instead of the namespaceSelector fields, due to the fact that *nil namespaceSelectors are promiscuous*.++Possible solutions to this divergent interpretation of policy might be:+- closed failures which break on old clients (making networkpolicy api evolution very hard)+- open failures with lots of warnings and docs about how old clients might +overinterpret the allowed connectivity for a policy++Both of these are impractical due to the nature of security tools, which need to +be robust and explicit.  Although failing in a closed manner is acceptable... it is obviously unfortunate,+as it would obsolete all network policy providers *not* eagerly adopting such a new semantic, which is+overly restrictive and against the spirit of community-friendly, safe API evolution which is so important+to a large project like Kubernetes with many external functional plugins.++Ideally, a fix here would “just work” for “back-rev” implementations of NetworkPolicy +(which are out-of-tree - generally implemented by cni plugins) and would not +introduce new surprises for users. But in practicality this is not the case +because, by adding a new selection data structure, the logical inclusion/exclusion +properties of namespace and pod selectors become drastically different, as shown in the table below:+++In this table "policy-reader" might be something like the "calico-controller" or any other cni agent+that reads the API Servers network policy portfolio and responds to it over time.++|         input policy         | policy-reader (old)    | client (new)        |   |   |+|------------------------------|------------------------|---------------------|---|---|+| nsNameSelector + podSelector | ANY ns, pod restricted | ns + pod restricted |   |   |+| nsNameSelector               | invalid (empty peer)   | ns restricted       |   |   |+| podSelector                  | ANY namespace          | ANY namespace       |   |   |++In an older client (one which predated the addition of a new, "nsNameSelector" field, we find+that there is a scenario (`ANY ns, pod restricted`), wherein an old interpretation of the API+assumes that the ONLY restricting field is a pod label.  Thus, although the user intended to+restrict all traffic to a namespace/pod combination, the policy implementer does something **much**+more promiscuous.++This is all avoidable if we could assume, in all cases, that namespaces have a default label.++There may also be many other usecases where the a security or permissions boundary might be conveniently defined in terms+of a namepsace name, and that such a definition would be most easily referenced by a default label.++### Goals++- Add an immutable default label to ALL namespaces, as the namespace name so this +can be used as selector by arbitrary components.++### Non-Goals++* Publishing name labels on all resources+* Exposing arbitrary fields as selectors++## Proposal++We propose to label of all namespaces, by default, with a reserved label +(i.e. “kubernetes.io/metadata.name” or some such), to allow easy selection.++If this label is missing, it is added by the apiserver++If the label is incorrect or changed, the apiserver fails to validate the object

Ha, I had two thoughts here:

  1. After this feature is enabled, will label selectors work for Namespaces, or will there need to be a read-write cycle on each Namespace object (like with CRDs for version upgrades)?

  2. Would it make sense to use/reserve metadata.kubernetes.io/ as a prefix for this kind of usage (reflecting field values to labels) without any promises of future reflections?

jayunit100

comment created time in 16 hours

Pull request review commentkubernetes/enhancements

Apiserver namespace labels

+# KEP-2161 : Immutable label selectors for all namespaces++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [User Stories (Optional)](#user-stories-optional)+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring Requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+<!-- /toc -->++## Release Signoff Checklist++Items marked with (R) are required *prior to targeting to a milestone / release*.++- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [ ] (R) Design details are appropriately documented+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [ ] (R) Graduation criteria is in place+- [ ] (R) Production readiness review completed+- [ ] Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++Today to select a Namespace by its name is not possible because the NamespaceSelector is only+possible to deal with labels.++The idea of this KEP is to propose that namespaces have an immutable label when created, created+by the APIServer that represents the metadata.name of the object and turn namespaces selectable +by the name.++## Motivation++In https://github.com/kubernetes/enhancements/issues/2112 , we discussed several +ways to implement network policies that select namespaces by name, rather than by +relying on labels which may be unknown, or uneditable by people writing policies, +or untrustworthy.++This was inspired by a broad community ask to target namespaces in this manner, +as evidenced by issues such as [kubernetes #88253](https://github.com/kubernetes/kubernetes/issues/88253), +and the larger set of user feedback obtained in  [user stories](https://github.com/jayunit100/network-policy-subproject/blob/master/p0_user_stories.md).++It turns out all solutions:+Break the old API in fundamental ways that are questionably WRT cost/benefit OR+Add nesting complexity to the network policy API, wherein certain “subsets” of +the API were not usable together.  This is not “bad”, but it is suboptimal and +introduces redundant semantics.  For example, you may need a way to declare +namespaceAsName selectors, which is distinct from namespace label selectors.++It’s also worth noting that there are at least 2 other NamespaceSelector APIs in +k/k - Validating and Mutating webhooks.  They will inevitably need similar API +evolution, but we don't need to do that as part of this KEP.++Example:  The obvious API, when combined with a podSelector, decreases security +of a pod - an old client would be more open than users would expect them to be. +This is thoroughly debated in the KEP.  Fail-closed is a requirement.++If a podSelector is an enabled for a network policy peer, then currently, nil +values for namespace selectors mean *any* namespace is allowed:++|                         | old api client   | new api client |+|-------------------------|------------------|----------------|+| namespaceAsNameSelector | ANY              | AND            |+| namespaceSelector       | AND              | AND            |+| ipBlock                 | NOT ALLOWED      | NOT ALLOWED    |++Thus, adding a *new* namespace selector field would result in  old api clients +assuming that ANY namespace is allowed when namespaceAsNameSelectors are utilized +instead of the namespaceSelector fields, due to the fact that *nil namespaceSelectors are promiscuous*.++Possible solutions to this divergent interpretation of policy might be:+- closed failures which break on old clients (making networkpolicy api evolution very hard)+- open failures with lots of warnings and docs about how old clients might +overinterpret the allowed connectivity for a policy++Both of these are impractical due to the nature of security tools, which need to +be robust and explicit.  Although failing in a closed manner is acceptable... it is obviously unfortunate,+as it would obsolete all network policy providers *not* eagerly adopting such a new semantic, which is+overly restrictive and against the spirit of community-friendly, safe API evolution which is so important+to a large project like Kubernetes with many external functional plugins.++Ideally, a fix here would “just work” for “back-rev” implementations of NetworkPolicy +(which are out-of-tree - generally implemented by cni plugins) and would not +introduce new surprises for users. But in practicality this is not the case +because, by adding a new selection data structure, the logical inclusion/exclusion +properties of namespace and pod selectors become drastically different, as shown in the table below:+++In this table "policy-reader" might be something like the "calico-controller" or any other cni agent+that reads the API Servers network policy portfolio and responds to it over time.++|         input policy         | policy-reader (old)    | client (new)        |   |   |+|------------------------------|------------------------|---------------------|---|---|+| nsNameSelector + podSelector | ANY ns, pod restricted | ns + pod restricted |   |   |+| nsNameSelector               | invalid (empty peer)   | ns restricted       |   |   |+| podSelector                  | ANY namespace          | ANY namespace       |   |   |++In an older client (one which predated the addition of a new, "nsNameSelector" field, we find+that there is a scenario (`ANY ns, pod restricted`), wherein an old interpretation of the API+assumes that the ONLY restricting field is a pod label.  Thus, although the user intended to+restrict all traffic to a namespace/pod combination, the policy implementer does something **much**+more promiscuous.++This is all avoidable if we could assume, in all cases, that namespaces have a default label.++There may also be many other usecases where the a security or permissions boundary might be conveniently defined in terms+of a namepsace name, and that such a definition would be most easily referenced by a default label.++### Goals++- Add an immutable default label to ALL namespaces, as the namespace name so this +can be used as selector by arbitrary components.++### Non-Goals++* Publishing name labels on all resources+* Exposing arbitrary fields as selectors++## Proposal++We propose to label of all namespaces, by default, with a reserved label +(i.e. “kubernetes.io/metadata.name” or some such), to allow easy selection.++If this label is missing, it is added by the apiserver++If the label is incorrect or changed, the apiserver fails to validate the object+++### User Stories (Optional)++See https://github.com/kubernetes/enhancements/pull/2113/files for relevant user stories.++### Notes/Constraints/Caveats (Optional)+++### Risks and Mitigations++* Every namespace gets bigger in size. We think this is inconsequential+* Some user may already be using that label already. This is mitigated by the +fact that the whole "kubernetes.io" label prefix is reserved. However, since there+is no validation of reserved label prefixes, such namespaces will be invalidated+post-upgrade, i.e. no further writes allowed. For this reason, we can do one alpha+release where we log/event if we observe usage of this key that is not compatible.++## Design Details++This can be implemented by modifying the defaults.go and validation.go components for the namespace API, i.e., in the defaults.go file for api/core:++```+func SetDefaults_Namespace(obj *v1.Namespace) {+  if obj.Labels == nil {+  	obj.Labels = map[string]string{}+  }+  +  if _, found := obj.Labels[“kubernetes.io/metadata.name”]; !found {+  	obj.Labels[“kubernetes.io/metadata.name”] = obj.Name+  }+}+```+And in the validation.go, we implement the guarantee of this namespace’s value +being constant WRT namespace name (which is immutable).++```+func ValidateNamespace(namespace *core.Namespace) field.ErrorList {+	// Check if namespace.Labels[“kubernetes.io/metadata.name”] == namespace.Name+  // if not add an error+  // ...+  return allErrs+```++This solves not just NetworkPolicy, but all such namespace selector APIs without +any disruption or version skew problems.++### Test Plan+* Add unit tests that creates a namespace and checks if the namespace contains +the label+* Add a test that tries to select this namespace by the label (this should +return also only that namespace)+* Try to modify the reserved label and this should return an error+* Check the WATCH operation against existing namespaces that do not have this +label still work properly.++### Graduation Criteria+* This feature being enabled by default at least one release.++### Upgrade / Downgrade Strategy+* Check the WATCH situation described in test plan, otherwise populate the label +of namespaces without it.+* In case of downgrade, as this is just a label it will work fine. Network Policies +that relies on this label may fail-close, which might be acceptable.++### Version Skew Strategy+N/A++## Production Readiness Review Questionnaire++### Feature Enablement and Rollback

Would this need to be a controller or a one-shot job?

jayunit100

comment created time in 16 hours

Pull request review commentkubernetes/enhancements

Apiserver namespace labels

+# KEP-2161 : Immutable label selectors for all namespaces++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [User Stories (Optional)](#user-stories-optional)+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring Requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+  - [Add new select-by-name capabilities to policy APIs](#add-new-select-by-name-capabilities-to-policy-apis)+<!-- /toc -->++## Release Signoff Checklist++Items marked with (R) are required *prior to targeting to a milestone / release*.++- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [ ] (R) Design details are appropriately documented+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [ ] (R) Graduation criteria is in place+- [ ] (R) Production readiness review completed+- [ ] Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++Today to select a Namespace by its name is not possible because the NamespaceSelector is only+possible to deal with labels.++The idea of this KEP is to propose that namespaces have an immutable label+matching the metadata.name of the namespace that allows label selectors to include/exclude+namespaces by name.++## Motivation++In https://github.com/kubernetes/enhancements/issues/2112 , we discussed several +ways to implement network policies that select namespaces by name, rather than by +relying on labels which may be unknown, or uneditable by people writing policies, +or untrustworthy.++This was inspired by a broad community ask to target namespaces in this manner, +as evidenced by issues such as [kubernetes #88253](https://github.com/kubernetes/kubernetes/issues/88253), +and the larger set of user feedback obtained in  [user stories](https://github.com/jayunit100/network-policy-subproject/blob/master/p0_user_stories.md).++It’s also worth noting that there are at least 2 other NamespaceSelector APIs in +k/k - Validating and Mutating webhooks.  They will inevitably need similar API +evolution, but we don't need to do that as part of this KEP.++It turns out that alternate [solutions](#alternatives):+Break the old API in fundamental ways that are questionably WRT cost/benefit OR+add nesting complexity to the network policy API, wherein certain “subsets” of+the API were not usable together.  This is not “bad”, but it is suboptimal and+introduces redundant semantics. This is avoidable if we could assume, in all+cases, that namespaces have a default label, thereby leveraging existing+functionalities offered by label selectors.++There may also be many other usecases where the security or permissions boundary+might be conveniently defined in terms of a namepsace name, and that such a+definition would be most easily referenced by a default label.++### Goals++- Add an immutable default label to ALL namespaces, as the namespace name so this +can be used as selector by arbitrary components.++### Non-Goals++* Publishing name labels on all resources++Not all resource names satisfy the label requirements. Some of those resources require+a name that can be used as a DNS subdomain name.+* Exposing arbitrary fields as selectors++## Proposal++We propose to label all namespaces, by default, with a reserved label of+“kubernetes.io/metadata.name” and set it to the namespace's name. This will allow+any resource with a `namespaceSelector` field (such as NetworkPolicy, MutatingWebhookConfiguration+etc) to select (or exclude with `notIn`) these namespaces by explicitly matching on+the namespace's name with traditional label selector mechanisms.++If this label is missing, it is added by the apiserver.++If the label is incorrect or changed, the apiserver fails to validate the object+++### User Stories (Optional)++See https://github.com/kubernetes/enhancements/pull/2113/files for relevant user stories.++### Notes/Constraints/Caveats (Optional)++* The name of the namespace must satisfy label value [requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).+Currently, the name of the namespace must be a valid [DNS label](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names),+and this requirement must be satisfied going forward.++### Risks and Mitigations++* Every namespace gets bigger in size. We think this is inconsequential+* Some user may already be using that label already. This is mitigated by the +fact that the whole "kubernetes.io" label prefix is [reserved](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set). However, since there+is no validation of reserved label prefixes, such namespaces will be invalidated+post-upgrade, i.e. no further writes allowed. For this reason, we can do one alpha+release where we log/event if we observe usage of this key that is not compatible.++## Design Details++This can be implemented by modifying the defaults.go and validation.go components for the namespace API, i.e., in the defaults.go file for api/core:++```+func SetDefaults_Namespace(obj *v1.Namespace) {+  if obj.Labels == nil {+  	obj.Labels = map[string]string{}+  }+  +  if _, found := obj.Labels[“kubernetes.io/metadata.name”]; !found {+  	obj.Labels[“kubernetes.io/metadata.name”] = obj.Name+  }+}+```+And in the validation.go, we implement the guarantee of this namespace’s value +being constant WRT namespace name (which is immutable).++```+func ValidateNamespace(namespace *core.Namespace) field.ErrorList {+	// Check if namespace.Labels[“kubernetes.io/metadata.name”] == namespace.Name+  // if not add an error+  // ...+  return allErrs+```++This solves not just NetworkPolicy, but all such namespace selector APIs without +any disruption or version skew problems.++### Test Plan+* Add unit tests that creates a namespace and checks if the namespace contains +the label+* Add a test that tries to select this namespace by the label (this should +return also only that namespace)+* Try to modify the reserved label and this should return an error+* Check the WATCH operation against existing namespaces that do not have this +label still work properly.++### Graduation Criteria+* This feature being enabled by default at least one release.++### Upgrade / Downgrade Strategy+* Check the WATCH situation described in test plan, otherwise populate the label +of namespaces without it.+* In case of downgrade, as this is just a label it will work fine. Network Policies +that rely on this label w.r.t. their `matchLabels` criteria within namespaceSelector+to enforce rules will fail-close, as they no longer will match these namespaces,+thereby fail to add such namespaces to their whitelist rules.+On the other hand, network policies with `matchExpressions` within a+namespaceSelector, specifically with a `notIn` operator as shown below, will+inadvertently select this namespace instead of excluding it, which is an undesired+side effect.++```+namespaceSelector:+  matchExpressions:+  - key: kubernetes.io/metadata.name+    operator: NotIn+    values:+    - kube-system+```++Hence, it must be noted that namespaces are not guaranteed to have this label on+downgrades to release which do not support this feature. Users may choose to label+their namespaces by themselves in order to restore their expected behaviour in+terms of network policy rules.++### Version Skew Strategy+N/A++## Production Readiness Review Questionnaire++### Feature Enablement and Rollback++1.21:+- gate disabled by default+- if gate disabled, log or event incompatible uses of this+- if gate enabled, enforce+- release note++1.22:+- gate enabled by default+- release note++1.23:+- lock gate enabled++### Rollout, Upgrade and Rollback Planning++_This section must be completed when targeting beta graduation to a release._++* **How can a rollout fail? Can it impact already running workloads?**+  TBD++* **What specific metrics should inform a rollback?**+  TBD++* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?**+  TBD++* **Is the rollout accompanied by any deprecations and/or removals of features, APIs, +fields of API types, flags, etc.?**+  Even if applying deprecation policies, they may still surprise some users.++### Monitoring Requirements++_This section must be completed when targeting beta graduation to a release._++* **How can an operator determine if the feature is in use by workloads?**++By running `kubectl get ns --show-labels` and inspecting the `kubernetes.io` values.++* **What are the SLIs (Service Level Indicators) an operator can use to determine** ++Since this just an immutable field, we don't expect any such indicators to be of relevance.++* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**++Since this just an immutable field, we don't expect any such indicators to be of relevance.++* **Are there any missing metrics that would be useful to have to improve observability +of this feature?**++Since this just an immutable field, we don't expect any such indicators to be of relevance.+++### Dependencies++* **Does this feature depend on any specific services running in the cluster?**+  None++### Scalability++* **Will enabling / using this feature result in any new API calls?**++No, because it is just mutating the incoming created namespaces at the APIServer level.++* **Will enabling / using this feature result in introducing new API types?**++No.++* **Will enabling / using this feature result in any new calls to the cloud +provider?**:++No++* **Will enabling / using this feature result in increasing size or count of +the existing API objects?**++No+

I think this will actually increase the resource size of Namespace objects and their label index (but probably not noticably).

jayunit100

comment created time in 17 hours

issue commentkubernetes/enhancements

Extending Hugepage Feature

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

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 rotten

bg-chun

comment created time in a day

issue commentcncf/toc

Update CNCF Cloud Native Definition v1.0

@kwussow potentially this is something for the business value subcommittee to look at?

xmulligan

comment created time in a day

Pull request review commentkubernetes/enhancements

Apiserver namespace labels

+# KEP-2161 : Immutable label selectors for all namespaces++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [User Stories (Optional)](#user-stories-optional)+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring Requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+<!-- /toc -->++## Release Signoff Checklist++Items marked with (R) are required *prior to targeting to a milestone / release*.++- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [ ] (R) Design details are appropriately documented+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [ ] (R) Graduation criteria is in place+- [ ] (R) Production readiness review completed+- [ ] Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++Today to select a Namespace by its name is not possible because the NamespaceSelector is only+possible to deal with labels.++The idea of this KEP is to propose that namespaces have an immutable label when created, created+by the APIServer that represents the metadata.name of the object and turn namespaces selectable +by the name.++## Motivation++In https://github.com/kubernetes/enhancements/issues/2112 , we discussed several +ways to implement network policies that select namespaces by name, rather than by +relying on labels which may be unknown, or uneditable by people writing policies, +or untrustworthy.++This was inspired by a broad community ask to target namespaces in this manner, +as evidenced by issues such as [kubernetes #88253](https://github.com/kubernetes/kubernetes/issues/88253), +and the larger set of user feedback obtained in  [user stories](https://github.com/jayunit100/network-policy-subproject/blob/master/p0_user_stories.md).++It turns out all solutions:+Break the old API in fundamental ways that are questionably WRT cost/benefit OR+Add nesting complexity to the network policy API, wherein certain “subsets” of +the API were not usable together.  This is not “bad”, but it is suboptimal and +introduces redundant semantics.  For example, you may need a way to declare +namespaceAsName selectors, which is distinct from namespace label selectors.++It’s also worth noting that there are at least 2 other NamespaceSelector APIs in +k/k - Validating and Mutating webhooks.  They will inevitably need similar API +evolution, but we don't need to do that as part of this KEP.++Example:  The obvious API, when combined with a podSelector, decreases security +of a pod - an old client would be more open than users would expect them to be. +This is thoroughly debated in the KEP.  Fail-closed is a requirement.++If a podSelector is an enabled for a network policy peer, then currently, nil +values for namespace selectors mean *any* namespace is allowed:++|                         | old api client   | new api client |+|-------------------------|------------------|----------------|+| namespaceAsNameSelector | ANY              | AND            |+| namespaceSelector       | AND              | AND            |+| ipBlock                 | NOT ALLOWED      | NOT ALLOWED    |++Thus, adding a *new* namespace selector field would result in  old api clients +assuming that ANY namespace is allowed when namespaceAsNameSelectors are utilized +instead of the namespaceSelector fields, due to the fact that *nil namespaceSelectors are promiscuous*.++Possible solutions to this divergent interpretation of policy might be:+- closed failures which break on old clients (making networkpolicy api evolution very hard)+- open failures with lots of warnings and docs about how old clients might +overinterpret the allowed connectivity for a policy++Both of these are impractical due to the nature of security tools, which need to +be robust and explicit.  Although failing in a closed manner is acceptable... it is obviously unfortunate,+as it would obsolete all network policy providers *not* eagerly adopting such a new semantic, which is+overly restrictive and against the spirit of community-friendly, safe API evolution which is so important+to a large project like Kubernetes with many external functional plugins.++Ideally, a fix here would “just work” for “back-rev” implementations of NetworkPolicy +(which are out-of-tree - generally implemented by cni plugins) and would not +introduce new surprises for users. But in practicality this is not the case +because, by adding a new selection data structure, the logical inclusion/exclusion +properties of namespace and pod selectors become drastically different, as shown in the table below:+++In this table "policy-reader" might be something like the "calico-controller" or any other cni agent+that reads the API Servers network policy portfolio and responds to it over time.++|         input policy         | policy-reader (old)    | client (new)        |   |   |+|------------------------------|------------------------|---------------------|---|---|+| nsNameSelector + podSelector | ANY ns, pod restricted | ns + pod restricted |   |   |+| nsNameSelector               | invalid (empty peer)   | ns restricted       |   |   |+| podSelector                  | ANY namespace          | ANY namespace       |   |   |++In an older client (one which predated the addition of a new, "nsNameSelector" field, we find+that there is a scenario (`ANY ns, pod restricted`), wherein an old interpretation of the API+assumes that the ONLY restricting field is a pod label.  Thus, although the user intended to+restrict all traffic to a namespace/pod combination, the policy implementer does something **much**+more promiscuous.++This is all avoidable if we could assume, in all cases, that namespaces have a default label.++There may also be many other usecases where the a security or permissions boundary might be conveniently defined in terms+of a namepsace name, and that such a definition would be most easily referenced by a default label.++### Goals++- Add an immutable default label to ALL namespaces, as the namespace name so this +can be used as selector by arbitrary components.++### Non-Goals++* Publishing name labels on all resources+* Exposing arbitrary fields as selectors++## Proposal++We propose to label of all namespaces, by default, with a reserved label +(i.e. “kubernetes.io/metadata.name” or some such), to allow easy selection.++If this label is missing, it is added by the apiserver++If the label is incorrect or changed, the apiserver fails to validate the object+++### User Stories (Optional)++See https://github.com/kubernetes/enhancements/pull/2113/files for relevant user stories.++### Notes/Constraints/Caveats (Optional)+++### Risks and Mitigations++* Every namespace gets bigger in size. We think this is inconsequential+* Some user may already be using that label already. This is mitigated by the +fact that the whole "kubernetes.io" label prefix is reserved. However, since there+is no validation of reserved label prefixes, such namespaces will be invalidated+post-upgrade, i.e. no further writes allowed. For this reason, we can do one alpha+release where we log/event if we observe usage of this key that is not compatible.++## Design Details++This can be implemented by modifying the defaults.go and validation.go components for the namespace API, i.e., in the defaults.go file for api/core:++```+func SetDefaults_Namespace(obj *v1.Namespace) {+  if obj.Labels == nil {+  	obj.Labels = map[string]string{}+  }+  +  if _, found := obj.Labels[“kubernetes.io/metadata.name”]; !found {+  	obj.Labels[“kubernetes.io/metadata.name”] = obj.Name+  }+}+```+And in the validation.go, we implement the guarantee of this namespace’s value +being constant WRT namespace name (which is immutable).++```+func ValidateNamespace(namespace *core.Namespace) field.ErrorList {+	// Check if namespace.Labels[“kubernetes.io/metadata.name”] == namespace.Name+  // if not add an error+  // ...+  return allErrs+```++This solves not just NetworkPolicy, but all such namespace selector APIs without +any disruption or version skew problems.++### Test Plan+* Add unit tests that creates a namespace and checks if the namespace contains +the label+* Add a test that tries to select this namespace by the label (this should +return also only that namespace)+* Try to modify the reserved label and this should return an error+* Check the WATCH operation against existing namespaces that do not have this +label still work properly.++### Graduation Criteria+* This feature being enabled by default at least one release.++### Upgrade / Downgrade Strategy+* Check the WATCH situation described in test plan, otherwise populate the label +of namespaces without it.+* In case of downgrade, as this is just a label it will work fine. Network Policies +that relies on this label may fail-close, which might be acceptable.++### Version Skew Strategy+N/A++## Production Readiness Review Questionnaire++### Feature Enablement and Rollback++1.21:+- gate disabled by default+- if gate disabled, log or event incompatible uses of this+- if gate enabled, enforce+- release note++1.22:+- gate enabled by default+- release note

in general most of the NetworkPolicy APIs could be prototyped in the early stages via some type of lightweight CRD or controller . I think we should visit this monday . cc @rikatz @abhiraut ha look the netpol operator idea ... just ... won't. .. go ... away :)

jayunit100

comment created time in a day

issue commentkubernetes/kubectl

git-like blame for kubectl

@apelisse Hi, kubectl-blame is able to customize time format now https://github.com/knight42/kubectl-blame#1-customize-time-format

soltysh

comment created time in a day

pull request commentkubernetes/enhancements

KEP 2079 - Add PortRange KEP

@thockin Are you/can you be assigned as the approver of this one? If so I'll change in the kep.yaml and wait for more considerations.

rikatz

comment created time in a day

push eventasdf-vm/actions

dependabot[bot]

commit sha 4a02138d06e1bb0a4f90f19b31cf085198307d89

Bump esbuild from 0.8.11 to 0.8.16 Bumps [esbuild](https://github.com/evanw/esbuild) from 0.8.11 to 0.8.16. - [Release notes](https://github.com/evanw/esbuild/releases) - [Changelog](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md) - [Commits](https://github.com/evanw/esbuild/compare/v0.8.11...v0.8.16) Signed-off-by: dependabot[bot] <support@github.com>

view details

Sora Morimoto

commit sha ca38b869a2d1adcbea666ab483bfac32e859a45b

yarn build Signed-off-by: Sora Morimoto <sora@morimoto.io>

view details

Sora Morimoto

commit sha 86d8df71356a197f4fbed809e32327b825610deb

Merge pull request #169 from asdf-vm/dependabot/npm_and_yarn/esbuild-0.8.16 Bump esbuild from 0.8.11 to 0.8.16

view details

push time in a day

delete branch asdf-vm/actions

delete branch : dependabot/npm_and_yarn/esbuild-0.8.16

delete time in a day

PR merged asdf-vm/actions

Bump esbuild from 0.8.11 to 0.8.16 dependencies javascript

Bumps esbuild from 0.8.11 to 0.8.16. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">esbuild's releases</a>.</em></p> <blockquote> <h2>v0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> <h2>v0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> <p>With TypeScript 4.1, you can now omit <code>baseUrl</code> when using <code>paths</code>. When you do this, it as if you had written <code>"baseUrl": "."</code> instead for the purpose of the <code>paths</code> feature, but the <code>baseUrl</code> value is not actually set and does not affect path resolution. These <code>tsconfig.json</code> files are now supported by esbuild.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">esbuild's changelog</a>.</em></p> <blockquote> <h2>0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> <h2>0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/f4cec94deaa61e5bb9bd3c0d14ad37ead1d8ca55"><code>f4cec94</code></a> publish 0.8.16 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/7ba75db79fc0d328a3b4dc039c04b7ff142d31ef"><code>7ba75db</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a></li> <li><a href="https://github.com/evanw/esbuild/commit/f8eb7595e4b16f7e235941b39eac59234af92396"><code>f8eb759</code></a> make <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a> backward-compatible</li> <li><a href="https://github.com/evanw/esbuild/commit/0e356b1852aad23d25726b7ce5a9a0242bcb41c4"><code>0e356b1</code></a> support custom host in serve api (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/8e9a4d5310c82cb1628af0eb0e903eb5a86f88ac"><code>8e9a4d5</code></a> release notes for "process.env.NODE_ENV" change</li> <li><a href="https://github.com/evanw/esbuild/commit/34c5305c174cb95dd2c01fe6f86ee90cfa6d33fc"><code>34c5305</code></a> warn about "process.env.NODE_ENV" with identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/4e503ba2ada87da775d918d77e6ce035a51dce37"><code>4e503ba</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>: avoid a warning for "require.main"</li> <li><a href="https://github.com/evanw/esbuild/commit/3b049b2083a624fb287c96bef23c9fb8d41d3e9f"><code>3b049b2</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a></li> <li><a href="https://github.com/evanw/esbuild/commit/fe795c93f11811f3ab5020078a578d422021b2cc"><code>fe795c9</code></a> types: overload <code>build</code> definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/561">#561</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/2fa473e4c2f5374e066353c9d37bdc8afa8da734"><code>2fa473e</code></a> publish 0.8.15 to npm</li> <li>Additional commits viewable in <a href="https://github.com/evanw/esbuild/compare/v0.8.11...v0.8.16">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

+475 -475

0 comment

6 changed files

dependabot[bot]

pr closed time in a day

push eventasdf-vm/actions

Sora Morimoto

commit sha ca38b869a2d1adcbea666ab483bfac32e859a45b

yarn build Signed-off-by: Sora Morimoto <sora@morimoto.io>

view details

push time in a day

startedFairwindsOps/goldilocks

started time in a day

issue commentkubernetes/enhancements

kubectl drain additional features to support usage as library in controllers

@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>

michaelgugino

comment created time in a day

issue closedkubernetes/enhancements

kubectl drain additional features to support usage as library in controllers

Enhancement Description

  • One-line enhancement description (can be used as a release note): Add additional functionality to kubectl drain to support better usage as a library in controllers.
  • Kubernetes Enhancement Proposal: (link to kubernetes/enhancements file, if none yet, link to PR)
  • Primary contact (assignee):
  • Responsible SIGs: sig-cli
  • Enhancement target (which target equals to which milestone):
    • Alpha release target (x.y)
    • Beta release target (x.y)
    • Stable release target (x.y)

Apply/remove optional drain annotation during cordon/uncordon and drain command

It might be helpful to support apply a specific annotation (or perhaps a user supplied annotation) to a node when drained. Since there is no server-side indication that a node is about to be drained. Since a controller might cordon/drain and then uncordon a given node, this would be helpful to signal other components that a node is being drained. This could obviously be accomplished independently of the drain library, but it would also make a nice enhancement.

I don't view this one as an immediate need.

Updated: Implemented/Merged

Better support contexts

Currently, there is no support to pass in context to functions that make api calls and retry. We should support contexts so long-running processes can cancel these calls.

The easiest point of integration would be adding the context as a element of the DrainHelper type, but we'll need to figure out where to best handle the user passing in a context vs not passing in a context because drain exposes numerous public functions/methods. Alternatively, we could refactor the actual CLI client to pass in a context, and context could always be required in the public functions.

PR: https://github.com/kubernetes/kubernetes/pull/85574

New Option: Skip Wait For Delete

Alternative to "Unready Node Timeout". Simply add an option to ignore pods that have a DeletionTimeStamp > N seconds. It's up to the user to decide when this option is appropriate; examples include the Node is unready and the pods won't drain otherwise (as described in Unready Node Timeout)

PR: https://github.com/kubernetes/kubernetes/pull/85577

Update: Not going to implement/ Obsolete

New Option: Unready Node Timeout

When draining a node that is unready, PDBs will be respected as normal. Typically, all pods will be successfully evicted and deleted. However, some pods may be configured with 'local-storage.' Since the kubelet is not responsive, these pods never get cleaned up, even if eviction succeeds. We will wait for them to be deleted forever.

To work around this, we should add an option to drain that supports ignoring deleted pods after X seconds for unready nodes. This is very helpful to ensure you can properly drain a node and respect PDBs; otherwise the logic to detect this condition and work around it needs to replicate much of the drain code.

closed time in a day

michaelgugino

issue commentkubernetes/enhancements

kubectl drain additional features to support usage as library in controllers

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

michaelgugino

comment created time in a day

delete branch asdf-vm/actions

delete branch : dependabot/npm_and_yarn/esbuild-0.8.15

delete time in a day

PR closed asdf-vm/actions

Bump esbuild from 0.8.11 to 0.8.15 dependencies javascript

Bumps esbuild from 0.8.11 to 0.8.15. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">esbuild's releases</a>.</em></p> <blockquote> <h2>v0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> <p>With TypeScript 4.1, you can now omit <code>baseUrl</code> when using <code>paths</code>. When you do this, it as if you had written <code>"baseUrl": "."</code> instead for the purpose of the <code>paths</code> feature, but the <code>baseUrl</code> value is not actually set and does not affect path resolution. These <code>tsconfig.json</code> files are now supported by esbuild.</p> </li> <li> <p>Fix evaluation order issue with import cycles and CommonJS-style output formats (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/542">#542</a>)</p> <p>Previously entry points involved in an import cycle could cause evaluation order issues if the output format was <code>iife</code> or <code>cjs</code> instead of <code>esm</code>. This happened because this edge case was handled by treating the entry point file as a CommonJS file, which extracted the code into a CommonJS wrapper. Here's an example:</p> <p>Input files:</p> <pre lang="js"><code>// index.js import { test } from './lib' export function fn() { return 42 } if (test() !== 42) throw 'failure' </code></pre> <pre lang="js"><code>// lib.js import { fn } from './index' export let test = fn </code></pre> <p>Previous output (problematic):</p> <pre lang="js"><code>// index.js var require_esbuild = __commonJS((exports) => { __export(exports, { fn: () => fn2 }); function fn2() { return 42; } if (test() !== 42) throw "failure"; }); <p>// lib.js var index = __toModule(require_esbuild()); var test = index.fn; module.exports = require_esbuild(); </code></pre></p> <p>This approach changed the evaluation order because the CommonJS wrapper conflates both binding and evaluation. Binding and evaluation need to be separated to correctly handle this edge case. This edge case is now handled by inlining what would have been the contents of the CommonJS wrapper into the entry point location itself.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">esbuild's changelog</a>.</em></p> <blockquote> <h2>0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> <p>With TypeScript 4.1, you can now omit <code>baseUrl</code> when using <code>paths</code>. When you do this, it as if you had written <code>"baseUrl": "."</code> instead for the purpose of the <code>paths</code> feature, but the <code>baseUrl</code> value is not actually set and does not affect path resolution. These <code>tsconfig.json</code> files are now supported by esbuild.</p> </li> <li> <p>Fix evaluation order issue with import cycles and CommonJS-style output formats (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/542">#542</a>)</p> <p>Previously entry points involved in an import cycle could cause evaluation order issues if the output format was <code>iife</code> or <code>cjs</code> instead of <code>esm</code>. This happened because this edge case was handled by treating the entry point file as a CommonJS file, which extracted the code into a CommonJS wrapper. Here's an example:</p> <p>Input files:</p> <pre lang="js"><code>// index.js import { test } from './lib' export function fn() { return 42 } if (test() !== 42) throw 'failure' </code></pre> <pre lang="js"><code>// lib.js import { fn } from './index' export let test = fn </code></pre> <p>Previous output (problematic):</p> <pre lang="js"><code>// index.js var require_esbuild = __commonJS((exports) => { __export(exports, { fn: () => fn2 }); function fn2() { return 42; } if (test() !== 42) throw "failure"; }); <p>// lib.js var index = __toModule(require_esbuild()); var test = index.fn; module.exports = require_esbuild(); </code></pre></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/2fa473e4c2f5374e066353c9d37bdc8afa8da734"><code>2fa473e</code></a> publish 0.8.15 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/0b26f65889c0e4fb87b303ed1438045cf0caf006"><code>0b26f65</code></a> internal "ModuleName" => external "GlobalName"</li> <li><a href="https://github.com/evanw/esbuild/commit/2446da5dbde1670f647203324f769f069fc7dd87"><code>2446da5</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/542">#542</a>: cyclic imports with cjs-style output</li> <li><a href="https://github.com/evanw/esbuild/commit/1e182e7b7e0cc504467667d36b9bbde2d3429644"><code>1e182e7</code></a> implement "paths" without "baseUrl"</li> <li><a href="https://github.com/evanw/esbuild/commit/77e4ca0d9fd11a5a60f8529f57fb817ea501c35c"><code>77e4ca0</code></a> publish 0.8.14 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/a05d6ed03239728d9997b1f9e572b2c99b5e0e12"><code>a05d6ed</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/556">#556</a>: guard "ProbeResolvePackageAsRelative"</li> <li><a href="https://github.com/evanw/esbuild/commit/102c1f7c6ba0927a1c1ad17624f39629c6e6b485"><code>102c1f7</code></a> publish 0.8.13 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/0782ffa1bf06ecf32520d4aadee11cedbc78e18f"><code>0782ffa</code></a> replace "const" with "let" when minifying</li> <li><a href="https://github.com/evanw/esbuild/commit/611c7eb867531e244d8e59f309b6f7fea86fe492"><code>611c7eb</code></a> treat typescript "import" assignments as "const"</li> <li><a href="https://github.com/evanw/esbuild/commit/b295b9ea7f0783527d1dcf5f199264393d140d7d"><code>b295b9e</code></a> prevent assigning to "const" in for loops</li> <li>Additional commits viewable in <a href="https://github.com/evanw/esbuild/compare/v0.8.11...v0.8.15">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

+5 -5

1 comment

2 changed files

dependabot[bot]

pr closed time in a day

pull request commentasdf-vm/actions

Bump esbuild from 0.8.11 to 0.8.15

Superseded by #169.

dependabot[bot]

comment created time in a day

PR opened asdf-vm/actions

Bump esbuild from 0.8.11 to 0.8.16

Bumps esbuild from 0.8.11 to 0.8.16. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">esbuild's releases</a>.</em></p> <blockquote> <h2>v0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> <h2>v0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> <p>With TypeScript 4.1, you can now omit <code>baseUrl</code> when using <code>paths</code>. When you do this, it as if you had written <code>"baseUrl": "."</code> instead for the purpose of the <code>paths</code> feature, but the <code>baseUrl</code> value is not actually set and does not affect path resolution. These <code>tsconfig.json</code> files are now supported by esbuild.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">esbuild's changelog</a>.</em></p> <blockquote> <h2>0.8.16</h2> <ul> <li> <p>Improve TypeScript type definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a>)</p> <p>The return value of the <code>build</code> API has some optional fields that are undefined unless certain arguments are present. That meant you had to use the <code>!</code> null assertion operator to avoid a type error if you have the TypeScript <code>strictNullChecks</code> setting enabled in your project. This release adds additional type information so that if the relevant arguments are present, the TypeScript compiler can tell that these optional fields on the return value will never be undefined. This change was contributed by <a href="https://github.com/lukeed">@lukeed</a>.</p> </li> <li> <p>Omit a warning about <code>require.main</code> when targeting CommonJS (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>)</p> <p>A common pattern in code that's intended to be run in node is to check if <code>require.main === module</code>. That will be true if the current file is being run from the command line but false if the current file is being run because some other code called <code>require()</code> on it. Previously esbuild generated a warning about an unexpected use of <code>require</code>. Now this warning is no longer generated for <code>require.main</code> when the output format is <code>cjs</code>.</p> </li> <li> <p>Warn about defining <code>process.env.NODE_ENV</code> as an identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</p> <p>The define feature can be used to replace an expression with either a JSON literal or an identifier. Forgetting to put quotes around a string turns it into an identifier, which is a common mistake. This release introduces a warning when you define <code>process.env.NODE_ENV</code> as an identifier instead of a string. It's very common to use define to replace <code>process.env.NODE_ENV</code> with either <code>"production"</code> or <code>"development"</code> and sometimes people accidentally replace it with <code>production</code> or <code>development</code> instead. This is worth warning about because otherwise there would be no indication that something is wrong until the code crashes when run.</p> </li> <li> <p>Allow starting a local server at a specific host address (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/563">#563</a>)</p> <p>By default, esbuild's local HTTP server is only available on the internal loopback address. This is deliberate behavior for security reasons, since the local network environment may not be trusted. However, it can be useful to run the server on a different address when developing with esbuild inside of a virtual machine/docker container or to request development assets from a remote testing device on the same network at a different IP address. With this release, you can now optionally specify the host in addition to the port:</p> <pre><code>esbuild --serve=192.168.0.1:8000 </code></pre> <pre lang="js"><code>esbuild.serve({ host: '192.168.0.1', port: 8000, }, { ... }) </code></pre> <pre lang="go"><code>server, err := api.Serve(api.ServeOptions{ Host: "192.168.0.1", Port: 8000, }, api.BuildOptions{ ... }) </code></pre> <p>This change was contributed by <a href="https://github.com/jamalc">@jamalc</a>.</p> </li> </ul> <h2>0.8.15</h2> <ul> <li> <p>Allow <code>paths</code> without <code>baseUrl</code> in <code>tsconfig.json</code></p> <p>This feature was <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#paths-without-baseurl">recently released in TypeScript 4.1</a>. The <code>paths</code> feature in <code>tsconfig.json</code> allows you to do custom import path rewriting. For example, you can map paths matching <code>@namespace/</code> to the path <code>./namespace/src/</code> relative to the <code>tsconfig.json</code> file. Previously using the <code>paths</code> feature required you to additionally specify <code>baseUrl</code> so that the compiler could know which directory the path aliases were supposed to be relative to.</p> <p>However, specifying <code>baseUrl</code> has the potentially-problematic side effect of causing all import paths to be looked up relative to the <code>baseUrl</code> directory, which could potentially cause package paths to accidentally be redirected to non-package files. Specifying <code>baseUrl</code> also causes Visual Studio Code's auto-import feature to generate paths relative to the <code>baseUrl</code> directory instead of relative to the directory containing the current file. There is more information about the problems this causes here: <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/31869">microsoft/TypeScript#31869</a>.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/f4cec94deaa61e5bb9bd3c0d14ad37ead1d8ca55"><code>f4cec94</code></a> publish 0.8.16 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/7ba75db79fc0d328a3b4dc039c04b7ff142d31ef"><code>7ba75db</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a></li> <li><a href="https://github.com/evanw/esbuild/commit/f8eb7595e4b16f7e235941b39eac59234af92396"><code>f8eb759</code></a> make <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a> backward-compatible</li> <li><a href="https://github.com/evanw/esbuild/commit/0e356b1852aad23d25726b7ce5a9a0242bcb41c4"><code>0e356b1</code></a> support custom host in serve api (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/563">#563</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/8e9a4d5310c82cb1628af0eb0e903eb5a86f88ac"><code>8e9a4d5</code></a> release notes for "process.env.NODE_ENV" change</li> <li><a href="https://github.com/evanw/esbuild/commit/34c5305c174cb95dd2c01fe6f86ee90cfa6d33fc"><code>34c5305</code></a> warn about "process.env.NODE_ENV" with identifier (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/466">#466</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/4e503ba2ada87da775d918d77e6ce035a51dce37"><code>4e503ba</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/560">#560</a>: avoid a warning for "require.main"</li> <li><a href="https://github.com/evanw/esbuild/commit/3b049b2083a624fb287c96bef23c9fb8d41d3e9f"><code>3b049b2</code></a> release notes for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/559">#559</a></li> <li><a href="https://github.com/evanw/esbuild/commit/fe795c93f11811f3ab5020078a578d422021b2cc"><code>fe795c9</code></a> types: overload <code>build</code> definitions (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/561">#561</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/2fa473e4c2f5374e066353c9d37bdc8afa8da734"><code>2fa473e</code></a> publish 0.8.15 to npm</li> <li>Additional commits viewable in <a href="https://github.com/evanw/esbuild/compare/v0.8.11...v0.8.16">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

+5 -5

0 comment

2 changed files

pr created time in a day

create barnchasdf-vm/actions

branch : dependabot/npm_and_yarn/esbuild-0.8.16

created branch time in a day

pull request commentkubernetes/enhancements

KEP-0661: StatefulSet volume resize

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

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 rotten

kk-src

comment created time in 2 days

issue commentkubernetes/kubectl

describe output is broken if all annotations are skipped (last-applied-configuration)

@lalyos I get the error still in 1.18.12

lalyos

comment created time in 2 days

issue commentkubernetes/kubectl

`kubectl get ... --namespace non-existent` should not exit with 0

/remove-lifecycle rotten

wknapik

comment created time in 2 days

pull request commentkubernetes/enhancements

Add manifest bundle kep

@fejta-bot: Closed this PR.

<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>

ecordell

comment created time in 2 days

more