| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 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 ++ | |
| 13:34:15 | alex_xu | efried: yea | |
| 13:35:12 | efried | alex_xu Okay. I'll bring back PS2, expand the test case to include some more permutations of RPs, and we'll see if it passes. | |
| 13:35:25 | efried | alex_xu If it doesn't, you get to fix the SQL :) | |
| 13:35:26 | alex_xu | efried: cool, thanks | |
| 13:35:33 | alex_xu | ok :) | |
| 13:35:38 | efried | cause I'm still too rusty | |
| 13:35:55 | efried | Did I mention the last time I did any remotely serious SQL was circa 2003? | |
| 13:36:27 | efried | Even then I didn't do anything this complicated. | |
| 13:37:52 | alex_xu | efried_brb: yea, without jaypipes, I don't know the SQL can't such complicated :) | |
| 13:41:06 | edleafe | alex_xu: if you skip the meeting, we'll assign all the tasks to you! :) | |
| 13:41:58 | jaypipes | alex_xu: no worries, we can do the conversation on your patches. | |
| 13:43:49 | Dinesh_Bhor | cdent: Hi, do you have 5 min? I have a question: http://paste.openstack.org/show/624973/ | |
| 13:44:30 | cdent | hi Dinesh_Bhor, reading that | |
| 13:45:36 | edleafe | Scheduler subteam meeting in 15 minutes in #openstack-meeting-alt | |
| 13:45:56 | cdent | Dinesh_Bhor: let’s take it to #openstack-sdks | |
| 13:56:37 | jaypipes | efried: luckily, the SQL language has not changed too significantly since 2003. :) | |
| 13:57:00 | efried | jaypipes And we seem to be using a subset of it anyway, in case different backends. | |
| 13:57:33 | jaypipes | efried: ack | |
| 13:59:24 | edleafe | efried: and sqla makes it *so* easy!! | |
| 13:59:59 | efried | edleafe I had a mind-blown moment this weekend when I realized I could actually just pass textual SQL down. I was like, "uhh, why aren't we just doing that?" | |
| 14:00:52 | edleafe | Because ORMs insulate us from the rough edges of SQL, and make life easy! | |
| 14:01:49 | edleafe | Scheduler subteam meeting running now in #openstack-meeting-alt | |