icehouse heat test

이 stack은 HOT template을 이용해서 빌드해본 그림이다. (HOT는 heat orchestration template이다.)
1개의 security group에 연결된 2개의 network port 그리고 그 port 각각에 연결된 2개의 instance이다.

스택으로 빌드하면서 몇가지 삽질을 했는데 그 중에 한가지는 아래의 메세지 였다.

heatclient.exc.HTTPBadRequest: ERROR: Property error : my_instance: key_name maximum recursion depth exceeded while calling a Python object

해당 메세지만 봤을때 어떤 key_name이라는 propertie 값이 recursive하게 호출 된다고 생각해서 작성한 template에서 온갖 삽질을 하고 아니면 max_nested_stack_depth 값과 관계가 있나 했던데 전혀 문제가 아니였다.

알고보니 keystone_backend의 값을 heat.common.heat_keystoneclient.KeystoneClient 를 사용한게 문제였다. 해당 파일(heat/common/heat_keystoneclient.py)에서 KeystoneClientV3 클래스와 KeystoneClient 클래스를 지원하고 있길레 당연히 V2를 이용하려면 아래 클래스를 이용해야 한다고 생각했다.

그 클래스는 다음과 같다.

class KeystoneClient(object):

    """Keystone Auth Client.

    Delay choosing the backend client module until the client's class
    needs to be initialized.
    """

    def __new__(cls, context):
        if cfg.CONF.keystone_backend == _default_keystone_backend:
            return KeystoneClientV3(context)
        else:
            return importutils.import_object(
                cfg.CONF.keystone_backend,
                context
            )


이 클래스를 보면 V3 클래스를 사용하지 않으면 아래의 분기로 importutils로 keystone_backend를 import하게 되어 있다..

헐 이게 뭔지.. 진짜 충격과 공포가..
아무튼 이 클래스는 왜 만들어 놨는지 이해를 할 수 없는 상태이고 반드시 KeystoneClientV3를 사용하거나 아니면 다른 keystoneclient를 만들어 써야 한다.

다음으로는 아래 메세지 이다.

heatclient.exc.HTTPBadRequest: ERROR: Property error : server2: key_name Authorization failed: The resource could not be found. (HTTP 404)

이건 아까 문제랑 겹치면서 헤깔리지만 아니면 빨리 찾을 수 있는 문제인데..
간단하게 정리하면 auth_uri 값을 정의 할때 http://controller:35357 가 아닌 http://controller:35357/v2.0 혹은 http://controller:35357/v3를 사용해야 한다.
http://controller:35357/v2.0을 사용하면 자동으로 v3로 바꿔서 서비스 한다.
이 auth_uri 값은 대부분의 openstack project들은 http://controller:35357 값으로 사용하나 heat는 뒤에 api version url이 없으면 auth fail이 일어 난다.

여기까지 정리 했을때 간단히 heat는 keystone v3만지원하고 있다고 생각하면 된다.
애초부터 알고 시작했으면 이런 삽질은 안했을텐데..

아무튼 heat에서 뭘 할 수 있는지는 잘 정리된 문서들이 많기 때문에 참고하면 될듯 하다.
http://docs.openstack.org/developer/heat/template_guide/hot_guide.html
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html
http://docs.openstack.org/developer/heat/template_guide/openstack.html

대략적으로 예제 템플릿들이나 설명들을 종합했을때 2가지에 편리하게 사용 할 수 있을것 같다.

1. 복잡한 neutron net, subnet, lb, router, security group 등을 심플하게 생성해서 관리해주는 목적과 같이 openstack의 component들에 대한 템플릿 활용
2. ceilometer를 연동해서 monitoring을 통한 autoscailing 정의와 같은 이벤트성 작업에 대한 활용

나머지는 거진 configuration management와 같은 deploy 툴들과 겹치는 부분이 많을 것 같다.

아무튼 heat는 나중에 여러 모로 재미 있게 사용가능 할 것 같지만 아직 에러 처리나 소프트웨어 구조에 보다 정리를 하면 더 나은 유저경험을 제공해 줄 수 있을것 같다.