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 > <mailto:yfr...@redhat.com>>: > Hi, > From https://bugzilla.redhat.com/show_bug.cgi?id=1163726#c3 > <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 : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
