I am trying to add a osd node by following command
ceph-deploy osd prepare ceph-02:/dev/sdb
Found error that config file /etc/ceph/ceph.conf exists
with different content. used --overwrite-conf to overwrite.
How do I use overwrite-conf?
Error log:
[ceph_deploy.osd][INFO ] Distro info: CentOS Linux 7.4.1708 Core
[ceph_deploy.osd][DEBUG ] Deploying osd to ceph-02
[ceph-02][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
[ceph_deploy.osd][ERROR ] RuntimeError: config file /etc/ceph/ceph.conf exists
with different content; use --overwrite-conf to overwrite
[ceph_deploy][ERROR ] GenericError: Failed to create 1 OSDs
This is a normal behavior for a ceph-deploy command. Just run ceph-deploy --overwrite-conf osd prepare ceph-02:/dev/sdb. This will replace your existing /etc/ceph/ceph.conf.
This will resolve your issue.
Related
For test purposes, I'm trying to connect a module that intoduces an absration layer over s3fs with custom business logic.
It seems like I have trouble connecting the s3fs client to the Minio container.
Here's how I created the the container and attach the s3fs client (below describes how I validated the container is running properly)
import s3fs
import docker
client = docker.from_env()
container = client.containers.run('minio/minio',
"server /data --console-address ':9090'",
environment={
"MINIO_ACCESS_KEY": "minio",
"MINIO_SECRET_KEY": "minio123",
},
ports={
"9000/tcp": 9000,
"9090/tcp": 9090,
},
volumes={'/tmp/minio': {'bind': '/data', 'mode': 'rw'}},
detach=True)
container.reload() # why reload: https://github.com/docker/docker-py/issues/2681
fs = s3fs.S3FileSystem(
anon=False,
key='minio',
secret='minio123',
use_ssl=False,
client_kwargs={
'endpoint_url': "http://localhost:9000" # tried 127.0.0.1:9000 with no success
}
)
===========
>>> fs.ls('/')
[]
>>> fs.ls('/data')
Bucket doesnt exists exception
check that the container is running:
➜ ~ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
127e22c19a65 minio/minio "/usr/bin/docker-ent…" 56 seconds ago Up 55 seconds 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp hardcore_ride
check that the relevant volume is attached:
➜ ~ docker exec -it 127e22c19a65 bash
[root#127e22c19a65 /]# ls -l /data/
total 4
-rw-rw-r-- 1 1000 1000 4 Jan 11 16:02 foo.txt
[root#127e22c19a65 /]# exit
Since I proved the volume binding is working properly by shelling into the container, I expected to see the same results when attached the container's filesystem via the s3fs client.
What is the bucket name that was created as part of this setup?
From the docs I'm seeing you have to give <bucket_name>/<object_path> syntax to access the resources.
fs.ls('my-bucket')
['my-file.txt']
Also if you look at the docs below there are a couple of other ways to access it using fs.open can you give that a try?
https://buildmedia.readthedocs.org/media/pdf/s3fs/latest/s3fs.pdf
I am having the time out issue while starting up my cluster dashboard with
microk8s dashboard-proxy
This issue occurs again and again in my kubernate cluster. I don't really know the cause of it.
error: timed out waiting for the condition on deployments/kubernetes-dashboard
Traceback (most recent call last):
File "/snap/microk8s/1609/scripts/wrappers/dashboard-proxy.py", line 50, in <module>
dashboard_proxy()
File "/snap/microk8s/1609/scripts/wrappers/dashboard-proxy.py", line 13, in dashboard_proxy
check_output(command)
File "/snap/microk8s/1609/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
File "/snap/microk8s/1609/usr/lib/python3.5/subprocess.py", line 708, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['microk8s.kubectl', '-n', 'kube-system', 'wait', '--timeout=240s', 'deployment', 'kubernetes-dashboard', '--for', 'condition=available']' returned non-zero exit status 1
I am running a kubernate cluster on vagrant machines(Centos) using microk8s. This issue can be cause by many raisons. Bellow is some of them;
Leak of memory
To fix: you need to increase memory within you vagrant machines settings
some thing went wrong during you microk8s installation
To fix : remove microk8s and reinstall it. In my case I use snap to install it. This is how I did
snap remove microk8s --purge
snap install microk8s --classic --channel=1.18/stable
some time you need to kill the process and restart you vagrant machine. In my case I did
lsof -Pi:10443 where 10443 on which my dashboard is running
kill -9 xxxx where xxxx is the PID retrieved from the previous command
I am trying to setup an LXC container (debian) as a Kubernetes node.
I am so far that the only thing in the way is the kubeadm init script...
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR SystemVerification]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.44-2-pve/modules.dep.bin'\nmodprobe: FATAL: Module configs not found in directory /lib/modules/5.4.44-2-pve\n", err: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
After some research I figured out that I probably need to add the following: linux.kernel_modules: ip_tables,ip6_tables,netlink_diag,nf_nat,overlay
But adding this to /etc/pve/lxc/107.conf doesn't do anything.
Does anybody have a clue how to add the linux kernel modules?
To allow load with modprobe any modules inside privileged proxmox lxc container, you need add this options to container config:
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:
lxc.mount.auto: proc:rw sys:rw
lxc.mount.entry: /lib/modules lib/modules none bind 0 0
before that, you must first create the /lib/modules folder inside the container
I'm not sure what guide you are following but assuming that you have the required kernel modules on the host, this would do it:
lxc config set my-container linux.kernel_modules overlay
You can follow this guide from K3s too. Basically:
lxc config edit k3s-lxc
and
config:
linux.kernel_modules: ip_tables,ip6_tables,netlink_diag,nf_nat,overlay
raw.lxc: lxc.mount.auto=proc:rw sys:rw
security.privileged: "true"
security.nesting: "true"
✌️
For the fix ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file run from the host:
pct set $VMID --mp0 /usr/lib/modules/$(uname -r),mp=/lib/modules/$(uname -r),ro=1,backup=0
For the fix [ERROR SystemVerification]: failed to parse kernel config run from the host:
pct push $VMID /boot/config-$(uname -r) /boot/config-$(uname -r)
Where $VMID is your container id.
building a master localy.
I am trying to use /kubernetes/docs/getting-started-guides/docker-multinode/master.sh
master is done!
some detail imformation:
K8S_VERSION is set to: 1.2.4
ETCD_VERSION is set to: 2.2.1
FLANNEL_VERSION is set to: 0.5.5
FLANNEL_IFACE is set to: wlan0
FLANNEL_IPMASQ is set to: true
MASTER_IP is set to: 192.168.1.104
ARCH is set to: amd64
Detecting your OS distro ...
Starting bootstrap docker ...
Starting k8s ...
4fa730ca61727c165345885639cbef4d5a34b5d0fa3a361c13b0abc3ead0dd58
{ "Network": "10.1.0.0/16", "Backend": {"Type": "vxlan"}}
vDOCKER_OPTS="$DOCKER_OPTS --mtu=1450 --bip=10.1.48.1/24"
next add a vagrant virtualbox slave to master.
trying to use /kubernetes/docs/getting-started-guides/docker-multinode/worker.sh it bring some issue:
K8S_VERSION is set to: 1.2.4
FLANNEL_VERSION is set to: 0.5.5
FLANNEL_IFACE is set to: wlan0
FLANNEL_IPMASQ is set to: true
MASTER_IP is set to: 192.168.1.104
ARCH is set to: amd64
Detecting your OS distro ...
Starting bootstrap docker ...
Starting k8s ...
Error response from daemon: lstat /var/lib/docker-bootstrap/aufs/mnt/8881a46cdd1fe51b7f0f86e8659bc8f9c905089b0d86a273e85d134
c637041c1/tmp/flannel/subnet.env: no such file or directory
I have two vm,
one is on public_network:192.168.1.110
other is on private_network:192.168.50.2
all is the same error output.
ps: can I use the worker.sh in aws ec2?
question is a bit miscellaneous,
hoping a cattle help me to consolidation.
I am lucky enough to pass the work node, but I don't know the exactly reason.
now I package the vagrant box in my google cloud disk, url is below----[https://drive.google.com/file/d/0B9WzutmgDDrodkpLRGM2c0J1RXc/view?usp=sharing][1].
before you take a public or private network with it, you should download a pre-compiled kubernetes version, and copy it to the vagrant folder.
use vagrant init kube-slave to start.
I have just updated our Sphinx server from 1.10-beta to 2.0.6-release, and now I have run into some issues with searchd. Previously we were able to run two instances of searchd next to each other by specifying two different config-files, i.e:
searchd --config /etc/sphinx/sphinx.conf
searchd --config /etc/sphinx/sphinx.staging.conf
sphinx.conf listens to 9306:mysql41, and 9312, while sphinx.staging.conf listens to 9307:mysql41 and 9313.
After we updated to 2.0.6 however, a second instance is never started. Or rather.. the output makes it seem like it starts, and a pid-file is created etc. But for some reason only the first searchd instance keeps running, and the second seems to shutdown right away. So while trying to run searchd --config /etc/sphinx/sphinx.conf twice (if that was the first one started) complains that the pid-file is in use, trying to run searchd --config /etc/sphinx/sphinx.staging.conf (if that is the second started instance) "starts" the daemon again and again, only no new process is created..
Note that if I switch these commands around when first creating the process, then sphinx.conf is the instance not really started.
I have checked, and rechecked, that these ports are only used by searchd.
Does anyone have any idea of what I can do/try next? I've installed it from source on ubuntu 10.04 LTS with:
./configure --prefix /etc/sphinx --with-mysql --enable-id64 --with-libstemmer
make -j4 install
Note to self: Check the logs!
RT-indices use binary logs to enable crash recovery. Since my old config files did not specify a path for where these should be stored, both instances of searchd tried to write to the same binary logs. The instance started last was of course not permitted to manipulate these files, and thus exited with a fatal error:
[Fri Nov 2 17:13:32.262 2012] [ 5346] FATAL: failed to lock
'/etc/sphinx/var/data/binlog.lock': 11 'Resource temporarily unavailable'
[Fri Nov 2 17:13:32.264 2012] [ 5345] Child process 5346 has been finished,
exit code 1. Watchdog finishes also. Good bye!
The solution was simple, ensure to specify a binlog_path inside the searchd configuration section of each configuration file:
searchd
{
[...]
binlog_path = /path/to/writable/directory
[...]
}