Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-22
13:19:01 sean-k-mooney efried: any idea what could cause ^ other then leaked allocations
13:20:41 sean-k-mooney the difference between 122355.0 vs 122867 is placement is in MiB and hypervior api is in MB i think
13:20:41 efried sean-k-mooney: TBH I never understood the allocation ration breakage issue.
13:20:56 efried s/ration/ratio/
13:21:32 sean-k-mooney efried: if you set them in the host aggregate we did not use that value to set the RP allocation ratio and instead only used the nova conf version
13:21:44 sean-k-mooney at least i think that was the issue
13:22:06 efried In this case it's nowhere close, though, as sq4ind points out.
13:22:26 sean-k-mooney well the capasity is right it the used that is wrong
13:22:36 efried Although in the original statement it's a lot closer: "in the placement-api : Over capacity for MEMORY_MB on resource provider 52c0c39e-30f9-4bd8-84e9-af5c35aac61f. Needed: 2048, Used: 175104, Capacity: 122355.0"
13:22:41 sean-k-mooney so this is noting to do with alocation ratios
13:23:02 efried sq4ind: Are you able to query the placement API directly?
13:23:13 sq4ind efried, let me try
13:23:32 efried I would like to see what placement thinks the allocation ratio is for that MEMORY_MB inventory record on provider 52c0c39e-30f9-4bd8-84e9-af5c35aac61f
13:23:52 edleafe cdent: reading scrollback
13:23:53 sean-k-mooney efried: yes the orignial error is correct allocating an addtion 2048 on top of 175104 would violate the over commit ratio
13:24:09 efried sean-k-mooney: Unless the alloc ratio is 1.5
13:24:14 efried or higher
13:24:16 edleafe cdent: we should accept either, but normalize how we store them. Is that the change you are proposing?
13:24:35 efried edleafe: It is unclear whether we are normalizing them or not.
13:24:41 efried cdent is finding out.
13:25:02 edleafe efried: gotcha. We definitely *should* be normalizing
13:25:10 efried edleafe: Or only accepting one format.
13:26:24 edleafe no, I don't think we need to do that
13:28:05 cdent here's the bug: https://bugs.launchpad.net/nova/+bug/1758057
13:28:06 openstack Launchpad bug 1758057 in OpenStack Compute (nova) "When creating uuid-based entities we can duplicate UUIDs" [Undecided,Triaged]
13:28:15 cdent we do not normalize, they are treated as different resource providers
13:29:48 sq4ind efried, sorry but I am not able to query placement api directly
13:31:00 cdent efried, edleafe: gonna have my lunch while that settlles in
13:32:33 edleafe cdent: chew thoroughly!
13:36:44 efried cdent: Okay, so I think we have to fix the bug by normalizing UUIDs for all the APIs, and I don't think we need a microversion for that. Afterwards we can consider whether we want a microversion to further restrict the acceptable input formats.
13:38:33 sq4ind is there any way to repopulate cells in the placement ? (or is it safe to remove cell and recreate it )
13:38:39 bauzas folks, gentle notice I'm under the water with serious vGPU testing
13:41:22 jaypipes cdent: hey, got your question on UUIDs answered?
13:42:57 mriedem kashyap: how's the libvirt min version bump thing going?
13:43:04 kashyap mriedem: Hi
13:43:16 kashyap mriedem: First fixing the last unit test of this, as we speak: https://review.openstack.org/#/c/534384/4/
13:43:28 kashyap (Then I'll get to it.)
13:43:55 kashyap Just duking around the last test for the conditional in driver.py. The existing patch & tests all 'pass'
13:44:11 kashyap mriedem: You got a deadline for me? Or was it yesterday? :-)
13:44:44 mriedem would be nice to have that done by milestone 1 in case anything crops up, then we have time later in the release to deal with it
13:44:59 kashyap Ah, true. /me goes to look when is Milestone-1
13:45:07 cdent jaypipes is probably a bug so made one: https://bugs.launchpad.net/nova/+bug/1758057
13:45:09 openstack Launchpad bug 1758057 in OpenStack Compute (nova) "When creating uuid-based entities we can duplicate UUIDs" [Undecided,Triaged]
13:45:19 mriedem kashyap: april 19
13:45:43 kashyap mriedem: Ah, I'll be starting tomm or at most Monday.
13:45:57 jaypipes cdent: cool. looks like a relatively simple fix.
13:46:02 cdent efried: I pretty much agree with you, but what do we do any extant providers that are the same uuid with different reps and have since diverged?
13:46:33 cdent jaypipes: if you look above in scrollback there are some differing opinions on the right fix, but not vastly so
13:46:37 kashyap mriedem: In your "copious free time", wonder if you can punch any holes in the above change: https://review.openstack.org/#/c/534384
13:46:51 kashyap If you can't get to it; it's fine. Got enough attention so far, can wait
13:46:59 mriedem kashyap: i already did wrt backports
13:47:04 mriedem so don't really want to talk about that one honestly
13:47:30 kashyap Okay, no prob; dansmith suggested on the post a bit more palatable.
13:47:31 efried cdent: That's a neat question. Let the user clean 'em up?
13:47:48 kashyap (But, IMHO, it just seems like (even Tony) is trying to overly stick to the "letter of the law")
13:47:55 efried cdent: ...which entails allowing DELETE APIs to accept and use non-normalized UUIDs...
13:48:05 lyarwood mriedem: sorry missed your ping earlier, looking now
13:48:31 mriedem dansmith: question in tssurya's scheduler sighup patch about locking https://review.openstack.org/#/c/550527/
13:48:42 mriedem dansmith: i have a feeling we should be locking on that new attribute when we're resetting it
13:49:47 efried cdent: Gotta say it's pretty doubtful that something like this would have happened IRL, because the client - whatever it is - will generally be using one code path to create providers. So they'll have created 'em all with the same UUID format.
13:50:18 dansmith mriedem: okay I failed to circle back to those so I'll try to do that this morning dodging meetings
13:51:17 cdent efried: that's probably true, I'm just asking the questions for completeness. Also, just sake of the record and all that (in the sense that it is not really germane for today's reality): the whole point of having an http api is so that there are and will be multiple clients and different code
13:51:46 efried yup, I get that.
13:52:34 efried cdent: I say we just fix the glitch, and not bother making a cleanup tool until someone claims they need it.
13:53:42 efried cdent, melwitt, mriedem: This would be a good bug for new contributors.
13:54:18 edleafe efried: +1 on not worrying about it until we need to worry about it
13:55:23 mriedem tag it with low-hanging-fruit then
13:57:04 efried done
13:58:08 sq4ind sean-k-mooney, efried any idea ?
13:58:31 efried sq4ind: None here, sorry.
13:58:47 sq4ind efried, thanks
13:58:57 efried sq4ind: But you may want to recap for jaypipes - this sounds up his alley to me.
13:59:04 gibi nova meeting starts in about a minute
14:03:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Create volume attachment during boot from volume in compute https://review.openstack.org/541420
14:04:04 efried mriedem: Poetic patch title ^
14:04:41 mriedem is it?
14:10:48 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813
14:13:30 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Add request_id to isntance action notifications https://review.openstack.org/553288
14:25:00 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Add request_id to instance action notifications https://review.openstack.org/553288
14:25:42 bauzas mriedem: come to France and you'll enjoy the day
14:25:57 bauzas well, if you can...
14:28:36 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Add request_id to instance action notifications https://review.openstack.org/553288
14:33:23 mriedem need another core for the bottom 2 patches in this series to move the nova-cells-v1 job in-tree and then change it to use neutron, which is the first part of removing nova-network https://review.openstack.org/#/c/549780/
14:36:03 stephenfin mriedem: I'll grab em
14:44:09 sq4ind I think I've found why I was having issues... basically when listing cells in placement I had one out of three rabbitmq servers in the transport url, and only hosts connected to this rabbitmq server were updating their resource usage. Now I've fixed the url, I am also moving VMs from hosts and removing hosts from placement cells, and then recreating them. After that everything works as it should be
14:44:16 sq4ind hope that makes sense
14:46:38 efried sq4ind: Glad you figured it out - sorry we couldn't be more help.
14:55:40 sq4ind efried, no problem :D I like to dig more and more into openstack internals :D And you were very helpful: you've gave some clues where to look at it :D, thanks ! :)
15:01:21 openstackgerrit Eric Fried proposed openstack/nova master: Support extending attached ScaleIO volumes https://review.openstack.org/554679
15:01:26 mriedem stephenfin: thanks for hitting those cells ci patches
15:03:17 stephenfin mriedem: np
15:06:50 mriedem edmondsw: we don't need both a powervm-resize and powervm-cold-migrate blueprint
15:06:55 mriedem if you implement resize, you have to have cold migrate
15:07:07 mriedem so i'm going to mark the cold migrate one as superseded
15:07:18 edmondsw mriedem yep
15:07:22 mriedem esberglu: ^
15:07:56 edmondsw rebuild and evac would go in there as well
15:08:07 edmondsw esberglu update the description on that one?
15:08:14 edmondsw (resize)
15:08:19 mriedem eh?

Earlier   Later