be.
> >
> > I see a few changes:
> > * Allow external resource to depend on other resources
> > * Expose more port attributes
> > * Expose more subnet attributes
> >
> > If you can list the attributes you care about that'd be great.
> >
>
> Gues
ts,
> not TripleO UI specifically. Note that we will also need a 'reverse'
> Mistral workflow which is going to convert template yaml network_config
> into the input json format, so GUI can display current configuration to the
> user and let him change that.
>
> Liz has updated network configuration wireframes which can be found here
> https://
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
+1, glad to hear it.
--
Dan Sneddon | Sen
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
On 04/20/2017 12:37 AM, Steven Hardy wrote:
> On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote:
>> On 04/13/2017 12:01 AM, Rabi Mishra wrote:
>>> On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon <dsned...@redhat.com
>>> <mailto:dsned...@redhat.com>> wr
On 04/13/2017 12:01 AM, Rabi Mishra wrote:
> On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon <dsned...@redhat.com
> <mailto:dsned...@redhat.com>> wrote:
>
> On 04/12/2017 01:22 PM, Thomas Herve wrote:
> > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon <dsned.
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
On 04/12/2017 01:22 PM, Thomas Herve wrote:
> On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon <dsned...@redhat.com> wrote:
>> I'm implementing predictable control plane IPs for spine/leaf, and I'm
>> running into a problem implementing this in the TripleO Heat templates.
tps://docs.openstack.org/developer/heat/template_guide/hot_spec.html#intrinsic-functions
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twit
accomplish this?
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
__
OpenStack Development Mailing List (not for usage questions)
U
accentuate the ears (since
owls often have white tufts on their ears).
I whipped up a quick example of what I'm talking about, it's attached
(hopefully it will survive the mailing list).
[1] - https://www.google.com/search?q=owl+face=isch=u=univ
--
Dan Sneddon | Senior Princi
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/
>
&
?
I'll be at the PTG Tuesday through Friday morning. I'm looking forward
to having some conversations about this topic.
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
On 02/09/2017 09:56 AM, Pete Birley
://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-ironic-inspector
[8] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-templates
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
uable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
>
+1, thanks for all the work you did in the past, Jay!
--
Dan Sneddon | Senior Principal OpenS
in, that will help us move toward a consensus
approach.
[1] - https://review.openstack.org/#/c/409920
[2] - https://review.openstack.org/#/c/409921
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
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
On 12/08/2016 08:10 PM, Jason Rist wrote:
> On 12/08/2016 05:28 PM, Dan Sneddon wrote:
>> On 12/08/2016 06:05 AM, Jiri Tomasek wrote:
>>> Hi all,
>>>
>>> I've been investigating how to implement TripleO network configuration
>>> in TripleO UI. Based
but I would like to merge the
networker.yaml role and then can backport it prior to refactoring the
NIC configs. In general, though, I think we can limit the number of NIC
configs to one per physical topology, and then enable/disable interfaces,
VLANs, routes, etc. for each role based on network co
s a different base configuration.
So this would change the workflow slightly. You would first develop a
template that included all the possible networks that could appear in
that physical configuration, then enable
automatic template generation based on LLDP data
received from the switch, I also expect this to be pretty
error-prone. For instance, it may be difficult to detect which
interfaces should be part of a bond or bridge. Also, in cases where
a VLAN appears on more than one interface, it
o-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
__
trol plane, then it would be impossible to configure a system with
only 2 NICs in a fault-tolerant way.
Second, there will be a large percentage of users who already have a
shared br-ex that wish to upgrade. Do we tell them that due to an
architectural change, they now must redeploy a new cloud w
"ifdown " followed by "ifup " doesn't stop the dhclient
process started by the udev rule? Or why this behavior appears to be
new to RHEL 7.3?
[1] - https://bugs.launchpad.net/tripleo/+bug/1640598
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com |
ve him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>
> Thanks,
>
+1 from me, Mich
While I appreciate the desire to have stylistically consistent logos, my eyes
don't perceive this logo as an owl. Hummingbird, maybe, or a sparrow or perhaps
a parrot, but I don't see an owl. The current logo is not easy to mistake for
another brand of fowl.
>> Dan Sneddon |
On 10/19/2016 10:33 AM, Dan Sneddon wrote:
> I am doing research to support the spec for TripleO deployment on
> routed networks [1]. I would like some input on how to represent
> multiple subnet ranges for the provisioning network in undercloud.conf.
>
> The Ironic Inspector
ional_inspection_iprange =
"172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"
I would like some feedback about how to represent this data in a way
that it can be easily parsed by Puppet, while remaining readable. Any
suggestions would be very much appreciated.
[1] - ht
m in CI. I suppose that begs the question, if we are testing
those, then why not Contrail, etc.? I don't know where we draw the
line, but it seems that we might want to at least periodically test
deploying some other Neutron drivers via TripleO.
[1] - https://review.openstack.org/#/c/385562
--
D
to talk to (keystone, heat,
> ironic, mistral, swift, zaqar-websocket).
>
> Once those configuration changes were made, I had a very pleasant experience
> using the UI. It worked exactly as expected. I think this might be a viable
> option.
>
> Thoughts?
>
> Thanks!
> -d
.
>> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> On Sep 30, 2016, at 11:36 AM, Dan Sneddon <dsned...@redhat.com> wrote:
>
> I don't think we can rely on the Undercloud as an API proxy unless we address
> the lack of HA on the Undercloud.
>
it stands.
>> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> On Sep 30, 2016, at 9:44 AM, Dan Trainor <dtrai...@redhat.com> wrote:
>
> Hi -
>
> I re-read your email a few times and like a few of the things that I see, but
> I'd love some
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
49 matches
Mail list logo
