[07:24] <lazyPower|Sprint> stub: ping
[07:26] <stub> lazyPower|Sprint: pong
[07:26] <lazyPower|Sprint> Hey stub, i'm looking @ https://code.launchpad.net/~james-w/charms/precise/postgresql/metrics/+merge/231322
[07:27] <lazyPower|Sprint> sorry incomplete thought and moving sessions, 1 moment
[07:28] <stub> lazyPower|Sprint: Dammit... I thought my 2 months of PG charm patches was getting a review ;)
[07:30] <lazyPower|Sprint> stub: they aren't in the queue that i see
[07:30] <lazyPower|Sprint> stub: http://review.juju.solutions
[07:31] <stub> lazyPower|Sprint: http://review.juju.solutions/review/1086, 6 days since last touch
[07:32] <stub> (but this is the  rollup branch requested, containing MPs dating from over 2 months ago)
[07:32] <lazyPower|Sprint> ooooo
[07:32] <lazyPower|Sprint> tests
[07:32] <lazyPower|Sprint> argh, rollup branches :(
[07:33] <stub> Hey, it used to be in 7 nicely separated patches
[07:33] <lazyPower|Sprint> wait, you mean this is 1 branch to review then/
[07:33] <lazyPower|Sprint> <3 you just made my day, i thought i had to go back through the 7 pending branches
[07:34] <stub> lazyPower|Sprint: Yeah, all those old branches got mushed together into this big MP on request
[07:34] <lazyPower|Sprint> hrm, this is a rather large MP
[07:34] <lazyPower|Sprint> i blame tvansteenburgh
[07:34] <stub> Although I'm not sure why you guys like that - for the last 10 years everyone around here has been focused on ways of keeping the MPs of small and manageable size ;)
[07:35] <lazyPower|Sprint> well, seeing the sheer size of this, i agree w/ that sentiment
[07:35] <stub> lazyPower|Sprint: I've got another 1500 lines of diff nearly ready to go ;)
[07:35] <lazyPower|Sprint> i'm just used to the GH workflow. I'm a LP noob
[07:36] <stub> I'd consider separating review and landing
[07:36] <stub> Review is just 'does this code look good'. 'Is this code an improvement'.
[07:36] <stub> And you want a small, self contained diff for that.
[07:36] <stub> Landing is about lint, tests etc. and ideally handled by a bot.
[07:37] <lazyPower|Sprint> we're getting closer to that
[07:37] <lazyPower|Sprint> our CI is just about there for this, which means we're literally wrapping the step before introducing bot landing
[07:38] <lazyPower|Sprint> ty for fixing the tests, i'm about to pull and run this
[07:38] <stub> Yup. I'm looking forward to that. I'm hoping to get the tests stable enough too, although that might make then annoyingly slow due to 'juju wait' needing a longer pause.
[07:39] <stub> The earlier reviews had picked up some genuine races, which I think I've fixed.
[07:39] <stub> But this branch still works better than trunk atm :)
[07:55] <stub> lazyPower|Sprint: I was planning on landing https://code.launchpad.net/~james-w/charms/precise/postgresql/metrics/+merge/231322 once I've got my queue cleared (getting the charm in shape to deploy Launchpad with it atm). I think there were things james wanted to fix on it, but I don't recall what now and it should be in a landable state as it is.
[07:55] <stub> Maybe just make the minor changes, stick run-one in the crontab stuff.
[07:57] <stub> IIRC james was going to make some changes, but got diverted to other things.
[07:57] <stub> But I want the statsd stuff in, so sod waiting.
[08:13] <lazyPower|Sprint> ack
[08:13] <lazyPower|Sprint> I'll be loking into merging this massive change
[08:14] <lazyPower|Sprint> a bit preoccupied with charm store triage atm, but will circle back to this before i EOD
[11:02] <zezom> I'm currently running proxmox at home on a single server + NAS but I'm quite impressed with what I've seen juju do. Unfortunately I am unable to tell if I can run MAAS and JUJU on the same single server. I would like the ability to add more servers in the future but for now one server is all I have.
[11:05] <zezom> I've read through the MAAS install doco on ubuntu.com but it doesn't say if the MASS controller install can run any virtual's on it's self or if it's only used to bootstrap other nodes to run virtual's.
[11:05] <lazyPower|Sprint> stub: looks like there's an interestinng mismatch between this branch and trunk.
[11:05] <stub> really? I thought I had them in sync
[11:06] <lazyPower|Sprint> Text conflict in hooks/hooks.py, Text conflict in test.py - i'm getting issues between the tests and hooks
[11:06] <lazyPower|Sprint> possibly they were at one point, i haven't looked to see if anything has been merged recently,  i just pulled the source and started prepping my env to dive into this giant
[11:08] <stub> lazyPower|Sprint: There was one revision unpushed... pushed it now.
[11:08] <stub> lazyPower|Sprint: yeah, it was 'merge trunk'. Sorry about that.
[11:09] <lazyPower|Sprint> all good :)
[11:09] <stub> Launchpad is supposed regenerate the diff and highlight this :-(
[11:09] <stub> That would be the lint fixes I landed for Adam, that were also lurking in this integration branch.
[11:12] <lazyPower|Sprint> stub: i've seen a few braches so far that haven't highlighted merge issues
[11:13] <lazyPower|Sprint> i think that *only* works if its got an issue when it's first pushed
[11:13] <lazyPower|Sprint> it doesn't continue to track the behavior of the branch if its diverged from trunk
[11:13] <stub> I can't really recall now.
[11:14] <stub> I normally remember to push so it isn't an issue ;)
[11:19] <lazyPower|Sprint> stub: i'm making it an even shorter distance than my colleagues have
[11:19] <lazyPower|Sprint> http://paste.ubuntu.com/8532283/
[11:21] <stub> lazyPower|Sprint: Do you have a JUJU_REPOSITORY set, with trusty/postgresql pointing to the right location? And you will need postgresql-psql too if you are testing with trusty
[11:22] <stub> Not that running tests is reviewing ;) That is something you do before landing.
[11:23] <lazyPower|Sprint> stub: we should add these to the dependency targets for making the tests. CI would fail miserably on this
[11:23] <lazyPower|Sprint> it expects whatever bundletester executes, to do everything it needs to successfully run the tests. I see what you've got in  here pre-dates amulet
[11:23] <stub> Yes, I need to switch to amulet. I think it supports most of what I need now, and I can probably add the rest.
[11:24] <lazyPower|Sprint> oh i wasnt saying re-write in amulet, i just noticed you built a fixture harness
[11:24] <lazyPower|Sprint> which is kind of neat tbh
[11:24] <stub> No, rewriting in amulet is a goal I have. I will then be able to put my fixture for driving amulet into the amulet package.
[11:33] <lazyPower|Sprint> stub: is postgresql-psql a pip package? I'm not seeing anything in apt to satisfy the dependency
[11:34] <stub> lazyPower|Sprint: it is cs:precise/postgresql-psql
[11:34] <lazyPower|Sprint> oh! charm dependency
[11:34] <lazyPower|Sprint> ack
[11:34] <stub> lazyPower|Sprint: I've avoided getting it pushed to trusty, since I'd rather embed it into the PostgreSQL charm for testing like amulet does with its sentinals.
[11:35] <stub> Currently, it pretends to be a general purpose cli, but it really mainly used by my test suite, and ends up sucking for both purposes.
[11:46]  * lazyPower|Sprint grins
[11:46] <lazyPower|Sprint> I've got a few projects along that vein
[11:46] <lazyPower|Sprint> yeah, i'm not getting any luck running the test suite
[11:47] <lazyPower|Sprint> the code review portion looks fine, i dont see anything detrimental in this codeblock but i'm hesitant to rubberstamp the merge without the warm fuzzy feeling of getting test feedback
[11:47] <stub> So we can fix that, or I can promise to confirm they pass before landing, or I can disable most of the tests ;)
[11:47] <lazyPower|Sprint> option 3 sounds like a wash
[11:47] <lazyPower|Sprint> option 2 is 'ok'ish but sets a precident
[11:47] <lazyPower|Sprint> i'd rather go with option 1 if at all possible
[11:48] <stub> Cause even if I disable the integration tests, I still have more tests than most charms ;)
[11:48] <lazyPower|Sprint> and we <3 you for that stub
[11:48] <lazyPower|Sprint> how do we go about fixing this? I'm not picking up where its failing, its like its not even attempting to make the deployment when i run make test (which is what bundletster is doing)
[11:49] <lazyPower|Sprint> juju status shows i just have the bootstrap. my JUJU_REPOSITORY is exported, and i have the postgresql-psql charm in that local repo
[11:49] <stub> I'm already landing almost all the work on this charm. Just it would be evil to review and land my own work :)
[11:49]  * lazyPower|Sprint nods
[11:49] <stub> You have the same error as before? juju deploy fails?
[11:49] <lazyPower|Sprint> i want to make this process less painful for everyone involved, and i've got the time to do this. i don't have any other blocks today that i'm implicitly scheduled to be at
[11:49] <lazyPower|Sprint> yeh
[11:49] <lazyPower|Sprint> let me capture that output for you
[11:51] <lazyPower|Sprint> http://paste.ubuntu.com/8532440/
[11:51] <lazyPower|Sprint> there's a snippet of the error output
[11:51] <stub> CalledProcessError: Command '['juju', 'deploy', '--config=/tmp/tmpyCZBRK/config.yaml', 'local:trusty/postgresql', 'postgresql', '-n', '1']' returned non-zero exit status 1
[11:51] <lazyPower|Sprint> wait
[11:51] <lazyPower|Sprint> i see it
[11:52] <lazyPower|Sprint> its looking for trusty/postgresql
[11:52] <lazyPower|Sprint> i have precise branched, and placed locally
[11:52] <stub> Right
[11:52] <lazyPower|Sprint> cheese and rice
[11:52] <lazyPower|Sprint> so this should target the trusty charm, as well as the MP then
[11:52]  * lazyPower|Sprint facepalms
[11:52] <lazyPower|Sprint> what am i doing with my life
[11:53] <stub> So lp:charms/precise/postgresql and lp:charms/trusty/postgresql are identical
[11:53] <lazyPower|Sprint> opportunity to make the tests more intuitive, as precise tests will *always* fail in this context
[11:53] <lazyPower|Sprint> but thats a matter for another day
[11:54] <stub> make test SERIES=precise will override the default series in your environment
[11:54] <stub> Otherwise, it will test the default series in your environment
[11:55] <lazyPower|Sprint> hmm
[11:55] <lazyPower|Sprint> i should make that a follow up item to investigate making test targets easier to work with, and sniffable from the path or something.
[11:56] <lazyPower|Sprint> that way if set use env, otherwise look @ path and use that to determine the series
[11:56] <stub> Yeah, it isn't pretty how I've got it
[11:56] <lazyPower|Sprint> i dont think this is just your problem. we have the same issue in amulet
[11:56] <stub> Maybe that will come out in the wash if I can get rid of this JUJU_REPOSITORY setup requirement?
[11:56] <lazyPower|Sprint> you either define series=precise|trusty  when you declare amulet.deployment()
[11:56] <lazyPower|Sprint> well, thats gone in amulet as well
[11:57] <lazyPower|Sprint> but it doesn't support local: links, you pass it the name of the charm, and all others are defined with cs: url's
[11:57] <lazyPower|Sprint> so you can't test 2 modified targets at once, which is a limitation (or feature, depending on how you look at it) of the amulet workflow
[11:57] <stub> The automatic test environment could just set some environment variables that amulet or other test suites sniff. No need to overengineer for this case.
[11:57] <lazyPower|Sprint> so for example, if these tests were amulet, it would just be d.add('postgresql') and thats enough for amulet to know to deploy the local copy of the charm.
[11:58] <lazyPower|Sprint> it uses the name of the charm from metadata.yaml and matches on that
[11:58] <lazyPower|Sprint> however, it looks more promising this time around now that i'm using the proper series
[11:58] <lazyPower|Sprint> i think this bit cory_fu as well looking over the feedback chain
[11:58] <stub> This is why we make bots run the tests ;)
[11:58] <stub> Yeah
[11:58] <stub> Cause who the hell still uses precise?
[11:59] <stub> (I don't! I should get the default branch switched to trusty)
[12:02] <stub> So generally, I'll see on average one test fail that works just fine when it is rerun alone, which I chalk up to the deployed services not being settled properly before the actual test is made
[12:02] <stub> Although I've improved that an awful lot on this branch (and slower now too T_T)
[12:04] <lazyPower|Sprint> well its still not deploying the tests
[12:04] <lazyPower|Sprint> same feedback, regardless of SERIES= during make test, or moving everything to trusty
[12:05] <stub> What does it tell you if you manually run the 'juju deploy' command, sans --config=/tmp/xxx
[12:05] <lazyPower|Sprint> i think the core issue here is the tests arent architected to be satisfied when run via bundletester. (however i'm getting the same result with make test)
[12:05] <lazyPower|Sprint> ooo well thats interesting
[12:05] <lazyPower|Sprint> Added charm "local:precise/postgresql-10" to the environment. ERROR cannot add service "postgresql": environment is no longer alive
[12:06] <stub> Has anyone packaged bundletester yet?
[12:06] <lazyPower|Sprint> indeed!
[12:06] <lazyPower|Sprint> its pip installable
[12:06] <lazyPower|Sprint> pip install bundletester
[12:06] <lazyPower|Sprint> looking into wth is going on with my local environment
[12:06] <stub> Gah... pooping all over FS without apt
[12:07] <stub> I'll put together a recipe build if I get bored ;)
[12:08] <lazyPower|Sprint> stub: source ~/.venv/bin/activate
[12:08] <lazyPower|Sprint> pip install bundletester
[12:08] <lazyPower|Sprint> no longer polluting anything, or you can even pass --user to install to ~/.local
[12:09] <stub> Where is ~/.venv coming from? Last I used virtualenv it was more manual
[12:09] <lazyPower|Sprint> you initialize it
[12:09] <lazyPower|Sprint> virtualenv ~/.venv
[12:09] <stub> oh, cool
[12:09] <lazyPower|Sprint> yeah, i do that when i want to test python modules - as its more of a 'bundler' experience
[12:09] <lazyPower|Sprint> and i'm the unpopular rails guy that got hired :)
[12:10] <stub> I've been using lxc, but had issues with juju inside lxc creating lxc containers...
[12:10] <lazyPower|Sprint> yikes. yeah
[12:10] <lazyPower|Sprint> it gets a bit angry about that
[12:11] <lazyPower|Sprint> hav eyou looked @ our vagrant story? after a networkin bugfix lands it'll be a nice alternative if you want isolated 'fresh cloud image' style testing
[12:11] <stub> Not yet. I'm backlogged on a couple of projects :-(
[12:11] <stub> So many things to do, so little enthusiasm ;)
[12:11] <lazyPower|Sprint> presently there's a route added that makes everything appear as if its coming from the gateway address - which unfortunately makes the postgresql ACL setting fail fantastically
[12:12] <lazyPower|Sprint> hurray for packet rewriting
[12:12] <lazyPower|Sprint> \o/
[12:13] <lazyPower|Sprint> i think aisrael actually pointed that one out a few weeks ago
[12:13] <tvansteenburgh> lazyPower: amulet actually does support local: urls now
[12:14] <lazyPower|Sprint> tvansteenburgh: wat
[12:14] <lazyPower|Sprint> why aren't we shouting from mountain tops about the awesomeness now?
[12:14] <tvansteenburgh> i added that recently-ish?
[12:14] <tvansteenburgh> shouting to whom?
[12:14] <stub>   Analyzing links from page https://pypi.python.org/simple/lazr.authentication/
[12:14] <stub>     Skipping link https://launchpad.net/lazr.authentication (from https://pypi.python.org/simple/lazr.authentication/); unknown archive format: .authentication
[12:14] <stub> :-P
[12:15] <tvansteenburgh> odd
[12:15] <tvansteenburgh> is that with pip install?
[12:16] <stub> Yes, but hmm.... might be mixing venv python with non-vm pip
[12:16] <lazyPower|Sprint> tvansteenburgh: in charmhelpers, the config object is read only yeah?
[12:16] <tvansteenburgh> nope
[12:17] <tvansteenburgh> you can save arbitrary data in it
[12:17] <lazyPower|Sprint> i have evidence that it gets saved to the archive, but its not coming back out when referenced
[12:17] <stub> nah, carping on about --allow-external (which doesn't seem to be a supported option)
[12:17] <tvansteenburgh> stub: valid option, is pip out of date?
[12:17] <stub> The config object is writable, and should be saved on successful exit if you are using @hook or the services framework.
[12:18] <tvansteenburgh> stub: e.g. https://github.com/juju-solutions/bundletester#installation
[12:18] <lazyPower|Sprint> well we know its getting saved, but it doesn't appear to be getting loaded
[12:19] <stub> This is from 'sudo apt-get install python-virtualenv; virtualenv ~/.venv; source ~/.venv/bin/activate; ~/.venv/bin/pip install bundletester'
[12:19] <stub> fresh trusty
[12:19] <stub> well... old trusty, but fresh venv
[12:21] <tvansteenburgh> stub: and you are passing the --allow- options ?
[12:22] <rbasak> marcoceppi_: around? Any news on removing the sentries from amulet?
[12:22] <tvansteenburgh> lazyPower: want extra eyes on the config stuff?
[12:22] <tvansteenburgh> rbasak: yeah we're still planning to do it :)
[12:23] <rbasak> tvansteenburgh: OK, thanks. In the meantime I think I'll drive what I need from the shell instead. Do you have any idea how I might wait for a hook to finish firing after I trigger one with add-relation or destroy-relation or something?
[12:23] <rbasak> How will amulet do that?
[12:23] <tvansteenburgh> rbasak: there are some helpers for stuff like that in amulet, you may be able to reuse
[12:24] <rbasak> I thought they currently relied on the sentries?
[12:24] <stub> So --allow-external lazr.authentication and --allow-unverified lazr.authentication required it seems, which is not good for me to do on this box :-(
[12:24] <lazyPower|Sprint> tvansteenburgh: not just yet, gimme another 5, doing env inspection
[12:24] <tvansteenburgh> stub: it's the only way, unless you can convince someone from lazr to publish on pypi
[12:24] <stub> Heck, I might have rights to do that.
[12:25] <tvansteenburgh> omg you would be my hero
[12:25] <lazyPower|Sprint> tvansteenburgh: its not loading the .charm_persistent_config
[12:25] <tvansteenburgh> rbasak: memory is a little rusty on how it's done exactly, i'd just take a look and see
[12:25] <lazyPower|Sprint> tvansteenburgh: appears related to scope possibly?
[12:25] <tvansteenburgh> scope of?
[12:26] <lazyPower|Sprint> @cached
[12:26] <lazyPower|Sprint> its saving this in $CHARM_DIR/CONFIG_FILE_NAME
[12:26] <lazyPower|Sprint> whatever that gets init'd to, in this case, its .persistent_charm_config
[12:27] <lazyPower|Sprint> and the config() object is passed a dest_dir key/value, and it shows at end of install print
[12:27] <stub> leonard.... I might still have his email around here somewhere...
[12:27] <lazyPower|Sprint> when config() is loaded in config_changed() - it's missing a key/value that's present in the file.
[12:28] <tvansteenburgh> lazyPower: i'm gonna come downstairs, having trouble following
[12:28] <lazyPower|Sprint> ack
[12:33] <stub> hookenv.config_data() uses the @cached decorator, so it is returning a singleton. It will only be loaded on process startup.
[12:33] <stub> First invocation I mean
[12:43] <lazyPower|Sprint> stub: it was an interesting omission from get_item()
[12:44] <tvansteenburgh1> had to override keys() in Config, the data was there, you just couldn't see it in keys()
[12:46] <stub> sounds like a bug. would never have suspected a bug ;)
[12:46] <tvansteenburgh> haha
[12:59] <stub> So I just got a automatic test run result, and the same problem as lazyPower|Sprint . The test suite is detecting the default series is trusty, and attempting to deploy that.
[13:01] <stub> But the branch being tested is precise, so everything fails.
[13:02] <lazyPower|Sprint> stub: yeah :( i'm working through this a layer at a time
[13:02] <lazyPower|Sprint> trying to unwind complexity
[13:03] <lazyPower|Sprint> i got it to deploy by moving it  to trusty, however install is failing consistently as its not deploying with +x perms on hooks.py - and i'm confused as to how that happened
[13:03] <stub> easy fix for me is to have the runner set the SERIES environment, cause then I don't need to update anythng ;)
[13:04] <stub> huh - hooks.py doesn't have the execute bit here
[13:06] <stub> lazyPower|Sprint: Try refreshing the branch. I just pushed a change to the perms to that file.
[13:26] <lazyPower|Sprint> stub: they're firing off like crazy atm i should have resutls shortly
[13:48] <lazyPower|Sprint> stub: this branch looks good in CR format, the tests need more work at the end of the day
[13:49] <lazyPower|Sprint> i'm going to make the associated comment on the MP and run the readme deployment tests. so long as everything passes standup i'm happy with whats here
[13:52] <stub> ta
[13:52] <lazyPower|Sprint> np, ty for taking me through the ropes of the unfamiliar territory of pgsql tests
[14:29] <vtolstov> hello
[14:30] <vtolstov> does somebody helps me and say: how can i provide website: interface: http and https ?
[14:30] <jamespage> coreycb,
[14:30] <jamespage> https://code.launchpad.net/~corey.bryant/charms/trusty/cinder/remove-missing/+merge/237439
[14:30] <vtolstov> how can i specify array or what i need to do?
[14:30] <jamespage> unit test failures
[14:31] <coreycb> jamespage, doh
[14:32] <jamespage> coreycb, :-)
[14:36] <jamespage> coreycb, if you have time - https://code.launchpad.net/~james-page/charms/trusty/neutron-openvswitch/disable-security-groups/+merge/237933
[14:36] <jamespage> we're running that on serverstack :-)
[14:37] <coreycb> jamespage, sure I'll take a look - oh so it's being tested atm :)
[14:37] <coreycb> jamespage, btw, does it make sense to add openstack-origin and openstack upgrade support to that charm?
[14:37] <jamespage> coreycb, no because its a suboridinate; it would get upgraded by its principle
[14:38] <coreycb> jamespage, ok, was wondering about that
[14:38] <jamespage> however having it twiddle is config might be a good idea
[14:38] <jamespage> right now its not an issue
[14:38] <coreycb> ok
[14:38] <coreycb> jamespage, so nova-compute presumably reinstalls packages for it?
[14:39] <jamespage> coreycb, yes it will
[14:39] <coreycb> jamespage, ok
[14:39] <jamespage> coreycb, this would get tricky if the list of packages needed to change - but atm it does not
[14:39] <jamespage> ...
[14:39] <jamespage> so we are OK for now
[14:39] <jamespage> not ruling out altogether tho
[14:40] <coreycb> jamespage, ok, there are a decent amount of tempest failures after upgrade so I wanted to blame it on that.  I need to dig some more.
[14:40] <jamespage> coreycb, icehouse -> juno?
[14:40] <coreycb> yes
[14:40] <jamespage> coreycb, there will be because of that neutron ipset bug I just uploaded a fix for
[14:41] <jamespage> without it you can't spin up instances....
[14:41] <coreycb> jamespage, ah maybe that's it.  yeah that would do it.
[14:41] <jamespage> basically the port creation fails because neutron can't setup the security correctly
[14:43] <roadmr> Hello folks, I had trouble getting nested lxc working with juju; meaning, juju deploying to a local provider, and having the deployed workload start some containers (inside the local-instantiated container)
[14:43] <roadmr> anybody had success with this?
[14:53] <vtolstov> anybody knows ?
[17:44] <weblife> I am not able to bootstrap for some reason after I destroyed my last environment.  Boot strap will not load tool sets for my ubuntu distro 14.10.  My output: http://paste.ubuntu.com/8534392/
[17:45] <stokachu> weblife: yea its known issue
[17:45] <stokachu> weblife: they working on getting the certificate renewed i beleive
[17:45] <weblife> stokachu: thank you
[17:46] <weblife> stokachu: you hear about an eta?
[17:47] <stokachu> weblife: yea try it now just got word they updated the cert
[17:47] <stokachu> works in browser  but please test juju
[17:51] <stokachu> weblife: any luck?
[17:53] <weblife> trying now
[17:54] <weblife> launching
[17:54] <weblife> stokachu: launching
[17:55] <stokachu> weblife: cool
[17:58] <weblife> stokachu: success!
[18:03] <weblife> has the issue with running juju on the local and running external environments been fixed?  I want to install the local version for some test.
[18:39] <weblife> I just want the juju team to know I am using juju for my grad project.  Thanks for your work.
[23:50] <zezom> is it possible to run juju on a maas controller server?