I suspect a "BaaS" (Bridge-as-a-service) proposal is lurking in this thread.
While the idea of yet-another-aas is probably not desirable at this time, it might be worth trying and understand - from an exclusively logical perspective (ie: the API consumer point of view) - what would be the difference between having a single logical network shared across a number of tenants, and a group of distinct networks interconnected by bridge ports. I've tried in the past to look at "unique" use cases for a network bridge feature; it might seem important to enforce that all the traffic between two network goes through a predefined channel where security and traffic shaping policies might be applied. On the other hand, I believe the same result can be achieved - in the logical model - with features such as security groups. This unless the Neutron API consumer explicitly wants to describe a topology where all the traffic is forced to flow through a specific logical appliance, but then we'll descend in the NFV/SFC/etc area. Another thing to keep in mind is that routers can be used to this aim, but - as Anik correctly noted - this is an admin-only feature at the moment. Allowing router owners to interconnect other tenants' networks, leveraging concepts such as keystone groups, is something that should be a natural evolution of the RBAC work. Still, this will leave us with a L3 interconnection, and not a direct L2 network-network connection. Salvatore On 2 June 2015 at 18:58, Fawad Khaliq <[email protected]> wrote: > Great! > A correction here: RBAC proposal does address some of the use cases on > interconnecting tenants. > > Fawad Khaliq > > > On Tue, Jun 2, 2015 at 9:41 PM, Anik <[email protected]> wrote: > >> That's exactly what I was asking for. Thanks Fawad. >> >> Regards, >> Anik >> 201-245-1569 >> >> ------------------------------ >> *From:* Fawad Khaliq <[email protected]> >> *To:* OpenStack Development Mailing List (not for usage questions) < >> [email protected]> >> *Cc:* Anik <[email protected]> >> *Sent:* Tuesday, June 2, 2015 9:29 AM >> *Subject:* Re: [openstack-dev] Interconnecting projects >> >> >> On Tue, Jun 2, 2015 at 9:14 PM, Assaf Muller <[email protected]> wrote: >> >> Check out: >> >> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html >> >> If I understand correctly, what Anik is probably asking for is way to >> connect two OpenStack projects together from a network point of view, where >> a private network in Project1 can be connected to a Router in Project2. >> AFAIK, I don't think we are planning to expose such model in RBAC where a >> tenant (non-admin) has a way control who can see/connect-to his/her >> resources. >> >> @Anik, please correct me if I am wrong. >> >> >> >> Kevin is trying to solve exactly this problem. We're really hoping to >> land it in >> time for Liberty. >> >> ----- Original Message ----- >> > Hi, >> > >> > Trying to understand if somebody has come across the following scenario: >> > >> > I have a two projects: Project 1 and Project 2 >> > >> > I have a neutron private network in Project 1, that I want to connect >> that >> > private network to a neutron port in Project 2. >> > >> > This does not seem to be possible without using admin credentials. I am >> not >> > talking about a shared provider network here. >> > >> > It seems that the problem lies in the fact that there is no data model >> today >> > that lets one Project have knowledge about any other Project inside the >> same >> > OpenStack region. >> > >> > Any pointers there will be helpful. >> > Regards, >> > Anik >> > 201-245-1569 >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> > >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
