Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

I would personally like to see Keystone get transitioned first, but it really doesn't matter where we start if we reach the right goal in the end. Since Emelien's work on refactoring all the providers for puppet-keystone, it has become a test bed for project-wide features. I'm really excited to

Re: [openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

Just FYI. Docker support multi log driver now[0]. Version New Logging Drivers 1.6.0 json-file, syslog, none 1.7.0 journald 1.8.0 fluentd, gelf 1.9.0 awslogs For the stdout from container, we can use gelf/syslog driver to forward. [0] https://docs.docker.com/engine/reference/logging/overview/

[openstack-dev] [Neutron][Networking-ovn] Instances on the compute node can not get IP address from DHCP

hello, I have build a 2 node devstack environment with ovn enabled by following http://docs.openstack.org/developer/networking-ovn/testing.html with 2 physical machine on one blade server. Then I created 3 instances, one in the controller node and other two in the compute node, same as :

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

On 23 January 2016 at 11:27, Adam Lawson wrote: > 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 >

[openstack-dev] [oslo] Sachi King for oslo core

Hey, so I'd like to propose Sachi - one of my HPE colleages who has been helping out with pbr for a while now, for oslo core. pbr is pretty quiet as you know, so its a bit hard to assess her work based on reviews done - but I think her error rate will be approximately the same as mine - pbr is

Re: [openstack-dev] [oslo] Sachi King for oslo core

+1 Robert. Here's hoping Sachi can expand her horizon to all of Oslo. Thanks, Dims On Sun, Jan 24, 2016 at 9:51 PM, Robert Collins wrote: > Hey, so I'd like to propose Sachi - one of my HPE colleages who has > been helping out with pbr for a while now, for oslo core.

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

I believe the issue is that the default is unspecified, which leads to nothing being advertised to VMs via dhcp/ra. So VMs end up using 1500, which leads to a catastrophe when running on an overlay on a 1500 underlay. On Jan 24, 2016 20:48, "Ian Wells" wrote: > On 23

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

I wrote the spec for the MTU work that's in the Neutron API today. It haunts my nightmares. I learned so many nasty corner cases for MTU, and you're treading that same dark path. I'd first like to point out a few things that change the implications of what you're reporting in strange ways. [1]

Re: [openstack-dev] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

One thing that might be tough for operators is dealing with different versions of openstack projects which require different versions of oslo. Right now we have some stuff on Liberty, some stuff not. As we containerize more services that's going to get even more true. Right now we can solve this

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (25/1) - 0900 UTC

Hello All, We will have an IRC meeting tomorrow (Monday, 25/4) at 0900 UTC in #openstack-meeting-4 Please review the expected meeting agenda here: https://wiki.openstack.org/wiki/Meetings/Dragonflow You can view last meeting action items and logs here:

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

On 22 January 2016 at 10:35, Neil Jerram wrote: > * Why change from ML2 to core plugin? > > - It could be seen as resolving a conceptual mismatch. > networking-calico uses > IP routing to provide L3 connectivity between VMs, whereas ML2 is > ostensibly > all about

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

At a minimum I think we should pick a default in devstack and dump a warning in neutron if operators don't specify it. I would still be preferable to changing the default even though it's a behavior change considering the current behavior is annoying. :) On Jan 24, 2016 23:31, "Ian Wells"

[openstack-dev] --allowed-address-pairs fails...

*Hi every one, * *When trying to execute this command:* * neutron --debug port-update 51ae49c8-d360-488e-badb-7bee31585471 --allowed-address-pairs action=clear* *I am getting the following error:* Traceback (most recent call last): File

Re: [openstack-dev] [murano] Nominate Rong Zhu to Murano Core

+1, no objections from my side. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2016-01-22 18:48 GMT+03:00 Serg Melikyan : > I would like to nominate Rong Zhu (zhurong on IRC) join to the Murano > core-reviewers team. He has been an

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

On 24 January 2016 at 20:18, Kevin Benton wrote: > I believe the issue is that the default is unspecified, which leads to > nothing being advertised to VMs via dhcp/ra. So VMs end up using 1500, > which leads to a catastrophe when running on an overlay on a 1500 underlay. >

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

>The reason for that was in the other half of the thread - it's not possible to magically discover these things from within Openstack's own code because the relevant settings span more than just one server IMO it's better to have a default of 1500 rather than let VMs automatically default to 1500

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

I like both of those ideas. On 24 January 2016 at 22:37, 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. > > I would still be preferable to changing the default even though it's a >

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

On 24 January 2016 at 22:12, Kevin Benton wrote: > >The reason for that was in the other half of the thread - it's not > possible to magically discover these things from within Openstack's own > code because the relevant settings span more than just one server > > IMO it's

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

Actually, I note that that document is Juno and there doesn't seem to be anything at all in the Liberty guide now, so the answer is probably to add settings for path_mtu and segment_mtu in the recommended Neutron configuration. On 24 January 2016 at 22:26, Ian Wells

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

On 22 January 2016 at 10:35, Neil Jerram wrote: > networking-calico [1] is currently implemented as an ML2 mechanism > driver, but > I'm wondering if it might be better as its own core plugin, and I'm > looking for > input about the implications of that, or for

Re: [openstack-dev] [oslo] Sachi King for oslo core

+1 from me, Go Sachi! Have no fear (paranoia) oslo is here! -Josh On 01/24/2016 06:51 PM, Robert Collins wrote: Hey, so I'd like to propose Sachi - one of my HPE colleages who has been helping out with pbr for a while now, for oslo core. pbr is pretty quiet as you know, so its a bit hard to

Re: [openstack-dev] [mistral] [murano] [yaql] An online YAQL evaluator [was RE: [mistral] [murano] An online YAQL evaluator]

Moshe, awesome and handy tool!!! Especially hear about completed this in 24 hours Hackathon session. :) Lin Yang @Intel > On Jan 17, 2016, at 08:25, Stan Lagun wrote: > > Very cool, indeed! Even myself (developer of yaql) often use yaqluator > instead of yaql CLI :) > >

Re: [openstack-dev] [nova] gate blockage due to eventlet 0.18

On 2016-01-24 22:35, Diana Clarke wrote: > And here's the upstream bug for the functional test failures: > > https://github.com/eventlet/eventlet/issues/291 > https://bugs.launchpad.net/nova/+bug/1537450 > > It was also fixed in eventlet 0.18.1. Diana, Thanks for investigating and

[openstack-dev] [keystone] keystone-meeting on jan 26, 2016 cancelled

Cancelling the upcoming keystone since most of the regular attendees will be flying out that day to attend the keystone midcycle that starts on on the 27th. Thanks, Steve Martinelli Keystone PTL __ OpenStack Development

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

+1, no objections. Well deserved, Victor. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2016-01-22 20:33 GMT+03:00 Serg Melikyan : > I would like to nominate Victor Ryzhenkin (freerunner on IRC) join to the > Murano > core-reviewers

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On 01/22/2016 09:01 AM, Dan Prince wrote: I gave a couple of ad-hoc demo's of my Mistral dev environment this week. For those interested in tinkering with TripleO Mistral actions in tripleo-common here are links to the code I used for those. Still a rough prototype but hopefully demonstrates how

[openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC

Hi neutrinos, A kind reminder for next week's meeting. Being the meeting right after the milestone was cut, I'd like to take most of the hour to talk about blueprints/specs, i.e. the beefy workload that has merged, and has yet to merge. We'll be brief on announcements and bugs, and skip the

[openstack-dev] [nova] gate blockage due to eventlet 0.18

Something about the eventlet 0.18 release is failing the cloudpipe functional tests, as well as our docs job (which is really really odd). An eventlet pin has been posted - https://review.openstack.org/271809 - once landed it should let the spice flow again. If someone could look into it deeper

Re: [openstack-dev] [nova] gate blockage due to eventlet 0.18

On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote: > Something about the eventlet 0.18 release is failing the cloudpipe > functional tests, as well as our docs job (which is really really odd). > > An eventlet pin has been posted - https://review.openstack.org/271809 - > once landed it

Re: [openstack-dev] [nova] gate blockage due to eventlet 0.18

yep. we should be all better now :) -- dims On Sun, Jan 24, 2016 at 2:48 PM, Andreas Jaeger wrote: > On 01/24/2016 08:01 PM, Jeremy Stanley wrote: >> >> On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote: >>> >>> Something about the eventlet 0.18 release is failing the

Re: [openstack-dev] [nova] gate blockage due to eventlet 0.18

On 01/24/2016 08:01 PM, Jeremy Stanley wrote: On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote: Something about the eventlet 0.18 release is failing the cloudpipe functional tests, as well as our docs job (which is really really odd). An eventlet pin has been posted -

[openstack-dev] [Cinder] No weekly meeting Jan 27

Just an official notice - there will be no weekly meeting January 27th due to the Mitaka Midcycle. Regular weekly meetings will continue the first week of February. Thanks! Sean McGinnis (smcginnis) __ OpenStack Development

Re: [openstack-dev] [nova] gate blockage due to eventlet 0.18

And here's the upstream bug for the functional test failures: https://github.com/eventlet/eventlet/issues/291 https://bugs.launchpad.net/nova/+bug/1537450 It was also fixed in eventlet 0.18.1. --diana >> Dims reported a related bug upstream: >> >>

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

Excerpts from Dan Prince's message of 2016-01-22 16:19:07 -0800: > On Fri, 2016-01-22 at 11:24 -0600, Ben Nemec wrote: > > So I haven't weighed in on this yet, in part because I was on > > vacation > > when it was first proposed and missed a lot of the initial > > discussion, > > and also because