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

[Matt Kassawara]

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 course.

Cheers,
Matt
__
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

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

[Matt Kassawara]

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 12:27 PM, Doug Hellmann 
wrote:

> Excerpts from Steve Martinelli's message of 2016-11-17 20:36:46 -0500:
> > In the keystone docs we have notes about how to upgrade between releases
> > [1], so does the nova team [2].
> >
> > Is it time we create an official guides to [3] for this subject?
> >
> > [1] http://docs.openstack.org/developer/keystone/upgrading.html
> > [2] http://docs.openstack.org/developer/nova/upgrade.html
> > [3] http://docs.openstack.org/
>
> Maybe, instead of creating a separate project-specific guide for
> every topic (install, upgrade, config, API, etc.), it would make
> sense to have developer, deployer, and user facing guides and create
> separate chapters in each for topics relevant to the audiences?
>
> Doug
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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 flavor details (vCPUs, memory etc.) and, RAM and CPU over-commit
> ratios from host's perspective.
>
>
> Thanks,
> Kaustubh
> --
> *From:* Dina Belova 
> *Sent:* Friday, August 19, 2016 12:37 PM
> *To:* OpenStack Development Mailing List; openstack-operators
> *Subject:* [Openstack-operators] [Performance][Documentation] Please take
> a look on OpenStack perofmance-docs
>
> Folks,
>
> During previous weeks we merged lots of OpenStack performance-related test
> plans and test results to the performance-docs
>  and your feedback
> (as usually) is very appreciated. I hope you can find something interesting
> for you here and share your opinion on what's going on regarding our
> performance researches.
>
>
> Thanks in advance!
>
> Cheers,
> Dina
>
> --
> *Dina Belova*
> *Senior Software Engineer*
> Mirantis, Inc.
> 525 Almanor Avenue, 4th Floor
> Sunnyvale, CA 94085
>
> *Phone: 650-772-8418 <650-772-8418> Email: dbel...@mirantis.com
> *
> www.mirantis.com
> 
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
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

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

[Matt Kassawara]

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 possibility to have
> reviews of the merged config options help texts Nova has updated in the
> last months.
>
> Background: In Mitaka and Newton, Nova put a lot of effort in providing
> valuable help texts for their config options. They are written from
> developers for operators. My assumption is, that technical writers like
> the docs team look at them differently. As these help texts get
> extracted from the code and will be used directly in the "configuration
> reference" manual, the text "by-passed" the writing expertise of the
> docs team.
>
> Be aware, that this is still an ongoing effort in Nova (see [1],
> especially "needs:fix_opt_description").
>
> References:
> [1] http://45.55.105.55:8082/config-options.html
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> 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
>
__
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

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

[Matt Kassawara]

The configuration reference essentially uses a script to parse help strings
from code in project repositories. Occasionally, the documentation team
augments content beyond what the automation provides. However, these
content augmentations, the script, and schedule for running the script
belong to the documentation team. Moving control of these items to projects
would likely yield a more robust configuration reference, particularly
regarding nuances of each project.

Speaking of help strings, I see a conflict between providing sufficient
content and preventing bloat of example configuration files. At the last
summit, I suggested implementing two types of help strings... one long and
one short. The configuration reference pulls the long string and the
configuration file generator pulls the short string. If this idea makes
sense, moving the configuration reference to project repositories would
potentially enable each project to implement such changes at its own pace.

On Wed, Jul 13, 2016 at 8:11 AM, Markus Zoeller <mzoel...@linux.vnet.ibm.com
> wrote:

> On 11.07.2016 00:02, Steve Martinelli wrote:
> > I personally like this solution, it seems much more scalable. This
> follows
> > the same pattern of the API docs (moving the content to project repos),
> > which puts the onus back on the project team to maintain and create
> > documentation. I'm also hoping this results in less duplication between
> the
> > guides and the keystone developer docs (the latter of which start to
> stray
> > from "developer" docs and begin to look like "user" docs.
>
> After reading this, the "configuration reference" comes to my mind.
> Having the api-ref and the config-ref at one place, near the code, seems
> logical to me. Nova put a lot of effort into providing valuable help
> text for the config options in the last months. We should also make sure
> that it will result in a good manual, which could be easier if it's
> in-tree, near the code.
>
> --
> Regards, Markus 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:
> >
> >> 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 I'm not a fan of the word "product", increasingly less
> technical
> >> audiences are learning about OpenStack and tend to compare it with other
> >> cloud infrastructure products. Such audiences expect a coherent,
> relatively
> >> mature product to easily evaluate, usually via proof-of-concept. Upon
> >> deciding to implement OpenStack, the central documentation attempts to
> >> gracefully lead them toward a production deployment that meets or
> exceeds
> >> requirements and expectations.
> >>
> >> However, since I began contributing to OpenStack documentation around
> the
> >> Havana release, I am seeing many projects, particularly core projects,
> >> trending toward more independence from other projects including central
> >> documentation. For operator and user documentation, a couple of projects
> >> contribute to the central documentation repository, some projects
> >> contribute to their own repositories, and an alarmingly large number of
> >> projects simply do not contribute such documentation and assume that all
> >> audiences involve developers. These differences lead to an increasingly
> >> negative overall experience for the audiences that OpenStack needs to
> >> increase adoption/growth and maintain the existing deployment base.
> >>
> >> As a contributor to central documentation and one or more other projects
> >> including neutron, I see the problems from both sides and don't
> >> particularly blame either party for them. Some politics, some technical,
> >> some a lack of resources, and some just a general misunderstanding about
> >> documentation. However, I think we need to develop a solution that works
> >> for both parties and ultimately benefits our audiences.
> >>
> >> One potential solution essentially involves moving operator and user
> >> documentation into project repositories (similar to developer
> >> documentation) and using infrastructure to coherently present it on
> >> docs

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

[Matt Kassawara]

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. The single location
> and consistent structure eases audiences of various technical expertise
> into OpenStack, typically operators and users rather than developers.
> Although I'm not a fan of the word "product", increasingly less technical
> audiences are learning about OpenStack and tend to compare it with other
> cloud infrastructure products. Such audiences expect a coherent, relatively
> mature product to easily evaluate, usually via proof-of-concept. Upon
> deciding to implement OpenStack, the central documentation attempts to
> gracefully lead them toward a production deployment that meets or exceeds
> requirements and expectations.
> >
> > However, since I began contributing to OpenStack documentation around
> the Havana release, I am seeing many projects, particularly core projects,
> trending toward more independence from other projects including central
> documentation. For operator and user documentation, a couple of projects
> contribute to the central documentation repository, some projects
> contribute to their own repositories, and an alarmingly large number of
> projects simply do not contribute such documentation and assume that all
> audiences involve developers. These differences lead to an increasingly
> negative overall experience for the audiences that OpenStack needs to
> increase adoption/growth and maintain the existing deployment base.
>
> bI know the UX team have been working on getting some data around this,
> but I'd be interested to know what data you have. The User Survey
> highlighted that, while OpenStack itself is difficult to understand, most
> people are pretty happy with the current state of the documentation. Also,
> of the core projects that users interact with, we have a good relationship
> with the Cross Project Liaisons and PTLs, and are consistently working with
> them to keep docs up to date. Docs are very much a living thing, especially
> in a situation like ours, where there are a lot of components all at
> different maturity levels. Is there something specific you feel we're
> dropping a ball on?
>

Most of my data involves a combination of observations from providing
support in #openstack (and some other channels) on IRC, mailing list posts,
bug reports, and attempting to use (or reference) the existing
documentation.


>
> >
> > As a contributor to central documentation and one or more other projects
> including neutron, I see the problems from both sides and don't
> particularly blame either party for them. Some politics, some technical,
> some a lack of resources, and some just a general misunderstanding about
> documentation. However, I think we need to develop a solution that works
> for both parties and ultimately benefits our audiences.
>
> I don't think I fully understand the problem you're trying to solve here,
> yet, which makes it difficult to determine a solution.
>

I'm trying to solve the problem of the central documentation content
falling behind the development curve of OpenStack. The documentation team
can't keep up with the exponential growth of OpenStack and most projects
don't contribute sufficient documentation for the audiences that the
central documentation serves. The user guide came to mind today when I
attempted to link to it for OpenStack client commands and found out it
doesn't even mention the OSC. How do we get users to adopt the OSC if the
documentation doesn't cover it?


>
> >
> > One potential solution essentially involves moving operator and user
> documentation into project repositories (similar to developer
> documentation) and using infrastructure to coherently present it on
> docs.openstack.org <http://docs.openstack.org/> which achieves the
> following goals:
>
> But I still don't understand what problem you're solving for here. Is the
> problem that developers aren't contributing to docs? That the docs are out
> of date? That users aren't finding the right docs?
>

All of the above.


>
> >
> > 1) Project developers can contribute documentation and code in the same
> patch, thus avoiding two different review queues and reviewers with
> different motivations and guidelines.
> > 2) Project developers can either work directly or via liaison with one
> or more documentation team members to improve documentation components
> during development or after merging technically accurate content.
> > 3) Rather than attempting to document all projects with little (if any)
> assistance from those projects, th

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

