| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 12:14:51 | efried | Talking about this: https://review.openstack.org/#/c/514197/4/nova/tests/functional/db/test_resource_provider.py@2387 | |
| 12:15:19 | alex_xu | ah | |
| 12:15:36 | efried | You want to create separate RPs for each different way an inventory can be exclude-worthy? | |
| 12:16:00 | efried | Morning jaypipes ! | |
| 12:16:17 | efried | (sorry, too cheerful?) | |
| 12:17:04 | alex_xu | efried: we can create three RPs , one hasn;t enough total vcpu, one hasn't current max_unit, the last one reserved a lot | |
| 12:17:28 | efried | alex_xu And is the idea for those RPs to be included or excluded? | |
| 12:17:46 | alex_xu | efried: all of us are cheerful when seeing jaypipes online :) | |
| 12:17:53 | efried | alex_xu i.e. do we want to create any other inventory in those RPs that makes them show up in the resulting candidate list? | |
| 12:17:54 | alex_xu | efried: exclude | |
| 12:17:59 | efried | Okay. | |
| 12:18:22 | alex_xu | efried: we should create inventory which match the request for other resource | |
| 12:18:49 | efried | Sorry, I didn't follow that one. | |
| 12:18:59 | alex_xu | efried: the reason is due to this https://review.openstack.org/#/c/514197/4/nova/objects/resource_provider.py@846 | |
| 12:19:41 | alex_xu | efried: your first VCPU inventory https://review.openstack.org/#/c/514197/4/nova/tests/functional/db/test_resource_provider.py@2381 doesn't have enough vcpus | |
| 12:20:13 | alex_xu | then the where conds will return False directly after https://review.openstack.org/#/c/514197/4/nova/objects/resource_provider.py@854 | |
| 12:20:32 | efried | alex_xu But just for that one resource. | |
| 12:20:40 | alex_xu | that means the mem and disk invetories acutally weren't tested | |
| 12:20:51 | efried | Oh, I don't think that's true. I hope not, anyway. | |
| 12:21:00 | efried | I have a different RP later on that tests that case... | |
| 12:21:22 | efried | or I thought I did... | |
| 12:21:56 | alex_xu | But the comment message said three inventory for three different failure case | |
| 12:22:13 | efried | alex_xu The one at L2389 | |
| 12:22:24 | efried | That one has one inventory that's good, one that's bad. | |
| 12:22:41 | efried | In that case, the 'bad' one is because the inventory is exhausted by allocations. | |
| 12:22:47 | efried | But that shouldn't matter, should it? | |
| 12:22:52 | jaypipes | efried, alex_xu: mornin, fellas! | |
| 12:23:35 | alex_xu | efried: that shounds good | |
| 12:24:09 | efried | alex_xu In any case, I can expand out all the conditions we're checking for in the SQL. | |
| 12:24:18 | efried | alex_xu But I still don't quite understand which way you're wanting to test. | |
| 12:25:02 | efried | alex_xu For each case, do you want (one inventory bad, one inventory good <= this RP should be *included*) or do you want (one inventory bad, no other inventory <= this RP should be *excluded*) | |
| 12:26:12 | alex_xu | efried: based on what you want to test | |
| 12:26:59 | efried | alex_xu Well, I'm not sure what your concern is. | |
| 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.. ? | |