[Rdo-list] Feedback on RDO install
kchamart at redhat.com
Wed Feb 26 08:11:30 UTC 2014
On Wed, Feb 26, 2014 at 11:25:34AM +0800, Daniel Veillard wrote:
> On Tue, Feb 25, 2014 at 12:04:44PM -0500, Lars Kellogg-Stedman wrote:
> > On Tue, Feb 25, 2014 at 05:48:15PM +0100, Dave Neary wrote:
[. . .]
> At that point i tried various things to have the 'public' network
> allocate IPs in the range of my local LAN, I tried for example
> [root at test ~(keystone_admin)]# nova floating-ip-bulk-delete 10.3.4.0/22
> [root at test ~(keystone_admin)]# nova floating-ip-bulk-create 192.168.0.56/29
> [root at test ~(keystone_admin)]# nova-manage floating list
> 2014-02-25 12:22:55.983 13516 DEBUG nova.openstack.common.lockutils
> [req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore
> "dbapi_backend" lock
> 2014-02-25 12:22:56.006 13516 DEBUG nova.openstack.common.lockutils
> [req-854a5ff1-baf3-43b3-b381-d23966d7ea04 None None] Got semaphore /
> lock "__get_backend" inner
> None 192.168.0.57 None nova eth0
> None 192.168.0.58 None nova eth0
> None 192.168.0.59 None nova eth0
> None 192.168.0.60 None nova eth0
> None 192.168.0.61 None nova eth0
> None 192.168.0.62 None nova eth0
> [root at test ~(keystone_admin)]#
> then i disasociated the floating IP of my guest which were allocated
> as 172.24.4.127 and tried to reallocate a floating IP but that didn't
> work it still picked 172.24.4.x
> Then I tried to create another public network matching my range
> and create a router from the private network, the operations worked
> at the interface level but I still cound not associate my instance
> interface to it.
> So right now I can create guests, I can't ssh to them, and I have
> no root password to log from the console (which works), it's a bit
You may want to check if you have SSH (and ICMP) security group
rules are correctly added.
> Someone who understands the basic operations needed to have the
> default created public network allocate IPs in the range of the user
> network should document those operations, it should be added to
> the RDO setup page, because as is even if the setup worked it's not
> really functional :)
Thanks for taking time to try this. I see that you're using Nova
FWIW, in my testing, I use Neutron networking (in a manually configured
2-node setup -- this helps for my nature of work involving a lot of
debugging). I'd like to outline the flow here, in case if you/someone
would like to try Neutron at some point:
Concept of tenant (now renamed to 'project') network: User-A can have
his/her own IP-namespace, private subnets while a User-B can _also_ have
his/her own isoloated set of IP namespace, subnets, iptables namespace.
Networks, subnets, routers creation
Once Neutron configured, and its services are running, then the below
1. Create a Keystone tenant called 'demoten1'.
2. Then, a Keystone user called 'tuser1' and associates it to the
3. Creates a Keystone RC file for the user (tuser1) and sources it.
4. Creates a new private network called 'priv-net1'.
5. Creates a new private subnet called 'priv-subnet1' on 'priv-net1'.
6. Creates a router called 'trouter1'.
7. Associates the router (trouter1 in this case) to an existing
external network (the script assumes it’s called as ext) by setting
it as its gateway.
8. Associates the private network interface (priv-net1) to the router
9. Adds Neutron security group rules for this test tenant (demoten1)
for ICMP and SSH.
There's a blog-post here with all the commands noted for the above
steps. Also, my iptables rules are here, at the end of the page.
More information about the dev