[openstack-dev] [nova] Conductor support for networking in Icehouse

Hi, I'm updating the installation guide for Icehouse. Based on the following blueprint, I removed the database configuration keys from nova.conf on the compute node in my test environment. https://blueprints.launchpad.net/nova/+spec/nova-network-objects However, when attempting to boot an

Re: [openstack-dev] [nova] Conductor support for networking in Icehouse

Done. https://bugs.launchpad.net/nova/+bug/1290568 On Mon, Mar 10, 2014 at 1:37 PM, Dan Smith d...@danplanet.com wrote: However, when attempting to boot an instance, the Nova network service fails to retrieve network information from the controller. Adding the the database keys resolves

Re: [openstack-dev] [nova] Conductor support for networking in Icehouse

Hmm... I guess the blueprint summary led me to believe that nova-network no longer needs to hit the database. On Mon, Mar 10, 2014 at 3:50 PM, Dan Smith d...@danplanet.com wrote: https://bugs.launchpad.net/nova/+bug/1290568 Thanks. Note that the objects work doesn't really imply that the

[openstack-dev] [neutron] Location of 'enable_security_group' key in ml2_conf.ini

I'm writing the ML2 configuration sections for the installation guide and found a potential location conflict for the 'enable_security_group' key in ml2_conf.ini. In the patch associated with this feature, the example configuration file has this key under [security_group].

Re: [openstack-dev] [neutron] Location of 'enable_security_group' key in ml2_conf.ini

seem to have added a new section accidentally. We don't intended to introduce a new section name. IMO, both firewall_driver and enable_security_group are placed in [securitygroup]. It should be fixed ASAP. I will take care of it. Thanks, Akihiro On Tue, Apr 8, 2014 at 5:51 AM, Matt

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

As someone who contributes a significant number of diagrams to OpenStack documentation [1], I think I can provide some insight from a different (non-developer?) perspective. Primarily, we should consider the information that a diagram conveys and the audience that references it. A picture is worth

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

Monty, The architectural changes to the installation guide for Liberty [1] support booting VMs on both the public/external/provider and private/project/self-service networks. Also, we should consider including similar "hybrid" scenarios in the networking guide [2] so deployers don't have to

Re: [openstack-dev] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

I would like involvement in this discussion too from a documentation perspective... particularly maintaining the configuration reference and possibly standardizing how packagers include dynamic configuration files. On Wed, Jan 6, 2016 at 10:53 AM, Martin Hickey wrote:

Re: [openstack-dev] [OpenStack-docs] [docs] [install-guide] Install guide from source

You can't mix distribution packages and source on the same host without using at least virtual environments for the latter. On Wed, Jun 1, 2016 at 9:30 AM, Andreas Jaeger wrote: > On 06/01/2016 05:21 PM, Spyros Trigazis wrote: > >> Hi everyone, >> >> Is the idea of having an

Re: [openstack-dev] [networking-ovn] provider networks

Provider networks should operate the same whether using the conventional L3 agent (q-l3) or native L3 support in OVN. Provider networks only operate at layer-2 and rely on a physical router on the same layer-2 segment to provide layer-3 services such as a gateway. On Fri, Jun 17, 2016 at 12:37

Re: [openstack-dev] [Neutron] MTU configuration pain

On Mon, Jan 18, 2016 at 4:14 PM, Kevin Benton wrote: > Thanks for the awesome writeup. > > >5) A bridge or veth pair with an IP address can participate in path MTU > discovery (PMTUD). However, these devices do not appear to understand > namespaces and originate the ICMP

Re: [openstack-dev] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable

Seems like a config error. What's in local.conf? On Thu, Feb 25, 2016 at 1:11 PM, Sean M. Collins wrote: > Can you provide the output of > > "ip route show" > > Was this after a unstack.sh that failed? > > It could be https://bugs.launchpad.net/devstack/+bug/1423020 popping

Re: [openstack-dev] [Neutron] MTU configuration pain

Ian, Overthinking and corner cases led to the existing implementation which doesn't solve the MTU problem and arguably makes the situation worse because options in the configuration files give operators the impression they can control it. For example, the segment_mtu does nothing in the in-tree

