communication #99711
closed
Server maintenance workflow for openSUSE Meet
Added by livdywan over 2 years ago.
Updated over 2 years ago.
Description
Issues such as #94637 and #93859 are very difficult to address because there's no defined workflow. Changes can be made by several people and there's no requirement to document in e.g. a ticket what was done or go through smoke testing and revert.
I'd like to suggest that common procedures are defined, and if something needs to be done there's one or several people who can help work on a task. I'm thinking of these ones to begin with:
- Host upgrade
- Jitsi version upgrade
- Smoke testing steps after any change
- Ticket-based process for all changes
- Related to communication #94637: openSUSE Meet (Jitsi) disables video and screensharing to save bandwidth added
- Related to tickets #93859: openSUSE Meet (Jitsi) is borked after upgrade added
- Private changed from Yes to No
No need for this to be Private.
Also #98823 may be worth mentioning, which is an openQA test for Jitsi which could be used in the future to spot regressions in automated tests.
Agreed in general, but can I suggest to not document host information in a ticket, which will get lost (means: get lost in the minds of the admins)?
Under normal conditions, I would suggest to add the information about a machine in our Salt setup. As meet.o.o is currently not using Salt, we need to find another place. What about a page in our Admin-Wiki here?
- Category set to Jitsi/ Meet
lrupp wrote:
As meet.o.o is currently not using Salt, we need to find another place. What about a page in our Admin-Wiki here?
Yeah, that sounds good to me. It should be as discoverable as possible.
- Status changed from New to Closed
- % Done changed from 0 to 100
Hi there - and a Happy and Healthy 2022!
I'm currently closing old tickets which did not see much change.
If the main concern still exists and should be handled, please re-open by just replying to this Email.
Thanks in advance,
Lars
Also available in: Atom
PDF