Open Stack

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
<robertc at 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 <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev