On 25 September 2014 14:43, Joe Talbott <[email protected]> wrote: > 1. We have several places in webui/webui/settings.py where we're blindly > doing this: > > path = os.path.join(BASE_DIR, '../../../../allowed_host.json') > > This is of course bad since it's assuming the app is installed in the > manner we deploy. > > I'm not sure how we can get around this and make IS happy. One approach > I've seen used is to have symlinks for these external data files and > local settings files. We'd need to handle the situation where those > files are absent as well and our current try/except logic might work for > that. Thoughts?
Let's follow the required IS Prodstack policy and put all config data under /srv/.../etc, and all variable data under /srv/.../var: https://wiki.canonical.com/InformationInfrastructure/IS/Policies/Prodstack#You_Must: As you point out, this precludes the relative path approach, since we absolutely cannot assume any part of the path name. Instead, I think we should have the charm write out templates with absolute paths built from the config.yaml data (service name, etc). > 2. We have a couple of places in ticket-system/ticket_system/settings.py > where we are using 'print'. I think this is bad as well. I have a > patch that removes two 'print' calls that seem to be debugging info and > converts another, which is a proper warning, to output to stderr. The > reason I'm bringing this up is for the client credential creation I have > a management command (manage.py create_client <redirect_uri>) that is > expected to, upon success, output the client credentials to give to the > other end of the relationship. Thoughts? +1 I believe that print makes sense only in the context of reporting back to the user of a CLI. Why not also send the warning to the log instead of stderr? -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
