| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-20 | |||
| 17:36:01 | dansmith | cdent: _would_ you do it? :) | |
| 17:36:01 | cfriesen | mriedem: yeah, that's what I was thinking | |
| 17:36:32 | cfriesen | mriedem: we need to validate the image properties of the new image against the current host though | |
| 17:37:13 | cdent | dansmith: I'm on the phone, so don't want to make promises, but if it needs someone it can probalby be me | |
| 17:37:56 | edleafe | dansmith: cdent: I may also have bandwidth for that | |
| 17:38:20 | dansmith | edleafe: that'd be cool | |
| 17:40:19 | mriedem | cfriesen: as far as i can tell, we don't do any manipulation of the request spec for rebuild with a new image such that we try to fake out placement to not try and double allocate the vcpu/memory_mb/disk_gb | |
| 17:40:48 | mriedem | we do tell the scheduler exactly which host/node we want, and we tell some filters to not run on it again, | |
| 17:41:10 | mriedem | but if placement doesn't return the source host then we'll have novalidhost and we can't rebuild with the new image | |
| 17:42:52 | mriedem | if placement does return the node we want, we don't double the allocations in placement, but we do attempt a claim on the compute as you found out | |
| 17:43:24 | mriedem | if the node is full, we likely won't even get to the compute to attempt the faulty claim... | |
| 17:43:37 | mriedem | b/c placement would have filtered it out | |
| 17:44:30 | cfriesen | before placement did the "_nova_check_type" flag tell us to skip over the resource filters? | |
| 17:44:34 | cdent | dansmith, edleafe: sorry wasn't really paying attention, which thing is this that needs a doer? | |
| 17:44:58 | mriedem | cfriesen: that flag was added long after placement was used in the scheduler, | |
| 17:45:07 | cdent | but am off phone now | |
| 17:45:08 | cfriesen | ah, okay | |
| 17:45:09 | mriedem | but yes that flag is used to tell which scheduler filters to run, and to not make a claim in placement | |
| 17:45:19 | mriedem | but it doesn't say 'don't use placement at all' | |
| 17:45:39 | cfriesen | open another bug? | |
| 17:45:50 | mriedem | request_is_rebuild could probably be used to completely bypass placement and just pull the compute node record from the db | |
| 17:46:05 | dansmith | cdent: the member_of aggregate add to allocation_candidates api | |
| 17:46:05 | mriedem | cfriesen: idk | |
| 17:46:06 | jaypipes | doude: is this something that only recently started failing? I'm struggling to pinpoint when the privsep (which from what I can tell has used msgpack for a while) started failing | |
| 17:46:33 | mriedem | cfriesen: after working on and breaking and regressing and trying to fix this rebuild with new image + scheduler thing for like the last 4 months, i don't really have any stomach for it anymore | |
| 17:47:12 | mriedem | cfriesen: if you want to report a bug just so it's tracked as a known issue, sure | |
| 17:47:19 | cdent | dansmith: thanks. edleafe and I will wrestle for it in dublin | |
| 17:47:51 | dansmith | jaypipes: it'd be after mikal privsep'd the libvirt driver recently | |
| 17:47:56 | dansmith | cdent: rock on | |
| 17:48:00 | cfriesen | mriedem: yeah, that's what I was thinking. we have a customer that'll probably end up complaining about it in a year or so when they get to pike | |
| 17:48:44 | dansmith | jaypipes: I'm sure we have no real tests for that code and that driver, so it popped up when we released queens and someone tried it | |
| 17:49:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Drop API compat handling for old compute error cases https://review.openstack.org/546256 | |
| 17:49:50 | mriedem | cfriesen: it's not just pike | |
| 17:50:02 | mriedem | cfriesen: that original regression was for a cve, | |
| 17:50:06 | mriedem | that went back to newton upstream, | |
| 17:50:08 | mriedem | and further downstream | |
| 17:50:14 | mriedem | depending on how long you support old relases | |
| 17:50:16 | mriedem | *releases | |
| 17:50:19 | mriedem | it's the cve that keeps on giving | |
| 17:50:32 | mriedem | i guess the only difference with pike would be placement.. | |
| 17:50:36 | mriedem | in the scheduler i mean | |
| 17:52:16 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Provide error codes for placement API https://review.openstack.org/418393 | |
| 17:53:15 | cfriesen | mriedem: right, just saw your comment. will have to see if we've backported the bug. | |
| 17:53:34 | mriedem | i'm going to go eat my feelings | |
| 17:54:02 | sean-k-mooney | anyone know if there is documentation on what constitutes a minimal legal virt driver implementation? | |
| 17:54:29 | penick | As well you should. | |
| 17:55:05 | cfriesen | mriedem: just for info, the placement issue is https://bugs.launchpad.net/nova/+bug/1750623 | |
| 17:55:05 | openstack | Launchpad bug 1750623 in OpenStack Compute (nova) "rebuild to same host with different image shouldn't check with placement" [Undecided,New] | |
| 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 | |