Merge lp://staging/~bloodearnest/canonical-identity-provider/sso-dev into lp://staging/canonical-identity-provider/release

Awesome, thanks for this.

Maybe you want review by someone more familiar with all the makefile wizardry. In general it looks OK to me, the code looks sensible and the thing works very nicely (and I tried some uncommon scenarios). I made some minor comments below, mainly typos. There's one thing that may need clarification so I didn't "Approve" outright.

Yeah, some of the makefile stuff is more complex that I'd like. Make is so good at many things, but it has some rough edges. I'm pretty comfortable with make, but I know not every one is. I'm hoping vila might spot some improvements I can make.

Are there any specific bits which look too much like magic?

I've fixed the various typos too.

+1 from me but don't forget to add a commit message :)

As for the makefile, nothing looks *too* magical, it's just unfamiliar due to rustiness with Makefiles. Maybe the way targets.mk is generated, but tbh I haven't looked at it too closely and it works anyway \o/.

FYI, the juju deployer config we inherit from the charm is here:

https://bazaar.launchpad.net/~ubuntuone-pqm-team/canonical-is-charms/canonical-identity-provider/view/head:/deploy.yaml

One more question, I ran:

$ make lint
make: /home/nessita/canonical/bloodearnest/sso-dev/env/bin/flake8: Command not found
Makefile.common:152: recipe for target 'lint' failed

any idea what is missing?

On Tue, Nov 17, 2015 at 3:18 PM, Natalia Bidart
<email address hidden> wrote:
>
>
> Diff comments:
>
>>
>> === renamed file 'Makefile' => 'Makefile.common'
>> --- Makefile 2015-11-12 17:08:24 +0000
>> +++ Makefile.common 2015-11-17 13:23:47 +0000
>> @@ -1,9 +1,9 @@
>> -# Copyright (C) 2014 Canonical Ltd.
>> -
>> +# Copyright (C) 2014 Canonical Ltd.
>
> Since you are editing this file, would you mind updating the Copyright notice to 2014-2015?

Done

>> +#
>> CM ?= /usr/lib/config-manager/cm.py
>> CONFIGMANAGER = config-manager.txt
>> CONN_CHECK_CONFIG_PATH ?= /tmp/sso_conn_check_config.yaml
>> -DJANGO_SETTINGS_MODULE = settings
>> +DJANGO_SETTINGS_MODULE ?= settings
>> ENV = $(CURDIR)/env
>> JUJU_ENV ?= local
>> JUJU_REPO ?= ../.juju-repo
>> @@ -42,27 +42,32 @@
>> $(TARBALL_BUILD_DIR):
>> @mkdir -p $(TARBALL_BUILD_DIR)
>>
>> +## run django's collectstatic command, STATIC_ROOT defaults to ./staticfiles
>> collectstatic:
>> # this uses a modified collectstatic command, called linkstatic, where the
>> # --link option uses relative urls, so save space when tarballed
>> @DJANGO_SETTINGS_MODULE=django_project.settings_build $(DJANGO_MANAGE) linkstatic --noinput --link
>>
>> +## create a pre-gzipped version of static text assets
>> zipstatic:
>> @echo Gzipping static asset files...
>> @find $(STATIC_ROOT) -name \*.js -or -name \*.css -or -name \*.svg | xargs gzip -kf
>>
>> -# variation of compilemessages target that uses settings_build
>> +## variation of compilemessages target that uses settings_build
>> compilemessages-build:
>> @DJANGO_SETTINGS_MODULE=django_project.settings_build $(MAKE) compilemessages
>>
>> # note: fetch-sourcedeps needs to be manually called before this will work.
>> +## build a deployment tarbal
>
> Typo here? tarball

Fixed

