=== fuzzy_ is now known as Ponyo === urulama-afk is now known as urulama === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [09:24] gnuoy, https://code.launchpad.net/~james-page/charms/trusty/quantum-gateway/fixup-utopic/+merge/235254 [09:24] fixup one for juno [09:24] juno on utopic that is [09:24] jamespage, \o/ looking now [09:46] * fabrice going for lunch with friends === fabrice is now known as fabrice|lunch === fabrice|lunch is now known as fabrice [12:45] hey arosales_ still planning on making some of those modifications to the juju/docs? === luca__ is now known as luca === ayr_ton is now known as ayr-ton [14:22] hey, who touched openerp last? [14:22] http://www.theopensourcerer.com/2014/09/how-to-install-openerp-odoo-8-on-ubuntu-server-14-04-lts/ [14:34] JoshStrobl, yes I need to get rolling on the charm guidelines. There was also some ideas to overall the charm walkthrough === allenap_ is now known as allenap === roadmr_ is now known as roadmr_afk [15:16] o/ JoshStrobl === balloons_ is now known as balloons === CyberJacz is now known as CyberJacob === TheRealMue is now known as TheMue === balloons is now known as Guest35774 === katco` is now known as katco === Guest35774 is now known as balloons_ === roadmr_afk is now known as roadmr === fabrice is now known as fabrice|dinner [16:21] Juju Users! How many of you are using DO? We could use YOUR votes! https://www.digitalocean.com/community/projects/juju-digitalocean-provider [16:51] charmer needed for simple review on icon + category [16:51] https://code.launchpad.net/~a.rosales/charms/precise/puppet/add-charm-icon-category/+merge/234359 [16:51] https://code.launchpad.net/~a.rosales/charms/precise/puppetmaster/add-icon-category/+merge/234362 [16:51] little self promotion, but coming up next on the review [16:54] ack, thanks arosales - will get these jammed out [17:24] aisrael: have a moment to talk about https://code.launchpad.net/~aisrael/charms/trusty/vem/lint-cleanup/+merge/234406? you do? awesome! [17:24] lazyPower: bring it [17:24] When you tested this, were you attempting to test against LXC inside of Vagrant? is that the core of the issue you outline in your comment [17:25] Correct. As I've discovered the past few days, there's some trickiness to getting some modules to work in the local environment. [17:25] yeah, especially this charm [17:25] the VEM charm is a software routing charm that bolts into openstack [17:25] * aisrael needs to add a caveats section to the local provider documentation [17:26] So all I did in the end with that charm is clean up the lint errors and move the tests to run under a virtualenv [17:29] i see this. do you have a cloud environment you can use to validate tests? [17:29] I typically run tests locally, if they are totally fubar'd i'll attempt at least once in a cloud provider - (aws, or HPCloud) - and if it fails there then i nack it. [17:32] niedbalski: ping [17:34] lazyPower: Yeah, I do now. I have DO working (and should have AWS soon) [17:35] ok. just a bit of a caveat when kicking off tests is we cant rely souly on the local provider as charmers. +1 for the feedback and the merge. I'm goign to follow up with niedbalski to kick these tests off in the lab he has access to for the cisco stuff. [17:35] thanks again aisrael [17:38] ack, good point === sarnold_ is now known as sarnold [17:55] charmes some others reviews in the queue that have a community review and/or small change that could use a quick look are: [17:55] https://code.launchpad.net/~tvansteenburgh/charms/precise/block-storage-broker/fix-tests/+merge/234168 [17:55] https://code.launchpad.net/~a.rosales/charms/trusty/mysql/add-default-keys/+merge/235064 [17:56] https://code.launchpad.net/~jorge/charms/trusty/mysql/fix-proof/+merge/234020 [17:56] https://code.launchpad.net/~wesmason/charms/precise/mongodb/fix-volumes/+merge/234670 [17:57] jcastro: fyi on https://code.launchpad.net/~jorge/charms/trusty/elasticsearch/remove-sets-metadata/+merge/234358 there is outstanding question from noodles on the sets [17:57] I remember this [17:57] marcoceppi, you told me this was old metadata, can you confirm? [17:58] lazyPower: for some reason auto charm testing didn't pass on https://code.launchpad.net/~a.rosales/charms/trusty/mongodb/jay-wren-faster-install/+merge/234241 but the log is not available. So I am going to re-run locally. [18:02] arosales: ack. ty for taking a look at it. [18:05] lazyPower: np. I'll let you know what I find. [18:06] lazyPower: if you have some time during your review I also posted some reviews above that have some community reviews on them and/or small changes that could use a charm to take a look. [18:06] arosales: werent' those tests giving you a headache at teh sprint, and you needed/wanted me to take a look at them? [18:07] ack, will look at this directly after gitlab. nearing completion of the MP testing [18:07] lazyPower: I thought I got some help on them, but let me see what bundle tester is saying. [18:11] jcastro: which is old metadata? sets? [18:11] yeah [18:11] the one you had me remove [18:11] that's what the MP is about [18:15] marcoceppi: this is related to the MP @ https://code.launchpad.net/~jorge/charms/trusty/elasticsearch/remove-sets-metadata/+merge/234358 [18:16] arosales: right, I've left a comment [18:16] * arosales fail should have checked first [18:16] marcoceppi: thanks! [18:17] marcoceppi: per your comment in https://code.launchpad.net/~jorge/charms/trusty/elasticsearch/remove-sets-metadata/+merge/234358 could you ack that MP? [18:18] wow, pyju, that is old [18:20] whoa, firs ttime i've seen this out of the gitlab charm in MONTHS [18:20] http://ec2-54-167-177-28.compute-1.amazonaws.com/ [18:20] hi5 to the contributor that fixed this [18:23] mbruzek: good looking out, i think you empowered this fix. https://bugs.launchpad.net/charms/+source/gitlab/+bug/1360594 [18:23] Bug #1360594: install hook failed - curl init.d/gitlab does not handle redirect [18:25] lazyPower: both curl -L and wget worked. Thanks lazyPower === balloons_ is now known as balloons [18:49] hi juju team, I'm trying to bootstrap juju on a maas node here, I see the node come up and then disconnect from the network [18:50] There is an error on the console Cannot find device "br0" ; Error getting hardware address for "br0" [18:51] apparently the error causes it to not bring eth0 back up so I juju can't contact it after that [18:51] Anyone seen this? [19:01] mwenning: sorry, no idea, and searching for bugs doesn't bring up much [19:01] mwenning: maybe try in #maas ? [19:02] marcoceppi: do you have any time today to talk about testing charms? [19:02] mwenning: check for syntax errors in /etc/network/interfaces [19:02] natefinch, thx. I'm looking at #1271144, somewhat similar to what I'm seeing. [19:02] Bug #1271144: br0 not brought up by cloud-init script with MAAS provider

