[openstack-dev] [neutron][stable] Stepping down from core

[Ihar Hrachyshka]

Hi neutrinos and all,

As some of you've already noticed, the last several months I was
scaling down my involvement in Neutron and, more generally, OpenStack.
I am at a point where I feel confident my disappearance won't disturb
the project, and so I am ready to make it official.

I am stepping down from all administrative roles I so far accumulated
in Neutron and Stable teams. I shifted my focus to another project,
and so I just removed myself from all relevant admin groups to reflect
the change.

It was a nice 4.5 year ride for me. I am very happy with what we
achieved in all these years and a bit sad to leave. The community is
the most brilliant and compassionate and dedicated to openness group
of people I was lucky to work with, and I am reminded daily how
awesome it is.

I am far from leaving the industry, or networking, or the promise of
open source infrastructure, so I am sure we will cross our paths once
in a while with most of you. :) I also plan to hang out in our IRC
channels and make snarky comments, be aware!

Thanks for the fish,
Ihar

__
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-infra] How to take over a project?

[Ihar Hrachyshka]

ONOS is not part of Neutron and hence Neutron Release team should not
be involved in its matters. If gerrit ACLs say otherwise, you should
fix the ACLs.

Ihar

On Tue, Apr 24, 2018 at 1:22 AM, Sangho Shin  wrote:
> Dear Neutron-Release team members,
>
> Can any of you handle the issue below?
>
> Thank you so much for your help in advance.
>
> Sangho
>
>
>> On 20 Apr 2018, at 10:01 AM, Sangho Shin  wrote:
>>
>> Dear Neutron-Release team,
>>
>> I wonder if any of you can add me to the network-onos-release member.
>> It seems that Vikram is busy. :-)
>>
>> Thank you,
>>
>> Sangho
>>
>>
>>
>>> On 19 Apr 2018, at 9:18 AM, Sangho Shin  wrote:
>>>
>>> Ian,
>>>
>>> Thank you so much for your help.
>>> I have requested Vikram to add me to the release team.
>>> He should be able to help me. :-)
>>>
>>> Sangho
>>>
>>>
 On 19 Apr 2018, at 8:36 AM, Ian Wienand  wrote:

 On 04/19/2018 01:19 AM, Ian Y. Choi wrote:
> By the way, since the networking-onos-release group has no neutron
> release team group, I think infra team can help to include neutron
> release team and neutron release team can help to create branches
> for the repo if there is no reponse from current
> networking-onos-release group member.

 This seems sane and I've added neutron-release to
 networking-onos-release.

 I'm hesitant to give advice on branching within a project like neutron
 as I'm sure there's stuff I'm not aware of; but members of the
 neutron-release team should be able to get you going.

 Thanks,

 -i
>>>
>>
>

__
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] [networking-ovn] Non voting jobs for networking-ovn on neutron.

[Ihar Hrachyshka]

On Mon, Dec 4, 2017 at 5:20 AM, Miguel Angel Ajo Pelayo
 wrote:
> We were thinking about the option of having a couple of non-voting jobs
> on
> the neutron check for networking-ovn. It'd be great for us, in terms of
> traceability,
> we re-use a lot of the neutron unit test base clases/etc, and sometimes
> we get hit by surprises.

I don't think unit test base classes are meant to break, and
regardless, a better path would be to move those pieces that you reuse
into neutron-lib and consume from there. I know some drivers reuse a
lot more than just the base test class, f.e. taking ml2 unit test
classes verbatim; I don't think this is the use case that we should
ultimately support.

>
> Sometimes some other changes hit us on the neutron scenario tests.
>
> So it'd be great to have them if you believe it's a reasonable thing.

Yamamoto's concern is valid in that if we don't set clear standards of
what could be included, we would open a can of worms with every
stadium driver asking for a slot in check queue. That being said, I
don't necessarily agree it's unacceptable; what I am saying is that
drivers would need to fulfill specific requirements (for example, all
tempest tests for major api extensions executed for reference
implementation would need to pass; there may be more requirements than
just that). I think having some non-voting *tempest* jobs for each
major driver (ovn, odl, midonet?) could be useful. We have a job
specific to ironic in our check queue. I would say accommodating for
better integration with our own stadium participants can be even more
helpful.

Ihar

__
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] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Ihar Hrachyshka]

Hi Andrea,

thanks for taking time to reply. I left some answers inline.

On Fri, Jan 19, 2018 at 9:08 AM, Andrea Frittoli
<andrea.fritt...@gmail.com> wrote:
>
>
> On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>> Hi all,
>
>
> Hi!
>>
>>
>> tl;dr I propose to switch to lib/neutron devstack library in Queens. I
>> ask for buy-in to the plan from release and QA teams, something that
>> infra asked me to do.
>>
>> ===
>>
>> Last several cycles we were working on getting lib/neutron - the new
>> in-tree devstack library to deploy neutron services - ready to deploy
>> configurations we may need in our gates.
>
>
> May I ask the reason for hosting this in the neutron tree?

Sorry for wording it in a misleading way. The lib/neutron library is
in *devstack* tree:
https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron
So in terms of deployment dependencies, there are no new repositories
to fetch from or gate against.

>
>>
>> Some pieces of the work
>> involved can be found in:
>>
>> https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate
>>
>> I am happy to announce that the work finally got to the point where we
>> can consistently pass both devstack-gate and neutron gates:
>>
>> (devstack-gate) https://review.openstack.org/436798
>
>
> Both legacy and new style (zuulv3) jobs rely on the same test matrix code,
> so your change would impact both worlds consistently, which is good.
>
>>
>>
>> (neutron) https://review.openstack.org/441579
>>
>> One major difference between the old lib/neutron-legacy library and
>> the new lib/neutron one is that service names for neutron are
>> different. For example, q-svc is now neutron-api, q-dhcp is now
>> neutron-dhcp, etc. (In case you wonder, this q- prefix links us back
>> to times when Neutron was called Quantum.) The way lib/neutron is
>> designed is that whenever a single q-* service name is present in
>> ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to
>> deploy services.
>>
>> Service name changes are a large part of the work. The way the
>> devstack-gate change linked above is designed is that it changes names
>> for deployed neutron services starting from Queens (current master),
>> so old branches and grenade jobs are not affected by the change.
>
>
> Any other change worth mentioning?
>

The new library is a lot more simplified and opinionated and has fewer
knobs and branching that is not very useful for majority of users.
lib/neutron-legacy was always known for its complicated configuration.
We hope that adopting the new library will unify and simplify neutron
configuration across different jobs and setups.

From consumer perspective, nothing should change expect service names.
Some localrc files may need adoption if they rely on old arcane knobs.
It can be done during transition phase since old service names are
expected to work.

>>
>>
>> While we validated the change switching to new names against both
>> devstack-gate and neutron gates that should cover 90% of our neutron
>> configurations, and followed up with several projects that - we
>> induced - may be affected by the change - there is always a chance
>> that some job in some project gate would fail because of it, and we
>> would need to push a (probably rather simple) follow-up to unbreak the
>> affected job. Due to the nature of the work, the span of impact, and
>> the fact that infra repos are not easily gated against with Depends-On
>> links, we may need to live with the risk.
>>
>> Of course, there are several aspects of the project life involved,
>> including QA and release delivery efforts. I was advised to reach out
>> to both of those teams to get a buy-in to proceed with the move. If we
>> have support for the switch now, as per Clark, infra is ready to
>> support the switch.
>>
>> Note that the effort span several cycles, partially due to low review
>> velocity in several affected repos (devstack, devstack-gate),
>> partially because new changes in all affected repos were pulling us
>> back from the end goal. This is one of the reasons why I would like us
>> to do the switch sooner rather than later, since chasing this moving
>> goalpost became rather burdensome.
>>
>> What are QA and release team thoughts on the switch? Are we ready to
>> do it in next weeks?
>
>
> If understood properly it would still be possible to use the old names
> right?
> Some jobs may not rely on test matrix and just hard code the list of
> services.
> Such jo

Re: [openstack-dev] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Ihar Hrachyshka]

On Thu, Jan 18, 2018 at 8:33 AM, Michael Johnson  wrote:
> This sounds great Ihar!
>
> Let us know when we should make the changes to the neutron-lbaas projects.
>
> Michael

Hi Michael!

You can already start, by introducing new service names without q-*
for your services. For example, neutron-lbaasv2 instead of q-lbaasv2.
You can have both in parallel, behaving the same way, like we do in
neutron devstack plugin:
https://github.com/openstack/neutron/blob/master/devstack/plugin.sh#L34
Once you have it in your devstack plugin, you should be able to safely
replace all occurrences of q-lbaasv2 in infra projects with the new
name. Handly link to detect them:

http://codesearch.openstack.org/?q=q-lbaas=nope==

Thanks!
Ihar

__
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] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Ihar Hrachyshka]

Hi all,

tl;dr I propose to switch to lib/neutron devstack library in Queens. I
ask for buy-in to the plan from release and QA teams, something that
infra asked me to do.

===

Last several cycles we were working on getting lib/neutron - the new
in-tree devstack library to deploy neutron services - ready to deploy
configurations we may need in our gates. Some pieces of the work
involved can be found in:

https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate

I am happy to announce that the work finally got to the point where we
can consistently pass both devstack-gate and neutron gates:

(devstack-gate) https://review.openstack.org/436798
(neutron) https://review.openstack.org/441579

One major difference between the old lib/neutron-legacy library and
the new lib/neutron one is that service names for neutron are
different. For example, q-svc is now neutron-api, q-dhcp is now
neutron-dhcp, etc. (In case you wonder, this q- prefix links us back
to times when Neutron was called Quantum.) The way lib/neutron is
designed is that whenever a single q-* service name is present in
ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to
deploy services.

Service name changes are a large part of the work. The way the
devstack-gate change linked above is designed is that it changes names
for deployed neutron services starting from Queens (current master),
so old branches and grenade jobs are not affected by the change.

While we validated the change switching to new names against both
devstack-gate and neutron gates that should cover 90% of our neutron
configurations, and followed up with several projects that - we
induced - may be affected by the change - there is always a chance
that some job in some project gate would fail because of it, and we
would need to push a (probably rather simple) follow-up to unbreak the
affected job. Due to the nature of the work, the span of impact, and
the fact that infra repos are not easily gated against with Depends-On
links, we may need to live with the risk.

Of course, there are several aspects of the project life involved,
including QA and release delivery efforts. I was advised to reach out
to both of those teams to get a buy-in to proceed with the move. If we
have support for the switch now, as per Clark, infra is ready to
support the switch.

Note that the effort span several cycles, partially due to low review
velocity in several affected repos (devstack, devstack-gate),
partially because new changes in all affected repos were pulling us
back from the end goal. This is one of the reasons why I would like us
to do the switch sooner rather than later, since chasing this moving
goalpost became rather burdensome.

What are QA and release team thoughts on the switch? Are we ready to
do it in next weeks?

Thanks for attention,
Ihar

__
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][networking-ovn] Stable branch maintainers for networking-ovn

[Ihar Hrachyshka]

For the record, I added Lucas to the gerrit group. I assume he will
mostly focus on OVN patches. You are still welcome to review other
repo patches, and if you stick to it, I am happy to expand your role
to cover all of them.

As for OVN, you only have one +2, and existing stable reviewers may
not be responsive. Don't hesitate to poke us about patches that block
your progress or don't attract enough attention in let's say a week.

Welcome to the game and enjoy!
Ihar

On Thu, Dec 21, 2017 at 1:55 AM, Lucas Alvares Gomes
 wrote:
> Hi,
>
>> Please tell me who from the OVN group is ready to take the burden, and
>> I will make you part of neutron-stable-maint. I think it's ok to be
>> more laissez faire with backports for subprojects than we were used
>> to, with the recent drop in core team membership and reduced capacity.
>
> Great! I will reach out the OVN core team so we make a decision about
> who should do it.
>
> Cheers,
> Lucas
>
> __
> 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][networking-ovn] Stable branch maintainers for networking-ovn

[Ihar Hrachyshka]

Please tell me who from the OVN group is ready to take the burden, and
I will make you part of neutron-stable-maint. I think it's ok to be
more laissez faire with backports for subprojects than we were used
to, with the recent drop in core team membership and reduced capacity.

Ihar

On Wed, Dec 20, 2017 at 10:58 AM, Armando M.  wrote:
>
>
> On 20 December 2017 at 00:27, Miguel Angel Ajo Pelayo 
> wrote:
>>
>> If we could have one member from networking-ovn on the
>> neutron-stable-maint team that would be great. That means the member would
>> have to be trusted not to handle neutron-patches when not knowing what he's
>> doing, and of course, follow the stable guidelines, which are absolutely
>> important. But I believe everybody takes the role seriously.
>
>
> It'll still take two +2 to push a patch in, and the oversight from more
> seasoned stable reviewers is still there to assist more inexperienced ones.
> Aside from the occasional lag, I don't believe that backports linger as much
> as they used to, but with the help of the dashboard and the initiative of
> the individual project maintainers velocity should increase. To be honest, I
> am not sure why we didn't do that before, similar review rights apply to
> things like specs reviews and neutron-lib changes. As for your concern about
> people stepping out of their own turf, I honestly don't believe that's a
> problem in reality, and even if it was, I always encourage people to reach
> out on IRC or other means.
>
> I don't have admin rights to the neutron-stable-maint team, fo that someone
> has to nudge Ihar :)
>
> HTH
> Armando
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>
>>
>>
>> If that's not a reasonable solution, then I'd vote for the specific stable
>> maintainers instead. But we need something to help us handle issues quicker
>> and at
>> the same time, in a controlled manner.
>>
>> Best,
>> Miguel Ángel.
>>
>> On Tue, Dec 19, 2017 at 5:48 PM Armando M.  wrote:
>>>
>>> On 19 December 2017 at 08:21, Lucas Alvares Gomes 
>>> wrote:

 Hi all,

 Just sending this email to try to understand the model for stable branch
 maintenance in networking-ovn (potentially other neutron drivers too).

 Right now, only members of the ``neutron-stable-maint`` gerrit group are
 able to approve patches for the stable branches; this can cause some delays
 when fixing things (e.g [0]) because we don't have any member in that group
 that is also a ``networking-ovn-core`` member. So, sometimes we have to go
 around and ping people to take a look at the patches and it kinda sucks.
>>>
>>>
>>> We had a Gerrit dashboard that helped stable reviewers stay on top of
>>> things [1], but it looks like it doesn't seem to work anymore. My suggestion
>>> would be to look into that as the lack of visibility might be the source of
>>> the recent delay.
>>>
>>> [1]
>>> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
>>>

 Is there any reason why things are set up in that way ?

 I was wondering if it would make sense to create a new group to help
 maintaining the stable branches in networking-ovn. The new group could
 include some of the core members willing to do the work +
 ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
 about it?
>>>
>>>
>>> Rather than create yet another group(s), it makes sense to have an
>>> individual from each neutron project participate in the neutron-stable-maint
>>> team (whose admin rights I think are held by Ihar as neutron member), for
>>> those of whom have actually an interest in reviewing stable patches :)
>>>
>>> HTH
>>> Armando
>>>

 [0] https://review.openstack.org/#/c/523623/

 Cheers,
 Lucas


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

Re: [openstack-dev] [neutron] Stepping down from core

[Ihar Hrachyshka]

It's a sad day. But I am happy we had you in leadership for so many
productive years. I also hope the community is anti-fragile and adopts
to changes.

I wish you all the best.
Ihar

On Fri, Dec 15, 2017 at 11:01 AM, Armando M.  wrote:
> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being the
> Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core is
> a duty rather than a privilege, and I personally feel like it's way overdue
> for me to recognize on the mailing list that it's the time that I state
> officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing with
> the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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] Propose Slawek Kaplonski for Neutron core

[Ihar Hrachyshka]

YES, FINALLY.

On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
> +1! ... even though I haven't been around. :)
>
> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle  wrote:
>>
>> Hi Neutron Team,
>>
>> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
>> has been an active contributor to the project since the Mitaka cycle. He has
>> been instrumental in the development of the QoS capabilities in Neutron,
>> becoming the lead of the sub-team focused on that set of features. More
>> recently, he has collaborated in the implementation of OVO and is an active
>> participant in the CI sub-team. His number of code reviews during the Queens
>> cycle is on par with the leading core members of the team:
>> http://stackalytics.com/?module=neutron
>>
>> In my opinion, his efforts are highly valuable to the team and we will be
>> very lucky to have him as a fully voting core.
>>
>> I will keep this nomination open for a week as customary,
>>
>> Thank you,
>>
>> Miguel
>>
>> __
>> 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] multiple agents with segment access

[Ihar Hrachyshka]

In general, you should be able to run both regular l2 agent (ovs) and
sriov agent. If you have problems with it, we should probably assume
it's a bug. Please report.

