해당 코드에서 보면 PortBindingPort 라는 새로운 테이블을 추가하며 그 테이블에는 port_id와 host명을 기록하고 있다.
class PortBindingPort(model_base.BASEV2):
port_id = sa.Column(sa.String(36),
sa.ForeignKey('ports.id', ondelete="CASCADE"),
primary_key=True)
host = sa.Column(sa.String(255), nullable=False)
port = orm.relationship(
models_v2.Port,
backref=orm.backref("portbinding",
lazy='joined', uselist=False,
cascade='delete'))
하지만 이 테이블에 대한 migration 코드는 기존 포트들을 위한 데이터를 추가하는 코드가 존재 하지 않았다. (물론 이정보를 얻기 위해서는 nova database와도 연계가 필요할듯 했다.)
아무튼 havana를 이용할때는 해당 테이블의 데이터는 openvswitch plugin을 사용할땐 큰 문제를 일으키지 않는다.
하지만 icehouse로 업그레이드 해서 ml2를 이용하게 될때 migration시 해당 table에 port에 대한 host정보가 없을시 문제를 일으키게 된다.
왜냐하면 ml2로 업그레이드 시 migration 코드에서 위의 테이블을 참조해서 ml2_port_bindings를 생성하게 된다.
간단히 정리해서 portbindingport에 port가 존재하지 않으면 ml2_port_bindings에 대한 데이터를 추가할 수 없다. 그리고 이후 ml2_port_bindings에 데이터가 존재하지 않으면 해당 데이터를 vif_type_unbound에 대한 값으로 생성한다.
결국 이 정보는 nova에서 info_cache에 network 정보로 저장하게 되고 이 잘못된 정보로 nova-compute 프로세스에서는 잘못된 처리를 하게 된다.
정리하자면 이 버그는 grizzly -> havana로 업그레이드 했을때 이미 timebomb으로 생성된 문제 였다. 또한 이와 비슷하게 neutron에는 몇가지 timebomb이 될 소지의 테이블 컬럼들이 존재한다. 이런 문제를 해결하기 위해서는 보다 테이블 컬럼에 대한 이해가 필요할 것 같다.
댓글 없음:
댓글 쓰기