| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-07 | |||
| 12:57:30 | mnaser | morning everyone | |
| 12:57:33 | openstackgerrit | Jake Yip proposed openstack/nova master: Add --before to nova-manage db archive_deleted_rows https://review.openstack.org/556751 | |
| 12:57:39 | mnaser | it looks liek nova-next job is broken | |
| 12:58:05 | mnaser | http://zuul.openstack.org/builds.html?job_name=nova-next | |
| 12:58:20 | mnaser | oh i guess this is the fix https://review.openstack.org/#/c/566446/ | |
| 13:26:14 | lei-zh | ping efried | |
| 13:26:22 | efried | lei-zh: Howdy. | |
| 13:26:32 | efried | finucannot: Didn't you have a patch for https://review.openstack.org/#/c/566498/ ? | |
| 13:27:05 | lei-zh | hi eric | |
| 13:27:25 | finucannot | efried: https://review.openstack.org/#/c/565535/ | |
| 13:27:39 | efried | finucannot: thanks | |
| 13:28:01 | lei-zh | a question about update provider tree patches, are you going to add that method for every virt driver | |
| 13:28:36 | efried | lei-zh: Not me; individual virt driver maintainers will be doing that. | |
| 13:28:53 | lei-zh | I mean this one, https://blueprints.launchpad.net/nova/+spec/update-provider-tree | |
| 13:29:27 | efried | lei-zh: I know xen is in process; I started a patch for libvirt which bhagyashri_s is going to take over; and I'll be doing the PowerVM one. | |
| 13:33:05 | lei-zh | efried, ok ,thanks, I'm working on reporting cpu features as traits for libvirt, thought it might be helpful to updating provder tree job | |
| 13:34:29 | lei-zh | https://review.openstack.org/#/c/560317/ | |
| 13:35:04 | efried | lei-zh: Sorry, my connection flaked for a couple of minutes there. | |
| 13:35:15 | lei-zh | ok, np | |
| 13:35:23 | lei-zh | efried, ok ,thanks, I'm working on reporting cpu features as traits for libvirt, thought it might be helpful to updating provder tree job | |
| 13:35:24 | efried | lei-zh: The xen series starts here: https://review.openstack.org/#/c/520313/ | |
| 13:36:19 | efried | lei-zh: libvirt is here: https://review.openstack.org/#/c/560444/ | |
| 13:37:52 | efried | lei-zh: If you're working on libvirt traits, you may want to base your series on that patch. | |
| 13:37:55 | lei-zh | efried: I see, I will keep an eye on those patches. | |
| 13:39:37 | lei-zh | efried: I've submitted code for libvirt to expose cpu features, https://review.openstack.org/#/c/560317/, I'm appreciated if you could have a look at it | |
| 13:39:52 | efried | Yeah, I think I remember looking at that already. | |
| 13:40:52 | lei-zh | cool, thanks | |
| 13:51:07 | bhagyashri_s | efried: Hi, I have written functional test case in the patch https://review.openstack.org/#/c/560459 test case code #link: http://paste.openstack.org/show/720489/ but it's giving me the usages that the compute node provider DISK_GGB is taken into account and not shared storage provider DISK_Gb can you plz help me for the same where exactly I am going wrong | |
| 13:53:09 | efried | bhagyashri_s: Can you WIP your change set and post a patch set with the functional test case included? | |
| 13:54:15 | efried | bhagyashri_s: That paste looks like you've duplicated a lot of the framework from some existing functional test suite. | |
| 13:56:05 | bhagyashri_s | efried: yeah for now I have create data separately once it will give correct output I will refactor the code and reuse the code from existing functional test suite | |
| 13:57:40 | efried | bhagyashri_s: At a glance it looks like the test is properly constructed. But if I'm going to debug it I would rather be able to create my environment so it looks like yours. | |
| 13:58:05 | efried | bhagyashri_s: And I'm not sure the utility of separating it out only to have to fold it back in later. | |
| 14:10:53 | dansmith | did mriedem say he was out today? | |
| 14:13:20 | melwitt | not that I recall | |
| 14:14:23 | openstackgerrit | Vabada proposed openstack/nova master: Fix typos in Host aggregates documentation https://review.openstack.org/566591 | |
| 14:15:05 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: Get inventories per vGPU type https://review.openstack.org/564215 | |
| 14:16:07 | dansmith | okay | |
| 14:17:17 | mnaser | melwitt: morning, do you think you could un-wip this to get some reviews to get nova-next to pass? https://review.openstack.org/#/c/566446/ | |
| 14:17:52 | melwitt | mnaser: yeah, going to fix it up soon. just woke up | |
| 14:18:08 | mnaser | melwitt: no worries :D thanks for looking into it in the first place | |
| 14:18:21 | mnaser | i found out that this was the fix by seeing it as the only passing job here, heh: http://zuul.openstack.org/builds.html?job_name=nova-next | |
| 14:18:25 | melwitt | it was caused by one of my console patches, unforunately | |
| 14:18:47 | mnaser | i'm sure we've all had our share of breaking $world | |
| 14:21:00 | efried | bhagyashri_s, bauzas: meet each other | |
| 14:21:43 | bauzas | bhagyashri_s: like I said in #openstack-meeting-4, I'll rebase https://review.openstack.org/#/c/560444/ under my https://review.openstack.org/#/c/564215/ branch | |
| 14:21:51 | bauzas | bhagyashri_s: and provide a new revision | |
| 14:41:33 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 14:41:56 | openstackgerrit | Vabada proposed openstack/nova master: Fix typos in Host aggregates documentation https://review.openstack.org/566591 | |
| 15:01:34 | dansmith | jaypipes: so, looking at your existing set of patches for the consumer thing, I don't see the thing I was suggesting, which was to always create a consumer/user/project with dummy values if the api request was with an old microversion | |
| 15:01:40 | dansmith | jaypipes: is there some reason you're not doing that? | |
| 15:01:49 | dansmith | because I think that would get us to a much more consistent spot | |
| 15:03:18 | jaypipes | dansmith: as opposed to just letting old records have no consumer record? | |
| 15:03:41 | dansmith | jaypipes: yeah | |
| 15:04:11 | dansmith | I was saying that I think we'd be a lot better off if we just did that.. have a config value of "if_no_user_id_then_use_this=$uuid" | |
| 15:04:11 | jaypipes | dansmith: guess I just didn't want to go through a forced data migration. | |
| 15:04:14 | dansmith | well, | |
| 15:04:35 | dansmith | if you did, we could have FKs and not have to conditionally handle "if there is a consumer, else..." anywhere else in the code | |
| 15:06:22 | melwitt | mnaser: just updated the devstack patch, fyi | |
| 15:06:23 | efried | the tradeoff being that we would have to have "if user/project is $dummy then don't display it" | |
| 15:06:30 | efried | etc | |
| 15:06:34 | jaypipes | dansmith: there's only a single place we do that in my code series. | |
| 15:06:37 | dansmith | efried: you must have that anyway | |
| 15:06:59 | dansmith | efried: in case someone creates an allocation with a new one and then displays it with an old one | |
| 15:07:01 | efried | right, just sayin you're not really saving anything. | |
| 15:07:24 | efried | sorry, 'tradeoff' isn't the right word. | |
| 15:07:25 | dansmith | jaypipes: but anyone that uses the api has to have that code as well yeah? | |
| 15:07:57 | dansmith | jaypipes: because if the allocation was created with an older one, then the newer microversion has to show something different and every consumer has to handle that | |
| 15:08:14 | dansmith | which I know they do today, I'm just saying I think this was done wrong from the beginning and we should correct it | |
| 15:08:36 | jaypipes | dansmith: so instead of switching on project_id == None, they would need to switch on project_id == <sentinel>? | |
| 15:08:37 | dansmith | having the ambiguity on both ends makes this more complicated | |
| 15:08:52 | dansmith | jaypipes: they being the api consumer? | |
| 15:09:07 | jaypipes | dansmith: yes | |
| 15:09:34 | dansmith | I'm not sure why they would be "switching" on that value at all | |
| 15:09:37 | jaypipes | dansmith: I thought project == None was as good a representation as any | |
| 15:10:16 | jaypipes | dansmith: lemme back up and make sure I understand your concern | |
| 15:10:42 | dansmith | an api consumer doesn't list allocations looking for those without a project, or looking for those with a project, right? they'd be listing them and counting things, collated by project, or something like that I think | |
| 15:10:51 | dansmith | and they have to handle the null-ness of that field as a special value | |
| 15:11:16 | jaypipes | dansmith: the only place in my code series that has any "logic" about whether a consumer record exists is line 227 here: https://review.openstack.org/#/c/565405/5/nova/api/openstack/placement/handlers/allocation.py | |
| 15:11:19 | dansmith | when I explained this to you last week you said "yes exactly" so I'm just confused :) | |
| 15:11:21 | mriedem | o/ | |
| 15:11:37 | dansmith | jaypipes: yeah I get that | |
| 15:11:40 | mriedem | anyone talk about this gate failure yet? http://status.openstack.org/elastic-recheck/#1769286 | |
| 15:11:58 | dansmith | mriedem: melwitt is on it I think | |
| 15:12:03 | mriedem | great | |
| 15:12:06 | dansmith | mriedem: came from her patches I think | |
| 15:12:14 | mriedem | it did, not sure how though | |
| 15:12:16 | mriedem | unless it's timing | |
| 15:12:37 | jaypipes | dansmith: an API caller just asks for allocations for a consumer UUID or allocations for a resource provider UUID | |
| 15:12:45 | melwitt | mriedem: it's that the console proxy config needs to be per cell instead of global for the TLS settings to get picked up | |
| 15:12:54 | melwitt | and devstack doesn't gate on nova-next | |
| 15:13:04 | dansmith | jaypipes: yep | |
| 15:13:13 | mriedem | melwitt: this isn't 100% failure though is it? | |
| 15:13:22 | melwitt | I don't understand why it doesn't fail on all patches though, for example this one, the vnc proxy log just ... stops http://logs.openstack.org/67/566367/1/check/nova-next/48ce9d6/logs/screen-n-novnc-cell1.txt.gz | |
| 15:13:44 | melwitt | no, it's not 100%, see the above example ^ | |
| 15:14:22 | melwitt | mriedem: this is the devstack patch I've proposed https://review.openstack.org/566446 it passed nova-next earlier but I updated it to remove repetition. if I did that right, it should still pass nova-next | |
| 15:25:38 | mriedem | melwitt: nova-next runs in the devstack experimental queue if you want to test changes on devstack itself | |
| 15:25:41 | mriedem | but yeah it's not gating | |
| 15:26:30 | melwitt | yeah, I realized that while working on the fix. I've been running it through the experimental queue to test the fix | |
| 15:27:23 | mriedem | ack. i'm in st paul today and just got online so getting caught up. | |