Open Stack

Alternatively, you could drop the 'external' attribute and attach your
instances directly to the provider network (no routers or private networks).

On Mon, Oct 3, 2016 at 1:16 AM, Saverio Proto <zioproto at gmail.com> wrote:

> Sorry I missed the Mailing List in the Cc:
> Saverio
>
> 2016-10-03 9:15 GMT+02:00 Saverio Proto <zioproto at gmail.com>:
> > Hello Kevin,
> >
> > thanks for your answer.
> >
> > so far I managed to make the network not shared just by making it not
> > external. Because I dont need NAT and floatingips this will match my
> > use case.
> >
> > As an admin I create the network like:
> > openstack network create --no-share --project user_project_uuid
> > --provider-physical-network physnet2 --provider-network-type flat
> > NETWORKNAME
> >
> > In this way only the users that belong to user_project_uuid see the
> > network with 'list' and 'show' operations.
> >
> > I still have to test carefully if Openstack will allow isolation to
> > brake in case a user or admin tries to create more networks mapped to
> > physnet2
> >
> > I hope I will upgrade to Mitaka as soon as possible.
> >
> > thank you
> >
> > Saverio
> >
> >
> >
> >
> >
> > 2016-10-03 7:00 GMT+02:00 Kevin Benton <kevin at benton.pub>:
> >> You will need mitaka to get an external network that is only available
> to
> >> specific tenants. That is what the 'access_as_external' you identified
> does.
> >>
> >> Search for the section "Allowing a network to be used as an external
> >> network" in
> >> http://docs.openstack.org/mitaka/networking-guide/config-rbac.html.
> >>
> >> On Thu, Sep 29, 2016 at 5:01 AM, Saverio Proto <zioproto at gmail.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Context:
> >>> - openstack liberty
> >>> - ubuntu trusty
> >>> - neutron networking with vxlan tunnels
> >>>
> >>> we have been running Openstack with a single external network so far.
> >>>
> >>> Now we have a specific VLAN in our datacenter with some hardware boxes
> >>> that need a connection to a specific tenant network.
> >>>
> >>> To make this possible I changed the configuration of the network node
> >>> to support multiple external networks. I am able to create a router
> >>> and set as external network the new physnet where the boxes are.
> >>>
> >>> Everything looks nice except that all the projects can benefit from
> >>> this new external network. In any tenant I can create a router, and
> >>> set the external network and connect to the boxes. I cannot restrict
> >>> it to a specific tenant.
> >>>
> >>> I found this piece of documentation:
> >>>
> >>>
> >>> https://wiki.openstack.org/wiki/Neutron/sharing-model-
> for-external-networks
> >>>
> >>> So it looks like it is impossible to have a flat external network
> >>> reserved for 1 specific tenant.
> >>>
> >>> I also tried to follow this documentation:
> >>>
> >>> http://docs.openstack.org/liberty/networking-guide/adv-
> config-network-rbac.html
> >>>
> >>> But it does not specify if it is possible to specify a policy for an
> >>> external network to limit the sharing.
> >>>
> >>> It did not work for me so I guess this does not work when the secret
> >>> network I want to create is external.
> >>>
> >>> There is an action --action access_as_external that is not clear to me.
> >>>
> >>> Also look like this feature is evolving in Newton:
> >>> http://docs.openstack.org/draft/networking-guide/config-rbac.html
> >>>
> >>> Anyone has tried similar setups ? What is the minimum openstack
> >>> version to get this done ?
> >>>
> >>> thank you
> >>>
> >>> Saverio
> >>>
> >>> _______________________________________________
> >>> OpenStack-operators mailing list
> >>> OpenStack-operators at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >>
> >>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161003/e70d8877/attachment.html>