↓ Skip to main content
Containers

Vagrant-OSX

·1 min

In the previous blog, I was left with the error that had little information for me to debug. I realized since I migrated most of the files from my previous laptop it might be causing an issue.

So a shot in the dark helped me. In my home directory, I just moved the .vagrant.d to .old_vagrant.d and just reissued the commands and VOILA!

> vagrant up --provider=docker
Bringing machine 'default' up with 'docker' provider...
==> default: Creating and configuring docker networks...
==> default: Image is already built from the Dockerfile. `vagrant reload` to rebuild.
==> default: Vagrant has noticed that the synced folder definitions have changed.
==> default: With Docker, these synced folder changes won't take effect until you
==> default: destroy the container and recreate it.
==> default: Enabling network interfaces...
==> default: Starting container...

A quick check for the docker image execution

> docker ps -a
CONTAINER ID   IMAGE                  COMMAND                  CREATED        STATUS                      PORTS     NAMES
82a58adb9870   e6a0117ec169           "/bin/bash"              17 hours ago   Exited (0) 16 seconds ago             qemu-test_default_1660854015
Author
Samarthya
Engineer, learner, tinkerer. This is my trophy shelf of everyday work and leisure.

Related

Vagrant OSX

·4 mins
Having just bought an M1 – MacBook Pro the issue are mounting. The premier challenge was to get my Vagrant boxes configured with provider virtualbox to run. Since VirtualBox clearly calls it out “no support”

ServiceAccount

If you have seen errors like these when deploying using a serviceAccount Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: could not get information about the resource ConfigMap "spinnaker-hellow-pipline" in namespace "spinnaker": configmaps "spinnaker-hellow-pipline" is forbidden: User "system:serviceaccount:jenkins:default" cannot get resource "configmaps" in API group "" in the namespace "spinnaker" What? # A service account provides an identity for processes that run in a Pod. Every namespace has a default service account When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. To use a non-default service account, set the spec.serviceAccountName field of a pod to the name of the service account you wish to use. The service account has to exist at the time the pod is created, or it will be rejected. The service account of an already created pod cannot be updated Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant no permissions to service accounts outside the kube-system namespace (beyond discovery permissions given to all authenticated users). — Official documentation Example # apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: "2021-08-27T07:52:20Z" name: default namespace: default resourceVersion: "XXXX" uid: XXXX secrets: - name: default-token-vcb75 Let’s add docker-registry secret to the SA. (My secret name is samarthya-docker)