Persistence Volume Stuck at terminating

Sometimes, PV and PVC could stuck at terminating. This is because there is a finalizer to protect the PV and PVC termination while there are still possible usage.

For example, when I am trying to delete the PV

both PV and PVC however are stuck for quite a while

the resolution is to edit and remove the finalizers:

then without the finalizers, it will let the PV and PVC termination.

kubernetes endpoints

endpoints is normally used behind the scene, without the need of any manual intervention.

However, for local testing, it could become helpful to leverage on the endpoints customization.

---	
  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "svc-to-external-web"
  spec:
    ports:
      - name: "apache"
        protocol: "TCP"
        port: 80
        targetPort: 80 
---
  kind: "Endpoints"
  apiVersion: "v1"
  metadata:
    name: "svc-to-external-web" 
  subsets: 
    - addresses:
        - ip: "8.8.8.8" #The IP Address of the external web server
        ports:
        - port: 80 
          name: "apache"

for example, with above, if we create a service without any selector (of any pods/deployments), and manually create an endpoint with the same name as the service, then we can configure where the endpoint point to, which could be an external IP address, or maybe to a docker service

like

apiVersion: v1
kind: Endpoints
metadata:
  name: svc-to-external-web
subsets:
- addresses:
  - ip: 192.168.64.1 # minikube ssh "route -n | grep ^0.0.0.0 | awk '{ print \$2 }'"
  ports:
  - port: 80

ref: https://theithollow.com/2019/02/04/kubernetes-endpoints/

pod stuck at pending with custom scheduler

i have created a custom scheduler, which has been in running state.

however, when i create a new pod, assigning it to the custom scheduler, through .spec.schedulerName. the pod has been stuck in pending state.


here are the sample configuration

scheduler.yml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-scheduler
    tier: control-plane
  name: my-scheduler
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=true
    - --port=10351
    - --scheduler-nam=my-scheduler
    - --secure-port=10359
    image: k8s.gcr.io/kube-scheduler:v1.16.0
    imagePullPolicy: IfNotPresent

pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  schedulerName: my-scheduler
  containers:
  -  image: nginx
     name: nginx

turns out the issue was with the --leader-elect. seems like the scheduler is not able to move forward with the --leader-elect set to true.

error running etcd in minikube

when I am trying to run etcdctl in minikube, there has been an exception:

commands:

ETCDCTL_API=3 etcdctl get "" --prefix=true
ETCDCTL_API=3 etcdctl get "" --from-key

Exception

{"level":"warn","ts":"2020-05-01T09:32:07.933Z","caller":"clientv3/retry_interceptor.go:61","msg":"retrying of unary invoker failed","target":"endpoint://client-ea0c78af-0a9d-4092-8722-75fed707e112/127.0.0.1:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest connection error: connection closed"}
Error: context deadline exceeded

the solution is to provide the needed ca files

ETCDCTL_API=3 etcdctl get "" --prefix=true --cacert=/var/lib/minikube/certs/etcd/ca.crt --cert=/var/lib/minikube/certs/etcd/server.crt --key=/var/lib/minikube/certs/etcd/server.key

the cert can be found by running

kubectl get pod etcd-minikube -n kube-system -o yaml

babel 7 with typescript

according to this post, https://devblogs.microsoft.com/typescript/typescript-and-babel-7/, it seems like babel 7 should work with typescript.

however, i have encountered quite a lot surprises during the integration.

here are the changes I have done:

install the typescript preset

yarn add --dev @babel/preset-typescript @babel/preset-env @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread

then configure babel.config.json

(most importantly, i have a "macro" plugin, that’s the reason I would like to switch from tsc to babel as i would like to leverage on the macros)

{
  "presets": [
    "@babel/env",
    "@babel/preset-typescript"
  ],
  "plugins": [
    "@babel/proposal-class-properties",
    "@babel/proposal-object-rest-spread",
    "macros"
  ],
  "ignore": [
    "node_modules"
  ]
}

then in package.json, add these scripts

    "build": "babel . -d lib --extensions '.ts,.tsx'",
    "apprun": "babel-node --extensions '.ts,.tsx' index.ts",
    "rundev": "build && nodemon lib/app/app.js",
    "runProd": "build && node lib/app/app.js"

