canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

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).

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