On the stable release of Havana installed through RDO, when I create images, their properties (disk_format, container_format, is_public) are lost even when set (they must be set, otherwise glance-api wouldn't accept the request).
However, they are not saved to the database. When I modify database manually, they are visible correctly, but it is still not possible to modify them through Glance.
Do you have any idea if that might be some configuration error or maybe a bug in RDO packaging?
Any help will be very much appreciated.
Did anyone get VPNaaS to work using RDO packages? Is there any good tutorial for that like the one on LBaaS?
I couldn't find any on RDO website and my attempts to create VPN always ended with PENDING_CREATE.
I'd appreciate if someone could share some tested recipe for getting VPNaaS to work on RDO
Ok, I've been chasing down some networking issues along with some other
folks. Here's what I'm seeing:
Starting with a vanilla F20 cloud image running on a F20 host, clone
devstack into it and run stack.sh.
First thing is that the RabbitMQ server issue I noted a few weeks ago is
still intermittently there. So during the step where rabbitmqctl is run
to set the password of the rabbit admin user, it might fail and all
subsequent AMQP communication fails which makes a lot of the nova
commands in devstack also fail.
But... if you get past this error (since it is intermittent), then
devstack seems to complete successfully. Standard commands like nova
list, keystone user-list, etc all work fine.
I did note though that access to Horizon does not work. I need to
investigate this further.
But worse than that is when you run nova boot, the host to guest
networking (remember this is devstack running in a VM) immediately gets
disconnected. This issue is 100% reproducible and multiple users are
reporting it (tsedovic, eharney, bnemec cc'd)
I did some investigation when this happens and here's what I found...
If I do:
$ brctl delif br100 eth0
I was immediately able to ping the guest from the host and vice versa.
If I reattach eth0 back to br100, networking stops again
Another thing... I notice that on the system br100 does not have an ip
address, but eth0 does. I thought when doing bridged networking like
this, the bridge should have the ip address and the physical iface that
is attached to the bridge does not get an ip addr.
So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
allowing it to use bootproto dhcp
I brought both ifaces down and then brought them both up. eth0 first
and br100 second
This time, br100 got the dhcp address from the host and networking
So is this just an issue with how nova is setting up bridges?
Since this network disconnect didn't happen until nova launched a vm, I
imagine this isn't a problem with devstack itself, but is likely an
issue with Nova Networking somehow.
Russell/DanS, is there any chance that all of the refactoring you did in
Nova Networking very recently introduce a regression?
I pushed a proposed workaround for the rabbitmq problem running devstack on Fedora 20. Ideally it would be best to fix the problem with rabbitmq, but in the meantime this change shouldn't hurt anything when rabbit behaves and it made devstack complete successfully again for me on the first try.
Let me know if you have any feedback. Thanks.
It seems there's no official Red Hat / RDO presence at OpenStack Days
Tokyo 2014, but I was nevertheless wondering whether other people will
be there? If so, maybe we could have a small meetup sometime (beer or
dinner after the first day?). Not sure there's other RDO people in
Japan, though. ;)
Here's the details for the event for those who haven't heard about it.
You'll notice all the other big names (that have business in Japan)
are listed in some way or another: