=== scuttle|afk is now known as scuttlemonkey === CyberJacob is now known as CyberJacob|Away === menn0 is now known as menn0-afk === menn0-afk is now known as menn0 [03:51] * arosales finishing up review time [04:15] Hi there I just build a juju deployment using the quick start and manual provisioning. I'm using 12.04 and have the precise juju-gui installed, but when I do a juju status it says pending. The machine is at 100% idle and it's been like 5 minutes. Is there anyway to figure out what is holding it up? === uru-bot is now known as urulama === CyberJacob|Away is now known as CyberJacob === mfa298___ is now known as mfa298 === CyberJacob is now known as CyberJacob|Away === kaydo___ is now known as kaydo [09:43] Interesting... my agent died while in debug-hooks [09:43] lxc [09:43] stub: seems surprising, anything interesting in the log file? [09:45] jam2: yeah, I seem to have a big arsed go panic in there [09:47] jam2: here we go. http://pastebin.ubuntu.com/8231693/ === allenap_ is now known as allenap === dosaboy_ is now known as dosaboy === scuttle|afk is now known as scuttlemonkey === wwitzel3_ is now known as wwitzel3 [13:30] Which project contains the text of this page? Doesn't look like it's juju-docs. https://juju.ubuntu.com/ [13:31] how does one test an upgrade-charm hook? [13:33] nevermind, `juju upgrade-charm -h` look helpful [13:36] hey marcoceppi, hazmat, jcastro, mbruzek did you see we had a community member working with linode contribue a quick start stack script for creating a juju jump-host on linode? https://www.linode.com/stackscripts/view/10193 [13:36] lazyPower, i did [13:37] that is awesome [13:37] I'll send him a shirt [13:37] lazyPower, ideally it would be wrapped up into a plugin like the digitalocean provider using the api.. its pretty manual to use something like that [13:37] basically its restricted to a one node env without some work [13:38] hazmat: well, I was working with fuzzy to achieve their goal of having a jump station for their trusted dev-staff to control deployments. [13:38] not sure if it really needs the host name set, or if could bootstrap localhost and be auto for the one node case [13:38] oh you're talking to them already? [13:38] they didn't like the idea of porting ~/.juju - so they threw it up as a stack script, and thats effectively their manual jump host. [13:39] jcastro: yeah - i've known fuzzy a little over a year. Fuz is working with our Meteor.js charm [13:39] oh ok [13:39] # Stephanie Sunshine [13:39] it started as "how can i gate deployments a-la capistrano style?" - to which I showed them Juju-strano [13:39] Thats the one. [13:39] what about her? should I send her a shirt or are there multiple ones? [13:39] Stephanie Sunshine = Fuz [13:40] ack [13:40] I'll send along a link to the DO provider as well [13:41] hazmat: I pinged the list with that stack script, any feedback for them on that thread would be awesome. I'll point fuz at it when she shows up later today. [13:41] I was talking about a phaux provider like your DO plugin - but for PoC work that was overkill. I can see that being on the roadmap as a community contribution though - baby steps :) [13:42] yeah [13:44] jcastro: any idea where that page lives, project wise (see previous question)? [13:45] the website, it's a wordpress setup [13:45] there should be a l ink on where to report bugs at the bottom [13:45] ... or not [13:45] https://launchpad.net/juju-website [13:46] ack, thanks [13:50] jcastro: I assume content changes just need to have a bug filed against it? [13:51] yeah [13:51] if you want irc ping luca [13:51] he's just taken over the site and is doing a massive clean up/reorg [13:54] kk [14:23] marcoceppi, jcastro, anyone else: do I have to do open_port 80 in my install hook if I declare my app to be http, or will juju expose do that for me? [14:23] natefinch: all port openings need to be explicit [14:23] marcoceppi: ok, that makes sense [14:23] port 80 isn't the only port an http server could run on [14:23] * marcoceppi wanders off pondering tomcat === urulama is now known as urulama_afk [14:41] natefinch, the other half of that bug, which is annoying [14:41] is the whole directory structure for local charms [14:41] so like, juju expects: [14:42] [14:42] -> [14:42] and if you do `juju deploy --repository=foo local:blah` [14:42] if foo doesn't have a series/charm structure, it just bails [14:43] jcastro: you should read my latest email about writing a charm, I mentioned that specifically [14:43] yeah [14:43] jcastro: my suggestion is to make juju deploy --local= work if points to a charm directory [14:43] yeah! [14:43] natefinch, is there a specific bug for that or is it just on your radar somewhere? [14:43] jcastro: on my radar, but we should make a bug [14:44] jcastro: my radar is notoriously unreliable ;) [14:44] ok I'll copy and paste your text and toss it in there [14:44] jcastro: awesome, thanks [14:46] https://bugs.launchpad.net/juju-core/+bug/1365542 [14:46] Bug #1365542: Doesn't deploy a charm unless the repository directory has a specific directory structure

