20:00:54 #startmeeting tc 20:00:56 Meeting started Tue Mar 15 20:00:54 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:57 ./ 20:00:57 hi 20:00:59 * rockyg tries to stay quiet in the back of the room 20:01:00 The meeting name has been set to 'tc' 20:01:09 Hellllooo everyone! 20:01:14 Our agenda for today: 20:01:15 yoooooooooo 20:01:20 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:33 I is here. 20:01:37 #topic Extra ATCs 20:01:42 We have a couple extra ATCs requests to rubberstamp. 20:01:50 NB: the governance repo was tagged for elections last week though, so those won't vote in upcoming elections 20:02:05 unless we start doing very funny things 20:02:09 * Adding Horizon extra-atc (https://review.openstack.org/290188) 20:02:20 i'm not in favor of doing funny things with the election 20:02:33 that one has enough to pass, will approve now 20:02:39 * Add dencaval to extra-atcs for Manila (https://review.openstack.org/289408) 20:02:46 o/ 20:02:47 already doing final testing on our roll generation tooling based on the existing tag 20:02:50 this one is missing one 20:03:01 was there a deadline missed for dencaval to need extra atc? 20:03:12 I don't see a need for it but maybe someone can explain 20:03:19 annegentle: start of PTL nomination period 20:03:29 ttx: ah for elections then? 20:03:29 annegentle: I thought he deserved voting rights in Manila, as well as docs 20:03:29 annegentle: just commented 20:03:33 annegentle: that is when we tag the governance repo and start generating rolls 20:03:37 I'm on spring break but popped in for this 20:03:41 thanks russellb 20:03:46 annegentle: dencaval has atc for docs, bswartz just wanted him in manilla too 20:03:47 needed to understand 20:03:50 annegentle: it's voting rights in manila as well 20:03:51 got it 20:03:55 bswartz : I think ttx and fungi just said it would be too late for this election anyway? 20:04:08 that will be valid for the next 20:04:08 yes that's my fault 20:04:08 still reasonable for next time around 20:04:15 voting rights last two cycles 20:04:16 ok, just making sure that's clear 20:04:18 russellb: ++ 20:04:21 I've already conveyed my apologies 20:04:34 alright both approved 20:04:39 thanks 20:04:42 #topic Update Kuryr mission statement 20:04:52 it will come into effect for ocata elections and summit passes for barcelona 20:04:57 o/ 20:04:58 #link https://review.openstack.org/289993 20:05:05 So this is about extending the bridging mission of Kuryr to also include storage features 20:05:21 It's a significant change but I think it makes sense 20:05:29 I still don't get it 20:05:55 these are really high level use cases, but it's not clear what actual code is to be written 20:06:02 and where that code plugs into the overall system 20:06:08 russellb: I'm not 100% sure what they will end up needing doing, yes 20:06:22 since for example Kubernetes has a cinder plugin 20:06:30 i'd expect a bit more confidence in specific deliverables than this 20:06:48 The bit about persistent storage for containers sounds interesting, though not conrete 20:06:52 but they seem convinced there are interesting things to do, and I'm fine with them exploring 20:06:54 *concrete 20:07:15 now if only Gerrit would ah. 20:07:17 ttx: +1, to me I'm ok with it as well 20:07:52 ok, well recorded my -1 fwiw. i'd rather just not rubber stamp these things 20:08:19 I think it's fine to wait a bit longer and have a more specific mission statement 20:08:20 russellb: I'm fine delying until we can get better answers from Gal 20:08:24 russellb: Agree 20:08:34 I raised the fuzziness first after all 20:08:38 ttx: right 20:08:49 I'd be ok with that, too. 20:08:54 russellb: I meant, I agree with not rubber stamping 20:08:54 ttx: o/ 20:08:57 yeah, the answers so far are almost as broad as the proposed mission statement 20:09:04 I'd be fine waiting a bit more, but I'm also ok trusting the team to move forward here and explore a bit 20:09:09 and i'm struggling with making it concrete -- 20:09:14 don't need to update mission statement to explore 20:09:16 russellb: can you take the action to reach out and get a cleaner explanation, or even (gasp) a ML thread about it ? 20:09:26 i've tried in gerrit 20:09:34 russellb: Fair point 20:09:35 russellb: I think it warrants a ML thread to be fair 20:09:38 ok 20:09:39 i can do that 20:09:52 if only so that the rest of the community sees it better 20:09:59 "Kuryr is the glue between the container world and OpenStack APIs"? 20:10:28 jaypipes: basically, no need to create glue if storage does not need glue 20:10:43 ttx: docker has a Cinder plugin? 20:10:44 the network case was clear, there are very clear plugin interfaces 20:10:54 i just want to know the equivalent for storage that they are targeting here 20:11:17 because without that, it's not clear to me that openstack should have a project for it 20:11:21 jaypipes: no but (1) k8s has, and (2) that might point to the possibility of adding it in Docker rather than OpenStack 20:11:23 vs working upstream in container thingy projects 20:11:33 hence more precision needed 20:11:39 ttx: fair enough points. 20:12:00 I'm not saying no (I actually still am a YEs on the proposal) but I agree with Russell this could use more clarity on the goals 20:12:12 yep, and i'm not upset if i'm overridden really :) 20:12:39 I'm happy with the use case getting more discussion so we all understand more 20:12:41 but "does this actually make sense" is a good question to ask :) 20:12:42 Also it sounds like extending a team mission should at the very minimum cause a ML thread, if only to attract more contributors 20:12:47 russellb: yah 20:12:47 I'm ok with waiting. More clarification is good and if the mission statement change is required then we better get it right otherwise it'll be upated again next cycle 20:13:36 #info waiting one more week for extra precision 20:13:56 #action russellb to follow up in a ML thread 20:14:20 #topic Add a resolution for PTL Leave of Absence 20:14:25 #link https://review.openstack.org/290141 20:14:33 anteaya posted a resolution to clarify TC communication expectations on PTLs leaves of absence 20:14:37 * annegentle admits she hasn't read it yet 20:14:47 The preferred option is of course public communication, but there are some cases where the PTL would rather not go public with the details, so there are backup solutions as well 20:14:57 There was some opposition to the resolution, mostly about the "communicate to the TC" part if I read the comments correctly 20:15:10 I think that's partly a misunderstanding on what the resolution is trying to achieve -- this is not about the PTLs communication duties toward their teams 20:15:15 i'd rather assume PTLs use good judgement and work this out within their teams 20:15:17 It's about clarifying the official projects PTLs communication duties toward the TC 20:15:34 yeah, the issue is all of the interface points outside of a team that also need to know about these changes 20:15:34 I think we can further document the PTLs communication duties toward their teams, but I see that as belonging in the Project Team Guide rather than governance 20:15:36 feels like massive overkill in policy 20:15:44 can we clarify the requirements/desires without specifying implementation? 20:15:45 russellb: ++ 20:16:00 russellb : "Please tell folks if you're going to be gone for a long time and you lead a project" is overkill? 20:16:12 i don't think we need a resolution for it 20:16:15 Ubuntu has a code of leadership which speaks to this 20:16:25 russellb : so how do we address it? 20:16:35 I think the current proposal is overly proscriptive 20:16:39 we kind of already had the "step down gracefully" clause buried somewhere 20:16:47 I see two things to think about: 1) elected leaders have a responsibility to those who elected them 20:16:54 We could just document it on the Project Team Guide. But I don't think a resolution is overkill either. 20:17:02 I'd support something that just highlights the required outcome 20:17:09 My initial sense is that what you really want to have a policy for is PTL disappearence/non-communication. Also consider the case where a PTL is pregnant (hey, it can happen), would she need to not run in the time period? 20:17:11 which is that folk don't go awol 20:17:16 sdague: that is the smooth tranistions expectation, but I don't know if this was a transisiton or not, hence the desire for more facts 20:17:18 2) the TC is the focal point for working across the other tehnical leaders in projects 20:17:19 lifeless: that's my read of it too 20:17:37 I like jaypipes's comments: Lets trust PTLs and project teams to handle this on their own, communicating with the TC. If the TC needs to step in to help, we can do that. 20:17:39 so I think I'm on the side that we don't need another policy for this 20:17:41 dtroyer: yes that's it 20:17:42 vacations, known predictable medical leave, those are having a life 20:18:01 annegentle: this doesn't cover vactation 20:18:06 this is unexpected events 20:18:11 non planned 20:18:12 community norms weren't followed, step down gracefully should cover this. 20:18:12 mestery : so this came about because of the situation with trove last week, in which a lot of people were surprised and up in arms because the ptl was out for a couple of weeks and only a few folks outside of the team knew. 20:18:23 sdague: should but didn't 20:18:28 was there actually a problem with trove? 20:18:33 sdague: is it documented somewhere (the "step down gracefully" ?) 20:18:35 we clearly had someone available to talk to and work with 20:18:36 dhellmann: OK, so what happened that was super bad during that time period? 20:18:39 it wasn't hard to figure out 20:18:39 sure, but its too low level; we can't legislate every eventuality. Was this prompted by some PTL going awol ? 20:18:44 Did the release for trove go bad or not happen (that would be bad)? 20:18:50 russellb : no. he was out for a few weeks, he came back, everything was handled except for whatever happened in the meeting last week. 20:18:58 As I mentioned in the spec, I'm also not in favor of having a policy for this. I'd rather rely on the common sense of PTLs and, most importantly, the community's 20:18:59 lifeless: yes, trove PTl was out but most didn't know 20:19:01 OK, so sounds like common sense prevailed? 20:19:16 I swore it was in our community standards somewhere, grepping 20:19:31 sdague: if it's already documented somewhere I'm fine not adding a layer 20:19:36 someone from the project came to the tc meeting and told us that though. i'm not upset. 20:19:39 sdague: grep man grep 20:19:43 jeblair: ++ 20:19:43 if we look past the prescriptive language in this resolution, I'm having a hard time understanding why we wouldn't want to write down that we expect folks to announce this sort of thing 20:20:09 especially if they happen to be stressed 20:20:12 jeblair : yeah, it was the qa folks I think 20:20:13 sdague: https://wiki.openstack.org/wiki/PTL_Guide#Availability ? 20:20:17 (that were upset) 20:20:18 and if we really want to add the resolution, I'd avoid mentioning all the steps and perhaps simplify it with: "let us know, please" 20:20:18 and are trying to figure out the right thing to do 20:20:26 more that it feels so heavyweight ... if we have to write this down, do we need formal policies for everything that seems like reasonable common sense 20:20:41 flaper87 : I agree with making this proposal simpler 20:20:48 flaper87: ++ 20:20:59 Resolution: IF as PTL you're going somewhere, let your project team and the TC know. 20:21:04 Seems pretty simple 20:21:06 how about we turn it into something we add to the project team guide ? 20:21:11 flaper87: that's what I suggested in the comments 20:21:12 ttx: +++ 20:21:13 ttx: sounds reasonable 20:21:14 thingee: yeh, I think thwas was it 20:21:15 ttx: that works 20:21:19 you don't have to go anywhere to not be able to fulfill your obligations 20:21:21 ttx: that would work, and make sure you have a proxy assigned 20:21:24 ttx: https://wiki.openstack.org/wiki/PTL_Guide#Availability 20:21:27 you can still be at home/office 20:21:30 anteaya : figure of speach 20:21:32 markmcclain: yeah, I did as well but... 20:21:32 just move that from the wiki 20:21:35 thingee: that's not official doc anymore 20:21:38 thingee: right 20:21:42 I'm not in favor of prescriptively documenting common sense in this case 20:21:42 ttx: if the bit thingee posted isn't in the guide, i think that's a great thing to include 20:22:06 someone needs to care enough to push that. That is why I was fine with the resolution model, whatever the author prefers basically 20:22:16 To me, the most important part is for the team to know the PTL is not going to be around. IF they manage to nominate an interim PTL, that's more than awesome. IMHO 20:22:23 An email to the ML is great 20:22:27 do we have a volunteer to push that in the PTG instead ? 20:22:29 ttx: I can do it 20:22:31 flaper87: Agreed 20:22:34 thingee: thanks! 20:22:37 thanks, thingee 20:22:54 thingee: awesome, thanks 20:23:01 and good find on it :) 20:23:04 Personally I think the PTG is more discoverable and less intimidating than a resolution, so I'm fine with it landing there 20:23:10 thingee: there's some similar language in doc/source/open-community.rst ; so maybe an enhancement to that 20:23:37 ttx: ++ 20:23:44 ttx: ++ 20:24:14 agreed let's not make it less appealing/possible to be PTL :) 20:24:15 I think we have consensus, lets move on? 20:24:27 yes 20:24:34 thingee: http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections 20:24:40 #agreed Push the thing to the PTG instead 20:24:58 jeblair: thanks 20:24:59 #action thingee to propose a PTG change to cover expectations on PTLs 20:25:16 thanks anteaya for bringing it up; obviously needed some thoughtful discussion 20:25:26 anteaya: ++ 20:25:30 ++ 20:25:33 ++ 20:25:37 ++ 20:25:49 well brought you all together 20:25:53 who else can do that? 20:26:03 Alrighty 20:26:12 #topic Open discussion 20:26:13 * jeblair has an answer but keeps it to himself 20:26:19 * Status update on the testing interface conformance issues found in Trove 20:26:23 To be respectful of everyone's time, and so you don't have to all watch me type this, I've put these comments on gist. 20:26:23 https://gist.github.com/amrith/343415cda4a937f78eac#file-trove-stable-liberty-txt 20:26:42 tl;dr is most issues were fixed ? 20:26:49 * ttx reads 20:26:51 yes, the summary is this 20:26:59 In summary, let me say that the stable/liberty gate is now working 20:26:59 again and is reliable. More needs to be done, and there is a plan to 20:26:59 address it in stable/liberty, stable/mitaka and moving forward. 20:27:15 I would also like to thank Matt for escalating this issue. 20:27:27 and I'll be working with him to take care of some final 'cats and dogs' ... 20:28:02 the cats and dogs that are raining down? 20:28:16 alright, it seems the issue is now closed and doesn't need TC follow-up 20:28:18 amrith: thanks for working on that 20:28:30 thanks amrith ! 20:28:31 russellb, if you are near where I am, yes it is raining hard. they call it New England for a reason ;) 20:28:32 yes, thx amrith for jumping on the issue and fixing it 20:28:47 thanks to all for the help getting the issues resolved. 20:28:47 it is raining cats and dogs here, for sure 20:28:49 i'm in California today, very dry 20:29:00 do we have both mordred and lifeless ? 20:29:23 Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%) 20:29:26 Just a heads up from the comm team: A blog post is being written. It started after our last meeting but there was not enough time. Hopefully will go out in the next couple of days 20:29:35 thanks flaper87 20:29:39 ttx: reporting for duty 20:29:49 mordred: around ? if yes I'd like to get deeper in the discussion we started two weeks ago 20:29:50 ttx: I am here! 20:29:57 * Are GPL test-only Python library dependencies an issue or not ? (lifeless, mordred) 20:30:00 About lifeless comments on https://review.openstack.org/#/c/279999/ 20:30:03 mordred: was just about to ring you :) 20:30:04 I feel like lifeless and I got somewhere 20:30:08 The question is... should GPL test-time library dependencies (like scapy or Mysql-Python) be considered ok or not 20:30:09 thanks tristanC 20:30:11 when we chatted a couple of weeks ago 20:30:16 lifeless seems to think they aren't ok, mordred seemed to think they are ok 20:30:22 fight! 20:30:24 I believe we've gotten to a middle ground 20:30:27 ttx: lol 20:30:28 dammit 20:30:30 ttx: I think we agreed that we can't say yes or no to that question 20:30:30 boring 20:30:34 buuuu 20:30:34 yah. 20:30:36 * flaper87 yawns 20:30:38 boo 20:30:38 from cross-project land, I surfaced up some stale specs http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html 20:30:40 ttx: sometimes they will. Sometimes they won't. 20:30:40 that it depends on the dependency 20:30:46 and we shoudl use human judgement 20:30:47 what sort of fight is this 20:30:54 ha 20:30:55 ttx: we fought in #openstack-dev 20:30:58 you missed it 20:30:58 ttx: so -> the blanket rule is that we have to assess each one. 20:31:06 I'd be interested in either someone interested in reviving these or the TC agreeing on some of these old specs being abandoned 20:31:23 lifeless: is there something we can add to the licensing requirements to make the rule clearer ? 20:31:30 or what we'd use to assess the rule ? 20:31:44 ttx: so its messy 20:31:47 because I'm not sure "asking mordred and lifeless about it" is scalable and durable 20:31:48 thingee: gotta admit, it took me a bit longer to parse that last sentence 20:32:08 ttx: ++ 20:32:09 ttx: well, it's infrequent enough, I'm actually comfortable with ask mordred and lifeless 20:32:31 I think it's more scalable than trying to define a process for it with everyone honestly :) 20:32:33 I'm ok with asking lifeless and mordred as long as they agree with my view of it 20:32:33 ttx: so, this specific proposal is invalid, because its making a blanket it's-ok rule. 20:32:40 yup 20:32:52 sdague : ttx : my suggestion was that what's needed should be made available via infra (images?) and not added to *requirements.txt 20:32:52 but a blanket it's-not-ok is also not the right thing 20:32:59 ttx: we can say something like 'invoking tools that are under any OSI approved license' is ok 20:33:04 lifeless: so since it merged we should post a clarification 20:33:21 ttx: because I think both mordred and I would agree that that is always ok, as far as it goes. 20:33:35 yup 20:33:35 * rockyg thinks maybe a set of questions to answer before submitting a patch to include in test reqs? 20:33:47 its where things get into interface based derivation that it gets messy 20:33:50 right, calling tools is ok, everything else is more on a case-by-case basis of defining extension of work 20:33:54 yah 20:34:00 that would be my take as well 20:34:05 the thing that provoked this was use of a python library 20:34:12 We might want to kick Python-MySQL out then 20:34:18 and ask ourselves the question later ? 20:34:25 it has a specific carve-out 20:34:28 python-mysql has the foss exception, right? 20:34:31 which is why it's ok ... 20:34:33 right 20:34:34 libmysqlclient has the FOSS excpetion 20:34:38 and why blanket rules are hard here 20:34:39 oh right 20:34:51 yah. turns out humans are good at assessing things and applying judgement 20:34:59 we should probably add that to the # GPL comment 20:35:05 in this case, we should call out that doing so is a good idea 20:35:06 mordred: nonsense! 20:35:06 ttx : yep +1 20:35:49 I'll add a tweak to requirements and propose a licensing.rst tweak 20:35:54 i feel like there's a subtext that hasn't quite been said here... 20:35:57 lifeless, mordred: is one of you interested in proposing a new wording that outlines the OK scenario and the "we need to think about it" scenario ? 20:36:08 to make it clearer that the blanket thing there is 'running things' not 'using libraries' 20:36:08 lifeless: ++ 20:36:20 lifeless: ++ 20:36:31 mordred: (and no, I know using is the wrong word, but in the absence of better ones :)) 20:36:33 #action lifeless to propose a licensing.rst tweak 20:36:36 we could also identify a small group of people as the people that should be tagged on reviews where the licensing questions aren't clear 20:36:40 which is that 'using libraries' is maybe not ok 20:36:41 lifeless: yah yah 20:36:43 russellb: yeh 20:36:52 which is the mordred / lifeless solution 20:36:53 because it can't be solved completely with policy 20:36:57 which i'm not convinced is the case 20:36:58 russellb: ++ 20:37:27 i'm wondering, in the example of scapy -- do folks feel it's inappropriate? if so, why? 20:37:31 russellb: ++ 20:37:32 we still have no way to prevent test libs from leaking into runtime 20:37:36 jeblair: I think lifeless point is that there might be cases where using a library would in fact be a case that a derived work would be the result 20:37:46 dims: I don't see a difference between runtime and testtime 20:37:57 dims: mechanically they are identical 20:38:01 mordred: i agree it could happen. but i see a difference between runtime and testtime :) 20:38:10 jeblair: and that looking at what the library is and how it's being used is the thing that's eventually going to be the deciding factor of that 20:38:14 jeblair: I do too 20:38:16 dims: if the GPL has any relevance to Python code, the situations are identical 20:38:18 yeah, I'm not sure why we don't make a test/production distinction 20:38:22 (who's distributing the binary that results when i run a test in the gate?) 20:38:27 jeblair: but I think it's worth a specific discussion of each case 20:38:40 jeblair: becuase having the abstract discussion on it has so far been unsuccessful 20:38:41 jeblair : right 20:38:43 dhellmann: from a distribution perspective (remember, GPL is a distribution license...) 20:38:44 and it's rare enough to make the cost of discussing it low 20:38:47 mordred: ok. i can be down with that. 20:38:50 (my personal relevant example here is pylint: I wrote some openstack-specific pylint checks previously, but have nowhere to store them. Clearly derived works from pylint (GPL), but also code that is easy to mentally separate from actual regular openstack deliverables) 20:39:06 gus : ++ 20:39:09 in the specific case of scapy, I want us to check with upstream 20:39:26 lifeless: i think that's a fantastic idea. 20:39:27 GPLv2 only is identified as ASLv2 incompatible by the FSF 20:39:55 if the author of scapy is fine with our use of it, then I tihnk we have no issue 20:39:57 yeah, but "incompatible" doesn't begin to describe the nuance :) 20:40:00 yah 20:40:04 If their intent is to be incompatible, we shouldn't use it - we don't want to be the test case for 'The GPL is meaningless for Python programs' 20:40:21 lifeless: agreed 20:40:22 if their intent is to be incomptible I want to have a discussion about it 20:40:25 I mean, maybe we do - but it would be a fairly massive distraction 20:40:27 because I'm more of an ass 20:40:37 but I do think checking first is the right move 20:40:38 Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%) 20:40:45 and depending on the feedback, it might be a very quick discussion 20:40:45 I'd *love* to have that discussion, kindof. 20:40:55 #info Quick update from elections: 51Hour left, 25 projects are missing candidates (which is about 47%) 20:41:13 so hopefully we'll receive nominations and not have to appoint dozens of PTls in our next meeting 20:41:47 ++ 20:41:51 Omer has abandoned the scapy review 20:41:58 so its a bit moot 20:42:30 well, we're going to send the 'last hours' announcement to motivate ptl-less project 20:42:44 btw some PTLs did not answer at all to our emails asking them for how much rooms they wanted at the design summit, if they don't have a PTL candidate either, I propose we fastrack their removal 20:42:53 lifeless: did we succeed in killing it with bureaucracy? 20:43:07 death by review 20:43:15 ttx: heh, which ones? long list? 20:43:19 ttx: ++removal 20:43:24 ttx: ++ 20:43:25 ttx: as many as are not running PTLs? 20:43:27 russellb: no, short. 20:43:32 ttx: ++ 20:43:33 that's good to hear ... 20:43:50 Thanks to thingee for being exceptionally persistent 20:43:56 nice thingee 20:44:18 jeblair: ' 20:44:19 Following Doug Hellmann's and @lifeless' comments, I will try and find another solution.' 20:44:20 so our best guess is that most PTLs will stand again and just haven't sent in a patch? 20:44:21 Slot allocatiojn to be published tomorrow 20:44:29 jeblair: so yes, I think. 20:44:44 lifeless: can you link me to that review please? 20:44:45 openstack governance garbage collection? :) 20:44:49 annegentle: a lot submissions just drop on the last day 20:44:54 https://review.openstack.org/#/c/277893/ 20:44:55 russellb: lol 20:45:01 ttx: yah 20:45:02 russellb: that is my TC election platform 20:45:06 nice 20:45:24 no summit slots, no PTL, the reference count for this project has reached 0 and will now be removed 20:45:35 thanks 20:45:41 lifeless: that's a shame. i honestly feel there is a very good argument for using it. 20:45:42 russellb: NullPointerException 20:45:47 We got out of the way successfully, but we approved a lot of things by leaps of faith. I'd argue newton is cleanup time 20:46:12 * flaper87 likes that 20:46:16 ttx: Sounds like an 80s movie: "OpenStack Newton: It's payback time." 20:46:18 lifeless: but i also agree it's not worth having if the question is moot. 20:46:19 yes, we should protect "in OpenStack" as having some real meaning 20:46:20 ttx: yeah 20:46:21 jeblair , lifeless : my -2 was procedural there for the freeze :-/ 20:46:33 we have 15 more minutes, any topic you'd like to discuss ? 20:46:40 https://review.openstack.org/#/c/292918/ 20:46:56 we seemed to have not had a testing clause in the asserts can upgrade tag 20:47:07 which I think is an oversight we should fix up 20:47:07 dhellmann: yes, I know 20:47:31