Ask Your Question

missing public network

asked 2014-02-04 11:52:10 -0500

luigi.romagnoli gravatar image

updated 2014-02-04 11:53:26 -0500

i create,, all subnet i need, one router, two ubuntu virtual machine and one load balancer everithing is great :-) Now i want to create another tenant (project) for demo purpose just done but my public network is missing maybe i'm tired can u help me?

neutron net-show b294358d-06bb-41b7-89ca-6d161fddb459 (user admin) +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | b294358d-06bb-41b7-89ca-6d161fddb459 | | name | public | | provider:network_type | gre | | provider:physical_network | | | provider:segmentation_id | 1 | | router:external | True | | shared | False | | status | ACTIVE | | subnets | a6704a6d-b315-42f9-b03d-451f894f413a | | tenant_id | a1ebd1aac2cd4234829497640c1ca53c | +---------------------------+--------------------------------------+

(user demo) neutron net-list

[root@node1 ~(keystone_demo)]# yes is empty :-(

if is not too much is there any way to see the loadbalancer on Network Topology view of my tenant?

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-02-05 02:39:59 -0500

marica gravatar image

I think that Neutron behaviour is correct: the public network you have created is NOT SHARED, therefore you cannot see it from another tenant rather than the owner.

edit flag offensive delete link more

answered 2014-02-05 03:19:57 -0500

luigi.romagnoli gravatar image

U are right usually i make the external network using the web interface that make it external and shared, programmatically i missed something and after your good answer i make some research

Apparently the easiest solution is to decouple the concept of 'external' from the concept of sharing. External will qualify the network in topological terms, whereas 'shared' will qualify it in terms of access. In this way, the external network as we know it today would be 'external and shared', whereas a network which is simply external would be visible only to the tenant who owns it, as any other network.

This is 'kind of' backward compatible. Indeed a data migration can be used to set shared=True for each network where external=True, but the responses will be different since the 'shared' attribute would change from False to True for existing external networks.

Moreover, in order to preserve backward compatibility, setting a network as external should keep having the same behaviour as now. This will mean that the network has to be 'shared' and 'external' at the same time. If a user want a 'private' external network, he/she will have to submit a request with shared=False, external=True (and this is a bit awkward). Similarly when unsetting the 'external' attribute, the network will go back to the 'private' state.

The real problem comes however when considering the following sequence of operations:

POST /networks with shared=True --> shared = True, external=False PUT /networks with external=True --> shared=True, external=False PUT /networks external=False --> shared=False, external=False The resulting state of the network at step 3 differs from step 1, and this is unaccepable.

Also, there will be complications related to policy verifications in this case.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-02-04 11:52:10 -0500

Seen: 475 times

Last updated: Feb 05 '14