On Tue, Nov 14, 2017 at 8:02 AM, Legacy, Allain
 wrote:
> Is it a known limitation that the ML2 plugin and associated drivers do not 
> properly handle cases where there are multiple agents running on the same 
> host?   That is, two or more agents that reside on the same host and both 
> report device/interface mappings  for physical networks?One such setup is 
> a set of nodes that are both running an L2 agent and a NIC SRIOV agent.
>
> We have found two problems specific to this configuration and are wondering 
> if these are known limitations, or simply not supported.
>
> For example, in a configuration where a host has L2, DHCP, and SRIOV agents 
> running on it, then:
>
> 1)   The DHCP scheduler can schedule a network to be hosted by that DHCP 
> agent even if the physical network is only supported by the SRIOV agent and 
> not by the L2 agent.  This can end up isolating the DHCP server as it will 
> not have access to the underlying physical segment.   This is happening 
> because "filter_hosts_with_network_access" in the Ml2Plugin will include the 
> host because the SRIOV mech driver reports that it has access to that segment.
>
> 2)   The Segment Plugin "segmenthostmappings" table gets overwritten with 
> tuples for whichever agent reports in last.  For example, if the L2 agent has 
> physical network mappings for 2 different physical networks (physnet0, 
> physnet1), but the SRIOV NIC agent only has 1 physical network reported 
> (physnet2), the segmenthostmappings table will have data for only physnet2 if 
> the SRIOV NIC agent reported last, or data for only both physnet0 and 
> physnet1 if the L2 agent reported last.  Data for physical networks belonging 
> to the other agent will be erroneously removed as stale entries.
>
> If it has been discussed before is there a plan to address this type of 
> configuration?
>
> Regards.
> Allain
>
>
>
> Allain Legacy, Software Developer, Wind River
> direct 613.270.2279  fax 613.492.7870 skype allain.legacy
> 350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5
>
>
>
>
>
> __
> 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] [zun][neutron] About Notifier

[Ihar Hrachyshka]

I don't think it is supposed to be pluggable, so no guarantees it
won't break for you if you decide to implement an out-of-tree
notifier. But I think Zun could instead listen for notifications that
are fed into ceilometer. We already issue those notifications, so it
would make sense to retrieve them from there instead of via a custom
interface.

Ihar

On Sun, Oct 1, 2017 at 7:15 PM, Hongbin Lu  wrote:
> Hi Neutron team,
>
>
>
> I saw neutron has a Nova notifier [1] that is able to notify Nova via REST
> API when a certain set of events happen. I think Zun would like to be
> notified as how Nova is. For example, we would like to receive notification
> whenever a port assigned to a container has been associated with a floating
> IP. If I propose a Zun notifier (preferably out-of-tree) for that, will you
> accept the patch? Or anyone has an alternative suggestion to stratify our
> use case.
>
>
>
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py
>
>
>
> Best regards,
>
> Hongbin
>
>
>
>
> __
> 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] Supporting SSH host certificates

[Ihar Hrachyshka]

What you describe (at least the use case) seems to resemble
https://review.openstack.org/#/c/456394/ This work never moved
anywhere since the spec was posted though. You may want to revive the
discussion in scope of the spec.

Ihar

On Fri, Sep 29, 2017 at 12:21 PM, Giuseppe de Candia
 wrote:
> Hi Folks,
>
>
>
> My intent in this e-mail is to solicit advice for how to inject SSH host
> certificates into VM instances, with minimal or no burden on users.
>
>
>
> Background (skip if you're already familiar with SSH certificates): without
> host certificates, when clients ssh to a host for the first time (or after
> the host has been re-installed), they have to hope that there's no man in
> the middle and that the public key being presented actually belongs to the
> host they're trying to reach. The host's public key is stored in the
> client's known_hosts file. SSH host certicates eliminate the possibility of
> Man-in-the-Middle attack: a Certificate Authority public key is distributed
> to clients (and written to their known_hosts file with a special syntax and
> options); the host public key is signed by the CA, generating an SSH
> certificate that contains the hostname and validity period (among other
> things). When negotiating the ssh connection, the host presents its SSH host
> certificate and the client verifies that it was signed by the CA.
>
>
>
> How to support SSH host certificates in OpenStack?
>
>
>
> First, let's consider doing it by hand, instance by instance. The only
> solution I can think of is to VNC to the instance, copy the public key to my
> CA server, sign it, and then write the certificate back into the host (again
> via VNC). I cannot ssh without risking a MITM attack. What about using Nova
> user-data? User-data is exposed via the metadata service. Metadata is
> queried via http (reply transmitted in the clear, susceptible to snooping),
> and any compute node can query for any instance's meta-data/user-data.
>
>
>
> At this point I have to admit I'm ignorant of details of cloud-init. I know
> cloud-init allows specifying SSH private keys (both for users and for SSH
> service). I have not yet studied how such information is securely injected
> into an instance. I assume it should only be made available via ConfigDrive
> rather than metadata-service (again, that service transmits in the clear).
>
>
>
> What about providing SSH host certificates as a service in OpenStack? Let's
> keep out of scope issues around choosing and storing the CA keys, but the CA
> key is per project. What design supports setting up the SSH host certificate
> automatically for every VM instance?
>
>
>
> I have looked at Vendor Data and I don't see a way to use that, mainly
> because 1) it doesn't take parameters, so you can't pass the public key out;
> and 2) it's queried over http, not https.
>
>
>
> Just as a feasibility argument, one solution would be to modify Nova compute
> instance boot code. Nova compute can securely query a CA service asking for
> a triplet (private key, public key, SSH certificate) for the specific
> hostname. It can then inject the triplet using ConfigDrive. I believe this
> securely gets the private key into the instance.
>
>
>
> I cannot figure out how to get the equivalent functionality without
> modifying Nova compute and the boot process. Every solution I can think of
> risks either exposing the private key or vulnerability to a MITM attack
> during the signing process.
>
>
>
> Your help is appreciated.
>
>
>
> --Pino
>
>
> __
> 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-dev] [neutron] Ocata moving to phase II

[Ihar Hrachyshka]

Hi all,

with the latest Ocata release[1], stable/ocata branches now officially
move to phase II support. The phase is defined in [2] as:

"Only critical bugfixes and security patches are acceptable."

In Neutron, it usually means that we may now allow fixes for High and
Critical bugs only. (Plus CVEs.) Of course, test fixes,
infrastructural fixes for gates, more test coverage, documentation
fixes are all valid fixes still, because they are by their own nature
don't affect production instances of Neutron.

And of course, Pike is now our main focus for all kinds of backports.

[1] https://review.openstack.org/#/c/505814/
[2] https://docs.openstack.org/project-team-guide/stable-branches.html

Ihar

__
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 native ovs firewall driver

[Ihar Hrachyshka]

On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
 wrote:
> So I was forced to explicitly set the MTU on br-int
> ovs-vsctl set int br-int mtu_request=9000
>
>
> Without this the tap device added to br-int would get MTU 1500
>
> Would this be something the ovs l2 agent can handle since it creates the 
> bridge?

Yes, I guess we could do that if it fixes your problem. The issue
stems from the fact that we use a single bridge for different networks
with different MTUs, and it does break some assumptions kernel folks
make about a switch (that all attached ports steer traffic in the same
l2 domain, which is not the case because of flows we set). You may
want to report a bug against Neutron and we can then see how to handle
that. I will probably not be as simple as setting the value to 9000
because different networks have different MTUs, and plugging those
mixed ports in the same bridge may trigger MTU updates on unrelated
tap devices. We will need to test how kernel behaves then.

Also, you may be interested in reviewing an old openvswitch-dev@
thread that I once started here:
https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316733.html
Sadly, I never followed up with a test scenario that wouldn't involve
OpenStack, for OVS folks to follow up on, so it never moved anywhere.

Cheers,
Ihar

__
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] Denver Team Dinner

[Ihar Hrachyshka]

+1

On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  wrote:
> +1
>
> On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński 
> wrote:
>>
>> +1
>>
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>>
>>
>>
>>
>> > Wiadomość napisana przez Miguel Lavalle  w dniu
>> > 12.09.2017, o godz. 17:23:
>> >
>> > Dear Neutrinos,
>> >
>> > Our social event will take place on Thursday September 12th at 7:30pm.
>> > The venue is going to be https://www.famousdaves.com/Denver-Stapleton. It 
>> > is
>> > located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
>> > minutes walk.
>> >
>> > I have a reservation for a group of 30 people under my name. Please
>> > respond to this message with your attendance confirmation by Wednesday
>> > night, so I can get a more accurate head count.
>> >
>> > Looking forward to see y'all Thursday night
>> >
>> > Best regards
>> >
>> > Miguel
>> >
>> > __
>> > 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] removing screen from devstack - RSN

[Ihar Hrachyshka]

On Fri, Sep 8, 2017 at 2:17 PM, John Villalovos
 wrote:
> Does this mean we can now get more user friendly names for the log files?
>
> Currently I see names like:
> screen-dstat.txt.gz
> screen-etcd.txt.gz
> screen-g-api.txt.gz
> screen-g-reg.txt.gz
> screen-ir-api.txt.gz
> screen-ir-cond.txt.gz
> screen-keystone.txt.gz
> screen-n-api-meta.txt.gz
> screen-n-api.txt.gz
> screen-n-cauth.txt.gz
> screen-n-cond.txt.gz
> screen-n-cpu.txt.gz
> screen-n-novnc.txt.gz
> screen-n-sch.txt.gz
> screen-peakmem_tracker.txt.gz
> screen-placement-api.txt.gz
> screen-q-agt.txt.gz
> screen-q-dhcp.txt.gz
> screen-q-l3.txt.gz
> screen-q-meta.txt.gz
> screen-q-metering.txt.gz
> screen-q-svc.txt.gz
> screen-s-account.txt.gz
> screen-s-container.txt.gz
> screen-s-object.txt.gz
> screen-s-proxy.txt.gz
>
> People new to OpenStack don't really know that 'q' means neutron.

This should be part of gate switch to lib/neutron that stalled for a
while: https://review.openstack.org/#/c/436798

Ihar

__
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] - transitioning PTL role to Miguel Lavalle

[Ihar Hrachyshka]

It's very sad news for the team, but I hope that Kevin will still be
able to contribute, or at least stay in touch. I am sure Miguel will
successfully lead the community in Queens and beyond. Thanks to Miguel
for stepping in the ring. Thanks to Kevin for his leadership in recent
cycles.

King is dead, long live the King!

Ihar

On Fri, Sep 8, 2017 at 8:59 PM, Kevin Benton  wrote:
> Hi everyone,
>
> Due to a change in my role at my employer, I no longer have time to be the
> PTL of Neutron. Effective immediately, I will be transitioning the PTL role
> to Miguel Lavalle.
>
> Miguel is an excellent leader in the community and has experience reviewing
> patches as a core, reviewing feature requests and specs as a driver,
> implementing cross-project features, handling docs, and on-boarding new
> contributors.
>
> We will make the switch official next week at the PTG with the appropriate
> patches to the governance repo.
>
> If anyone has any concerns with this transition plan, please reach out to
> me, Thierry, or Doug Hellmann.
>
> Cheers,
> 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
>

__
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] [neutron] no upgrades meeting tomorrow

[Ihar Hrachyshka]

Hi,

I won't be able to chair the meeting because of a conference, so I
cancel it. We won't have one the week after that because of PTG
either. We will meet the next time in two weeks.

Thanks,
Ihar

__
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][puppet] mod_wsgi support (pike bug?)

[Ihar Hrachyshka]

On Mon, Sep 4, 2017 at 8:07 AM, Kevin Benton  wrote:
> #2 would be preferable as well just because we have so many guides/distros
> mentioning the different file locations. I'm not familiar with mod_wsgi
> enough to know if it's possible.
>
> Another 3rd option may be to edit the oslo config constructor call when
> using that entry point to add some well-known paths for additional config
> files rather than only parsing 'sys.argv[1]'. For example, we could always
> try to add /etc/neutron/plugin.ini to the list which we can document that
> distros/deployment tools should always create or have a symbolic link to a
> plugin-specific config (e.g. ml2_conf.ini).

For the record, oslo.config already reads /etc/neutron/neutron.conf
(and some other locations) when no arguments are passed:

https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L711-L739

Also for the record, I consider not being able to load existing split
configuration files a regression. We won't be able to move to the new
operation mode unless we figure out how to load them. If mod_wsgi is
not willing to bend their argv, a envvar could be a good option.

Ihar

__
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] [tests] [tempest] Neutron dvr tempest test problem

[Ihar Hrachyshka]

On Thu, Aug 24, 2017 at 5:13 AM, Luigi Toscano  wrote:
> On Thursday, 24 August 2017 12:51:05 CEST Ning Yao wrote:
>> Hi, all
>>
>> I encounter a problem about neutron tempest test. I run the tempest
>> neutron plugin test against my self-build OpenStack, and I find that
>> tempest will run the dvr test and report NotImplementedERROR. I dig
>> into the test code and find that even if I do not enable dvr router
>> for my OpenStack, the dvr test runs and does not automatically skip.
>> This is because it only skip this logic when
>> network-feature-enabled.api_extensions does not support dvr.
>
> I think that you hit this:
>
> https://bugs.launchpad.net/neutron/+bug/1450067
>
> which should be fixed from Pike.

Yes. Operator should also set enable_dvr = False for neutron-server so
that it doesn't advertise support for 'dvr' API extension.

Thanks,
Ihar

__
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] [neutron] no CI and upgrades meetings this week

[Ihar Hrachyshka]

Hi,

we are in pre-release mode, and some of active participants will not
be able to join those meetings, so we will cancel them this week.

Thanks, and see you all next week.
Ihar

__
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] Functional job failure rate at 100%

[Ihar Hrachyshka]

On Mon, Aug 7, 2017 at 2:52 AM, Jakub Libosvar  wrote:
> Hi all,
>
> as per grafana [1] the functional job is broken. Looking at logstash [2]
> it started happening consistently since 2017-08-03 16:27. I didn't find
> any particular patch in Neutron that could cause it.
>
> The culprit is that ovsdb starts misbehaving [3] and then we retry calls
> indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
> a bug [4] and started investigation, I'll update my findings there.
>
> I think at this point there is no reason to run "recheck" on your patches.
>
> Thanks,
> Jakub
>
> [1]
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
> [2] http://bit.ly/2vdKMwy
> [3]
> http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> [4] https://bugs.launchpad.net/neutron/+bug/1709032

Considering all the instability of the job we see lately (this bug
being the latest hit, but we also have bug
https://bugs.launchpad.net/neutron/+bug/1707933, close release, and no
significant resources on digging the issue, I propose to temporarily
disable the job: https://review.openstack.org/#/c/491548/. I also
suggest our mighty leadership to harness awareness of the issue and
rally troops to get it solved.

(to reply to Kevin's request in IRC) To recap what happened with
timeout bug: https://bugs.launchpad.net/neutron/+bug/1707933, it
popped up ~ month ago in master, but it hits Ocata branch too (so it's
either a recent backport, or some external dependency). The way it
happens is one of test worker (almost always running a
FirewallTestCase test case) dies in the middle of run (you can see
'Killed' message in console log, and most of the times, you can also
see the job taking ~2h and the last test worker dying with
'inprogress' state). The first hypothesis was that some (other?) test
case calls execute(['kill', ...]) with the worker PID. To check that,
Jakub proposed https://review.openstack.org/#/c/487065/ and rechecked
for a while until the bug was triggered in the gate. The collected log
suggested that kill was NOT called with the PID. The next step could
be catching all os.kill() calls in all functional tests and logging
their arguments somewhere (with call stacks). We were thinking of
mocking os.kill, replacing it with a function that would log and pass
it to the original implementation, but didn't have time for that so
far.

Regards,
Ihar

__
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] Call for help with in-tree tempest scenario test failures

[Ihar Hrachyshka]

Thanks for those who stepped in (Armando and Slawek).

We still have quite some failures that would benefit from initial log
triage and fixes. If you feel like in this feature freeze time you
have less things to do, helping with those scenario failures would be
a good way to contribute to the project.

Thanks,
Ihar

On Fri, Jul 28, 2017 at 6:02 AM, Sławek Kapłoński  wrote:
> Hello,
>
> I will try to check QoS tests in this job.
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
>> Wiadomość napisana przez Jakub Libosvar  w dniu 
>> 28.07.2017, o godz. 14:49:
>>
>> Hi all,
>>
>> as sending out a call for help with our precious jobs was very
>> successful last time and we swept all Python 3 functional from Neutron
>> pretty fast (kudos the the team!), here comes a new round of failures.
>>
>> This time I'm asking for your help > poster here> with gate-tempest-dsvm-neutron-dvr-multinode-scenario
>> non-voting job. This job has been part of check queue for a while and is
>> very very unstable. Such job covers scenarios like router dvr/ha/legacy
>> migrations, qos, trunk and dvr. I went through current failures and
>> created an etherpad [1] with categorized failures and logstash queries
>> that give you latest failures with given particular tests.
>>
>> If you feel like doing troubleshooting and sending fixes for gates,
>> please pick one test and write down your name to the test.
>>
>> Thanks to all who are willing to participate.
>>
>> Have a great weekend.
>> Jakub
>>
>>
>> [1]
>> https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures
>>
>>
>> __
>> 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-dev] [neutron] FFE for net-mtu-enh api extension requested

[Ihar Hrachyshka]

Hi PTL/all,

I would like to request an exception for inclusion of net-mtu-enh API
extension (with ML2 implementation) for Pike.

The patch is ready for review, it includes tempest tests and docs
update. There are several things in the patch that we will need to
follow up in the next release (hence a lot of TODOs), but those are
not because the patch is not complete, but because we need to
accommodate for rolling upgrades of controllers.

The RFE: https://launchpad.net/bugs/1671634
The patch: https://review.openstack.org/#/c/483518/

Best regards,
Ihar

__
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] Proposal to change integrated neutron grenade gate job to multi-node

[Ihar Hrachyshka]

I don't see any issue with it, but it would be great to hear from
infra. They may have their reservations because the change may
somewhat raise pressure on the number of nodes (that being said, there
are some savings too for projects that currently run both versions of
the job at the same time - one via integrated gate and another
project-specific).

Ihar

On Fri, Jul 14, 2017 at 2:05 PM, Brian Haley  wrote:
> Hi,
>
> While looking at ways to reduce the number of jobs we run in the Neutron
> gate, I found we ran two very similar jobs for some projects:
>
> gate-grenade-dsvm-neutron-ubuntu-xenial (single-node job)
> gate-grenade-dsvm-neutron-multinode-ubuntu-xenial (2-node job)
>
> We talked about this in the Neutron CI meeting this week [1] and felt it
> best to remove the single-node job and just run the multi-node job, mostly
> because it more mimics a "real" Neutron deployment where there are separate
> controller and compute nodes.  Looking at the Neutron grafana dashboard [2]
> the two jobs have about the same failure rate in the gate (~0), so I don't
> think there will be any problems with the switch.
>
> This has an impact on the integrated gate since it currently runs the
> single-node job, so I wanted ot get thoughts on any issues they'd have with
> this change [3].
>
> Thanks,
>
> -Brian
>
> [1]
> http://eavesdrop.openstack.org/meetings/neutron_ci/2017/neutron_ci.2017-07-11-16.00.log.html#l-112
> [3] http://grafana.openstack.org/dashboard/db/neutron-failure-rate
> [2] https://review.openstack.org/#/c/483600/
>
> __
> 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] DSVM gates for networking-l2gw

[Ihar Hrachyshka]

It may be a non-negligible effort to make ovs containerized in the
namespace in the first place (that's one of the things we still miss
in fullstack in neutron repo). I know that Terry Wilson had some code
for that, but I can't find it right now.

Ihar

On Thu, Jul 6, 2017 at 1:57 AM, Ricardo Noriega De Soto
<rnori...@redhat.com> wrote:
> The idea for the future is to enable a new job with the l2gw agent enabled.
> In order to do that, I thought about creating a network namespace running an
> OVS instance with the hwvtep schema so the l2gw agent can connect to it.
> This is just a first rough idea and I haven't tested anything.
>
> Do you have any other good approach for this???
>
> On Mon, Jul 3, 2017 at 5:14 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>> Plan sounds fine. Those interested in ovs backend may build on top,
>> but at least laying basic api coverage with a fake/dummy driver is a
>> must for a service plugin project that is serious about integration
>> with Neutron.
>>
>> Ihar
>>
>> On Wed, Jun 14, 2017 at 9:38 PM, Ricardo Noriega De Soto
>> <rnori...@redhat.com> wrote:
>> > Hello L2GWers
>> >
>> > Currently networking-l2gw CI only covers unit tests. However, there is
>> > an
>> > experimental check that starts a devstack VM to be able to run more
>> > complex
>> > tests. That experimental check is not working, and we are trying to fix
>> > it,
>> > however we encountered some difficulties that we wanted to share with
>> > you.
>> >
>> > https://review.openstack.org/#/c/471692/
>> >
>> > The configuration of the experimental check uses the L2GW agent which is
>> > very good, however, the API tests try to create a l2gw connection and
>> > fail
>> > since there is not an ovsdb instance with the vtep schema to execute.
>> >
>> > If we use the dummy driver, these three failing testcases will be
>> > skipped
>> > and we have a way to test the API (without backend).
>> >
>> > So for now, our proposal is to modify this experimental check using the
>> > dummy driver, and convert it to a possible non-voting -> voting gate
>> > executing pure API tests.
>> >
>> > Furthermore, we will start working on a new gate with the l2gw agent and
>> > create a new OVS entity in a namespace or something similar to be able
>> > to
>> > test api and agent together.
>> >
>> > Any comment is more than welcome!
>> >
>> > Thanks guys
>> >
>> > --
>> > Ricardo Noriega
>> >
>> > Senior Software Engineer - NFV Partner Engineer | Office of Technology
>> > |
>> > Red Hat
>> > irc: rnoriega @freenode
>> >
>> >
>> >
>> > __
>> > 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
>
>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
> __
> 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] writable mtu

[Ihar Hrachyshka]

On Wed, Jul 5, 2017 at 6:43 PM, Ian Wells  wrote:
> I think I misinterpreted: you'd enable all options and then deal with the
> consequences in the backend code which has to implement one the of the
> previously listed behaviours?  That seems sane to me provided the required
> behaviours are documented somewhere where a driver implementer has to trip
> over them.

Yeah. Only with a twist that I believe we also need a 'flag' extension
that would indicate that MTU is writable.

Ihar

__
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] writable mtu

[Ihar Hrachyshka]

On Wed, Jul 5, 2017 at 6:11 PM, Ian Wells <ijw.ubu...@cack.org.uk> wrote:
> On 5 July 2017 at 14:14, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>> Heya,
>>
>> we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
>> Pike that allows setting MTU for network on creation.
>
>
> This was actually in the very first MTU spec (in case no one looked), though
> it never got implemented.  The spec details a whole bunch of stuff about how
> to calculate whether the proposed MTU will fit within the encap,
> incidentally, and will reject network creations when it doesn't.
>
> Note that the MTU attribute was intended to represent an MTU that will
> definitely transit.  I guess no-one would actually rely on this, but to
> clarify, it's not intended to indicate that bigger packets will be dropped,
> only that smaller packets will not be dropped (which is the guarantee you
> need for two VMs to talk to each other.  Thus the MTU doesn't need to be
> increased just because the infrastructure MTU has become larger; it just
> means that future networks can be created with larger MTUs from this point,
> and the current MTU will still be valid.
>
> This is also the MTU that all VMs on that network will be told, because they
> need to use the same value to function.  If you change it, VMs after the
> event will have problems talking to their earlier friends because they will
> now disagree on MTU (and routers will have problems talking to at least one
> of those sets).
>
>> (but not update,
>> as per latest comment from Kevin there) I already see a use case to
>> modify MTU for an existing network (for example, where you enable
>> Jumbo frames for underlying infrastructure, and want to raise the
>> ceiling; another special case is when you migrate between different
>> encapsulation technologies, like in case of ml2/ovs to networking-ovn
>> migration where the latter doesn't support VXLAN but Geneve only).
>
>
> You look like you're changing the read-only segmentation type of the network
> on this migration - presumably in the DB directly - so you're changing
> non-writeable fields already.  Couldn't the MTU be changed in a similarly
> offline manner?

Yeah, you are correct, but we may also hack it around in
networking-ovn by implying all tunneled networks are actually geneve
despite the type in database. (I understand that's rather hackish, but
the very idea of migrating to a driver that doesn't natively support
your tunnel type is hackish af).

Nevertheless, the case where operators want to increase MTU for
existing networks after infrastructure MTU upgrade still stands.

>
> That said: what will you do with existing VMs that have been told the MTU of
> their network already?

Same as we do right now when modifying configuration options defining
underlying MTU: change it on API layer, update data path with the new
value (tap to brq to router/dhcp legs) and hope instances will get
there too (by means of dhcp lease refresh eventually happening, or
rebooting instances, or else). There is no silver bullet here, we have
no way to tell instances to update their interface MTUs.

At least not till we get both new ovs and virtio-net in the guests
that will know how to deal with MTU hints:
https://bugzilla.redhat.com/show_bug.cgi?id=1408701
https://bugzilla.redhat.com/show_bug.cgi?id=1366919
(there should also be ovs integration piece but I can't find it right away.)

Though even with that, I don't know if guest will be notified about
changes happening during its execution, or only on boot (that probably
depends on whether virtio polls the mtu storage). And anyway, it
depends on guest kernel, so no luck for windows guests and such.

>
> Put a different way, a change to the infrastructure can affect MTUs in two
> ways:
>
> - I increase the MTU that a network can pass (by, for instance, increasing
> the infrastructure of the encap).  I don't need to change its MTU because
> VMs that run on it will continue to work.  I have no means to tell the VMs
> they have a bigger MTU now, and whatever method I might use needs to be 100%
> certain to work or left-out VMs will become impossible to talk to, so
> leaving the MTU alone is sane.

In this scenario, it sounds like you assume everything will work just
fine. But you don't consider neutron routers that will enforce the new
larger MTU for fragmentation, that may end up sending frames to
unaware VMs of size that they can't choke.

> - I decrease the MTU that a network can pass (by, for instance, using an
> encap with larger headers).  The network comprehensively breaks; VMs
> frequently fail to communicate regardless of whether I change the network
> MTU property, because running VMs have already learned their MTU value and,
> again, there's no way to up

[openstack-dev] [neutron] writable mtu

[Ihar Hrachyshka]

Heya,

we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
Pike that allows setting MTU for network on creation. (but not update,
as per latest comment from Kevin there) I already see a use case to
modify MTU for an existing network (for example, where you enable
Jumbo frames for underlying infrastructure, and want to raise the
ceiling; another special case is when you migrate between different
encapsulation technologies, like in case of ml2/ovs to networking-ovn
migration where the latter doesn't support VXLAN but Geneve only).

If I go and implement the RFE as-is, and later in Queens we pursue
updating MTU for existing networks, we will have three extensions for
the same thing.

- net-mtu (existing read only attribute)
- net-mtu-enhanced (allow write on create)
- net-mtu-enhanced-enhanced (allow updates)

Not to mention potential addition of per-port MTU that some folks keep
asking for (and we keep pushing against so far).

So, I wonder if we can instead lay the ground for updatable MTU right
away, and allow_post: True from the start, even while implementing
create only as a phase-1. Then we can revisit the decision if needed
without touching api. What do you think?

Another related question is, how do we expose both old and new
extensions at the same time? I would imagine that implementations
capable of writing to the mtu attribute would advertise both old and
new extensions. Is it correct? Does neutron api layer allow for
overlapping attribute maps?

Ihar

__
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] [neutron] no CI meeting tomorrow

[Ihar Hrachyshka]

It's July 4th, so we'll skip the meeting.

Ihar

__
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] DSVM gates for networking-l2gw

[Ihar Hrachyshka]

Plan sounds fine. Those interested in ovs backend may build on top,
but at least laying basic api coverage with a fake/dummy driver is a
must for a service plugin project that is serious about integration
with Neutron.

Ihar

On Wed, Jun 14, 2017 at 9:38 PM, Ricardo Noriega De Soto
 wrote:
> Hello L2GWers
>
> Currently networking-l2gw CI only covers unit tests. However, there is an
> experimental check that starts a devstack VM to be able to run more complex
> tests. That experimental check is not working, and we are trying to fix it,
> however we encountered some difficulties that we wanted to share with you.
>
> https://review.openstack.org/#/c/471692/
>
> The configuration of the experimental check uses the L2GW agent which is
> very good, however, the API tests try to create a l2gw connection and fail
> since there is not an ovsdb instance with the vtep schema to execute.
>
> If we use the dummy driver, these three failing testcases will be skipped
> and we have a way to test the API (without backend).
>
> So for now, our proposal is to modify this experimental check using the
> dummy driver, and convert it to a possible non-voting -> voting gate
> executing pure API tests.
>
> Furthermore, we will start working on a new gate with the l2gw agent and
> create a new OVS entity in a namespace or something similar to be able to
> test api and agent together.
>
> Any comment is more than welcome!
>
> Thanks guys
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
> __
> 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-dev] [neutron] no CI and upgrades meetings in next two weeks

[Ihar Hrachyshka]

Hi all,

subject says it all. Also note that upgrades meeting moved to
Thursday: https://review.openstack.org/474347

Ihar

__
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] security group OVO change

[Ihar Hrachyshka]

To close the loop here,

- this also broke heat py3 job (https://launchpad.net/bugs/1698355)
- we polished https://review.openstack.org/474575 to fix both
vmware-nsx and heat issues
- I also posted a patch for oslo.serialization for the bug that
triggered MemoryError in heat gate:
https://review.openstack.org/475052
- the vmware-nsx adoption patch is at:
https://review.openstack.org/#/c/474608/ and @boden is working on it,
should be ready to go in due course.

Thanks and sorry for inconveniences,
Ihar

On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton  wrote:
> Hi,
>
> The commit https://review.openstack.org/284738 has broken decomposed plugins
> (those that extend security groups and rules). The reason for this is that
> there is a extend callback that we use which expects to get a database
> object and the aforementioned patch passes a new neutron object.
>
> I have posted [i] to temporarily address the issue. An alternative is to
> revert the patch until the decomposed plugins can figure out how to
> correctly address this.
>
> Thanks
>
> Gary
>
> [i] https://review.openstack.org/474575
>
>
> __
> 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-dev] [neutron][upgrades] no meeting today

[Ihar Hrachyshka]

And sorry for late notice.

Ihar

__
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] pep8 breakage

[Ihar Hrachyshka]

UPD: in case you wonder if that's fixed, we are waiting for 
https://review.openstack.org/#/c/471763/ to land.


Ihar


On 06/07/2017 05:23 AM, Akihiro Motoki wrote:

Six 1.10.0 is not the root cause. The root cause is the version bump
of pylint (and astroid).
Regarding pylint and astroid, I think the issue will go once
https://review.openstack.org/#/c/469491/ is merged.
However, even after the global requirement is merged, neutron pylint will fail
because pylint 1.7.1 has a bit different syntax check compared to pylint 1.4.3.

I wonder pylint version bump should be announced because it
potentially breaks individual project gate.

Is it better to revert pylint version bump in global-requirements, or
just to ignore some pylint rules temporarily in neutron?

Akihiro


2017-06-07 20:43 GMT+09:00 Gary Kotton :

Hi,

Please see bug https://bugs.launchpad.net/neutron/+bug/1696403. Seems like
six 1.10.0 has broken us.

I have posted a patch in the requirements project. Not 100% sure that this
is the right way to go. At least that will enable us to address this in
neutron.

Thanks

Gary


__
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] [stable][kolla][release] Policy regarding backports of gate code

[Ihar Hrachyshka]

On 06/05/2017 09:42 AM, Michał Jastrzębski wrote:

My question is, is it ok to backport gate logic to stable branch?
Regular code doesn't change so it might not be considered a feature
backport (users won't see a thing).


Yes, that's allowed. Stable maintainers are concerned about 
destabilizing production code. Touching gate infrastructure, adding 
tests, updating documentation is almost always ok. (Assuming your 
changes don't e.g. reduce test coverage.)


Ihar

__
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] [tc][ptls][all] Potential Queens Goal: Migrate Off Paste

[Ihar Hrachyshka]

On Fri, Jun 2, 2017 at 1:21 PM, Matt Riedemann  wrote:
> I don't think the maintenance issue is the prime motivator, it's the fact
> paste is in /etc which makes it a config file and therefore an impediment to
> smooth upgrades. The more we can move into code, like default policy and
> privsep, the better.

I am not sure this problem is of general interest to all code
consumers. For one, the fact that we even consider the file a
configuration file (and put it under /etc) is just a glitch that could
be easily fixed by 1) stopping considering it a config file; and 2)
moving it out of /etc/. Actually, both 1) and 2) are already done in
RDO/RH-OSP for quite some time, and I think nothing blocks others to
do the same, or upstream to adopt this stance. If that's the only
issue with the current approach, then I can't see how this is of broad
community interest to tackle it and not something more user
visible/impactful.

As for the library being not maintained, this can be solved
organizationally, without impacting consuming projects.

Ihar

__
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] no upgrades meeting on May 29th

[Ihar Hrachyshka]

It's Memorial day in US.

Ihar

__
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-sfc] pep8 failing

[Ihar Hrachyshka]

Make sure you have the latest neutron-lib in your tree: neutron-lib==1.6.0

On Tue, May 16, 2017 at 3:05 AM, Vikash Kumar
 wrote:
> Hi Team,
>
>   pep8 is failing in master code. translation hint helpers are removed from
> LOG messages. Is this purposefully done ? Let me know if it is not, will
> change it.
>
> ./networking_sfc/db/flowclassifier_db.py:342:13: N531  Log messages require
> translation hints!
> LOG.info("Deleting a non-existing flow classifier.")
> ^
> ./networking_sfc/db/sfc_db.py:383:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port chain.")
> ^
> ./networking_sfc/db/sfc_db.py:526:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port pair.")
> ^
> ./networking_sfc/db/sfc_db.py:658:13: N531  Log messages require translation
> hints!
> LOG.info("Deleting a non-existing port pair group.")
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:38:9: N531  Log
> messages require translation hints!
> LOG.info("Configured Flow Classifier drivers: %s", names)
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:44:9: N531  Log
> messages require translation hints!
> LOG.info("Loaded Flow Classifier drivers: %s",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:80:9: N531  Log
> messages require translation hints!
> LOG.info("Registered Flow Classifier drivers: %s",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:87:13: N531  Log
> messages require translation hints!
> LOG.info("Initializing Flow Classifier driver '%s'",
> ^
> ./networking_sfc/services/flowclassifier/driver_manager.py:107:17: N531  Log
> messages require translation hints!
> LOG.error(
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:63:17: N531  Log messages
> require translation hints!
> LOG.error("Create flow classifier failed, "
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:87:17: N531  Log messages
> require translation hints!
> LOG.error("Update flow classifier failed, "
> ^
> ./networking_sfc/services/flowclassifier/plugin.py:102:17: N531  Log
> messages require translation hints!
> LOG.error("Delete flow classifier failed, "
> ^
> ./networking_sfc/services/sfc/driver_manager.py:38:9: N531  Log messages
> require translation hints!
> LOG.info("Configured SFC drivers: %s", names)
> ^
> ./networking_sfc/services/sfc/driver_manager.py:43:9: N531  Log messages
> require translation hints!
> LOG.info("Loaded SFC drivers: %s", self.names())
> ^
> ./networking_sfc/services/sfc/driver_manager.py:78:9: N531  Log messages
> require translation hints!
> LOG.info("Registered SFC drivers: %s",
> ^
> ./networking_sfc/services/sfc/driver_manager.py:85:13: N531  Log messages
> require translation hints!
> LOG.info("Initializing SFC driver '%s'", driver.name)
> ^
> ./networking_sfc/services/sfc/driver_manager.py:104:17: N531  Log messages
> require translation hints!
> LOG.error(
> ^
> ./networking_sfc/services/sfc/plugin.py:57:17: N531  Log messages require
> translation hints!
> LOG.error("Create port chain failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:82:17: N531  Log messages require
> translation hints!
> LOG.error("Update port chain failed, port_chain '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:97:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port chain failed, portchain '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:122:17: N531  Log messages require
> translation hints!
> LOG.error("Create port pair failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:144:17: N531  Log messages require
> translation hints!
> LOG.error("Update port pair failed, port_pair '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:159:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port pair failed, port_pair '%s'",
> ^
> ./networking_sfc/services/sfc/plugin.py:185:17: N531  Log messages require
> translation hints!
> LOG.error("Create port pair group failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:213:17: N531  Log messages require
> translation hints!
> LOG.error("Update port pair group failed, "
> ^
> ./networking_sfc/services/sfc/plugin.py:229:17: N531  Log messages require
> translation hints!
> LOG.error("Delete port pair 

[openstack-dev] [neutron] no upgrades meeting tomorrow

[Ihar Hrachyshka]

Hi,

I have some unexpected family obligations for the time slot that just
popped up that I can't postpone, so we will need to cancel the meeting. I
believe it's also reasonable since we haven't made much progress on action
items pointed out during the previous meeting, so let's meet once we have
those covered.

See you in a week.

Ihar
__
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] [neutron] no CI or upgrades meetings this week

[Ihar Hrachyshka]

And no CI meetings in next two weeks after the summit because of no planned
attendance from main participants.

Ihar
__
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] [neutron] no upgrades meeting on May 1

[Ihar Hrachyshka]

Hi,

Due to a conflict in my schedule, I need to cancel the meeting this Monday.

Ihar
__
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] All Hail our Newest Release Name - OpenStack Rocky

[Ihar Hrachyshka]

Hi,

It would also be nice to actually get an email to vote. I haven't seen one.
:) Not that I'm not ok with the name, just saying that it may be worth
exploring what happened.

Ihar

On Fri, Apr 28, 2017 at 3:34 PM Morgan Fainberg 
wrote:

> It would be nice if there was a bit more transparency on the "legal
> risk" (conflicts with another project, etc), but thanks for passing on
> the information none-the-less. I, for one, welcome our new "Rocky"
> overlord project name :)
>
> Cheers,
> --Morgan
>
> On Fri, Apr 28, 2017 at 2:54 PM, Monty Taylor 
> wrote:
> > Hey everybody!
> >
> > There isn't a ton more to say past the subject. The "R" release of
> OpenStack
> > shall henceforth be known as "Rocky".
> >
> > I believe it's the first time we've managed to name a release after a
> > community member - so please everyone buy RockyG a drink if you see her
> in
> > Boston.
> >
> > For those of you who remember the actual election results, you may recall
> > that "Radium" was the top choice. Radium was judged to have legal risk,
> so
> > as per our name selection process, we moved to the next name on the list.
> >
> > Monty
> >
> > ___
> > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openst...@lists.openstack.org
> > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> __
> 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-dev] [neutron] CI team meeting on Apr 25 canceled

[Ihar Hrachyshka]

Hi,

sorry for late update, but I will not be offline for the time of the
meeting, so I guess we will cancel.

Ihar
__
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][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

[Ihar Hrachyshka]

All traffic is denied by default. OpenStack security groups API is
modeled to reflect what AWS does. You may find your needs better
served by fwaas plugin for neutron that is not constrained by AWS
compatibility.

Ihar

On Sun, Apr 23, 2017 at 8:33 PM, 田明明  wrote:
> Can we add an "action" to security group rule api, so that we could dispatch
> rules with "deny" action? Until now， security group only supports add
> white-list rules but this couldn't satisfy many people's needs.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> 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] Development workflow for bunch of patches

[Ihar Hrachyshka]

Sometimes it's possible to avoid the stacking, and instead just rely
on Depends-On (usually in those cases where patches touch completely
different files). In that way, you won't need to restack on each
dependency respin. (But you may want to recheck to get fresh results.)
Of course it won't work as you may expect in local git checkout
because it doesn't know about Depends-On tags, so it's of limited
application.

Ihar

On Wed, Apr 19, 2017 at 1:11 AM, Sławek Kapłoński  wrote:
> Hello,
>
> I have a question about how to deal with bunch of patches which depends one
> on another.
> I did patch to neutron (https://review.openstack.org/#/c/449831/) which is
> not merged yet but I wanted to start also another patch which is depend on
> this one (https://review.openstack.org/#/c/457816/).
> Currently I was trying to do something like:
> 1. git review -d 
> 2. git checkout -b new_branch_for_second_patch
> 3. Make second patch, commit all changes
> 4. git review <— this will ask me if I really want to push two patches to
> gerrit so I answered „yes”
>
> Everything is easy for me as long as I’m not doing more changes in first
> patch. How I should work with it if I let’s say want to change something in
> first patch and later I want to make another change to second patch? IIRC
> when I tried to do something like that and I made „git review” to push
> changes in second patch, first one was also updated (and I lost changes made
> for this one in another branch).
> How I should work with something like that? Is there any guide about that (I
> couldn’t find such)?
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> __
> 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] [qa][gate] tempest slow - where do we execute them in gate?

[Ihar Hrachyshka]

On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier
 wrote:
> We don"t run slow tests because the QA team think that they don't bring
> enough value to be executed, every time and everywhere. The idea is that if
> some specific slow tests are of some interest to some specific openstack
> projects, those projects can change the config of their jobs to enable these
> tests.


But since it's not executed anywhere in tempest gate, even as
non-voting (?), it's effectively dead code that may be long broken
without anyone knowing. Of course there are consumers of the tests
downstream, but for those consumers it's a tough call to start
depending on the tests if they are not sanity checked by tempest
itself. Wouldn't it make sense to have some job in tempest gate that
would execute those tests (maybe just them to speed up such a job?
maybe non-voting? maybe even as periodic? but there should be
something that keeps it green in long run).

Ihar

__
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] Switching gate testing to use Ubuntu Cloud Archive

[Ihar Hrachyshka]

I just saw the plan merged in master:
https://review.openstack.org/#/c/451492/ That's cool! Can we also
backport the change to Ocata and maybe Newton so that we don't hit the
same bug there? The backport is already up:
https://review.openstack.org/#/c/456506/

Thanks,
Ihar

On Mon, Apr 3, 2017 at 4:06 PM, Clark Boylan  wrote:
> Hello,
>
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>
> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).
>
> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.
>
> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.
>
> Any other thoughts or ideas?
>
> [0] http://status.openstack.org/elastic-recheck/#1646779
> [1] http://status.openstack.org/elastic-recheck/#1643911
> [2] http://status.openstack.org/elastic-recheck/#1638982
> [3] https://review.openstack.org/451492
>
> Thank you,
> Clark
>
> __
> 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-dev] [qa][gate] tempest slow - where do we execute them in gate?

[Ihar Hrachyshka]

Hi all,

so I tried to inject a failure in a tempest test and was surprised
that no gate job failed because of that:
https://review.openstack.org/#/c/457102/1

It turned out that the test is not executed because we always ignore
all 'slow' tagged test cases:
http://logs.openstack.org/02/457102/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/89a08cc/console.html#_2017-04-17_01_43_39_115768

Question: do we execute those tests anywhere in gate, and if so,
where? (And if not, why, and how do we guarantee that they are not
broken by new changes?)

Ihar

__
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] [stable] What's the plan for mitaka-eol?

[Ihar Hrachyshka]

Yes, please cancel.

I don't even see at this point a need for a separate program for the
effort. It was applicable before when we dealt with stable gates on daily
basis, but it's no longer the case.

Ihar

On Mon, Apr 10, 2017 at 2:19 PM Matt Riedemann  wrote:

> There was no stable team meeting today but according to the release
> schedule page [1], Mitaka EOL happens after today. So what's the plan?
> Same old song and dance as always?
>
> Also, while I'm here, should the stable team meeting be cancelled? There
> hasn't been a meeting in a month [2]. Should we cancel the meeting and
> just use the mailing list for any needed communication?
>
> [1] https://releases.openstack.org/
> [2] http://eavesdrop.openstack.org/meetings/stable/2017/
>
> --
>
> Thanks,
>
> 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
>
__
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] Switching gate testing to use Ubuntu Cloud Archive

[Ihar Hrachyshka]

I mentioned that in a meeting today but for greater visibility...

This change in how we gate against LTS raises a question whether what
we claim in: 
https://review.openstack.org/#/c/402940/4/reference/project-testing-interface.rst
is still valid. The wording of the document is such that suggests we
test against LTS, and with the UCA adoption in gate, that will no
longer be true. I am not against the change per se, I just want the
decision to be thought through and advertised to consumers beyond
tight circle of upstream developers.

Ihar

On Mon, Apr 3, 2017 at 4:39 PM, Clark Boylan <cboy...@sapwetik.org> wrote:
> On Mon, Apr 3, 2017, at 04:33 PM, Ihar Hrachyshka wrote:
>> Are we going to keep some job not using the archive, to make sure we
>> don't
>> break people using packages from LTS? Maybe just periodic/non-voting
>> would
>> be enough to keep it working on older packages.
>
> Old stable branches will continue to run against the base LTS release.
> But considering that this is how users of Ubuntu get newer packages, the
> deployment projects are using it for newer branches, and we know that
> the base LTS is broken, I'm not sure how much benefit there would be to
> keep testing on the base LTS if we make the switch.
>
> Its important to note that anyone using base LTS is broken and we know
> this because of our testing.
>
> Clark
>
> __
> 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] [all] Switching gate testing to use Ubuntu Cloud Archive

[Ihar Hrachyshka]

Are we going to keep some job not using the archive, to make sure we don't
break people using packages from LTS? Maybe just periodic/non-voting would
be enough to keep it working on older packages.

On Mon, Apr 3, 2017 at 4:07 PM Clark Boylan  wrote:

> Hello,
>
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).
>
> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
>
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.
> On the positive side both the OpenStack puppet modules and OpenStack
> Ansible are using UCA with their deployment tooling so this should get
> us closer to what people are using in the wild.
>
> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).
>
> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.
>
> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.
>
> Any other thoughts or ideas?
>
> [0] http://status.openstack.org/elastic-recheck/#1646779
> [1] http://status.openstack.org/elastic-recheck/#1643911
> [2] http://status.openstack.org/elastic-recheck/#1638982
> [3] https://review.openstack.org/451492
>
> Thank you,
> Clark
>
> __
> 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] - Adding Miguel Lavalle to neutron-drivers team

[Ihar Hrachyshka]

On Thu, Mar 30, 2017 at 2:11 PM, Kevin Benton  wrote:
> Hi,
>
> I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team
> [1].

It's not completely clear if you seek support here, but in case you do, +1.

Ihar

__
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] [neutron] functional job broken by eventlet 0.20.1

[Ihar Hrachyshka]

Hi all,

FYI we were broken by the new eventlet. The fix is at:
https://review.openstack.org/#/c/447817/

Hopefully we can find reviewers in EMEA/APAC time zones to groom and land it.

Thanks,
Ihar

__
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] [QA][gate][all] dsvm gate stability and scenario tests

[Ihar Hrachyshka]

I had some patches to collect more stats about mlocks here:
https://review.openstack.org/#/q/topic:collect-mlock-stats-in-gate but they
need reviews.

Ihar

On Fri, Mar 17, 2017 at 5:28 AM Jordan Pittier 
wrote:

> The patch that reduced the number of Tempest Scenarios we run in every job
> and also reduce the test run concurrency [0] was merged 13 days ago. Since,
> the situation (i.e the high number of false negative job results) has not
> improved significantly. We need to keep looking collectively at this.
>
> There seems to be an agreement that we are hitting some memory limit.
> Several of our most frequent failures are memory related [1]. So we should
> either reduce our memory usage or ask for bigger VMs, with more than 8GB of
> RAM.
>
> There was/is several attempts to reduce our memory usage, by reducing the
> Mysql memory consumption ([2] but quickly reverted [3]), reducing the
> number of Apache workers ([4], [5]), more apache2 tuning [6]. If you have
> any crazy idea to help in this regard, please help. This is high priority
> for the whole openstack project, because it's plaguing many projects.
>
> We have some tools to investigate memory consumption, like some regular
> "dstat" output [7], a home-made memory tracker [8] and stackviz [9].
>
> Best,
> Jordan
>
> [0]: https://review.openstack.org/#/c/439698/
> [1]: http://status.openstack.org/elastic-recheck/gate.html
> [2] : https://review.openstack.org/#/c/438668/
> [3]: https://review.openstack.org/#/c/446196/
> [4]: https://review.openstack.org/#/c/426264/
> [5]: https://review.openstack.org/#/c/445910/
> [6]: https://review.openstack.org/#/c/446741/
> [7]:
> http://logs.openstack.org/96/446196/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b5c362f/logs/dstat-csv_log.txt.gz
> [8]:
> http://logs.openstack.org/96/446196/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b5c362f/logs/screen-peakmem_tracker.txt.gz
> [9] :
> http://logs.openstack.org/41/446741/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/fa4d2e6/logs/stackviz/#/stdin/timeline
>
> On Sat, Mar 4, 2017 at 4:19 PM, Andrea Frittoli  > wrote:
>
> Quick update on this, the change is now merged, so we now have a smaller
> number of scenario tests running serially after the api test run.
>
> We'll monitor gate stability for the next week or so and decide whether
> further actions are required.
>
> Please keep categorizing failures via elastic recheck as usual.
>
> thank you
>
> andrea
>
> On Fri, 3 Mar 2017, 8:02 a.m. Ghanshyam Mann, 
> wrote:
>
> Thanks. +1. i added my list in ethercalc.
>
> Left put scenario tests can be run on periodic and experimental job. IMO
> on both ( periodic and experimental) to monitor their status periodically
> as well as on particular patch if we need to.
>
> -gmann
>
> On Fri, Mar 3, 2017 at 4:28 PM, Andrea Frittoli  > wrote:
>
> Hello folks,
>
> we discussed a lot since the PTG about issues with gate stability; we need
> a stable and reliable gate to ensure smooth progress in Pike.
>
> One of the issues that stands out is that most of the times during test
> runs our test VMs are under heavy load.
> This can be the common cause behind several failures we've seen in the
> gate, so we agreed during the QA meeting yesterday [0] that we're going to
> try reducing the load and see whether that improves stability.
>
> Next steps are:
> - select a subset of scenario tests to be executed in the gate, based on
> [1], and run them serially only
> - the patch for this is [2] and we will approve this by the end of the day
> - we will monitor stability for a week - if needed we may reduce
> concurrency a bit on API tests as well, and identify "heavy" tests
> candidate for removal / refactor
> - the QA team won't approve any new test (scenario or heavy resource
> consuming api) until gate stability is ensured
>
> Thanks for your patience and collaboration!
>
> Andrea
>
> ---
> irc: andreaf
>
> [0]
> http://eavesdrop.openstack.org/meetings/qa/2017/qa.2017-03-02-17.00.txt
> [1] https://ethercalc.openstack.org/nu56u2wrfb2b
> [2] https://review.openstack.org/#/c/439698/
>
> __
> 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: 

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ihar Hrachyshka]

On Thu, Mar 16, 2017 at 12:00 PM, Doug Hellmann  wrote:
> Please keep translations for exceptions and other user-facing messages,
> for now.

To clarify, that means LOG.exception(_LE(...)) should also be cleaned
up? The only things that we should leave are messages that eventually
get to users (by means of stdout for clients, or thru API payload, for
services).

Ihar

__
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] [codesearch] how to exclude projects?

[Ihar Hrachyshka]

Thank a lot Diana, the info is exactly what I was looking for.

I proposed the patch to ignore those repos in:
https://review.openstack.org/446634

Ihar

On Wed, Mar 15, 2017 at 5:30 PM, Diana Clarke
<diana.joan.cla...@gmail.com> wrote:
> Hi Ihar:
>
> The OpenStack Hound instance [1] is passed config.json with the
> projects to index.
>
> That file is generated by jeepyb here [2] based on the projects
> defined in projects.yaml [3].
>
> Here's an example config.json [4] I manually generated a couple of
> weeks back when I was looking into why some tripleo projects weren't
> being indexed (turns out it was just stale because puppet was
> disabled).
>
> IIUC, puppet is still disabled for codesearch, so you'll need to ping
> infra once you've modified jeepyb to exclude the openstack/deb-*
> repos.
>
> pabelanger in #openstack-infra kindly did a manual puppet run for me
> when I recently wanted config.json refreshed, so he'll know what to do
> when you're ready.
>
> Finally, there's also this entry in the infra system-config docs [5]
> that points to the bug tracker etc.
>
> Hope that helps!
>
> Cheers,
>
> --diana
>
> [1] http://codesearch.openstack.org/
> [2] 
> https://github.com/openstack-infra/jeepyb/blob/master/jeepyb/cmd/create_hound_config.py
> [3] 
> https://github.com/openstack-infra/project-config/blob/master/gerrit/projects.yaml
> [4] https://gist.github.com/dianaclarke/1533448ed33232f5c1c348ab57cb884e
> [5] https://docs.openstack.org/infra/system-config/codesearch.html
>
> On Wed, Mar 15, 2017 at 5:06 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>> Hi all,
>>
>> lately I noticed that any search in codesearch triggers duplicate
>> matches because it seems code for lots of projects is stored in
>> openstack/deb- repos, probably used for debian
>> packaging. I would like to be able to exclude the projects from the
>> search by openstack/deb-* pattern. Is it possible?
>>
>> Ideally, we would exclude them by default, but I couldn't find where I
>> patch codesearch to do it. Is there a repo for the webui that I can
>> chew?
>>
>> Ihar
>>
>> __
>> 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] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

[Ihar Hrachyshka]

Any update? The issue still seems to be present.

On Mon, Nov 28, 2016 at 6:42 AM, Ilya Shakhat <ishak...@mirantis.com> wrote:
> Hi Ihar,
>
> This sounds like a bug - the contents of official group should be in sync
> with the governance repo.
> I'll take a look what went wrong with it.
>
> Thanks,
> Ilya
>
> 2016-11-26 2:28 GMT+03:00 Ihar Hrachyshka <ihrac...@redhat.com>:
>>
>> Hi all,
>>
>> I am looking at
>> http://stackalytics.com/?project_type=openstack=neutron-group and I
>> see some reviews counted for projects that are for long out of neutron
>> stadium (f.e. dragonflow or kuryr or networking-hyperv). How can we get them
>> excluded from the official neutron stats?
>>
>> I’ve briefly looked at the code, and it seems like the project should
>> reflect what’s defined in governance repo, but apparently it’s not the case.
>> So what does it reflect?
>>
>> Ihar
>> __
>> 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-dev] [codesearch] how to exclude projects?

[Ihar Hrachyshka]

Hi all,

lately I noticed that any search in codesearch triggers duplicate
matches because it seems code for lots of projects is stored in
openstack/deb- repos, probably used for debian
packaging. I would like to be able to exclude the projects from the
search by openstack/deb-* pattern. Is it possible?

Ideally, we would exclude them by default, but I couldn't find where I
patch codesearch to do it. Is there a repo for the webui that I can
chew?

Ihar

__
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][gate] functional job busted

[Ihar Hrachyshka]

That was quick folks. Thanks everyone for moving the patches forward.

Ihar

On Wed, Mar 15, 2017 at 4:32 AM, Miguel Angel Ajo Pelayo
<majop...@redhat.com> wrote:
> Thank you for the patches. I merged them, released 1.1.0 and proposed [1]
>
> Cheers!,
>
> [1] //review.openstack.org/445884
>
>
> On Wed, Mar 15, 2017 at 10:14 AM, Gorka Eguileor <gegui...@redhat.com>
> wrote:
>>
>> On 14/03, Ihar Hrachyshka wrote:
>> > Hi all,
>> >
>> > the patch that started to produce log index file for logstash [1] and
>> > the patch that switched metadata proxy to haproxy [2] landed and
>> > together busted the functional job because the latter produces log
>> > messages with null-bytes inside, while os-log-merger is not resilient
>> > against it.
>> >
>> > If functional job would be in gate and not just in check queue, that
>> > would not happen.
>> >
>> > Attempt to fix the situation in multiple ways at [3]. (For
>> > os-log-merger patches, we will need new release and then bump the
>> > version used in gate, so short term neutron patches seem more viable.)
>> >
>> > I will need support from both authors of os-log-merger as well as
>> > other neutron members to unravel that. I am going offline in a moment,
>> > and hope someone will take care of patches up for review, and land
>> > what's due.
>> >
>> > [1] https://review.openstack.org/#/c/442804/ [2]
>> > https://review.openstack.org/#/c/431691/ [3]
>> > https://review.openstack.org/#/q/topic:fix-os-log-merger-crash
>> >
>> > Thanks,
>> > Ihar
>>
>> Hi Ihar,
>>
>> That is an unexpected case that never came up during our tests or usage,
>> but it is indeed something the script should take into account.
>>
>> Thanks for the os-log-merger patches, I've reviewed them and they look
>> good to me, so hopefully they'll land before you come back online.  ;-)
>>
>> Cheers,
>> Gorka.
>
>

__
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] [neutron][gate] functional job busted

[Ihar Hrachyshka]

Hi all,

the patch that started to produce log index file for logstash [1] and
the patch that switched metadata proxy to haproxy [2] landed and
together busted the functional job because the latter produces log
messages with null-bytes inside, while os-log-merger is not resilient
against it.

If functional job would be in gate and not just in check queue, that
would not happen.

Attempt to fix the situation in multiple ways at [3]. (For
os-log-merger patches, we will need new release and then bump the
version used in gate, so short term neutron patches seem more viable.)

I will need support from both authors of os-log-merger as well as
other neutron members to unravel that. I am going offline in a moment,
and hope someone will take care of patches up for review, and land
what's due.

[1] https://review.openstack.org/#/c/442804/
[2] https://review.openstack.org/#/c/431691/
[3] https://review.openstack.org/#/q/topic:fix-os-log-merger-crash

Thanks,
Ihar

__
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][networking-l2gw] Unable to create release tag

[Ihar Hrachyshka]

On Tue, Mar 14, 2017 at 6:04 AM, Jeremy Stanley  wrote:
> The ACL for that repo doesn't seem to be configured to allow it
> (yet):
>

Probably fallout of neutron stadium exclusion. While it was in the
stadium, releases were happening thru openstack/releases machinery.

Ihar

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

[Ihar Hrachyshka]

On Tue, Feb 21, 2017 at 7:03 AM, Roua Touihri 
wrote:

> How can we interconnect two VMs without using a bridge or a switch as an
> intermediate. That is, only via a virtual link (e.g. veth or tap). In fact,
> I see that when we create an aditional subnet and two ports of the given
> subnet. Then when I attach each port to a running VM, neutron use a bridge
> as an intermediate element. I want to create a mesh topology between
> several VMs of the same tenant in addition to or without the default
> network created by neutron.
>
>
If you don't care about neutron network at all and want different topology,
then maybe neutron is not the project that should solve the issue for you.

But what is exactly the use case for that topology in your environment?

Ihar
__
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] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Ihar Hrachyshka]

On Fri, Mar 10, 2017 at 6:49 AM, Andrea Frittoli
 wrote:
> - Glance v1 has been deprecated in Newton, so it's deprecated in all
> supported releases

Glance not maintaining Mitaka branch?

Ihar

__
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] upgrades PTG recap

[Ihar Hrachyshka]

On Mon, Mar 6, 2017 at 10:50 AM, Morales, Victor
 wrote:
> Regarding this testing, is there a place where it was documented, scripted or 
> shared? Something that helps to someone else can take a look.  And in the 
> other hand,  is there a way to simulate a “fake change” for similar releases 
> where didn’t add significant features but we still need to guarantees its 
> functionality.

I don't think Artur shared any write-up. It would be nice to have one
for later reference. Artur, what d'you think?

As for 'fake' change, I am not sure I follow what you mean. If/when we
have gate job covering the scenario, it will be validated on each
patch.

Ihar

__
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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ihar Hrachyshka]

I have a question: why can't operators just switch to en_US to execute services?

Another question: what makes log messages so much different from API
responses? Couldn't you make the same argument that it's easier to
find a reason for a request failure if the error message is in
English? Should we then just stop translating any messages and say
English is the only OpenStack language we recommend?

I try to see what makes logs so much different from API error
messages, and why operators cannot pick the right language based on
their priorities.

On Mon, Mar 6, 2017 at 8:28 AM, Ian Y. Choi  wrote:
> Doug Hellmann wrote on 3/7/2017 12:53 AM:
>>
>> Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:
>>>
>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

 On 2017-03-06 14:03, Sean Dague  wrote:
>
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
>
> ">> Yes, we decided some time ago to not translate the log files
> anymore and
>>>
>>> thus our tools do not handle them anymore - and in general, we remove
>>> these kind of files."
>
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
>
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.

 Sean, this was removed as followup to:


 http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

 Let me copy Ian as i18n PTL,

 Andreas
>>>
>>> That all seems reasonable, and I'm happy to follow the i18n team's lead
>>> here. It is however a significant reversal of policy, and there is
>>> substantial code infrastructure in projects (like Nova) to support the
>>> old policy.
>>>
>>> So if this is new policy, a much wider dissemination of it would be
>>> welcomed, as it means we can purge this infrastructure from projects
>>> like Nova.
>>>
>>>  -Sean
>>>
>> Yes, we went to a great deal of trouble to enable log translations,
>> so I'm surprised to see it being dropped to quickly.  I don't
>> necessarily disagree with the decision, because I know translator
>> time is limited. But it would be nice to have the discussion here,
>
>
> +1 and for such discussions including openstack-i...@lists.openstack.org
> mailing list would be also nice :)
>
> On Barcelona Design Summit, there were I18n contributor meetup and I18n team
> members discussed a lot.
> One of things was not to translate log-level strings for server projects.
>
> Note that such decision was made not because translator time is limited.
>
> Log messages are important to better identify which errors are being posed
> and most operators (+ developers)
> diagnose and start to solve error situations from the log messages.
> I18n team previously translated log messages a lot especially thanks to
> translation contribution from IBM. (AFAIK)
> However, after then, there have been some voices - why I18n team translated
> log messages?
> After listening to the voices in details, I18n team identified that the
> background of such voices was related with searching log messages on
> Internet.
> Searching English log messages on the Internet will retrieve more number of
> results than searching translated log messages on the Internet.
>
> Translating log messages now has two different point of views:
>  - Will be useful for OpenStack users to better understand log messages in
> details with translated log messages?
>  - Or will not be useful for OpenStack users because the original log
> messages will have better chance to find solutions who occurred the similar
> cases on the Internet?
>
> I18n team discussed with such point of views and on Barcelona Summit the
> latter point would be more important than the former point.
> Also, it would be just a point of view from PTL, but it is difficult for me
> to encourage to contribution translations which have such kind of
> controversy.
>
> Now I would like to listen again to not only developers, but also operators
> and translators - for log string translation.
> If someone thinks that the former point would be more important than the
> latter point, please share through this mailing list to reconsider the
> current decision.
>
>
> With many thanks,
>
> /Ian
>
>
>> instead of on a list most of the community isn't subscribed to, so
>> everyone involved can understand the reason for the change and so
>> the folks who asked for it originally can be included in the
>> conversation. As Sean points out, the policy change has a lot of
>> other implications about how logging is handled throughout the
>> applications.
>>
>> Doug
>>
>> 

[openstack-dev] [neutron] upgrades PTG recap

[Ihar Hrachyshka]

Hi all,

This is a report on upgrades related topics discussed during PTG in
Atlanta. A general PTG report from PTL can be found at:

http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html

Topics discussed:
1. OVO progress;
2. running mixed server versions;
3. online data migration framework;
4. impact of new features (multiple port bindings) for mixed
server execution, and how to deal with it;
5. gate.

=> OVO progress
The effort is a bit stalled but slowly progressing. Progress is
sometimes blocked by external ongoing initiatives: new oslo.db
enginefacade; other code refactoring. Sometimes we need to back off
and fix plugin database logic before switching to objects (think of
lock_for_update removal in all places in current code). The initiative
is critical only as long as there are other initiatives that would
benefit from it. At this point, we are mainly looking at multiple port
bindings feature and its potential impact on our ability to run mixed
server versions at the same time. Other objects are worth an effort
but are not critical. There may be other objects during the cycle that
may be determined critical for rolling upgrades support.

Specifically talking about lock_for_update support in objects layer:
https://review.openstack.org/#/c/435598/ , Kevin is hesitant to add
it. Instead we are going to clean up remaining code that uses the
locking feature, like in https://review.openstack.org/#/c/438144/ . We
need the same approach applied for quotas.

=> Running mixed server versions
Initial testing done by Artur showed that it's now possible to execute
Newton and Ocata server versions in the same environment with some
success. This is partly the result of OVO work, but also the fact that
Ocata cycle was short and not rich on new features. We should build on
top of that to deliver the same for Pike. We should give special
attention to initiatives that may disrupt the work (multiple port
bindings and others).

=> Online data migration framework
We discussed that in general there are 3 steps needed for online
migration 1) Declaration of the intent and creating a general
framework for online migration, 2) CLI for online migration (example
patch https://review.openstack.org/#/c/432494/) and, 3) The changes
made in the object layer for online data migration needs to be
backward compatible. We sat down and looked at specific contract
migrations from the past as a matter of case study excercise. During
our discussion we found out that all the migrations might not be
addressed by the general framework and will require case-by-case code
to implement the needed transition. Actually, intent for most
non-obvious contractions would be hard to express in a general way.

=> Impact of multiple port bindings
Discussions suggest that the feature may be of high impact for our
ability to deliver mixed server versions for Ocata->Pike upgrade. This
is not because of database access not being properly aligned for the
newly expected feature. Instead, we may hit issues because of the
nature of the extension usage, that is usually consumed by compute
component. Once nova switches to using the new extension to drive port
bindings if the extension is present, and if neutron replies to nova
that it indeed supports the new extension before all neutron-servers
are upgraded to Pike, then it may turn out that some data stored in
the database may not be easily implemented/acted on by older
neutron-servers.

Ideally, we would instead block any new API requests till the moment
when all neutron-servers are running the new code, at which point they
could start advertising the fact on /extensions/ endpoint. That would
imply that neutron-servers become aware of each other, and extensions
each of them support and expose. In that case, they could negotiate to
use the common subset of extensions, and avoid exposing any extensions
that are not implemented by any other neutron-server. In that case,
newer servers would still behave as if they don't support new API
features. Then once the upgrade to the new release is complete,
neutron-servers could detect the end of upgrade phase (either through
some external event, like admin initiated signals; or by periodic
inspection of the server db table) and reload extensions to enable new
API. I am going to report the proposal as RFE and write it up in form
of a spec where we will be able to discuss it in more details.

Since multiple port bindings work is scheduled to land this cycle, we
should work on that proposal in Pike too.

=> Gating
It's still not clear what to do with mixed server version gating, and
apparently we will need to sync again with folks driving it for nova
gate. In the meantime, we may want to continue periodic local
validations of mixed setup to assure nothing is borked.

As for grenade multinode linuxbridge job, there is lack of clear
interest in the subgroup, so I asked Kevin if he is interested in
making it working. Kevin said he will 

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

[Ihar Hrachyshka]

With https://review.openstack.org/#/c/437699/ in, stadium projects
will no longer have any other option but to follow the common
schedule. That change is new for Pike+ so we may still see some issues
with Ocata release process.

Ihar

On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang  wrote:
> Add [release] tag in subject.
>
> Do not follow the OpenStack release schedule will cause lots of issues. Like
> requirements changes, patches is merged which should not be merged into
> stable.
>
> It also may break the deploy project release schedule( like Kolla will not
> be
> released until sfc release ocata branch and tag ).
>
> I hope sfc team could follow the OpenStack release schedule, even though it
> may
> cause some cherry-pick, but it is safer and how OpenStack project live.
>
>
> On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton  wrote:
>>
>> Please note that things are going to start to get messy now – there are
>> changes in neutron that break master and these will affect the cutting of
>> the stable version. One example is https://review.openstack.org/441654
>>
>>
>>
>> So I suggest cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton 
>> Reply-To: OpenStack List 
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> Thanks!
>>
>>
>>
>> From: Jeffrey Zhang 
>> Reply-To: OpenStack List 
>> Date: Sunday, March 5, 2017 at 9:12 AM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> This is talked in [0]. sfc team said
>>
>>
>>
>> > we will pull a stable/ocata branch around end of Feb or early March the
>> > latest.
>>
>>
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html
>>
>>
>>
>> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton  wrote:
>>
>> Hi,
>>
>> We are pretty blocked at the moment with our gating on stable/ocata. This
>> is due to the fact that there is no networking-sfc version tagged for ocata.
>>
>> Is there any ETA for this?
>>
>> Thanks
>>
>> Gary
>>
>>
>>
>>
>> __
>> 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
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Jeffrey Zhang
>>
>> Blog: http://xcodest.me
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [requirements][neutron] bot bumping patches off gate queue

[Ihar Hrachyshka]

Any updates on the problem? It still bumps patches off gate queue,
resetting it and backing off progress for the whole integrated gate.
Is the work followed up somewhere? Any patches to chew?

Ihar

On Wed, Feb 1, 2017 at 5:14 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Wed, Feb 01, 2017 at 07:49:21AM -0800, Ihar Hrachyshka wrote:
>> On Wed, Feb 1, 2017 at 7:42 AM, Armando M. <arma...@gmail.com> wrote:
>> >
>> >
>> > On 1 February 2017 at 07:29, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> lately I see the requirements bot proposing new rebases for its
>> >> patches (and bumping existing patch sets from the gate queue) every
>> >> second hour, at least for Neutron [1], which makes it impossible to
>> >> land the patches, and which only makes gate pre-release situation
>> >> worse. On top of that, the proposed rebases don't really add anything
>> >> material to the sync patch, no new version changes and such.
>> >>
>> >> I think we had some guards against such behavior before, so I wonder
>> >> if they were broken or removed lately? Any plans to fix that?
>> >>
>> >> It would be nice to be able to land the update before RC1 is cut off,
>> >> but at this point, it does not seem realistic.
>> >>
>> >> [1] https://review.openstack.org/#/c/423645/
>> >>
>> >
>> > Let's stop merging until the bot proposal change lands. That ought to stop
>> > the spurious rebase!
>> >
>> > Hard times require hard measures!!
>>
>> That's assuming it's triggered by neutron merges. It may as well be
>> requirements merges that trigger rebases. Something that I believe
>> requirements team will help us to understand.
>
> So it's a combination of both.  The bot runs are triggered on merges to
> openstack/requirements but the rebases are (clearly) due to the fact that
> neutron has advanced in the mean time.
>
> We knew this was a suboptimal part of the process but until your thread we
> assumed it was wasting CPU/gate resources.  You've exposed the developer
> cost and that elevates this in priority.
>
> We processes a few requirements feature freeze excetpions which is what caused
> the issue you highlight in that review.  I'll see what I can do about finding
> someone to fix this before we release Ocata.
>
> The "fix" will be to check if the bot run is a rebase *and* if the current
> revision of the change is lacking a vote from jenkins.  Hmmm I guess we should
> *also* check if the version in gerrit has +W and avoid the upload in that case
> also.
>
>
> Yours Tony.
>
>
> __
> 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] [ironic] state of the stable/mitaka branches

[Ihar Hrachyshka]

On Thu, Mar 2, 2017 at 8:13 AM, Pavlo Shchelokovskyy
 wrote:
> I'm also kind of wondering what the grenade job in stable/newton will test
> after mitaka EOL? upgrade from mitaka-eol tag to stable/newton branch? Then
> even that might be affected if devstack-gate + project config will not be
> able to set *_ssh in enabled drivers while grenade will try to use them.

When a branch is EOLed, grenade jobs using it for old side of the
cloud are deprovisioned.

Ihar

__
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] [ironic] state of the stable/mitaka branches

[Ihar Hrachyshka]

Agreed. All I am saying is that as long as there was no change in the
policy, projects are expected to keep up.

I see that upper-constraints.txt mentioned in the email several times.
I believe it's the least that the project could do to fix the branch,
and lack of the fix doesn't seem like a good enough reason to drop the
ball in the middle (for the project as a whole, not for any specific
contributor). Other projects spent some time upfront and adopted
constraints quite a while ago. I am surprised that there are still
stable branches that don't do that. It's so much easier to maintain
them with constraints in place!

Ihar

On Wed, Mar 1, 2017 at 12:34 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2017-03-01 11:36:47 -0800 (-0800), Ihar Hrachyshka wrote:
>> On Wed, Mar 1, 2017 at 11:15 AM, Pavlo Shchelokovskyy
>> <pshchelokovs...@mirantis.com> wrote:
>> > With all the above, the question is should we really fix the gates for the
>> > mitaka branch now? According to OpenStack release page [1] the Mitaka
>> > release will reach end-of-life on April 10, 2017.
>>
>> Yes we should. It's part of the contract with consumers that rely on
>> follows:stable-policy tag owned by Ironic and other projects.
>
> It's a two-way street though. As a community we agreed to extend
> stable support timelines on the promise that the people consuming
> those would step up to keep them testable. If key projects are
> having trouble testing stable/mitaka now and the people relying on
> that aren't helping fix the situation, then it's time to again
> reevaluate our earlier choices for support duration.
> --
> Jeremy Stanley
>
> __
> 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] [ironic] state of the stable/mitaka branches

[Ihar Hrachyshka]

On Wed, Mar 1, 2017 at 11:15 AM, Pavlo Shchelokovskyy
 wrote:
> With all the above, the question is should we really fix the gates for the
> mitaka branch now? According to OpenStack release page [1] the Mitaka
> release will reach end-of-life on April 10, 2017.

Yes we should. It's part of the contract with consumers that rely on
follows:stable-policy tag owned by Ironic and other projects.

Ihar

__
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] [neutron] no upgrades meeting today

[Ihar Hrachyshka]

Hi,

Sorry for short notice but I figured some of us just met on PTG and where
still traveling back in last several days and would appreciate getting the
hour back to settle pending post PTG items.

This week I will work with PTG participants on producing a detailed report
on the event where it touched our topic. We will share the report with the
team in due course.

We will have the next meeting in a week.

Thanks
Ihar
__
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] - approximate schedule for PTG

[Ihar Hrachyshka]

Thanks a lot for the ical, it's really helpful, adding some structure
to the PTG anarchy.

Ihar

On Sat, Feb 18, 2017 at 12:42 PM, Kevin Benton  wrote:
> Hi All,
>
>
> Here is a rough outline of the order in which I want to cover the items:
> https://etherpad.openstack.org/p/neutron-ptg-pike-final
>
>
> I've also put together a calendar that has the meeting times as well as a
> few relevant cross project sessions and our team dinner/photo.
>
> I suggest watching the calendar for changes since we will need to make
> adjustments as we go.
>
> ICAL:
> https://calendar.google.com/calendar/ical/khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com/public/basic.ics
>
> HTML page:
> https://calendar.google.com/calendar/embed?src=khbmhi1mhtthrmgv2gnejtul3o%40group.calendar.google.com=America/New_York
>
>
> If you notice any conflicts or missing items, reply right away so I can get
> it fixed.
>
> Cheers,
> 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
>

__
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] - Neutron team social in Atlanta on Thursday

[Ihar Hrachyshka]

+1.

On Fri, Feb 17, 2017 at 11:18 AM, Kevin Benton  wrote:
> Hi all,
>
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
>
> Cheers,
> 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
>

__
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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

Another potentially interesting devstack service that may help us to
understand our memory usage is peakmem_tracker. At this point, it's
not enabled anywhere. I proposed devstack-gate patch to enable it at:
https://review.openstack.org/#/c/434511/

On Wed, Feb 15, 2017 at 12:38 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Another potentially relevant info is, we saw before that oom-killer is
> triggered while 8gb of swap are barely used. This behavior is hard to
> explain, since we set kernel swappiness sysctl knob to 30:
>
> https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L432
>
> (and any value above 0 means that if memory is requested, and there is
> swap available to fulfill it, it will not fail to allocate memory;
> swappiness only controls willingness of kernel to swap process pages
> instead of dropping disk cache entries, it may affect performance, but
> it should not affect malloc behavior).
>
> The only reason I can think of for a memory allocation request to
> trigger the trap when swap is free is when the memory request is for a
> RAM-locked page (it can either be memory locked with mlock(2), or
> mmap(2) when MAP_LOCKED used). To understand if that's the case in
> gate, I am adding a new mlock_tracker service to devstack:
> https://review.openstack.org/#/c/434470/
>
> The patch that enables the service in Pike+ gate is:
> https://review.openstack.org/#/c/434474/
>
> Thanks,
> Ihar
>
> On Wed, Feb 15, 2017 at 5:21 AM, Andrea Frittoli
> <andrea.fritt...@gmail.com> wrote:
>> Some (new?) data on the oom kill issue in the gate.
>>
>> I filed a new bug / E-R query yet for the issue [1][2] since it looks to me
>> like the issue is not specific to mysqld - oom-kill will just pick the best
>> candidate, which in most cases happens to be mysqld. The next most likely
>> candidate to show errors in the logs is keystone, since token requests are
>> rather frequent, more than any other API call probably.
>>
>> According to logstash [3] all failures identified by [2] happen on RAX nodes
>> [3], which I hadn't realised before.
>>
>> Comparing dstat data between the failed run and a successful on an OVH node
>> [4], the main difference I can spot is free memory.
>> For the same test job, the free memory tends to be much lower, quite close
>> to zero for the majority of the time on the RAX node. My guess is that an
>> unlucky scheduling of tests may cause a slightly higher peak in memory usage
>> and trigger the oom-kill.
>>
>> I find it hard to relate lower free memory to a specific cloud provider /
>> underlying virtualisation technology, but maybe someone has an idea about
>> how that could be?
>>
>> Andrea
>>
>> [0]
>> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/6f31320/logs/syslog.txt.gz#_Feb_14_00_32_28
>> [1] https://bugs.launchpad.net/tempest/+bug/1664953
>> [2] https://review.openstack.org/434238
>> [3]
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Out%20of%20memory%3A%20Kill%20process%5C%22%20AND%20tags%3A%5C%22syslog.txt%5C%22
>> [4]
>> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/1dfb4b7/logs/dstat-csv_log.txt.gz
>>
>> On Mon, Feb 6, 2017 at 10:13 AM Miguel Angel Ajo Pelayo
>> <majop...@redhat.com> wrote:
>>>
>>> Jeremy Stanley wrote:
>>>
>>>
>>> > It's an option of last resort, I think. The next consistent flavor
>>> > up in most of the providers donating resources is double the one
>>> > we're using (which is a fairly typical pattern in public clouds). As
>>> > aggregate memory constraints are our primary quota limit, this would
>>> > effectively halve our current job capacity.
>>>
>>> Properly coordinated with all the cloud the providers, they could create
>>> flavours which are private but available to our tenants, where a 25-50% more
>>> RAM would be just enough.
>>>
>>> I agree that should probably be a last resort tool, and we should keep
>>> looking for proper ways to find where we consume unnecessary RAM and make
>>> sure that's properly freed up.
>>>
>>> It could be interesting to coordinate such flavour creation in the mean
>>> time, even if we don't use it now, we could eventually test it or put it to
>>> work if we find trapped anytime later.
>>>
>>>
>>> On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann <mriede...@gmail.com>
>>> wrote:
>>>>
>>>> On 2/5/2017 1:

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

Another potentially relevant info is, we saw before that oom-killer is
triggered while 8gb of swap are barely used. This behavior is hard to
explain, since we set kernel swappiness sysctl knob to 30:

https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L432

(and any value above 0 means that if memory is requested, and there is
swap available to fulfill it, it will not fail to allocate memory;
swappiness only controls willingness of kernel to swap process pages
instead of dropping disk cache entries, it may affect performance, but
it should not affect malloc behavior).

The only reason I can think of for a memory allocation request to
trigger the trap when swap is free is when the memory request is for a
RAM-locked page (it can either be memory locked with mlock(2), or
mmap(2) when MAP_LOCKED used). To understand if that's the case in
gate, I am adding a new mlock_tracker service to devstack:
https://review.openstack.org/#/c/434470/

The patch that enables the service in Pike+ gate is:
https://review.openstack.org/#/c/434474/

Thanks,
Ihar

On Wed, Feb 15, 2017 at 5:21 AM, Andrea Frittoli
 wrote:
> Some (new?) data on the oom kill issue in the gate.
>
> I filed a new bug / E-R query yet for the issue [1][2] since it looks to me
> like the issue is not specific to mysqld - oom-kill will just pick the best
> candidate, which in most cases happens to be mysqld. The next most likely
> candidate to show errors in the logs is keystone, since token requests are
> rather frequent, more than any other API call probably.
>
> According to logstash [3] all failures identified by [2] happen on RAX nodes
> [3], which I hadn't realised before.
>
> Comparing dstat data between the failed run and a successful on an OVH node
> [4], the main difference I can spot is free memory.
> For the same test job, the free memory tends to be much lower, quite close
> to zero for the majority of the time on the RAX node. My guess is that an
> unlucky scheduling of tests may cause a slightly higher peak in memory usage
> and trigger the oom-kill.
>
> I find it hard to relate lower free memory to a specific cloud provider /
> underlying virtualisation technology, but maybe someone has an idea about
> how that could be?
>
> Andrea
>
> [0]
> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/6f31320/logs/syslog.txt.gz#_Feb_14_00_32_28
> [1] https://bugs.launchpad.net/tempest/+bug/1664953
> [2] https://review.openstack.org/434238
> [3]
> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Out%20of%20memory%3A%20Kill%20process%5C%22%20AND%20tags%3A%5C%22syslog.txt%5C%22
> [4]
> http://logs.openstack.org/93/432793/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/1dfb4b7/logs/dstat-csv_log.txt.gz
>
> On Mon, Feb 6, 2017 at 10:13 AM Miguel Angel Ajo Pelayo
>  wrote:
>>
>> Jeremy Stanley wrote:
>>
>>
>> > It's an option of last resort, I think. The next consistent flavor
>> > up in most of the providers donating resources is double the one
>> > we're using (which is a fairly typical pattern in public clouds). As
>> > aggregate memory constraints are our primary quota limit, this would
>> > effectively halve our current job capacity.
>>
>> Properly coordinated with all the cloud the providers, they could create
>> flavours which are private but available to our tenants, where a 25-50% more
>> RAM would be just enough.
>>
>> I agree that should probably be a last resort tool, and we should keep
>> looking for proper ways to find where we consume unnecessary RAM and make
>> sure that's properly freed up.
>>
>> It could be interesting to coordinate such flavour creation in the mean
>> time, even if we don't use it now, we could eventually test it or put it to
>> work if we find trapped anytime later.
>>
>>
>> On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann 
>> wrote:
>>>
>>> On 2/5/2017 1:19 PM, Clint Byrum wrote:


 Also I wonder if there's ever been any serious consideration given to
 switching to protobuf? Feels like one could make oslo.versionedobjects
 a wrapper around protobuf relatively easily, but perhaps that's already
 been explored in a forum that I wasn't paying attention to.
>>>
>>>
>>> I've never heard of anyone attempting that.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> 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
>> 

Re: [openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

[Ihar Hrachyshka]

On Fri, Feb 10, 2017 at 2:48 PM, Clark Boylan <cboy...@sapwetik.org> wrote:
> On Fri, Feb 10, 2017, at 10:54 AM, Ihar Hrachyshka wrote:
>> Oh nice, I haven't seen that. It does give (virtualized) CPU model
>> types. I don't see a clear correlation between models and
>> failures/test times though. We of course miss some more details, like
>> flags being emulated, but I doubt it will give us a clue.
>
> Yes, this will still be the virtualized CPU. Also the lack of cpu flag
> info is a regression compared to the old method of collecting this data.
> If we think that info could be useful somehow we should find a way to
> add it back in. (Maybe just add back the cat /proc/cpuinfo step in
> devstack-gate).

To update, I posted a patch that logs /proc/cpuinfo using new ansible
data gathering playbook: https://review.openstack.org/#/c/433949/

>
>> It would be interesting to know the overcommit/system load for each
>> hypervisor affected. But I assume we don't have access to that info,
>> right?
>
> Correct, with the exception of infracloud and OSIC (if we ask nicely) I
> don't expect it will be very easy to get this sort of information from
> our clouds.
>
> For infracloud a random sample of a hypervisor shows that it has 24 real
> cores. In the vanilla region we are limited to 126 VM  instances with
> 8vcpu each. We have ~41 hypervisors which is just over 3 VM instances
> per hypervisor. 24realcpus/8vcpu = 3 VM instances without
> oversubscribing. So we are just barely oversubscribing if at all.

Ack, thanks for checking, we will need to find some other hypothesis then.

For the record, we discussed with Clark an idea of adding a synthetic
benchmark at the start of every job (before our software is actually
installed on the node), to get some easily comparable performance
numbers between runs that are guaranteed to be unaffected by OpenStack
installation; but Clark had his reservation because the test would be
synthetic and hence not real life, and because we already have
./stack.sh run time that can be used as a silly benchmark. Of course,
./stack.sh depends on lots of externalities, so it's not as precise as
a targeted benchmark would be, but Clark feels the latter would be of
limited use.

Apart from that, it's not clear where to go next. I doubt cpuinfo dump
will reveal anything insane in failing jobs, so other ideas are
welcome.

Ihar

__
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] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

[Ihar Hrachyshka]

Oh nice, I haven't seen that. It does give (virtualized) CPU model
types. I don't see a clear correlation between models and
failures/test times though. We of course miss some more details, like
flags being emulated, but I doubt it will give us a clue.

It would be interesting to know the overcommit/system load for each
hypervisor affected. But I assume we don't have access to that info,
right?

Ihar

On Fri, Feb 10, 2017 at 8:39 AM, Clark Boylan <cboy...@sapwetik.org> wrote:
> On Fri, Feb 10, 2017, at 08:21 AM, Morales, Victor wrote:
>>
>> On 2/9/17, 10:59 PM, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote:
>>
>> >Hi all,
>> >
>> >I noticed lately a number of job failures in neutron gate that all
>> >result in job timeouts. I describe
>> >gate-tempest-dsvm-neutron-dvr-ubuntu-xenial job below, though I see
>> >timeouts happening in other jobs too.
>> >
>> >The failure mode is all operations, ./stack.sh and each tempest test
>> >take significantly more time (like 50% to 150% more, which results in
>> >job timeout triggered). An example of what I mean can be found in [1].
>> >
>> >A good run usually takes ~20 minutes to stack up devstack; then ~40
>> >minutes to pass full suite; a bad run usually takes ~30 minutes for
>> >./stack.sh; and then 1:20h+ until it is killed due to timeout.
>> >
>> >It affects different clouds (we see rax, internap, infracloud-vanilla,
>> >ovh jobs affected; we haven't seen osic though). It can't be e.g. slow
>> >pypi or apt mirrors because then we would see slowdown in ./stack.sh
>> >phase only.
>> >
>> >We can't be sure that CPUs are the same, and devstack does not seem to
>> >dump /proc/cpuinfo anywhere (in the end, it's all virtual, so not sure
>>
>> I don’t think that logging this information could be useful mainly
>> because this depends on enabling *host-passthrough*[3] in nova-compute
>> configuration of Public cloud providers
>
> While this is true we do log it anyways (was useful for sorting out live
> migration cpu flag inconsistencies). For example:
> http://logs.openstack.org/95/429095/2/check/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/35aa22f/logs/devstack-gate-setup-host.txt.gz
> and grep for 'cpu'.
>
> Note that we used to grab proper /proc/cpuinfo contents but now its just
> whatever ansible is reporting back in its fact list there.
>
> Clark
>
> __
> 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-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

[Ihar Hrachyshka]

Hi all,

I noticed lately a number of job failures in neutron gate that all
result in job timeouts. I describe
gate-tempest-dsvm-neutron-dvr-ubuntu-xenial job below, though I see
timeouts happening in other jobs too.

The failure mode is all operations, ./stack.sh and each tempest test
take significantly more time (like 50% to 150% more, which results in
job timeout triggered). An example of what I mean can be found in [1].

A good run usually takes ~20 minutes to stack up devstack; then ~40
minutes to pass full suite; a bad run usually takes ~30 minutes for
./stack.sh; and then 1:20h+ until it is killed due to timeout.

It affects different clouds (we see rax, internap, infracloud-vanilla,
ovh jobs affected; we haven't seen osic though). It can't be e.g. slow
pypi or apt mirrors because then we would see slowdown in ./stack.sh
phase only.

We can't be sure that CPUs are the same, and devstack does not seem to
dump /proc/cpuinfo anywhere (in the end, it's all virtual, so not sure
if it would help anyway). Neither we have a way to learn whether
slowliness could be a result of adherence to RFC1149. ;)

We discussed the matter in neutron channel [2] though couldn't figure
out the culprit, or where to go next. At this point we assume it's not
neutron's fault, and we hope others (infra?) may have suggestions on
where to look.

[1] 
http://logs.openstack.org/95/429095/2/check/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/35aa22f/console.html#_2017-02-09_04_47_12_874550
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2017-02-10.log.html#t2017-02-10T04:06:01

Thanks,
Ihar

__
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-Infra] [all][stable][ptls] Tagging liberty as EOL

[Ihar Hrachyshka]

Has the liberty-eol cleanup happened? Because I still see
stable/liberty branch in openstack/neutron repo, which gets in the way
of some logic around proactive backports:
https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and
I see backports proposed for the branch that is no longer supported
and has broken gate setup.

Please advise,
Ihar

On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
 wrote:
> The repos listed[0] have had stable/liberty branch removed and replaced with
> a liberty-eol tag. Any open reviews have been abandoned.
>
> Please let me know if there are any mistakes or latecomers to the list.
>
> Cheers,
> Josh
>
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
> wrote:
>>
>> Hey Tony and all,
>>
>> I'm happy to take care of these retirements. However I probably can't get
>> to it until Tuesday next week. So assuming no other infra root beats me to
>> it I'll look at it then.
>>
>> Cheers,
>> Josh
>>
>> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>>
>>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>>> > and Dec
>>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>>> > zuul/layout.yaml
>>> > to remove liberty exclusions and jobs.
>>>
>>> This took longer as there are a few repos that are scheduled for EOL that
>>> were a
>>> little problematic during the kilo cycle.  I've updated the list at [1]
>>>
>>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>>> that
>>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>>> later.
>>>
>>> eol_branch.sh needs just the repo names what can be generated with
>>> something like:
>>>
>>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>>
>>> The data format is a balance between human and machine readable.
>>>
>>> Yours Tony.
>>>
>>> [1]
>>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt
>>> [2]
>>> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> openstack-in...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
>
> __
> 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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

On Thu, Feb 2, 2017 at 7:44 AM, Matthew Treinish  wrote:
> Yeah, I'm curious about this too, there seems to be a big jump in Newton for
> most of the project. It might not a be a single common cause between them, but
> I'd be curious to know what's going on there.

Both Matt from Nova as well as me and Armando suspect
oslo.versionedobjects. Pattern of memory consumption raise somewhat
correlates with the level of adoption for the library, at least in
Neutron. That being said, we don't have any numbers, so at this point
it's just pointing fingers into Oslo direction. :) Armando is going to
collect actual memory profile.

Ihar

__
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] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

[Ihar Hrachyshka]

The BadStatusLine error is well known:
https://bugs.launchpad.net/nova/+bug/1630664

Now, it doesn't mean that the root cause of the error message is the
same, and it may as well be that lowering the number of workers
triggered it. All I am saying is we saw that error in the past.

Ihar

On Thu, Feb 2, 2017 at 1:07 PM, Kevin Benton  wrote:
> This error seems to be new in the ocata cycle. It's either related to a
> dependency change or the fact that we put Apache in between the services
> now. Handling more concurrent requests than workers wasn't an issue before.
>
> It seems that you are suggesting that eventlet can't handle concurrent
> connections, which is the entire purpose of the library, no?
>
> On Feb 2, 2017 13:53, "Sean Dague"  wrote:
>>
>> On 02/02/2017 03:32 PM, Armando M. wrote:
>> >
>> >
>> > On 2 February 2017 at 12:19, Sean Dague > > > wrote:
>> >
>> > On 02/02/2017 02:28 PM, Armando M. wrote:
>> > >
>> > >
>> > > On 2 February 2017 at 10:08, Sean Dague > > 
>> > > >> wrote:
>> > >
>> > > On 02/02/2017 12:49 PM, Armando M. wrote:
>> > > >
>> > > >
>> > > > On 2 February 2017 at 08:40, Sean Dague > >  > > >
>> > > > 
>> > > > > >
>> > > > On 02/02/2017 11:16 AM, Matthew Treinish wrote:
>> > > > 
>> > > > > 
>> > > > >
>> > > > > We definitely aren't saying running a single worker is
>> > how
>> > > we recommend people
>> > > > > run OpenStack by doing this. But it just adds on to
>> > the
>> > > differences between the
>> > > > > gate and what we expect things actually look like.
>> > > >
>> > > > I'm all for actually getting to the bottom of this, but
>> > > honestly real
>> > > > memory profiling is needed here. The growth across
>> > projects
>> > > probably
>> > > > means that some common libraries are some part of this.
>> > The
>> > > ever growing
>> > > > requirements list is demonstrative of that. Code reuse
>> > is
>> > > good, but if
>> > > > we are importing much of a library to get access to a
>> > couple of
>> > > > functions, we're going to take a bunch of memory weight
>> > on that
>> > > > (especially if that library has friendly auto imports in
>> > top level
>> > > > __init__.py so we can't get only the parts we want).
>> > > >
>> > > > Changing the worker count is just shuffling around deck
>> > chairs.
>> > > >
>> > > > I'm not familiar enough with memory profiling tools in
>> > python
>> > > to know
>> > > > the right approach we should take there to get this down
>> > to
>> > > individual
>> > > > libraries / objects that are containing all our memory.
>> > Anyone
>> > > more
>> > > > skilled here able to help lead the way?
>> > > >
>> > > >
>> > > > From what I hear, the overall consensus on this matter is to
>> > determine
>> > > > what actually caused the memory consumption bump and how to
>> > > address it,
>> > > > but that's more of a medium to long term action. In fact, to
>> > me
>> > > this is
>> > > > one of the top priority matters we should talk about at the
>> > > imminent PTG.
>> > > >
>> > > > For the time being, and to provide relief to the gate,
>> > should we
>> > > want to
>> > > > lock the API_WORKERS to 1? I'll post something for review
>> > and see how
>> > > > many people shoot it down :)
>> > >
>> > > I don't think we want to do that. It's going to force down the
>> > eventlet
>> > > API workers to being a single process, and it's not super
>> > clear that
>> > > eventlet handles backups on the inbound socket well. I
>> > honestly would
>> > > expect that creates different hard to debug issues, especially
>> > with high
>> > > chatter rates between services.
>> > >
>> > >
>> > > I must admit I share your fear, but out of the tests that I have
>> > > executed so far in [1,2,3], the house didn't burn in a fire. I am
>> > > looking for other ways to have a substantial memory saving with a
>> > > relatively quick and dirty fix, but coming up empty handed thus
>> > far.
>> > >
>> > > [1] https://review.openstack.org/#/c/428303/
>> >   

Re: [openstack-dev] [requirements][neutron] bot bumping patches off gate queue

[Ihar Hrachyshka]

On Wed, Feb 1, 2017 at 7:42 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 1 February 2017 at 07:29, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>> Hi all,
>>
>> lately I see the requirements bot proposing new rebases for its
>> patches (and bumping existing patch sets from the gate queue) every
>> second hour, at least for Neutron [1], which makes it impossible to
>> land the patches, and which only makes gate pre-release situation
>> worse. On top of that, the proposed rebases don't really add anything
>> material to the sync patch, no new version changes and such.
>>
>> I think we had some guards against such behavior before, so I wonder
>> if they were broken or removed lately? Any plans to fix that?
>>
>> It would be nice to be able to land the update before RC1 is cut off,
>> but at this point, it does not seem realistic.
>>
>> [1] https://review.openstack.org/#/c/423645/
>>
>
> Let's stop merging until the bot proposal change lands. That ought to stop
> the spurious rebase!
>
> Hard times require hard measures!!

That's assuming it's triggered by neutron merges. It may as well be
requirements merges that trigger rebases. Something that I believe
requirements team will help us to understand.

Ihar

__
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] [requirements][neutron] bot bumping patches off gate queue

[Ihar Hrachyshka]

Hi all,

lately I see the requirements bot proposing new rebases for its
patches (and bumping existing patch sets from the gate queue) every
second hour, at least for Neutron [1], which makes it impossible to
land the patches, and which only makes gate pre-release situation
worse. On top of that, the proposed rebases don't really add anything
material to the sync patch, no new version changes and such.

I think we had some guards against such behavior before, so I wonder
if they were broken or removed lately? Any plans to fix that?

It would be nice to be able to land the update before RC1 is cut off,
but at this point, it does not seem realistic.

[1] https://review.openstack.org/#/c/423645/

Thanks for help,
Ihar

__
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] [elastic-recheck] Miscellaneous questions of potential Neutron interest

[Ihar Hrachyshka]

Hi all,

we were looking at expanding usage of elastic-recheck in Neutron, and
several questions popped up that we would like to ask.

1. Are all jobs eligible for coverage with queries? The reason we ask
is that there was some disagreement on whether all job runs are
eligible, or e.g. gate queue job runs only. For example, in Neutron,
we have fullstack and functional tests that are in check queue but not
in gate queue. Can we still post queries for those jobs? Will e-r bot
match against those queries?

2. Review velocity is not stable in the project. Sometimes we get
immediate reviews, sometimes not so much (the last one took me a month
to land a query). It's important that new queries get timely feedback.
Can we consider expanding core reviewer team to smoothen the process?
If not, how can we make sure queries land in time?

3. I see some IRC channels have elastic-recheck bot reporting about
identified failures in the channels. How can we add the bot to our
channel?

Thanks for the answers,
Ihar

__
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] [ovo] unhashable type error

[Ihar Hrachyshka]

Looking at the code, I don't see a clear case to even use set() type
there. A list would seem to work just fine. Should we try to convert
to using lists there?

Nevertheless, we can look into extending the object base class for
hashing. I wonder though if it's something to tackle in Neutron scope.
Sounds more like an oslo.versionedobjects library feature request.

Ihar

On Wed, Jan 25, 2017 at 11:53 AM, Das, Anindita  wrote:
> Hi Ihar,
>
>
>
> While doing the integration for vlanallocation [1] I found that OVO
> associated with VlanAllocation throws “unhashable type” error with py35.
>
> The associated stack trace is here [2].
>
>
>
> To resolve this issue I added an equality and hash method in the
> vlanallocation OVO [3].
>
> My understanding is we will face the same problem with other OVO objects as
> well when we do similar operations on the object as in [1].
>
> Should we make all the OVO objects hashable or deal it case by case?
> Thoughts?
>
>
>
>
>
> [1]
> https://review.openstack.org/#/c/367810/28/neutron/plugins/ml2/drivers/type_vlan.py@77
>
> [2] http://paste.openstack.org/show/596281/
>
> [3]
> https://review.openstack.org/#/c/367810/28/neutron/objects/plugins/ml2/vlanallocation.py@38-55
>
>
>
> Thanks,
>
> Anindita (irc: dasanind)

__
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] change in argument type for allocate_partially_specified_segment

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday
 wrote:
> Thanks for bringing this up!
>
> I was assuming that from Ocata everyone should switch from usage 'old'
> TunnelTypeDriver to updated one.

