| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 12:27:27 | alex_xu | efried: the comment https://review.openstack.org/#/c/514197/4/nova/tests/functional/db/test_resource_provider.py@2387 is only about line 2383 and 2386 aren't tested actually | |
| 12:27:27 | efried | alex_xu Are you concerned that one bad inventory will cause the whole thing to be excluded when it really shouldn't be? | |
| 12:28:03 | efried | alex_xu Oh, I think they must be. | |
| 12:28:22 | efried | alex_xu If you were to "fix" either one of those so they're viable, that RP would show up in the result. | |
| 12:28:37 | efried | They have to *all* fail in order to exclude this RP. | |
| 12:28:43 | efried | Don't they? | |
| 12:29:19 | jaypipes | efried, alex_xu: did you see my suggestion on renaming that "root providers" to "non-sharing providers"? | |
| 12:29:46 | alex_xu | efried: no, they are exclue, one RP hasn't enough VCPU, but has enough disk and mem, will be exclude | |
| 12:29:47 | efried | jaypipes I saw you "abstained" from my leetle survey, but I hadn't yet seen that, no. | |
| 12:30:06 | jaypipes | efried: I didn't abstain. I voted no on all options :) | |
| 12:30:29 | efried | jaypipes Cool. So you're in favor of "non-sharing"? | |
| 12:30:44 | jaypipes | efried: you fancy taking over the resource providers summary email for cdent the next 3 weeks? | |
| 12:31:08 | alex_xu | jaypipes: sorry, I didn't see that, where is it? | |
| 12:31:11 | jaypipes | efried: I am in favor of "non-sharing providers", yes | |
| 12:31:19 | jaypipes | alex_xu: in the commit message comment.. | |
| 12:31:43 | alex_xu | which patch....? | |
| 12:32:09 | jaypipes | alex_xu: https://review.openstack.org/#/c/480379/ | |
| 12:32:22 | efried | jaypipes Oh, uh, I could try to do that. I don't really have a handle on some of the sub-sub-pieces. | |
| 12:32:41 | jaypipes | efried: well, doing the email would give you that handle, ya? :) | |
| 12:32:48 | efried | That's one way to look at it. | |
| 12:32:50 | jaypipes | hehe | |
| 12:33:06 | jaypipes | efried: we can split the work between the two of us if you'd prefer. | |
| 12:33:16 | jaypipes | efried: are you going to Sydney? | |
| 12:33:19 | alex_xu | jaypipes: yea, non-shared provider sounds the right way | |
| 12:33:23 | efried | jaypipes Fraid not. | |
| 12:33:56 | jaypipes | efried: I think you meant "Fried not". | |
| 12:34:04 | jaypipes | geez, I am turning into my dad. | |
| 12:34:13 | efried | That's way better than I got in grade school. | |
| 12:34:19 | alex_xu | jaypipes: initial I thought that should be RP for compute node, the compute node always the root of nested resource provider, but yes, the child resource provider also can share something with others, so non-shared resource provider sounds right | |
| 12:34:40 | jaypipes | efried: I'm not going to Sydney either, so we can tackle the summary email between the two of us. | |
| 12:34:58 | efried | jaypipes Okay, sounds good to me. | |
| 12:35:12 | jaypipes | alex_xu: makes sense for compute nodes, yes, but eventually we'd like to detach the placement service from being compute-specific. | |
| 12:35:22 | alex_xu | jaypipes: yea | |
| 12:35:23 | efried | ++ | |
| 12:36:26 | efried | jaypipes I added 'non-sharing' as an option to the poll. | |
| 12:36:32 | alex_xu | jaypipes: still looking for your feedback on https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/add-trait-support-in-allocation-candidates | |
| 12:36:33 | efried | jaypipes Not that it's a democracy or anything. | |
| 12:37:11 | jsheeren | hi all, i already asked in #openstack but i think it's actually a dev issue (but don't shoot me if i'm wrong ..:) | |
| 12:37:33 | jaypipes | lol | |
| 12:37:39 | jaypipes | jsheeren: what's up? | |
| 12:37:42 | jsheeren | i'm running into an issue with instance resize of instances with a cinder backed root disk | |
| 12:37:56 | jsheeren | the resize does a resize_cleanup action, which checks if a root disk exists | |
| 12:38:03 | jsheeren | instances with a cinder root disk, do not have a nova root disk | |
| 12:38:11 | jsheeren | so this code gets executed: https://github.com/openstack/nova/blob/stable/ocata/nova/virt/libvirt/driver.py#L1149 | |
| 12:38:18 | jsheeren | the instance base path gets deleted | |
| 12:38:35 | jsheeren | this is a problem on nfs shared storage. when we suspend the instance after a resize, and then resume it. nova cannot find the libvirt xml definition | |
| 12:38:54 | jsheeren | i think the issue is introduced after https://bugs.launchpad.net/nova/+bug/1666831 | |
| 12:38:56 | openstack | Launchpad bug 1666831 in OpenStack Compute (nova) ocata "Nova recreates instance directory after migration/resize" [Low,Fix committed] - Assigned to Lee Yarwood (lyarwood) | |
| 12:39:09 | efried | It's the 666 in that bug number. | |
| 12:39:14 | jaypipes | heh | |
| 12:39:15 | jsheeren | lol | |
| 12:39:37 | jaypipes | jsheeren: are you trying to resize the root disk along with the flavor? | |
| 12:41:08 | jsheeren | jaypipes: the resize is triggered through horizon, going from flavor a to flavor b. not sure about the resize of the root disk along with the flavor, let me check real quick | |
| 12:41:28 | jaypipes | jsheeren: just check if the root_gb of the flavor is different from a to b. | |
| 12:41:40 | jsheeren | yes, that is the case | |
| 12:42:25 | jaypipes | jsheeren: k. I don't *think* that is the cause of this, but one sec, I'm going to give you some code to patch that one line and retry the operation.... one sec. | |
| 12:42:39 | jsheeren | jaypipes: thanks | |
| 12:45:19 | jaypipes | jsheeren: change the line so that it looks like this: | |
| 12:45:47 | jaypipes | if os.path.exists(inst_base) and not root_disk.exists() and not compute_utils.is_volume_backed_instance(instance._context, instance): | |
| 12:46:10 | jaypipes | jsheeren: restart the nova-compute service, retry your resize operation and lemme know if that fixes things. | |
| 12:47:13 | jsheeren | jaypipes: ok, i will, thanks! | |
| 12:47:31 | jaypipes | jsheeren: np. lemme know if that works and I'll add a note to the bug and submit a new bug for it. | |
| 12:55:01 | jsheeren | jaypipes: your patch works for us | |
| 12:56:24 | jsheeren | we're going to use this for now, as it is nfs shared storage. i assume people with no nfs shared storage will not run into this issue | |
| 12:57:03 | jsheeren | jaypipes: thanks for the fast response AND fix! | |
| 13:08:13 | efried | jaypipes Point of design for GET /allocation_candidates. Let's say I request inventory in three RCs. There's a RP with inventory in two of those RCs. But one of them is exhausted or otherwise unsuitable (wrong step_size, whatever). Should I *still* get a candidate with that RP in it (assuming another RP in the tree/aggregate can satisfy the other two pieces of the resource request)? | |
| 13:10:19 | bhagyashris | Hi all, Is nova-cpu.conf is used by only n-cpumte service or this is used by other service also like n-sch, n-cond.. ? | |
| 13:11:15 | efried | bhagyashris You talking devstack? | |
| 13:12:00 | bhagyashris | efried: yes | |
| 13:13:17 | efried | bhagyashris Easiest thing is to take a look at the service commands. The conf file is sent to the executables as a parameter. | |
| 13:16:29 | efried | bhagyashris sudo systemctl cat devstack@* | grep nova-cpu.conf <== For my devstack, this shows me only the nova-compute service. | |
| 13:16:56 | bhagyashris | efried: yes | |
| 13:17:13 | efried | bhagyashris Does that answer your question? | |
| 13:17:24 | bhagyashris | efried: yes | |
| 13:17:32 | bhagyashris | efried: thank you :) | |
| 13:17:39 | efried | bhagyashris You're welcome! | |
| 13:24:46 | cdent | efried: on your inventory question above, if I’m understanding the question correctly (I’m not sure I am) the answer is “yes”. Why, in the dances of your mind, would it be "no"? | |
| 13:25:14 | efried | cdent I agree. alex_xu and I have been debating it. | |
| 13:25:48 | efried | cdent He raised a valid point, which was, "Give me a real world example where this could happen." | |
| 13:25:57 | cdent | always a useful point | |
| 13:26:32 | efried | cdent It took a while, and eventually I had to resort back to the "DISK_GB provided by both local storage and a shared RP" thing. | |
| 13:26:33 | cdent | “real world example” depends on the answer to “can a compute node have local and shared disk” if the answer is yes, we get all sorts of examples, yeah? | |
| 13:26:36 | cdent | jinx! | |
| 13:26:38 | efried | hah! | |
| 13:26:58 | openstackgerrit | Matthew Booth proposed openstack/nova master: Use Migration object in ComputeManagerMigrationTestCase https://review.openstack.org/502126 | |
| 13:26:59 | openstackgerrit | Matthew Booth proposed openstack/nova master: Automatically revert resize which fails on destination https://review.openstack.org/462521 | |
| 13:27:53 | alex_xu | yea, finally, efried beats me | |
| 13:28:12 | cdent | efried: I think the api should allow for that possibility, even if compute nodes don’t or won't | |
| 13:28:17 | cdent | as we can’t see the future of placement | |
| 13:28:34 | cdent | and limiting placement for the models presented by today’s compute nodes is limiting | |
| 13:28:53 | efried | cdent The first example I came up with was: You're on a compute that's NUMA-capable and modeled with its CPU and memory resources in NUMA nodes, but you're making a request that doesn't care about NUMA affinity, so you should be able to get your VCPU from one NUMA node and your MEMORY_MB from a different one. | |
| 13:29:33 | cdent | I still find that modeling hard to stomach, but yeah, if you’re doing it that way, I agree | |
| 13:30:16 | efried | Anyway, I agree we don't want to paint ourselves into a corner. Which means we still have some SQL work to do on https://review.openstack.org/#/c/514197/ | |
| 13:31:08 | efried | I had one test case bug that "fixed" one aspect of the test and revealed this design hole at the same time. Just glad alex_xu caught it (in both places). | |
| 13:32:18 | efried | alex_xu So what's the path forward from here? Looks like we need to rework the logic some more. | |
| 13:32:40 | jaypipes | jsheeren: awesomesauce. I'll file a bug :) | |
| 13:33:12 | alex_xu | efried: emm...feel like, https://review.openstack.org/#/c/514197 should be revert to the patchset2? | |
| 13:33:51 | efried | alex_xu But with the new test case? | |
| 13:34:02 | jaypipes | efried: if there's no constraints saying that all three RCs need to be provided by the same RP, then sure. | |
| 13:34:13 | efried | jaypipes ++ | |