| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 08:29:00 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183 | |
| 08:29:01 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 08:29:01 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 08:29:02 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 08:29:02 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 08:31:46 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor https://review.openstack.org/512965 | |
| 08:54:54 | openstackgerrit | David Rabel proposed openstack/nova master: VMware: add support for graceful shutdown of instances https://review.openstack.org/494169 | |
| 08:56:46 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node https://review.openstack.org/516217 | |
| 09:13:43 | rabel | heyho! | |
| 09:13:51 | rabel | https://review.openstack.org/#/c/494169/ is ready for review (again) :) | |
| 09:27:23 | openstackgerrit | jichenjc proposed openstack/nova master: Add more functional test for placement.usage https://review.openstack.org/513264 | |
| 09:28:52 | openstackgerrit | jichenjc proposed openstack/nova master: fix race condition of instance host https://review.openstack.org/494458 | |
| 09:29:17 | openstackgerrit | jichenjc proposed openstack/nova master: Add quiesce and unquiesce in support matrix https://review.openstack.org/482390 | |
| 09:32:56 | openstackgerrit | jichenjc proposed openstack/nova master: check query param for used_limits function https://review.openstack.org/499091 | |
| 09:36:04 | openstackgerrit | jichenjc proposed openstack/nova master: emove glance usage inside compute https://review.openstack.org/511392 | |
| 09:36:05 | openstackgerrit | jichenjc proposed openstack/nova master: Remove usage of glance.generate_image_url https://review.openstack.org/511397 | |
| 09:38:40 | openstackgerrit | jichenjc proposed openstack/nova master: Remove usage of glance.generate_image_url https://review.openstack.org/511397 | |
| 09:50:53 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Fix missing metavar in aggregate-update https://review.openstack.org/512485 | |
| 09:53:02 | openstackgerrit | jichenjc proposed openstack/nova master: WIP: conf: remove deprecated 'project_id_regex' opt https://review.openstack.org/501057 | |
| 10:07:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [Placement] Fix parameter order in placement API ref https://review.openstack.org/516233 | |
| 10:22:09 | openstackgerrit | Tuan Luong-Anh proposed openstack/nova master: Using --option ARGUMENT https://review.openstack.org/516238 | |
| 10:27:27 | jsheeren | hi, i'm having an issue with nova resize actions. the instance dir /var/lib/nova/instances/instance_uuid gets deleted; on suspend and resume this causes the error that libvirt cannot find the libvirt xml file | |
| 10:28:07 | jsheeren | if i watch the folder, an instance_uuid_resize folder get's created. after the resize, this folder gets deleted. as well as the /var/lib/nova/instances/instance_uuid folder | |
| 10:28:13 | jsheeren | has anyone seen this before? | |
| 10:58:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add a warning in 'nova-manage cell_v2 delete_cell' https://review.openstack.org/513771 | |
| 11:16:02 | openstackgerrit | Yikun Jiang proposed openstack/nova master: [WIP]Add pagination and Changes-since filter support for os-migrations. https://review.openstack.org/330406 | |
| 11:41:11 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073 | |
| 11:53:30 | efried | alex_xu So... my test case was buggy. That's a relief. | |
| 12:03:00 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Document the real behavior of notify_on_state_change https://review.openstack.org/516264 | |
| 12:04:41 | efried | alex_xu If you're around, let's talk about how you'd like to split up those test cases and I can work on that today. | |
| 12:09:13 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 12:10:39 | alex_xu | efried: hey, i'm here | |
| 12:11:00 | efried | alex_xu Hi. I'm glad you figured out that bug in my test. | |
| 12:11:11 | efried | At some point I'd like to get some tips on how you debug this stuff. | |
| 12:11:39 | alex_xu | efried: I drop in the same trap before, that is really hard thing to remember | |
| 12:11:48 | efried | Ah, okay. | |
| 12:11:59 | efried | Well, I'll know for the future. | |
| 12:12:18 | efried | I was of course thinking my "add allocation" was actually going to *add* an allocation. | |
| 12:12:39 | efried | Like, why couldn't you have two separate allocations rows for the same RP/RC | |
| 12:13:12 | efried | But I guess if you're e.g. resizing, you're supposed to do the math on the client side and replace the whole record. | |
| 12:13:40 | efried | Anyway - how would you like to split up that one test case? Where the three inventories all have something that excludes them from the result. | |
| 12:13:59 | alex_xu | efried: yea, something like that as i remember | |
| 12:14:20 | alex_xu | efried: I like your current way | |
| 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 | 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: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: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 | |