[19:02]

[19:03] mwenning: I had a problem where eth0 would not come up on its own and it turned out to be a incorrect key in that file. [19:03] natefinch, I can actually start the node up OK in maas [19:04] natefinch: I do [19:04] I always have time for charm testing [19:05] mwenning: what version of juju are you using? [19:05] natefinch, 1.20.7 [19:06] mwenning: nice [19:07] marcoceppi: mostly I have no idea what I'm doing testing a charm. Like... do I really have to install the thing? That seems like it's destined to be a problem, especially for a charm like mine that takes 20+ minutes to install, depending on where it's being deployed [19:09] mwenning: at the bottom of that bug, a developer is asking if the primary network interface is called something other than eth0... if so, you need to set the network-bridge attribute in environments.yaml (to whatever the primary interface is) [19:09] natefinch: so there are varying forms of testing. A blanket that will cover all types of charms is integration testing which does actually deploy the charm and there are a few frameworks that exist to interact with a deployed environment to verify it's working correctly (a la Amulet). Then there's just plain old unit testing which works as well [19:12] marcoceppi: I guess the "has some tests" requirement for getting promulgated as a trusty charm is just very vague to me. I'm sure that's at least somewhat on purpose. I can definitely do several unit testy things pretty easily. But the key "does juju deploy actually work?" test is going to take 20+ minutes to run if it's run on amazon. I don't know a way around that. === roadmr is now known as roadmr_afk [19:13] natefinch, primary network meaning the one that maas is on? I have eth0 going out to the internet, eth1 is the internal maas network [19:13] natefinch: well, the minium requirement for testing is unit tests (this is the golang charm?). Having integration tests is great as we can make sure it works constantly. That, and we have an automated testing framework that we're running charms through [19:13] mwenning: if br0 is disconnecting we need to figure out why. Where do you see that message? [19:13] mbruzek, on the node console. [19:13] mwenning: and you do not see that happen on a normal maas start ? [19:14] mbruzek, correct. [19:15] unfortunately it rolled off the console screen now, I can run it again and try to write down the details [19:15] marcoceppi: yeah, this is for the go discourse charm. I can certainly hook up some Go unit tests to the charm tests. Charm tests just need a *.test executable under the tests directory, right? I can put a script in there to install go and run go test. [19:16] mbruzek, looks like some script does an ifdown on eth0, then tries to configure br0, fails, and never brings eth0 back up again [19:16] natefinch: yeah, the pattern for how testing works is mutating actually, now we have more entry points. Like if you have a Makefile with a test or unit_test target it'll get run [19:16] natefinch: but any executable file (not just files with .test) will be executed with the testing harness as well [19:16] marcoceppi: makefiles, cute :) [19:16] mbruzek, I'll start it up again and get more info [19:16] * marcoceppi makes a note to update testing docs [19:16] marcoceppi: so any executable in the tests directory? [19:17] natefinch: yes [19:17] so many people complained about .py extensions that it opened to all executables [19:17] haha [19:17] * marcoceppi rolls eyes [19:17] mwenning: I would be surprised if juju was doing the ifdown. I think you have something wrong there that I just don't have enough information on yet. [19:18] natefinch: so you could, if you want to forego a makefile, put 100-unit.test which was just +x and the bash required to unit test the hooks [19:18] that'd be sufficient for the testing bits. We've gotten a lot of feedback about standing up a charm and environment each time you want to test [19:19] marcoceppi: actually, I had a thought, I think I can precompile a testing executable and check it in [19:19] natefinch: that's be bad ass [19:19] marcoceppi: haha... it even defaults to being called .test [19:20] natefinch: it was meant to be ;) [19:20] mbruzek, it'll be a few minutes to come back up. If I hit the timing just right I think I can enable the console login and get more info [19:20] marcoceppi: sweet, now all I have to do is write the tests. [19:21] natefinch: hah, no sweat! ;) === fuzzy_ is now known as Ponyo [19:56] lazyPower: my mongo tests keep timing out on me http://paste.ubuntu.com/8381939/ [19:56] I may have to go in and increase their timemout value [20:02] good old mongo.... destroyer of timeouts === roadmr_afk is now known as roadmr [20:05] mbruzek, https://pastebin.canonical.com/117305/ [20:05] don [20:06] t know if that enlightens at all.. [20:27] arosales: ack. let me take a look at it when i wrap the BD work i'm in the middle of [20:27] if you're seeing timeouts, then CI will be, and everyone else will be too. [20:27] lazyPower: thanks [20:43] mwenning: This is outside my area of expertise. There is a br0 problem, but I can not tell where. [20:48] mbruzek, ok thx. I'll keep at it. I'm still trying to get in thru the console. [21:08] mwenning: whats in /etc/network/interfaces? [21:08] do you have a bridge device specified in there? or elsewhere that would be recognized by the system? [21:10] lazyPower, it just defines lo, eth0 as dhcp (external internet), and eth1 as static (internal maas network) [21:10] no bridges [21:11] thats why ti cant find the bridge device br0 [21:11] Hmm. Looks like the cassandra charm is broke. [21:11] aisrael: quoreming? [21:11] lazyPower: http://pastebin.ubuntu.com/8382625/ [21:11] mwenning: http://paste.ubuntu.com/8382626/ [21:11] Tracking it down now. Looks like it's using the wrong gpg key [21:12] take a look there, i implicitly define my network bridge and tie it to a physical interface [21:12] aisrael: thats new emergent behavior compared to what i've seen cause failures in the past. must be an updated GPG key [21:12] carry on sir [21:21] lazyPower: testing the fix now, but is there somewhere upstream I can check to verify _why_ the gpg key changed? [21:22] aisrael: Just the cassandra issue tracker, which i think is in jira [21:25] Yup, that fixed it [21:47] lazyPower: since https://code.launchpad.net/~a.rosales/charms/trusty/mysql/add-default-keys/+merge/235064 was merged can you update https://code.launchpad.net/~jorge/charms/trusty/mysql/fix-proof/+merge/234020 to invalid or superceeded so it drops off the queue? [21:47] sure thing, sorry i missed that. [21:48] lazyPower: no worries. I think you got most of the other low hanging bits --thanks :-) [21:48] i did my best. a few of the changes were a bit in depth to review as no tests were in teh charm, however - they were solid merges [21:49] I'll take a look at MongoDB after BD - it may get moved to Monday [21:49] depends on how late the BD merges take me into the night w/ bundles [21:49] actually, lets make a card for that and I'll dive into it monday morning. [21:49] lazyPower: I am still trying to get mongo tests not to time out :-/ [21:49] i bet i know whats going on there, its the sheer volume of the instances. [21:49] lazyPower: there is still this one https://code.launchpad.net/~jorge/charms/trusty/elasticsearch/remove-sets-metadata/+merge/234358 [21:50] its deploying 8 or 9 servers iirc. and that can be trimmed down to a single shard, w/ replicas [21:50] all the functionality would be done there [21:50] but I thought marcoceppi was going to update this one since it was +1ed by the communty and he commented [21:50] but still needs a charmer to take action on it. [21:50] lazyPower failing for me in aws too [21:51] marcoceppi: any objections to merging https://code.launchpad.net/~jorge/charms/trusty/elasticsearch/remove-sets-metadata/+merge/234358 ? [21:51] ack. Let me wrangle it now that we have a clear path forward with how our CI infra handles testing. [21:51] it works with juju test, but not bundletester is what i'm seeing, and its going to take some refactoring. [21:51] arosales: i'm already on it. [21:51] lazyPower: any recomendation on passing larger constraints to bundle tester? [21:51] or increasing timeout? [21:52] arosales: none [21:52] marcoceppi: merging and closing [21:55] marcoceppi: lazyPower: thanks :-) [21:55] arosales: i'm gonig to send another batch update with the work i've done in the BD stack this week re: rev queue update [21:55] as thats been a majority of the work i've done since i've been back from the sprint [21:56] lazyPower: ack and thanks for the reviews [21:56] mwenning: any update on Dell OMSA today? [21:56] now that iv'e waited until EOD time for you, let me poke you about something :P [21:56] sorry about that, i'll try to remember to poke you earlier in the day on Monday if there's no change. [21:57] lazyPower, I've been trying to get this juju cluster up to run it. [21:57] np. [21:57] :| anything I can do to assist you? [21:59] hmm, actually I managed to run it on another smaller cluster here, it came back with an error. [21:59] give me a second, I'll get it in a pastebin [22:02] https://pastebin.canonical.com/117311 [22:04] the deployment timed out [22:04] the hourglass in the response code says amulet killed the setup before it finished [22:05] mwenning: 2 things. 1) change line 16 to 1800, [22:05] oh it has d.sentry.wait() [22:05] so just 1 thing [22:05] if you can do that and re-run, it should pass, it looks like it was nearly finihsed when amulet pulled the plug [22:06] d.sentry.wait() means wait forever? [22:06] negative. [22:06] d.sentry.wait() is an internal command to amulet, it says "halt progression until no further hooks are being fired in teh environment" [22:06] it assures that at least at one single ms during the deployment, no hooks are queued to be fired, and it has "settled" [22:06] what's 2) ;-) [22:06] d.sentry.wait() was going to be 2 [22:07] but thats in there, i jumped the gun [22:09] k, so timeout=1800 [22:10] yep [22:10] running... [22:10] * lazyPower crosses fingers [22:23] lazyPower: it's charm test pulling the plug [22:23] mwenning: ^ [22:23] lazyPower mwenning charm test -e maas --timeout 1800 10-deploy.test [22:24] ahhh [22:24] yeah, I'm going to bump the default for that when I do some work on amulet next [22:24] 600 is way to close [22:24] mwenning: also, -v may help illuminate more what's going on with charm test [22:25] marcoceppi, I changed the d.setup(timeout=1800) in tests/10-deploy.test, will that do the same thing? [22:26] mwenning: nope, this is the difference between teh timeout for a test and for the test runner, slight distinction, in our jenkins infrastructure the charm test timeout is 2 hours, but the CLI defaults to 600 seconds. [22:27] amulet and charm-test are decoupled from each other so there's a bunch of different timeouts running around and no one is talking to each other [22:27] rats. ok. killing and starting again [22:35] lazyPower, when I try a variant of your /etc/network/interfaces file, it comes up with the route default pointing to the maas server [22:37] so nothing gets routed out to the internet [22:37] Am I doing something else wrong? [22:37] mwenning: well all of the networking config there is subject to modification for your specific use. In this case 10.0.10.1 is a router on my network, and 10.0.10.2 is my MAAS region/cluster controller. [22:38] mwenning: http://paste.ubuntu.com/8383171/ here's my route table on that server [22:39] not sure how much help thats going to be for you, but this is what i have setup [22:41] after changing a config variable X and do something if for some other reason config-changed hook runs will i still get updated value of X? [22:50] lazyPower, ok, ours is set up a bit differently - eth0 is connected to the outside world, eth1 is connected to all the maas nodes. [22:50] maas server ip-forwards everything [22:51] mwenning: in my specific setup, the br0 attached to eth1 is whats making my vmaas cluster visible to the network [22:51] that interface handles the anding to reach my units. [22:51] (is anding the proper term here? i think i just failed in networking lingo) [22:51] i digress, its handling the masqerade and forwarding [23:02] lazyPower, this is going to take some time, hope you're not hanging around for me. [23:02] mwenning: nah, i'm around for other reasons :) poking you and helping where i can is a perk [23:02] ok preciate it. [23:07] my "small" cluster has 2 nodes, unfortunately it needs three for the test. The "big" one is having all these problems, I'm trying to rebuild the maas server [23:14] ahh [23:14] mwenning: well if you've got other stuff to do this can wait. If its not an easy fire and forget thing [23:15] i can lend a hand next week as well, i've got a few windows i can block out to help [23:16] lazyPower, I'm going to try to get it running a little while longer - I may leave it running over the weekend. [23:17] ack. i'll be around about another hour before i dip out for the weekend [23:18] sounds about right. [23:51] marcoceppi: hey, I'm still having this 'only charmers can initiate reviews' prob on the revq [23:51] jose: it's a known issue [23:51] an update is going live soon [23:52] oh, ok [23:52] sorry about that, then [23:52] testing button is also broken ;) [23:52] but that's being fixed too [23:52] \o/ [23:52] thanks for all your work!