In Helm v3, the release name is now mandatory as part of the commmand, see `helm install --help`:

&gt; Usage:  
&gt;   helm install [NAME] [CHART] [flags]

**Your command should be**:

`helm install my-nginx stable/nginx-ingress`


----------


Furthermore, Helm will not auto-generate names for releases anymore. If you want the &quot;old behavior&quot;, you can use the `--generate-name` flag. e.g:

`helm install --generate-name stable/nginx-ingress`

The v3 docs are available at https://v3.helm.sh/docs/, but as it is a beta version, the docs will not be accurate for a while. It&#39;s better to rely on the CLI `--help`, that is auto-generated by Go/[Cobra](https://github.com/spf13/cobra).

The `--name` flag is no more in version 3.

It should be

    helm install my-nginx stable/nginx-ingress

**Syntax:**

&gt; help install [name] [chart]

I don&#39;t think the helm3 does support &quot;--name&quot; argument. As per the helm3 doc, the command to install a package and expected output is given down below:

    $ helm install happy-panda bitnami/wordpress
    NAME: happy-panda
    LAST DEPLOYED: Tue Jan 26 10:27:17 2021
    NAMESPACE: default
    STATUS: deployed
    REVISION: 1
    NOTES:
    ** Please be patient while the chart is being deployed **
Here &quot;happy-panda&quot; is the name of the release and &quot;bitnami/wordpress&quot; is the name of the chart. Also you can generate name for the release by using 
```--generate-name``` flag.

As others have mentioned, there is no `--name` flag in version 3 of Helm. Also, Helm v3 comes without `stable` repository setup by default. The best way to discover a chart by searching the [Artifact Hub][1]. Once you find the repo, which hosts the chart you are looking for, you need to add the repo as:

    helm repo add nginx-stable https://helm.nginx.com/stable

And then you can install chart 

    helm install my-nginx nginx-stable/nginx-ingress


  [1]: https://artifacthub.io/

As name was made compulsory in helm3, 
if we do `helm repo --help`,

    help install [name] [chart]

If the chart was not present,
1. use `helm repo add &lt;name&gt; &lt;url&gt;`
2. then use `helm install` 

There&#39;s a previous question [Can&#39;t compile C program on a Mac after upgrade to Mojave](https://stackoverflow.com/questions/52509602/cant-compile-c-program-on-a-mac-after-upgrade-to-mojave), and the answers to that have covered most of the variations on what goes wrong.

Now — as of Monday 2019-10-07 — you can upgrade to macOS Catalina 10.15.  Once again, during the upgrade, the `/usr/include` directory has been blown away by the update, even though XCode 11.0 was installed before upgrading (from Mojave 10.14.6) to Catalina.  Consequently, compilers built to expect that there is a `/usr/include` directory do not work any longer.

The main recommended step for the Mojave issues — using the command:

&gt;     open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

