| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-16 | |||
| 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 | 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: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: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. | |
| 15:20:07 | mdbooth | kashyap: What have you changed? | |
| 15:20:37 | mdbooth | kashyap: pastebin your local diff | |
| 15:20:48 | kashyap | Fixing the fall out of bumping versions: https://review.openstack.org/#/c/558783/ | |
| 15:21:18 | mdbooth | kashyap: I'll fire it up locally | |
| 15:21:31 | kashyap | mdbooth: Then, wait -- let me post the merge-conflict fixed series | |
| 15:22:40 | mdbooth | I can't pull it right now | |
| 15:23:36 | kashyap | Yeah, it's merge conflict; I fixed it this morning locally. Pushing the new rev in a couple. I'll notify | |
| 15:23:51 | efried | kashyap: Note that takashin is doing a whole slew of patches to remove mox. | |
| 15:24:13 | kashyap | efried: So, he'll be replacing it w/ Mock, is it? | |
| 15:24:36 | efried | kashyap: Yes. There's a bp for that, so I'm sure he would welcome the help if you'd like to propose a "fix" for this problem that happens to swap out mox for mock. | |
| 15:25:09 | efried | kashyap: https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/mox-removal | |
| 15:25:29 | kashyap | efried: I'll see about it. Python unit tests is one my Python weakness area | |
| 15:25:47 | kashyap | First trying to remove all the now-needless compat code due to the version bumps | |
| 15:26:10 | efried | kashyap: No pressure :) | |
| 15:27:39 | kashyap | Thanks for the (non-null) pointer | |
| 15:28:28 | mdbooth | efried kashyap: I'd recommend against mixing those 2 changes, though. | |
| 15:28:41 | kashyap | mdbooth: Yeah, I'm strictly following the "One logical change per patch" | |
| 15:28:43 | kashyap | No madness | |
| 15:28:58 | kashyap | But appreciate the reminder :-) | |
| 15:29:28 | mdbooth_ | kashyap: Don't know if ^^^ sent, but I recommend against mixing those 2 changes. | |
| 15:29:53 | kashyap | mdbooth_: Yep, got sent. And then I wrote: < kashyap> mdbooth: Yeah, I'm strictly following the "One logical change per patch" rule | |
| 15:30:06 | cfriesen | mriedem: M0z122: I think this was the last time I tried to push LVM resize/migration upstream: https://review.openstack.org/#/c/337334/ | |
| 15:31:53 | mdbooth_ | cfriesen: Aside: do you get a performance benefit from lvm? | |
| 15:32:05 | openstackgerrit | Merged openstack/nova master: Add config drive link to api-guide https://review.openstack.org/561113 | |
| 15:32:54 | cfriesen | mdbooth_: last time we checked, I think there was a difference, but I don't know that we've checked in a while. Have you seen more recent benchmarks? | |
| 15:33:23 | mdbooth_ | cfriesen: No, but I vaguely recall that it was marginal at best. | |
| 15:33:32 | mdbooth_ | cfriesen: Over raw, that is. | |
| 15:33:56 | mdbooth_ | Just wondering if you had data which showed it's worth the bother. | |
| 15:34:00 | M0z122 | cfriesen: many thks will have a look on it | |
| 15:35:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Add DifferentHostFilter to enabled_filters default https://review.openstack.org/561651 | |
| 15:37:12 | mdbooth_ | cfriesen: Intuitively, I'd expect that if you fallocate a raw file which isn't fragmented and open it O_DIRECT, all of which I think we do, the performance should be the same as LVM, as the kernel is basically doing the same in both cases. | |
| 15:38:41 | mdbooth_ | cfriesen: Numbers beat intuition of course, though :) | |
| 15:52:57 | Nisha_Agarwal | Hi team, I have 2 stable pike devstack setups- one stacked last week on a freshly imaged system and another stacked around a month ago. When i was trying "nova boot" for ironic nodes on both the setups i land up in this error http://paste.openstack.org/show/719143/ due to which it send the "delete" event to ironic node as soon as it goes to "wait-call-back" state. On debugging we found that it happens because instance's context is set to | |