[Matt Kassawara]

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 documentation more
than the installation guide. Regardless of outcome, the API documentation
caters to a smaller audience with at least some knowledge of OpenStack
and/or development experience, thus having less impact on adoption of
OpenStack. On the other hand, the installation guide is extremely popular
and caters to a larger audience with little (if any) prior knowledge of
OpenStack that expects the procedures to work with minimal frustration.
Victimizing this audience hinders adoption of OpenStack and may cast the
wrong impression of moving content into project repositories.

On Mon, Jul 11, 2016 at 3:52 PM, Michael Johnson 
wrote:

> I support putting infrastructure in place to allow the project
> documentation to be in the project's repository.  We had problems in
> the Mitaka release with documentation getting deleted without the
> project team knowing it was happening until users were asking us where
> the documentation was located.
>
> Having it in the repository makes it easier to review that the
> required documentation updates are being made and gives the project
> team visibility to changes in the documentation.
>
> Michael
>
>
> On Sun, Jul 10, 2016 at 10:31 PM, Andreas Jaeger  wrote:
> >
> > With Install Guide and API references, we had specific problems to
> > solve. Which ones do you see exactly with other guides?
> >
> > Also, before we discuss moving further documentation around, I'd like to
> > see first how the API references and Install guides work out and what we
> > need to improve there - before discussing next steps,
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> >
> __
> > 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
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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
performance problems and all modern layer-3 devices support PMTUD. Thus,
unless explicitly disabled (or broken by blocking ICMP), PMTUD provides an
optimal solution that enables the sender to retransmit the initial packet
and any future packets without fragmentation.

[1] https://en.wikipedia.org/wiki/IP_fragmentation

On Mon, Jul 11, 2016 at 11:18 AM, Sam Yaple  wrote:

> On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes  wrote:
>
>> On 07/11/2016 07:45 AM, Sam  Yaple wrote:
>>
>>> Hello,
>>>
>>> There was alot of work to get MTU advertisement working well in Mitaka.
>>> With the work that was done we can finally have 1500 mtu networks for
>>> tunneled networks if the underlying infrastructure supports jumbo frames.
>>>
>>> Its fantastic for people who have 1500 mtu networks and want to use
>>> vxlan, no more hacks to get the instance to use 1450 mtu. Its fantastic
>>> for people who want to use 1500+ networks and get the instances setup
>>> with 9000 mtu interfaces. Its is not good for people who want consistent
>>> mtu no matter the network type. But thats fine, since mtu advertisement
>>> _could_ be disabled. Its a fantastic default to have it turned on.
>>>
>>> With a recent patchset [1] the ability to turn off MTU advertisements
>>> was deprecated in Newton. In the review it was stated there is no valid
>>> use case for it. I disagree.
>>>
>>> The scenario is the infrastructure has jumbo frames enabled, but I do
>>> not want the instances to be using jumbo frames, but I want them to be
>>> using the default 1500 mtu that the rest of the world operates on. This
>>> would still setup all of the virtual switching infrastructure to the
>>> correct MTUs, but not try to adjust the instances MTUs. In this way the
>>> instances are only communicating at 1500 mtu, but never having to
>>> fragment/drop inside of the SDN when communicating with other networks
>>> even if it is a VXLAN or other tunneled network.
>>>
>>> Without the option to disable mtu advertisement, inside the same
>>> environment flat/vlan and gre/vxlan network will always have different
>>> mtu, even if the backend supports jumbo frames.
>>>
>>> My ask is we keep the advertise_mtu option, and keep it enabled by
>>> default. This would allow for the default, common 1500 mtu across
>>> networks of different types.
>>>
>>> This scenario would be very similiar to having a computer with 1500 mtu
>>> attached to a switch which supports jumbo frames. Just because the
>>> switch will accept and process a 9000 mtu frame, doesnt mean the
>>> computer has to send a 9000 mtu frame. A very common scenario in the
>>> real world.
>>>
>>> [1] https://review.openstack.org/#/c/310448/
>>>
>>
>> Hi Sam,
>>
>> Out of curiosity, in what scenarios is it better to limit the instance's
>> MTU to a value lower than that of the maximum path MTU of the
>> infrastructure? In other words, if the infrastructure supports jumbo
>> frames, why artificially limit an instance's MTU to 1500 if that instance
>> could theoretically communicate with other instances in the same
>> infrastructure via a higher MTU?
>>
>> Hey Jay,
>
> A not-so-uncommon way to setup networks in neutron involves the use of 1:1
> NATs. You have a firewall device that holds real, valid public addresses
> that map to private addresses (RFC-1918). So to OpenStack the network
> appears as a private network, but some of those address map to public
> addresses outside of OpenStack's sphere of knowledge. This works really,
> really well when you have multiple separate ranges of public ip addresses
> and separate gateways for each and you want to use them without creating
> multiple subnets on an external network with OpenStack. This has been
> written about in blog posts [1] and used in enterprise environments (it is
> what Rackspace does for their private cloud [2]).
>
> In this situation, since you are mapping real-ips and the real world runs
> on 1500 mtu, you want to make sure your MTUs match in ways that cannot be
> auto-discovered. A good way to do this is to just use the default 1500 mtu
> for every instance and ensure that that never fragments (which means at
> least 1550 mtu networks for vxlan). So in this case you would have setup
> your network in such a way that a 1500 mtu frame from the internet can
> arrive at your instance without ever being fragment, and outgoing traffic
> isn't trying to send >1500mtu packets into the real internet.
>
> Additionally, there may be other services using the interface (it is not
> dedicated to just neutron traffic) such as ceph which loves high MTUs. I
> mention this as a secondary point because neutron doesn't affect this at
> all, but it is 

[openstack-dev] The future of OpenStack documentation

[Matt Kassawara]

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 I'm not a fan of the word "product", increasingly less technical
audiences are learning about OpenStack and tend to compare it with other
cloud infrastructure products. Such audiences expect a coherent, relatively
mature product to easily evaluate, usually via proof-of-concept. Upon
deciding to implement OpenStack, the central documentation attempts to
gracefully lead them toward a production deployment that meets or exceeds
requirements and expectations.

However, since I began contributing to OpenStack documentation around the
Havana release, I am seeing many projects, particularly core projects,
trending toward more independence from other projects including central
documentation. For operator and user documentation, a couple of projects
contribute to the central documentation repository, some projects
contribute to their own repositories, and an alarmingly large number of
projects simply do not contribute such documentation and assume that all
audiences involve developers. These differences lead to an increasingly
negative overall experience for the audiences that OpenStack needs to
increase adoption/growth and maintain the existing deployment base.

As a contributor to central documentation and one or more other projects
including neutron, I see the problems from both sides and don't
particularly blame either party for them. Some politics, some technical,
some a lack of resources, and some just a general misunderstanding about
documentation. However, I think we need to develop a solution that works
for both parties and ultimately benefits our audiences.

One potential solution essentially involves moving operator and user
documentation into project repositories (similar to developer
documentation) and using infrastructure to coherently present it on
docs.openstack.org which achieves the following goals:

1) Project developers can contribute documentation and code in the same
patch, thus avoiding two different review queues and reviewers with
different motivations and guidelines.
2) Project developers can either work directly or via liaison with one or
more documentation team members to improve documentation components during
development or after merging technically accurate content.
3) Rather than attempting to document all projects with little (if any)
assistance from those projects, the primary role of the documentation team
becomes managing overall organization/presentation of documentation and
assisting projects with their contributions.

We're seeing decent adoption of moving API documentation into project
repositories, so I want to initiate some discussion about moving additional
documentation (or other options) prior to mid-cycles (including ops) and
the next summit.

Matt
__
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

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

[Matt Kassawara]

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 PM, Murali R  wrote:

