Re: [Openstack] Failed "db sync" while upgrading from essex to folsom
On Tue, 2013-04-30 at 16:06 +0530, Shashank Sahni wrote: > Hi Calvin, > > Thank you for the reply. It solved the "db sync" issue. But soon after > this, the nova-compute daemons started throwing the following trace. > > 2013-04-30 15:53:21 TRACE nova OperationalError: (OperationalError) (1054, > "Unknown column 'instance_metadata_1.instance_id' in 'field list'") > > When I checked the instance_metatdata table, I found that it has > "instance_uuid" as a field and not "instance_id". It seems to be another > issue with db sync. > > Suggestions? From https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/133_folsom.py#L349 It looks like 'instance_uuid' is the correct column name in Folsom. Are you sure that you've updated your nova-compute packages to the Folsom version and restarted all of the nova services? The simplest explanation for this error is that you have an Essex service accessing the Folsom database. -- Calvin Walton smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Failed "db sync" while upgrading from essex to folsom
On Mon, 2013-04-29 at 20:16 +0530, Shashank Sahni wrote: > Hi everyone, > > I'm having some trouble upgrading from essex to folsom. The cloud is > currently running on Ubuntu 12.04. For the upgrade, I included the folsom > repo(ubuntu cloud archive) and upgraded the packages. Things went fine > until I issued "nova-manage db sync". It failed with the following error. > > 2013-04-29 20:13:50 23254 TRACE nova raise > exc.NoSuchTableError(full_name) > 2013-04-29 20:13:50 23254 TRACE nova NoSuchTableError: `projects` > > Ironically, the table exists. But I get the same message accessing it > through mysql console. This is due to a bug in one version of the Ubuntu package that included a broken database migration; it had a foreign key on a latin-1 table (dns_domains) referencing a text column on a utf-8 table (projects), which mysql does not support. As a result, a *later* migration that changed the projects table partially failed, and left the table in a half-created state. I ran into this problem, and the only way I found to *fix* the error was to dump the database to a sql file, drop the entire database, manually edit the dump file to correct the referencing table charset on the 'dns_domains' table, add the definition for the projects table back, then restore the database from the dump. Related issues on launchpad: https://bugs.launchpad.net/nova/+bug/993663 https://bugs.launchpad.net/ubuntu/+source/nova/+bug/975085 Amusingly, if you're using keystone, the 'projects' table is actually not used by anything, but it still has to exist. -- Calvin Walton smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Preventing OpenStack from allocating some floating ips?
On Thu, 2012-08-02 at 13:59 -0400, Lars Kellogg-Stedman wrote: > If I create a floating address range like this: > > nova-manage floating create --ip_range=10.243.30.0/24 > > Is there any way to "block out" specific addresses in that range? For > example, the .1 address is the network gateway, and everything will > fall apart if that address is accidentally allocated to an instance. > > Similarly, our host needs an address in that range in order to route > traffic to the gateway. > > Is there any way to exempt specific addresses? I realize that instead > of allocating a /24 I could allocate a series of, say, /28 networks, > but that seems a little clumsy. (The following is assuming you're using Essex - I don't really know anything about Quantum) An interesting thing about how floating IPs work is that internally nova-network just has a big table of ip addresses in the database. The only thing that using a CIDR range like "10.243.20.0/24" does is save you some typing - it does the exact same thing as separately adding "10.243.20.1", "10.243.20.2", and so on. So it really makes no difference if you just individually add the ip addresses that you want to use. The easiest alternative? Just add the entire /24 range, then delete the individual addresses that you want to reserve using nova-manage floating delete 10.243.30.1 and so on. -- Calvin Walton ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Instances can't access eachother via external (floating) ips?
On Mon, 2012-04-23 at 06:45 -0700, Mike Scherbakov wrote: > Hi Calvin, Sorry I didn't respond earlier, the email temporarily got lost :) > show us iptables -nL -t nat | grep NAT on the node with nova-network. (192.168.0.101 is the nova-network node's "external" address) DNAT all -- 0.0.0.0/0192.168.0.33to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 ACCEPT all -- 192.168.22.32/27 192.168.22.32/27 ! ctstate DNAT DNAT tcp -- 0.0.0.0/0169.254.169.254 tcp dpt:80 to:192.168.0.101:8775 DNAT all -- 0.0.0.0/0192.168.0.33 to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 SNAT all -- 192.168.22.350.0.0.0/0to:192.168.0.33 SNAT all -- 192.168.22.410.0.0.0/0to:192.168.0.88 SNAT all -- 192.168.22.32/27 0.0.0.0/0to:192.168.0.101 Note that the nova-network is actually colocated on a machine that also runs nova-compute; this is a small 2-node lab deployment. > Could it be that your fixed_range flag in nova.conf covers both > subnets, > like 192.168.0.0/16 ? My fixed_range is very small, and doesn't overlap: --fixed_range=192.168.22.32/27 > Second reason - I presume that the traffic from VM will go via your > router if you access another VM via floating IP, > so router should know the route to 192.168.0.x (static/ospf?) 192.168.0.x is the office network, and communication between other machines on that network and the router on that network all work fine. In the course of trying some other things out, I found that when I enabled ipv4 forwarding on the nova-network box: echo 1 >/proc/sys/net/ipv4/ip_forward Then the virtual machines /were/ able to communicate with each-other via their floating IP addresses. I'm still not sure about what's going on, but it's good enough for our lab use now. > > Regards, > > On Fri, Apr 20, 2012 at 7:03 AM, Calvin Walton > wrote: > Hi, > > I have instances running in Openstack using FlatDHCP > networking mode. > Each one has an IP address in the internal subnet > (192.168.22.x) and a > floating IP from the external subnet (192.168.0.x). > > I've found that from one instance, I cannot connect to another > instance > (or, in fact, even the same instance) via the external > floating address > (I have some monitoring tools that attempt to do this to > verify that a > server is running). Connections from external computers work > fine. > > My best guess is that there is an issue with the NAT on my > nova-network > node not allowing loopback connections. Is this intentional, > or a bug? > Is there a workaround available? > > For reference, I'm currently using OpenStack from the > 'latest-milestone-test' OpenStack PPA on Ubuntu 12.04 Precise. -- Calvin Walton Blindside Networks http://www.blindsidenetworks.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Instances can't access eachother via external (floating) ips?
Hi, I have instances running in Openstack using FlatDHCP networking mode. Each one has an IP address in the internal subnet (192.168.22.x) and a floating IP from the external subnet (192.168.0.x). I've found that from one instance, I cannot connect to another instance (or, in fact, even the same instance) via the external floating address (I have some monitoring tools that attempt to do this to verify that a server is running). Connections from external computers work fine. My best guess is that there is an issue with the NAT on my nova-network node not allowing loopback connections. Is this intentional, or a bug? Is there a workaround available? For reference, I'm currently using OpenStack from the 'latest-milestone-test' OpenStack PPA on Ubuntu 12.04 Precise. -- Calvin Walton Blindside Networks http://www.blindsidenetworks.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
