Hi Robert, all, >>> But what are we meant to do? Nova etc are dead easy: nova-manage db sync >>> every time the code changes, done. I believe, it's not different from Nova: run db sync every time the code changes. It's the only way to guarantee the most recent DB schema version is used.
Interestingly, that Neutron worked for us in TripleO even without db-sync. I think it's caused by the fact, the Neutron internally calls metadata.create_all(), which creates DB schema from SQLAlchemy models definitions (which is perfectly ok for *new installations* as long as you 'stamp' the DB schema revision then, but it *does not* work for upgrades). Thanks, Roman On Wed, Feb 26, 2014 at 2:42 AM, Robert Collins <robe...@robertcollins.net> wrote: > So we had this bug earlier in the week; > https://bugs.launchpad.net/tripleo/+bug/1283921 > > Table 'ovs_neutron.ml2_vlan_allocations' doesn't exist" in > neutron-server.log > > We fixed this by running neutron-db-migrate upgrade head... which we > figured out by googling and asking weird questions in > #openstack-neutron. > > But what are we meant to do? Nova etc are dead easy: nova-manage db > sync every time the code changes, done. > > Neutron seems to do something special and different here, and it's not > documented from an ops perspective AFAICT - so - please help, cluebats > needed! > > -Rob > > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