> I think for provider networks we have to disable OVN_L3. Because devstack
> setup for neutron is creating a default router in the standard setup and
> conflicts with external router.
>
>
> On Fri, Jun 17, 2016 at 10:57 AM, Ryan Moats  wrote:
>
>> Murali R  wrote on 06/17/2016 12:33:09 PM:
>>
>> > From: Murali R 
>> > To: Ryan Moats/Omaha/IBM@IBMUS
>> > Cc: Ben Pfaff , discuss 
>> > Date: 06/17/2016 12:33 PM
>> > Subject: Re: [ovs-discuss] [ovn] provider networks
>> >
>> > > Your question makes me think that you are using provider networks
>>
>> > > in a way different from I have used them
>> >
>> > Actually it is standard
>> > Q_USE_PROVIDER_NETWORKING=True
>> > PHYSICAL_NETWORK=providernet
>> > PROVIDER_NETWORK_TYPE=flat
>> > OVS_PHYSICAL_BRIDGE=br-provider
>> > PROVIDER_SUBNET_NAME=provider-subnet
>> > FIXED_RANGE=10.145.253.0/24
>> > NETWORK_GATEWAY=10.145.253.1
>> > ALLOCATION_POOL=start=10.145.253.111,end=10.145.253.242
>> >
>> > So earlier, probably the full l3 support wasn't there. I made
>> > changes for logical flow additions in my own repo and use it for
>> > testing. I had to do a big merge for l3 extensions last night
>> > because networking-ovn eas expecting some idl extensions in new
>> updates.
>> >
>> > The setup now creates a logical router in OVN and assigns the
>> > gateway address given above. The gateway should not be used to
>> > allocate address for OVN router.
>> >
>> > If I create another private network, add a new router attach it to
>> > public network created, the traffic is hitting my external company
>> > gateway all the way out. Not sure what is happening. Can I just
>> > delete the default router1 that the devstack setup created? Looks
>> > like I may have to do some manual configs to get this setup working.
>> > Or should I disable OVN_L3 in devstack?
>>
>> I'm dropping the openvswitch discuss list and adding the openstack
>> dev list because this is very much now questions for that channel.
>>
>> Right now, my test cloud is in a state where I can't answer your
>> question directly, but my memory is that a router should not be
>> created and if it is, that would be a bug against something...
>>
>> Ryan
>>
>>
>
> __
> 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
>
>
__
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

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

[Matt Kassawara]

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 install-guide from source and possibly
>> virtualenvs still under consideration?
>>
>> I'd like to share with you what we are currently doing along with
>> the install-guide based on the cookiecutter template.
>>
>> I have created this change [1] in our project repo. Although some
>> commands are ugly it works in the same way on Ubuntu, Fedora,
>> Suse and Debian. Since this change aims Newton release, we clone
>> from master, when we branch will update to clone from the stable
>> branch.
>>
>> Cheers,
>> Spyros
>>
>> [1] https://review.openstack.org/#/c/319399/
>>
>
> We will not have a full from source guide - let's grow the existing one
> first before adding another variation ;). The idea was AFAIR that projects
> can install from source if there are no packages for them.
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
__
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

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

[Matt Kassawara]

I'm also not a fan of option 3 because it trades one kind of technical debt
for another. However, one could argue that some (relevant) content is
better than no (or defunct) content. Interestingly, option 3 also reflects
what ultimately happens if projects decide to maintain all documentation in
their respective repositories. Easier for developers to contribute, but at
the expense of usability by our various audiences.

On Thu, May 12, 2016 at 6:56 AM, Brian Curtin <br...@python.org> wrote:

> On Thu, May 12, 2016 at 1:24 AM, Joseph Robinson
> <joseph.robin...@rackspace.com> 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:
> >>>
> >>>> So, before developer frustrations drive some or all projects to move
> >>>> their documentation in-tree which which negatively impacts the goal of
> >>>> presenting a coherent product, I suggest establishing an agreement
> >>>> between developers and the documentation team regarding the review
> >>>> process.
> >>>
> >>> My 2c, but it's said all over the place that OpenStack is not a
> product,
> >>> but a framework. So perhaps the goal you're pursuing is not working
> >>> because it's not accessible by design?
> >>>
> >>>> 1) The documentation team should review the patch for compliance with
> >>>> conventions (proper structure, format, grammar, spelling, etc.) and
> >>>>provide
> >>>> feedback to the developer who updates the patch.
> >>>> 2) The documentation team should modify the patch to make it compliant
> >>>>and
> >>>> ask the developer for a final review to prior to merging it.
> >>>> 3) The documentation team should only modify the patch to make it
> >>>>build (if
> >>>> necessary) and quickly merge it with a documentation bug to resolve
> any
> >>>> compliance problems in a future patch by the documentation team.
> >
> > I like the idea of options 2 and 3. Specifically though, I think Option 3
> > - merging content that builds, and checking out a bug to improve the
> > quality - can work in some cases. With a dedicated teams on several
> > guides, docs contributors would be able to pick up bugs right away -
> > that¹s my 2c.
>
> This is just enabling technical debt as process and ultimately hurts
> the users of the docs who end up with poorly worded or incorrect
> information by letting subpar -- but syntactically correct --
> documentation in. Even a dedicated team isn't going to get around to
> everything, and someone coming in later to pick up bugs to document is
> less likely to be the right person to convey the proper explanation
> and details than the one who implemented the work.
>
> __
> 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
>
__
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

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

[Matt Kassawara]

Can you move this documentation to the networking guide where
operators/users can locate it more easily?

On Wed, May 11, 2016 at 3:26 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
wrote:

> Hi Matt,
>
> If you look through the documentation, there are steps described to
> install 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.
>>
>> On Wed, May 11, 2016 at 2:47 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
>> wrote:
>>
>>> Hi Matt,
>>>
>>>
>>> Here is the wiki - https://wiki.openstack.org/wiki/Neutron/L2-GW
>>>
>>> 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 Kapur <sukhdevka...@gmail.com>
>>>> 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 by using "pip install networking-l2gw"
>>>>>
>>>>> This release has several enhancements and fixes for issues discovered
>>>>> in liberty release.
>>>>>
>>>>> Thanks
>>>>> Sukhdev Kapur
>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> __
>>>> 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
>>>>
>>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>
__
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

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

[Matt Kassawara]

Do you have any examples of how to implement L2GW outside of DevStack?
Operators do not deploy on DevStack.

On Wed, May 11, 2016 at 2:47 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
wrote:

> Hi Matt,
>
>
> Here is the wiki - https://wiki.openstack.org/wiki/Neutron/L2-GW
>
> 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 Kapur <sukhdevka...@gmail.com>
>> 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 by using "pip install networking-l2gw"
>>>
>>> This release has several enhancements and fixes for issues discovered in
>>> liberty release.
>>>
>>> Thanks
>>> Sukhdev Kapur
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
>
__
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

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

[Matt Kassawara]

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 by using "pip install networking-l2gw"
>
> This release has several enhancements and fixes for issues discovered in
> liberty release.
>
> Thanks
> Sukhdev Kapur
>
>
> __
> 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
>
>
__
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

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

[Matt Kassawara]

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 AM, Carl Baldwin  wrote:

> Greetings all,
>
> This document [1] was superseded by this one [2] a while ago.  It
> looks like the source for [1] no longer exists but the web server
> still has a copy that it continues to serve up.  At least, that is the
> situation as far as I can tell.
>
> Can anyone help here?  Do we need to add something to the docs
> generation to clean up stale pages?
>
> Carl Baldwin
>
> [1]
> http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html
> [2]
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html
>
> __
> 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
>
__
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

Re: [openstack-dev] Wiki

[Matt Kassawara]

>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
surprisingly large number of people referencing old content (OpenStack
sites and external sites such as personal blogs) because they don't
understand our release names or cycle length and the content doesn't always
make it clear. For documentation on OpenStack sites in particular, Google
doesn't help by ranking old content fairly high. I suspect that confusion
around preferred location of content and chronic frustration around
contributing to the central documentation (let's fix it! [1]) caused
sporadic growth of content on the wiki. Replacing the wiki with a
combination of more formal documentation and blog posts makes sense
providing the blog posts contain obvious publication dates (or relevant
release cycle) and, if necessary, some sort of deprecation notice to guide
consumers toward newer, more relevant content. Also, if content in a blog
post becomes more formal documentation, reference it.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094390.html

On Wed, May 11, 2016 at 8:44 AM, Thierry Carrez 
wrote:

> Thierry Carrez wrote:
>
>> [...]
>> I'll soon start a thread on that. Since that goes a lot beyond the dev
>> community, I'll post it to the openstack general list and post a pointer
>> to it here.
>>
>
> See
> http://lists.openstack.org/pipermail/openstack/2016-May/016154.html
>
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
>
__
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

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

[Matt Kassawara]

Julien,

Project or framework... regardless of the word, consumers of OpenStack
(without additional knowledge) see it as a single entity. Anyway,
especially after implementing the big tent, the documentation team is not
large enough to assign one or more people to manage documentation in each
project repository (including bug triage and patch reviews) or attend
project meetings. As a result, the documentation team asks each project to
assign a liaison that advocates documentation with developers, assists
developers with contributing/maintaining documentation, and collaborates
with the documentation team. Collaboration includes bug triage, patch
reviews, attending meetings, and communicating via IRC and/or the mailing
list. Unfortunately, most projects do not collaborate effectively with the
documentation team which results in a disconnection between the
documentation team and projects/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
> > their documentation in-tree which which negatively impacts the goal of
> > presenting a coherent product, I suggest establishing an agreement
> > between developers and the documentation team regarding the review
> > process.
>
> My 2c, but it's said all over the place that OpenStack is not a product,
> but a framework. So perhaps the goal you're pursuing is not working
> because it's not accessible by design?
>
> > 1) The documentation team should review the patch for compliance with
> > conventions (proper structure, format, grammar, spelling, etc.) and
> provide
> > feedback to the developer who updates the patch.
> > 2) The documentation team should modify the patch to make it compliant
> and
> > ask the developer for a final review to prior to merging it.
> > 3) The documentation team should only modify the patch to make it build
> (if
> > necessary) and quickly merge it with a documentation bug to resolve any
> > compliance problems in a future patch by the documentation team.
> >
> > What do you think?
>
> We, Telemetry, are moving our documentation in-tree and are applying a
> policy of "no doc, no merge" (same policy we had for unit tests).
> So until the doc team starts to help projects with that (proof-reading,
> pointing out missing doc update in patches, etc) and trying to be part
> of actual OpenStack projects, I don't think your goal will ever work.
>
> For example, we have an up-to-date documentation in Gnocchi since the
> beginning, that covers the whole project. It's probably not coherent
> with the rest of OpenStack in wording etc, but we'd be delighted to have
> some folks of the doc team help us with that.
>
> Cheers,
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
>
__
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