I am not sure. We haven't marked the 'old' one with any deprecation
warnings, did we? For Ocata at least, both classes will be available
for use. In Pike, we can look at cleaning up the old class (either
through deprecation warning and removal in Q; or using
NeutronLibImpact process).

>
> Revering both back to session means reverting all refactor and this is not
> in line with enginefacade work and as I remember some of OVO patches we
> waiting for this refactor too.
>
> I we can duplicate methods or we can check type of the argument if session
> or context and proceed differently. I will push patch for this ASAP.
>

I reviewed the patch, I think it's a good path forward, thanks.

Ihar

__
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] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor
 wrote:
> Given the latest issues related with the memory consumption[1] in CI jobs, 
> I’m just wondering if you have a plan to deal and/or improve it in Neutron.

AFAIU the root cause is still not clear, and we don't know if it's
Neutron or job setup that triggers the OOM. I think we all see that
the gate is not healthy lately (it's not just tempest, functional
failure rate is also pretty bad). We need a squad team with clear
ownership for failure tracking to get back to normal.

Ihar

__
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] PTL candidacy

[Ihar Hrachyshka]

On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton  wrote:
> LBaaS is a little special since Octavia will have it's own API endpoint
> completely that they will evolve on their own. The other spun-out projects
> (e.g. VPNaaS) will have the API defined in neutron-lib[1].

In a way, VPNaaS is also special, because it's an out-of-stadium repo
that nevertheless brings its own full blown API definition. We will
need to sort that out.

I see that you suggest we should work on bringing VPNaaS back into the
stadium during Pike. While I am not confidant that it may happen in a
single cycle (there were plenty of issues with the repo identified
during latest stadium assessment), I agree that, assuming we want that
API to exist in the future, it makes sense to bring it back in.
Especially if in the future we want to programmatically enforce single
source of API truth.

Ihar

__
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] PTL candidacy

[Ihar Hrachyshka]

Catching up on the thread, lots of good thoughts.

I don't think there is disagreement here around how Networking API
should evolve in terms of vendor extensions. As Kevin suggested, we
don't want to advertise API extensibility without Neutron team
supervision.

One of the reasons behind current api-ref effort that includes moving
API definitions from all stadium projects into neutron-lib - and
vouching for new API changes in scope of this single repo - is to
transform Neutron from a shallow API controller that allows to plug in
opaque API modules into a single API with consistent behavior, review
practices and standards.

I would go as far as to say that once that effort is complete, we
should start looking for ways to discourage (if not forbid) API
pluggability not proxied through proper in-neutron-lib review process.
It's one thing to allow plugging in different networking backends that
all implement the same Networking API behavior; and it's completely
different to allow those plugins to change Networking API to the point
where you can't even tell if it's open API guaranteed to work in other
environments.

Yes, there is concern that Networking API doesn't move as quick as
some vendors may want. We can address that with streamlining review
process for new API definitions. As long as an API proposal makes
sense not just for one specific backend, and is defined in general
enough terms, I think we can go with expedited review procedure.
Indeed we should probably reconsider how we enforce reference
implementation completion before an extension is allowed in.

Ihar

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur  wrote:
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one of
> the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is missing
> in Neutron APIs and what would take to make them extensible so that vendors
> do not run around trying to figure out alternative solutions
>
> cheers..
> -Sukhdev
>
>
>
>>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>
>
>
>
>>
>>
>> Thanks for attention,
>> Ihar
>>
>> __
>> 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-dev] [neutron] change in argument type for allocate_partially_specified_segment

[Ihar Hrachyshka]

Hi Anna,

I see that as part of [1], we changed the argument type for the $subj
function from session to context. Sadly, it turns out we still call it
with a session from the 'old' TunnelTypeDriver. I suspect the same
issue may affect allocate_fully_specified_segment.

I assume that means all 'old' tunnel type drivers are broken. Should
we fix it by duplicating those two functions for old and new cases
too? Or should we revert both of them back to session? (I assume the
former, since the latter is not in line with enginefacade work.)

[1] 
https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py

Thanks in advance,
Ihar

__
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] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
>> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote:
>> > I'm on board with getting visibility into the drivers with improvements to
>> > driverlog, etc. What I'm uncertain of is providing much in the lines of
>> > 'validation'. Core reviewers don't frequently have access to the hardware 
>> > or
>> > software required to validate these drivers so we can't be sure if the
>> > features really are working as expected.
>> >
>> > If validation is as flexible as you highlighted in the email, we can at
>> > least get it to a point where all recent CI runs are linkable from 
>> > driverlog
>> > and people can see recent tempest runs. I don't foresee the Neutron team
>> > getting to a point soon where we vouch for certain drivers though just
>> > because it is so hard to keep up with their changes (even ignoring changes
>> > in the vendor hardware itself).
>>
>> Good point. We may guide plugins and drivers on how to set up CI; we
>> may help Foundation to set up Marketplace in such a way that would
>> allow to automatically consume test artifacts from driver owners; we
>> may provide guidance to Foundation about which features are more
>> important to reflect that in Marketplace; but I would hope we don't
>> put the Neutron team on the hook to validate each driver, or even
>> police CI owners to produce consumable results. (The stick in the
>> latter case would be driver not showing up in Marketplace, or showing
>> up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?

I think it's B, but under Neutron team supervision. As a first step,
we would need to come up with an objective way to compare existing
drivers, and anarchy in how they execute tests, set up environment,
and publish artifacts won't make it easy.

I believe that as long as vendor CI setups are in line with our
guidelines (execute all tests and pass them, configure api_extensions
in tempest.conf to explicitly enumerate supported extensions), then we
can feed test artifacts into Marketplace, where a driver would get a
'supported'/'tested' badge for each extension enumerated in
tempest.conf as long as the latest run is success. If test run failed,
or an extension was not enumerated, then we don't have information
about whether it works with the driver, and hence will show N/A or
Unsupported in corresponding per-feature column.

Of course I assume here that support information useful to users is of
extension granularity. I think that's a reasonable assumption and is
in line with how Networking API is supposed to be consumed. We may
introduce additional tempest flags for special cases like ipv6 support
(already present) if better granularity is needed.

Ihar

__
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] PTL Candidacy

[Ihar Hrachyshka]

On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> I'm on board with getting visibility into the drivers with improvements to
> driverlog, etc. What I'm uncertain of is providing much in the lines of
> 'validation'. Core reviewers don't frequently have access to the hardware or
> software required to validate these drivers so we can't be sure if the
> features really are working as expected.
>
> If validation is as flexible as you highlighted in the email, we can at
> least get it to a point where all recent CI runs are linkable from driverlog
> and people can see recent tempest runs. I don't foresee the Neutron team
> getting to a point soon where we vouch for certain drivers though just
> because it is so hard to keep up with their changes (even ignoring changes
> in the vendor hardware itself).

Good point. We may guide plugins and drivers on how to set up CI; we
may help Foundation to set up Marketplace in such a way that would
allow to automatically consume test artifacts from driver owners; we
may provide guidance to Foundation about which features are more
important to reflect that in Marketplace; but I would hope we don't
put the Neutron team on the hook to validate each driver, or even
police CI owners to produce consumable results. (The stick in the
latter case would be driver not showing up in Marketplace, or showing
up with no feature support information.)

Ihar

__
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] [neutron] PTL candidacy

[Ihar Hrachyshka]

Hi team,

I would like to propose my PTL candidacy for Pike.

Some of you already know me. If not, here is my brief OpenStack bio. I
joined the community back in Havana, and managed to stick around till
now. During the time, I fit several project roles like serving as a
Neutron liaison of different kinds (stable, oslo, release), fulfilling
my Neutron core reviewer duties, taking part in delivering some
longstanding features, leading QoS and upgrades subteams, as well as
being part of Neutron Drivers team. I also took part in miscellaneous
cross project efforts.

I think my experience gives me broad perspective on how the OpenStack
community and more specifically Networking works, and what is expected
from its PTL.

First, let me describe my vision of PTL role.

* It's not only about technical intricacies. It's also about people
and procedures that make the project run smoothly day by day. The role
of PTL is in empowering other team members, keeping track of any
roadblocks and inconveniences that the team have, and working on
streamlining workflow.

* It's about delegation. We should make it a habit to look at the list
of potential candidates for core membership and other leadership and
administrative positions not just in times we are short on existing
members.

* PTL should be transparent and replaceable. I will work with outgoing
PTL to capture oral wisdom and state of affairs into a publicly
accessible project dashboard, and I will continue sharing such
information with the team on constant basis. The project dashboard
will give you answers to questions like: what's the project direction?
what are current priorities, and where does each stand?  what's on PTL
and Drivers' mind? which cross-project and governance initiatives are
currently worked on? etc.

As PTL, I'd like to focus on the following things:

* Speed up the RFE/spec process. We should manage RFE/spec review
pipeline in such a way so that initiatives that are given a green
light on writing up design details get timely feedback and can get
past spec process in reasonable time.  At the same time we should be
honest to the community not to accept proposals that have high risk to
fall through cracks due to lack of manpower. I will encourage usage of
reviewday and other tools to keep focus of the team. We will mull over
the idea of virtual code sprints for high demand topics.

* Continue Stadium program without drastic changes of direction.
Thanks to Armando, we filled the Stadium with tangible meaning. I want
us to build on top of that foundation to drive consistency and high
quality standards between participating projects.

* Support Marketplace rework. With huge number of drivers and plugins
available for Neutron, it became hard for operators to pick the right
one and for vendors to advertise their features. There is strong
vendor interest to improve situation there. We should boost Feature
Classification work, and integrate it with how third party CI systems
report test results so that they become useful for Marketplace.

* Introduce Gate Keeper role. We've recently made significant progress
in how we deal with gate: we expanded coverage to new types of jobs,
we utilize Grafana and other community tools, we review gate-failure
tagged bugs during weekly meetings. Sadly, sometimes gate becomes
unstable, and it slows down work progress for everyone.  In such
cases, it's all about timely addressing the issue. For that matter, I
will work with the team on defining a new Gate Keeper role that would
help prioritizing current gate issues, as well as proactively work
with the team on gate instability vectors. I believe clear ownership
is the key.

* Make centralized L3 legacy indeed. We have DVR and HA in tree for
quite some time. Both technologies are now mature enough, and are no
longer mutually exclusive. Sadly, they are still second class citizens
in our own gate.  My belief is we should give users a clear signal
that old L3 is indeed legacy by switching our jobs to DVR+HA where
applicable.  I am sure that will surface some previously unknown
issues, but we'll be ready to tackle them.  While it's never black or
white, I suggest we prioritize this work over adding new major L3
features.

* Support existing maintenance initiatives. I'd like us to close
neutron-lib saga in Pike, and consider neutron-lib switch for a
requirement to all Stadium projects starting from Queens. We should
also close OSC transition during Pike.

* Explore alternative ways to evolve Neutron API.  Piling up
extensions and allowing third parties to completely change core
resource behaviour is not ideal, and now that api-ref and API
consolidation effort in neutron-lib are closer to completion, we may
have better answers to outstanding questions than during previous
attempts to crack the nut. I would like to restart the discussion some
time during Pike.

Now, you may ask, it's a nice list of things to do, but we can't
manage to handle all of that in one cycle, can we? Well, 

Re: [openstack-dev] [All projects that use Alembic] Absence of pk on alembic_version table

[Ihar Hrachyshka]

An alternative could also be, for Newton and earlier, to release a
note saying that operators should not run the code against ENFORCING
galera mode. What are the reasons to enable that mode in OpenStack
scope that would not allow operators to live without it for another
cycle?

Ihar

On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday
 wrote:
> Hello everyone!
>
> Guys in our team faced an issue when they try to run alembic migrations on
> Galera with ENFORCING mode. [1]
>
> This was an issue with Alembic [2], which was quickly fixed by Mike Bayer
> (many thanks!) and new version of alembic was resealed [3].
> The global requirements are updated [4].
>
> I think that it is desired to fix this for Newton at least. We cannot bump
> requirements for Newton, so hot fix can be putting pk on this table in the
> first migration like proposed [5].  Any other ideas?
>
> [1] - https://bugs.launchpad.net/neutron/+bug/1655610
> [2] - https://bitbucket.org/zzzeek/alembic/issues/406
> [3] - http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
> [4] - https://review.openstack.org/#/c/423118/
> [5] - https://review.openstack.org/#/c/419320/
>
>
> --
> Regards,
> Ann Taraday
>
> __
> 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] Using neutron lib plugin constants

[Ihar Hrachyshka]

On Tue, Dec 27, 2016 at 12:03 AM, Gary Kotton  wrote:

> The following decomposed plugins are not gating:
>
> -  openstack/networking-brocade
> 
> (please see https://review.openstack.org/415028)
>
> -  openstack/networking-huawei
> 
> (please see https://review.openstack.org/415029)
>
> -  openstack/astara-neutron
> 
> (please see https://review.openstack.org/405388)
>
> Can the relevant maintainers of those projects please address things if
> possible.
>
>
>
> The openstack/networking-cisco
> 
> does not consumer the correct neutron-lib version. So can the maintainers
> also please take a look at that.
>
> Happy holidays
>
> Gary
>
>
>
> *From: *Gary Kotton 
> *Reply-To: *OpenStack List 
> *Date: *Monday, December 26, 2016 at 3:37 PM
> *To: *OpenStack List 
> *Subject: *[openstack-dev] [Neutron] Using neutron lib plugin constants
>
>
>
> Hi,
>
> Please note the following two patches:
>
> 1.  https://review.openstack.org/414902 - use CORE from neutron lib
>
> 2.  https://review.openstack.org/394164 - use L3 (previous known as
> L3_ROUTER_NAT)
>
> Please note that the above will be removed from neutron/plugins/common
> 
> /*constants.py* and neutron-lib will be used.
>
>
>
> For the core change I have posted:
>
> 1.  VPNaaS - https://review.openstack.org/#/c/414915/
>
>
>

I approved the VPNaaS patch. I think we can land CORE patch for neutron too
now (+2d).


> For the L3 change things are a little more complicated (
> http://codesearch.openstack.org/?q=L3_ROUTER_NAT=nope==):
>
> 1.  networking-cisco – https://review.openstack.org/414977
>
> 2.  group-based-policy – https://review.openstack.org/414976
>
> 3.  big switch - https://review.openstack.org/414956
>
> 4.  brocade - https://review.openstack.org/414960
>
> 5.  dragonflow - https://review.openstack.org/414970
>
> 6.  networking-huawei - https://review.openstack.org/414971
>
> 7.  networking-odl = https://review.openstack.org/414972
>
> 8.  astara-neutron - https://review.openstack.org/414973
>
> 9.  networking-arista - https://review.openstack.org/414974
>
> 10.  networking-fortinet - https://review.openstack.org/414980
>
> 11.  networking-midonet - https://review.openstack.org/414981
>
> 12.  networking-nec - https://review.openstack.org/414982
>
> 13.  networking-onos - https://review.openstack.org/414983
>
>
>
I note a lot of those repos do weird things with tox/requirements, pulling
mitaka neutron into master and similar. I don't think we want to wait for
them to fix their gate strategy. I am fine landing the neutron patch any
time, since projects had a working week to review the relevant patches, and
we merged all stadium fixes already. I put WIP on the neutron patch for now
just to give another announcement during the next team meeting, and then we
will proceed landing it.

Ihar
__
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] [neutron] killing non-dvr ovs scenario job

[Ihar Hrachyshka]

Hi all,

currently, we have three experimental scenario jobs:

1. linuxbridge single node
2. ovs non-dvr single node
3. ovs dvr multi node

I don’t see why we should at this point care about the 2nd one. I think we  
decided some time ago that the future we see is most if not all tempest  
jobs in neutron gate to be multinode, and dvr+ha enabled. In this context,  
trying to make the 2nd job work is not very productive, and I think we  
should instead focus on the 3rd one.


I proposed a patch killing the 2nd job here:  
https://review.openstack.org/#/c/414210/


Of course, linuxbridge is not dvr compatible yet, so we don’t touch it just  
now (though it could probably use some transition to multinode).


Ihar

__
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] [neutron][dragonflow] advertise_mtu option to be removed

[Ihar Hrachyshka]

Hi all,

I plan to remove the deprecated advertise_mtu option with  
https://review.openstack.org/413567


I checked projects still using the option, and the only project to be hit  
by the change seems to be dragonflow. I proposed a fix at:  
https://review.openstack.org/414047


Please make sure that your plugin does not access the option  
programatically, otherwise your plugin may break after we land the neutron  
patch. If you have more related patches for your project, please reuse the  
topic:


https://review.openstack.org/#/q/topic:advertise-mtu-removal

We will also announce the patch on one of next team meetings.

Thanks,
Ihar

__
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