does not work out of the gate because the directory `/Library/Developer/CommandLineTools/Packages/` does not exist (so there&#39;s not yet a `.pkg` file to open).

Is there a good (official) way to create and populate the directory `/usr/include`?

Can&#39;t compile a C program on a Mac after upgrading to Catalina 10.15

I use ESLint in all of my TypeScript projects with the following settings:

      &quot;extends&quot;: [&quot;airbnb&quot;, &quot;prettier&quot;, &#39;plugin:vue/recommended&#39;],
      &quot;plugins&quot;: [&quot;prettier&quot;],
      &quot;parserOptions&quot;: {
      &quot;parser&quot;: &quot;@typescript-eslint/parser&quot;,
      &quot;ecmaVersion&quot;: 2018,
      &quot;sourceType&quot;: &quot;module&quot;
      },
+ a bunch of custom rules. I&#39;ve also installed the following dependencies for TypeScript support:

        &quot;@typescript-eslint/eslint-plugin&quot;: &quot;^1.7.0&quot;,
        &quot;@typescript-eslint/parser&quot;: &quot;^1.7.0&quot;,

However, one of ESLint&#39;s most useful rules, https://eslint.org/docs/rules/no-unused-vars, seems to be very poorly configured for TypeScript projects. For example, when I export an enum, the rule warns me that the enum isn&#39;t in use in the file where it is declared:

    export enum Foo {
       Bar,
    }

Similarly, when I import an interface or class to be used as a type, &#39;no-unused-vars&#39; will complain again on the the line of the actual import:

*In Foo.ts*

    export interface Foo {
       bar: string;
    }

*In bar.ts*

    import { Foo } from &#39;./Foo&#39;
    const bar: Foo = { bar: &#39;Hello&#39; };

Is there any way to configure the no-unused-vars rule to take these two cases into account? I&#39;m not a fan of disabling the rule, as it is one of the most helpful rules in my entire ruleset outside of these cases.

I&#39;ve already downgraded the rule to only give a warning instead of an error, but having all my documents filled with warnings still kind of defeats the purpose of using esLint.

Filling my all my documents with //eslint-disable-line as suggested [here][1] also seems like a bad solution.

  [1]: https://stackoverflow.com/questions/55039931/standardjs-no-unused-vars-while-its-used/55239941

ESLint - Configuring &quot;no-unused-vars&quot; for TypeScript

When I try to install a chart with helm:

    helm install stable/nginx-ingress --name my-nginx

I get the error: 

&gt; Error: unknown flag: --name

But I see the above command format in many documentations. 

Version: 

&gt; version.BuildInfo{Version:&quot;v3.0.0-beta.3&quot;,
&gt; GitCommit:&quot;5cb923eecbe80d1ad76399aee234717c11931d9a&quot;,
&gt; GitTreeState:&quot;clean&quot;, GoVersion:&quot;go1.12.9&quot;}

Platform: Windows 10 64

What could be the reason?

Helm install unknown flag --name

When I try to install a chart with helm:
<pre><code class="hljs language-bash">helm install stable/nginx-ingress --name my-nginx
</code></pre>
I get the error:
> Error: unknown flag: --name
But I see the above command format in many documentations.
Version:
> version.BuildInfo{Version:"v3.0.0-beta.3",
> GitCommit:"5cb923eecbe80d1ad76399aee234717c11931d9a",
> GitTreeState:"clean", GoVersion:"go1.12.9"}
Platform: Windows 10 64
What could be the reason?

I have been trying to install nginx ingress using helm version 3

    helm install my-ingress stable/nginx-ingress

But Helm doesn&#39;t seem to be able to find it&#39;s official `stable` repo. It gives the message: 

&gt; Error: failed to download &quot;stable/nginx-ingress&quot; (hint: running `helm
&gt; repo update` may help)


---

I tried `helm repo update`. But it doesn&#39;t help.

I tried listing the repos `helm repo list` but it is empty.


---


I tried to add the stable repo: 

    helm repo add stable https://github.com/helm/charts/tree/master/stable

But it fails with: 

&gt; Error: looks like &quot;https://github.com/helm/charts/tree/master/stable&quot;
&gt; is not a valid chart repository or cannot be reached: failed to fetch
&gt; https://github.com/helm/charts/tree/master/stable/index.yaml : 404 Not
&gt; Found

Helm V3 - Cannot find the official repo

I am building the Dockerfile for python script which will run in minikube windows 10 system below is my Dockerfile



Building the docker using the below command
```docker build -t python-helloworld . ```

and loading that in minikube docker demon
```docker save python-helloworld | (eval $(minikube docker-env) &amp;&amp; docker load)```

Docker File



```
FROM python:3.7-alpine
#add user group and ass user to that group
RUN addgroup -S appgroup &amp;&amp; adduser -S appuser -G appgroup

#creates work dir	
WORKDIR /app

#copy python script to the container folder app
COPY helloworld.py /app/helloworld.py

#user is appuser
USER appuser

ENTRYPOINT  [&quot;python&quot;, &quot;/app/helloworld.py&quot;]
```	


 pythoncronjob.yml file (cron job file)
 
```
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: python-helloworld
spec:
  schedule: &quot;*/1 * * * *&quot;
  jobTemplate:
    spec:
      backoffLimit: 5
      template:
        spec:
          containers:
          - name: python-helloworld
            image: python-helloworld
            imagePullPolicy: IfNotPresent
            command: [/app/helloworld.py]
          restartPolicy: OnFailure
```

Below is the command to run this Kubernetes job
```kubectl create -f pythoncronjob.yml```


But getting the below  error job is not running scuessfully but when u ran the Dockerfile alone its work fine 

standard_init_linux.go:211: exec user process caused &quot;exec format error&quot;

standard_init_linux.go:211: exec user process caused &quot;exec format error&quot;

While deploying mojaloop, Kubernetes responds with the following errors:  

&gt; Error: validation failed: [unable to recognize &quot;&quot;: no matches for kind
&gt; &quot;Deployment&quot; in version &quot;apps/v1beta2&quot;, unable to recognize &quot;&quot;: no
&gt; matches for kind &quot;Deployment&quot; in version &quot;extensions/v1beta1&quot;, unable
&gt; to recognize &quot;&quot;: no matches for kind &quot;StatefulSet&quot; in version
&gt; &quot;apps/v1beta2&quot;, unable to recognize &quot;&quot;: no matches for kind
&gt; &quot;StatefulSet&quot; in version &quot;apps/v1beta1&quot;]



My Kubernetes version is 1.16.  
How can I fix the problem with the API version?  
From investigating, I have found that Kubernetes doesn&#39;t support apps/v1beta2, apps/v1beta1.  
How can I make Kubernetes use a not deprecated version or some other supported version?  
 
I am new to Kubernetes and anyone who can support me I am happy 



no matches for kind &quot;Deployment&quot; in version &quot;extensions/v1beta1&quot;

I need to configure Ingress Nginx on azure k8s, and my question is if is possible to have ingress configured in one namespace et. ingress-nginx and some serivces in other namespace eg. resources?
My files looks like so:

```
# ingress-nginx.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ingress-nginx
  template:
    metadata:
      labels:
        app: ingress-nginx
      annotations:
        prometheus.io/port: &#39;10254&#39;
        prometheus.io/scrape: &#39;true&#39; 
    spec:
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.12.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
          - name: http
            containerPort: 80
          - name: https
            containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
```

``` 
# configmap.yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
---
# default-backend.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app: default-http-backend
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: default-http-backend
  template:
    metadata:
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissible as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: gcr.io/google_containers/defaultbackend:1.4
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: default-http-backend

```

```
kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
spec:
  externalTrafficPolicy: Local
  type: LoadBalancer
  selector:
    app: ingress-nginx
  ports:
  - name: http
    port: 80
    targetPort: http
  - name: https
    port: 443
    targetPort: https
```

```
        # app-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app-ingress
  namespace: ingress-nginx
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - api-sand.fake.com
  rules:
  - host: api-sand.fake.com
    http:
      paths:
      - backend:
          serviceName: api-sand
          servicePort: 80
        path: /

```

And then I have some app running in the **resources namespace**, and problem is that I am getting the following error 
```
error obtaining service endpoints: error getting service resources/api-sand from the cache: service resources/api-sand was not found

```
If I deploy api-sand in the same namespace where ingress is then this service works fine.

Ingress configuration for k8s in different namespaces

I have been using the Kubernetes and Helm for a while and have now come across Kustomize for the first time.

*But what exactly is the difference between Kustomize and Helm?*

Are both simply different solutions for bundling K8s elements such as services, deployments, ...? Or does it make sense to use both Helm and Kustomize together?

What is the difference between Helm and Kustomize?

I tried to run a Helm upgrade before running `helm repo update` and now it seems to be permanently stuck in &quot;STATUS: pending-upgrade&quot; and won&#39;t let me try to run the upgrade again.

Trying to run:
`helm upgrade --namespace coder --install --force --atomic --wait --version 1.13.2 --values ./coder.yaml coder coder/coder`

outputs: `Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress`

Content Type	Original Author	Original Content on Stackoverflow
Question	Charlie	View Question on Stackoverflow
Solution 1 - Kubernetes	Eduardo Baitello	View Answer on Stackoverflow
Solution 2 - Kubernetes	Charlie	View Answer on Stackoverflow
Solution 3 - Kubernetes	Dipto Mondal	View Answer on Stackoverflow
Solution 4 - Kubernetes	Pankaj	View Answer on Stackoverflow
Solution 5 - Kubernetes	Kailash 1999	View Answer on Stackoverflow

Helm install unknown flag --name

Kubernetes Problem Overview

Kubernetes Solutions

Solution 1 - Kubernetes

Solution 2 - Kubernetes

Solution 3 - Kubernetes

Solution 4 - Kubernetes

Solution 5 - Kubernetes

ESLint - Configuring "no-unused-vars" for TypeScript

Can't compile a C program on a Mac after upgrading to Catalina 10.15

Attributions