| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-02 | |||
| 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 | |
| 02:31:41 | Kevin_Zheng | correct | |
| 02:31:56 | gmann | when horizon try to fetch the old flavor ? | |
| 02:32:51 | Kevin_Zheng | yes | |
| 02:33:14 | gmann | i mean why horizon try to get old flavor? | |
| 02:34:09 | Kevin_Zheng | because instance saved the old flavor id | |
| 02:34:23 | Kevin_Zheng | and return it to horizon | |
| 02:34:36 | Kevin_Zheng | horizon use it to show the flavor details | |
| 02:34:53 | gmann | show flavor details in Instance detail tab? | |
| 02:35:10 | Kevin_Zheng | yeah | |
| 02:35:21 | Kevin_Zheng | also the instances list tab | |
| 02:35:48 | gmann | humm | |
| 02:36:13 | gmann | so with >2.47 horizon do not need to do that as instance can give flavor detail | |
| 02:36:20 | Kevin_Zheng | maybe | |
| 02:36:36 | gmann | so 2.47 actually solved the problem ? | |
| 02:36:55 | Kevin_Zheng | yeah it could | |
| 02:37:05 | gmann | i mean just show the what instance return either it exit or deleted | |
| 02:37:25 | Kevin_Zheng | yeah | |
| 02:44:05 | gmann | yea but that will be old stale thing that people would not find such flavor in system as horizon modified it | |
| 02:44:26 | gmann | may be you are asking about disabling this feature is good idea | |
| 02:44:46 | Kevin_Zheng | Yeah, I can think of one usecase of this | |
| 02:45:06 | Kevin_Zheng | since flavor have alot of fields | |
| 02:45:20 | gmann | yea | |
| 02:45:21 | Kevin_Zheng | maybe people want to only change one of the field | |
| 02:45:42 | Kevin_Zheng | so they don't want to create a new one and do all the input | |
| 02:46:27 | Kevin_Zheng | I was thinking, maybe instead of delete-and-create, horizon can provide a copy-and-modify | |
| 02:46:37 | gmann | yea | |
| 02:46:39 | Kevin_Zheng | leave the deleting to user | |
| 02:47:00 | gmann | because flavor id changes and thats problem for other instance operation like resize etc | |
| 02:47:09 | Kevin_Zheng | yeah | |
| 02:47:27 | Kevin_Zheng | and people don't know that editing is actually deleting and creating | |
| 02:48:29 | gmann | true | |
| 02:49:02 | Kevin_Zheng | replies on my maillist post is welcomed :) | |
| 02:52:36 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711 | |
| 02:53:45 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs to Instance object https://review.openstack.org/489408 | |
| 02:58:37 | openstackgerrit | zhangdaolong proposed openstack/nova master: Add debug log for fail to get console https://review.openstack.org/490302 | |
| 03:10:11 | openstackgerrit | zhangdaolong proposed openstack/nova master: Keep the code consistent https://review.openstack.org/490304 | |