2:11 a.m.
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@test ~(keystone_admin)]# nova floating-ip-bulk-delete 10.3.4.0/22
[root@test ~(keystone_admin)]# nova floating-ip-bulk-create 192.168.0.56/29
[root@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
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:166
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
/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:245
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@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
frustrating.
You may want to check if you have SSH (and ICMP) security group
rules are correctly added[1].
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
network.
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
applies:
1. Create a Keystone tenant called 'demoten1'.
2. Then, a Keystone user called 'tuser1' and associates it to the
'demoten1'.
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
(trouter1).
9. Adds Neutron security group rules for this test tenant (demoten1)
for ICMP and SSH.
There's a blog-post here[2] with all the commands noted for the above
steps. Also, my iptables rules are here[3], at the end of the page.
[1] http://docs.openstack.org/user-guide/content/configure_security_groups_ru...
[2] http://kashyapc.com/2013/12/13/script-to-create-neutron-tenant-networks/
[3]
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-t...
--
/kashyap