Retirement username variables in Juniper alpha1

Site Operators
1

Thanks for the update @nedbat.

While testing configuration/juniper.alpha1 deployment I got this error. Can we apply this fix from upstream?

Except from this already fixed issue, Juniper alpha1 base installation is running well. Great job!

2

Are other people seeing this error? It would be great if the Prospectus installation wasn’t mixed into the Open edX installation in the first place, but I know the playbooks are hard to keep clean.

3

Not on my side. I don’t even know what Prospectus is and what role it plays in the Open edX environment.

4

Prospectus is edx.org’s closed-source marketing front-end. It won’t be installed, but it seems like there are installation errors due to a few settings in the playbooks?

5

Thanks Ned. I didn’t know it had a proper name :grinning:

6

I just tried an installation of open-release/juniper.alpha1, and it completed successfully. @toxinu can you share the details of your failure?

7

I just double checked and I linked to the wrong PR, I was referring to this one. Sorry about that.

And this is the error I encountered before cherry-picking above commit (striped for a better reading):

TASK [oauth_client_setup : Create OAuth2 django-oauth-toolkit Backend Service Applications]
[...]
failed: (item={
    u'username': u'None',
    u'backend_service_secret': u'[striped data]',
    u'name': u'retirement-service',
    u'backend_service_id': u'[striped data]'}
    ) => {
        "changed": true,
        "cmd": "/edx/bin/python.edxapp /edx/bin/manage.edxapp lms --settings=production create_dot_application --grant-type client-credentials --client-id [striped data] --client-secret [striped data] --scopes user_id --update retirement-service-backend-service None",
        "delta": "0:00:09.772101",
        "end": "2020-02-03 10:47:07.441994",
        "item": {
            "backend_service_id": "[striped data]",
            "backend_service_secret": "[striped data]",
            "name": "retirement-service",
            "username": "None"
        }
    }
    [...]
    django.contrib.auth.models.DoesNotExist: User matching query does not exist.
    [...]
8

I don’t understand why you are getting an error when I do not. I’m using the open-release/juniper.alpha1 branch in the edx organization repos. Are you using something even slightly different?

9

I am using both open-release/juniper.alpha1 from edx-platform and configuration repositories. The only difference is the configuration one in which I have cherry-picked the fix I mentioned above.

My guess is that you need to enable COMMON_RETIREMENT_SERVICE_SETUP to encounter this error.

10

Do you mind providing the complete details of how I can reproduce the problem? Exactly what variables have you set, and how?

11

This is the retirement configuration while running openedx_native.yml playbook (from this branch, based on open-release/juniper.alpha1) on a freshly installed vm.

COMMON_RETIREMENT_SERVICE_SETUP: True
RETIREMENT_SERVICE_ENABLE_CRON_JOB: True
RETIREMENT_SERVICE_COOL_OFF_DAYS: 5
RETIREMENT_SERVICE_CRON_JOB_HOURS: 0
RETIREMENT_SERVICE_CRON_JOB_MINUTES: 0
RETIREMENT_LMS_BASE_URL: [..]
RETIREMENT_ECOMMERCE_BASE_BASE_URL: [..]
RETIREMENT_CREDENTIALS_BASE_BASE_URL: [..]

As you can see the default username for retirement user use EDXAPP_RETIREMENT_SERVICE_WORKER_USERNAME which have no reference in any place in the configuration repository because there is a mismatch with EDXAPP_RETIREMENT_SERVICE_USER_NAME variable. I think this is why this MR has been merged. Hopefully all these details should have been provided in the MR description to provide some context.

I hope that I gave you enough details. Thanks for your time @nedbat :raised_hands:

PS: Just to be cleared in case I am not. This is not related to prospectus, actually this is a bug which have been fixed in master and we need this fix in juniper.alpha1 branch too.

12

OK, thanks for the clarification. I’ve cherry-picked the fix onto open-release/juniper.alpha1.

1 Like