Saturday, November 9, 2019

kubernetes quotas

kubectl create namespace pippo
kubectl create quota myhq --hard=cpu=1,memory=1G,pods=2 --namespace=pippo
kubectl run --restart=Never busybox --image=busybox --namespace=pippo

Error from server (Forbidden): pods "busybox" is forbidden: failed quota: myhq: must specify cpu,memory

You can create your pod with requests and limits:

kubectl run --restart=Never busybox --image=busybox --namespace=pippo --limits=cpu=100m,memory=512Mi --requests=cpu=50m,memory=256Mi --dry-run -o yaml > mypod.yaml

  - image: busybox
    imagePullPolicy: IfNotPresent
    name: busybox
        cpu: 100m
        memory: 512Mi
        cpu: 50m
        memory: 256Mi

obviously all values in "requests" must be <= values in limits

busybox docker image

docker pull busybox
docker inspect busybox

if I see in the Config section (don't look at ContainerConfig ) the Cmd is simply "sh"

which means that if I do

kubectl run --restart=Never busybox -it --image=busybox

I simply get a shell.

If I create a pod who executes simply "env"

kubectl run --restart=Never busybox --image=busybox -- env

and then "inspect" it

kubectl get pod busybox -o yaml

I see that the container got the entry:

  - env

and since the "args" are simply appended to the default command defined in the container ("If you define args, but do not define a command, the default command is used with your new arguments.")... it's equivalent to specifying:

command: ["sh", "-c"]
args: ["env"]

don't forget the "-c", otherwise you get "sh: can't open 'env': No such file or directory"

NB: if with "kubectl run" you specify --command

kubectl run busybox --image=busybox --restart=Never --command -- env

then "command" instead of "args" will be generated:

  - command:
    - env
    image: busybox
    name: busybox

This aspect of containers/pods (how to run a command with arguments) is rather confusing and poorly engineered.

Thursday, November 7, 2019

JPA Parent child relationship

a quick reminder to myself:

if Post -> PostComment is a Unidirectional association (Post has a List<PostComments; but PostComment has no reference to Post),
then the insertion of each PostComment is done in two phases (INSERT + UPDATE who sets the parentId on the child table).
For this reason, the parentId column CANNOT BE DECLARED AS NOT NULL.

I don't like that.... ultimately that column should NEVER be null...

On the other hand, if you setup a full bidirectional relationship, only ONE insert is done, and you can keep parentId as NOT NULL.
To achieve that, you must explicitely set the Post attribute on the PostComment entity, before you persist/merge (I think, at least)