Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-05
20:46:43 cfriesen ah, that makes sense
20:46:43 mriedem b/c of the unique constraint on the provider name
20:48:49 mriedem so https://github.com/openstack/nova/blob/653515a45032811b6bc2f1d0fb651472005496ec/nova/scheduler/client/report.py#L2173 is really just not right for (1) in-progress / unconfirmed migrations and (2) evacuated hosts
20:49:26 cfriesen agreed
20:49:55 mriedem i could start a rolling ball with said functional test to at least recreate the issue so we can throw fixes at it
20:49:56 sean-k-mooney cfriesen: just looking at the placmenet fuctional test tehy expresly check that deleteing allocated resouce provider fails just an fyi https://github.com/openstack/placement/blob/master/placement/tests/functional/db/test_resource_provider.py#L363-L367
20:50:54 cfriesen sean-k-mooney: yeah, it's valid that it fails when there are allocations, but setting "cascade=false" is supposed to delete those allocations. except it doesn't
20:52:02 sean-k-mooney when calling delete_resource_provider
20:52:30 mriedem cfriesen: you mean cascade=true
20:52:32 sean-k-mooney initally i assumed when you said cascade=true you were refering to the db schema
20:52:42 cfriesen bah, yes. cascade=true
20:52:44 mriedem looks like that code was written specifically for an ironic case https://review.opendev.org/#/c/428375/6/nova/scheduler/client/report.py@771
20:52:52 mriedem so not really thinking about migrations and evacuates and suh
20:52:54 mriedem *such
20:53:46 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Spec to pre-filter disabled computes with placement https://review.opendev.org/657884
20:53:47 mriedem dansmith: got that spec updated ^
20:55:28 sean-k-mooney i would need to check the placmeent api to confim but the allocation table has teh RP it was allcaoed from so we should be able to simply look up all the allocation for a given rp then delete tehm assuming that is exposed at the api level
20:55:34 sean-k-mooney which i proably is not
20:56:08 icarusfactor Can I have more than one compute_driver for nova.conf or is it limited to only one?
20:56:36 sean-k-mooney ya its not
20:57:39 sean-k-mooney so we need to add a new endpoint which is /allocations?rp_uuid=XYZ to be be able to do this cleanly
20:58:15 sean-k-mooney icarusfactor: its one per nova.conf
20:58:29 sean-k-mooney icarusfactor: but you can have multiple agent on the same host in some cases
20:58:44 sean-k-mooney icarusfactor: are you trying to run ironc and libvirt on teh same host?
20:59:15 icarusfactor sean-k-mooney, Nifty , I'm running libvirt currently. Was wondering how to do that.
20:59:50 sean-k-mooney its generally not a great idea to do but if you have a second nova.conf that you pass to the second agent you can make it work
21:00:55 icarusfactor sean-k-mooney, Just trying and experimenting with different methods , want to use the Stein docker nova driver.
21:00:56 sean-k-mooney normally i would recommend running the ironic driver assuming that is the other one you want to use on one of your contoler instead of colcating it on a libvirt compute node
21:01:17 mriedem sean-k-mooney: right i asked that here https://review.opendev.org/#/c/428375/6/nova/scheduler/client/report.py@771
21:01:20 mriedem but never got a response
21:02:22 mriedem we can get the allocations for a given provider with this API https://developer.openstack.org/api-ref/placement/?expanded=list-resource-provider-allocations-detail#list-resource-provider-allocations
21:02:25 sean-k-mooney icarusfactor: i had thought that dirver nova docker driver was nolonger mainatined
21:03:03 sean-k-mooney mriedem: oh off the RP endpoint
21:03:10 sean-k-mooney cool ya that seams more sane
21:03:20 icarusfactor sean-k-mooney, Humm, that is what I was wondering , the Dashboard now shows the docker option.
21:03:22 sean-k-mooney at least that way we cant get out of sync
21:03:44 sean-k-mooney icarusfactor: dashboard as in horizon?
21:03:47 icarusfactor Seeing it in Stien , I was wanting to try this option.
21:03:50 icarusfactor yes
21:04:05 sean-k-mooney icarusfactor: could that be form zun?
21:04:11 mriedem https://review.opendev.org/#/c/657016/ is my change where cdent pointed out that failure to delete the rp doesn't make us fail to delete the compute service
21:04:16 mriedem finally connecting all the dots
21:04:19 mriedem i'm slow and dumb
21:04:33 icarusfactor sean-k-mooney, Cant answer that.
21:04:59 sean-k-mooney icarusfactor: https://github.com/openstack/nova-docker
21:05:22 sean-k-mooney icarusfactor: it proably related to zun
21:05:55 sean-k-mooney mriedem: oh this is a recent change
21:06:08 icarusfactor sean-k-mooney, ok , will check zun out , that helps as I was going /dev/null fast.
21:06:14 mriedem sean-k-mooney: which?
21:06:24 sean-k-mooney https://review.opendev.org/#/c/657016/
21:06:38 sean-k-mooney its from monday where cdent commented
21:08:05 mriedem i think i wrote that at the ptg,
21:08:09 mriedem but it's a follow on fix to https://review.opendev.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80
21:08:12 mriedem which isn't so new
21:08:32 sean-k-mooney oh may 3rd not june 3rd
21:08:39 sean-k-mooney i miss read teh commit date
21:08:43 mriedem so we used to always orphan the rps when when deleting a compute service,
21:09:03 mriedem then we tried to delete the rps, but if it failed we still deleted the copute service and didn't try all nodes in the case of ironic,
21:09:14 mriedem now we realize that we can still fail to delete the rps b/c of evacs and unconfirmed migrations
21:09:20 mriedem so not the worst, but still busted...
21:09:46 mriedem meanwhile, let's pile a bunch of new code into nova yay wee!!!!
21:10:23 sean-k-mooney hehe well stephen is trying to delete a tone of it too :)
21:10:33 sean-k-mooney but im guessing we shoudl update https://github.com/openstack/nova/blob/653515a45032811b6bc2f1d0fb651472005496ec/nova/scheduler/client/report.py#L2173
21:10:52 sean-k-mooney to get teh allcotion form the RP via teh placmeent api right
21:11:11 mriedem stephen is deleting the stuff no one has been using for several years sure :)
21:11:12 sean-k-mooney and then if we combind that with your change for ironic that might do the right thing
21:11:30 mriedem i need to write the functional recreate test first before we start throwing fixes at it,
21:11:42 mriedem because there are several issues here i think and i need to start with the tests
21:13:19 sean-k-mooney sure but https://review.opendev.org/#/c/657016/2/nova/api/openstack/compute/services.py is calling delete_resource_provider
21:13:40 mriedem i know
21:13:59 mriedem ^ is no worse off than what we have today, it just handles 1:M ironic nodes,
21:14:07 sean-k-mooney so if we fix and test delete_resource_provider for a singel provider then we can layer your other fix on top.
21:14:15 mriedem cdent's -1 is that the commit message is asserting that if we fail to delete the rp we won't delete the compute service which is false
21:14:15 sean-k-mooney yes
21:14:40 sean-k-mooney i think they shoudl stay seperate patches too because its really two sperate problems
21:15:00 mriedem so before refactoring delete_resource_provider and how that works for allocations, i would need to think about whether or not those should be separate changes (i think they should for sanity)
21:15:12 mriedem right
21:15:57 mriedem but right now i have familial duties so can't work on this until tomorrow
21:16:29 sean-k-mooney mriedem: night o/ if you want me to try on work on part of this let me know
21:16:46 sean-k-mooney i need to go finish some spec reviews from yesterday
21:45:19 openstackgerrit Adam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class https://review.opendev.org/662105
22:13:13 openstackgerrit Adam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class https://review.opendev.org/662105
22:13:49 openstackgerrit Sundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification. https://review.opendev.org/603955
23:26:11 openstackgerrit Artom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug https://review.opendev.org/644881
23:26:11 openstackgerrit Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498
23:26:12 openstackgerrit Artom Lifshitz proposed openstack/nova master: [DNM] use iptables in nova-multinode https://review.opendev.org/660782
23:27:27 artom mriedem, dansmith, think I got everything ^^ Don't expect anything else to happen tonight, I'm gone after this anyways, just an FYI
23:27:34 artom *I don't expect
#openstack-nova - 2019-06-06
02:17:52 alex_xu sean-k-mooney: thanks
02:18:29 yonglihe sean-k-mooney: thanks
03:09:19 openstackgerrit XiaojueGuan proposed openstack/nova master: Fix code intendent of file wsgi.py https://review.opendev.org/663487
05:35:55 openstackgerrit Merged openstack/nova master: Hide hypervisor id on windows guests https://review.opendev.org/579897
05:48:36 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove an unused method https://review.opendev.org/663502
07:32:51 openstackgerrit Sharat Sharma proposed openstack/nova master: Modifying install-guide to include public endpoint for identity service https://review.opendev.org/663530
08:19:16 kashyap alex_xu: Want to put this through? I already had your +2 on it (and it now has +2 from Eric): https://review.opendev.org/#/c/661574/
08:22:05 alex_xu kashyap: checking now
08:22:35 lyarwood mdbooth: morning, think I've worked out the test_show_update_rebuild_list_server RDO failure. It's a simple race, when passing the test isn't verifying the image as other tests have already downloaded it.
08:23:00 mdbooth lyarwood: Ouch!
08:23:04 lyarwood mdbooth: I can reproduce easily by running tempest.api.compute.servers.test_servers and everything passes and tempest.api.compute.servers.test_servers.ServerShowV263Test where the test fails
08:23:09 mdbooth lyarwood: Also, that's awesome sleuthing

Earlier   Later