| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 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 | 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 | |