| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-09 | |||
| 11:32:07 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add microversion 2.67 to support volume_type https://review.openstack.org/606398 | |
| 11:46:22 | openstackgerrit | Merged openstack/nova master: Move test.nested to utils.nested_contexts https://review.openstack.org/608416 | |
| 12:41:19 | pooja_jadhav | Hi team, anyone help me in the https://github.com/openstack/nova/blob/85b36cd2f82ccd740057c1bee08fc722209604ab/nova/tests/functional/api_sample_tests/test_simple_tenant_usage.py#L85-L93.. When we run test name "test_get_tenants_usage" and passed instance_uuid_1 in the query. If we check the instances in simple tenant usages controller. we can see instance-2 object data in the instances list. If we pass instance-2 in query then in the | |
| 12:41:20 | pooja_jadhav | instances we can see instance-3. So how actually its working? | |
| 12:45:32 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Fix os-simple-tenant-usage result order https://review.openstack.org/608685 | |
| 12:49:29 | bauzas | mnaser: sean-k-mooney: sorry was afk | |
| 12:50:13 | bauzas | mnaser: thanks for the proposal, but unfortunately, AFAIK, k80 devices aren't supported by nvidia for vGPUs | |
| 12:51:28 | bauzas | gibi: saw your thread, I need proper time to read it and reply to it | |
| 12:55:37 | gibi | bauzas: sure it needs time. The reason for the mail was to summarize the problem as it is pretty hard for solve it consistently without seeing every corner of it | |
| 13:02:09 | stephenfin | dansmith: What's the by-service approach you refer to here? https://review.openstack.org/#/c/608703/ (link to a spec/commit is good) | |
| 13:32:19 | dansmith | stephenfin: did you see the link to the bug? | |
| 13:32:45 | dansmith | stephenfin: regardless, as I said, I think mentioning the discover step (whether by service or regular) in the devstack docs is the right thing to do | |
| 13:33:18 | stephenfin | Yup, that's the plan. Didn't click the bug link though. Will do now | |
| 13:33:29 | stephenfin | Well, soon as I'm done with downstream fun | |
| 13:47:06 | efried | gibi: Can you help me understand some basics of selecting a destination host during evac/migrate? | |
| 13:51:03 | efried | or dansmith bauzas | |
| 13:51:15 | efried | You can specify a host without the force flag and we'll run GET /a_c, right? | |
| 13:51:18 | dansmith | efried: I'm not sure what you're asking.. it's not really any different | |
| 13:51:33 | dansmith | yeah, IIRC | |
| 13:51:42 | dansmith | only the force flag makes us totally skip I think | |
| 13:51:48 | efried | And then what happens if the GET /a_c returns no candidates for the requested host? | |
| 13:51:58 | efried | Do we fail or do we select a different host? | |
| 13:53:31 | dansmith | we should fail | |
| 13:53:42 | dansmith | lemme find a thread to pull | |
| 13:55:45 | dansmith | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L983-L995 | |
| 13:56:12 | dansmith | schedule with a single host in the destination field.. if we get back novalidhost, we error the migration | |
| 13:58:08 | efried | So what use was the force flag ever supposed to be? Literally an optimization to avoid running some code, but behaviorally/algorithmically no difference? | |
| 14:00:18 | efried | Because in theory since we're using placement now, which is fast, that optimization buys us almost nothing. So if ^ is true, the force flag is basically obsolete anyway. | |
| 14:02:08 | mriedem | i can field this one... | |
| 14:02:21 | mriedem | efried: before the force flag, specifying a host at all bypassed the scheduler, | |
| 14:02:49 | mriedem | then a microversion was added which made passing a host go through the scheduler for validation, but apparently at least one person though we should preserve the ability to bypass the scheduler, so the force flag was added to do that backdoor | |
| 14:03:11 | efried | What was the motivation to "bypass the scheduler"? Because it was inefficient? | |
| 14:03:53 | mriedem | idk, i'm assuming to oversubscribe a host just to move things around | |
| 14:03:58 | mriedem | at least temporarily | |
| 14:04:10 | efried | is oversubscribe even possible at this point? | |
| 14:04:23 | efried | (Outside of allocation ratio, which doesn't count) | |
| 14:04:37 | mriedem | i don't think so, at least not for vcpu/ram/dis | |
| 14:04:38 | mriedem | *disk | |
| 14:04:52 | mriedem | as i noted in gibi's patch - we broke that in pike when force still goes through claiming resource allocations in conductor | |
| 14:04:54 | sean-k-mooney | efried: if it bypassed the scduer it proably bypassed the placement claim too but i have never check that | |
| 14:05:05 | mriedem | sean-k-mooney: incorrect | |
| 14:05:28 | efried | Yeah, that's the point. Since we started claiming from placement, you can't oversubscribe. | |
| 14:05:35 | mriedem | efried: in the old days, before placement, if you bypass the scheduler, conductor would not send limits down to the RT so it wouldn't fail the limits check on the resource claim | |
| 14:05:46 | sean-k-mooney | mriedem: was that unintentional however as you jsut said we "broke" that in pike | |
| 14:05:59 | efried | has anyone screamed about that breakage? | |
| 14:06:13 | efried | Or do we still not have enough serious operators on pike yet? :P | |
| 14:06:17 | mriedem | there are like 3 people i now on >= pike but no... | |
| 14:06:47 | mriedem | *know | |
| 14:06:51 | edleafe | efried: one reason for the force option was that admins wanted to be able to say "I know what I'm doing, dammit!". It wasn't about code efficiency | |
| 14:07:17 | efried | edleafe: But IIUC, the destination host is observed regardless. | |
| 14:07:32 | mriedem | observed? | |
| 14:07:41 | efried | meaning you either get on the suggested host or you die | |
| 14:07:50 | mriedem | correct | |
| 14:07:51 | efried | I'm not sure how we would "fix" the oversubscribe thing at this point, without adding a placement feature to allow it. | |
| 14:08:22 | mriedem | i don't think adding features to support shooting yourself is something we want to do at this point | |
| 14:08:22 | efried | which I doubt we want to do | |
| 14:08:40 | efried | "Hey placement, you know that one thing you're supposed to be designed to do? Yeah, don't do that." | |
| 14:08:42 | edleafe | efried: it isn't just oversubscription that would cause the scheduler to reject it. Things like affinity, etc., would also cause it to fail | |
| 14:08:52 | mriedem | note that even with forced live migration, conductor still runs some checks that could cause us to reject the host | |
| 14:09:05 | mriedem | edleafe: nope | |
| 14:09:12 | efried | you mean besides the allocation claim? | |
| 14:09:12 | mriedem | we don't do any affinity checks outside of the scheduler for live migration | |
| 14:09:30 | edleafe | mriedem: without the force option, we do | |
| 14:09:36 | mriedem | in the scheduler | |
| 14:10:01 | mriedem | but that's more to my point - force is bad | |
| 14:10:15 | efried | I think what I'm getting at is, force isn't so much bad as... obsolete? | |
| 14:10:20 | mriedem | you could screw up AZs too | |
| 14:10:22 | efried | Like, it doesn't do anything useful anymore. | |
| 14:10:24 | edleafe | well, yeah, but admins wanted to be able to override | |
| 14:10:28 | mriedem | efried: agree | |
| 14:10:35 | edleafe | I'm not saying it's right | |
| 14:10:38 | mriedem | efried: it made a bit more sense pre-placement | |
| 14:10:42 | edleafe | Just that that was the pushback at the time | |
| 14:10:46 | efried | because oversubscribe | |
| 14:11:11 | efried | Okay, thanks, this helps validate my response to gibi's thread. | |
| 14:13:47 | openstackgerrit | Merged openstack/os-vif master: Remove IPTools deprecated implementation https://review.openstack.org/605422 | |
| 14:15:51 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Extend port profiles with datapath offload type https://review.openstack.org/572081 | |
| 14:17:43 | belmorei_ | hi. I'm having an issue with Ironic allocations in placement | |
| 14:18:58 | belmorei_ | We define the Ironic flavors with resources:VCPU=0, ... as documented in "https://docs.openstack.org/ironic/queens/install/configure-nova-flavors.html". | |
| 14:18:58 | belmorei_ | What I see is that allocations are only done for the resource class, and not vcpus, ram, disk. I imagine this intentional? | |
| 14:20:10 | efried | what do you mean, only done for the resource class? | |
| 14:20:43 | belmorei_ | the allocation for the resource_provider is only the ironic resource_class | |
| 14:20:54 | dansmith | belmorei_: yes, expected | |
| 14:21:22 | belmorei_ | great. Let me describe the issue | |
| 14:24:13 | belmorei_ | The problem is that we enable the ironic flavors per project (these projects are only for baremetal) (projects are mapped to a cell that only has the baremetal nodes) | |
| 14:24:59 | belmorei_ | However, users also have access to the "default" flavors that are for VMs in these projects (we can't remove public flavors) | |
| 14:26:37 | belmorei_ | If a user makes the mistake to use a default flavor in these projects (flavor for VMs) placement can return already in use baremetal nodes because they have cpu, ram, ... | |
| 14:27:30 | dansmith | belmorei_: the baremetal nodes should be exposing no cpu,ram,etc inventory | |
| 14:27:40 | dansmith | belmorei_: they should expose one inventory item of the baremetal resource class and nothing else | |
| 14:28:43 | belmorei_ | dansmith: Good to know I would expect that, but it's not happening. Maybe a conf issue in my side | |
| 14:29:10 | dansmith | belmorei_: yeah, I'm not sure how that could be happening anymore.. jroll dtantsur ? | |
| 14:29:34 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/virt/ironic/driver.py#L790 | |
| 14:29:47 | mriedem | we still reported cpu/ram/disk inventory for ironic nodes in queens | |
| 14:30:26 | mriedem | https://github.com/openstack/nova/commit/a985e34cdeef777fe7ff943e363a5f1be6d991b7#diff-1e4547e2c3b36b8f836d8f851f85fde7 removed that in stein | |
| 14:31:33 | dansmith | mriedem: um, we should have had a cutover so we're not exposing both right? | |
| 14:31:39 | dansmith | I thought that was like pike | |
| 14:31:57 | dansmith | comment there says zero in pike | |
| 14:31:58 | jroll | dansmith: we didn't do the cutover so people could migrate their flavor | |
| 14:32:08 | dansmith | jroll: right, but in queens? | |
| 14:32:19 | jroll | this is the first I've heard of this, fwiw, though it makes sense | |