canonical-ci-engineering team mailing list archive

[Joe Talbott <joe.talbott@xxxxxxxxxxxxx>]

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

> 
> > 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?

Joe