Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-07
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.
15:28:58 melwitt k
15:29:43 mriedem bauzas: lyarwood: would be good to get this in and released https://review.openstack.org/#/c/566164/
15:40:19 kashyap mriedem: Holiday in the UK / IE
15:40:28 kashyap Probably France too
15:40:48 mriedem alright
15:42:02 kashyap (Not in France)
15:42:30 kashyap mriedem: BTW, thanks for the careful review here: https://review.openstack.org/#/c/565242/4/nova/virt/libvirt/driver.py@a4798
15:43:00 kashyap mriedem: Even I wrote "After second thoughts", I think hard-failing at Compute start up sounds cleaner
15:44:54 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add NUMANetworkTopology object https://review.openstack.org/564439
15:44:55 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440
15:44:56 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.networks field https://review.openstack.org/564441
15:44:57 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add NetworkRequest.physnet, tunnelled https://review.openstack.org/564442
15:44:58 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443
15:44:59 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Add 'populate_networks' to network API https://review.openstack.org/564444
15:45:00 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Add '_get_network_tunnel_status' https://review.openstack.org/564445
15:45:01 openstackgerrit Stephen Finucane proposed openstack/nova master: db: Add network_requests to instance_extra https://review.openstack.org/564446
15:45:02 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add Instance.network_requests https://review.openstack.org/564447
15:45:03 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Start accounting for network requests https://review.openstack.org/564448
15:45:04 openstackgerrit Stephen Finucane proposed openstack/nova master: rt: Start utilizing Instance.network_requests https://review.openstack.org/564449
15:45:05 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add RequestSpec.requested_networks https://review.openstack.org/564450
15:45:06 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Remove unnecessary default parameter https://review.openstack.org/564451
15:45:07 openstackgerrit Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing network_requests https://review.openstack.org/564452
15:45:35 mriedem kashyap: time to get dansmith to arbitrate
15:46:05 kashyap mriedem: Hehe, thought so. FWIW, I checked with a "real Operator" (runs OpenStack in Fedora Infra)
15:46:20 kashyap mriedem: And he agrees with your suggestion
15:53:43 dansmith mriedem: kashyap: commented
15:53:47 kashyap Completely unrelated thing about English: mriedem once corrected on a commit message: "we told it was" --> "we said [...]". I can't explain _why_ but his correction of s/told/said indeed "sounds" correct.
15:53:59 kashyap dansmith: Thanks; /me wears prickle-safe suit and heads to Gerrit

Earlier   Later