| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-13 | |||
| 16:09:13 | sean-k-mooney | erol: perhaps. i have used ironic but only in a limited fashion. one thing that you should be aware of is when deleteing ironic nodes it does not alway delete the neutron port which can cause issues | |
| 16:09:49 | raghav | +----------------+---------------------+-----------------+----------------+-------+ | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | +----------------+---------------------+-----------------+----------------+-------+ | region!child@1 | praveen-dev | QEMU | 10.223.197.217 | up | +----------------+---------------------+-----------------+----------------+-------+ | |
| 16:09:50 | sean-k-mooney | *used ironic much, only in a limited fashion | |
| 16:10:01 | raghav | here id fiels is non-integer | |
| 16:10:21 | sean-k-mooney | raghav: the id field is a string | |
| 16:10:35 | raghav | my nova-api version is 15.0.1 | |
| 16:10:37 | sean-k-mooney | raghav: infact its usally a uuid | |
| 16:10:57 | raghav | but in doc its integer | |
| 16:11:16 | raghav | https://github.com/openstack/nova/blob/stable/mitaka/nova/objects/compute_node.py#L59 | |
| 16:12:18 | erol | sean-k-mooney: I wish there is a cli command to flush failed attempt for RetryFilter | |
| 16:12:23 | raghav | i am getting parsing error in watcher because of this | |
| 16:13:50 | sean-k-mooney | raghav: so the id field in the db is an int | |
| 16:14:20 | sean-k-mooney | however i belive the ID filed in the api maps to the UUID field in the db as the id filed in the db is not exposed | |
| 16:14:51 | sean-k-mooney | raghav: i could be wrong on that but jaypipes or mriedem shoudl be able to confirm | |
| 16:15:26 | mriedem | which table? | |
| 16:15:35 | mriedem | we expose the compute_nodes.id field out of the API | |
| 16:15:37 | mriedem | b/c we're dumb | |
| 16:16:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/hypervisors.py#L52 | |
| 16:16:32 | mriedem | sean-k-mooney: i plan on fixing that | |
| 16:16:33 | mriedem | https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api | |
| 16:17:24 | sean-k-mooney | raghav: actully i might be getting confused with the flavor sorry ignore what i previously said. | |
| 16:17:25 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Cleanup code in create_ploop_image https://review.openstack.org/444970 | |
| 16:17:26 | sean-k-mooney | mriedem: cool | |
| 16:17:37 | mriedem | sean-k-mooney: we expose the flavor.id too out of the API | |
| 16:18:55 | sean-k-mooney | mriedem: yes but for the flavor id that is also user set able as any arbitry string, and i know several people who have reversed the name and id filed on the commandline so that is even more of an issue | |
| 16:19:07 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Cleanup code in create_ploop_image https://review.openstack.org/444970 | |
| 16:19:26 | mriedem | sean-k-mooney: well, there is flavor.id and flavor.flavorid | |
| 16:19:32 | mriedem | flavor.flavorid is user-settable | |
| 16:19:36 | mriedem | flavor.id is the primary key | |
| 16:20:11 | mriedem | i guess we don't expose flavor.id here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/flavors.py#L34 | |
| 16:20:18 | mriedem | it might be the server get | |
| 16:20:49 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L259 i guess that's flavorid too | |
| 16:21:05 | sdague | mriedem: we don't expose the .id anywhere iirc | |
| 16:21:31 | mriedem | sdague: ok i thought we did and that was part of what prompted your original spec to nest the flavor details in the server response | |
| 16:21:46 | mriedem | it also came up when moving flavors from the cell to the api db | |
| 16:21:58 | mriedem | i might be misremembering details though, it was a year ago | |
| 16:23:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040 | |
| 16:23:35 | sdague | mriedem: there were interesting challenges with flavor.id in cells v1, because it is an auto incrementing id | |
| 16:23:43 | sdague | and, thus could be different in the cells | |
| 16:24:21 | sdague | it is used as the join column | |
| 16:24:47 | dansmith | same for cellsv2 of course, | |
| 16:24:57 | dansmith | but I think we've gotten rid of all those things by now | |
| 16:28:27 | raghav | mriedem: so is it bug in nova code? | |
| 16:28:47 | mriedem | raghav: is what a bug in nova code? sorry i'm on a call so i'm not sure what the earlier discussion is about. | |
| 16:29:31 | mriedem | raghav: are you using cellsv1? i see region!child@1 | |
| 16:29:34 | mriedem | that looks like cellsv1 | |
| 16:30:16 | raghav | mriedem: i have devstack setup | |
| 16:30:22 | mriedem | raghav: note that you don't want to be using cellsv1 | |
| 16:30:29 | raghav | mriedem: with ocata release | |
| 16:30:35 | mriedem | raghav: what's your ENABLED_SERVICES variable? | |
| 16:30:45 | mriedem | you shouldn't have n-cell-region or n-cell-child | |
| 16:31:32 | raghav | mriedem: n-api,n-cpu,n-cond,n-sch,n-novnc,n-cauth | |
| 16:31:37 | mriedem | sorry just n-cell | |
| 16:36:40 | mriedem | raghav: in general, we don't want int id's exposed out of the API, which is why we have https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api | |
| 16:36:55 | mriedem | raghav: but that's going to be done in a microversion | |
| 16:37:57 | sdague | raghav: honestly, I think there is a lot of confusion about how you got to that kind of data, and the only way any of us know that to be possible is if you have a cells v1 setup | |
| 16:38:08 | sdague | raghav: so, perhaps a reproduce scenario would be useful | |
| 16:38:15 | mriedem | raghav: for now os-hypervisors will return an int for the id https://developer.openstack.org/api-ref/compute/?expanded=show-hypervisor-statistics-detail,show-hypervisor-details-detail | |
| 16:38:19 | mriedem | as shown in the docs | |
| 16:38:27 | mriedem | my blueprint is to change that to return the uuid rather than the int id | |
| 16:38:48 | melwitt | sdague: in cells v1, we don't officially support flavors in cell dbs. users like CERN have their own automation that syncs flavors from the api cell db to the child cell dbs. fwiw | |
| 16:39:08 | mriedem | raghav: as for the hypervisor hostname being "region!child@1" that looks like cellsv1 | |
| 16:39:18 | mriedem | so it seems you have n-cells running somewhere in your devstack setup | |
| 16:39:26 | sdague | melwitt: right, it was definitely a goofy thing | |
| 16:40:25 | raghav | mriedem: yes its running | |
| 16:40:41 | raghav | mriedem: i could see in screen | |
| 16:40:49 | mriedem | raghav: yeah, so you don't want that | |
| 16:41:00 | mriedem | raghav: that's going to cause you all kinds of confusion | |
| 16:41:06 | mriedem | so i'd start over w/o n-cell enabled | |
| 16:41:13 | raghav | mriedem: so what should i do now | |
| 16:41:38 | mriedem | raghav: restack w/o n-cell for one | |
| 16:41:41 | raghav | mriedem: in local.conf i have not enabled n-cell | |
| 16:42:19 | mriedem | raghav: well, it's not enabled by default, so something is running it in your setup | |
| 16:42:40 | mriedem | raghav: also, be aware that cells v2, which is required in ocata, is not the same as the nova-cells service, | |
| 16:42:44 | mriedem | or n-cell service in devstack | |
| 16:42:47 | mriedem | i know it's confusing | |
| 16:43:58 | raghav | mriedem: i have n-cells-region and n-cells-child running | |
| 16:45:06 | raghav | mriedem: if i re-stack again those will get enabled | |
| 16:45:58 | sdague | raghav: why do you have those running? | |
| 16:46:35 | raghav | mriedem: i dont know how they are running, i just stacked without enabling them | |
| 16:46:36 | melwitt | raghav: what's in your stack-screenrc? are there any n-cell* in there? | |
| 16:47:01 | raghav | melwitt: yes n-cell-region and n-cell-chile | |
| 16:47:08 | raghav | melwitt: yes n-cell-region and n-cell-child | |
| 16:47:08 | sdague | raghav: so... step one, please get back to a base clean environment | |
| 16:48:07 | melwitt | raghav: okay. so it looks like you definitely have remnants of an earlier install where n-cell was part of ENABLED_SERVICES | |
| 16:48:16 | mriedem | dansmith: did you still want a specific unit test for https://review.openstack.org/#/c/443403/11/nova/context.py ? | |
| 16:49:09 | openstackgerrit | Maciej Szankin proposed openstack/nova-specs master: Add use-local-scheduler spec https://review.openstack.org/438936 | |
| 16:49:15 | dansmith | mriedem: yes, I'm not sure why we wouldn't | |
| 16:49:20 | raghav | melwitt: how can i remove it | |
| 16:49:32 | dansmith | mriedem: are you doing both of those in a follow-up? | |
| 16:50:49 | mriedem | dansmith: i can do them in this change | |
| 16:51:16 | mriedem | raghav: maybe posting your local.conf in a gist would help us | |
| 16:51:29 | mriedem | raghav: personally i'd re-clone devstack from stable/ocata to make sure it's completely clean | |
| 16:51:32 | mriedem | in a new vm | |
| 16:53:13 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Spec to add per instance timeout for LM https://review.openstack.org/442809 | |
| 16:53:25 | melwitt | yeah, I'm not 100% an unstack.sh/stack.sh after killing processes would result in a fresh read of ENABLED_SERVICES | |
| 16:53:44 | mriedem | i would completely start over | |
| 16:53:44 | sdague | that should, but a ./clean.sh is even safer | |
| 16:53:54 | sdague | yeh, completely fresh not a bad idea either | |
| 16:53:56 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: Replace live migration steps and delays with memory iteration logic https://review.openstack.org/443339 | |