Create a way to wipe an environment

[Christopher Allan Webber]

It should be possible to do something like:

::

    ./bin/gmg wipe_environment mediagoblin.ini

This should then ask the user to confirm (the user should have to
type "yes") but should then wipe all:


-  sessions
-  the database specified in mediagoblin.ini
-  the files in the specified public\_store and queue\_store
   (assuming they're of BasicFileStore type)

[Christopher Allan Webber]

I added a script for this that semi-sucks at the toplevel:

./destroy\_environment.py

However it isn't very good and doesn't look at what's in the
mediagoblin config file or anything.

[Christopher Allan Webber]

Will is working on this. Yay, thanks Will! Will is making a
command, ./bin/gmg wipealldata

Right now it looks like this converted my super stupid script.
However, I'm not happy at all with that old script, as it made
assumptions about where things lived. Could we update this to read
things out of the config file?

::

    from mediagoblin.init import setup_global_and_app_config
    from mediagoblin import mg_globals
    
    read_mediagoblin_config(config_path)
    # use these to setup the connection
    mg_globals.app_config['db_host']
    mg_globals.app_config['db_port']
    
    # This is the database name to be dropped
    mg_globals.app_config['db_name']
    
    # other things in here to remove:
    #  - queuestore_base_dir
    #  - publicstore_base_dir
    #  - workbench_path

Unfortunately we won't be able to wipe the session information from
here because we don't have
`http://bugs.foocorp.net/issues/397 <http://bugs.foocorp.net/issues/397>`_
done, but I wouldn't worry about that too much for now.

As for how to get the config file path at all, see the other gmg
commands which use it to setup the app.

[Will Kahn-Greene]

I'm bumping this to 0.0.5--I'll work on it then.

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/296 .
Relations:
#110: related

[Christopher Allan Webber]

Hi! Sadly, I think this has gotten a little more rather than less complex now that we're moving to SQL.

In order for this command to work, we'd have to:

• Be capable of determining the database type and the proper database destroying commands per DB (maybe that's not so hard, depending on how sqlalchemy supports killing databases)
• Kill the appropriate storage systems. I guess we could only support killing the BasicFileStorage ones, which would be easy to support.

Regardless, this should be held off until SQL work lands. (Is there some sort of way we should tag things for that?)

[Will Kahn-Greene]

Bumping this out of the milestone because it should wait until after the SQL stuff has landed.

[Will Kahn-Greene]

Chris pointed out this is a one-liner now:

rm -rf *.db user_dev/

Given that, there's no need for this anymore. Closing.