>> build-tarball: install-wheels $(TARBALL_BUILD_PATH)
>>
>> +## write the bzr revno to lib/versioninfo.py
>> version:
>> bzr version-info --format=python > lib/versioninfo.py
>>
>> ### Wheels ###
>>
>> +## create/reinitialise the virtualenv
>> virtualenv:
>> @virtualenv --clear --system-site-packages $(ENV)
>>
>>
>> === added file 'Makefile.juju'
>> --- Makefile.juju 1970-01-01 00:00:00 +0000
>> +++ Makefile.juju 2015-11-17 13:23:47 +0000
>> @@ -0,0 +1,124 @@
>> +# sso specific config
>> +CHARM_SERIES = trusty
>> +CHARM = canonical-identity-provider
>> +CHARM_BRANCH = lp:~ubuntuone-pqm-team/canonical-is-charms/canonical-identity-provider
>> +CHARM_SRC = ../sso-charm
>> +DEPLOYER_CONFIG = $(CURDIR)/django_project/deploy.yaml
>> +DEPLOYER_TARGET = sso-app-dev
>> +
>> +# generic config
>> +LOG_DIRS ?= ./logs/www-oops ./logs/schema-updates
>> +ABS_CHARM_SRC = $(shell readlink -f $(CHARM_SRC))
>> +LOCAL_JUJU_CONFIG = .local.yaml
>> +JUJU_REPOSITORY ?= $(CURDIR)/.juju-repo
>> +JUJU_HOME ?= $(HOME)/.juju
>> +JENV = $(JUJU_HOME)/environments/$(JUJU_ENV).jenv
>> +export JUJU_REPOSITORY JUJU_ENV
>> +export I_CAN_HAZ_JUJU=yes
>> +
>> +# python config, overriding the non-juju config
>> +PYTHONPATH := $(LXC_BASEDIR)/etc:$(SRC_DIR):$(LIB_DIR):$(CURDIR)
>> +export PYTHONPATH
>> +
>> +
>> +
>> +$(CHARM_SRC):
>> + @bzr branch $...

On Tue, Nov 17, 2015 at 3:18 PM, Natalia Bidart
<email address hidden> wrote:
> One more question, I ran:
>
> $ make lint
> make: /home/nessita/canonical/bloodearnest/sso-dev/env/bin/flake8: Command not found
> Makefile.common:152: recipe for target 'lint' failed
>
> any idea what is missing?

Assuming you've bootstrapped (or just make dependencies), not sure. I
haven;t altered any of the dev deps or make targets beyond bootrstrap
(which is now dependecnies) and make run.

It works for me here.

More errors. On the host, on a sso-dev clean branch, I tried:

nessita@dali:~/canonical/bloodearnest/sso-dev$ export I_CAN_HAZ_JUJU=yes
nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
(Makefiles changed - rebuilding lxc target list)
unknown option -- -
usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port]
           [-Q cipher | cipher-auth | mac | kex | key]
           [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] [user@]hostname [command]
Makefile:106: recipe for target 'clean' failed
make: *** [clean] Error 255

The main issue I see with this errors is that I have no idea what is going on, nor I can debug in a easy way.

On Tue, Nov 17, 2015 at 9:05 PM, Natalia Bidart
<email address hidden> wrote:
> More errors. On the host, on a sso-dev clean branch, I tried:
>
> nessita@dali:~/canonical/bloodearnest/sso-dev$ export I_CAN_HAZ_JUJU=yes
> nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
> (Makefiles changed - rebuilding lxc target list)
> unknown option -- -
> usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
> [-D [bind_address:]port] [-E log_file] [-e escape_char]
> [-F configfile] [-I pkcs11] [-i identity_file]
> [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
> [-O ctl_cmd] [-o option] [-p port]
> [-Q cipher | cipher-auth | mac | kex | key]
> [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
> [-w local_tun[:remote_tun]] [user@]hostname [command]
> Makefile:106: recipe for target 'clean' failed
> make: *** [clean] Error 255

Hmm, this suggests your lxd is not set up correctly, it doesn't have
an IP currently.

The ssh command is on line 106:

@ssh -qtAF $(SSH_CONFIG_FILE) $(IP) -- $(MAKE) $(LXC_MAKE_FLAGS) -C
$(PWD) $@ $(LXC_MAKE_VARS)

I suspect the issue is that the $(IP) is coming out as empty, which is
confusing ssh

I will try and add an explicit check for an IP address, with suitable
error message. Previously, I have just been checking the container was
created, not also a) it was running and b) it has an IP address, which
are all things that are required so ssh in, but can fail.

Additionally, clean should be able to be run from host without ssh,
which I will fix

Would echoing the ssh command by default be better? It would make
things clearer in case of error, but at the expense of largely
irrelevant line noise on most command output.

--

Thanks

