Closed raghavanv90 closed 3 years ago
Same problem here on Debian 9. The strange thing is that neither pharos-cluster nor jakolehm/cfssl
have been updated recently and it was working last week.
For the moment the workaround seems to be to manually run
sudo mkdir /opt/pharos
on the master(s)
I am experiencing the same issue on 3 newly installed CentOS 7.8 machines.
Below is the pharos up
command in debug mode.
...
10.6.70.11: + ctr -n pharos image pull docker.io/jakolehm/cfssl:0.1.1
10.6.70.11: docker.io/jakolehm/cfssl:0.1.1: resolving |--------------------------------------|
## OUTPUT OMITTED ##
10.6.70.11: docker.io/jakolehm/cfssl:0.1.1: resolved |++++++++++++++++++++++++++++++++++++++|
## OUTPUT OMITTED ##
10.6.70.11: elapsed: 1.6 s total: 0.0 B (0.0 B/s)
10.6.70.11: unpacking linux/amd64 sha256:060f8665eb7a898674ca59bd38366f04ffab7393efae6151534cb0603b2fb078...
10.6.70.11: done
10.6.70.11: + ctr -n pharos install --path /opt/pharos --replace docker.io/jakolehm/cfssl:0.1.1
10.6.70.11: ctr: mkdir /opt/pharos/bin: no such file or directory
10.6.70.11: ! 1
[node01] Error: exec failed with code 1: configure-cfssl.sh
...
https://github.com/kontena/pharos-cluster/blob/master/lib/pharos/host/el7/scripts/configure-cfssl.sh
Maybe there's breaking changes to ctr
?
Maybe the --path
option used to create the directory if it did not exist. But doesn't any more.
DESCRIPTION:
ctr is an unsupported debug and administrative client for interacting
with the containerd daemon. Because it is unsupported, the commands,
options, and operations are not guaranteed to be backward compatible or
stable from release to release of the containerd project.
I can confirm.
ctr
from v1.3.0 and up does not create the missing directory, if it does not exist. I created a pull request.
@rwunderer yeah workaround seems to solve the issue However observing other issue after manually creating "sudo mkdir /opt/pharos" - Opened https://github.com/kontena/pharos-cluster/issues/1559, are you facing the same?
Fixed in #1556
Following the directions on the site I hit this problem today still. Its seems like your fix has been applied, is there a new iteration of the same bug or have has it not reached the latest release/documentation?
Ok well I guess the problem is that it is fixed in pharos 3.2.2 and current is still 3.2.1 as of installing using chpharos today. Could that get pushed?
When I try to deploy the k8s cluster it fails with a below error, Environment: VMs - Tried it on both versions - CentOS Linux release 7.4.1708 (Core) & CentOS Linux release 7.8.2003 (Core) pharos 3.2.1 chpharos 0.6.2
`ERROR: Pharos::PhaseManager::Error : Phase failed on 1 host:
[root@localhost ~]# cat cluster.yml hosts:
see all supported options: https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md
load-balance: least_conn cert-manager: enabled: true issuer: name: letsencrypt-staging server: https://acme-staging-v02.api.letsencrypt.org/directory email: xxxx.com host-upgrades: enabled: true schedule: "30 6 *" schedule_window: 1h reboot: true
interval: 7d
kontena-storage: enabled: true data_dir: /var/lib/kontena-storage storage: use_all_nodes: true pool: replicated: size: 3 dashboard: enabled: true filesystem: enabled: true pool: replicated: size: 3 kontena-backup: enabled: false cloud_credentials: /path/to/aws_credentials aws: bucket: pharos-backups region: eu-central-1 kontena-lens: enabled: true name: 'pharos-cluster' ingress: host: 'mycluster.local' tls: enabled: true email: 'xxxx.com' user_management: enabled: true persistence: enabled: true charts: enabled: true repositories: