Re: [Openstack-operators] [neutron] ML2/OVS dropping packets?

Can you do a tcpdump to see if the VM is sending any packets out that other interface with the source mac of the primary interface? We make use of the NORMAL action which does mac learning so it's possible something is slipping through that is causing OVS to get the wrong port association. The

[Openstack-operators] Sydney Summit Call for Presentations Open Until July 14th

Hi everyone, You have less than a month to submit your speaking proposals for the OpenStack Summit Sydney , November 6-8, 2017. Submit your proposals here

Re: [Openstack-operators] [neutron] ML2/OVS dropping packets?

So this all gets more interesting the packets aren't lost they get routed (switched?) to the wrong interface... The VM has two interfaces on the same network. Not sure this makes sense and wes done because this was a straight physical to virtual migration. But seems like it should work so VM

Re: [Openstack-operators] Turning TC/UC workgroups into OpenStack SIGs [all][uc]

On Wed, Jun 21, 2017 at 10:44 AM, Shamail Tahir wrote: > Hi, > > In the past, governance has helped (on the UC WG side) to reduce > overlaps/duplication in WGs chartered for similar objectives. I would like > to understand how we will handle this (if at all) with the new

Re: [Openstack-operators] [neutron] ML2/OVS dropping packets?

Hi Jon - From what I understand, while you might have gone to the trouble of configuring a lossless data centre ethernet, that guarantee of packet loss ends at the hypervisor. OVS (and other virtual switches) will drop packets rather than exert back pressure. I saw a useful paper from IBM

Re: [Openstack-operators] Panko and event system

I think that I'm getting more clear picture. If understand it right, there two main possibilities. 1) Panko can be installed to store events and if I want to find some events I need to use panko's API. 2) Directly subscript to events via RabbitMQ. As far I understand all events generated by

Re: [Openstack-operators] Turning TC/UC workgroups into OpenStack SIGs

Matt Riedemann wrote: > How does the re-branding or re-categorization of these groups solve the > actual feedback problem? If the problem is getting different people from > different groups together, how does this solve that? For example, how do > we get upstream developers aware of operator

Re: [Openstack-operators] [neutron] ML2/OVS dropping packets?

On Wed, Jun 21, 2017 at 02:39:23AM -0700, Kevin Benton wrote: :Are there any events going on during these outages that would cause :reprogramming by the Neutron agent? (e.g. port updates) If not, it's likely :an OVS issue and you might want to cross-post to the ovs-discuss mailing :list. Guess

Re: [Openstack-operators] [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

On 6/21/2017 9:59 AM, Thierry Carrez wrote: Hi everyone, One of the areas identified as a priority by the Board + TC + UC workshop in March was the need to better close the feedback loop and make unanswered requirements emerge. Part of the solution is to ensure that groups that look at specific

[Openstack-operators] Turning TC/UC workgroups into OpenStack SIGs [all][uc]

Hi everyone, One of the areas identified as a priority by the Board + TC + UC workshop in March was the need to better close the feedback loop and make unanswered requirements emerge. Part of the solution is to ensure that groups that look at specific use cases, or specific problem spaces within

Re: [Openstack-operators] [openstack-dev] [all][Ironic][Nova] The /service API endpoint

On 6/20/2017 1:37 AM, Kumari, Madhuri wrote: 2. Also why this API only expose the state of RPC servers and not the API server in the environment? I've wondered the same. It looks like that filtering happened in Mitaka: https://review.openstack.org/#/c/277881/ I'm surprised that didn't happen

Re: [Openstack-operators] [neutron] ML2/OVS dropping packets?

Are there any events going on during these outages that would cause reprogramming by the Neutron agent? (e.g. port updates) If not, it's likely an OVS issue and you might want to cross-post to the ovs-discuss mailing list. Can you check the vswitch logs during the packet loss to see if there are

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

Doing future meetings at 1100UTC would also be fine by me. I’ll put it on the agenda for today’s meeting (in ~10 minutes) Stig > On 21 Jun 2017, at 09:13, Blair Bethwaite wrote: > > Thanks Pierre. That's also my preference. > > Just to be clear, today's 0900 UTC

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

Thanks Pierre. That's also my preference. Just to be clear, today's 0900 UTC meeting (45 mins from now) is going ahead at the usual time. On 21 Jun. 2017 5:21 pm, "Pierre Riteau" wrote: Hi Blair, I strongly prefer 1100 UTC. Pierre > On 21 Jun 2017, at 06:54, Blair

[Openstack-operators] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

Hi everyone, Don't forget todays meeting for the PublicCloudWorkingGroup. 1400 UTC in IRC channel #openstack-meeting-3 Etherpad: https://etherpad.openstack.org/p/publiccloud-wg Goals: https://etherpad.openstack.org/p/SYDNEY_GOALS_publiccloud-wg Talk to you this afternoon! Tobias

Re: [Openstack-operators] [User-committee] [scientific] 0900 UTC meeting time change?

Hi Blair, I strongly prefer 1100 UTC. Pierre > On 21 Jun 2017, at 06:54, Blair Bethwaite wrote: > > Hi all, > > The Scientific-WG's 0900 UTC meeting time (it's the non-US friendly time) is > increasingly difficult for me to make. A couple of meetings back we