| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-18 | |||
| 13:54:37 | sean-k-mooney | one of the fixes that was only a partial fix was to move that later so that the dma region could be allocate before the cpus are pinned | |
| 13:54:55 | sean-k-mooney | that was done in https://libvirt.org/git/?p=libvirt.git;a=commit;h=7e72ac7878 | |
| 13:55:24 | sean-k-mooney | but that was backin 2014 so it obviouslyu was not a full fix or it was broken angain later | |
| 13:56:01 | rmart04 | OK :/ | |
| 13:59:57 | sean-k-mooney | rmart04: this was the final kernel fix i belive https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee6268ba3a68 | |
| 14:00:01 | sean-k-mooney | that was in 4.19 | |
| 14:00:15 | rmart04 | ah ok, my bad I said 4.14 earliar | |
| 14:01:00 | rmart04 | How easy is it to find out whether it was backported in C7? | |
| 14:03:43 | sean-k-mooney | its in the rhel kernel-3.10.0-957.26.1.el7 pacakge and needs libivrt ibvirt-4.5.0-13.el7 or higher | |
| 14:06:26 | rmart04 | OK thats amazing thank you. I think i'll see how far we are away from those package versions and expidite moving to them | |
| 14:46:06 | mordred | sean-k-mooney: you remember every conversation we've had about things from the past, right? | |
| 14:46:29 | sean-k-mooney | mordred: ocourse i was right and you were .... | |
| 14:46:42 | sean-k-mooney | mordred: is there a converstation in partcalar? | |
| 14:46:47 | mordred | sean-k-mooney: what's the story with the api_servers config option for glance - we've asked about deprecating/removing it and getting rid of the idea of being a poor-mans-client-side-load-balancer | |
| 14:47:03 | mordred | but I can't remember where the discussion got to on that | |
| 14:47:33 | sean-k-mooney | right we wanted to not do the crappy round robin thing we do in nova anymore | |
| 14:47:37 | mordred | (I'm trying to help cyborg with their glance support, but since it's copied from nova I wnat to make sure anything I do would eventually be transferrable back to nova) | |
| 14:47:41 | sean-k-mooney | i belive dansmith was onboard with that | |
| 14:47:54 | sean-k-mooney | i dont know if we have done anything to change it in nova | |
| 14:47:58 | mordred | yeah. I guess I should look to see if we marked the option as deprecated yet | |
| 14:48:15 | sean-k-mooney | mordred: efried did bring it up but then he had to move on | |
| 14:48:38 | dansmith | I was not on board with removing it, | |
| 14:48:46 | dansmith | but I think I was the only nova person in that position | |
| 14:49:01 | mordred | Support for image service configuration via standard keystoneauth1 Adapter | |
| 14:49:02 | mordred | options was added in the 17.0.0 Queens release. The api_servers option was | |
| 14:49:04 | mordred | retained temporarily to allow consumers time to cut over to a real load | |
| 14:49:06 | mordred | balancing solution. | |
| 14:49:14 | mordred | there's the help text- so it implies that post-queens its existence is temporary | |
| 14:49:24 | mordred | but with no official deprecation story :) | |
| 14:50:00 | mordred | basically - I would like to either kill this or if we can never kill it support it in ksa so that we can stop it with copying the round-robin code everywhere | |
| 14:50:02 | sean-k-mooney | dansmith: oh i just rememebered you had an opion and i generally rememeber when you dont like something so i assume you were ok with it | |
| 14:51:08 | efried | I would have deprecated it if I had been allowed to. I may be misremembering, but I think we put out a RFC on the ML and someone put up their hand and said they were still using it. Might even have been dansmith :P | |
| 14:51:45 | mordred | efried: :) | |
| 14:51:48 | dansmith | no, wasn't me, | |
| 14:52:14 | dansmith | but there are people in redhat, tripleo and edge-related IIRC, that definitely don't want to lose it | |
| 14:52:33 | sean-k-mooney | because its used for rabbit mq? | |
| 14:52:34 | efried | Also, I think I commented on the cyborg stuff when it went in, saying they really shouldn't be carrying all this warty stuff over from nova -- that is, they *never* should have supported [glance]api_servers. But I think they wound up just merging it for expediency. | |
| 14:52:40 | mordred | I thought all those people thought k8s was super sexy - why is a lb hard? | |
| 14:53:04 | dansmith | the history is a little dim for me without digging that back up, but basically for a very small number of remote edge machines, a "real load balancer" is not an option and having nova be able to try multiple glance servers is a major win | |
| 14:53:15 | mordred | nod | |
| 14:53:26 | efried | If ^ is not an issue for cyborg, I say they kill it, with prejudice. | |
| 14:53:33 | mordred | ok - that's fair enough I suppose | |
| 14:53:39 | sean-k-mooney | dansmith: really? ha proxy is pretty light weight | |
| 14:53:59 | efried | esp if it means they're no longer anchored to ksa and can cut over to sdk | |
| 14:54:04 | sean-k-mooney | im not sure i by that given it will be handleing very little traffic | |
| 14:54:14 | dansmith | sean-k-mooney: it's not just the haproxy of course, it's the config, the need for shared L2 failover VIP, pacemaker to manage it, etc | |
| 14:54:36 | dansmith | it's all the complexity that comes with deploying that architecture | |
| 14:55:11 | mordred | sure. although I'll again point my fingers at all of the people rushing to install k8s in those contexts so they should have an easier time of it | |
| 14:55:53 | dansmith | I haven't heard any consistent plans about how to do that in a non-toy arrrangement, fwiw.. lots of chest-puffing and hand waving | |
| 14:56:01 | dansmith | not that it doesn't exist, but just I haven't heard a clear plan | |
| 14:56:09 | dansmith | and all I'm doing is communicating the request | |
| 14:56:14 | mordred | dansmith: fair | |
| 14:56:39 | efried | If there really is a need for api_servers, then I guess we should support it in sdk so that's not something that blocks $consumer from cutting over. | |
| 14:56:43 | mordred | I guess from my end I actually don't care other than wanting to mock people who think they can deploy a cloud but can't deploy a load balancer ... | |
| 14:56:46 | mordred | efried: exactly | |
| 14:56:49 | dansmith | personally, I do not understand how relying on a centralized (even if HA'd) load balancer is better than the clients knowing the options and being able to help themselves out of a failure to talk to one | |
| 14:56:51 | mordred | if this is a thing that has to stay around | |
| 14:56:52 | efried | Easy for me to say, I won't be the one doing it. | |
| 14:57:01 | sean-k-mooney | dansmith: ok that more hevy wait then kolla does so i guess that is different in ooo | |
| 14:57:15 | mordred | then I want to just say screw it and support it in the client layer | |
| 14:57:34 | efried | dansmith: ftr, api_servers isn't really a load-balancer. I think it's a deafdumbandblind round robin. | |
| 14:57:36 | mordred | it's way too fundamental of a piece of config to stich in in the way it's being done | |
| 14:57:44 | mordred | a very dumb one | |
| 14:57:46 | mordred | it doesn't do retries | |
| 14:57:53 | efried | or failovers, or anything. | |
| 14:57:55 | mordred | yah | |
| 14:57:59 | efried | You simply get the next one on each subsequent api req | |
| 14:58:14 | mordred | it's probalby _less_ HA | |
| 14:58:17 | efried | heh | |
| 14:58:22 | efried | indeed | |
| 14:58:37 | mordred | maybe it's time to one-more-time go to the mailing list | |
| 14:58:40 | dansmith | I understand, but it still gets you 66% success instead of zero if 1/3 is down, and it could be made to do the right thing | |
| 14:58:44 | mordred | maybe life has changed for peopel since queens | |
| 14:58:56 | dansmith | mordred: this was not queens when we had this discussion, fwiw | |
| 14:58:59 | sean-k-mooney | mordred: for the better? | |
| 14:59:09 | mordred | dansmith: no? that's the release mentioned in the nova config docs | |
| 14:59:14 | dansmith | mordred: anyway, don't use my name in the email, I'm not prepared to argue for it anymore | |
| 14:59:21 | mordred | dansmith: I won't | |
| 14:59:28 | dansmith | mordred: that's when it was deprecated I think, but the concern about removing it was within the last year | |
| 14:59:34 | mordred | nod | |
| 14:59:49 | dansmith | but also, we were told that it was going to go away regardless so those people are assuming it's going or gone I think | |
| 15:00:06 | mordred | oh - well that's something perhaps | |
| 15:00:27 | artom | stephenfin, did the flavor extra spec validation spec ever go anywhere? | |
| 15:00:38 | stephenfin | artom: it landed last cycle | |
| 15:00:47 | stephenfin | API microversion 2.84, I think? | |
| 15:01:43 | artom | stephenfin, 2.86, but yeah, thanks for the pointer | |
| 15:01:56 | artom | So we could use that for the cpu_dedicated_mask, right? | |
| 15:02:08 | efried | I don't see a patch (at least owned by me) proposing removing it. | |
| 15:02:08 | efried | Deprecate: https://review.opendev.org/#/c/692227/ (merged) | |
| 15:02:09 | artom | Context is my latest comment on https://review.opendev.org/#/c/468203/15 | |
| 15:03:19 | efried | Comments in above patch contain ML links mordred | |
| 15:03:45 | efried | and also refers to some people who wanted to keep it. | |
| 15:04:04 | stephenfin | artom: fair comment. In the middle of something at the moment but I'll get a reply to it | |
| 15:04:30 | artom | stephenfin, no rush. Today's my "upstream day", trying to do some reviews where I can :) | |
| 15:04:30 | stephenfin | we can't rely on the validation though, mind you, since it's an API change | |
| 15:04:42 | stephenfin | *in an API microversion | |
| 15:07:55 | mordred | efried: ooh! so it is deprecated! | |
| 15:08:42 | mordred | efried: how many releases do we have to wait to remove a deprecated thing? can we remove that now in victoria? or do we have to wait until w? | |
| 15:09:25 | dansmith | mordred: should probably ask the ptl | |
| 15:10:15 | stephenfin | mordred: it's six months or one release, whatever is greater | |