| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 13:14:04 | sq4ind | | memory_mb | 122867 | | |
| 13:14:04 | kashyap | sq4ind: Please use pastebin :-( | |
| 13:14:08 | sq4ind | | memory_mb_used | 12800 | | |
| 13:14:14 | sq4ind | | running_vms | 4 | | |
| 13:14:18 | sq4ind | | service_host | nova0.linguamatics.com | | |
| 13:14:22 | sq4ind | | service_id | 12 | | |
| 13:14:26 | sq4ind | | state | up | | |
| 13:14:30 | sq4ind | | status | enabled | | |
| 13:14:34 | sq4ind | | uptime | 1:59 | | |
| 13:14:38 | sq4ind | | users | 1 | | |
| 13:14:44 | sq4ind | | vcpus | 16 | | |
| 13:14:48 | sq4ind | | vcpus_used | 6 | |
| 13:14:50 | sq4ind | sorry | |
| 13:14:52 | sq4ind | sean-k-mooney, sorry for pasting here | |
| 13:14:54 | sq4ind | https://pastebin.com/aprda4We | |
| 13:15:13 | sean-k-mooney | sq4ind: thats ok | |
| 13:15:18 | mriedem | lyarwood: can you check https://review.openstack.org/#/c/555029/ before we do a queens release? | |
| 13:17:31 | mriedem | melwitt: might want to throw the spec review day on the schedule wiki https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule#Special_review_days | |
| 13:17:48 | sean-k-mooney | sq4ind: so the capsity on the RP more or less matache the hypervisor api 122355.0 vs 122867 | |
| 13:18:10 | sean-k-mooney | sq4ind: but the used ram is way off 12800 vs 175104 | |
| 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 | |