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
Add ability to enable/disable maintenance mode from cli. #8748
Conversation
I was under the impression that we have this already. But obviously not. :-) 👍 |
🚀 Test Passed. 🚀 |
use Symfony\Component\Console\Input\InputOption; | ||
use Symfony\Component\Console\Output\OutputInterface; | ||
|
||
class MMode extends Command { |
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.
Why not just Mode?
besides the noted MMode/mmode: 👍 |
|
||
protected function execute(InputInterface $input, OutputInterface $output) { | ||
if ($input->getOption('on')) { | ||
\OC_Config::setValue('maintenance', true); |
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 would prefer if the legacy class OC_Config would not be used - but this has to be addressed separately
Looks good besides the MMode thing already mentioned |
I picked mmode because the existing name of maintenance:singleuser for single user mode would mean maintenance:maintenance for consistency. Too long and redundant. I thought about using just mode. Can't remember exactly why I settled on mmode. I agree mode would be better. I'll switch it. @DeepDiver1975 I haven't dug into what is and isn't legacy before. I see the lib/private/legacy folder now. What is the correct way to use \OC\Config? I see that OC_Config is a wrapper for it with base.php making an OC\Config instance for OC_Config. Everywhere I can see OC\Config used I see OC_Config being referenced to get that instance (eg in core/register_command.php when instantiating the ConvertType command class). This looks like an area that is half way through refactoring. |
exactly - and because of that we can ignore this within this pr |
Consider it ignored :-) |
I'm not sure what sort of refactoring you are talking about, but you really should take the Config object as a constructor dependency, just like |
\OC_Config::setValue('maintenance', false); | ||
$output->writeln('Maintenance mode disabled'); | ||
} else { | ||
if (\OC_Config::getValue('maintenance', false)) { |
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.
Use elseif instead, which is one level less deep.
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.
From a computation perspective it doesn't make any difference but I prefer this style. There are three available options, on, off and nothing. In the event of nothing, status is displayed which can have two possible values.
So determining and returning that status is nested. Representing the 3 options as 4 parts of the same if block because one of the options can have two return values makes it a little less readable to my mind.
Consider using |
@@ -0,0 +1,52 @@ | |||
<?php | |||
/** | |||
* Copyright (c) 2013 Robin Appelman <icewind@owncloud.com> |
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.
2014?
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.
Most of the code was written in 2013 by Robin. This is just a cp of singleuser.php with a handful of changes for the different config option. So I left it. Should it be changed to 2014 or 2013-2014?
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.
Add another copyright line with 2014 and your name?
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.
Assuming that you probably copied singleuser.php to mode.php and then swapped all the logic contained in the actually command class, I am not sure there is anything remaining that would have to attributed to robin.
I am not sure using the options on and off is such a good idea. A mandatory argument seems to be the better choice to me. |
🚀 Test Passed. 🚀 |
The refactoring I was talking about was how OC_Config is legacy but is the only way to get the OC\Config object that is instantiated in base.php. The more I think about it the more I think following your suggestion and using OC\Config inside the class is the better way to go. register_command.php will still need to be updated when there is an alternate way to get that object but at least the class won't. Since mode.php is basically a copy of singleuser.php it would be good to keep them in sync. Anyone have any objections or comments on changing this for both files? |
Please use a new pull request for that. These are different issues. You are adding something new, so use the knowledge that is currently available. I am also pretty sure I complained about lack of dependency injection in the PR for singleuser.php. If you change singleuser.php here, this PR will take longer to get merged. |
Yes, hadn't thought of DI for this. Good point. |
A new inspection was created. |
👍 This looks good to me. Will test and merge as soon as Jenkins passes. |
Cool. |
🚀 Test Passed. 🚀 |
Add ability to enable/disable maintenance mode from cli. * owncloud/cli_maintenance_mode: Use OC\Config instead of OC_Config Changed class name to mode Add ability to enable/disable maintenance mode from cli.
Tested as follows
|
Simple addition to the capabilities of console.php to turn maintenance mode on or off. Basically a dupe of the singleuser.php script by Robin Appelman. Useful for backup scripts so that database and data directory snapshots can be taken with no changes from users. If these two things are not perfectly in sync when backed up, restore will be a major headache.