| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-16 | |||
| 11:34:04 | openstackgerrit | Matthew Booth proposed openstack/nova master: Pass disk_info dict to libvirt_info https://review.openstack.org/529329 | |
| 11:34:05 | openstackgerrit | Matthew Booth proposed openstack/nova master: Expose volume host type and path independent of libvirt config https://review.openstack.org/530786 | |
| 11:34:06 | openstackgerrit | Matthew Booth proposed openstack/nova master: Don't generate fake disk_info in swap_volume https://review.openstack.org/530787 | |
| 11:34:07 | openstackgerrit | Matthew Booth proposed openstack/nova master: Local disk serial numbers for the libvirt driver https://review.openstack.org/529380 | |
| 12:04:06 | cdent | welcome back gibi, hope you had a great honeymoon | |
| 12:22:23 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/543569 | |
| 12:30:58 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: Refactor a test method including 3 test cases https://review.openstack.org/561603 | |
| 12:30:59 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/561604 | |
| 12:37:10 | gibi | cdent: thanks! We had a great honeymoon indeed | |
| 12:37:17 | cdent | \o/ | |
| 12:38:55 | efried | Say, anyone been after the gate yet this morning? I noticed it started failing pretty consistently on Friday (of course). | |
| 12:41:31 | efried | cdent: You know things about grenade, yah? | |
| 12:41:36 | cdent | efried: there's discussion on os-dev related to neutron and requirements handling breaking the gate | |
| 12:41:42 | cdent | so I think it is being worked on already | |
| 12:41:46 | efried | oh, okay. | |
| 12:41:50 | efried | So it's not nova's fault? | |
| 12:42:35 | cdent | as far as I was able to discern, no | |
| 12:42:49 | efried | k, I guess I'll just wait, then. | |
| 12:46:25 | openstack | Launchpad bug 1763966 in grenade "python-psutil dependency error on ubuntu 16.04.4" [Undecided,New] | |
| 12:46:25 | cdent | efried: this is at least one of the bugs: https://bugs.launchpad.net/devstack/+bug/1763966 | |
| 12:47:30 | efried | ack | |
| 12:51:52 | bauzas | efried: yet again working on my NUMA spec | |
| 12:52:04 | efried | mhm | |
| 12:52:21 | bauzas | efried: tbh, I need to look again at your own group spec | |
| 12:53:11 | bauzas | yeah I'm looking at it now | |
| 12:56:57 | bauzas | efried: /me trying to understand https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/granular-resource-requests.html#requirement-3 | |
| 12:57:37 | efried | bauzas: You should note that jaypipes has proposed an amendment which appreciably changes things: https://review.openstack.org/#/c/560974/ -- but if I have my way, that delta will die a fiery death. | |
| 12:58:38 | efried | bauzas: requirement 3 is saying that we want to be able to land our instance even if it means spreading VCPU resources across multiple NUMA nodes because we're reaching a point where they're getting pretty full and we can't fit all of them on one. | |
| 12:59:49 | bauzas | efried: what I don't understand is, if I have a tree with for example a RP, and then a child RP passing VGPU resources, would I still have the compute UUID RP being accepted if I'm saying some unnumbered group, like resources:VCPU=1&VGPU=1 ? | |
| 13:00:19 | bauzas | or do I need to ask for resources1:VCPU=1&resources2:VGPU=1 ? | |
| 13:00:32 | LAKUNI1 | ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss | |
| 13:00:53 | artom | snek! | |
| 13:01:16 | efried | bauzas: In that situation, either one would be fine. | |
| 13:01:26 | bauzas | efried: because atm, the main RP is having VGPU inventories, but after my implementation, it would have a nested RP which would only pass VGPU | |
| 13:01:36 | bauzas | efried: ok cool then | |
| 13:01:48 | bauzas | efried: then why people should care about numbered req groups ? | |
| 13:02:03 | efried | bauzas: Because let's say for example you want two VFs on different networks. | |
| 13:02:21 | efried | Networks are represented by traits on the PF RPs. | |
| 13:02:39 | efried | We don't allow you to say resources=VF:1,VF:1 | |
| 13:03:08 | bauzas | aha, I see it written The semantic for the (single) un-numbered grouping is unchanged. That is, it may still return results from different RPs in the same tree (or, when “shared” is fully implemented, the same aggregate). However, a numbered group will always return results from the same RP. This is to satisfy Requirement 2. | |
| 13:04:23 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: only increment disk address unit for scsi devices https://review.openstack.org/561196 | |
| 13:04:30 | bauzas | efried: ok, so, resources:VGPU:1,VCPU=1 is identical to resources1:VGPU=1&resources2:VGPU=1 but *not equivalent to* resources1:VGPU=1,VCPU=1 | |
| 13:04:59 | bauzas | because if you're passing multiple resource classes to the same numbered group, then they need to be in the same RP | |
| 13:05:01 | bauzas | right? | |
| 13:05:03 | efried | bauzas: With the spec as written, that's correct. With jaypipes' amendment, those would be very different. | |
| 13:05:17 | bauzas | argh | |
| 13:05:19 | efried | Sorry, that was confusing. | |
| 13:05:39 | bauzas | efried: https://review.openstack.org/#/c/560974/1/specs/rocky/approved/granular-resource-requests.rst@34 right? | |
| 13:05:49 | bauzas | the conf option that would modify the behaviour ? | |
| 13:05:55 | bauzas | I'm not sure I like that | |
| 13:07:42 | efried | The conf option would allow you to specify resource classes in the spec that allow their units to be spread across multiple RPs, when specified in the un-numbered request group. | |
| 13:08:37 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Numbered request groups use different providers https://review.openstack.org/560974 | |
| 13:08:40 | efried | bauzas: I think jaypipes was trying to satisfy the "spread" use case. So you would put VCPU in that conf option, and then you could say resources=VCPU:4, and placement would *first* try to fit all the VCPUs on one RP, but if it couldn't, it would then try to do 2 and 2, and then 1,1,1,1 | |
| 13:08:59 | bauzas | efried: I see | |
| 13:09:19 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/pike: only increment disk address unit for scsi devices https://review.openstack.org/561611 | |
| 13:09:24 | jaypipes | efried: sorry, just pushed up a new rev on that. didn't change much, though. | |
| 13:09:30 | bauzas | efried: I'm rushing to upload my spec so we could be discussing about that | |
| 13:10:06 | efried | jaypipes: ack. I was just responding to cdent's comments... | |
| 13:10:36 | jaypipes | efried: yup, I responded to both you and cdent on the last revision review. | |
| 13:11:20 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/ocata: only increment disk address unit for scsi devices https://review.openstack.org/561613 | |
| 13:19:02 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 13:19:52 | bauzas | efried: jaypipes: you could be interested in ^ | |
| 13:20:14 | jaypipes | bauzas: s/could/will/ | |
| 13:20:29 | efried | ack | |
| 13:29:43 | M0z122 | Hi there, | |
| 13:29:59 | M0z122 | I'm interested in LVM backed instances, But it seems that cold migrate,live-migration,live snapshoting, resize are not implemented when images_type == lvm. Do you know if there are any onging dev on this, or any plan to dev it ? | |
| 13:40:27 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/561604 | |
| 13:43:24 | mriedem | M0z122: cfriesen has code for that i believe | |
| 13:51:54 | openstackgerrit | Merged openstack/nova master: Fix doc link for api https://review.openstack.org/561499 | |
| 13:52:21 | dansmith | mriedem: should we be holding off on approvals for the current fails? seems to have hit everything I've looked at this morning already | |
| 13:53:30 | efried | dansmith: Doc-only fixes are kosher :) ---^ | |
| 13:53:46 | dansmith | ...yeah, and/ | |
| 13:54:39 | openstack | Launchpad bug 1763966 in devstack "python-psutil dependency error on ubuntu 16.04.4" [Critical,Fix released] - Assigned to hongbin (hongbin034) | |
| 13:54:39 | efried | dansmith: cdent was telling me earlier we think this has something to do with neutron and requirements, with this being one of the culprits: https://bugs.launchpad.net/devstack/+bug/1763966 | |
| 13:54:56 | dansmith | efried: right I know, | |
| 13:54:57 | efried | not nova-specific, beind discussed in #openstack-dev | |
| 13:55:00 | dansmith | I know | |
| 13:55:01 | efried | okay. | |
| 13:55:07 | dansmith | I'm asking if it's 100%, because I assume it is, | |
| 13:55:14 | dansmith | thus no reason to send anything into recheck or the gate | |
| 13:55:16 | efried | It seems to be. Except for doc fixes. | |
| 13:55:17 | efried | Right. | |
| 13:56:04 | mriedem | master is fine | |
| 13:56:05 | efried | dansmith: So yeah, you should hold off +A on the zvm series. | |
| 13:56:17 | efried | but only til the gate is fixed | |
| 13:56:29 | mriedem | https://review.openstack.org/#/q/I8bf80efc04883cd754c19bea0303064080112c6e | |
| 13:56:56 | dansmith | oh as of an hour ago, okay | |
| 13:57:00 | efried | oh, okay, cool. | |
| 13:57:06 | dansmith | all the ones I'm looking at were before that | |
| 13:59:22 | edleafe | Scheduler subteam meeting in 1 minute in #openstack-meeting-alt | |
| 14:12:03 | M0z122 | mriedem: thanks, will ask to cfriesen | |
| 14:26:02 | openstackgerrit | Merged openstack/nova-specs master: Spec for isolating configuration of placement database https://review.openstack.org/552927 | |
| 14:33:02 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Stop printing flavor details on successful flavor-delete https://review.openstack.org/561634 | |
| 14:51:30 | kosamara | Hi mriedem, I've updated https://review.openstack.org/#/c/555861/ Can you take a look if you have the time? | |
| 14:52:28 | mriedem | i'll put it in the browser tab queue | |
| 15:13:41 | kashyap | Hi folks, wonder if anyone has time to look at why is 'mox' raising UnexpectedMethodCallError with this unit test: http://paste.openstack.org/show/719304/ | |
| 15:14:20 | kashyap | I posted two code fragments the test points to (from guest.py & driver.py in nova/libvirt) | |
| 15:18:17 | kashyap | mdbooth: Wonder if you have a minute to look at the above (read prior 3 lines of scroll for context)? Last I recall, you made the change to that surrounding code. :-) | |
| 15:19:33 | kashyap | mdbooth: So, that UnexpectedMethodCallError is raised when "if a method is called with incorrect parameters, or out of the specified order". | |
| 15:19:46 | kashyap | Neither is the case, from my reading. | |