Most people use OpenDaylight when connecting Mininet to OpenStack. You
will find many examples here:
https://www.google.com/search?q=mininet+opendaylight+openstack
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc
those choices have the same end result.
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
On 04/19/2017 12:06 PM, Ignazio Cassano wrote:
> Hi Dan, on the physical switch the 567 is not the native v
cal_network datacentre \
--provider:network_type flat --shared
Of course, remove shared if you don't want tenants directly attaching to
any of the above networks, and add "--router:external" if any of these
are to be used for SNAT/floating IP.
--
Dan Sneddon | Senior
external network interface:
>
> Replace /|INTERFACE_NAME|/ with the actual interface name. For
> example, /eth2/ or /ens256/.
>
> # ovs-vsctl add-port br-ex /p5p2/
>
> /
> /
> /Regards/
> /Gaurav Goyal/
>
&
impacts on performance and network traffic. You could get snapshots
for just data by using Cinder volumes for non-boot mount points.
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
- Original Message
o
ML2 plugin drivers. More information on ML2 plugins can be found here:
http://docs.openstack.org/developer/neutron/devref/l2_agents.html
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
__
ast business hours, or during business hours of GMT +1
(we have a large development office in Brno, CZ with engineers that
work on TripleO). There is also an RDO-specific mailing list available
here: https://www.redhat.com/mailman/listinfo/rdo-list
--
Dan Sneddon | Principal OpenStack En
by simply
using one subnet per network, but using a separate network for each
192.168.10.x, 192.168.11.x, and 192.168.12.x.
--
Dan Sneddon | Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
650.254.4025| dsneddon:irc @dxs:twitter
On 04/22/2016 05:49 AM
r HTTPS if
using SSL).
In general, you want to use port 5000 for all remote Keystone
connections, with the exception that if you want to use the API for
creating users or tenants you need to use the admin API. The only
difference between the two is that 35357 can perform admin functions on
the u
reet
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
> On Fri, Apr 1, 2016 at 2:13 PM, Dan Sneddon <dsned...@redhat.com
> <mailto:dsned...@redhat.com>> wrote:
>
&
On 04/01/2016 02:07 PM, Dan Sneddon wrote:
> On 04/01/2016 01:07 PM, Adam Lawson wrote:
>> The Contrail team that said they are using their network product with
>> OpenStack without requiring a mechanism driver with the ML2 plugin.
>> More specifically, they said they don
gin.
[1] - http://www.opencontrail.org/rdo-openstack-opencontrail-integration/
The same kind of approach applies to some other 3rd-party Neutron
plugin providers, although there are also some that use ML2 and do the
customization at the mechanism and type driver layer. Does that answer
your questio
s often a sign of an MTU problem.
Especially if you are running VXLAN, you need room for the tunnel
headers. If your MTU is 1500 on the wire, then the VM MTU must be 1450
or smaller to make room for the VXLAN headers. Check
/etc/neutron/dnsmasq-neutron.conf, and make sure this option is set
s used to host a self-service portal, so that VM
needs to be able to issue commands against the Public APIs in order to
provision services. In this case, it would have been difficult to
engineer a solution that allowed both the VM and the internal services
to connect to a single API without increasing the
s of this RFC, as long as 100.64.0.0/10 were only used
for Tenant networks and not floating IP addresses.
That said, we already have 192.168.X.X, 172.X.X.X, and 10.X.X.X
addresses. If a customer were already using all of these throughout
their network, then I could see using 100.64.0.0/10 in order
e remote
network, and they will use their default route for everything else.
--
Dan Sneddon | Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
650.254.4025| dsneddon:irc @dxs:twitter
___
OpenStack-operators mail
ly understand what you're saying.
> If the catalog showed only internal API's, how would external clients
> reach you at all?
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
>
I'm not sure I'm on board with the three endpoints as listed, but at
the very least I would swap Internal and Provider in your example:
* Public - Available outside. may incur costs to access internally
* Internal - Not exposed to normal users and intended for backend sorts
of things.
* Provider
s simpler, but still provides
the advantages of having multiple endpoints. This introduces a
dependency on a proxy, but I've never seen a production deployment that
didn't use a load-balancing proxy. In this case, the Keystone endpoint
list would show the internal API URLs, but they would not
is
listening for inbound traffic to those IPs. You might send traffic out, but the
return traffic is going to go to the NAT server and not your VM.
None of this has anything to do with OpenStack or private IPs, you just have
local routing issues.
-Dan Sneddon
- Original Message -
> Dear
n idea what projects are available, both core and optional.
http://governance.openstack.org/reference/projects/index.html
The official list is the projects.yaml that is linked to from this
page, and it should be up-to-date:
https://wiki.openstack.org/w/index.php?title=Project_Teams
--
Dan Sn
21 matches
Mail list logo