On Wed, Nov 18, 2015 at 10:34 AM, Simon Davy <email address hidden> wrote:
> On Tue, Nov 17, 2015 at 9:05 PM, Natalia Bidart
> <email address hidden> wrote:
>> More errors. On the host, on a sso-dev clean branch, I tried:
>>
>> nessita@dali:~/canonical/bloodearnest/sso-dev$ export I_CAN_HAZ_JUJU=yes
>> nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
>> (Makefiles changed - rebuilding lxc target list)
>> unknown option -- -
>> usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
>> [-D [bind_address:]port] [-E log_file] [-e escape_char]
>> [-F configfile] [-I pkcs11] [-i identity_file]
>> [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
>> [-O ctl_cmd] [-o option] [-p port]
>> [-Q cipher | cipher-auth | mac | kex | key]
>> [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
>> [-w local_tun[:remote_tun]] [user@]hostname [command]
>> Makefile:106: recipe for target 'clean' failed
>> make: *** [clean] Error 255
>
> Hmm, this suggests your lxd is not set up correctly, it doesn't have
> an IP currently.
>
> The ssh command is on line 106:
>
> @ssh -qtAF $(SSH_CONFIG_FILE) $(IP) -- $(MAKE) $(LXC_MAKE_FLAGS) -C
> $(PWD) $@ $(LXC_MAKE_VARS)
>
> I suspect the issue is that the $(IP) is coming out as empty, which is
> confusing ssh
>
> I will try and add an explicit check for an IP address, with suitable
> error message.

Done. If it can't find an IP address for the container, any command
that needs ssh will fail with a more helpful error.

Another option would be to auto-start the container it its not started, perhaps?

--
Simon

I pulled the changes. A run of make clean without the env var and I run with it both succeded with the same output:

nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
rm -rf /home/nessita/canonical/bloodearnest/sso-dev/env
rm -rf branches/wheels
rm -rf ../.juju-repo
rm -rf branches/*
rm -rf logs/*.*
rm -rf staticfiles
rm -f lib/versioninfo.py
rm -f targets.mk
find -name '*.pyc' -delete
find -name '*.~*' -delete
nessita@dali:~/canonical/bloodearnest/sso-dev$ export I_CAN_HAZ_JUJU=yes
nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
(Makefiles changed - rebuilding lxc target list)
rm -rf
rm -rf
rm -rf
rm -rf branches/*
rm -rf logs/*.*
rm -rf staticfiles
rm -f lib/versioninfo.py
rm -f targets.mk
find -name '*.pyc' -delete
find -name '*.~*' -delete
nessita@dali:~/canonical/bloodearnest/sso-dev$

Were you expecting this or there is some randomness around? What confuses me is that I don't see the container in my list of containers:

nessita@dali:~/canonical/bloodearnest/sso-dev$ sudo lxc-ls --fancy
NAME STATE IPV4 IPV6 GROUPS AUTOSTART
----------------------------------------------------------------
cpi-trusty STOPPED - - - NO
juju-trusty-lxc-template STOPPED - - - NO
sca-trusty STOPPED - - - NO
sso-trusty STOPPED - - - NO

Replying to:

"FWIW: that script is just:

#!/bin/bash
sudo service gunicorn stop
trap 'sudo service gunicorn start' INT
bash /srv/gunicorn/run_sso_wsgi.sh $@

We could actually get rid of this, perhaps. Some thing like:

run: gunicorn-stop
    @trap 'sudo service gunicorn start' INT;
/srv/gunicorn/run_sso_wsgi.sh --bind=$(ARGS) --reload
--error-logfile=- --access-logfile=- --timeout=99999

would probably work. I can have a look at that if you've prefer to get
rid of the script?"

I would prefer to get rid of the script mainly because having the script mean that when reading the Makefile it requires to go an open other script in other folder; and also sometimes I try to cleanup stuff and is not trivial to know where a script is used or not, to decide if it can be removed.

On Wed, Nov 18, 2015 at 12:15 PM, Natalia Bidart
<email address hidden> wrote:
> I pulled the changes. A run of make clean without the env var and I run with it both succeded with the same output:
>
> nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
> rm -rf /home/nessita/canonical/bloodearnest/sso-dev/env
> rm -rf branches/wheels
> rm -rf ../.juju-repo
> rm -rf branches/*
> rm -rf logs/*.*
> rm -rf staticfiles
> rm -f lib/versioninfo.py
> rm -f targets.mk
> find -name '*.pyc' -delete
> find -name '*.~*' -delete
> nessita@dali:~/canonical/bloodearnest/sso-dev$ export I_CAN_HAZ_JUJU=yes
> nessita@dali:~/canonical/bloodearnest/sso-dev$ make clean
> (Makefiles changed - rebuilding lxc target list)
> rm -rf
> rm -rf
> rm -rf
> rm -rf branches/*
> rm -rf logs/*.*
> rm -rf staticfiles
> rm -f lib/versioninfo.py
> rm -f targets.mk
> find -name '*.pyc' -delete
> find -name '*.~*' -delete
> nessita@dali:~/canonical/bloodearnest/sso-dev$
>
> Were you expecting this or there is some randomness around?

This is correct. Most make targets are unaltered and shared between
old and new dev envs

> What confuses me is that I don't see the container in my list of containers:
>
> nessita@dali:~/canonical/bloodearnest/sso-dev$ sudo lxc-ls --fancy
> NAME STATE IPV4 IPV6 GROUPS AUTOSTART
> ----------------------------------------------------------------
> cpi-trusty STOPPED - - - NO
> juju-trusty-lxc-template STOPPED - - - NO
> sca-trusty STOPPED - - - NO
> sso-trusty STOPPED - - - NO

lxd and lxc containers are differently managed. Try

lxc list

FYI lxd containers are in /var/lib/lxd/containers, not /var/lib/lxc

--
Simon

On Wed, Nov 18, 2015 at 12:24 PM, Natalia Bidart
<email address hidden> wrote:
> Replying to:
>
> "FWIW: that script is just:
>
> #!/bin/bash
> sudo service gunicorn stop
> trap 'sudo service gunicorn start' INT
> bash /srv/gunicorn/run_sso_wsgi.sh $@
>
> We could actually get rid of this, perhaps. Some thing like:
>
> run: gunicorn-stop
> @trap 'sudo service gunicorn start' INT;
> /srv/gunicorn/run_sso_wsgi.sh --bind=$(ARGS) --reload
> --error-logfile=- --access-logfile=- --timeout=99999
>
> would probably work. I can have a look at that if you've prefer to get
> rid of the script?"
>
> I would prefer to get rid of the script mainly because having the script mean that when reading the Makefile it requires to go an open other script in other folder; and also sometimes I try to cleanup stuff and is not trivial to know where a script is used or not, to decide if it can be removed.

Ok, I will try this approach.

--
Simon

Thank you for all the answers and improvements. I tried a new run from scratch, issuing:

$ make lxc-delete
$ make clean

$ make lxc-setup
Using saved parent location: bzr+ssh://bazaar.launchpad.net/~bloodearnest/+junk/ols-tools/
No revisions or tags to pull.
./branches/ols-tools/setup-devel-lxd sso /srv/login.ubuntu.com/devel
Using lxc sso
Checking ssh key set up...done
Setting up posgtresql init on /dev/shm on boot...done
Device .home removed from sso
Device .src removed from sso
Device .logs removed from sso
Device .etc removed from sso
Device .home added to sso
Device .src added to sso
Device .logs added to sso
Device .etc added to sso
Creating fake tarball...done.
Setting up nessita for passwordless sudo...done.
Removing landscape-common...done.
Checking for network access...done.
Updating package index...done.
Installing ppa deps...done.
Installing juju stable ppa...done.
Updating package index (again)...done.
Updating system packages...done.
Installing required packages...done.
Cleaning up packages...done.
Configuring lxc sshd...done.
Restarting ssh...done.
Updating sso juju environment to use lxc ip 10.0.3.41
Checking for basenode access...done
Checking for CAT access...done.
Updating basenode...done.
Installing basenode...done.

And then make bootstrap, which fails as follow (I'm connected to the VPN):

nessita@dali:~/canonical/bloodearnest/sso-dev$ make bootstrap
cat dependencies.txt | xargs sudo apt-get install -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-amqplib is already the newest version.
python-bson is already the newest version.
python-iso8601 is already the newest version.
python-launchpadlib is already the newest version.
python-m2crypto is already the newest version.
python-memcache is already the newest version.
python-psutil is already the newest version.
python-psycopg2 is already the newest version.
python-simplejson is already the newest version.
python-testresources is already the newest version.
python-bcrypt is already the newest version.
python-beautifulsoup is already the newest version.
python-virtualenv is already the newest version.
bzr is already the newest version.
python-lxml is already the newest version.
python-tz is already the newest version.
python-yaml is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
cat dependencies-devel.txt | xargs sudo apt-get install -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version.
libxslt1-dev is already the newest version.
make is already the newest version.
memcached is already the newest version.
python-dev is already the newest version.
screen is already the newest version.
swig is already the newest version.
config-manager is already the newest version.
firefox is already the newest version.
gettext is already the newest version.
libpq-dev is already the newest version.
libxml2-dev is already the newest version.
postgresql-client-9.3 is already the newest version.
postgresql-contrib-9....

>> === modified file 'src/identityprovider/tests/test_command_cleanup.py'
>> --- src/identityprovider/tests/test_command_cleanup.py 2015-04-30 17:20:09 +0000
>> +++ src/identityprovider/tests/test_command_cleanup.py 2015-11-17 13:23:47 +0000
>> @@ -48,8 +48,8 @@
>>
>> def make_test_accounts(self, count=0, date_created=None):
>> for i in xrange(count):
>> - email = self.factory.make_email_address(prefix='isdtest+',
>> - domain='canonical.com')
>> + email = self.factory.make_email_address(prefix='testemail+',
>> + domain='example.com')
>
> What's the rationale for this change? The job needs to clear from the DB all email addressed created by the acceptance tests, which use the isdtest+ prefix, so changing it will not trigger the right cleanup.

So, one of the things I tried to do was "normalise" the dev acceptance
test configuration, so it could just be part default devel
configuration. This would mean that a) you wouldn't need access to the
config branch to run acceptance tests and b) could run the acceptance
tests against the dev server OOTB with no config changes, which
simplified stuff a lot.

The only thing in the *dev* acceptance settings that was at all
sensitive was the isdtest email stuff, as it might leak info about our
production config.

Now, the isdtest email stuff was already in the code base anyway (like
in the above test), but I went ahead an made the default dev config
use <email address hidden>, and updated some tests that were expecting
other config.

I don't *think* this will have broken the clean up job, as that uses
the configured emails, which are unchanged in prod or staging.

But maybe I missed something?

--
Thanks

Poke... what's the status on this? Simon, could I at least request, if feasible, for you to merge trunk into this? I did so but there was a (minor) conflict, I think I solved it well enough that my local copy is working but I'd be more at ease if I knew you did the right thing while merging :)

The actual reason I'm asking is this: I tried running acceptance tests in my old-style lxc setup and failed miserably. The set of config directives I used to just inject in my ../local_config/settings.py no longer "just works", and after spending a couple of hours trying, I gave up and decided to give sso-dev another whirl. Acceptance tests worked magically out of the box. So I'm wondering if perhaps the work done to remove the settings-by-symlink workflow broke the old way of doing acceptance testing.

Does this make sense to you? What do I need to do now in order to run acceptance tests locally? OTOH if it's easier to just use sso-dev, that's fair enough, but we'd need to push for this to land so that people wanting to run acceptance aren't left in the same limbo as me (or I was just being extra dumb today - always a possibility, particularly on Mondays).

Thanks and apologies for the rant!

On Mon, Dec 7, 2015 at 10:37 PM, Daniel Manrique
<email address hidden> wrote:
> Poke... what's the status on this? Simon, could I at least request, if feasible, for you to merge trunk into this?

Done. All tests passing.

> I did so but there was a (minor) conflict, I think I solved it well enough that my local copy is working but I'd be more at ease if I knew you did the right thing while merging :)

Yep, it was just bzr merge failing hard on trivial changes, for
unknown reasons :)

> The actual reason I'm asking is this: I tried running acceptance tests in my old-style lxc setup and failed miserably. The set of config directives I used to just inject in my ../local_config/settings.py no longer "just works", and after spending a couple of hours trying, I gave up and decided to give sso-dev another whirl. Acceptance tests worked magically out of the box. So I'm wondering if perhaps the work done to remove the settings-by-symlink workflow broke the old way of doing acceptance testing.

Hmm, it shouldn't have. ../local_config/settings.py is still used, but
just via PYTHONPATH, not a symlink. I did test the acceptances tests
with that change, with out issue. I will try again.

However, the old way of running acceptance tests (via run-tests and
scripts/acceptance-tests) mv's ../local_config/settings.py out of the
way, writes its own version there, runs the server and tests, and then
copies back your old settings.py. So, to my knowledge, you've never
been able to manually tweak ../local_config/settings.py when running
tests this way.

However, if you run the server yourself manually, and run the tests
separately with make run-acceptance, then your local settings.py is
used (and you'll need to have the acceptance relations

The sso-dev work removes all this complexity. The is now no difference
between devel settings and the acceptance tests settings, so no file
mv'ing needed. It also already has an sso server and mail server
running, so everything is much simpler when it comes to running

> Does this make sense to you? What do I need to do now in order to run acceptance tests locally? OTOH if it's easier to just use sso-dev, that's fair enough, but we'd need to push for this to land so that people wanting to run acceptance aren't left in the same limbo as me (or I was just being extra dumb today - always a possibility, particularly on Mondays).

I would like to land, but still waiting on review approval, there's
some outstanding comments. I will ask Natalia to have a look again.

> Thanks and apologies for the rant!

No worries - sorry it's not landed yet :(

--
Simon

On Tue, Dec 8, 2015 at 11:18 AM, Simon Davy <email address hidden> wrote:
> On Mon, Dec 7, 2015 at 10:37 PM, Daniel Manrique
> <email address hidden> wrote:
>> Poke... what's the status on this? Simon, could I at least request, if feasible, for you to merge trunk into this?
>
> Done. All tests passing.
>
>> I did so but there was a (minor) conflict, I think I solved it well enough that my local copy is working but I'd be more at ease if I knew you did the right thing while merging :)
>
> Yep, it was just bzr merge failing hard on trivial changes, for
> unknown reasons :)
>
>> The actual reason I'm asking is this: I tried running acceptance tests in my old-style lxc setup and failed miserably. The set of config directives I used to just inject in my ../local_config/settings.py no longer "just works", and after spending a couple of hours trying, I gave up and decided to give sso-dev another whirl. Acceptance tests worked magically out of the box. So I'm wondering if perhaps the work done to remove the settings-by-symlink workflow broke the old way of doing acceptance testing.
>
> Hmm, it shouldn't have. ../local_config/settings.py is still used, but
> just via PYTHONPATH, not a symlink. I did test the acceptances tests
> with that change, with out issue. I will try again.

Using ./run-tests dev, the acceptance tests ran fine for me on r1374

Thanks

--
Simon

Argh, so I did ./run-tests dev (note, using trunk, not sso-dev) and it still won't run acceptance :( (r1376 here).

What I'm seeing is that ./run-tests dev starts by unconditionally bootstrapping, which I think destroys my ../local_config/settings.py, so by the time the acceptance tests start, the config is all borked and obviously they fail.

No worries though, I have a reasonable workaround by using sso-dev whenever I need acceptance tests run ;) (which is not often, really).

Ohnoes... here comes Daniel with more crazy problems...

Apparently once the container is shut down and restarted, part of the db configuration changes, so on next boot it fails with (ultimately) this:

django.db.utils.OperationalError: FATAL: password authentication failed for user "ssoadmin"

How to repro (I_CAN_HAZ_JUJU assumed to be set at all times):

(maybe delete any old sso containers with lxc delete)
(set up my crazy /src mount in the ols-dev profile)
get a checkout of sso-dev
merge latest trunk (I did this myself, maybe I screwed up?)
make lxc-setup
make bootstrap
ssh into container, change to /src/blahblah/sso-dev dir
make test ARGS=some.quick.test
*it works*
sudo poweroff (the container!)
lxc start sso
wait until juju stabilizes (on startup a series of config-changeds fire up)
ssh into container, change to /src/blahblah/sso-dev dir
make test ARGS=some.quick.test
* now it fails with the above-shown message *

Logging out of the container and redoing "make bootstrap" from the host brings things to a working state again, but I seem to recall this shouldn't be necessary.

On Wed, Jan 6, 2016 at 10:16 PM, Daniel Manrique
<email address hidden> wrote:
> Ohnoes... here comes Daniel with more crazy problems...
>
> Apparently once the container is shut down and restarted, part of the db configuration changes, so on next boot it fails with (ultimately) this:
>
> django.db.utils.OperationalError: FATAL: password authentication failed for user "ssoadmin"
>
> How to repro (I_CAN_HAZ_JUJU assumed to be set at all times):
>
>
> (maybe delete any old sso containers with lxc delete)
> (set up my crazy /src mount in the ols-dev profile)
> get a checkout of sso-dev
> merge latest trunk (I did this myself, maybe I screwed up?)
> make lxc-setup
> make bootstrap
> ssh into container, change to /src/blahblah/sso-dev dir
> make test ARGS=some.quick.test
> *it works*
> sudo poweroff (the container!)
> lxc start sso
> wait until juju stabilizes (on startup a series of config-changeds fire up)
> ssh into container, change to /src/blahblah/sso-dev dir
> make test ARGS=some.quick.test
> * now it fails with the above-shown message *
>
> Logging out of the container and redoing "make bootstrap" from the host brings things to a working state again, but I seem to recall this shouldn't be necessary.

It shouldn't. I will look into it, and merge trunk in the process

FYI, there are lxc-start and lxc-stop make commands which I would
encourage rather than sudo poweroff

--
Simon

Hello :)