| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-20 | |||
| 16:18:58 | dansmith | that would suck to have to add another mapping :/ | |
| 16:18:59 | melwitt | no we don't, token only | |
| 16:19:10 | dansmith | well then I'm pretty -1 on that plan | |
| 16:19:19 | sean-k-mooney | we dont need to add anything in nova | |
| 16:19:29 | dansmith | you could scatter/gather to find it | |
| 16:19:47 | sean-k-mooney | to find the inial url | |
| 16:19:53 | sean-k-mooney | ya you could | |
| 16:19:54 | dansmith | sean-k-mooney: that's not necessary, because we given them the url from the proxy anyway | |
| 16:20:04 | dansmith | sean-k-mooney: belmiro just doesn't want that | |
| 16:20:26 | dansmith | presumably because he doesn't want to run multiple services and have multiple firewall rules | |
| 16:20:29 | melwitt | oh yeah, I guess he said as much already (scatter gather) | |
| 16:21:03 | sean-k-mooney | ya if he does not want to run multiple proxy instances | |
| 16:21:10 | dansmith | melwitt: ah, I hadn't even clicked the link, but yeah | |
| 16:21:52 | melwitt | we could add another config option! for choosing whether you want a central console auth | |
| 16:21:55 | dansmith | melwitt: I think we'd want that as a toggle | |
| 16:21:57 | dansmith | yeah | |
| 16:22:11 | dansmith | because if you want most efficient and least-shared, you don't want it doing that | |
| 16:22:18 | melwitt | yeah | |
| 18:47:16 | belmoreira | bauzas dansmith melwitt sean-k-mooney I see that you discussed the vncproxy topic. Sorry I needed to leave the office (end of the working day here). | |
| 18:48:03 | sean-k-mooney | no worries. did you add it to the ptg adgenda | |
| 18:48:47 | belmoreira | not yet | |
| 18:48:55 | sean-k-mooney | was dansmith correct when ne assumed you did not want to run multiple novnc proxy instance (1 per cell) | |
| 18:49:22 | belmoreira | let me explain my concern. | |
| 18:49:27 | sean-k-mooney | or are you just concerned about how many port you need to open in the fire wall | |
| 18:49:29 | sean-k-mooney | sure | |
| 18:49:42 | belmoreira | having the vncproxy per cell in theory is good, because we are sharding the service per cell. But it depends in the deployment... For deployments that only expose the console_url in the internal network is ok. | |
| 18:50:05 | belmoreira | However, in my case I need to expose the vncproxy externally. Having only one set os vncproxies allow me to open only one port in the external firewall and have only one console_url address masked by the load balancer. | |
| 18:50:27 | belmoreira | The current approach of having a vncproxy per cell, means that I will have a different console_url per cell. Mapping this with the LB I will need at least to have a different frontend per cell. If I do it per port is a lot of open ports... | |
| 18:50:38 | sean-k-mooney | well you could | |
| 18:50:49 | sean-k-mooney | you can use a reverse proxy instead of a loadblance | |
| 18:51:06 | sean-k-mooney | and expose only one port and have it route the reuest to the backend based on a partil path match | |
| 18:51:17 | sean-k-mooney | or using a subdomain per cell | |
| 18:51:53 | sean-k-mooney | so the reverse proxy is the only thing you open the firewall too and have it dispatch internally to the per cell proxy based on a part of the url | |
| 18:51:56 | belmoreira | true, but in those cases we are also exposing the cell architecture to the user | |
| 18:52:21 | sean-k-mooney | yes at least to the extend needed to match on the url | |
| 18:52:30 | belmoreira | the console_url will be different per cell | |
| 18:52:39 | sean-k-mooney | ya it would be | |
| 18:53:02 | sean-k-mooney | so if we allowed a singel vnc proxy to connect to any of the cell dbs that would be your preference | |
| 18:54:27 | sean-k-mooney | belmoreira: dansmith and melwitt can correct me if i get this wrong but i think what they were suggesting was add a config option to denote if the novnc proxy should connect to on celldb or multiple and having it do a scater gater request to each cell db in the case of multi cell mode | |
| 18:55:07 | belmoreira | having that possibility would be great. I already patch it and have it working in my test infrastructure | |
| 18:55:19 | sean-k-mooney | belmoreira: that would assume that the novnc proxy can actully connect to all the hyperviors in any cell but i belive that is the cause for your env right | |
| 18:56:06 | belmoreira | yes | |
| 18:58:02 | belmoreira | my ideal setup is to have a set of vncproxies that can connect to any hypervisor in the region | |
| 19:00:10 | sean-k-mooney | ya which this would give you | |
| 19:00:51 | sean-k-mooney | i think the main issue is from the consol url we dont know which instance it for without looking up the token and to do that we need to check the cell db | |
| 19:01:10 | sean-k-mooney | so in this case we would need to check multiple cell dbs which increase the load on the db since only one will have the token | |
| 19:01:30 | sean-k-mooney | so we would not want to do that by default but we could allow you to opt into it | |
| 19:02:31 | belmoreira | basically is something similar to the code that I pointed earlier | |
| 19:03:01 | belmoreira | I agree that this shouldn't be the default. Small deployments would not benefit from it | |
| 19:04:59 | dansmith | yeah that's what I meant.. scatter/gather to find the cell that a token is in is not very efficient, but I think the alternative is a lot more work for the few people that might want it | |
| 19:05:19 | dansmith | I'd definitely prefer solving that at the load balancer level with a url suffix or something like that, | |
| 19:05:44 | dansmith | so I think adding a config to scatter/gather is okay and let's not add a new mapping table just for this until/unless performance becomes an issue | |
| 19:08:42 | belmoreira | I think it would be ok. Consoles are not a popular api call. I can report after in terms of performance. | |
| 19:11:47 | belmoreira | thank you all. I can add this into the ptg agenda we need to discuss it more | |
| 19:13:46 | belmoreira | I need to leave now. thank you again | |
| 21:15:36 | zigo | What's the problem with https://review.opendev.org/c/openstack/nova/+/809759 ? (ie what's happening with this nova-tox-validate-backport check?) | |
| 21:57:22 | artom | zigo, it checks that the "source" hash is merged in an upstream branch | |
| 21:57:45 | artom | zigo, so if you cherry pick from wallaby to victoria, the victoria check will fail until the wallaby one merged | |
| 21:59:07 | artom | zigo, ah, no, I had the completely wrong idea without even opening the link | |
| 21:59:11 | artom | "Stable branch requires either cherry-pick -x headers or [stable-only] tag!" is what explains it | |
| 21:59:15 | artom | In the job output | |
| 22:28:08 | clarkb | sounds like someone needs to update the bot or fix the job. Cherrypicking the gitreview change doesn't make sense as it is different than masters | |
| 22:28:30 | clarkb | in my personal opinion it seems like overkill to make people explicitly tag stuff stable only | |
| 22:28:38 | clarkb | its clearly stable only and reviewers can see that why do we need CI to -1? | |
| 23:08:48 | artom | clarkb, it's really a commit message linter, if you think about it | |
| 23:09:11 | artom | I'm very *shrug* about it, though I'd tend to err on the side of "more linting" over "less linting" | |
| #openstack-nova - 2021-09-21 | |||
| 01:34:21 | opendevreview | Eric Xie proposed openstack/os-vif master: Fix typos https://review.opendev.org/c/openstack/os-vif/+/810137 | |
| 07:15:59 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: [stable-only]Update .gitreview for stable/xena https://review.opendev.org/c/openstack/nova/+/809759 | |
| 07:16:30 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: [stable-only]Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/nova/+/809760 | |
| 07:16:36 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: [stable-only]Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/nova/+/809760 | |
| 07:17:00 | gibi | zigo, artom, clarkb: I've updated the stable/xena setup patches | |
| 07:17:51 | gibi | I think in general the backport check helps enforceing that we only merge patches in a good branch order | |
| 07:18:07 | gibi | new stable branch setup seems to be an edge case | |
| 07:19:26 | bauzas | good morning folks | |
| 07:20:41 | bauzas | gibi: hmmmm | |
| 07:21:18 | gibi | bauzas: good morning | |
| 07:21:28 | bauzas | gibi: modifying the commit msg would mean that the CI job would accept it ? | |
| 07:21:53 | bauzas | haha | |
| 07:21:55 | bauzas | "Stable branch requires either cherry-pick -x headers or [stable-only] tag!" | |
| 07:22:03 | gibi | bauzas: yes, either the patch needs to have a cherry-picked from line where the hash points to a merged change or the patch needs to state that it is stable only | |
| 07:22:09 | bauzas | saw in https://zuul.opendev.org/t/openstack/build/97c7712edfe34c5386c0cc2fc37ef466 | |
| 07:22:20 | bauzas | gibi: kk, +2 then | |
| 07:24:02 | bauzas | gibi: looks like we need to do this also for all of the changes https://review.opendev.org/q/owner:infra-root%2540openstack.org+(project:openstack/nova+OR+project:openstack/placement)+is:open | |
| 07:28:51 | bauzas | ah no | |
| 07:29:01 | bauzas | just rechecks because of timeouts in placement | |
| 07:34:53 | gibi | I think we dont have the backport check in placement | |
| 07:35:31 | gibi | the placement lower constraint timeout needs https://review.opendev.org/c/openstack/placement/+/810001 to merge first | |
| 07:48:17 | bauzas | gibi: this is correct, hence my "ah no" :) | |
| 07:48:32 | bauzas | (placement doesn't verify the backports) | |
| 07:49:12 | bauzas | gibi: and shit, you're right | |
| 07:49:18 | bauzas | we need a second core | |
| 07:51:17 | bauzas | lyarwood: I know your placement knowledge is the same than old greek, but we'd appreciate a +W for a dependency bump https://review.opendev.org/c/openstack/placement/+/810001 in order to fix the gate | |
| 07:56:32 | gibi | bauzas: also the stable team needs to make a short term decision what to do with the lower constraint bump on stable/xean | |
| 07:56:53 | bauzas | we have an open change about it | |
| 07:56:54 | gibi | it is not really allowed, but we can push an RC2 to be in the xena release | |
| 07:57:11 | bauzas | https://review.opendev.org/c/openstack/placement/+/787863 | |
| 07:57:28 | gibi | yeah that also possible | |
| 07:57:32 | gibi | turning off the job | |
| 07:57:57 | bauzas | honestly, I have no opinion and this could be discussed at the PTG | |
| 07:58:14 | bauzas | but we need to consider the bump, agreed | |