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
