Magnum Trouble Shooting

🔴 ERROR . OpenStack Magnum Certificate Error 발생 

 

 

🟠  --debug로 확인, 다양한 error 원인 발견  

1. human error:  keystone_authtoken 섹션에 적지 않고 keystone_auth 섹션으로 오타 

2. domain_name으로 재설정 : domain도 id가 아니라 domain_name으로 설정값 바꿔서 적용 

3. barbican 서비스가 정지 상태 : magnum 이나 barbican 디렉토리에 들어가도 아무 log가 출력되지 않음

 => barbican 포트를  listen이 안되고 있었음 !!! 

 

🟢 매뉴얼로 barbican api 서비스 재시작 및 활성화

 

# systemctl start openstack-barbican-api
# systemctl enable openstack-barbican-api

 

 

이렇게 인증 문제는 통과된 것 같았으나 . . .

---

🔴 ERROR . Failed to get discovery url fron 'https://discovery.etcd.io/new?size=1'.

 

🙋‍♀️잠깐! etcd요 ?

(엣시디라고 읽는다) 
이는 머신의 분산된 시스템 또는 클러스터의 설정을 공유, 서비스 검색 및 스케줄러 조정을 위한 일관된 오픈소스로 
분산형 키-값 저장소.

더욱 안전한 자동 업데이트를 지원하고, 스케줄링되는 작업을 조정하며 컨테이너에 대한 오버레이 네트워킹 설정을 지원 

 

🟠 매그넘은 etcd를 사용하는데, 이 etcd는 discovery 토큰을 얻고 생성하기 위해 io에 접속한다. 
즉, 인터넷 연결이 안되는 경우 이는 실패할 수 밖에 없는 것

 

이 오류는 꽤 자주 등장한다 ㅠ ㅠ vmnet 8번아 제발 인터넷 연결 좀 중간에 끊어지지마라ㅠㅠㅠ

 

🟢 컨트롤러 노드의 인터넷 연결 재실행 및 ping 8.8.8.8 확인 후 재실행

---

🔴 ERROR . Resource Create Failed : resources.docker_volume.properties.volume_type: . . . VolumeType() could not be found. 

🟠 openstack voluem type list로 확인해보니, type이 없다 

🟢 lvm 도커 볼륨 타입 생성 및 cinder 서비스 재실행하여 적용 

 

# openstack volume type create lvm
# openstack volume type set lvm --property volume_backend_name=LVM

 

# systemctl start openstack-cinder-volume.service target.service  @storage node 
# systemctl start openstack-cinder-api.service openstack-cinder-scheduler.service @controller node

---

🔴 ERROR : miniou_wait_condition, softwareDeployment, ResourceGroup 

 

# 일단 스택 삭제! 

클러스터는.... 설치시간만큼 삭제 시간도 오래걸린다. .. . . 몇 번의 시도 끝에 터득한

 

🎨 HOW TO DELETE CLUSTER IN A FASTER WAY:

클러스터 생성시 함께 생성된

스택을 먼저 삭제하고, 클러스터 삭제 

# openstack stack delete <stack 명>
# openstack coe cluester delete <cluster명>

 

 

뿔뿔이 흩어지며 삭제되고 있는 중 

 

🟠삽질1.  cinder volume 용량을 더 늘려 보자.

 

구글링을 하다보니, cinder volume 양이 충분하지 않기 때문일수도 있다고 한다!

 

It seems that docker volume creation failed, cinder logs should provide more details why it failed. If I should guess, it's because your cinder volume size is not big enough (check with "vgs" command) - by default 25G volume per each node is created but you can tune size by tweaking following params in your env.yaml file (adequate size for deployment testing):
master_docker_volume_size_gb: 6
node_docker_volume_size_gb: 4

 

이전에 cinder 설치한 블로그 글을 살펴보니

cinder-volume을 파티션하지 않은채로

그 디스크 고대로 갖다 붙인 상황

# pvcreate /dev/sdb ..

 

#pvscan : 물리 볼륨 확인 - PE 한 개 단위로 잡혀 나옴 (4.81기가 바이트)

# 볼륨 확인 

 

# vgs
# pvscan

 

🟠-1. 기존 cinder volume 삭제 @ storage node

 

 

🟠-2.  파티셔닝한 디스크로  cinder volume 그룹 생성  @ storage node

 

# fdisk /dev/sdb
# pvcreate /dev/sdb1
# vgcreate /dev/sdb1 cinder-volumes

# vi /etc/cinder/cinder.conf  
filter = [ ...,  "a/sdb1/", ... ]

파티션된 /dev/sdb -> /sdb1 

 

볼륨 추가하였으나 여전히 오류!
볼륨은 문제가 아니었음을...

 

 

🟠 삽질 2.  Time out 시간이 촉박한가? 더 늘려보자! 

인프라 스펙에 따라 클러스터 생성시간이 다르니까 그냥 시간이 오래걸리는 걸 수 있다.

제한 시간을 더 늘려서 생성해본다.

 

# openstack coe cluster create kubecluster --cluster-template kubetemplate --master-count 1 --node-count 1 --keypair mykey --timeout 80
#openstack coe cluster create kubecluster --cluster-template kubetemplate --master-count 1 --node-count 1 --keypair mykey --timeout 120

 

time out시간을 80도, 120으로도 늘려보았지만 여전히 오류! 
타임아웃값도 문제가 아니였음을...

 

 

🟠 삽질 3. [clients_keystone] endpoint_type 을 public으로 수정 

 

참고 구글링 자료

kolla ansible 설치에 관한 내용이긴 하지만,

kube-master가 keystone의 internal endpoint를 바라보고 있어서 

heat - keystone 간의 통신이 잘 이루어지지 않을 수도 있다는 내용이었다.

[clients_keystone]의  endpoint_type 타입을 public으로 변경해보자. 

 

# vi /etc/heat/heat.conf 

그래도 오류...