[ 
https://issues.apache.org/jira/browse/AIRAVATA-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Christie updated AIRAVATA-3383:
--------------------------------------
    Description: 
Make it easier for gateway developers to get a settings_local.py for local 
development. What we tend to do is copy the settings_local.py for the deployed 
Django portal instance and then modify it to work for local development.

Here are some differences between the production and local dev settings_local.py
- comment out production settings like DEBUG, STATIC_ROOT, ALLOWED_HOSTS
- comment out the MySQL database engine - local dev will use sqlite db instead
-- need to also remove the db password or mask it
- comment out/remove the Email settings
- set GATEWAY_DATA_STORE_REMOTE_API so that locally the user sees the files on 
the remote deployed gateway
- comment out FILE_UPLOAD_TEMP_DIR
- comment out the TUS settings

Also, for the Keycloak OAuth login to work we need to add 
{{http://localhost:8000/}} and {{http://localhost:8000/auth/callback*}}.

Improvements that could be made:
- ideally, we would create a new Keycloak client for the realm that has as 
little privileges as necessary. The Keycloak client used for the production 
deployed Django portals has 'manage-users' role. The Keycloak client for local 
development should only allow logging in to localhost.
- might be good to create a SQLite configuration that names the database file 
uniquely, but that is maybe something that is only useful is working on more 
than one gateway

h5. TODO

- [ ] verify that client can be created for local portal development using the 
REST API
- [ ] script to add manage-clients role to portal client service accounts (they 
currently only get manage-users role)
- [ ] update TenantManagementKeycloakImpl to add manage-clients to newly 
created portal client service accounts
- [ ] Django portal: implement creating portal client using REST API
- [ ] Django portal: implement creating settings_local.py download
- [ ] handle clients that don't have "Direct Access Grants Enabled" - redirect 
to Keycloak login page to login with username/password (see comment below)

  was:
Make it easier for gateway developers to get a settings_local.py for local 
development. What we tend to do is copy the settings_local.py for the deployed 
Django portal instance and then modify it to work for local development.

Here are some differences between the production and local dev settings_local.py
- comment out production settings like DEBUG, STATIC_ROOT, ALLOWED_HOSTS
- comment out the MySQL database engine - local dev will use sqlite db instead
-- need to also remove the db password or mask it
- set GATEWAY_DATA_STORE_REMOTE_API so that locally the user sees the files on 
the remote deployed gateway
- comment out FILE_UPLOAD_TEMP_DIR
- comment out the TUS settings

Also, for the Keycloak OAuth login to work we need to add 
{{http://localhost:8000/}} and {{http://localhost:8000/auth/callback*}}.

Improvements that could be made:
- ideally, we would create a new Keycloak client for the realm that has as 
little privileges as necessary. The Keycloak client used for the production 
deployed Django portals has 'manage-users' role. The Keycloak client for local 
development should only allow logging in to localhost.
- might be good to create a SQLite configuration that names the database file 
uniquely, but that is maybe something that is only useful is working on more 
than one gateway

h5. TODO

- [ ] verify that client can be created for local portal development using the 
REST API
- [ ] script to add manage-clients role to portal client service accounts (they 
currently only get manage-users role)
- [ ] update TenantManagementKeycloakImpl to add manage-clients to newly 
created portal client service accounts
- [ ] Django portal: implement creating portal client using REST API
- [ ] Django portal: implement creating settings_local.py download
- [ ] handle clients that don't have "Direct Access Grants Enabled" - redirect 
to Keycloak login page to login with username/password (see comment below)


> Automate creating a settings_local.py file for local development
> ----------------------------------------------------------------
>
>                 Key: AIRAVATA-3383
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-3383
>             Project: Airavata
>          Issue Type: Bug
>          Components: Django Portal
>            Reporter: Marcus Christie
>            Assignee: Marcus Christie
>            Priority: Major
>
> Make it easier for gateway developers to get a settings_local.py for local 
> development. What we tend to do is copy the settings_local.py for the 
> deployed Django portal instance and then modify it to work for local 
> development.
> Here are some differences between the production and local dev 
> settings_local.py
> - comment out production settings like DEBUG, STATIC_ROOT, ALLOWED_HOSTS
> - comment out the MySQL database engine - local dev will use sqlite db instead
> -- need to also remove the db password or mask it
> - comment out/remove the Email settings
> - set GATEWAY_DATA_STORE_REMOTE_API so that locally the user sees the files 
> on the remote deployed gateway
> - comment out FILE_UPLOAD_TEMP_DIR
> - comment out the TUS settings
> Also, for the Keycloak OAuth login to work we need to add 
> {{http://localhost:8000/}} and {{http://localhost:8000/auth/callback*}}.
> Improvements that could be made:
> - ideally, we would create a new Keycloak client for the realm that has as 
> little privileges as necessary. The Keycloak client used for the production 
> deployed Django portals has 'manage-users' role. The Keycloak client for 
> local development should only allow logging in to localhost.
> - might be good to create a SQLite configuration that names the database file 
> uniquely, but that is maybe something that is only useful is working on more 
> than one gateway
> h5. TODO
> - [ ] verify that client can be created for local portal development using 
> the REST API
> - [ ] script to add manage-clients role to portal client service accounts 
> (they currently only get manage-users role)
> - [ ] update TenantManagementKeycloakImpl to add manage-clients to newly 
> created portal client service accounts
> - [ ] Django portal: implement creating portal client using REST API
> - [ ] Django portal: implement creating settings_local.py download
> - [ ] handle clients that don't have "Direct Access Grants Enabled" - 
> redirect to Keycloak login page to login with username/password (see comment 
> below)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to