| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-20 | |||
| 17:55:05 | cfriesen | mriedem: just for info, the placement issue is https://bugs.launchpad.net/nova/+bug/1750623 | |
| 17:56:00 | sean-k-mooney | cfriesen: rebuilds on the same host are disabled by default correct so that bug will only be present if they are enabled? | |
| 17:57:42 | cfriesen | sean-k-mooney: are you thinking resize? | |
| 17:57:51 | sean-k-mooney | cfriesen: yes i am | |
| 17:58:09 | sean-k-mooney | specifcially https://docs.openstack.org/nova/queens/configuration/config.html#DEFAULT.allow_resize_to_same_host | |
| 17:58:20 | sean-k-mooney | but i guess there is not the same option for rebuild | |
| 17:58:41 | cfriesen | "rebuild" is by definition on same host, otherwise it's an evacuate | |
| 17:59:14 | sean-k-mooney | cfriesen: evacuate is a livemigration but yes rebild make sense on the same host as less work to do | |
| 17:59:35 | sean-k-mooney | a rebuild to another host would still be valid | |
| 18:00:03 | cfriesen | "nova evacuate" is not a migration, the host is already dead. really it should be called "resuscitate" | |
| 18:00:38 | sean-k-mooney | cfriesen: no you can evacuate hosts that are not dead for maintneance | |
| 18:00:53 | sean-k-mooney | at least via horizon | |
| 18:02:06 | cfriesen | sean-k-mooney: that's not the nova evacuate API though. | |
| 18:02:59 | cfriesen | sean-k-mooney: that's "nova host-evacuate" or "nova host-evacuate-live", which is done on the client side just to confuse things. | |
| 18:03:07 | sean-k-mooney | cfriesen: are you sure because i was pretty sure evacuate was ment to livemigrate off all instances on a singel host | |
| 18:03:12 | dansmith | sean-k-mooney: yes | |
| 18:03:25 | dansmith | sean-k-mooney: http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/ | |
| 18:04:07 | cfriesen | so dan, when do we rename evacuate to "resuscitate"? | |
| 18:04:10 | dansmith | if horizon has an evacuate button, I don't know what it does, but I would have assumed it is actually evacuate | |
| 18:04:24 | sean-k-mooney | dansmith: looks like the have renamed the horizon option to migrate host | |
| 18:04:40 | dansmith | cfriesen: the complication is that if you have instances on shared storage, evacuate is not resuscitate | |
| 18:04:42 | dansmith | or recreate | |
| 18:05:00 | dansmith | cfriesen: evacuate is the worst possible name, but changing it also brings confusion, IMHO | |
| 18:06:39 | cfriesen | dansmith: we're bringing instances back from the dead, so I think resuscitate works. if they've got shared storage they keep what they had, if not they get new rootfs | |
| 18:07:02 | sean-k-mooney | dansmith: so the evacuate option in old horizon now migrate host is only available when you mark a host as down but that does not mean nova-compute and all the vms on that host are dead. it just means the api introduces for the opnfv guest to aministativly set the host down has been called | |
| 18:07:11 | dansmith | it's no different from start from the user's perspective if they don't know what happend :) | |
| 18:07:26 | dansmith | cfriesen: that said, I don't want to change it now because of the confusion factor, so I shan't agree on naming | |
| 18:07:35 | cfriesen | fair enough | |
| 18:07:51 | dansmith | sean-k-mooney: that would be real nova evacuate if the host has to be marked as down | |
| 18:07:53 | sean-k-mooney | dansmith: i think the horizon nameing is confusing thing more because i dont know if they ment the same thing and nova evacuate or not | |
| 18:08:00 | dansmith | sean-k-mooney: and that means we reconstruct the instance, not migrate it | |
| 18:08:40 | sean-k-mooney | dansmith: but horizon in pike at least renamed that button form evacuate to migrate host | |
| 18:08:50 | cfriesen | sean-k-mooney: In pike at least, horizon lets you disable the service and then call "migrate host". I'm pretty sure this is just disabling it, not administratively setting it as "down". | |
| 18:09:14 | dansmith | yeah marked as down and disabled are different | |
| 18:09:21 | cfriesen | sean-k-mooney: yep, just confirmed this with pike. it's still up but disabled | |
| 18:09:26 | sean-k-mooney | cfriesen: yes so does migrate host via horixon actully migrate or does it do nova evacuate | |
| 18:09:42 | cfriesen | migrate (or live-migrate, not sure). not evacuate | |
| 18:10:09 | cfriesen | it's probably calling the same code as "nova host-evacuate" or "nova host-evacuate-live" | |
| 18:10:14 | sean-k-mooney | cfriesen: ok because before pike that button was called evacuate hence my confution | |
| 18:11:02 | cfriesen | yeah, horizon used the real logical meaning of evacuate, while nova didn't. | |
| 18:11:16 | sean-k-mooney | anyway didnt mean to distract. | |
| 18:11:49 | sean-k-mooney | dansmith: thanks for the blog post i think i have read it before you ill add it back to my book marks. | |
| 18:12:51 | cfriesen | anyone seen this running tox? "src/pcremodule.c:32:18: fatal error: pcre.h: No such file or directory" | |
| 18:13:40 | jaypipes | cfriesen: yes. install libpcre-dev | |
| 18:14:00 | jaypipes | cfriesen: should be fixed in the latest bin requirements thing, actually. | |
| 18:14:19 | jaypipes | cfriesen: or libpcre3-dev... can't remember. | |
| 18:14:34 | jaypipes | or pcre-devel on RH distros or something like that.. | |
| 18:14:52 | sean-k-mooney | cfriesen: jaypipes https://stackoverflow.com/a/22559967 | |
| 18:15:21 | cfriesen | pcre-devel looks promising | |
| 18:15:27 | sean-k-mooney | looks like its libpcre3-dev on ubuntu and pcre-devel on centos | |
| 18:18:00 | sean-k-mooney | cfriesen: i think the new requirement is comming from whereto which pulls in python-pcre | |
| 18:18:10 | efried | cfriesen: Yeah, you need a n... what sean-k-mooney said | |
| 18:18:36 | efried | cfriesen: I think you need to install libpcre3-dev | |
| 18:19:57 | sean-k-mooney | cfriesen: also be aware python-pcre does not appear to work on 32bit systmes. i was causeing mriedem dev enviroment to explode be case an enum value was more then could fit in 32Bits | |
| 18:24:22 | cfriesen | installed the new package, things are working now. | |
| 18:24:37 | cfriesen | who develops on 32-bit anymore? :) | |
| 18:26:11 | jroll | <mriedem> this is a 32 bit vm i guess, so that's my problem | |
| 18:26:13 | jroll | that guy does :P | |
| 18:29:17 | TheJulia | heh | |
| 18:29:35 | sean-k-mooney | well all i know is nova is not tested in the gate with a 32bit os so even if it works as far as im concerend its broken untill the ci says otherwise | |
| 18:32:06 | sean-k-mooney | is the fake driver https://github.com/openstack/nova/blob/master/nova/virt/fake.py the minimal working example of a virt driver? | |
| 18:39:17 | mriedem | didn't realize it was a 32bit image | |
| 18:39:20 | mriedem | oops | |
| 18:41:21 | mriedem | it's a snow day here today and the family in the house is driving me a little crazy | |
| 18:41:39 | cfriesen | mine are home all week, school's on break | |
| 18:42:12 | sean-k-mooney | cfriesen: so you looking forward to the week away next week then | |
| 18:42:41 | doude | jaypipes: thanks for your attention. It started failing since begining of November with patch https://review.openstack.org/#/c/515916/ | |
| 18:44:04 | sean-k-mooney | doude: any chance we could move contrial to an os-vif plugin in the future | |
| 18:45:02 | sean-k-mooney | doude: it would avoid having to make that type of change in the nova tree in the future | |
| 18:45:33 | doude | yes we already started the work for the dpdk case with VhostHostUser type https://github.com/openstack/nova/commit/1ba834c0e48c85bf84ff3ec62fce0d5cb5c39c6d#diff-f78fb1f9dab4cca6e24c53779de7cfcf thanks to mhenkel | |
| 18:45:56 | doude | but still need to do the work for the TAP VIF type | |
| 18:46:15 | sean-k-mooney | doude: ah cool | |
| 18:46:18 | doude | I plane to work on it for R | |
| 18:46:36 | mnaser | mriedem: if you have a few minutes .. i think the fix should not be backported to stable/ocata because the bug doesn't exist there. the commit which "introduced" this bug is https://github.com/openstack/nova/commit/63805735c25a54ad1b9b97e05080c1a6153d8e22 | |
| 18:46:50 | mnaser | which was in pike, before that, the api layer never did a reserve on the volume, the compute would do it | |
| 18:47:21 | mnaser | and because of this, the delete will always clean it up because the detach will happen inside the compute | |
| 18:47:38 | mriedem | and if we failed in scheduling, the volume isn't reserved via the api anyway | |
| 18:47:39 | mriedem | works for me | |
| 18:47:48 | mnaser | okay cool ill drop them | |
| 18:48:03 | mnaser | ill add a note to teh bug | |
| 18:50:28 | mriedem | mnaser: thanks | |
| 18:50:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Only attempt a rebuild claim for an evacuation to a new host https://review.openstack.org/546268 | |
| 18:50:43 | mriedem | cfriesen: ^ easy peasy | |
| 18:51:24 | mnaser | dropped and added a note to the bug .. now to check why the patches didn't pass | |
| 18:54:38 | mriedem | mnaser: actually there is another case which could have happened in ocata, | |
| 18:55:10 | mriedem | mnaser: bfv where nova creates the volume and attaches it, then driver.spawn fails, the compute puts the instance into ERROR state and resets the host/node to None | |
| 18:55:23 | mriedem | so if you go to delete the instance, instance.host is None but you could have a volume attached | |
| 18:55:54 | mriedem | mnaser: however, that's also being handled compute-side with this https://review.openstack.org/#/c/545087/ | |
| 18:57:01 | mnaser | fun times.. | |
| 18:57:19 | sean-k-mooney | mriedem: ya that was/is an annowing edge case as you end up with a load of volumes if spawning fails often enven if you asked for the volume to be delted when the vm is deleted | |
| 18:57:33 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Filter Resource Provider List for Traits https://review.openstack.org/546009 | |
| 18:57:52 | efried | cdent, jaypipes, edleafe: Fixed that to do 400s on invalid traits ^ | |
| 18:58:26 | cdent | roger | |
| 18:59:31 | edleafe | efried: ack | |
| 19:01:05 | sean-k-mooney | efried: is the only difference eventually between /allocation_candidates and /resource_providers going to be that allocation candidate support checking for avilable capasity to claim resouces form the resouce providers | |
| 19:01:39 | efried | sean-k-mooney: No, I think there's lots of differences. | |
| 19:02:12 | efried | sean-k-mooney: GET /resource_providers actually already supports capacity filtering | |
| 19:02:15 | edleafe | efried: https://www.youtube.com/watch?v=galB-OUPfBg | |
| 19:02:21 | efried | sean-k-mooney: But there's a lot it doesn't do. | |
| 19:02:40 | efried | Before I clicked, I *knew* it had to be an Airplane scene. | |