[openstack-dev] [Neutron] Elevating context to remove subnets created by admin

2016-06-03 Thread Darek Smigiel
Hello,
Doing reviews I noticed, that Liu Yong submitted a bug [1] where we have a 
problem with removing subnets.

In short: if tenant wants to delete network with subnets, where at least one of 
subnets is created by admin, he’s not able to do this.
Liu also prepared bugfix for it [2], but now it’s starting to be much more 
complicated.

What is desired solution in this case?
One of suggestions is to elevate context, remove all subnets and nuke 
everything. It can cause a problem, when one tenant can remove others’ tenant 
subnets.
The other is to just show info to tenant, that he’s not allowed to delete 
network. But in the same time, it could be strange, that owner is not able to 
just get rid of *his* network and subnets.

If you have any opinions, suggestions, please feel free to share

[1] https://bugs.launchpad.net/neutron/+bug/1588228
[2] https://review.openstack.org/#/c/324617/


Darek
__
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] Bi-weekly upgrades work status. 6/2/2016

2016-06-02 Thread Darek Smigiel
Thanks Artur for this summarize.

> On Jun 2, 2016, at 3:29 PM, Korzeniewski, Artur 
>  wrote:
> 
> Hi Neutrinos,
> I would like to start the first bi-weekly upgrades work report.
>  
> TLDR:
> In order to inform community what is going on in upgrades field, we would 
> like to start bi-weekly reporting. We would like to show progress in database 
> resource transition to Oslo VersionedObjects. Also list of code refactoring 
> places will be provided. Community members can take a look at the list and 
> see if their work is not conflicting with upgrades effort.
>  
> General approach:
> During Mitaka release cycle, we have started the journey to port database 
> resources to Oslo VersionedObject (OVO). As first, we have chosen the Port, 
> Subnet and Network resources. As the process is very complicated, we have 
> divided the work to first define interface object, and then work on 
> integration patches in core Neutron code. The NeutronDbObject base class is 
> still evolving, and we have spent the Mitaka release cycle on working on 
> solid base, in order to reuse the code for all derived classes.
> We are still working on basic OVO integration, so any help in getting the 
> work done would be appreciated. For detailed info, please take a look at 
> below list.
> We would like to finish already started patches, priority has the Port, 
> Subnet and Network objects. If you want to contribute and port new objects to 
> OVO, please prepare object implementation and some usage in core Neutron 
> code. In order to see which object is already covered, please take a look at 
> below list of existing patches.
>  
>  
> I would like to remind that agreed approach at Design Summit in Austin was, 
> that every new resource added to neutron should have OVO implemented. Please 
> comply, and core reviewers please take care of this requirements in patches 
> you review.
>  
>  
> The effort to move all database resources to Oslo VersionedObject will 
> contribute to block offline contracting migration in Ocata release. In Newton 
> cycle we would like to have our last offline data migration.
>  
>  
> Objects merged:
> Subnetpool https://review.openstack.org/275789 
> 
> Subnet https://review.openstack.org/264273 
> 
> Port extension: Allowed address pairs https://review.openstack.org/268274/ 
> 
> Port extension: Extra DHCP opt https://review.openstack.org/273072/ 
> 
> Port extension: Port allowed address pairs 
> https://review.openstack.org/268274 
> Port extension: Port security https://review.openstack.org/292178 
> 
> OVO for VLAN aware VMs: https://review.openstack.org/310410 
> 
>  
>  
> Objects under review:
> Network https://review.openstack.org/269658 
> 
> Port https://review.openstack.org/253641 
> Port extension: security groups https://review.openstack.org/284738 
> 
> Agent  https://review.openstack.org/297887 
> 
> Route, RoutePort and RouterRoute https://review.openstack.org/307964 
> 
> DistributedVirtualRouter mac address https://review.openstack.org/304873/ 
> 
> Service Type: https://review.openstack.org/304322 
> 
> Flavor and Service Profile https://review.openstack.org/306685 
> 
>  
>  
> Integration patches merged:
> Integrate the port allowed address pairs VersionedObject in 
> Neutronhttps://review.openstack.org/287756 
> 
> Integrate the Extra Dhcp Opt VersionedObject in Neutron 
> https://review.openstack.org/285397 
>  
> Integration patches Under development:
> Subnet OVO https://review.openstack.org/321001 
> 
> Identified usages of Subnet:
> · main integration with db_base_plugin and ml2 plugin
> · DHCP RPC usage
> · IPAM usage
> · dvr_mac_db.py
> · l3_db.py
> · extraroute_db.py
> Subnetpool usage: https://review.openstack.org/300056 
> 
> Replace plugin class for address scope ovo 
> https://review.openstack.org/308005 
>  
>  
> Testing:
> The API tests for sorting/pagination has been added for port and network
> https://review.openstack.org/306272 
> https://review.openstack.org/320980 
> More tests are needed for resources that use sorting/pagination on API level.
> Testing in gate has been covered 

[openstack-dev] [Neutron][Stable][Liberty][CLI] Gate broken

2016-05-17 Thread Darek Smigiel
Hello Stable Maint Team,
It seems that python-neutronclient gate for Liberty is broken[1][2] by update 
for keystoneclient. OpenStack proposal bot already sent update to requirements 
[3], but it needs to be merged.
If you have enough power, please unblock gate.

Thanks,
Darek

[1] https://review.openstack.org/#/c/296580/
[2] https://review.openstack.org/#/c/296576/
[3] https://review.openstack.org/#/c/258336/
__
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] OSC transition

2016-05-04 Thread Darek Smigiel

> On May 4, 2016, at 6:10 AM, Na Zhu <na...@cn.ibm.com> wrote:
> 
> Hi Richard,
> 
> I read the contents in the link, I think the discussion in Austin summit have 
> not updated to the webpage.
> But from here 
> https://etherpad.openstack.org/p/newton-neutron-future-neutron-client 
> <https://etherpad.openstack.org/p/newton-neutron-future-neutron-client>, it 
> mentions python-neutronclient provides OSC plugin for neutron-*aas,
> does it mean all neutron-*aas CLIs still live in python-neutronclient repo? 
> If yes, should every neutron-*aas owner updates the CLIs from neutron to 
> openstack?
> 
> I found Dean Troyer set the [Blueprint neutron-client] implement neutron 
> commandsstate to obsolete, does the OSC transition continue move along?
> 

Transition is in progress. Here you have spec for it [1]. Probably the most 
important thing for you is this [2] where all required commands are described.


[1] 
http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html
 
<http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html>
[2] https://etherpad.openstack.org/p/osc-neutron-support 
<https://etherpad.openstack.org/p/osc-neutron-support>

Darek Smigiel (dasm)

__
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] Social at the summit

2016-04-28 Thread Darek Smigiel
Unfortunately, I’ve got response from Bangers, that they’re fully booked for 
Today

"Thank you for your interest in hosting a business dinner with us at Banger's 
tonight. Unfortunately we are booked with reservations this evening, so I am 
unable to accommodate your request. I wish you all the best in finding the 
perfect venue for your event.”

Are we trying to find some other spot, or just keep Bangers and we will see?

Darek

> On Apr 26, 2016, at 8:27 PM, Kyle Mestery <mest...@mestery.com> wrote:
> 
> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
> but it should be able to hold 50+ people. See y'all at 6PM Thursday!
> 
> Kyle
> 
>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery <mest...@mestery.com> wrote:
>> 
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han <hzh...@ebay.com> wrote:
>>> +1 :)
>>> 
>>> Han Zhou
>>> Irc: zhouhan
>>> 
>>> 
>>> On Monday, April 25, 2016, Korzeniewski, Artur
>>> <artur.korzeniew...@intel.com> wrote:
>>>> 
>>>> Sign me up :)
>>>> 
>>>> Artur
>>>> IRC: korzen
>>>> 
>>>> -Original Message-
>>>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>>>> Sent: Monday, April 25, 2016 7:19 PM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> <openstack-dev@lists.openstack.org>
>>>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>>> 
>>>> Count me in!
>>>> Will be good to meet all you guys!
>>>> 
>>>> Darek (dasm) Smigiel
>>>> 
>>>>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>>>> <doug...@parksidesoftware.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>>> wrote:
>>>>>> 
>>>>>> WAT???
>>>>>> 
>>>>>> It was never supposed to be core only. Everyone is welcome!
>>>>> 
>>>>> +2
>>>>> 
>>>>> irony intended.
>>>>> 
>>>>> Socials are not controlled by gerrit ACLs.  :-)
>>>>> 
>>>>> doug
>>>>> 
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On 25 Apr 2016, at 11:56, Edgar Magana <edgar.mag...@workday.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Would you extend it to ex-cores?
>>>>>>> 
>>>>>>> Edgar
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 4/25/16, 10:55 AM, "Kyle Mestery" <mest...@mestery.com> wrote:
>>>>>>>> 
>>>>>>>> Ihar, Henry and I were talking and we thought Thursday night makes
>>>>>>>> sense for a Neutron social in Austin. If others agree, reply on this 
>>>>>>>> thread
>>>>>>>> and we'll find a place.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> Kyle
>>>>>>>> 
>>>>>>>> ___
>>>>>>>> ___ 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] Social at the summit

2016-04-26 Thread Darek Smigiel
Great idea Kyle,
This place looked awesome.

FYI, I’ve sent request for reservation. Just in case if Thursday would be 
crowded, especially that a lot of teams could have the same idea.

Thanks,
Darek

