canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

On Thursday, September 25, 2014, Joe Talbott <joe.talbott@xxxxxxxxxxxxx>
wrote:

> On Thu, Sep 25, 2014 at 07:06:51PM +0100, Evan Dandrea wrote:
> > On 25 September 2014 14:43, Joe Talbott <joe.talbott@xxxxxxxxxxxxx
> <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?