babel-node is working fine.

however, the babel built output seems quite often is not complete.

for once, it complains transpiled graphql_macro_1 is not defined, as this line is missing from the generated javascript file:

const graphql_macro_1 = require("graphql.macro");

then at this moment, it’s complaining this line

as this variable, regeneratorRuntime is called but looks like nowhere it has been defined in the generate javascript file.

this is the complete package.json, with the relevant packages and scripts

{
  "name": "frontend",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
....
    "graphql": "^15.0.0",
    "graphql.macro": "^1.4.2",
...
  },
  "scripts": {
...
    "build": "babel . -d lib --extensions '.ts,.tsx'",
    "apprun": "babel-node --extensions '.ts,.tsx' index.ts",
    "rundev": "build && nodemon lib/app/app.js",
    "runProd": "build && node lib/app/app.js"
  },
  "devDependencies": {
    "@babel/cli": "^7.8.4",
    "@babel/core": "^7.9.0",
    "@babel/node": "^7.8.7",
    "@babel/plugin-proposal-class-properties": "^7.8.3",
    "@babel/plugin-proposal-export-default-from": "^7.8.3",
    "@babel/plugin-proposal-export-namespace-from": "^7.8.3",
    "@babel/plugin-proposal-object-rest-spread": "^7.9.5",
    "@babel/preset-env": "^7.9.5",
    "@babel/preset-flow": "^7.9.0",
    "@babel/preset-typescript": "^7.9.0",
    "babel-watch": "^7.0.0",
...
  }
}

vs https://www.typescriptlang.org/docs/handbook/compiler-options.html, tsc is doing much better job. the only caveat is, it cannot generate the necessary babel macros.

ref:

https://babeljs.io/docs/en/babel-preset-typescript#docsNav

https://iamturns.com/typescript-babel/

the original post from microsoft below

Today we’re excited to announce something special for Babel users.Over a year ago, we set out to find what the biggest difficulties users were running into with TypeScript, and we found that a common theme among Babel users was that trying to get TypeScript set up was just too hard. The reasons often varied, but for a lot of developers, rewiring a build that’s already working can be a daunting task.

Babel is a fantastic tool with a vibrant ecosystem that serves millions of developers by transforming the latest JavaScript features to older runtimes and browsers; but it doesn’t do type-checking, which our team believes can bring that experience to another level. While TypeScript itself can do both, we wanted to make it easier to get that experience without forcing users to switch from Babel.

That’s why over the past year we’ve collaborated with the Babel team, and today we’re happy to jointly announce that Babel 7 now ships with TypeScript support!

How do I use it?

If you’re already using Babel and you’ve never tried TypeScript, now’s your chance because it’s easier than ever. At a minimum, you’ll need to install the TypeScript plugin.

npm install --save-dev @babel/preset-typescript

Though you’ll also probably want to get the other ECMAScript features that TypeScript supports:

npm install --save-dev @babel/preset-typescript @babel/preset-env @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread

Make sure your .babelrc has the right presets and plugins:

{
    "presets": [
        "@babel/env",
        "@babel/preset-typescript"
    ],
    "plugins": [
        "@babel/proposal-class-properties",
        "@babel/proposal-object-rest-spread"
    ]
}

For a simple build with @babel/cli, all you need to do is run

babel ./src --out-dir lib --extensions ".ts,.tsx"

Your files should now be built and generated in the lib directory.

To add type-checking with TypeScript, create a tsconfig.json file

{
  "compilerOptions": {
    // Target latest version of ECMAScript.
    "target": "esnext",
    // Search under node_modules for non-relative imports.
    "moduleResolution": "node",
    // Process & infer types from .js files.
    "allowJs": true,
    // Don't emit; allow Babel to transform files.
    "noEmit": true,
    // Enable strictest settings like strictNullChecks & noImplicitAny.
    "strict": true,
    // Disallow features that require cross-file information for emit.
    "isolatedModules": true,
    // Import non-ES modules as default imports.
    "esModuleInterop": true
  },
  "include": [
    "src"
  ]
}

