| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-03 | |||
| 13:13:36 | stephenfin | Firefox insisted on me installing stuff | |
| 13:15:13 | artom | stephenfin, yeah, I ended up installing the client | |
| 13:15:21 | artom | Neither Chrome nor Firefox were working | |
| 13:15:32 | artom | FWIW, Jitsi was just fine in the browser *ahem AHEM* | |
| 13:15:34 | artom | ;) | |
| 13:15:59 | liuyulong | gibi, alex_xu, meetpad does not work fine if without a proxy. So I setup a socket5 proxy VM from a public cloud in Singapore, it does not work fine either. The voice of the meeting was not very clear. | |
| 13:17:26 | gibi | liuyulong: thanks for the info. we switched to zoom | |
| 13:22:35 | stephenfin | I assume I'm the only that is seeing a stutter every now and then? | |
| 13:30:57 | stephenfin | artom: I can still hear everyone | |
| 13:31:02 | stephenfin | so just you | |
| 13:31:07 | artom | stephenfin, I know | |
| 13:31:51 | dansmith | gibi: I just continue to get a spinning "connecting" trying to join the juno zoom room | |
| 13:32:07 | dansmith | ah, here we go.. it's crazy slo | |
| 13:33:50 | gibi | dansmith: I'm glad you could join | |
| 13:34:10 | dansmith | gibi: well, it is still just "connecting" and I have audio, but no video and no window to mute myself or anything like that | |
| 13:34:25 | dansmith | and I can't quit :) | |
| 13:34:46 | gibi | dansmith: strange, the room run well so far | |
| 13:34:54 | dansmith | how many people are in it? | |
| 13:35:59 | gibi | 23 | |
| 13:40:48 | gibi | dansmith: now you are in! | |
| 13:41:00 | dansmith | gibi: on a different computer :/ | |
| 13:41:12 | gibi | :/ | |
| 13:49:13 | bauzas | gosh, I'm seeing double now | |
| 13:52:17 | kashyap | For me audio is completely lost; /me just joined shortly... | |
| 13:52:41 | kashyap | Joinied via Linux Zoom app. (Yes, yes, I tried the "Windows solution" - turned it off and turned it back on) | |
| 13:53:35 | kashyap | Ah, fixed | |
| 13:56:13 | kashyap | sean-k-mooney: Are we talking about default machine type change? | |
| 14:08:00 | dansmith | For anyone that was suffering the same thing as me, | |
| 14:08:35 | dansmith | the only way I was able to get zoom to not hang on connect is to start zoom itself, grab the meeting ID out of the link, and join the conference by id instead of the automatic linky thing | |
| 14:08:53 | dansmith | on my other machine just clicking the link works fine, so I dunno if it's a browser thing or a zoom thing or what | |
| 14:09:25 | sean-k-mooney | dansmith: are you using firefox or chome | |
| 14:09:34 | sean-k-mooney | chrome seam to be working better for people | |
| 14:09:45 | dansmith | chrome (of course) and I've never had this problem with zoom until today | |
| 14:09:52 | sean-k-mooney | that said i clinked the screen share button just now and it hard locked | |
| 14:10:18 | sean-k-mooney | is there a way to get the tile view of multiple people by the way | |
| 14:10:45 | sean-k-mooney | its nice to be able to see people to see queue of if they are trying to speak so i dont speak over people | |
| 14:12:03 | sean-k-mooney | if that is only in the app i might download the flatpack or snap assuming there is one | |
| 14:12:40 | mordred | artom: left a comment on https://review.opendev.org/#/c/733151 - thanks for working on that! | |
| 14:12:43 | gibi | sean-k-mooney: there is gallery view in the app (linux) | |
| 14:14:53 | artom | mordred, that was super quick, thank you! | |
| 14:15:31 | artom | mordred, so I'm just starting to audit the pre-2.72 stuff (that's where gtema said you stopped) in sdk and catching it up with WIP patches where I can | |
| 14:15:44 | mordred | artom: cool | |
| 14:16:22 | sean-k-mooney | gibi: yep that is what i was looking for | |
| 14:17:46 | gibi | sean-k-mooney: I'm usign the deb package from the zoom webpage | |
| 14:18:48 | sean-k-mooney | ya i might try that just installed the flatpak | |
| 14:18:55 | sean-k-mooney | if it does not work ill grab the deb | |
| 14:23:46 | sean-k-mooney | hehe yes i can definetly typo lots of stuff | |
| 14:29:07 | rouk | sean-k-mooney I narrowed down that metadata issue, it gets fixed when I point nova-api to nova db instead of nova_cell0, it's not selecting the cell for some reason in a single cell deployment (which has 2 now, cause cell0 is mandatory), where does the cell db get selected? Everything else seemed to go to the right place, but block_device_mapping reads are going to a different db than writes. | |
| 14:32:08 | sean-k-mooney | ok so the block device info is only in the cell db not the api db | |
| 14:37:13 | rouk | So... What's the fix? Is it broken? Am I using it wrong? | |
| 14:38:06 | sean-k-mooney | sorry im currently in the nova call. but ill try and take a look when its done | |
| 14:39:56 | rouk | Yeah sure thing, for now I have nova-api configured to use the nova db, instead of nova_cell0, which "fixes" the issue for now. But maybe that breaks other things I'm not aware of. It's just a dev location so I don't mind if I destroy the db. | |
| 14:41:02 | sean-k-mooney | that will only work for a singel cell deployment | |
| 14:41:33 | sean-k-mooney | you can deploy the metadata serivce seperatly and you can deploy a different metata api instance per cell | |
| 14:46:51 | rouk | Yeah, but in a single cell deployment should it be writing to nova then trying to read the data from nova_cell0? Looks like something has to be wrong. | |
| 14:47:17 | rouk | New data shows up in nova, API tries to read it from nova_cell0 and never sees it. | |
| 14:55:41 | sean-k-mooney | so the correct work around is to deploy a seperate metadta service and point it to the cell db | |
| 14:56:00 | sean-k-mooney | but keep the nova-api actully poining only at the api db | |
| 14:56:20 | sean-k-mooney | but we should look into this and try and fix it so that is not required | |
| 15:00:45 | rouk | Yeah. I'll look into deploying metadata separate, not sure how/if kolla has it supported yet, but I'll figure it out. Anything I can do to help fix the issue upstream? | |
| 15:04:15 | rouk | Also have i screwed my db by pointing directly at the nova db on nova-api and nova-scheduler? | |
| 15:04:35 | rouk | As that current workaround didn't have much thought put into the consequences | |
| 15:16:05 | sean-k-mooney | you likely have not broke them but you should not do that | |
| 15:16:46 | sean-k-mooney | dansmith: ^ the api db should not point directly to the cell db right. it looks like the block device mapping are only in the cell db so they are missing form the metadata responce | |
| 15:17:10 | sean-k-mooney | pointing nova-api at the cell db instead of cell0 seams to fix it but obvioly not the right thing to do | |
| 15:17:30 | sean-k-mooney | the workaround im suggesting is deploy a seperate metadta api and have it point to the cell db for now | |
| 15:18:13 | sean-k-mooney | rouk: i think we are just not correctly downcalling form the api to the cell db to get this info | |
| 16:24:35 | bauzas | beer'o time | |
| 16:27:55 | rouk | sean-k-mooney: seems like kolla doesnt have any tooling for deploying per-cell metadata yet, is there some documentation on whats actually needed to do it? any docs i can find from nova are super vague on how per-cell meta works. | |
| 16:34:59 | rouk | seems like the easiest fix would be to keep api connected to the cell's db until its fixed, unless theres some implementation docs i can use to add per-cell meta to kolla. | |
| 17:14:07 | lbragstad | gmann johnthetubaguy i see the policy stuff made it on the retrospective | |
| 17:14:34 | johnthetubaguy | lbragstad: yeah, just saying it was good it landed | |
| 17:14:35 | lbragstad | gmann johnthetubaguy i tried joining, but i was a late | |
| 17:14:52 | lbragstad | is there anything that we can take out of that discussion? | |
| 17:19:02 | gmann | lbragstad: few things we discussed during oslo-nova session on Monday | |
| 17:19:12 | gmann | on json format stuff | |
| 17:20:17 | gmann | lbragstad: L80 - https://etherpad.opendev.org/p/oslo-victoria-topics | |
| 17:21:14 | gmann | especially how to migrate json format to yaml in smooth way | |
| 17:21:19 | lbragstad | gmann ah - yeah | |
| 17:27:51 | sean-k-mooney | rouk: well you only have one cell so i would leave the main api pointing to the api db/cell 0 and have the seperate metadata service point to the singel cell | |
| 17:28:19 | sean-k-mooney | kolla does support a spereate metadtaa api i belive so that should be doable. i think | |
| 17:28:40 | rouk | yeah, but i dont know how to set up a separate metadata service, docs arent really specific on what to do, and id have to understand the process before i can add it to kolla. | |
| 17:28:56 | rouk | i dont see any tasks for it in kolla | |
| 17:31:14 | sean-k-mooney | ya just looked too it looks like they dont support it | |
| 17:32:08 | rouk | yeah, so im debating between adding support for it, which... theres little docs other than spec drawing for me to implement it, or just leaving nova-api on wrong db till i need multi-cell or the nova bug is fixed | |
| 17:32:44 | sean-k-mooney | rouk: so currently you are just chainging [database]/connection | |
| 17:32:51 | rouk | yes. | |
| 17:32:53 | sean-k-mooney | to point to your nova db which is cell 1 | |
| 17:33:06 | sean-k-mooney | and ytou are not changin [api_database]/connection | |
| 17:33:12 | rouk | correct. | |
| 17:33:34 | sean-k-mooney | im not sure if that would implcitly be harmful | |
| 17:34:09 | sean-k-mooney | rouk: the schelder shoudl not need to be modifed by the way | |
| 17:34:14 | sean-k-mooney | it would only be nova-api | |
| 17:34:45 | rouk | yeah, i need to revert that change, kolla puts them onto the same config, i need to make my change more specific and split it up a bit | |
| 17:35:06 | sean-k-mooney | ya that is simple to do with kolla | |
| 17:35:20 | rouk | yeah, just going to do a nova-api.conf override | |
| 17:35:52 | sean-k-mooney | yep | |
| 17:36:06 | sean-k-mooney | i really like there config override system | |
| 17:36:25 | sean-k-mooney | you know htat you can use jinja varables in your config overrides too | |
| 17:37:54 | sean-k-mooney | so you can put connection = mysql+pymysql://{{ nova_cell0_database_user }}:{{ nova_cell0_database_password }}@{{ nova_cell0_database_address }}/{{ nova_cell0_database_name }} | |