Opened 13 years ago

Closed 12 years ago

#29 closed defect (wontfix)

Create a way to wipe an environment

Reported by: Christopher Allan Webber Owned by: Will Kahn-Greene
Priority: minor Milestone:
Component: programming Keywords:
Cc: Parent Tickets:

Description (last modified by Will Kahn-Greene)

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)

Change History (10)

comment:1 by Christopher Allan Webber, 13 years ago

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


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

comment:2 by Christopher Allan Webber, 13 years ago

Component: Programming
Owner: set to Will Kahn-Greene
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
    # use these to setup the connection
    # This is the database name to be dropped
    # 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
` <>`_
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.

comment:3 by Will Kahn-Greene, 13 years ago

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

comment:4 by Christopher Allan Webber, 13 years ago


comment:5 by Christopher Allan Webber, 13 years ago


comment:6 by Christopher Allan Webber, 12 years ago


comment:4 by Will Kahn-Greene, 12 years ago

The original url for this bug was .
#110: related

comment:5 by Christopher Allan Webber, 12 years ago

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?)

comment:6 by Will Kahn-Greene, 12 years ago

Description: modified (diff)
Milestone: 0.2.1

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

comment:7 by Will Kahn-Greene, 12 years ago

Resolution: wontfix
Status: acceptedclosed

Chris pointed out this is a one-liner now:

rm -rf *.db user_dev/

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

Note: See TracTickets for help on using tickets.