Pulp

From the perspective of the user, I think that people will be using pulp who don't know much about django. I like that we "own" the interface that they should use.

I rewrote the description just now with a clearer case for its removal versus it being an autocomplete issue.

bmbouter, there was some conversation around using pulp-manager to execute some of the functions in our developer aliases.

prestart (stop, start) pjournal, to name a few. This seems like something that would be useful to expose to users, but something that falls outside the scope of what django-admin would be expected to do. I'm not sold that its appropriate to do this for pulp-manager, but it does seem like it at least has the potential to be nice.

Can you confirm that what we added to pulp-manager (reset-admin-password) is also added to django-admin?

amacdona@redhat.com wrote:

Can you confirm that what we added to pulp-manager (reset-admin-password) is also added to django-admin?

Yes when I run django-admin I can see these commands listed.

(pulp) [vagrant@pulp3-source-fedora28 pulp_rpm]$ django-admin
/usr/local/lib/pulp/lib64/python3.6/site-packages/psycopg2/__init__.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip insta
ll psycopg2-binary" instead. For details see: <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
  """)

Type 'django-admin help <subcommand>' for help on a specific subcommand.

Available subcommands:

[app]
    reset-admin-password
    stage-profile-summary

[auth]
    changepassword
    createsuperuser

FYI
django-admin uses setting from 'pulpcore.app.settings'
and this leads to the traceback

Django version 2.1.7, using settings 'pulpcore.app.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

pulp: django.request:ERROR: Internal Server Error: /pulp/api/v3/remotes/docker/docker/1/sync/
Traceback (most recent call last):
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/django/core/handlers/base.py", line 126, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/django/core/handlers/base.py", line 124, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/rest_framework/viewsets.py", line 116, in view
    return self.dispatch(request, *args, **kwargs)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/rest_framework/views.py", line 495, in dispatch
    response = self.handle_exception(exc)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/rest_framework/views.py", line 455, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/rest_framework/views.py", line 492, in dispatch
    response = handler(request, *args, **kwargs)
  File "/home/vagrant/devel/pulp_docker/pulp_docker/app/viewsets.py", line 145, in sync
    'repository_pk': repository.pk
  File "/home/vagrant/devel/pulp/pulpcore/tasking/tasks.py", line 194, in enqueue_with_reservation
    redis_conn = connection.get_redis_connection()
  File "/home/vagrant/devel/pulp/pulpcore/tasking/connection.py", line 11, in get_redis_connection
    _conn = get_redis_from_config(settings)
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/rq/cli/helpers.py", line 39, in get_redis_from_config
    if settings.get('REDIS_URL') is not None:
  File "/home/vagrant/.virtualenvs/pulp/lib64/python3.7/site-packages/django/conf/__init__.py", line 58, in __getattr__
    val = getattr(self._wrapped, name)
AttributeError: 'Settings' object has no attribute 'get'
[26/Feb/2019 13:46:31] "POST /pulp/api/v3/remotes/docker/docker/1/sync/ HTTP/1.1" 500 27

meanwhile pulp-manager uses /etc/pulp/settings.py and all is fine :)

pulp-manager handles the setting of DJANGO_SETTINGS_MODULE for the user in a way that django-admin does not automatically handle. We have no docs on this configuration requirement, so I'm not surprised you're hitting that error when using django-admin. This highlights my main concern actually; pulp-manager is taking action for the user but is lacking in documentation and functionality (autocomplete).

Either way, we need to document that Pulp's settings file is at pulpcore.app.settings and that users need to set DJANGO_SETTINGS_MODULE with something like: export DJANGO_SETTINGS_MODULE=pulpcore.app.settings. We should also link to the Django docs they have on it: https://docs.djangoproject.com/en/2.1/topics/settings/#designating-the-settings If you export this and run django-admin then it'll work for you.

I'm open to keeping pulp-manager, but I need some convincing that it's doing more good than harm. Also is the effort to write/maintain a bunch of docs and fix the tooling to go in-between Django and Pulp's users worth it? It's a pretty big responsibility that Django is already 100% committed to in terms of docs and support.

Note also pulp-manager isn't using "/etc/pulp/server.conf". It's using pulp.app.settings which is what is referencing /etc/pulp/server.conf. A correctly configured django-settings is identical to this so it also uses /etc/pulp/server.conf.

I am changing how we integrate with DynaConf so that django-admin is able to properly load the settings. This is the suggested solution from the dynaconf issue we filed during our initial integration.

https://github.com/rochacbruno/dynaconf/issues/89#issuecomment-449421777