Overhang.io

Course Deletion using portainer?

as per request by @regis i’m generating a discussion to help resolve this issue or generate a strategy for deleting courses.

Referencing the following issue from github:

Is there current example of deleting of a course?

in attempting to replicate this (tutor v3.3.4, and running a custom fork of the edx-platform branched from ironwood.master with very view modifications)
(with tutor running a local functional instance)

  • i’ve started up portainer to gain access to the running containers
  • connected to both the lms & cms containers respectively attempting to run the delete_course command, but regardless when attempting to perform the described action am greeted by the following:

command:
./manage.py cms delete_course course-v1:testing+1+2019

output:

Traceback (most recent call last):
  File "./manage.py", line 123, in <module>
    execute_from_command_line([sys.argv[0]] + django_args)
  File "/openedx/venv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/openedx/venv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/openedx/venv/local/lib/python2.7/site-packages/django/core/management/base.py",line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/openedx/venv/local/lib/python2.7/site-packages/django/core/management/base.py",line 330, in execute
    output = self.handle(*args, **options)
  File "/openedx/edx-platform/cms/djangoapps/contentstore/management/commands/delete_course.py", line 69, in handle
    if not modulestore().get_course(course_key):
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/django.py", line 316, in modulestore
    settings.MODULESTORE['default'].get('OPTIONS', {})
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/django.py", line 298, in create_modulestore_instance
    **_options
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/mixed.py", line 176, in __init__
    signal_handler=signal_handler,
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/django.py", line 298, in create_modulestore_instance
    **_options
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/split_mongo/split.py", line 707, in __init__
    self.db_connection = MongoConnection(**doc_store_config)
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/modulestore/split_mongo/mongo_connection.py", line 278, in __init__
    retry_wait_time=retry_wait_time, **kwargs
  File "/openedx/edx-platform/common/lib/xmodule/xmodule/mongo_utils.py", line 50, in connect_to_mongodb
    **kwargs
  File "/openedx/venv/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 425, in __init__
    raise ConnectionFailure(str(e))
pymongo.errors.ConnectionFailure: [Errno 111] Connection refused

I’ve attempted to run this command from the following containers:

  • tutor_local_lms_1
  • tutor_local_cms_1 (the suggested container to perform the command from)
  • tutor_local_lms_worker_1
  • tutor_local_cms_worker_1

Additionally, I’ve tried activating the virtual environment before performing the operation as well.

I’m assuming this has something to do with how i’m attempting to perform the operation.

@regis suggested checking that the mongodb container is running, which it appears to be. It’s listed in portainer, and i’m able to access its console through that interface in a currently running in a local instance. so i’m at a loss.

Also, it’s worth noting that I’m fairly new to both docker, and openedx. so go easy on me…

Hi @crivet! Thanks for taking the time to move your question here.
I managed to reproduce your issue. Here is the “tl;dr” solution:

 ./manage.py cms --settings=tutor.production delete_course course-v1:testing+1+2019

And now for the longer explanation: the problem comes from the fact that when we launch a console in the cms container with Portainer, the DJANGO_SETTINGS_MODULE environment variable is not defined. As a consequence, the manage.py commands loads the platform settings from its defaults: lms.envs.devstack_docker. These defaults do not work with Tutor. In particular, the mongodb connection credentials are incorrect, causing the above error. To solve this issue, we need to manually specify which settings we want to load, hence the --settings tutor.production option.

But why is the DJANGO_SETTINGS_MODULE environment variable undefined? With Portainer, launching a console is like running docker-compose exec .... When we exec into a running container, we skip the container entrypoint. In Tutor, it is the openedx container entrypoint that defines the DJANGO_SETTINGS_MODULE.

To better understand this, you can run:

tutor local run cms bash
echo $DJANGO_SETTINGS_MODULE

This should print cms.envs.tutor.production, showing that the default settings are well defined.

But if we run the following:

tutor local exec cms bash
echo $DJANGO_SETTINGS_MODULE

Then nothing is printed.

1 Like

Awesome, just ran a few test deletions on my test instance and it worked using the additional settings flag. Thanks for the help @regis, greatly appreciated.