[14:49] jcastro: great === fgallina is now known as fgallina-lunch === jog_ is now known as jog === katco` is now known as katco === fgallina-lunch is now known as fgallina [15:38] Hey arosales_ where do you think the Code Review section in the Charms Review Doc should be? Prior to the charmers team part so it doesn't break apart the absolutely essential parts of the review? [15:40] Also, I was thinking about moving up the community review ending part to prior to the charmers team, that way the process of the charmers team can take up more room if necessary and not push down the community content. [15:41] JoshStrobl: hmm, it would live in the workflow your defined, perhaps before deploy/test. [15:41] JoshStrobl: or we could leave that specifically for the ~charmer section [15:41] your thoughts? [15:42] hmm [15:42] I guess it comes back to if we think everyone will want/be able to do a code review. [15:42] exactly [15:43] I don't want to make it seem like it is only meant for the charmers team. [15:43] ya +1 to that [15:43] but it is your call [15:43] I think this should be _the_ review process [15:43] we could put it out to the list for input too [15:44] ideally, the review process is transparent and anyone wanting to can do a full reivew. [15:44] but [15:44] perhaps folks just want a workflow that is straight forward and does not include code review [15:45] marcoceppi, do you know if the "expanded sections" header thing (the Juju specific Markdown) works? [15:45] arosales_, if the expanded sections part works, we could have it prior to the deployment section. [15:46] arosales_, it could be unexpanded by default, marked optional, those that want or are required to dive into the code review can expand the section [15:47] marcoceppi, what I am referring to -> https://github.com/juju/docs/wiki/Markdown#foldouts [15:48] JoshStrobl: yes, those all work [15:48] JoshStrobl: you can see it in action on this page: [15:48] https://juju.ubuntu.com/docs/reference-release-notes.html [15:48] ah sweet, thanks [15:49] arosales_, would that work? [15:49] JoshStrobl: if you need additional HTML elements that don't exist yet, Im happy to make more markdown plugins [15:50] Hey, all. [15:50] I will have short question about deploying to openstack. [15:50] allomov: feel free to ask your question [15:50] I get following error trying to bootstrap openstack environment: https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/b7192994bbab0f0c70d8e1a19f7dcb09cab3cb70/fail-juju.log [15:51] here is a piece from my environment.yml file https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/799c20a50083e82bf832cadb3e72ad7d2159c5a4/juju-env.yml [15:51] allomov: you need to create cloud image metadata for your openstack provider [15:51] allomov: https://juju.ubuntu.com/docs/howto-privatecloud.html [15:52] JoshStrobl: I am thinking if we just put out code review section in the ~charmer section but welcome anyone to also do that as part of their reivew . .. [15:52] marcoceppi: cool, thank you for the source [15:52] JoshStrobl: but also try to keep this readable so folks don't think this is just for ~charmers [15:52] allomov: the first half of that doc is pretty heavy with details that might confuse at first. Make sure you read through once :) [15:53] marcoceppi: that's the strange thing, because I didn't need to use my region name before. fog gem for instance doesn't need it [15:53] allomov: Juju does a bit more and things slightly differently than fog gem [15:55] JoshStrobl: my 2 cents, fwiw, lets put the code review section in the "general/community" review process. Cavet the code review is optional pending review comfort level. [15:55] inlucde some common things to look for that we can grow out so folks can grow their skill there if they want [15:55] * arosales_ thinking out loud [15:55] JoshStrobl: as you mentioned this could also be folded in too [15:55] arosales_, sounds good to me. [15:56] arosales_, I'll make note of the existing code review contents you pointed out in the comments and it can be expanded up later if others come up with more stuff, sound good? === fabrice is now known as fabrice|dinner [16:01] JoshStrobl: sounds good [16:02] Fantastic. I'll get started on it now then! [16:02] * arosales_ really liking this doc. [16:03] I will also be creating a complimentary charm author guidliens doc specifically to call out design consideration and common gotchas in reviews that we can take care of before review. [16:03] JoshStrobl: be good to get your input there if you have time given your a charm author [16:04] arosales_, sounds good. do you want us to figure it out after your guys' sprint? [16:08] JoshStrobl: ya I have this slated to creat at the sprint next week. [16:08] \o/ === hatch__ is now known as hatch [16:12] JoshStrobl: to conrim I read that correctly, re "figure it out after your guy's sprint" was that in regards to your charm review doc, or my charm author guidlines doc. [16:12] arosales_, your charm author guidelines doc [16:13] arosales_, we understand each other correctly? [16:16] JoshStrobl: we do :-) [16:16] great :) [16:44] arosales_, sorry to nag you again, was thinking about another thing to watch out for in the code review, you approve of the following? "Not using set -ex in bash scripts, which allows the bash script to more easily catch failed execution, thereby allowing Juju to more accurately detect a failed hook." [16:47] JoshStrobl: not nagging at all [16:52] JoshStrobl: yes, that should def be in there [16:52] JoshStrobl: well, only -e is needed [16:52] -x is xtrace [16:52] marcoceppi, ah [16:53] I'll remove the x part then :P [16:53] -eux should be in best practices though, (-u being that if a varaible is accessed before set it's an error) [16:54] marcoceppi, so you think I should have it as -eux or something like "Not using set -e or set -eux[...]" [16:54] -e is the minimum for a review, -eux should be in the best practice section of the docs imo [16:54] * marcoceppi may make a merge for that === uru_ is now known as urulama_afk [16:59] JoshStrobl: +1 to marcoceppi comments on just making sure -e is there [17:00] +1 on recommending -eux though per marcoceppi's suggestions [17:02] marcoceppi, request for the script that converts the GFM / Juju Markdown into HTML (you know, the make stuff), have a sha1sum of each file. Do an on-the-fly comparison between the sha1sum of the files in src/en/ and the existing sha1sums. If the file changed, THEN convert it. Otherwise don't bother. I think it'd speed up the converting time when using "make" since it'd only convert files that have changed. [17:03] (does this with some of his custom "compilers") [17:03] JoshStrobl: sure, that's a great idea. Can you open an issue on GH [17:03] I'm collecting a list of things I can do "offline" the next time I'm flying [17:03] yep, is the converter in juju/docs? [17:04] JoshStrobl: yup [17:04] cool, I'll file an issue there then [17:04] you're talking about a hashsum of the compiled file, right? [17:04] rather [17:04] no, a sha1sum of the src/en markdown files [17:04] if compiled file exists, and hashsum of the source hasn't changed, then skip [17:05] otherwise, you'd never get an initial copy of the compiled file [17:05] if src/en/*.md sha1sum !== existing sha1sum of the file (stored in a .sha1sum file), compile, else skip [17:06] right, if the sha1sum simply doesn't, go ahead and compile it anyways, since the file probably doesnt exist in htmldocs [17:06] JoshStrobl: yeah, i get teh concept. def open an issue, it's a great idea esp as the docs increase size [17:06] I was going to implement a file watcher [17:06] so as src/* files changed it would just recompile them [17:07] that'd be great too, but I'd prefer to not have to compile every single markdown file into HTML whenever I make a change I want to test :P [17:07] but yea, I'll file an issue in a bit [17:08] it would only compile the markdown file that changed, not all the files [17:08] but yeah [17:10] You can sorta get an idea of how I do it by looking at the recursiveCompiling function at https://github.com/StroblIndustries/Metis/blob/master/build/compiler/metisCompiler and the fileChanged function at https://github.com/StroblIndustries/Metis/blob/master/build/compiler/compilerFunctions [17:11] it is bash, I'm going to assume yours is in python, but the logic is essentially the same [17:13] anyone got that error on a bootstrap? [17:13] ERROR juju.cmd supercommand.go:323 cannot initiate replica set: cannot get replica set configuration: cannot get replset config: not authorized for query on local.system.replset [17:13] arosales_, doc is now updated: https://github.com/JoshStrobl/docs/commit/bf62c234572b94ff61cec6709db3190654639433?diff=split [17:14] avoine: what version of juju are you using? `juju version`? [17:14] 1.20.6-trusty-amd64 and juju-mongodb 2.4.9-0ubuntu3 [17:15] from http://ppa.launchpad.net/juju/stable/ubuntu [17:16] and with an lxc local bootstrap [17:17] * arosales_ loving the split in github [17:17] JoshStrobl: thanks taking a look [17:21] marcoceppi, issue filed - https://github.com/juju/docs/issues/157 [17:49] kirkland: using "run-one-constantly" in the new review queue, love these little helper scripts [17:49] marcoceppi: woot :-) [17:50] marcoceppi: btw, I just found, per dpb2, the timeout command, which is nice in conjunction with run-one* [17:50] nice [17:50] :) === CyberJacob|Away is now known as CyberJacob === roadmr is now known as roadmr_afk === CyberJacob is now known as CyberJacob|Away [18:55] marcoceppi: got a question for you === arosales_ is now known as arosales [18:55] any any yaml experts out there [18:55] I am looking at the cassandra charm [18:55] arosales: what's the problem? [18:56] and it is currently failing proff as it is missing defatult value for some of the keys [18:56] I am looking for a recomendaton on what to put for a default [18:56] is it simply, "default:" [18:56] arosales: just put the default key, but leave it blank [18:56] or [18:56] yes, that one [18:56] default: "" [18:56] marcoceppi: ack on just the default key, but blank, ie "default:" [18:57] marcoceppi: thanks. [18:57] to keep current behavior, you should use the former, if blank string is needed (intead of unset) then the latter [18:57] marcoceppi: ack. [18:57] it's the difference between "" and NULL which most charms wont' care about, but some do [18:57] I'll check that doesn't cause any issues on the charm deploy [18:57] ya I was wondering if some charms check for any value to be set [18:58] and take action on that even if it is blank [18:58] or specifically look for a Null, and then key off that [18:58] that was my main concern === roadmr_afk is now known as roadmr [20:27] hatch: no. The mismatch in versions between deployed and what you have installed locally wouldn't cause that. (moving convo here) [20:28] ahh ok, just noticed it, thought I'd point it out [20:28] :) [20:28] I'm really hoping you can reproduce this [20:28] heh [20:28] hatch: i found the issue though [20:28] your source option is coming back as undefined. and it should be defaulting to true. [20:29] so is this a GUI bug? [20:29] i'm pointing a finger at the devel branch of the gui, I'm testing with -stable now and pending a deployment. [20:29] it appears so [20:30] interesting.... [20:30] wow if it is, it's good we caught it now and not next week lol [20:32] lazyPower: I'll also try on stable [20:54] tvansteenburgh: http://paste.ubuntu.com/8253401/ [20:54] i ran into a promulgate bug - any idea what i've snagged? [20:55] wait, i found it. when i cloned it it was missing the push branch it was sniffing for. I overrode the lp resource to use the ~charmers route and it worked. === CyberJacob|Away is now known as CyberJacob [21:00] So...I have a theory that in a certain situation the containerName passed to OpenstackStorage.Remove() can be blank (perhaps if a destroy-environment is called after a failed destroy due to an API timeout, not sure), which will result in a DELETE being sent to the swift account URL (and in v1.7.x of swift marks the account on swift as deleted, which is a total PITA to then fix as it involves either a) waiting for a cron'd script to really delete the DB, or [21:00] b) manually removing the sqlite3 DB file for the user on the swift replicas - both of which then results in the account being recreated based on the keystone perns for the user on next access. Now I have an easy fix for that (check for the error condition specifically in func Remove(...)), but not a clue how to replicate the issue, other than the fact that this is the only explanation I have for how my swift account got screwed after a failed destroy-enviro [21:00] nment followed by a successful one. [21:00] Any thoughts? [21:01] probably better off asked in #juju-dev, but more after ideas or reactions like "that sounds ridiculs, naaah" [21:02] *ridiculous [21:17] lazyPower: so I was able to deploy it just fine in an old version of the GUI [21:17] you the same? [21:18] source isn't even set when running the juju-run command [21:18] er, it's not in the list [21:24] If I give an http:// url to image-metadata-url, it still downloads with 'https://' is that expected? [21:30] and by downloads, I mean, downloads the images [21:33] dpb2:are you referring to simple streams? [21:33] hatch: correct, it worked fine using a -stable revision of the gui. [21:34] er, whatever is provided by default. [21:34] hatch: i'd re-target the bug against the GUI and point to this LP resource for all the aggregated details. [21:34] lazyPower: maybe, I'm referring to the images for lxc creation that get downloaded form cloud-images.ubuntu.com [21:34] dpb2: ah, yeah it defaults to secure comms to avoid MITM attacks. [21:35] lazyPower: but I changed it to http? [21:35] no good? [21:35] natefinch: are there any schenanigans with fetching of the cloud image url structure? [21:36] dpb2: so, offtopic - i've noticed you've incremented by 1, level up? [21:36] lazyPower: perhaps... you never know with me [21:36] lazyPower: definitely [21:36] thanks so much for the help [21:36] lazyPower: I think freenode didn't like my identity. :) [21:37] hatch: np :) I smelled some schenanigans once I saw the deploy configuration in the bug. [21:37] dpb2: Freenode, like camelot - is a silly place. === dpb2 is now known as dpb1 [21:39] lazyPower: I've also got help on getting apache2 going for ghost and which options I need so very close to finally piecing together a bundle :) [21:40] hatch: awesome! I look forward to seeing your bundle submission [21:41] lazyPower: I'm back! [21:41] dpb1: decrement === pjdc_ is now known as pjdc [22:27] arosales, Github will not let me merge your change as-is. [22:27] mbruzek, what is the issue? [22:27] mbruzek:ok let me get this conflict resolved [22:28] https://github.com/juju/docs/pull/154 is in question [22:28] I have no problem with the *change* I need you to run the commands to get your branch current (is my guess). [22:28] JoshStrobl, I see the following message: We can’t automatically merge this pull request. [22:28] to resolve conflicts before continuing. [22:29] arosales, maybe your master branch of your fork isn't updated? [22:29] * JoshStrobl checks [22:29] yea it is 186 commits behind juju master [22:30] Hi there, I got a new Juju installation going, but on the command and control node, my logs are being spammed pretty bad. Could someone tell me what is going on and possibly how to fix it? https://clbin.com/XZ63i [22:30] ya it appears so [22:30] hi fuzzy I have not seen that before. [22:30] * arosales working to update [22:31] fuzzy, what version of Juju are you using? [22:34] mbruzek: I think if I push to master it will hit master [22:34] mbruzek: to confirm your review was a +1? [22:34] arosales, Confirmed. It looks great [22:35] mbruzek: ok thanks [22:35] Sorry my wifi card likes to forget it exists [22:35] fuzzy, have not seen that error before what version of Juju are you using? [22:35] the latest one for 12.04 as of last night [22:36] I followed the quickstart for manual provisioning [22:37] is there an easy way to get juju to spit out version info? [22:38] fuzzy, juju version [22:38] 1.20.7-precise-amd64 [22:39] hrmm... That *is* the latest. [22:39] What command are you running that it gives you this log output? [22:39] cat /var/log/syslog [22:39] well tail -n 100 /var/log/syslog [22:40] * JoshStrobl is going reset his fork of juju/docs. git sometimes doesn't like to fast-forward so I magically end up with extra commits that are then ahead of juju/docs. [22:40] fuzzy, I have several messages like that in my syslog [22:41] fuzzy, so I guess that is normal. [22:41] fuzzy, You can go to #juju-dev and ask the developers about those logs, but I see them all over my syslog too. [22:42] wow that's noisy.. [22:44] fuzzy, I am about to end my day I have to get to dinner. === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob [22:59] fuzzy: that looks like the migrations weren't run against the collection setting roles [22:59] and yes, thats very noisy. [23:00] ty :) [23:00] about 10mb in 24 hours of logs === CyberJacob is now known as CyberJacob|Away