Any one can help? 於 2015/5/29 上午10:39,"Wilson Kwok" <leiw...@gmail.com> 寫道:
> Ok > 於 2015/5/28 下午6:24,"Remo Mattei" <r...@italy1.com> 寫道: > >> Nope. >> >> Inviato da iPhone >> >> Il giorno 28/mag/2015, alle ore 02:04, Wilson Kwok <leiw...@gmail.com> >> ha scritto: >> >> Hello all, >> >> Have some see my attached screenshots? >> >> Thanks >> 於 2015/5/27 上午11:14,"Wilson Kwok" <leiw...@gmail.com> 寫道: >> >>> 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 <r...@italy1.com>: >>> >>>> 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 <leiw...@gmail.com> 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 <yfr...@redhat.com>: >>>> >>>>> 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 >>>> >>>> >>>> >>>> >>>> >>> !DSPAM:1,5566da3a317321526615646! >> >>
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack