| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 21:25:54 | jaypipes | dansmith: if you're looking for something to get your mind off this resize stuff, your opinion on https://review.openstack.org/#/c/474914/7/os_vif/objects/vif.py would be useful. | |
| 21:34:08 | mriedem | ok coming up | |
| 21:35:01 | mriedem | i assume someone is going to fix the pep8 failures in the last change | |
| 21:35:10 | dansmith | jaypipes said he was | |
| 21:35:21 | jaypipes | yes | |
| 21:35:43 | dansmith | did we get jenkins runs? | |
| 21:36:21 | dansmith | btw, | |
| 21:36:49 | dansmith | jaypipes: reading your (now) top patch earlier, I was kinda thinking the ocata compat thing could/should be split from the fixing of resize_confirm | |
| 21:36:56 | dansmith | are those tied together in some obscure way I'm not seeing? | |
| 21:37:29 | jaypipes | dansmith: yeah, agree with you | |
| 21:37:38 | jaypipes | dansmith: this all kinda snowballed on me. :( | |
| 21:38:05 | dansmith | cdent rightly noted that the patch is large and gangly at this point | |
| 21:38:18 | jaypipes | yup | |
| 21:41:25 | mriedem | f i got distracted and screwed up my rebase | |
| 21:51:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: remove provider allocs in confirm/revert resize https://review.openstack.org/488510 | |
| 21:51:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Sum allocations in the scheduler when resizing to the same host https://review.openstack.org/490085 | |
| 21:51:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Test resize to same host with placement api https://review.openstack.org/489973 | |
| 21:53:16 | mriedem | ok i'm +2 on the bottom resize test change | |
| 21:53:21 | mriedem | and my middle change should be ready | |
| 21:53:34 | jaypipes | mriedem: lemme review the second then. | |
| 21:53:46 | jaypipes | mriedem: would certainly be easier to merge the bottom two... | |
| 21:54:16 | jaypipes | mriedem: will +2 the bottom one when I see the test runs | |
| 22:01:08 | openstackgerrit | Chris Friesen proposed openstack/nova master: Filter out stale migrations in resource audit https://review.openstack.org/339715 | |
| 22:09:48 | tonyb | mriedem: ANy chance we can get https://review.openstack.org/#/c/489078/ some love. It's needed to unblock a glanceclient update | |
| 22:12:18 | mriedem | wtf what tests rely on those? | |
| 22:13:07 | mriedem | oh nova.tests.unit.test_wsgi.TestWSGIServerWithSSL | |
| 22:14:00 | mriedem | done | |
| 22:14:09 | mriedem | tonyb: see if dansmith will love up on that now | |
| 22:14:51 | tonyb | mriedem: Thanks | |
| 22:15:11 | mriedem | jaypipes: dansmith: fyi i also backported the PUT allocations overwrite change to ocata https://review.openstack.org/#/c/490231/ | |
| 22:15:40 | mriedem | kangaroo sausage | |
| 22:15:42 | dansmith | really really trying not to say something dirty here | |
| 22:15:50 | dansmith | about "love up" on this patch | |
| 22:15:58 | tonyb | dansmith: LOL | |
| 22:16:10 | colby_ | down the newton version of nova support passing the libvirt cpu model from the flavor metadata hw:cpu_model ? Ive been having trouble finding that answer. Ive seen people say it worked in kilo but I have been unable to get it to work on newton | |
| 22:17:36 | mriedem | colby_: no, those are configured on the compute node, not something passed through flavor extra specs | |
| 22:17:41 | mriedem | unless someone has hacked that into their cloud | |
| 22:18:10 | colby_ | thanks! | |
| 22:18:35 | mriedem | flavor extra specs are a complete wild west so someone could have hacked that in | |
| 22:20:09 | colby_ | yea was hoping it would support it. Was tyring to have flavors that only worked on newer hypervisors, through host aggregates and would use higher cpu model. We use ceph backend so we default to the lowest cpu model for live migration but would like to be able to create some tiers | |
| 22:25:19 | mriedem | colby_: cburgess might have some tips | |
| 22:37:39 | cfriesen | colby_: mriedem: we hacked in setting the cpu model for a subset of Intel models in the flavor extra specs, and back around kilo we proposed upstreaming it but it turned out to be difficult to do generally (due to different clouds/hypervisors not treating cpu models the same) | |
| 22:38:32 | cfriesen | colby_: could you use host aggregates, one per model that you want to expose? | |
| 23:29:28 | colby_ | cfriesen: we could. I was tyring to do it in a way where the older cpu model flavors could still run on the newer hypervisors to not restrict those to just the old hypervisors. I was hoping to be able to have instances with different cpu models on the same hypervisor. But that may not be an option. | |
| 23:31:53 | cfriesen | colby_: that was what we hacked in...flavors could specify the cpu model they wanted and would be scheduled on that cpu model or "newer", but would be run with the cpu model they specified. | |
| 23:33:06 | cfriesen | colby_: making it generic enough to apply upstream across different hypervisors and different providers turned out to be horribly complicated | |
| 23:34:57 | colby_ | yea that makes sense | |
| #openstack-nova - 2017-08-03 | |||
| 00:21:13 | openstackgerrit | Merged openstack/nova master: Add redirect for api-microversion-history doc https://review.openstack.org/489641 | |
| 00:24:13 | openstackgerrit | Merged openstack/nova master: add top 404 redirect https://review.openstack.org/490181 | |
| 00:24:52 | openstackgerrit | Merged openstack/nova master: sort redirectmatch lines https://review.openstack.org/490182 | |
| 00:25:31 | openstackgerrit | Merged openstack/nova master: fix rpc broken rst comment https://review.openstack.org/490197 | |
| 00:26:10 | openstackgerrit | Merged openstack/nova master: Update SSL cert used in testing https://review.openstack.org/489078 | |
| 02:08:29 | Kevin_Zheng | mriedem: flavor id is not included in the reply > 2.47 | |
| 02:10:22 | gmann | Kevin_Zheng, in server show? | |
| 02:10:38 | Kevin_Zheng | gmann: I used list/details | |
| 02:10:56 | Kevin_Zheng | "flavor": {"ephemeral": 0, "ram": 512, "original_name": "m1.tiny", "vcpus": 1, "extra_specs": {}, "swap": 0, "disk": 1} | |
| 02:11:04 | Kevin_Zheng | I guess this is what horizon uses | |
| 02:12:17 | gmann | Kevin_Zheng, yea, it is right as per microversion 2.47 | |
| 02:12:43 | Kevin_Zheng | do you know the flavor story matt mentioned last night? | |
| 02:13:54 | Kevin_Zheng | Horizon-flavor | |
| 02:14:03 | gmann | Kevin_Zheng, no, whats that. in 2,47 id not returned instead flavor data | |
| 02:14:42 | Kevin_Zheng | horizon shows flavor name when display instances, right? | |
| 02:15:31 | Kevin_Zheng | it also provided a feature that can edit existing flavors, no matter it has been used or not | |
| 02:16:11 | Kevin_Zheng | since nova don't provide this kind of action, horizon delete the old flavor and created a new one, the id of the flavor is changed | |
| 02:16:12 | openstackgerrit | Merged openstack/nova master: Test resize to same host with placement api https://review.openstack.org/489973 | |
| 02:16:29 | Kevin_Zheng | before we move flavor to api db | |
| 02:16:36 | gmann | yea | |
| 02:16:38 | Kevin_Zheng | flavor is soft-deleted | |
| 02:16:58 | Kevin_Zheng | when nova returned instance.flavor_id | |
| 02:17:17 | Kevin_Zheng | horizon can still got the deleted flavor | |
| 02:17:34 | Kevin_Zheng | but when it is in api db | |
| 02:17:46 | Kevin_Zheng | delete is gone forever | |
| 02:17:59 | Kevin_Zheng | so cannot display | |
| 02:18:49 | gmann | i see | |
| 02:18:57 | Kevin_Zheng | another thing is that even we can get the correct flavor name | |
| 02:19:06 | Kevin_Zheng | if we modified the flavor details | |
| 02:19:43 | Kevin_Zheng | the display of the flavor under this name will be incorrect | |
| 02:19:58 | Kevin_Zheng | so I guess maybe showing id is better? | |
| 02:20:16 | Kevin_Zheng | but we don't reply id > 2.47 | |
| 02:20:32 | Kevin_Zheng | maybe we should add it to the current reply?? | |
| 02:20:39 | gmann | Kevin_Zheng, so name should be same in horizon after modification right | |
| 02:20:58 | Kevin_Zheng | it depends, you can also edit name | |
| 02:21:34 | Kevin_Zheng | very complicated usecases | |
| 02:21:54 | gmann | but with id it will be same issue that horizon will get deleted id | |
| 02:22:41 | Kevin_Zheng | yeah, maybe people should come up with a solution, I've posted a maillist | |
| 02:26:14 | gmann | Kevin_Zheng, so when horizon modified flavor(deleted old one). and if someone check instance it shows as flavor-id in instance detail even that is deleted | |
| 02:26:21 | gmann | that is till 2,47 | |
| 02:26:40 | gmann | right? | |
| 02:27:01 | Kevin_Zheng | yeah, thats one option, or we could just display the details | |
| 02:27:14 | Kevin_Zheng | because we already have it | |
| 02:27:28 | gmann | i mean what was behavior till 2,47 | |
| 02:28:19 | Kevin_Zheng | Not available will be displayed | |
| 02:28:23 | gmann | instance use to show old flavor id which is deleted | |
| 02:28:31 | Kevin_Zheng | as we moved flavor to api db | |
| 02:28:36 | gmann | yes | |
| 02:28:39 | Kevin_Zheng | and delete is delete there | |
| 02:28:59 | Kevin_Zheng | horizon could not get the flavor from db using id | |
| 02:30:51 | gmann | yea but GET instance shows the flavor id (<2.47) | |
| 02:31:05 | Kevin_Zheng | yeah, | |
| 02:31:31 | gmann | so instance detail in horizon will have old id | |