Re: [openstack-dev] [Neutron] MTU configuration pain

Results from the Open vSwitch agent... I highly recommend reading further, but here's the TL;DR: Using physical network interfaces with MTUs larger than 1500 reveals problems in several places, but only involving Linux components rather than Open vSwitch components (such as br-int) on both the

Re: [openstack-dev] [Neutron] MTU configuration pain

Adam, Any modern datacenter network, especially those with 10 Gbps or faster connectivity, should support jumbo frames for performance reasons. However, depending on the network infrastructure, jumbo frames does not always mean a 9000 MTU, so neutron should support a configurable value rather

Re: [openstack-dev] [Neutron] MTU configuration pain

rtising > it would be harmful? > On Jan 18, 2016 23:57, "Matt Kassawara" <mkassaw...@gmail.com> wrote: > >> >> >> On Mon, Jan 18, 2016 at 4:14 PM, Kevin Benton <blak...@gmail.com> wrote: >> >>> Thanks for the awesome writeup. >>> >&g

Re: [openstack-dev] [Neutron] MTU configuration pain

n...@hpe.com> wrote: > On 01/20/2016 08:56 AM, Sean M. Collins wrote: > >> On Tue, Jan 19, 2016 at 08:15:18AM EST, Matt Kassawara wrote: >> >>> No. However, we ought to determine what happens when both DHCP and RA >>> advertise it. >>> >> >> We

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

Good news... the number of neutron options with a sane default value has increased significantly in the last couple of releases. If you're looking at the installation guide, it explicitly configures more options to override bad values set by distribution packages. For deployment tools, explicitly