[openstack-dev] Easing contributions to central documentation

[Matt Kassawara]

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 the recent summit involves the review process,
particularly the lengthy amount of time patches sit in the review queue
with -1s for various "conventions" problems such as structure, formatting,
grammar, spelling, etc. Unlike most OpenStack developers that focus on a
particular project, the documentation team covers all projects and lacks
the capacity to understand each one enough to contribute and maintain
technically accurate documentation in a timely manner. However, covering
all projects enables the documentation team to organize and present the
documentation to various audiences, primarily operators and users, that
consume OpenStack as a coherent product. In other words, the entire process
relies on developers contributing to the central documentation. So, before
developer frustrations drive some or all projects to move their
documentation in-tree which which negatively impacts the goal of presenting
a coherent product, I suggest establishing an agreement between developers
and the documentation team regarding the review process.

As much as the documentation team wants to present OpenStack as a coherent
product, it contains many projects with different contribution processes.
In some cases, individual developers prefer to contribute in unique ways.
Thus, the conventional "one-size-fits-all" approach that the documentation
team historically takes with reviewing contributions from developers yields
various levels of frustration among projects and developers. I ran a
potential solution by various developers during the recent summit and
received enough positive feedback to discuss it with a larger audience. So,
here goes...

A project or individual developer decides the level of documentation team
involvement with reviewing patches. The developer adds a WIP to the
documentation patch while adding content to prevent premature reviews by
the documentation team. Once the content achieves a sufficient level of
technical accuracy, the developer removes the WIP and adds a comment in the
review indicating of the following preferences:

1) The documentation team should review the patch for compliance with
conventions (proper structure, format, grammar, spelling, etc.) and provide
feedback to the developer who updates the patch.
2) The documentation team should modify the patch to make it compliant and
ask the developer for a final review to prior to merging it.
3) The documentation team should only modify the patch to make it build (if
necessary) and quickly merge it with a documentation bug to resolve any
compliance problems in a future patch by the documentation team.

What do you think?
__
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

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

[Matt Kassawara]

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 impression that OpenStack consists of many loosely associated
projects rather than a coherent cloud computing solution. However, as a
contributor to a few other OpenStack projects who helps other developers
contribute to central documentation, I can understand some of the
frustrations with it. I prefer to resolve these frustrations and have some
ideas that I intend to float in separate thread, but if you don't think
that's possible, consider submitting a spec to change the primary purpose
of the central documentation team to simply managing links to content in
the project trees.

On Fri, May 6, 2016 at 10:03 AM, Ildikó Váncsa 
wrote:

> Hi Lana,
>
> Thanks for the summary, it's pretty good reading to catch up what happened
> recently.
>
> I have one question, I might missed a few entries, so please point me to
> the right document in this case. We had a docco session with the Telemetry
> team and we agreed on moving back the documentation snippets, like for
> instance the Install Guide, to the project trees is a really good step and
> we're very supportive. In this sense I would like to ask about the plans
> regarding the Admin guide. We have a chapter there, which is on one hand
> outdated and on the other hand would be better to move under the project
> trees as well. Is this plan/desire in line with your plans regarding that
> document?
>
> Thanks,
> /Ildikó
>
> > -Original Message-
> > From: Lana Brindley [mailto:openst...@lanabrindley.com]
> > Sent: May 06, 2016 08:13
> > To: enstack.org; OpenStack Development Mailing List;
> openstack-i...@lists.openstack.org
> > Subject: What's Up, Doc? 6 May 2016
> >
> > Hi everyone,
> >
> > I hope you all had a safe journey home from Summit, and are now fully
> recovered from all the excitement (and jetlag)! I'm really
> > pleased with the amount of progress we made this time around. We have a
> definitive set of goals for Newton, and I'm confident that
> > they're all moving us towards a much better docs suite overall. Of
> course, the biggest and most important work we have to do is to get
> > our Install Guide changes underway. I'm very excited to see the new
> method for documenting OpenStack installation, and can't wait
> > to see all our big tent projects contributing to docs in such a
> meaningful way. Thank you to everyone (in the room and online) who
> > contributed to the Install Guide discussion, and helped us move forward
> on this important project.
> >
> > In other news, I've written a wrapup of the Austin design summit on my
> blog, which you might be interested in:
> > http://lanabrindley.com/2016/05/05/openstack-newton-summit-docs-wrapup/
> >
> > == Progress towards Newton ==
> >
> > 152 days to go!
> >
> > Bugs closed so far: 61
> >
> > Because we have such a specific set of deliverables carved out for
> Newton, I've made them their own wiki page:
> > https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
> > Feel free to add more detail and cross things off as they are achieved
> throughout the release. I will also do my best to ensure it's kept
> > up to date for each newsletter.
> >
> > One of the first tasks we've started work on after Summit is moving the
> Ops and HA Guides out of their own repositories and into
> > openstack-manuals. As a result, those repositories are now frozen, and
> any work you want to do on those books should be in
> > openstack-manuals.
> >
> > We are almost ready to publish the new RST version of the Ops Guide,
> there's just a few cleanup edits going in now, so make sure you
> > have the right book, in the right repo from now on. This was our very
> last book remaining in DocBook XML, so the docs toolchain will
> > be removing DocBook XML support. See spec
> https://review.openstack.org/311698 for details.
> >
> > Another migration note is that the API reference content is moving from
> api-site to project specific repositories and api-site is now
> > frozen. For more detail, see Anne's email:
> http://lists.openstack.org/pipermail/openstack-docs/2016-May/008536.html
> >
> > == Mitaka wrapup ==
> >
> > We performed a Mitaka retrospective at Summit, notes are here:
> https://etherpad.openstack.org/p/austin-docs-mitakaretro
> >
> > In particular, I'd like to call out our hard working tools team Andreas
> and Christian, all our Speciality Team leads, and the Mitaka release
> > managers Brian and Olga. Well done on a very successful release,
> everyone :)
> >
> > Total bugs closed: 645
> >
> > == Site Stats ==
> >
> > Thanks to the lovely people at Foundation (thanks Allison!) I now have
> access to more stats than I could possibly guess what to do
> > with, and I'm hoping to be 

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

[Matt Kassawara]

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 configuring certain options prevents surprises if default values
change. Automatic configuration file generation and the release notes
mechanism makes detection of these changes a bit easier, but building
confidence takes time.

On Mon, Apr 11, 2016 at 8:39 AM, Sean M. Collins  wrote:

> Armando M. wrote:
> > My understanding of the plan to overhaul the neutron (bloated) layer
> > present in DevStack being tackled in [1] has always been that this was
> > about trimming the layer rather than eliminating it altogether. Is this
> > email a reflection of a desire to change direction? If so, SeanC please
> > clarify because I am slightly confused.
>
> As part of the DevStack refactor, I am trying to shrink the amount of
> DevStack configuration variables that are carried around for Neutron.
> That is the part I am trying to eliminate. There must be support for
> Neutron in DevStack, if we ever wish to become the default networking
> project in OpenStack and successfully deprecate nova-network.
>
> > To the very minimum we'd need to find the right blend of config variables
> > which (in conjunction with some other *optional* local.conf extra juice)
> > produce the Neutron configuration files that we have in the gate, namely
> > OVS, LB and OVS+DVR, with their multi-node variants, and thus allow us to
> > get happy pass with Grenade/Tempest (if that means skipping some tests so
> > be it) across all the branches we currently gate against. The rest of the
> > layer can be stripped to the bare bone, but without it we're basically
> > gonna have to deal with long local.conf files with entire chunks of agent
> > files etc. thus making Neutron support for repos like devstack-gate and
> > project-config rather more painful (I am assuming we're gonna have to use
> > the new layer/approach at some point?). Bear in mind that the complexity
> > bubble needs to move/split, it's not just gonna burst and vanish :)
>
> It is my hope that we can start looking at some of these configurations,
> take a look at what puppet or ansible set, and realize that a lot of
> these options could just be defaults instead of making it the job of
> deployment tools to explicitly configure.
>
> > On another note, we'd have to keep in mind neutron_plugins that currently
> > have a place in the devstack tree and/or that rely on the existing
> > neutron_legacy bits. What's the plan for those (e.g. networking-[ovn,
> odl,
> > ...] et al)? Finally, what's the plan for switching in the gate?
>
> I think neutron_plugins will eventually be removed. Third party plugins
> like ovn, odl, et al most likely have DevStack plugins that supersede
> the code in neutron_plugins.
>
> For the OVS and LB agents, I think we need to clean them up, and again,
> see what can be configured by default.
>
> --
> Sean M. Collins
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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  wrote:

> On 04/01/2016 12:00 PM, Fox, Kevin M wrote:
>
>> And with external rbac in mitaka, you can finally have private floating
>> ip's. :)
>>
>
> Wha. I mean.
>
> My face. It just fell off.
>
> 
>> *From:* Monty Taylor
>> *Sent:* Thursday, March 31, 2016 10:23:22 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent
>>
>>
>> Just a friendly reminder to everyone - floating IPs are not synonymous
>> with Public IPs in OpenStack.
>>
>> The most common (and growing, thank you to the beta of the new
>> Dreamcompute cloud) configuration for Public Clouds is directly assign
>> public IPs to VMs without requiring a user to create a floating IP.
>>
>> I have heard that the require-floating-ip model is very common for
>> private clouds. While I find that even stranger, as the need to run NAT
>> inside of another NAT is bizarre, it is what it is.
>>
>> Both models are common enough that pretty much anything that wants to
>> consume OpenStack VMs needs to account for both possibilities.
>>
>> It would be really great if we could get the default config in devstack
>> to be to have a shared direct-attached network that can also have a
>> router attached to it and provider floating ips, since that scenario
>> actually allows interacting with both models (and is actually the most
>> common config across the OpenStack public clouds)
>>
>> Monty
>>
>> __
>> 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
>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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
do.

First, a little history about the guide...

The installation guide often provides the first experience for people
trying OpenStack. Thus, the guide should provide not just a good
experience, but a great experience. We can all agree on wanting more
adoption of OpenStack. For many people, launching an instance and being
able to access it feels like summiting a mountain. My first experience with
OpenStack involved nearly a month of trying to install Grizzly with neutron
for evaluation purposes using the installation guide. It didn't work.
Looking at various support channels such as IRC and ask.openstack.org, most
people were stuck at the same place without any answers. I finally
determined that nova lacked the configuration telling it to use neutron for
networking, so it kept attempting to build nova networks when those
components didn't exist. I opened a bug and someone fixed it. Shortly
thereafter, I began addressing the seemingly infinite number of
installation guide bugs. However, the cycle of frustration was beginning to
repeat itself with Havana. The reactive method of finding a problem,
opening a bug, and waiting for a patch simply wasn't working for our
audience of potential operators, not developers, that just expect it to
work.

So, I proposed changing the guide from reactive to proactive. In other
words, we update and test the guide prior to release for every distribution
it supports. We began this approach with Icehouse and saw a decrease in
bugs and frustration. Furthermore, when assisting people through various
support channels, we could more easily determine whether the problem was a
just a typo or a problem with the guide. However, proactively maintaining
the guide put a significant burden on the contributors. Gone were the days
of "fire-and-forget" patches. Almost all patches require actual testing,
sometimes across several distributions. Updating the guide for the next
release requires performing full installations, often several times per
distribution, until we can successfully install and test all services
without deviating from the instructions. A considerable amount of work,
especially about a month before release when contributors who involve
themselves in other projects are also busy trying to release those
projects. Thus, the installation guide has seen a decrease in contributions
making it increasingly difficult to update and test for each release.
Furthermore, the installation guide receives little, if any, support from
most projects including "core" projects. Even if those projects know about
the installation guide, most assume that the documentation team magically
updates it for every release to deploy each service in a basic fashion
accounting for configuration changes and recommendations. From the
perspective of a project developer, those updates probably seem simple.
Just read the code, track patches, and maybe attend some meetings, right?
>From the perspective of installation guide contributors, we can't involve
ourselves that deeply in one project let alone nearly ten projects. Imagine
us trying to consider big tent projects? We have begged projects for years
to provide resources for maintaining the installation guide. If nothing
else, provide some notes on an etherpad indicating what we should change.
At this point in the game, we shouldn't have to resort to deprecation
messages or gate job configurations to determine how to deploy a service.

Regarding use of distribution packages instead of source...

The guide uses distribution packages instead of source because our audience
is usually familiar with them and they eliminate a significant number of
steps in an already complex and often overwhelming process. For example,
packages manage dependencies and provide init scripts. The installation
guide teaches our audience how to deploy the most common OpenStack services
for evaluation purposes. For example, our audience quickly learns that each
service typically depends on keystone, a database, and a message queue.
After getting comfortable with the installation process, we recommend
implementing redundancy/security on top of a basic installation and
eventually tooling for a production deployment.

Distribution packages aren't perfect by any means. First, they usually lag
the upstream release cycle by several weeks which forces us to update and
test changes using milestones, sometimes not even the last "feature-freeze"
milestone, after the first release candidate appears upstream. Next, they
sometimes contain bugs and packagers seldom contribute resources to triage
and address them which forces us to implement workarounds that can confuse
or distract our audience. Finally, and 

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

[Matt Kassawara]

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
> docs.openstack.org/developer is usually the more appropriate place, at
> least to begin with. This should probably be made more explicit both in the
> Infra Manual, plus anywhere that Foundation is discussing big tent
> inclusion.


We tell operators and users to look at the documentation on
docs.openstack.org because the documentation in /developer is aimed at
developers and often lacks polish. Now we're telling developers to put
operator/user documentation into /developer?
__
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

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

[Matt Kassawara]

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 up
> again
> --
> Sean M. Collins
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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 drivers, the network_device_mtu option only impacts parts of some
in-tree drivers, and path_mtu only provides a way to change the MTU for VMs
for all in-tree drivers. I ran my experiments without any of these options
to provide a clean slate for empirically analyzing the problem and finding
a solution for the majority of operators.

Matt

On Mon, Jan 25, 2016 at 6:31 AM, Sean M. Collins  wrote:

> On Mon, Jan 25, 2016 at 01:37:55AM EST, Kevin Benton wrote:
> > At a minimum I think we should pick a default in devstack and dump a
> > warning in neutron if operators don't specify it.
>
> Here's the DevStack change that implements this.
>
> https://review.openstack.org/#/c/267604/
>
> Again this just fixes it for DevStack. Deployers still need to set the
> MTUs by hand in their deployment tool of choice. I would hope that we
> can still move forward with some sort of automatic discovery - and also
> figure out a way to take it from 3 different config knobs down to like
> one master knob, for the sake of sanity.
>
> --
> Sean M. Collins
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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 controller and compute nodes. Most
of the problems involve MTU disparities in security group bridge components
on the compute node.

First, review the OpenStack bits and resulting network components in the
environment [1] and see that a typical 'ping' works using IPv4 and IPv6 [2].

[1] https://gist.github.com/ionosphere80/23655bedd24730d22c89
[2] https://gist.github.com/ionosphere80/5f309e7021a830246b66

Note: The tcpdump output in each case references up to seven points:
neutron router gateway on the public network (qg), namespace end of the
neutron router interface on the private network (qr), controller node end
of the VXLAN network (underlying interface), compute node end of the VXLAN
network (underlying interface), Open vSwitch end of the veth pair for the
security group bridge (qvo), Linux bridge end of the veth pair for the
security group bridge (qvb), and the bridge end of the tap for the VM (tap).

I can use SSH to access the VM because every component between my host and
the VM supports at least a 1500 MTU. So, let's configure the VM network
interface to use the proper MTU of 9000 minus the VXLAN protocol overhead
of 50 bytes... 8950... and try SSH again.

2: eth0:  mtu 8950 qdisc pfifo_fast qlen
1000
link/ether fa:16:3e:ea:22:3a brd ff:ff:ff:ff:ff:ff
inet 172.16.1.3/24 brd 172.16.1.255 scope global eth0
inet6 fd00:100:52:1:f816:3eff:feea:223a/64 scope global dynamic
   valid_lft 86396sec preferred_lft 14396sec
inet6 fe80::f816:3eff:feea:223a/64 scope link
   valid_lft forever preferred_lft forever

Contrary to the Linux bridge experiment, I can still use SSH to access the
VM. Why?

Let's ping with a payload size of 8922 for IPv4 and 8902 for IPv6, the
maximum for a VXLAN segment with 8950 MTU.

# ping -c 1 -s 8922 -M do 10.100.52.102
PING 10.100.52.102 (10.100.52.102) 8922(8950) bytes of data.
>From 10.100.52.102 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 10.100.52.102 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

# ping6 -c 1 -s 8902 -M do fd00:100:52:1:f816:3eff:feea:223a
PING fd00:100:52:1:f816:3eff:feea:223a(fd00:100:52:1:f816:3eff:feea:223a)
8902 data bytes
>From fd00:100:52::101 icmp_seq=1 Packet too big: mtu=1500

--- fd00:100:52:1:f816:3eff:feea:223a ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Look at the tcpdump output [3]. The router namespace, operating at layer-3,
sees the MTU discrepancy between inbound packet and the neutron router
gateway on the public network and returns an ICMP "fragmentation needed" or
"packet too big" message to the sender. The sender uses the MTU value in
the ICMP packet to recalculate the length of the first packet and caches it
for future packets.

[3] https://gist.github.com/ionosphere80/4e1389a34fd3a628b294

Although PTMUD enables communication between my host and the VM, it limits
MTU to 1500 regardless of the MTU between the router namespace and VM and
therefore could impact performance on 10 Gbps or faster networks. Also, it
does not address the MTU disparity between a VM and network components on
the compute node. If a VM uses a 1500 or smaller MTU, it cannot send
packets that exceed the MTU of the tap interface, veth pairs, and bridge on
the compute node. In this situation which seems fairly typical for
operators trying to work around MTU problems, communication between a host
(outside of OpenStack) and a VM always works. However, what if a VM uses a
MTU larger than 1500 and attempts to send a large packet? The bridge or
veth pairs would drop it because of the MTU disparity.

Using observations from the Linux bridge experiment, let's configure the
MTU of the interfaces in the router namespace to match the interfaces
outside of the namespace. The public network (gateway) interface MTU
becomes 9000 and the private network router interfaces (IPv4 and IPv6)
become 8950.

31: qr-d744191c-9d:  mtu 8950 qdisc
noqueue state UNKNOWN mode DEFAULT group default
link/ether fa:16:3e:34:67:40 brd ff:ff:ff:ff:ff:ff
32: qr-ae54b450-b4:  mtu 8950 qdisc
noqueue state UNKNOWN mode DEFAULT group default
link/ether fa:16:3e:d4:f1:63 brd ff:ff:ff:ff:ff:ff
33: qg-e3303f07-e7:  mtu 9000 qdisc
noqueue state UNKNOWN mode DEFAULT group default
link/ether fa:16:3e:70:09:54 brd ff:ff:ff:ff:ff:ff

Let's ping again with a payload size of 8922 for IPv4, the maximum for a
VXLAN segment with 8950 MTU, and look at the tcpdump output [4]. For
brevity, I'm only showing IPv4 because IPv6 provides similar results.

# ping -c 1 

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

[Matt Kassawara]

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 than a
boolean. I envision one configuration option containing the physical
network MTU that neutron uses to calculate the MTU of all virtual network
components. Mike... this mechanism should work for any physical network
MTU, large or small.

Matt

On Sat, Jan 23, 2016 at 3:28 PM, Mike Spreitzer  wrote:

> Adam Lawson  wrote on 01/23/2016 02:27:46 PM:
>
> > For the sake of over-simplification, is there ever a reason to NOT
> > enable jumbo frames in a cloud/SDN context where most of the traffic
> > is between virtual elements that all support it? I understand that
> > some switches do not support it and traffic form the web doesn't
> > support it either but besides that, seems like a default
> > "jumboframes = 1" concept would work just fine to me.
> >
> > Then again I'm all about making OpenStack easier to consume so my
> > ideas tend to gloss over special use cases with special requirements.
>
> Regardless of the default, there needs to be clear documentation on what
> to do for those of us who can not use jumbo frames, and it needs to work.
> That goes for production deployers and also for developers using DevStack.
>
> Thanks,
> Mike
>
>
>
> __
> 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
>
>
__
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

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

[Matt Kassawara]

st packet and caches it
for future packets.

# ping -c 1 -s 8923 -M do 10.100.52.104
PING 10.100.52.104 (10.100.52.104) 8923(8951) bytes of data.
>From 10.100.52.104 icmp_seq=1 Frag needed and DF set (mtu = 8950)

--- 10.100.52.104 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

# ping6 -c 1 -s 8903 -M do fd00:100:52:1:f816:3eff:fe46:acd3
PING fd00:100:52:1:f816:3eff:fe46:acd3(fd00:100:52:1:f816:3eff:fe46:acd3)
8903 data bytes
>From fd00:100:52::101 icmp_seq=1 Packet too big: mtu=8950

--- fd00:100:52:1:f816:3eff:fe46:acd3 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

# ip route get to 10.100.52.104
10.100.52.104 dev eth1  src 10.100.52.45
cache  expires 596sec mtu 8950

# ip route get to fd00:100:52:1:f816:3eff:fe46:acd3
fd00:100:52:1:f816:3eff:fe46:acd3 from :: via fd00:100:52::101 dev eth1
 src fd00:100:52::45  metric 0
cache  expires 556sec mtu 8950

Finally, let's try SSH.

# ssh cirros@10.100.52.104
cirros@10.100.52.104's password:
$

# ssh cirros@fd00:100:52:1:f816:3eff:fe46:acd3
cirros@fd00:100:52:1:f816:3eff:fe46:acd3's password:
$

SSH works for both IPv4 and IPv6.

This experiment reaches the same conclusion as the first experiment.
However, using physical hardware that supports jumbo frames reveals an
additional problem with the veth pair for the neutron router interface on
the public network. For any MTU, we can address the egress MTU disparity
(from the VM) by advertising the MTU of the overlay network to the VM via
DHCP/RA or using manual interface configuration. Additionally, IP protocol
version does not impact MTU calculation for Linux bridge.

Hopefully moving to physical hardware makes this experiment easier to
understand and the conclusion more useful for realistic networks.

Matt

On Wed, Jan 20, 2016 at 11:18 AM, Rick Jones <rick.jon...@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'd have to look at the RFCs for how hosts are supposed to behave since
>> IPv6 has a minimum MTU of 1280 bytes while IPv4's minimum mtu is 576
>> (what is this, an MTU for ants?).
>>
>
> Quibble - 576 is the IPv4 minimum, maximum MTU.  That is to say a
> compliant IPv4 implementation must be able to reassemble datagrams of at
> least 576 bytes.
>
> If memory serves, the actual minimum MTU for IPv4 is 68 bytes.
>
> rick jones
>
>
> __
> 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
>
__
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

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

[Matt Kassawara]

No. However, we ought to determine what happens when both DHCP and RA
advertise it.

On Tue, Jan 19, 2016 at 12:36 AM, Kevin Benton <blak...@gmail.com> wrote:

> >Yup. We mostly attempt to do that now.
>
> Right, but not by default. Can you think of a scenario where advertising
> 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.
>>>
>>> >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 message from the host instead of a
>>> namespace. Therefore, the message never reaches the destination...
>>> typically a host outside of the deployment.
>>>
>>> I suspect this is because we don't put the bridges into namespaces. Even
>>> if we did do this, we would need to allocate IP addresses for every compute
>>> node to use to chat on the network...
>>>
>>
>> Yup. Moving the MTU disparity to the first layer-3 device a packet
>> traverses inbound to a VM saves us from burning IPs too.
>>
>>
>>>
>>>
>>>
>>> >At least for the Linux bridge agent, I think we can address ingress
>>> MTU disparity (to the VM) by moving it to the first device in the chain
>>> capable of layer-3 operations, particularly the neutron router namespace.
>>> We can address the egress MTU disparity (from the VM) by advertising the
>>> MTU of the overlay network to the VM via DHCP/RA or using manual interface
>>> configuration.
>>>
>>> So when setting up DHCP for the subnet, would telling the DHCP agent to
>>> use an MTU we calculate based on (global MTU value - network encap
>>> overhead) achieve what you are suggesting here?
>>>
>>
>> Yup. We mostly attempt to do that now.
>>
>> On Fri, Jan 15, 2016 at 10:41 AM, Sean M. Collins <s...@coreitpro.com>
>>>> wrote:
>>>>
>>>>> MTU has been an ongoing issue in Neutron for _years_.
>>>>>
>>>>> It's such a hassle, that most people just throw up their hands and set
>>>>> their physical infrastructure to jumbo frames. We even document it.
>>>>>
>>>>>
>>>>> http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html
>>>>>
>>>>> > Ideally, you can prevent these problems by enabling jumbo frames on
>>>>> > the physical network that contains your tenant virtual networks.
>>>>> Jumbo
>>>>> > frames support MTUs up to approximately 9000 bytes which negates the
>>>>> > impact of GRE overhead on virtual networks.
>>>>>
>>>>> We've pushed this onto operators and deployers. There's a lot of
>>>>> code in provisioning projects to handle MTUs.
>>>>>
>>>>> http://codesearch.openstack.org/?q=MTU=nope==
>>>>>
>>>>> We have mentions to it in our architecture design guide
>>>>>
>>>>>
>>>>> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/arch-design/source/network-focus-architecture.rst#n150
>>>>>
>>>>> I want to get Neutron to the point where it starts discovering this
>>>>> information and automatically configuring, in the optimistic cases. I
>>>>> understand that it can be complex and have corner cases, but the issue
>>>>> we have today is that it is broken in some multinode jobs, even Neutron
>>>>> developers are configuring it correctly.
>>>>>
>>>>> I also had this discussion on the DevStack side in
>>>>> https://review.openstack.org/#/c/112523/
>>>>> where basically, sure we can fix it in DevStack and at the gate, but it
>>>>> doesn't fix the problem for anyone who isn't using DevStack to deploy
>>>>> their cloud.
>>>>>
>>>>> Today we have a ton of MTU configuration options sprinkled throghout
>>>>> the
>>>>> L3 agent, dhcp agent, l2 agents, and at least one API extension to the
>>>>> REST API for handling MTUs.
>>>>>
>>>>> So yeah, a lot of knobs and not a lot of documentat

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

[Matt Kassawara]

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 message from the host instead of a
> namespace. Therefore, the message never reaches the destination...
> typically a host outside of the deployment.
>
> I suspect this is because we don't put the bridges into namespaces. Even
> if we did do this, we would need to allocate IP addresses for every compute
> node to use to chat on the network...
>

Yup. Moving the MTU disparity to the first layer-3 device a packet
traverses inbound to a VM saves us from burning IPs too.


>
>
>
> >At least for the Linux bridge agent, I think we can address ingress MTU
> disparity (to the VM) by moving it to the first device in the chain capable
> of layer-3 operations, particularly the neutron router namespace. We can
> address the egress MTU disparity (from the VM) by advertising the MTU of
> the overlay network to the VM via DHCP/RA or using manual interface
> configuration.
>
> So when setting up DHCP for the subnet, would telling the DHCP agent to
> use an MTU we calculate based on (global MTU value - network encap
> overhead) achieve what you are suggesting here?
>

Yup. We mostly attempt to do that now.

On Fri, Jan 15, 2016 at 10:41 AM, Sean M. Collins 
>> wrote:
>>
>>> MTU has been an ongoing issue in Neutron for _years_.
>>>
>>> It's such a hassle, that most people just throw up their hands and set
>>> their physical infrastructure to jumbo frames. We even document it.
>>>
>>>
>>> http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html
>>>
>>> > Ideally, you can prevent these problems by enabling jumbo frames on
>>> > the physical network that contains your tenant virtual networks. Jumbo
>>> > frames support MTUs up to approximately 9000 bytes which negates the
>>> > impact of GRE overhead on virtual networks.
>>>
>>> We've pushed this onto operators and deployers. There's a lot of
>>> code in provisioning projects to handle MTUs.
>>>
>>> http://codesearch.openstack.org/?q=MTU=nope==
>>>
>>> We have mentions to it in our architecture design guide
>>>
>>>
>>> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/arch-design/source/network-focus-architecture.rst#n150
>>>
>>> I want to get Neutron to the point where it starts discovering this
>>> information and automatically configuring, in the optimistic cases. I
>>> understand that it can be complex and have corner cases, but the issue
>>> we have today is that it is broken in some multinode jobs, even Neutron
>>> developers are configuring it correctly.
>>>
>>> I also had this discussion on the DevStack side in
>>> https://review.openstack.org/#/c/112523/
>>> where basically, sure we can fix it in DevStack and at the gate, but it
>>> doesn't fix the problem for anyone who isn't using DevStack to deploy
>>> their cloud.
>>>
>>> Today we have a ton of MTU configuration options sprinkled throghout the
>>> L3 agent, dhcp agent, l2 agents, and at least one API extension to the
>>> REST API for handling MTUs.
>>>
>>> So yeah, a lot of knobs and not a lot of documentation on how to make
>>> this thing work correctly. I'd like to try and simplify.
>>>
>>>
>>> Further reading:
>>>
>>>
>>> http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html
>>>
>>> http://lists.openstack.org/pipermail/openstack/2013-October/001778.html
>>>
>>>
>>> https://ask.openstack.org/en/question/6140/quantum-neutron-gre-slow-performance/
>>>
>>>
>>> https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/
>>>
>>>
>>> http://blog.systemathic.ch/2015/03/05/openstack-mtu-pitfalls-with-tunnels/
>>>
>>> https://twitter.com/search?q=openstack%20neutron%20MTU
>>>
>>> --
>>> Sean M. Collins
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> 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
>
>

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

[Matt Kassawara]

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:

> Hey Kendall,
>
> Sure. Count me in! :)
>
> Thanks,,
> Martin
>
>
> [image: Inactive hide details for "Kendall J Nelson" ---06/01/2016
> 16:57:41---Hey Martin, I thought it might be interesting to get a]"Kendall
> J Nelson" ---06/01/2016 16:57:41---Hey Martin, I thought it might be
> interesting to get a panel discussion at the
>
> From: "Kendall J Nelson" 
> To: "OpenStack Development Mailing List \(not for usage questions\)" <
> openstack-dev@lists.openstack.org>
> Date: 06/01/2016 16:57
>
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Hey Martin,
>
> I thought it might be interesting to get a panel discussion at the Summit
> to discuss the lack of consistency/ work towards a more universal way of
> using the oslo config generator. Would you be interested? I was hoping to
> get someone from Neutron, Nova and Keystone and I could represent Cinder.
>
> All the Best,
> *Kendall J. Nelson*
> Software Engineer  Cinder Contributor
> --
> *E-mail:* *kjnel...@us.ibm.com* 
> *Cell Phone:* (952) 215- 4025
> *IRC Nickname:* diablo_rojo
> [image: IBM]
>
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
>
>
> [image: Inactive hide details for "Martin Hickey" ---01/06/2016 06:34:59
> AM---Hi Jay, +1 on the lack of consistency between projects. W]"Martin
> Hickey" ---01/06/2016 06:34:59 AM---Hi Jay, +1 on the lack of consistency
> between projects. When adding the generator
>
> From: "Martin Hickey" 
> To: jsbry...@electronicjungle.net, "OpenStack Development Mailing List
> \(not for usage questions\)" 
> Date: 01/06/2016 06:34 AM
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Hi Jay,
>
> +1 on the lack of consistency between projects. When adding the generator
> to Neutron, we could not find a consistent pattern so we tried to adopt as
> best as possible.
>
> Let me know if you need any feedback on the Neutron experience.
>
> Regards,
> Martin
>
>
> [image: Inactive hide details for "Jay S. Bryant" ---05/01/2016
> 19:56:25---Ben, Please see my in-line responses ...]"Jay S. Bryant"
> ---05/01/2016 19:56:25---Ben, Please see my in-line responses ...
>
> From: "Jay S. Bryant" 
> To: openst...@nemebean.com, "OpenStack Development Mailing List (not for
> usage questions)" 
> Date: 05/01/2016 19:56
> Subject: Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> --
>
>
>
> Ben,
>
> Please see my in-line responses ...
>
> On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> >> Hello,
> >>
> >>
> >> In brainstorming ideas for talks at the upcoming summit, I thought about
> >> some of the things I had worked on for Cinder and what could still be
> >> improved. One of the things I have been looking into is the generation
> >> of sample configuration option files. Upon initial research it looks
> >> like none of the main projects are doing it the same way.
> > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
> > (at least) are all using the oslo-config-generator tool for this.  There
> > might be some slight variation in how they call it, but they are using
> it.
> Yes, we know that they are all using oslo-config-generator but there is
> not consistency
> in how the information that oslo-config-generator needs to do its job is
> being created.
> Kendall is looking to better understand what we should be doing and try
> to bring
> greater consistency between the projects.
>
> > I only vaguely recall having discussions about this with Cinder, so I'd
> > be interested in a refresher around why Cinder didn't want to do it the
> > same way.  I kind of considered it a solved problem.
> So, the challenge Cinder has is the fact that there are many
> configuration options with all the
> different drivers.  We had proposed a static cinder/opts.py file with
> hacking checks to ensure
> that all new options were pulled into the file.  This was considered
> undesirable.  This lead to
> the current solution where we are working to find all the possible
> option lists to dynamically
> create the cinder/opts.py file.  Similar to what we used to do with the
> old config generator.
>
> For Nova, having a dynamic solution is less important as they don't have
> options changing
> as frequently.  It appears that 

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

[Matt Kassawara]

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 choose between these
architectures.

[1] https://review.openstack.org/#/c/221560/
[2] http://docs.openstack.org/networking-guide/deploy.html

Matt

On Tue, Sep 15, 2015 at 9:04 AM, Monty Taylor  wrote:

> Hey all!
>
> If any of you have ever gotten drunk with me, you'll know I hate floating
> IPs more than I hate being stabbed in the face with a very angry fish.
>
> However, that doesn't really matter. What should matter is "what is the
> most sane thing we can do for our users"
>
> As you might have seen in the glance thread, I have a bunch of OpenStack
> public cloud accounts. Since I wrote that email this morning, I've added
> more - so we're up to 13.
>
> auro
> citycloud
> datacentred
> dreamhost
> elastx
> entercloudsuite
> hp
> ovh
> rackspace
> runabove
> ultimum
> unitedstack
> vexxhost
>
> Of those public clouds, 5 of them require you to use a floating IP to get
> an outbound address, the others directly attach you to the public network.
> Most of those 8 allow you to create a private network, to boot vms on the
> private network, and ALSO to create a router with a gateway and put
> floating IPs on your private ip'd machines if you choose.
>
> Which brings me to the suggestion I'd like to make.
>
> Instead of having our default in devstack and our default when we talk
> about things be "you boot a VM and you put a floating IP on it" - which
> solves one of the two usage models - how about:
>
> - Cloud has a shared: True, external:routable: True neutron network. I
> don't care what it's called  ext-net, public, whatever. the "shared" part
> is the key, that's the part that lets someone boot a vm on it directly.
>
> - Each person can then make a private network, router, gateway, etc. and
> get floating-ips from the same public network if they prefer that model.
>
> Are there any good reasons to not push to get all of the public networks
> marked as "shared"?
>
> OH - well, one thing - that's that once there are two networks in an
> account you have to specify which one. This is really painful in nova
> clent. Say, for instance, you have a public network called "public" and a
> private network called "private" ...
>
> You can't just say "nova boot --network=public" - nope, you need to say
> "nova boot --nics net-id=$uuid_of_my_public_network"
>
> So I'd suggest 2 more things;
>
> a) an update to python-novaclient to allow a named network to be passed to
> satisfy the "you have more than one network" - the nics argument is still
> useful for more complex things
>
> b) ability to say "vms in my cloud should default to being booted on the
> public network" or "vms in my cloud should default to being booted on a
> network owned by the user"
>
> Thoughts?
>
> Monty
>
> __
> 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
>
__
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

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

[Matt Kassawara]

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 a thousand words, so if you want to draw something, you might as well
do it right.

Documentation that developers primarily reference (and maintain) probably
benefits from the path of least resistance. In other words, not learning a
new application or adhering to conventions such as fonts, color schemes,
etc. If a text-type diagram can convey the information to other developers
without becoming difficult to interpret or maintain, use it.

However, we should take a different approach for documentation that anyone
other than developers might reference. After all, documentation plays a
significant role in first impressions and text-type diagrams don't convey
the professional, commercially viable product vibe to people who make
decisions about adopting and implementing OpenStack. Therefore, such
documentation benefits from image-type diagrams that adhere to conventions.

When in doubt, ask the documentation team. Most of us don't specialize in
the development of any particular service and can therefore provide an
outside opinion about the format, content, and potential audience of a
diagram. Furthermore, we don't mind collaborating with developers to draw
diagrams in any format or simply convert existing text-type diagrams to
image-type diagrams.

Matt

[1]
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source/figures


On Fri, May 15, 2015 at 8:33 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Fri, May 15, 2015 at 2:27 PM, Joe Gordon joe.gord...@gmail.com wrote:



 On Thu, May 14, 2015 at 3:52 AM, John Garbutt j...@johngarbutt.com
 wrote:

 On 12 May 2015 at 20:33, Sean Dague s...@dague.net wrote:
  On 05/12/2015 01:12 PM, Jeremy Stanley wrote:
  On 2015-05-12 10:04:11 -0700 (-0700), Clint Byrum wrote:
  It's a nice up side. However, as others have pointed out, it's only
  capable of displaying the most basic pieces of the architecture.
 
  For higher level views with more components, I don't think ASCII art
  can provide enough bandwidth to help as much as a vector diagram.
 
  Of course, simply a reminder that just because you have one or two
  complex diagram callouts in a document doesn't mean it's necessary
  to also go back and replace your simpler ASCII art diagrams with
  unintelligible (without rendering) SVG or Postscript or whatever.
  Doing so pointlessly alienates at least some fraction of readers.
 
  Sure, it's all about trade offs.
 
  But I believe that statement implicitly assumes that ascii art diagrams
  do not alienate some fraction of readers. And I think that's a bad
  assumption.
 
  If we all feel alienated every time anyone does anything that's not
  exactly the way we would have done it, it's time to give up and pack it
  in. :) This thread specifically mentioned source based image formats
  that were internationally adopted open standards (w3c SVG, ISO ODG)
 that
  have free software editors that exist in Windows, Mac, and Linux
  (Inkscape and Open/LibreOffice).

 Some great points make here.

 Lets try decide something, and move forward here.

 Key requirements seem to be:
 * we need something that gives us readable diagrams
 * if its not easy to edit, it will go stale
 * ideally needs to be source based, so it lives happily inside git
 * needs to integrate into our sphinx pipeline
 * ideally have an opensource editor for that format (import and
 export), for most platforms

 ascii art fails on many of these, but its always a trade off.

 Possible way forward:
 * lets avoid merging large hard to edit bitmap style images
 * nova-core reviewers can apply their judgement on merging source based
 formats
 * however it *must* render correctly in the generated html (see result
 of docs CI job)

 Trying out SVG, and possibly blockdiag, seem like the front runners.
 I don't think we will get consensus without trying them, so lets do that.

 Will that approach work?


 Sounds like a great plan.




 After further investigation in blockdiag, is useless for moderately
 complex diagrams.

 Here is my attempt at graphing nova [0], but due to a blockdiag bug from
 2013, [1] it is impossible to clearly read. For example, in the diagram
 there is not supposed to be any arrow between the conductor and
 cinder/glance/neutron. I looked into dia, and while it has plenty of
 diagram shapes it doesn't have a good template for software architecture,
 but maybe there is a way to make dia work. And that just  leaves SVG
 graphics,  after spending an hour or two  playing around with Inkscape and
 it looks promising (although the learning curve is pretty steep). Here is
 my first attempt in Inkscape [2].


 [0]
 

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

[Matt Kassawara]

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].

https://review.openstack.org/#/c/67281/33/etc/neutron/plugins/ml2/ml2_conf.ini

The most recent gate from the milestone-proposed branch also has this key
under [security_group].

http://logs.openstack.org/76/85676/1/gate/gate-tempest-dsvm-neutron/80af0f6/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz

However, the code has this key under [securitygroup] with the
'firewall_driver' key.

https://github.com/openstack/neutron/blob/master/neutron/agent/securitygroups_rpc.py

What's the proper location for the 'enable_security_group' key?

Thanks,
Matt
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Kassawara]

Thiago,

My current ml2_conf.ini looks like your example. My environment also
continues to work if I omit the entire [security_group] section. However,
it stops working if I omit the [securitygroup] section.

Matt


On Mon, Apr 7, 2014 at 5:36 PM, Martinx - ジェームズ
thiagocmarti...@gmail.comwrote:

 Hi!

 I faced this problem this weekend, look:
 https://bugs.launchpad.net/bugs/1303517

 Currently, my ml2_conf.ini contains:

 ---
 [security_group]
 enable_security_group = True

 [securitygroup]
 firewall_driver =
 neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
 ---

 Best!
 Thiago


 On 7 April 2014 19:50, Akihiro Motoki amot...@gmail.com wrote:

 Hi Matt,

 Thanks for raising this. Both should be the same section.
 [securitygroup] section exists in Havana and previous releases and
 it is the right section name.

 When we introduced enable_security_group option, we 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 Kassawara mkassaw...@gmail.com
 wrote:
  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].
 
 
 https://review.openstack.org/#/c/67281/33/etc/neutron/plugins/ml2/ml2_conf.ini
 
  The most recent gate from the milestone-proposed branch also has this
 key
  under [security_group].
 
 
 http://logs.openstack.org/76/85676/1/gate/gate-tempest-dsvm-neutron/80af0f6/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
 
  However, the code has this key under [securitygroup] with the
  'firewall_driver' key.
 
 
 https://github.com/openstack/neutron/blob/master/neutron/agent/securitygroups_rpc.py
 
  What's the proper location for the 'enable_security_group' key?
 
  Thanks,
  Matt
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Kassawara]

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 instance, the Nova network service
fails to retrieve network information from the controller. Adding the the
database keys resolves the problem. I'm using the 2014.1~b3-0ubuntu1~cloud0
packages on Ubuntu 12.04.

Matt
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Kassawara]

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 the problem. I'm using
  the 2014.1~b3-0ubuntu1~cloud0 packages on Ubuntu 12.04.

 Can you file a bug with details from the logs?

 --Dan

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matt Kassawara]

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 service
 doesn't hit the database. In fact, nova-compute stopped hitting the
 database before we started on the objects work.

 Anyway, looks like there are still some direct-to-database things
 lingering in the linux_net module. I'm not sure those will get resolved
 before icehouse at this point...

 --Dan

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev