| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-08 | |||
| 12:54:12 | finucannot | efried: https://github.com/tox-dev/tox/issues/425#issuecomment-285941532 | |
| 13:21:41 | fried_rice | finucannot: looking... | |
| 13:21:58 | finucannot | fried_rice: tl;dr: tox devs recognize it as an open bug | |
| 13:22:08 | finucannot | but that still doesn't help us right now, unfortunately :( | |
| 13:30:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441 | |
| 13:30:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add InstanceNUMANetworkInfo object https://review.openstack.org/564442 | |
| 13:30:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443 | |
| 13:30:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add 'create_resource_requests' to network API https://review.openstack.org/564444 | |
| 13:30:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add '_get_network_tunnel_status' https://review.openstack.org/564445 | |
| 13:30:15 | fried_rice | finucannot: Thanks for that. | |
| 13:32:43 | fried_rice | finucannot: So what seems reasonable to me is: | |
| 13:32:43 | fried_rice | For tox.inis that have explicit sections for the auto envs, set basepython=python3 in [testenv] and set basepython=<exact_x.y_version> in the explicit sections. | |
| 13:32:43 | fried_rice | For tox.inis that don't have sections for the auto envs, do the thing we've been doing, but add a TODO in the [testenv] section saying: | |
| 13:32:43 | fried_rice | # TODO: put basepython=python3 here and remove from individual envs once https://github.com/tox-dev/tox/issues/425#issuecomment-285941532 is fixed. | |
| 13:34:42 | finucannot | I noted it on some random review, but I'd be happy just to do the latter for everything. It hardly seems worth the effort to be have to think about this stuff | |
| 13:35:07 | finucannot | *but* if it annoys you, the above makes sense :) | |
| 13:36:39 | fried_rice | finucannot: Unnecessary repetition is just a serious bugbear for me | |
| 13:37:14 | giblet | is it just me or the gate suffers ? http://grafana.openstack.org/dashboard/db/zuul-status | |
| 13:37:33 | finucannot | giblet: All the -2s? Yeah, I've been seeing that too | |
| 13:37:39 | fried_rice | finucannot: Am I -1 on any of them at the moment? Cause the other option is for me to just back away and let others approve these. Because as you say, it's not the end of the world. | |
| 13:38:09 | finucannot | fried_rice: Just the nova one, iirc? | |
| 13:38:35 | giblet | finucannot: looking at the test nodes graph on that dashboard shows that everything stuck | |
| 13:39:11 | fried_rice | finucannot: The nova one has explicit sections for the auto envs. So we could do that first thing I mentioned. (With comments saying "this can be removed once issue XXX is fixed". | |
| 13:39:12 | fried_rice | ) | |
| 13:39:27 | finucannot | giblet: Looks like fungi and co have noticed it already, if #openstack-infra is to be believed | |
| 13:39:41 | giblet | finucannot: ohh, thanks | |
| 13:39:54 | finucannot | fried_rice: Yup, agreed. I think I said as much in the review | |
| 13:40:03 | finucannot | Just a matter of who's going to do it | |
| 13:40:06 | giblet | finucannot: I only checked the infra status wiki | |
| 13:40:35 | fried_rice | finucannot: okay, I just got here (long story), haven't caught up on my gerrit overnight yet. I'd be happy to make that change. | |
| 13:40:44 | fungi | apparently an ubuntu security update for unbound (the local caching resolver we run on all our servers) failed to successfully restart on many of our zuul executors and so they spontaneously ceased being able to resolve any dns names | |
| 13:40:59 | fried_rice | Is that bad? | |
| 13:41:12 | fungi | the only real downside to unattended security upgrades | |
| 13:41:27 | fried_rice | Hey, it's secure at least. | |
| 13:41:37 | fungi | securely broken :/ | |
| 13:41:46 | jroll | every service is secure when it doesn't run :P | |
| 13:41:51 | fungi | anyway, fixed now and yes, thanks for the reminder that we didn't log that giblet | |
| 13:42:43 | giblet | fungi: thanks for working on the issue :) | |
| 13:48:04 | fungi | giblet: sure, it was mostly frickler and ianw who figured it out and fixed it | |
| 13:48:18 | fungi | but you're welcome nonetheless | |
| 13:53:58 | openstackgerrit | Merged openstack/python-novaclient master: fix tox python3 overrides https://review.openstack.org/573347 | |
| 13:58:55 | openstackgerrit | Eric Fried proposed openstack/nova master: fix tox python3 overrides https://review.openstack.org/572974 | |
| 13:58:59 | fried_rice | finucannot: ^ | |
| 14:00:11 | finucannot | fried_rice: done. Cheers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;0 | |
| 14:00:20 | finucannot | lovely | |
| 14:00:31 | mdbooth | finucannot: Was that an attempt at buffer overflow? | |
| 14:01:41 | finucannot | mdbooth: Notifications cause my screen to lock up for an indeterminate period. No idea what's wrong :( | |
| 14:12:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678 | |
| 14:12:06 | openstackgerrit | Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958 | |
| 14:12:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405 | |
| 14:12:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 14:12:10 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 14:14:27 | fried_rice | kashyap: libvirt isn't the only hypervisor, dude. | |
| 14:14:50 | kashyap | But there are other "hypervisor dudes" here too | |
| 14:16:03 | fried_rice | kashyap: Nothing to scroll, referring to the >26 volumes discussion on the ML. | |
| 14:16:26 | fried_rice | kashyap: Your response reads like "Well, because this libvirt-specific thing handles 256, we should make the limit 256." | |
| 14:16:27 | kashyap | fried_rice: Err, sorry. I misread your comment :-) | |
| 14:17:04 | kashyap | Hmm, true, I didn't mean it to imply that way. | |
| 14:17:06 | fried_rice | kashyap: Sorry, it's a sore point for me. | |
| 14:17:13 | kashyap | No, no. It's completel fine. | |
| 14:17:28 | kashyap | I'm interested in data from other hypervisors too. Can those just chime in? | |
| 14:17:40 | fried_rice | kashyap: I appreciate how thoroughly you thought through and researched. | |
| 14:17:58 | kashyap | I just meant to share whatever data I have from a libvirt PoV. Didn't mean to say this is all "cut and dried". | |
| 14:18:10 | fried_rice | kashyap: Yeah, I pestered the relevant folks from my team yesterday to respond to that. We have scenarios where IBMi customers on POWER stripe data across literally hundreds of volumes. | |
| 14:18:23 | fried_rice | I'll fup and bug them again. | |
| 14:18:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443 | |
| 14:18:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add 'create_resource_requests' to network API https://review.openstack.org/564444 | |
| 14:18:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Retrieve tunneled status in '_get_network_info' https://review.openstack.org/564445 | |
| 14:19:56 | kashyap | fried_rice: I see, interesting. I don't have access to POWER machine, so certainly I don't know its limitations | |
| 14:20:02 | kashyap | (Or capabilities) | |
| 14:20:29 | kashyap | fried_rice: Also how is I/O performance across those many 100s of volumes? | |
| 14:20:30 | fried_rice | kashyap: Oh, nobody does, that's totally understandable :) | |
| 14:20:56 | fried_rice | kashyap: As I understand it, they did that striping specifically to achieve better performance. So it must be... good. | |
| 14:21:05 | fried_rice | kashyap: But I'm not the expert there. | |
| 14:21:23 | kashyap | (I suggested 256 as a potential number after looking through Kernel threads this morning, and all that testing done by the libguestfs folks.) | |
| 14:21:45 | kashyap | fried_rice: I see. I'll check with some RHT folks have access to POWER machines | |
| 14:23:45 | fried_rice | kashyap: my SME says he wants the max to be 4k :) | |
| 14:24:03 | kashyap | fried_rice: Ask them to respond with a bit more detail, please :-) | |
| 14:24:04 | mriedem | dansmith: this is for you https://review.openstack.org/#/c/490015/ | |
| 14:24:17 | fried_rice | kashyap: Yeah, I'm doing that. For some reason my guy didn't see the thread originally. | |
| 14:24:22 | dansmith | mriedem: oh boy! | |
| 14:24:50 | fried_rice | kashyap: I may wind up having to proxy his response. But one way or another we'll get it out there :) | |
| 14:24:55 | mriedem | osc didn't have host-evacuate-live so someone wants to add it | |
| 14:25:19 | dansmith | we really really should avoid more name confusion | |
| 14:25:40 | kashyap | fried_rice: Sure, noting on his behalf is fine. Just understanding the requirements of different hypervisors. If it's not too unpalatable ... we can even conditionalize based on hypervisor? | |
| 14:26:00 | fried_rice | host-evacuate-live. To me, that means "clear out this host by live-migrating all the instances off of it". So that must not be what it does. | |
| 14:26:30 | fried_rice | kashyap: That sounds like the right approach to me, and is what dansmith expressed as his first preference as well. | |
| 14:26:48 | kashyap | fried_rice: Oh, I didn't see his response yet. | |
| 14:30:34 | melwitt | mriedem, dansmith: I dunno if y'all saw but I added a -W to this https://review.openstack.org/569923 last night to signal that it's legit failing at least the xenserver, hyperv, and vmware third party CIs. so it seems there's some coordination we need to do there | |
| 14:32:20 | melwitt | oh, the tempest change that disables the virtual interfaces tests hasn't merged yet, that would explain it https://review.openstack.org/571556 | |
| 14:32:32 | melwitt | I didn't notice that last night | |
| 14:36:35 | mriedem | dansmith: yup hence my -1 on the change | |
| 14:36:43 | dansmith | mriedem: yup | |
| 14:36:50 | mriedem | fried_rice: that's exactly what it does | |
| 14:36:57 | fried_rice | holy shit! | |
| 14:37:46 | mriedem | melwitt: the 3rd party CIs must not be honoring depends-on | |
| 14:37:58 | fried_rice | I know ^ is true for powervm ci. | |
| 14:38:19 | melwitt | mriedem: yeah, I didn't realize there was possibility of it working differently and not honoring | |
| 14:38:20 | fried_rice | uh, sorry, we get it for zuul but not for tox? Or something. | |
| 14:54:05 | pvc | hi | |