> On Apr 26, 2016, at 8:27 PM, Kyle Mestery <mest...@mestery.com> wrote:
> 
> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
> but it should be able to hold 50+ people. See y'all at 6PM Thursday!
> 
> Kyle
> 
>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery <mest...@mestery.com> wrote:
>> 
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han <hzh...@ebay.com> wrote:
>>> +1 :)
>>> 
>>> Han Zhou
>>> Irc: zhouhan
>>> 
>>> 
>>> On Monday, April 25, 2016, Korzeniewski, Artur
>>> <artur.korzeniew...@intel.com> wrote:
>>>> 
>>>> Sign me up :)
>>>> 
>>>> Artur
>>>> IRC: korzen
>>>> 
>>>> -Original Message-
>>>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>>>> Sent: Monday, April 25, 2016 7:19 PM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> <openstack-dev@lists.openstack.org>
>>>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>>> 
>>>> Count me in!
>>>> Will be good to meet all you guys!
>>>> 
>>>> Darek (dasm) Smigiel
>>>> 
>>>>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>>>> <doug...@parksidesoftware.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>>> wrote:
>>>>>> 
>>>>>> WAT???
>>>>>> 
>>>>>> It was never supposed to be core only. Everyone is welcome!
>>>>> 
>>>>> +2
>>>>> 
>>>>> irony intended.
>>>>> 
>>>>> Socials are not controlled by gerrit ACLs.  :-)
>>>>> 
>>>>> doug
>>>>> 
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On 25 Apr 2016, at 11:56, Edgar Magana <edgar.mag...@workday.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Would you extend it to ex-cores?
>>>>>>> 
>>>>>>> Edgar
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 4/25/16, 10:55 AM, "Kyle Mestery" <mest...@mestery.com> wrote:
>>>>>>>> 
>>>>>>>> Ihar, Henry and I were talking and we thought Thursday night makes
>>>>>>>> sense for a Neutron social in Austin. If others agree, reply on this 
>>>>>>>> thread
>>>>>>>> and we'll find a place.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> Kyle
>>>>>>>> 
>>>>>>>> ___
>>>>>>>> ___ 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] Social at the summit

2016-04-25 Thread Darek Smigiel
Count me in!
Will be good to meet all you guys!

Darek (dasm) Smigiel

> On Apr 25, 2016, at 12:13 PM, Doug Wiegley  
> wrote:
> 
> 
>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka  wrote:
>> 
>> WAT???
>> 
>> It was never supposed to be core only. Everyone is welcome!
> 
> +2
> 
> irony intended.
> 
> Socials are not controlled by gerrit ACLs.  :-)
> 
> doug
> 
>> 
>> Sent from my iPhone
>> 
>>> On 25 Apr 2016, at 11:56, Edgar Magana  wrote:
>>> 
>>> Would you extend it to ex-cores?
>>> 
>>> Edgar
>>> 
>>> 
>>> 
>>> 
 On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
 
 Ihar, Henry and I were talking and we thought Thursday night makes sense 
 for a Neutron social in Austin. If others agree, reply on this thread and 
 we'll find a place.
 
 Thanks!
 Kyle
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] fyi, continued tenant -> project changes in devstack

2016-04-04 Thread Darek Smigiel



On 04/04/2016 02:52 PM, Sean Dague wrote:

The following patches are making changes to shift from tenant -> project
for all the  references in devstack (it's not quite done yet, but this
was done as a lot of small patches to make potential reverts easy) -
https://review.openstack.org/#/q/topic:project_id+project:openstack-dev/devstack+status:open

For the most part this shouldn't impact folks, as nothing in here should
really be used outside of devstack. However some plugins might be
impacted if they work off of variables that were not expected.

https://review.openstack.org/#/c/301122/ - which makes changes to some
of lib/neutron-legacy is the patch I would most expect to have that kind
of side effects.


In the meantime similar work is happening in Neutron, so in the future, 
there would be possibility to remove all occurences of 'tenant_id' from 
this place.


https://review.openstack.org/#/q/topic:bp/keystone-v3+status:open



If breaks happen, please let us know. The response is mostly going to be
'please update your plugins' unless there turns out to be a really bad
issue.

-Sean




__
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] -2'ing all patches on every gate breakage

2016-04-04 Thread Darek Smigiel



On 04/04/2016 11:41 AM, Armando M. wrote:



On 4 April 2016 at 09:36, Ihar Hrachyshka > wrote:


Graham > wrote:

On 04/04/2016 17:11, Ihar Hrachyshka wrote:

Hi all,

I noticed that often times we go and -2 all the patches in
the review queue
on every neutron specific gate breakage spotted. This is
allegedly done to
make sure that nothing known to be broken land in merge
gate until we fix
the breakage on our side.

While I share the goal of not resetting the gate if we can
avoid it, I find
the way we do it a bit too aggressive. Especially
considering that often
times those -2 votes sit there not cleared even days after
the causing
breakage is fixed, needlessly blocking patches landing.

I suggest we either make sure that we remove those -2
votes right after
gate fixes land, or we use other means to communicate to
core reviewers
that there is a time window when nothing should land in
the merge queue.

Thanks,
Ihar


I recently submitted https://review.openstack.org/295253 as an
idea for
designate to prioritize reviews.

Something similar could be a good solution, in conjunction
with a bot.

So, when a gate breakage starts, saying "!gate breakage" would
apply a
"-1 Procedural Block" that gets removed when "!gate fixed" was
said?

This removes the need for humans to do the removal (and try and
remember which reviews were really -2'd or they had had a -1 on)


Thanks for the idea, that’s indeed an interesting approach. It
also helps in that now any core member would be able to
consistently block project patches for merge gate, or cancel the
alert.

Armando, do you think we could try to adopt the approach? If yes,
I may look into a patch for that.


Um, not sure, it feels over-engineered.


My $0.02
Recently, we had several gate breakages, so it would be nice to have 
automatic tool to block/unblock patchsets without any problem.


I don't know if this is a good solution, but could give *power* to all 
core reviewers to immediately give "STOP" sign for all patchsets.


--
Darek





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] [neutron] -2'ing all patches on every gate breakage

2016-04-04 Thread Darek Smigiel

One of these patchsets was mine, so I feel qualified to send a response :)

On 04/04/2016 12:06 PM, Armando M. wrote:



On 4 April 2016 at 09:51, Ihar Hrachyshka > wrote:


Doug Wiegley > wrote:

On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka
> wrote:

Armando M. >
wrote:

On 4 April 2016 at 09:01, Ihar Hrachyshka
> wrote:
Hi all,

I noticed that often times we go and -2 all the
patches in the review queue on every neutron specific
gate breakage spotted. This is allegedly done to make
sure that nothing known to be broken land in merge
gate until we fix the breakage on our side.

This is not allegedly done. When I do it, I put a
comment next to my action.



While I share the goal of not resetting the gate if we
can avoid it, I find the way we do it a bit too
aggressive. Especially considering that often times
those -2 votes sit there not cleared even days after
the causing breakage is fixed, needlessly blocking
patches landing.

That's a blatant lie: I am aggressive at putting -2s
as well as removing them. Other changes for those the
-2 stick is probably because they aren't worth the
hassle. We've been also in feature freeze so slowing
things down should have hurt anyway.


I suggest we either make sure that we remove those -2
votes right after gate fixes land, or we use other
means to communicate to core reviewers that there is a
time window when nothing should land in the merge queue.

Initially I tried sending emails ahead of time
alerting for gate breakages, but that doesn't work for
obvious reasons: there is a lag that can still be fatal.



Emails don't work. Or work just occasionally.
Openstack Dev mailing list is pretty crowded, so sometimes to read 
everything, takes hours. In this situation, important message can be 
easily skipped.




On the specific circumstance, gate broke on Friday
late afternoon PDT. It didn't seem that was anything
critical worth merging at all cost that couldn't wait
until Monday morning and I didn't bother check that
things merged safely in the middle of my weekend.


Yeah, but it’s already up to two working days in some places.


Not that -2’s sitting around is good, but what is so urgent
that two days affects the overall flow of things, and didn’t
get escalated?  Review chains can address collaboration
issues.  Monster syntax churns with lots of conflicts get more
annoying, but they’re annoying for everyone anyway. The worst
part of two days with a -2 is the fact that no one will look
at it and give feedback during that time period, IMO, not that
it takes longer to merge.  Velocity is about throughput, not
latency.


It is definitely not the end of the world. The process of -2
cancellation is just non-transparent, and I am not sure whether I
need to reach the vote owner to remove it, or it will just
magically vanish. I had inconsistent experiences with freezing
-2’s in OpenStack.


If the vote doesn't magically vanish when you expect to, you can 
simply reach out the person. When has that become a problem, 
especially when that person is usually available on irc and generally 
very responsive?


The -2 keeps you on your toes and aware of the state of the gate, 
which to me is a good thing :)


I'll shortly describe the situation.
My patchset got approved. It had +W and gate pre-approved it, but failed 
on final merge. So at the end landed as +2, +W and -2 from gate.


I didn't know what happened until I've seen Armando's "-2" with 
explanation. Even though I'm trying to be proactive on IRC channel about 
possible gate problems.


So it's definitely good method to "be aware". But, in the same time it 
was very strange to me. I had everything prepared to be merged, but it 
didn't got merge.




Landing a patch earlier lowers the chance of git conflict for
other patches being crafted in parallel with it; it also removes
the need for a core reviewer to get back to it and +W later, in
case enough +2 votes are there. 



I like the idea of adopting -1 instead of -2 and looking whether
it still works for the initial goal