and just run

tsc

and that’s it! tsc will type-check your .ts and .tsx files.

Feel free to add the --watch flag to either tool to get immediate feedback when anything changes. You can see how to set up a more complex build on this sample repository which integrates with tools like Webpack. You can also just play around with the TypeScript preset on Babel’s online REPL.

What does this mean for me?

Using the TypeScript compiler is still the preferred way to build TypeScript. While Babel can take over compiling/transpiling – doing things like erasing your types and rewriting the newest ECMAScript features to work in older runtimes – it doesn’t have type-checking built in, and still requires using TypeScript to accomplish that. So even if Babel builds successfully, you might need to check in with TypeScript to catch type errors. For that reason, we feel tsc and the tools around the compiler pipeline will still give the most integrated and consistent experience for most projects.

So if you’re already using TypeScript, maybe this doesn’t change much for you. But if you’re already using Babel, or interested in the Babel ecosystem, and you want to get the benefits of TypeScript like catching typos, error checking, and the editing experiences you might’ve seen in the likes of Visual Studio and Visual Studio Code, this is for you!

Caveats

As we mentioned above, the first thing users should be aware of is that Babel won’t perform type-checking on TypeScript code; it will only be transforming your code, and it will compile regardless of whether type errors are present. While that means Babel is free from doing things like reading .d.ts files and ensuring your types are compatible, presumably you’ll want some tool to do that, and so you’ll still need TypeScript. This can be done as a separate tsc --watch task in the background, or it can be part of a lint/CI step in your build. Luckily, with the right editor support, you’ll be able to spot most errors before you even save.

Second, there are certain constructs that don’t currently compile in Babel 7. Specifically,

  • namespaces
  • bracket style type-assertion/cast syntax regardless of when JSX is enabled (i.e. writing <Foo>x won’t work even in .ts files if JSX support is turned on, but you can instead write x as Foo).
  • enums that span multiple declarations (i.e. enum merging)
  • legacy-style import/export syntax (i.e. import foo = require(...) and export = foo)

These omissions are largely based technical constraints in Babel’s single-file emit architecture. We believe that most users will find this experience to be totally acceptable. To make sure that TypeScript can call out some of these omissions, you should ensure that TypeScript uses the --isolatedModules flag.

What next?

You can read up on the details from the Babel side on their release blog post. We’re happy that we’ve had the chance to collaborate with folks on the Babel team like Henry Zhu, Andrew Levine, Logan Smyth, Daniel Tschinder, James Henry, Diogo Franco, Ivan Babak, Nicolò Ribaudo, Brian Ng, and Vladimir Kurchatkin. We even had the opportunity to speed up Babylon, Babel’s parser, and helped align with James Henry’s work on typescript-eslint-parser which now powers Prettier’s TypeScript support. If we missed you, we’re sorry but we’re grateful and we appreciate all the help people collectively put in!

Our team will be contributing to future updates in the TypeScript plugin, and we look forward to bringing a great experience to all TypeScript users. Going forward, we’d love to hear your feedback about this new TypeScript support in Babel, and how we can make it even easier to use. Give us a shout on Twitter at @typescriptlang or in the comments below.

Happy hacking!

docker compose timeout

I was not able to run my `docker-compose` commands earlier:

for example dcd up

dcd ps


after turning on –verbose, dcd --verbose ps, turns out the issue is with one of the containers:

This is a front end container, which also explains why I am not able to hot reload the pages, even though I already have the volume mount.

and in case, docker kill is also not working, then do a restart of docker, followed by docker stop and docker rm

Update yarn indirect dependencies

It’s common that some indirect dependencies are deprecated due to some vulnerability issues. for example,

I have multiple indirect dependencies on `kind-of`

which are being used by various other dependencies (direct and indirect)



which recently found out there is an isuse with `kind-of`

https://github.com/advisories/GHSA-6c8f-qphg-qjgp

and to update this indirect dependencies, the solution is to add a solution block in package.json

after that, then just run `yarn`

it will update the dependencies to correct version

refer to https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

https://itnext.io/fixing-security-vulnerabilities-in-npm-dependencies-in-less-than-3-mins-a53af735261d