| *** mordred has quit IRC | 04:08 | |
| *** mordred has joined #openstack-requirements | 04:10 | |
| *** coolsvap has joined #openstack-requirements | 04:34 | |
| *** ELIEWARS_03 has joined #openstack-requirements | 06:04 | |
| ELIEWARS_03 | HOLA | 06:06 |
|---|---|---|
| ELIEWARS_03 | *EN VISTO* | 06:07 |
| *** ELIEWARS_03 has left #openstack-requirements | 06:09 | |
| *** ELIEWARS_03 has joined #openstack-requirements | 06:09 | |
| *** ELIEWARS_03 has left #openstack-requirements | 06:09 | |
| *** ELIEWARS_03 has joined #openstack-requirements | 07:15 | |
| *** ELIEWARS_03 has left #openstack-requirements | 07:16 | |
| *** ELIEWARS_03 has joined #openstack-requirements | 07:16 | |
| *** ELIEWARS_03 has left #openstack-requirements | 07:16 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/requirements: Updated from generate-constraints https://review.openstack.org/364762 | 07:18 |
| *** jpena|off is now known as jpena | 07:24 | |
| *** jpena is now known as jpena|lunch | 12:02 | |
| *** jpena|lunch is now known as jpena | 13:02 | |
| openstackgerrit | Sylvain Bauza proposed openstack/requirements: Raise netaddr to a minimum of 0.7.13 https://review.openstack.org/370833 | 13:39 |
| *** mriedem has joined #openstack-requirements | 14:16 | |
| mriedem | huzzah! | 14:16 |
| mriedem | https://review.openstack.org/#/c/370833/ | 14:16 |
| mriedem | nova would like ^ for our rc1 | 14:16 |
| mriedem | basically 0 impact to our ci system | 14:16 |
| dims | mriedem : +2, will wait for tonyb | 14:21 |
| mriedem | thanks | 14:23 |
| prometheanfire | I -1 because of it's huge impact | 14:28 |
| mriedem | prometheanfire: we don't have to re-release those other things | 14:31 |
| mriedem | or i'm not sure why we would | 14:31 |
| prometheanfire | I'm not sure that's true | 14:31 |
| prometheanfire | I'd like to hear that the release team wouldn't re-release those things | 14:31 |
| prometheanfire | dhellmann: ^ | 14:31 |
| prometheanfire | and tonyb lol ^ | 14:32 |
| mriedem | the only issue i could see happening, is if this lands and then that goes into stable/newton for requirements, | 14:32 |
| mriedem | and then that syncs to projects on their stable/newton branches | 14:32 |
| mriedem | because that would be a red flag for stable/newton releases as we don't want min dep bumps in a stable branch | 14:33 |
| mriedem | and i see that stable/newton doesn't exist for the requirements repo yet.... | 14:34 |
| mriedem | so that would likely happen | 14:34 |
| mriedem | because the libs have stable/newton branches | 14:34 |
| ttx | I think we'd have to re-release to have synced constraints | 14:37 |
| ttx | if if we re-release oslo.config then it snowballs | 14:38 |
| ttx | Will sync with dhellmann when he is done commuting | 14:39 |
| *** sdague has joined #openstack-requirements | 14:40 | |
| *** bauzas has joined #openstack-requirements | 14:41 | |
| sdague | prometheanfire: why do you believe this is a huge impact? | 14:41 |
| ttx | sdague: we usually ensure common requirements in releases | 14:41 |
| sdague | we did usually ensure that | 14:42 |
| sdague | however, those values used to mean something for testing | 14:42 |
| sdague | which they don't any more | 14:42 |
| sdague | and we've told everyone to use upper-constraints | 14:42 |
| mriedem | if we cared about syncing when the server projects release, we shouldn't cut the stable branch for the libs/clients 2 weeks before the servers | 14:43 |
| mriedem | imo | 14:43 |
| prometheanfire | my understanding is that we'd have to sync the min bump out | 14:43 |
| sdague | mriedem: right, exactly that | 14:43 |
| sdague | prometheanfire: no, we really wouldn't | 14:43 |
| ttx | prometheanfire: sdague argues we don't really need to do that | 14:43 |
| mriedem | prometheanfire: it will sync out naturally | 14:43 |
| prometheanfire | this is why people want divergent requirements (which we are working on | 14:43 |
| sdague | prometheanfire: we already have that | 14:43 |
| prometheanfire | ttx: need is a strong word :P | 14:43 |
| sdague | we have libraries out there with different values | 14:44 |
| sdague | because they froze 2 weeks ago | 14:44 |
| prometheanfire | sdague: do we? | 14:44 |
| mriedem | the only issue i have is the sync is going to go into stable/newton for the libs, which means a min version bump in a stable release | 14:44 |
| mriedem | but as noted in the ML, | 14:44 |
| sdague | mriedem: sure, but it's still basically a noop | 14:44 |
| ttx | mriedem: we'll have to pass it as a .z | 14:44 |
| mriedem | people should be shipping from u-c upper bound for newton, now mins | 14:44 |
| mriedem | ttx: yeah it will have to be a known thing | 14:44 |
| mriedem | s/now/not/ | 14:45 |
| prometheanfire | should be | 14:45 |
| prometheanfire | should is a strong word | 14:45 |
| sdague | I feel like we had a process based on heuristics | 14:45 |
| sdague | but the world really changed | 14:45 |
| sdague | and now the argument is the process is right, regardless of the actual risk assessment we are talking about | 14:46 |
| ttx | sdague: we generally cargo-cult a number of things in that area, yes, because when we change and we can't remember all the problem space, we can get burnt | 14:46 |
| sdague | ttx: right, and what I'm saying is I believe if you do the actual risk assessment, this is the least risky way forward | 14:46 |
| ttx | Last time we innovated two weeks before release there was this explosion that took us 10 days to fix as you may remember. Turns yourself forver into a careful person | 14:47 |
| ttx | Now I agree that this /looks/ less risky | 14:47 |
| sdague | ttx: ok, propose to me a scenario where this causes a problem | 14:47 |
| ttx | But I'd rather think twice rather than jump in | 14:48 |
| * bauzas looking at the gap between 0.7.12 and 0.7.13 to evaluate the risk | 14:48 | |
| dims | this specific thing does look less risky, going back through time trying to think about the scenarios | 14:48 |
| mriedem | in the bug report zigo said this wouldn't be an issue for xenial since they're already using a new enough netaddr, but i'm wondering about other distros and what version of netaddr they might be shipping for newton | 14:48 |
| ttx | bauzas: it's not the gap that is the problem, it's the fact that we'd ship components with different minimums | 14:48 |
| sdague | ttx: which we already do because of when we freeze | 14:48 |
| prometheanfire | ya, 0.7.18 is what's stable here | 14:48 |
| sdague | plus all the 3rd party libraries that have different minimums | 14:49 |
| ttx | sdague: what do you mean by that | 14:49 |
| zigo | mriedem: For Debian, no pb with netaddr 0.7.18 | 14:49 |
| sdague | ttx: we have 400 packages you need to install to get openstack | 14:49 |
| prometheanfire | zigo: ltns | 14:49 |
| dims | ttx : that's what rc2 is for right? we can things if needed and match them up again | 14:49 |
| dims | s/can things/can cut things/ | 14:49 |
| sdague | saying that something will go wrong if the 100 we control don't have exact minimums, when the 300 we don't are all over the place, is non sensical | 14:49 |
| zigo | ttx: I never understood why having components with different minimums is a problem, as long as we have something co-installable. | 14:50 |
| bauzas | ttx: mmm, I see | 14:50 |
| ttx | sdague: I guess in this case the worst case scenario is we have to re-release everything | 14:50 |
| zigo | ttx: It is in fact a reality in this case that other components may not care about having an older netaddr. | 14:50 |
| mriedem | we have raised mins on some other deps in the last 2 weeks, but they look like things that wouldn't be deps of other already frozen libs | 14:50 |
| bauzas | FWIW, 0.7.12 was released 2 years ago | 14:51 |
| bauzas | so I'm seriously wondering which OS could continue to deliver it as a bare minimum | 14:51 |
| zigo | FYI, I would have seen this earlier in other releases, but I'm late for Newton because building everything on infra for the first time. | 14:51 |
| dims | bauzas : which means that we should revisit the minimums really early in the cycle | 14:52 |
| zigo | Oh, and when we're at it, I'm always amazed to see we're still supposed to use sphinx < 1.3... | 14:52 |
| zigo | I really hope this will be fixed for Ocata. | 14:52 |
| dims | prometheanfire : that's probably an action item for early ocata | 14:52 |
| zigo | That one, and psutil ... | 14:52 |
| ttx | sdague: My concern is more around installing several components with different requirements files | 14:52 |
| prometheanfire | zigo: there's a patch to raise that that's been held back | 14:53 |
| dims | action is survey the minimums across distros and versions we would like to support and fix g-r minimums | 14:53 |
| prometheanfire | and mins were suposed to be looked at this cycle too | 14:53 |
| sdague | ttx: right, and I'm saying that it's not a real concern | 14:53 |
| prometheanfire | but now we are spun up as a team so hopefully it helps | 14:53 |
| zigo | prometheanfire: Raise which one? psutil or sphinx? | 14:53 |
| dims | prometheanfire : right, agree. we failed to do that | 14:53 |
| sdague | as someone who has debugged these interactions a lot, this is a very low risk change | 14:53 |
| prometheanfire | sphinx | 14:53 |
| prometheanfire | and psutil I think | 14:53 |
| zigo | Ok. | 14:53 |
| prometheanfire | I agree that it looks low risk | 14:54 |
| prometheanfire | if the 'intrested parties' are willing to take the risk then ok | 14:54 |
| ttx | sdague: ok, I'll discuss it with dhellmann | 14:54 |
| prometheanfire | that's why I -1 it, not -2 | 14:54 |
| prometheanfire | so if requirements and release teams are willing to take it... | 14:54 |
| dims | we should probably pause for tonyb to weigh in | 14:54 |
| prometheanfire | yes | 14:54 |
| prometheanfire | should be 8ish hours | 14:55 |
| zigo | psutil 2.0.0 is from mars 2014 ... :) | 14:55 |
| prometheanfire | I know | 14:55 |
| ttx | I definitely agree it sounds low-risk and I can't make an example of how it would fail. My only reason foir resisting it is that I don't like to change the rules in the last minutes of the game | 14:55 |
| prometheanfire | zigo: https://review.openstack.org/333717 | 14:55 |
| prometheanfire | ttx: exactly | 14:55 |
| dims | zigo : when requirements ocata opens up, can you please help us fix things in g-r minimums? | 14:56 |
| prometheanfire | zigo: I had a review as well, but abandoned it since tony's is older | 14:56 |
| zigo | ttx: It has always been my view that the rules are broken to begin with, if the end result is to keep things broken. | 14:56 |
| sdague | ttx: ok, I get frustrated by holding to outdated rules instead of actually doing scenario analysis on actual risks | 14:56 |
| dims | sdague : totally hear your frustration | 14:56 |
| prometheanfire | again, formally supporting divergent reqs is something we are working on | 14:57 |
| prometheanfire | https://bugs.launchpad.net/openstack-requirements/+bug/1623571 https://etherpad.openstack.org/p/ocata-requirements-notes | 14:57 |
| openstack | Launchpad bug 1623571 in OpenStack Global Requirements "lower-constraints blueprint idea dumping ground" [Undecided,New] | 14:57 |
| prometheanfire | anyway, lets wait for releases team feedback and tony's feedback | 14:57 |
| zigo | dims: For Ocata, I'd really like us to use sphinx 1.4, but it's going to be painful, as many projects are erroring when there's only warnings. | 14:58 |
| ttx | sdague: This system is complex and has failed in unforeseen ways in the past. Or are you saying you understand it so well at this stage it can't fail in this scenario ? | 14:58 |
| ttx | I'm fine deferring to your expertise -- you certainly practice this system more often than I do | 14:58 |
| sdague | the only failure scenarios on min requirement mismatch are as follows | 14:58 |
| sdague | package a requires b >=1.1 | 14:59 |
| sdague | package c requires b >=1.2 | 14:59 |
| sdague | package a is installed and chooses 1.1 for some reason | 14:59 |
| sdague | c is installed later, and that is moved up because of the mismatch | 14:59 |
| sdague | if in that window package a has involved a started service, it will start with 1.1, and on service restart will shift forward | 15:00 |
| sdague | which is probably not actually an issue, but may see a behavior change | 15:00 |
| sdague | or if there is something really tricky with cffi in package b, the compiled version for 1.1 may not match what's in 1.2 | 15:00 |
| ttx | Only example I could make up would be of some weird deployment system that would expect requirements to be the same across everything (since it always was) and then would deploy the wrong version for nova. But that's a pretty fucked-up scenario I'll admit | 15:00 |
| prometheanfire | ya, I'm not aware of a dep system THAT broken | 15:01 |
| sdague | ttx: that means it is deploying without using pip | 15:01 |
| prometheanfire | well, ya, then there's pip... | 15:01 |
| sdague | the big issues we had before was different max versions | 15:02 |
| ttx | sdague: Also I think we only have identical requirements at release time. I think they are not 100% synced in day +1 | 15:02 |
| mriedem | yeah caps were always the big issue before | 15:02 |
| sdague | ttx: we don't though | 15:02 |
| sdague | because you can't just account for our packages | 15:02 |
| sdague | you also have to account for all the libraries and other python code we depend on | 15:03 |
| sdague | making our packages the same wasn't a 100% solution | 15:03 |
| ttx | I don't understand that point. We have global-requirements. That resolves to a set of dependencies and versions. | 15:03 |
| sdague | it was risk mitigation | 15:03 |
| zigo | sdague: Your case is with things using pip. Using packages, we don't have this problem, as only version 1.2 will be used everywhere. | 15:03 |
| ttx | Not two or three | 15:03 |
| sdague | ttx: right, but I think you incorrectly assume that it solved a bigger issue than it did | 15:03 |
| sdague | it didn't solve coinstallability | 15:04 |
| sdague | it made is so we didn't completely f- it up in code we controlled | 15:04 |
| sdague | and upper-constraints made it so we resolved to something that actually could coinstall, with g-r never actually guarunteed | 15:04 |
| ttx | No, all I'm saying is that there was a reason why we wanted requirements to be exactly synced by release time, and we cargo-culted it to this day | 15:04 |
| sdague | ttx: as risk mitagation | 15:05 |
| ttx | You're saying that the reason is no longer present | 15:05 |
| ttx | sdague: totally | 15:05 |
| ttx | risk management, to be more precise | 15:05 |
| sdague | and I'm saying this doesn't add any really incremental risk | 15:05 |
| prometheanfire | gr is just the minimums, in reality it's not that useful (except to add exclusions) | 15:06 |
| sdague | prometheanfire: right, it is the input file to set bounds on upper-constraints resolving | 15:06 |
| ttx | OK, as I said, I'll make the case to dhellmann and expect him to approve it | 15:06 |
| sdague | this change would not change that answer | 15:06 |
| prometheanfire | sdague: UC being a defacto cap :P | 15:06 |
| sdague | prometheanfire: sure | 15:06 |
| prometheanfire | ya, I'd expect this to go in, just highly irregular | 15:07 |
| ttx | Minor issue is that it forces a bump on stable/newton that should in theory be a .y bump when we only have space for .z, so we'd have to have a (new) rule to consider those .z as well | 15:07 |
| prometheanfire | and wanted more discussion before it was workflowed | 15:07 |
| sdague | ok, I'm good with conversation to make sure folks are comfortable with it. Just wanted to make sure objections were based on actual risk assessment and not just cargo cult. | 15:08 |
| ttx | I think that was the standing reasons why we did sync reqs pre-release | 15:08 |
| mriedem | ttx: i'd think the stable team would make an exception for this as a known thing | 15:08 |
| mriedem | i don't think we need new process for this in stable | 15:08 |
| mriedem | we've had exceptional minimum bumps in stable before | 15:08 |
| mriedem | moving forward, we should probably branch the libs/clients *after* the server projects | 15:09 |
| ttx | mriedem: actually we need to have some rule there (requirements change triggering .y or .z) because we are already inconsistent | 15:09 |
| mriedem | since we're doing it in the wrong direction for deps | 15:09 |
| prometheanfire | anyway, I still haven't had caffeine, so... | 15:09 |
| sdague | mriedem: that assumes deps are more important than stable testing | 15:09 |
| mriedem | ttx: in stable it's pretty cut and dried, | 15:09 |
| mriedem | you can't bump .y if that's used in the next series | 15:09 |
| sdague | I really think that min dep drift is not an issue | 15:09 |
| mriedem | and .y is already used | 15:09 |
| sdague | not with upper-constraints | 15:09 |
| ttx | sdague: should we just stop syncing them then ? | 15:11 |
| * ttx is 11 min late to a meeting | 15:11 | |
| sdague | we still need to sync the exclusions, and we still want to move the ball forward over time. But I think eventual consistency is fine | 15:11 |
| prometheanfire | minimums set exclusionary criteria | 15:12 |
| sdague | especially when we're talking about a boundary that is 2 years old | 15:12 |
| prometheanfire | alsong with != ofc | 15:12 |
| sdague | prometheanfire: sure, but it isn't the kind of change that impacts upper-constraints | 15:12 |
| sdague | if this did change uc, then we'd be talking about a radically different issue | 15:12 |
| prometheanfire | upperconstraints is just a snapshot | 15:13 |
| prometheanfire | uc changes are also easier for us to merge, we did so a couple of times in the freeze | 15:13 |
| prometheanfire | simpler because they don't change exclusionary criteria | 15:13 |
| prometheanfire | anyway, getting my caffeine now | 15:14 |
| sdague | uc changes are actually the dangerous ones those, as those change / invalidate our testing | 15:14 |
| sdague | this is so much less risky than a uc change | 15:15 |
| dhellmann | ttx, sdague, prometheanfire, mriedem : it's fine with me if we want to try to get the requirements update in place. I strongly suspect this is not the only min we have that's out of date, so I'm not sure why we need to rush it, but either way it's fine. I suggested a release note fix because that seemed easier to ensure would happen today, not because I thought there was risk in changing the min for netaddr. | 15:43 |
| dhellmann | I hope we can prioritize fixing the min settings across the board for ocata | 15:44 |
| dims | dhellmann ++ that was my suggestion as well | 15:46 |
| mriedem | dhellmann: did you say that in a review or the ML? | 15:47 |
| sdague | it just seems odd when we can actually do the real fix to not and do the reno | 15:47 |
| dhellmann | mriedem : on irc somewhere | 15:47 |
| mriedem | sdague wanted to avoid a release note in nova saying basically we know this is wrong, but we aren't fixing it for newton | 15:47 |
| dhellmann | sdague : it's fine. I didn't want nova to miss its deadline today because of this. | 15:48 |
| sdague | yeh | 15:48 |
| mriedem | personally i'm fine with just not fixing it | 15:48 |
| mriedem | and not release noting it | 15:48 |
| mriedem | and assuming people are at a high enough version that it won't impact them | 15:48 |
| sdague | well https://review.openstack.org/#/c/370833/ is jenkins +1 | 15:48 |
| mriedem | and if it does, oops | 15:48 |
| sdague | yeh, I could honestly live with that as well | 15:49 |
| mriedem | dhellmann: prometheanfire: dims: ttx: ^ | 15:51 |
| mriedem | if you guys would rather just not push, i'm cool with that and we can leave it for ocata | 15:51 |
| dhellmann | mriedem : that works for me, too | 15:51 |
| dhellmann | I like not routing around our procedures in the heat of the moment | 15:52 |
| ttx | it's just weird that we can't fix things that require requirements bump pre-release, but we can post-release | 15:52 |
| sdague | ttx: right, that ^^^ | 15:52 |
| sdague | it's like, we have this fix | 15:52 |
| prometheanfire | honestly I'm fine going either way | 15:52 |
| sdague | and we know it's fine | 15:52 |
| sdague | and it would be fine on the stable branch | 15:52 |
| ttx | i.e. we relaxed the post-release rules a lot | 15:53 |
| sdague | but in rc phase it's not | 15:53 |
| dhellmann | ttx: I'm not sure what you mean | 15:53 |
| ttx | dhellmann: I mean we are basically saying that there is a class of bugs we can't fix in RCs | 15:54 |
| sdague | ttx: more importantly, there is a class of really low risk bugs we can't fix in RCs | 15:54 |
| ttx | while I agree that we need to make tradeoffs in the last phases of the release, we are not there yet | 15:54 |
| sdague | there are definitely lots of bugs we can't fix in RCs for very solid reasons | 15:54 |
| ttx | so I'm also fine with fixing it in RC1 the way we'd fix it in 14.0.1 | 15:55 |
| ttx | but then I think it's mostly a non-issue, too :) | 15:55 |
| ttx | so we could "discover" it later | 15:56 |
| dhellmann | we've become very conservative about requirements changes during the rc period because of the amount of trouble we've had in the past. I think some of the things that caused that trouble have been addressed, so I'm OK with going ahead with this change (bump netaddr, do not re-release everything that uses it, update nova before its rc1). but I'm also comfortable saying that this isn't a big deal and not fixing it. | 15:56 |
| dhellmann | I guess I don't have a strong opinion one way or the other. | 15:56 |
| ttx | dhellmann: same. Basically this issue points to the need to change the rules. I don't like to change the rules while in RC phase | 15:57 |
| dhellmann | ttx: right, that's what I meant by "heat of the moment" earlier | 15:57 |
| ttx | so I'm 50/50 | 15:57 |
| dhellmann | prometheanfire : thoughts? | 15:58 |
| ttx | Fix it now + Change the rule now vs. Fix it post-release and change the rule in Ocata | 15:58 |
| sdague | I'm 60/40 in favor of fixing it, just because we can, and it might help 1 or 2 actual users | 15:58 |
| prometheanfire | sorry, meeting, reading now | 15:58 |
| ttx | (but I think we need to change the rule in Ocata, don't want to have the same discussion next time) | 15:59 |
| dhellmann | ttx: yes, we should talk about the rule for ocata either way | 15:59 |
| prometheanfire | I'm on the fence too, I don't think this will cause problems and will be fine to merge | 15:59 |
| prometheanfire | but I'm fine with not merging too | 15:59 |
| prometheanfire | and yes, we've already started small talks related to this for ocata | 16:00 |
| ttx | dhellmann: how likely is it going to be the only one such case ? | 16:00 |
| ttx | If we expect several, I'd rather change the rule now... next issue might not be so... ignorable | 16:00 |
| prometheanfire | we have a couple of other changes that are waiting til after we branch | 16:00 |
| ttx | If we think it's likely the only such one, let's wait | 16:01 |
| prometheanfire | there are 3-4 changes to gr that were delated | 16:01 |
| prometheanfire | delayed | 16:01 |
| ttx | Feels like an oslo.db bump will make all that shallow | 16:02 |
| prometheanfire | ya, that's one (though people still seem to be arguing about it) | 16:02 |
| ttx | dhellmann: I'm 51% on approving it now and let it be eventually consistent | 16:03 |
| prometheanfire | oslo.log is one | 16:03 |
| prometheanfire | zigo: https://review.openstack.org/365253 | 16:03 |
| prometheanfire | keystonemiddleware is another | 16:04 |
| prometheanfire | anyway, I'm fine with the merge, but believe that tony should have a say | 16:04 |
| prometheanfire | mriedem: can you wait til he's in? | 16:04 |
| dhellmann | ttx: I don't have any other cases in mind, I just know we've seen a few this week and I think that means we've not been good about keeping the mins up to date at all. | 16:04 |
| mriedem | prometheanfire: i'll be around when tonyb is if he's going to be 'the decider' | 16:07 |
| dhellmann | I have to give up my lunch table for the rush, so I'm going to move across the street to the coffee shop. brb. | 16:07 |
| prometheanfire | mriedem: he has a new title now :D | 16:07 |
| ttx | That all-requirements-synced constraint is painful to handle and if additions are kept under control, very probably useless | 16:07 |
| mriedem | http://www.azquotes.com/picture-quotes/quote-i-m-the-decider-and-i-decide-what-is-best-george-w-bush-64-47-33.jpg | 16:08 |
| prometheanfire | ttx: as far as keeping lower-requirements (what gr basicly is) in sync and up to date goes, we have a plan | 16:08 |
| prometheanfire | mriedem: exactly | 16:08 |
| prometheanfire | ttx: https://bugs.launchpad.net/openstack-requirements/+bug/1623571 | 16:08 |
| openstack | Launchpad bug 1623571 in OpenStack Global Requirements "lower-constraints blueprint idea dumping ground" [Undecided,New] | 16:08 |
| prometheanfire | ttx: basically, each project would keep it's own lower-constraints test, global requirements would just be the lowest lower requirement + any exclusions | 16:11 |
| prometheanfire | an upper-lower-constraints file could be useful to packagers for providing a globale min as well | 16:11 |
| prometheanfire | gr would mostly be recordkeeping at that point | 16:12 |
| ttx | prometheanfire, mriedem: I think we should just make the call now, waiting makes me want to defer it anyway | 16:19 |
| prometheanfire | ok | 16:19 |
| dhellmann | yeah, I concur | 16:19 |
| prometheanfire | merge++ | 16:19 |
| ttx | requirements are frozen to accomodate the release team and the release team says ok | 16:19 |
| dhellmann | it seems we're all either on the fence or softly in favor of going ahead with the update? | 16:19 |
| prometheanfire | seems so | 16:20 |
| dhellmann | yeah, I'll go approve that requriements change | 16:20 |
| ttx | I'm slightly in favor of approving if we can approve it now | 16:20 |
| dhellmann | prometheanfire : do you want to +2 it as well? | 16:20 |
| prometheanfire | I will | 16:20 |
| ttx | If we wait tomorrow, then I'm in 51% in favor of pretending we never spotted the bug | 16:20 |
| prometheanfire | lol | 16:20 |
| prometheanfire | +W'd | 16:21 |
| ttx | % increase with every day until release day | 16:21 |
| ttx | I can get pretty blind by the time we reach release | 16:21 |
| ttx | a bug ? Nooooo | 16:21 |
| dhellmann | mriedem, sdague : we're going ahead with the netaddr change. I'll leave it to you to watch the g-r update and handle nova. | 16:23 |
| mriedem | dhellmann: we already have the nova change lined up with depends-on | 16:23 |
| mriedem | so ok | 16:23 |
| prometheanfire | sosayweall :D | 16:26 |
| dhellmann | would everyone please look over my email summary to the list and ensure I didn't get anything wrong or miss anything? | 16:27 |
| prometheanfire | when it comes through | 16:27 |
| ttx | looking | 16:27 |
| ttx | waiting | 16:28 |
| dhellmann | http://lists.openstack.org/pipermail/openstack-dev/2016-September/103784.html | 16:29 |
| dhellmann | sorry, forgot to post the link | 16:29 |
| prometheanfire | lgtm | 16:30 |
| *** jpena is now known as jpena|off | 17:10 | |
| sdague | dhellmann: sounds good, thank you | 17:31 |
| sdague | and thanks everyone here | 17:31 |
| *** david-lyle has quit IRC | 19:40 | |
| *** david-lyle has joined #openstack-requirements | 19:40 | |
| openstackgerrit | Merged openstack/requirements: Raise netaddr to a minimum of 0.7.13 https://review.openstack.org/370833 | 20:13 |
| dims | dhellmann : +1 from me | 20:20 |
| dhellmann | dims : thanks | 20:28 |
| prometheanfire | it's about time for tonyb to wake up :P | 20:29 |
| * dims sends tonyb some strong coffee to help him catchup | 20:29 | |
| amrith | dims, I'd like some too | 20:32 |
| * dims hands amrith a big carafe | 20:52 | |
| amrith | thank you dims, that hit the spot. | 21:00 |
| * tonyb doesn't like the looks of that scrollback :( | 21:13 | |
| amrith | did you drink your coffee? | 21:15 |
| prometheanfire | lol | 21:24 |
| prometheanfire | don't think that'll help much | 21:25 |
| prometheanfire | tonyb: the mailing list is a better summary | 21:26 |
| tonyb | amrith: No :( in a nova meeting then school run | 21:27 |
| amrith | hmm, a problem not solved by coffee. Need a stronger solution but it isn't that time (yet). | 21:29 |
| prometheanfire | espresso | 21:33 |
| tonyb | prometheanfire: I only drinnk double espressos at home | 21:33 |
| amrith | solution, don't be at home :) | 21:34 |
| tonyb | mriedem: Are you goign to be around in a about 90mins? to talk thought the netarr/os-vif (and maybe oslo.db) reviews? | 21:34 |
| mriedem | tonyb: i'll be on tonight....but might be heading home soon | 21:35 |
| tonyb | mriedem: okay. that'll give me time to catch up | 21:35 |
| dhellmann | tonyb : I'm around for a while, too. our meetup should be starting in ~1 hr | 21:45 |
| *** amit213 has quit IRC | 21:47 | |
| *** jhesketh has quit IRC | 21:47 | |
| prometheanfire | I trink too much coffee | 21:48 |
| *** jhesketh has joined #openstack-requirements | 21:49 | |
| *** amit213 has joined #openstack-requirements | 21:51 | |
| *** mriedem has quit IRC | 21:58 | |
| tonyb | dhellmann: Thanks. | 22:17 |
| *** number80 has quit IRC | 22:50 | |
| *** sdague has quit IRC | 22:52 | |
| *** mriedem has joined #openstack-requirements | 23:10 | |
| mriedem | tonyb: i'm around | 23:10 |
| mriedem | sort of | 23:10 |
| *** number80 has joined #openstack-requirements | 23:12 | |
| prometheanfire | as much as any of us can be 'around'? | 23:24 |
| *** armax has quit IRC | 23:37 | |
| *** armax has joined #openstack-requirements | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
