Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-20
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
07:58:25 gibi so 1) bump lower constarint and release RC2 so we are not breaking stable policy abour reqs 2) try to pin virtualenv during tox installation to avoid unpinned setuptools on stable (this is the long term solution) 3) turn off the lower job
07:59:27 gibi and the problem is not placement specific but hitting a lot of projects
07:59:31 gibi nova is not impacted
07:59:44 gibi so a common solution would be good
08:20:18 bauzas gibi: let's discuss this during our meeting tonight
08:20:26 gibi sure
08:20:35 gibi bauzas: btw would you like to take over charing of the meeting?
08:20:44 bauzas gibi: I was thinking about it
08:20:53 bauzas I can do it :)
08:20:55 gibi elodilles: will you be available on todays meeting to talk about the stable req bump problem?
08:21:04 gibi bauzas: then I officially give you the baton :)
08:21:14 bauzas huuuuuuuuuuh
08:23:00 bauzas https://www.youtube.com/watch?v=43RID9cIEAE
08:23:05 bauzas DOOOOOH
08:24:01 gibi bauzas: https://review.opendev.org/c/opendev/irc-meetings/+/810165
08:25:16 bauzas gibi: thanks, was looking on it...after finding the Simpson video :)

Earlier   Later