Hello all, Have some see my attached screenshots?
Thanks 於 2015/5/27 上午11:14，"Wilson Kwok" <[email protected]> 寫道： > Hello all, > > Please see attached Zip screenshots, you will know what is my problem. > > Thanks for your help! > > 2015-05-27 1:15 GMT+08:00 Remo Mattei <[email protected]>: > >> Just a quick note, each tenant has it’s own default security group rules. >> So I would double check and make sure your admin does have those rules set. >> If it works with Demo it has to work with admin. >> >> Remo >> >> On May 26, 2015, at 09:03, Wilson Kwok <[email protected]> wrote: >> >> Hi Yair, >> >> I just tried something: >> >> 1. I created Peter account and added into Demo project, I can access >> Peter's VM from external network PC via floating IP. >> 2. Admin account router account floating IP is 172.28.0.163, I can ping >> it, but I can't access Admin's VM floating IP 172.128.0.164 from external >> network PC (Securty Group allow ICMP and SSH) >> 3. Demo account with no problem. >> >> I created public network with keystone admin, please see below result >> with neutron net-show public: >> >> [root@localhost ~(keystone_admin)]# neutron net-show public >> +---------------------------+--------------------------------------+ >> | Field | Value | >> +---------------------------+--------------------------------------+ >> | admin_state_up | True | >> | id | 6145669e-4688-40a6-b878-aaa2f9cb26c6 | >> | mtu | 0 | >> | name | public | >> | provider:network_type | vxlan | >> | provider:physical_network | | >> | provider:segmentation_id | 10 | >> | router:external | True | >> | shared | True | >> | status | ACTIVE | >> | subnets | 65c1896c-0bc6-4b00-b89b-57f2677b3219 | >> | tenant_id | e67ef147ee074f83bdab0da903f0cdd3 | >> +---------------------------+--------------------------------------+ >> and keystone tenant-list command: >> >> [root@localhost ~(keystone_admin)]# keystone tenant-list >> /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: >> DeprecationWarning: The keystone CLI is deprecated in favor of >> python-openstackclient. For a Python library, continue using >> python-keystoneclient. >> 'python-keystoneclient.', DeprecationWarning) >> +----------------------------------+----------+---------+ >> | id | name | enabled | >> +----------------------------------+----------+---------+ >> | e67ef147ee074f83bdab0da903f0cdd3 | admin | True | >> | 24f9a6c52a1d471a8e7dc0f8fde32ced | demo | True | >> | 64c18def585e45e39b5e4ec161e18633 | services | True | >> | 80f0de3f19bf4c699938b54288d1ede8 | test | True | >> +----------------------------------+----------+---------+ >> Thanks for your help! >> >> >> 2015-05-26 18:32 GMT+08:00 Yair Fried <[email protected]>: >> >>> Hi, >>> From https://bugzilla.redhat.com/show_bug.cgi?id=1163726#c3 >>> >>> <snip> >>> By marking a network as "external" you are actually sharing it among all >>> other tenants to be used as default GW and a source for floating IPs. >>> >>> Marking a network as "shared" is allowing other tenants to connect VMs >>> (and not router GWs) directly to the network. >>> >>> Marking an external network as "shared" would allow VMs of all tenants >>> to connect to a network as well as pull floating ips from it (via router >>> GW). While this is possible in Neutron, it is also redundant, as with the >>> case above - There isn't much sense in pulling a floating IP from a network >>> that you can connect to directly. >>> </snip> >>> >>> please provide the relevant output from: >>> $ neutron net-show <external net> >>> $ keystone tenant-list >>> >>> Without this output it seems like the network was created by non-admin >>> tenant/user which shouldn't allow its floating IPs to be consumed by other >>> tenants. I've never tried to do that, so I'm not sure if this is a >>> legitimate operation and if so, how such network should behave. >>> >>> The ideal flow is: >>> 1. Admin creates an external network (usually called "public") in its >>> own tenant. >>> 2. Users (in their own tenants) create private networks and VMs attached >>> to them. >>> 3. Users create routers connecting their private networks ( >>> router-interface-add") to the external ("public") network >>> ("router-gateway-set"). >>> *** At this point, VMs should be able to access the outside world via >>> NAT. >>> 4. Now users can allocate floating IPs to their VMs (only those VMs that >>> are connected to the external network via routers). >>> >>> Please let me know if this is unclear >>> Regards >>> Yair >> >> >> >> >> >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
