On Thursday, September 25, 2014, Joe Talbott <[email protected]> wrote:
> On Thu, Sep 25, 2014 at 07:06:51PM +0100, Evan Dandrea wrote: > > On 25 September 2014 14:43, Joe Talbott <[email protected] > <javascript:;>> 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). > > Thanks for your response. > > That's a fine approach but where do we put that template? I don't think > we can make settings.py a template since then the charm is altering code > in the payload. We already support a 'local_settings.py' file in the > branch and could have the charm populate that with the required info, > i.e. paths to config and variable data There are a few ways you could do it. Have the charm tell the wsgi worker about some environment variables that settings.py consumes. Have the code import from a file that the charm puts on PATH. > > > > 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? > > It's my (perhaps misguided) impression that logging in settings.py is > bad as well as logging something before logging is configured prevents > later basicConfig() calls from having an effect. The docs say that > basicConfig is only for simple scripts so perhaps I'm being overly > cautious. Does anyone have any experience or knowledge regarding > logging in a django settings.py file? > Ah, that makes sense. The logging module is a bit brain-dead in its instance on being set up once. I've heard there are better replacements for it out there. Maybe something to look into longer-term?
-- 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
