-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MM-44651] Implement MaxCallParticipants
config setting
#93
Conversation
} | ||
ret := config{ | ||
clientConfig: p.getConfiguration().getClientConfig(), | ||
SkuShortName: skuShortName, | ||
CloudMaxParticipants: cloudMaxParticipants, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this is a breaking change but given it only affects Cloud I think we can safely make it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think... Good thing mobile isn't cut yet. :)
@@ -58,16 +58,16 @@ export type CallsConfig = { | |||
ICEServers: string[], | |||
AllowEnableCalls: boolean, | |||
DefaultEnabled: boolean, | |||
MaxCallParticipants: number, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going snake case makes the server code more complex as we need yet another config wrapper, not sure if it's worth it to be honest but let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, it's fine. We're kind of stuck with it for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good code-wise, I went through it carefully. I will approve after I do QA on it (will take awhile to get the server set up and run through all the combinations).
} | ||
ret := config{ | ||
clientConfig: p.getConfiguration().getClientConfig(), | ||
SkuShortName: skuShortName, | ||
CloudMaxParticipants: cloudMaxParticipants, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think... Good thing mobile isn't cut yet. :)
@@ -162,6 +172,10 @@ func (c *configuration) Clone() *configuration { | |||
} | |||
} | |||
|
|||
if c.MaxCallParticipants != nil { | |||
cfg.MaxCallParticipants = model.NewInt(*c.MaxCallParticipants) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question for myself: why model.NewInt
here but new(int)
everywhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I feel like Hamlet now 💀
Part of me wants to avoid relying on model
as much as possible but it's so tempting to save a line by using the util...
${(props) => props.isCloudPaid && css` | ||
cursor: not-allowed; | ||
`} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call.
@@ -58,16 +58,16 @@ export type CallsConfig = { | |||
ICEServers: string[], | |||
AllowEnableCalls: boolean, | |||
DefaultEnabled: boolean, | |||
MaxCallParticipants: number, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, it's fine. We're kind of stuck with it for now.
Co-authored-by: Christopher Poile <[email protected]>
server/activate.go
Outdated
@@ -56,6 +47,16 @@ func (p *Plugin) OnActivate() error { | |||
// On Cloud installations we want calls enabled in all channels so we | |||
// override it since the plugin's default is now false. | |||
if isCloud(p.pluginAPI.System.GetLicense()) { | |||
cfg.MaxCallParticipants = new(int) | |||
*cfg.MaxCallParticipants = cloudMaxParticipantsDefault | |||
if maxPart := os.Getenv("MM_CALLS_MAX_PARTICIPANTS"); maxPart != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discovered in QA: Do we not want to allow on-prem to use the MM_CALLS_MAX_PARTICIPANTS
flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's more like we need it on Cloud, not so much on on-prem although given it's not possible to use common configuration overrides due to the plugin id issue I think it makes sense to allow this to be used on non-cloud installations as well. I can update 👍
This has been a disaster to test. First, after setting up a mocked CWS system and a custom docker image, and spinning up a test server using that hash, you can only upload the plugin once. After that the plugin upload button is deactivated (but you can get around that by never leaving the system console). Second, often you'll get an error back from uploading a plugin: If you get that, your server is toast -- it will no longer accept plugin uploads, so you have to spin up a new one. Third, the Fourth, I could not test whether the manual max participants configuration setting works in cloud, because it wouldn't let me change any config settings. It would respond with: Finally, I could not test the max 8 default for cloud. This is because I could not change other settings like What I was able to test:
What I was not able to test:
Issues found:
So at the moment I think we need to:
|
Thanks @cpoile , I am sorry you had to go through all that trouble just to test this but if anything it helped to reinforce even further the need to have better tools/permissions when testing/debugging in Cloud. I'll make sure to raise these concerns in our future discussions with Cloud/SREs. For the sake of this PR could we test whatever is feasible using cloud licenses on a local env? I understand it won't be 100% accurate (as we have seen already) but it's better than nothing.
Interesting, there must be some racy behaviour with the two operations then given that locally I was consistently getting the activation after the initial config change trigger. I am almost regretting not going forward with the plugin id change since it would have prevented all this 😬 Anyhow, I think for the time being we can put in place a little check and apply the overrides as soon as the configuration has been loaded the first time. E.g.: func (p *Plugin) setConfiguration(configuration *configuration) error {
p.configurationLock.Lock()
defer p.configurationLock.Unlock()
if p.configuration == nil && configuration != nil {
setOverrides(configuration)
} What do you think?
Yes this is expected and fine for now. Created MM-44781.
I think there may still be some issues with on-prem I guess where we should show the blocked cursor anyway since there's nothing to click but it's a minor thing. |
No worries. :)
I've done that, and that would be the "let's just hope" option. In the end I don't think there is a way to finish testing this at the moment, so it's the only option.
That won't work, unfortunately, because the pluginAPI isn't set at that point either. I think that putting the overrides in the Instead, when you upload a plugin, that's when the overrides in the But either way, maybe we can keep it in the |
Done. Was able to test everything, including mobile. I wasn't able to test that changing the config setting in the system console doesn't affect the overrides, because of the error I talked about above. But I'm assuming so, b/c of the code. I think we're good to go @streamer45 |
Thanks @cpoile for the huge effort here 💯 |
Summary
PR implements a new
MaxCallParticipants
config setting to optionally limit the maximum number of participants in calls.Config value can be also be overridden through the
MM_CALLS_MAX_PARTICIPANTS
environment variable if needed.@cpoile I made various changes to the logic to avoid having two values for essentially the same thing. It would be great if you could do some QA on this to make sure I haven't missed anything.
Ticket Link
https://mattermost.atlassian.net/browse/MM-44651