Re: [openstack-dev] [OpenStack-docs] Fwd: [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

Snipping a lot, because I'm particularly interested in one comment... > I agree that many developers (especially developers of those groups new to > the big tent) seem to think that they need to be on the top level > docs.openstack.org, without necessarily understanding that >

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

Hi, I didn't see this e-mail until now because I'm busy trying to update and test the installation guide in time for the Mitaka release. As a primary contributor to the installation guide for about six releases including restructuring it a couple of times, I think I can explain why we do what we

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

Sean, I can tell you how the configuration should work. Sean Collins and I have collaborated quite a bit on how to fix the DevStack networking problems... mostly by replacing the legacy neutron bits with something a bit more flexible and less crufty. On Fri, Apr 1, 2016 at 12:39 PM, Monty Taylor

Re: [openstack-dev] Wiki

>From the perspective of contributing documentation and providing support (mostly in #openstack) to a variety of consumers, the wiki tends to provide yet another location for varying levels of content without a specific audience and questionable relevance due to lack of maintenance. I find a

Re: [openstack-dev] [Neutron] Stale documentation on docs.o.o

All of the documentation on d.o.o suffers from the inability to easily delete files that search engines continue to reference. To delete specific files, I recommend opening a bug in openstack-manuals and someone on the documentation team (or infra?) can handle it. On Wed, May 11, 2016 at 11:15

Re: [openstack-dev] [Neutron][L2GW] Mitaka release of L2 Gateway now available

stall L2GW outside of devstack. > > -Sukhdev > > > On Wed, May 11, 2016 at 1:54 PM, Matt Kassawara <mkassaw...@gmail.com> > wrote: > >> Do you have any examples of how to implement L2GW outside of DevStack? >> Operators do not deploy on DevStack. >> >> O

Re: [openstack-dev] Easing contributions to central documentation

> wrote: > > Hi All, One reply inline: > > > > On 11/05/2016, 7:33 AM, "Lana Brindley" <openst...@lanabrindley.com> > wrote: > > > >>On 10/05/16 20:08, Julien Danjou wrote: > >>> On Mon, May 09 2016, Matt Kassawara wrote:

Re: [openstack-dev] [Neutron][L2GW] Mitaka release of L2 Gateway now available

This should provide you all the information that you need. > > -Sukhdev > > > > On Wed, May 11, 2016 at 1:14 PM, Matt Kassawara <mkassaw...@gmail.com> > wrote: > >> Can you point me to the documentation? >> >> On Wed, May 11, 2016 at 2:05 PM, Sukhdev

Re: [openstack-dev] [Neutron][L2GW] Mitaka release of L2 Gateway now available

Can you point me to the documentation? On Wed, May 11, 2016 at 2:05 PM, Sukhdev Kapur wrote: > > Folks, > > I am happy to announce that Mitaka release for L2 Gateway is released and > now available at https://pypi.python.org/pypi/networking-l2gw. > > You can install it

Re: [openstack-dev] Easing contributions to central documentation

/developers. Improving collaboration via liaisons would resolve most problems. On Tue, May 10, 2016 at 4:08 AM, Julien Danjou <jul...@danjou.info> wrote: > On Mon, May 09 2016, Matt Kassawara wrote: > > > So, before developer frustrations drive some or all projects to move >

[openstack-dev] Easing contributions to central documentation

At each summit, I speak with a variety of developers from different projects about the apparent lack of contributions to the central documentation. At previous summits, the most common complaint involved using DocBook. After converting most of the documentation to RST, the most common complaint at

Re: [openstack-dev] [OpenStack-docs] What's Up, Doc? 6 May 2016

One significant advantage of central documentation involves providing content in a single location with consistent structure or format that best serves the particular audience. Moving most or all documentation into project trees essentially eliminates this advantage, leaving our audiences with an

Re: [openstack-dev] The future of OpenStack documentation

Zoeller (markus_z) > > > The folks that contribute to the keystone guides today would still be > very > > welcomed to continue to contribute once/if the switch is made. > > > > On Fri, Jul 8, 2016 at 5:02 PM, Matt Kassawara <mkassaw...@gmail.com> > wrote: > &g

Re: [openstack-dev] [docs][nova] config options help texts: reviews by technical writers?

I think we can help. Do you want us to submit patches for config option descriptions that benefit from rewording? Also, you might want to post to the -docs list. On Mon, Jul 18, 2016 at 6:29 AM, Markus Zoeller wrote: > I'd like to ask the docs team if they see the

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

All MTU changes must occur on a layer-3 device, typically a router. If a router receives a packet with an MTU larger than the next-hop interface, it can either fragment it or use path MTU discovery (PMTUD) to inform the sender of the next-hop interface MTU value [1]. Fragmentation causes

Re: [openstack-dev] The future of OpenStack documentation

Andreas, I consider the API documentation and installation guide rather complex for initial content to move to project repositories and evaluate the results. However, we're seeing rather strong adoption of moving API documentation which I think predicts adoption of moving operator/user

Re: [openstack-dev] The future of OpenStack documentation

Inline... On Sun, Jul 10, 2016 at 5:22 PM, Lana Brindley <openst...@lanabrindley.com> wrote: > On 09/07/16 07:02, Matt Kassawara wrote: > > Currently, OpenStack provides central documentation (primarily in the > openstack-manuals repository) for operators and users. T

[openstack-dev] The future of OpenStack documentation

Currently, OpenStack provides central documentation (primarily in the openstack-manuals repository) for operators and users. The single location and consistent structure eases audiences of various technical expertise into OpenStack, typically operators and users rather than developers. Although

Re: [openstack-dev] [Openstack-operators] [Performance][Documentation] Please take a look on OpenStack perofmance-docs

Why isn't this content in the openstack-manuals repository? On Sun, Aug 21, 2016 at 4:38 PM, Kaustubh Kelkar wrote: > I might have missed it entirely, but I wasn't able to find virtual > resources used by the instances. IMO, it'd be great if one could see > instance

Re: [openstack-dev] [docs][upgrades] time to add official docs for upgrading services?

How about top-level organization by project/service, each with consistent topics that pertain to installation, configuration, upgrades, development, API, etc? Projects can determine whether some or all of those topics reside in the openstack-manuals or project repository. On Fri, Nov 18, 2016 at

[openstack-dev] [docs] Stepping down from core

Howdy! After several years of contributing to OpenStack documentation, a significant change in my career path warrants resigning from my role as a core reviewer. Working with the OpenStack community was a great experience and I hope it continues to grow... with sufficient documentation, of