#juju-gui 2013-01-21
<bac> jujugui: i see a test failure in trunk.  if no one is working on it i'll fix it as it affects an area of the code i'm working on.
<frankban> bac: should disable the "Destroy" menu for the Juju GUI service? I see that failing too. thanks for taking care of it.
<bac> frankban: yes.  just a problem with the test set up.  fix coming.  a review would be nice.
<frankban> bac: sure
<bac> frankban: https://codereview.appspot.com/7174043
<bac> bcsaller1: you around?
<bcsaller1> bac: yeah, whats up?
<bac> bcsaller1: can you review https://codereview.appspot.com/7174043 -- our test suite currently has a failure.  easy peasy.
<bcsaller1> bac: I think I have that fix in my branch as well, hit the same thing, +1 though
<bac> bcsaller1: oh, ok.  i like to do testfix branches in isolation for faster turn-around.
<bcsaller1> I'd call that a trivial even :)
<bac> yep
<frankban> bac: done, thank you.
<bac> thanks
<bac> alejandraobregon, bcsaller1, frankban:  meeting today?  last one to join has to lead.
 * bac votes to cancel
<gary_poster> frankban, bac, bcsaller1 especially today, thank you for work.  Please make sure that bcsaller1's branch is reviewed so it can be landed asap
<gary_poster> also then please make the email I sent about getting the charm ready to go
<bcsaller1> gary_poster: I am cleaning up a lint issue I didn't catch but will submit it in a minute
<gary_poster> awesome thanks bcsaller1 
<gary_poster> GUI is getting a lot of good press here
<bcsaller1> gary_poster: I'm going to attempt one last fix for the drag/delta interaction issue again after that
<gary_poster> cool thanks bcsaller1 
<gary_poster> bac frankban are you all making progress on the charm stuff?  thank you for your review frankban 
<frankban> gary_poster: welcome. When are we supposed to make a release? I'd like to make it after the annotations branch is landed. 
<gary_poster> frankban, bac, makes sense.  If everything is done by frankban's lunch tomorrow that will be ok.  If everything is done by bac's EOD that would be even better.  presentation is tomorrow roughly 1800 UTC.  our presentation preparation will be tonight roughly 2230 UTC
<bac> gary_poster: ok, will try to get it done today
<gary_poster> ty
<frankban> bac: ping me if you need help. gary_poster: do you want us to land your charm-proof branch?
<gary_poster> yes please frankban.  thank you
<bac> gary_poster, frankban: reviewing it now
<gary_poster> ty
<bac> frankban: reviewed so ready to land
<frankban> bac: cool thanks
<frankban> gary_poster, bac: charm-proof landed.
<bac> good
<gary_poster> great, thank you
<frankban> bac, gary_poster: I'll make stable and trunk releases before my EOD. bac: he other steps are: 1) request review, 2) communicate the charm can be announced. (a double check that everything works after the release (e.g charm deploy) is strongly appreciated)
<bac> frankban: i'm working on the release now
<frankban> bac: ah ok
<bac> frankban: just updated CHANGES.yaml and proceeding
<frankban> bac: great, so ping me if you need help or another eye on qa
<bac> frankban: ok
<bac> frankban: when do you eod?
<frankban> 30min
<bac> k
<gary_poster> thanks to both of you.
<gary_poster> If bcsaller1 gets the fix for bug 1099921 today, it would be great to have that landed asap and I will do as much to help.  even better to have a release with that, but that's icing
<_mup_> Bug #1099921: Dragging services fails intermittently <juju-gui:Triaged> < https://launchpad.net/bugs/1099921 >
<gary_poster> as much as I can I mean.  maybe some availability this afternoon
<bac> frankban: i had a setback (computer crashed) and making the release is taking a little longer than expected.
<frankban> bac: uploading it I guess...
<bac> yes
<bac> gary_poster: does uploading the new release take forever?
<gary_poster> bac, pretty sure no.  been awhile since I did one.
<bac> gary_poster: it eventually got pushed
<gary_poster> cool bac thanks for letting me know
<bac> jujugui: release 0.1.5 is on launchpad.  i'm deploying a charm now for testing.
<bac> if anyone else wants to QA it, that's be swell before i announce to jorge
<hazmat> did the read-only config option make it to the charm
<hazmat> cool, it did
<therve> hazmat, http://paste.ubuntu.com/1556410/
<gary_poster> hey bac.  therve reports some issues with the charm, from an hour or so ago.  (he also says that juju trunk does not work)
<bac> gary_poster: i'm still trying to get the charm up on ec2
<therve> yeah that's the paste I just put bac
<gary_poster> bac, what's the problem you are encountering, do you know?
<bac> gary_poster: no, still pending
<bac> no indications of error, just taking forever, like it does
<therve> bac, http://paste.ubuntu.com/1556414/ is another error I got with the default value for juju-gui-source
<gary_poster> bac, it only takes five or ten minutes IME these days.  We eliminated most of the slowdowns
<bac> gary_poster: to confirm, i tried deploying with
<bac> juju deploy cs:~juju-gui/precise/juju-gui
<bac> anything off about that?
<gary_poster> bac, did you take a look at log on machine?  I'll see if I can figure out what therve's message means, though there's a meeting I'm in
<gary_poster> no, bac (and if the README were broken that would be another issue, of course0
<gary_poster> )
<bac> bcsaller1: hey can you try to spin up a charm on ec2 in parallel to me trying?
<bac> gary_poster: his first paste indicates the charm install hook is attempting to install from a branch not download the release from LP
<bac> the release i made (0.1.5) is there
<gary_poster> bac, yes, he did his first paste after the second paste didn't work
<therve> bac, yeah that's after setting juju-gui-source to lp:juju-gui
<bac> therve: ok, i understand
<gary_poster> bac, I have a suspicion that therve was trying to use default source (release) while it was being uploaded.  The upload script had created a release on LP before the file upload was complete.  We maybe need to make that code more robust to say "if the file does not exist then we will try the older version"
<gary_poster> I'm 80% sure of that diagnosis :-)
<therve> :)
<gary_poster> After that, we have two more issues:
<bac> gary_poster, therve: there was an abnormally long time between the release being created and the upload finishing, so that is a good theory
<therve> I'm trying again with a release build
<gary_poster> (1) when you (bac) start a juju charm, it never actually completes
<gary_poster> (2) The first pastebin shows that the lp:juju-gui thing doesn't work, which should, even though it is supposed to be used rarely.
<gary_poster> We have tests for that but they now use a special branch
<gary_poster> to test the charm
<gary_poster> rather than the integration with the charm and the gui
<gary_poster> we should have a separate branch for this
 * gary_poster wants some CI
<therve> juju-gui-source: 0.1.5 seems to work fine \o/
<bac> gary_poster: i destroyed the service and re-deployed it.  the agent state remains in pending
<gary_poster> weird
<bac> there is nothing i can do as i cannot ssh into it
<bac> therve: yay
<gary_poster> lemme try to dupe
<gary_poster> https://launchpad.net/juju-gui/stable/0.1.5 shows no downloads, which is weird
<gary_poster> I don't know if that updates with latency
<therve> gary_poster, it does for me
<bac> gary_poster: i have created cards for the branch version of juju-gui-source failing for the problem with failure when the tarball is not yet uploaded.
<gary_poster> therve, oh, sorry, I wasn't clear.  I meant the download counter
<therve> oh
<gary_poster> thank you bac
<bac> gary_poster: i see a tgz on launchpad at that url
<gary_poster> bac, I meant the download counter
<bac> oh, the download counter is not real time
<gary_poster> cool
<bac> it is updated daily
<gary_poster> oh ok
<gary_poster> that's some latency :-)
<hazmat> i've got stats on the charm i can query
<bac> gary_poster: it parses apache log files daily to get the download count...
<gary_poster> cool bac.  I downloaded it manually
<gary_poster> eh, which means nothing new in context.
<hazmat> 32 charm downloads from the store
<gary_poster> cool hazmat.  I think we have no new bugs, only newly discovered bugs.
<gary_poster> but we will verify when one of us gets a charm started from scratch...
<gary_poster> bac, fwiw, my machines are taking a long time to start
<gary_poster> not the charm but the machines themselves
<gary_poster> ok I have a machine...
<gary_poster> so far so good.
<gary_poster> bac, therve, works for me.  My belief in my previous diagnosis is up to 95%, and high enough for me to leave it alone.
<bac> gary_poster: so i'm vexed as to why i can't get a charm deployed on ec2
<therve> well you don't seem to be able to get a machine?
<gary_poster> bac pastebin the output of your status?
<therve> maybe try a different region
<bac> since i'm deploying from the charm store, there should be minimal traffic...so my crappy bandwidth isn't an issue
<bac> gary_poster: https://pastebin.canonical.com/82615/
<gary_poster> bac, what happens when you try `juju ssh 1`
<bac> 2013-01-21 16:42:48,630 INFO Waiting for machine to come up.
<gary_poster> bac, yeah
<gary_poster> that's not our fault
<gary_poster> that's EC2 or something
<bac> i'm going to destroy the environment and see it anything different happens
<gary_poster> I bet the environment will be gone then.  That will be different. :-)
<bac> gary_poster: so, how do you want to proceed with the charm announcement?
<gary_poster> bac, no go, for a different reason: the environment is pretty broken AFAICT. :-/
<bac> gary_poster: how so?
<bac> is it broken on uistage?
<bac> ugh, pending relation lines are badly broken on safari
<gary_poster> bac, I see 2.5 issues.
<gary_poster> 1) Click on service.  This shows menu.  Click on "view."  Nothing happens.
<bac> 2) When there are ambiguous relations clicking to select one or the other does nothing.
<gary_poster> 2) precisely bac
<bac> 2.5) profit?
<bac> 3) selecting a target service when adding a relation brings up the menu
<gary_poster> 2.5) when you try to make a relation from mysql to mediawiki, using the menu, when you click on mediawiki the menu shows up
<bac> 4) impossible to dismiss menu by clicking away
<gary_poster> yes, bac, that was my 2.5 :-)
<gary_poster> oh, good, yes.  I didn't recognize that was a bug, but was annoyed by it
<bac> ugh
<bac> so i'll go make cards for these
<gary_poster> bac, I feel like these need to be fixed before we announce, unfortunately :-(
<bac> gary_poster: yes.
<bac> but my release making will be faster next time
<bac> even if ec2 hates me
<gary_poster> bac, please make bugs for them also, and maybe even send an email out to the juju-gui list about the status, mentioning that I emphasize their priority.
<gary_poster> We need to make our qa story explicit, while we are improving our test story.
<bac> gary_poster: rt
<gary_poster> alejandraobregon or jovan2, if you are around, do you know where we can get an svg of the juju logo?
<jovan2> gary_poster: greg should have one, I'll ask him
<gary_poster> thank you jovan2 
<bac> gary_poster: i created the six new bugs and put them in the main story.  the WIP limit of 2 is going to be problematic to moving these cards through.
<gary_poster> bac, reversing priority
<gary_poster> I mean, WIP limits
<alejandraobregon> gary_poster: hi gary, not available in guidelines site, just seeing if can get you one somewhere else
<gary_poster> thank you alejandraobregon 
<bac> gary_poster: ok
<bac> gary_poster: i think you may be the only one with supercow powers to do that
<gary_poster> bac, you and I have the same "Manager" role.  I'd expect it is associated with that role, but maybe not
<bac> gary_poster: we've seen this before
<gary_poster> bac, but I updated it to 4
<bac> or perhaps i'm doing it wrong
<bac> thanks
<alejandraobregon> gary_poster: got it. emailing now
<gary_poster> you rock alejandraobregon, thank you!
<bcsaller1> bac, gary_poster: has the menu interaction been fixed? I think I see the issue, surprised the tests didn't catch this actually
<gary_poster> bcsaller1, no, not fixed unless bac did it (and I don't think he's had time)
<bac> bcsaller1: you talking about 'view' not working?
<bcsaller1> view and not being able to dismiss I think
<bac> bcsaller1: no, they aren't fixed afaik
<bcsaller1> bac: ok, on it
<bac> gary_poster: my second attempt on ec2 worked fine
<gary_poster> bac, more or less good. :-) I don't see how that error could have been our fault
<bac> bcsaller1: you can see it broken on uistage
<bac> gary_poster: i agree
<bac> fwiw, lp2kanban is being relaunched and should update those new cards soon
<bac> bcsaller1: i'm going to step away for a bit but will be back shortly
<bcsaller1> bac: I'll try to propose before you're back
<bac> bcsaller1: are you working on one of the new cards?
<bcsaller1> bac: I am working on the viewClick (which works now) and on the serviceMenu toggle
<bac> bcsaller1: would you grab the cards on the board so frankban and teknico don't get confused in the morning?
<bcsaller1> bac: will do :)
<bac> cool.  see you tomorrow.
#juju-gui 2013-01-22
<bac> morning frankban, teknico.
<frankban> hi bac 
 * bac starts reviewing
<teknico> bac, good morning
<bac> teknico: better today?
<teknico> bac, yes, much better, thanks :-)
<bac> frankban: first one done.  land away
<frankban> thanks!
<bac> frankban: 'file not found' reviewed.  teknico can you do a second review?
<bac> teknico: nm, i see you're on it
<teknico> bac, I am :-)
<frankban> bac, teknico: thanks
<frankban> bac: I think the comment you suggested makes sense
<bac> frankban: good
<bac> hi teknico, do you have a moment to chat about bug 1102640?
<_mup_> Bug #1102640: Selecting a target service when adding a relation brings up the menu <juju-gui:Triaged> < https://launchpad.net/bugs/1102640 >
<bac> hi bcsaller
<bcsaller> hey :)
 * teknico is back from lunch
<teknico> bac, sure
<bac> sorry bcsaller, i didn't see you respond.  i was going to ask if your branch fixed bug 1102640 but i see it didn't
<_mup_> Bug #1102640: Selecting a target service when adding a relation brings up the menu <juju-gui:Triaged> < https://launchpad.net/bugs/1102640 >
<bac> teknico: ok, regular hangout?
<teknico> bac, yep
<bcsaller> bac: That may be covered by the fix, I didn't see that one to specifically include it in testing ,checking now
<bcsaller> bac: appears to be fixed as well
<bac> bcsaller: not really
<bac> on call.  want to join?
<bcsaller> bac: yeah
<frankban> bac, bcsaller: one test fails in trunk, adding the trivial fix in my current branch, landing soon.
<bac> frankban: thanks
<bcsaller> frankban: thanks
<gary_poster> you guys rock, thank you
<bac> bcsaller: i think i fully understand what is going on now...but not how to fix it.  can we chat before or after the standup?
<bcsaller> bac: sure
<bac> alejandraobregon, goodspud, teknico, benji: call now
<alejandraobregon> bac: hi, we're at the sprint in a meeting, sorry we can't join..
<bac> alejandraobregon: right, forgot
<alejandraobregon> bac: no worries
<bac> bcsaller: can you give me a quick idea on where to make the framework changes?
<bcsaller> bac: it looks like we *could* but don't need to. app/assets/javascripts/d3-components.js:202 We do assign the global d3.event object
<bcsaller> and can use that to cancel the event
<bcsaller> so the proper fix should be available now
<bac> bcsaller: oh, nice
<bac> bcsaller: using d3.event to preventDefault did not prevent serviceClick from being called.  a crude work-around that does work is http://paste.ubuntu.com/1560040/
<bcsaller> bac: I think you want stopPropagation, not preventDefault
<bac> bcsaller: ok i'll try that
<bac> bcsaller: neither stopPropagation nor stopEvent prevent serviceClick from being called
<bcsaller> bac: hmm, that seems wrong because it should. I'll poke around a bit but don't let that interfere with what you're doing.
<bac> bcsaller: did you note i was using d3.event.sourceEvent?  the actuall d3.event doesn't have those methods.
<bac> bcsaller: i'm going to grab some lunch
<bcsaller> The event facade should have them as well, but I'll look into it more, thanks
<therve> is the gui supposed to work in firefox?
<therve> I can't make it work for some reason here
<therve> but it works in chromium
<gary_poster> therve, not really, no.  We occasionally make sure it works in FF but we won't say it is supported until we have something like daily CI tests for the browser.  That's almost certainly happening in the next two months.  Meanwhile, we use chromium because it is wildly faster, particularly for the things we are doing.
<gary_poster> Medium priority: FF seems to be broken.
<hazmat> gary_poster, bummer
<gary_poster> y
<bac> bcsaller, benji: can you have a look at my review?
<benji> bac: sure
<bac> thanks
<bcsaller> bac: doing it now
<bac> great
<bac> bcsaller: i attempted to come up with a test but so far have not been able to craft one
<bac> bcsaller: the existing test doesn't simulate click events but calls the underlying methods directly.
<bac> bcsaller: so, i'll make a card and perhaps collaborate with someone tomorrow to figure out how to get something working
<bcsaller> bac: a card is fine. 
<benji> away
<gary_poster> goodspud, try http://10.19.1.40:8888/
#juju-gui 2013-01-23
<bac> hi frankban, i see you're working on bug 1103204.  are you able to duplicate it?
<_mup_> Bug #1103204: Removing a relation sometimes fails <juju-gui:Triaged> < https://launchpad.net/bugs/1103204 >
<frankban> bac, yes
<bac> good
<frankban> bac: could you please take a look at https://codereview.appspot.com/7199043 ?
<bac> frankban: ok.
<bac> frankban: it is odd you had to go to such lengths to reproduce the bug.  it frequently happened right away for me after reloading the page.
<frankban> bac: in uistage or locally?
<bac> locally
<bac> frankban: approved
<frankban> bac: thanks. 
<bac> with that i'm going back to bed.  perhaps i'll feel better after lunch.
<frankban> benji: are you around?
<benji> frankban: I am.  What's up?
<frankban> benji: do you have time for a review? https://codereview.appspot.com/7199043
<benji> sure, I'll look now
<frankban> benji: cool, thanks
<benji> my pleasure
<benji> frankban: I got distracted for a minute, but the review is done now.
<frankban> benji: thanks, re the test, agreed. what do you think about creating another card for it? it would be easier to add missing test after your current card is landed.
<benji> frankban: makes sense; in fact, I may do that card too (unless you really want it)
<frankban> benji: cool, creating a card, please feel free to tackle it if that means just a reasonably small addition to your branch
<frankban> benji: added card for bug #1103477
<_mup_> Bug #1103477: Add test for relation removal <juju-gui:Triaged> < https://launchpad.net/bugs/1103477 >
<benji> thanks
<gary_poster> bacm bcsaller frankban teknico, as I said in my email, please let me know if you are interested in working on the Go Juju changes.  It will help our planning discussion.  Some indication of degree of interest would be somewhat helpful a well.  Let's say a scale of 1 to 10, where 5 represents ambivalence, 1 represents an abhorrence verging on the irrational, and 10 represents ecstasy and bliss at the idea. :-)
<gary_poster> bac, that is
<gary_poster> benji, thanks for your email.  a degree of interest indicator would be nice but not necessary
<teknico> gary_poster, oh, I thought it wasn't needed, at least on my part
<benji> gary_poster: for Go?
<teknico> gary_poster, let's turn it to eleven! ;-)
<gary_poster> teknico, ok :-)
<gary_poster> benji, yes
<benji> gary_poster: 8.5
<gary_poster> benji, cool thanks
<Makyo> Meeting today?
<Makyo> benji, frankban teknico - meeting?
<benji> Makyo: sounds like fun
<frankban> Makyo: yep
<teknico> Makyo, yep
<Makyo> + bac 
<benji> gary_poster might even join us
<benji> Makyo: bac isn't feeling well
<Makyo> benji, Ah, thanks.
<benji> bcsaller: something that might make the run-the-tests-and-scrape-the-result script easier: http://pypi.python.org/pypi/xvfbwrapper
<benji> bcsaller: in particular the "Example: Headless Selenium WebDriver Tests" section
<bcsaller> benji: thats how its done in the charm test I think
<benji> it might be, I suggested it but am not sure what they settled on
<gary_poster> sorry, meeting benji :-)
<therve> hola!
<therve> http://paste.ubuntu.com/1563427/ is my problem of the day :)
<gary_poster> :-/
<frankban> therve: could you please paste the full charm.log?
<teknico> therve, your world is broken :-)
<therve> frankban, where's that?
<therve> teknico, I know! there is most certainly something wrong with me
<teknico> therve, most likely not :-)
<frankban> inside the juju gui instance, it should be in /var/lib/juju/units/juju-gui-0/charm.log, or something similar...
<frankban> therve: ^^^
<therve> I don't have such a thing
<therve> I have 'juju-gui-0.1.5' instead of 'build-prod' in the /var/lib/juju/units/juju-gui-0/charm/juju-gui/ directory
<teknico> therve, uhm, now our world is broken too :-P
<frankban> therve: is the provider lxc?
<therve> frankban, indeed
<teknico> it's nice that someone is able to actually deploy on lxc :-)
<therve> teknico, it's been rather challenging :)
<gary_poster> therve, related topic.  I'm in the process of describing the details of what Landscape is providing the GUI in annotations so that I can work with the UX folks to figure out the user stories and presentation.  Could you comment on/correct this?  http://pastebin.ubuntu.com/1563586/
<frankban> therve: do you have the file /var/log/juju/unit-juju-gui-0.log or similar (inside the container)?
<therve> frankban, new instance: http://paste.ubuntu.com/1563593/
<therve> gary_poster, so
<therve> gary_poster, right now, it's unit, not machine
<therve> gary_poster, I think there are a couple of others annotations, at a technical level
<therve> gary_poster, ie, a global link to resolve security and reboot alerts
<therve> and probably a root_url to landscape
<gary_poster> therve, so if we get a security alert on a unit, we will go to a Landscape link that is not specific for a given unit
<gary_poster> ?
<gary_poster> to resolve it
<gary_poster> and same for reboot
<therve> gary_poster, yeah unfortunately we don't have one per unit
<therve> gary_poster, although, considering all the machines are the same, at least the whole service ought to get the alert
<gary_poster> ok cool therve.  And you also have a Landscape link to the machines that represent the current environment, right?
<therve> gary_poster, correct
<gary_poster> cool
<gary_poster> therve, "all the machines are the same": really?  Juju allows you deploy machines with a given set of constraints, and then add machines later to the same service after having changed constraints
<gary_poster> and even over time I wonder if new machines might be different than old
<therve> gary_poster, all the machines in a service
<therve> iiuc
<gary_poster> therve, since you can add units over time, that can change things yeah?  But anyway, IIUC it is irrelevant: you are already giving us per unit annotations about reboot/security, and then our Landscape reboot/security control is for...the entire environment or every single machine that your Landscape is managing?
<gary_poster> irrelevant to us right now I mean :-)
<therve> gary_poster, we can decide maybe
<gary_poster> because what you have would handle either scenario, homogenous or heterogeneous
<gary_poster> ok, therve, np, it doesn't change the story much on our side
<frankban> therve: just deployed juju gui on lxc, worked fine, what's the juju origin in your environment.yaml?
<therve> frankban, ppa
<frankban> therve: in the charm directory, juju-gui should be a link. where does it point to?
<therve> frankban, /var/lib/juju/units/juju-gui-1/charm/release/juju-gui-0.1.5
<gary_poster> Hey Makyo! Welcome back!  How was the trip?
<Makyo> gary_poster, Excellent!  Good to be home, though.
<therve> gary_poster, sent an email about annotations
<frankban> therve: output of "ll /var/lib/juju/units/juju-gui-1/charm/release/juju-gui-0.1.5/ ?
<therve> frankban, sorry the instance is gone :/
<frankban> therve: np
<benji> new review up: https://codereview.appspot.com/7195047/
<therve> frankban, it seems to be that the setup_gui logic in the charm is wrong
<therve> ie the first_path_in_dir call doesn't do what it ough to
<therve> (although I'm not sure how this could end up being build-prod I guess)
<frankban> therve: in setup_gui we link the uncompressed release dir to juju-gui
<therve> correct
<frankban> at this point, juju-gui should contain build-prod, which is the root of the production GUI.
<frankban> therve: then, in start_gui, that directory is build_dir, and we overwrite the configuration file: config_js_path = os.path.join(build_dir, 'juju-ui', 'assets', 'config.js')
<therve> frankban, oh right, there is one more level though
<therve> frankban, it's looking for /var/lib/juju/units/juju-gui-0/charm/juju-gui/build_prod/ whereas the path is /var/lib/juju/units/juju-gui-0/charm/juju-gui/$version/build_prod/ 
<frankban> therve: you mean, $version is juju-gui-0.1.5?
<therve> frankban, yeah
<frankban> therve: the directory structure, starting from the charm root, should be:
<therve> frankban, the ln in setup_gui create a link inside JUJU_GUI_DIR, it doesn't replace it
<therve> the -f in ln doesn't remove the drectory
<frankban> therve: but at the time setup_gui call ln -s, JUJU_GUI_DIR should not exist
<therve> frankban, ah that may be the issue. It does exists
<frankban> so, the problem is, it exists, and should not
 * therve nods
<therve> oh, hum
<therve> frankban, I have a file in my local charm :/
<therve> let me try again
<frankban> therve: how did you deploy the charm when you first encountered this problem?
<frankban> ah, ok
<frankban> gary_poster: https://codereview.appspot.com/7205044 (from me and Nicola) should address all the comments in the charm review
<gary_poster> awesome frankban, looking
<frankban> thanks
<gary_poster> teknico, frankban nice work, thank you.  Land as is
<therve> frankban, ok it works after cleaning up my local charm. Sorry for the noise.
<teknico> gary_poster, thanks :-)
<gary_poster> :-)
<frankban> therve: no problem :-)
<gary_poster> therve, yeah, glad it's ok :-)
<gary_poster> thank you frankban for walking through with him. :-)
<frankban> gary_poster: cool, EOD for us, after the second review, if everything's ok, please feel free to land the branch (or have someone do that), and re-propose. I've tried tests and qa, they pass, but a double check would be great
<gary_poster> cool frankban and teknico have a great evening and thanks again
<benji> allgui: ok, I have some crazyness that I'm having trouble debugging, anyone available to pair?
<gary_poster> benji, that's guihelp I think yeah?
<benji> gary_poster: could be, I couldn't remember and couldn't find it written down anywhere
<gary_poster> :-)
<benji> guihelp: ok, I have some crazyness that I'm having trouble debugging, anyone available to pair?
<gary_poster> benji, it's in the kanban card from the discussion.  I try to keep notes there before blogs
<benji> it is also in my notes now
<gary_poster> cool
<therve> hazmat, https://code.launchpad.net/~therve/juju/env-annotations-gc/+merge/144583 for your reviewing pleasure
<benji> Makyo: thanks for the review of my branch, would you mind reviewing another one for me?  I want to move them as far along as possible so I'm not gumming up the works. https://codereview.appspot.com/7133069
<Makyo> benji, on it.
<benji> thanks!
<Makyo> benji, This is stacked on your other branch, right?
<benji> Makyo: right... oh!  I bet you are asking that because the diff is screwed up.
<Makyo> It's just big, yeah.  Where should I be looking, specifically?
<benji> let me see if I can fix it
 * benji turns the big handle on the side of an oily, smokey machine labled "lbox"
<benji> Makyo: I give up.  Here is the real diff: http://paste.ubuntu.com/1564396/ and here is the new (but still bloated) review: https://codereview.appspot.com/7206047
<benji> (why a new review?  because I killed the old one in hopes that the -req switch for lbox would actually work)
<Makyo> benji, Thanks, will take a look
<benji> I appreciate it.
<alejandraobregon> hazmat: pdr 2?
<alejandraobregon> robbiew: pdr 2
<robbiew> alejandraobregon: ack
#juju-gui 2013-01-24
<bcsaller> frankban: can you test that phantomjs branch again after install phantomjs? :) npm install -g phantomjs Want to get another verification that it works
<frankban> bcsaller: sure
<frankban> bcsaller: i wonder why phantomjs is not a dependency of mocha-phantomjs
<bcsaller> frankban: I would think so as well, but their might be an issue with phantom also wanting a global install 
<frankban> bcsaller: 326 tests complete (6 seconds) 1 test pending, very cool!
<bcsaller> sweet :)
<bcsaller> hey wait! your computer is faster than mine!
<bcsaller> no fair
<frankban> :-)
<gary_poster> hey bcsaller looks like you merged the phantomjs without the review changes
<bcsaller> gary_poster: they should be in there
<bcsaller> docs, removed console comments, what did I miss? (and sorry)
<gary_poster> bcsaller, ah weird.  No, it's cool.  Your branch (https://code.launchpad.net/~bcsaller/juju-gui/phantom-testing) does not have your changes (verified locally and in LP) but trunk does.  I guess that is some lbox magic or something. <shrug> But yes it's in trunk, thanks and sorry for false alarm
<bcsaller> gary_poster: yeah, I didn't repropose/push, just did the submit after the changes
<gary_poster> interesting that lbox works that way.  Thanks for the branch bcsaller, really awesome to have that.
<bcsaller> gary_poster: really happy to have this branch in :)
<gary_poster> definitely :-)
<teknico> bac, bcsaller, benji, frankban, Makyo, daily call in 2 minutes
<Makyo> Downside to the phantomjs thing: leaving make test-server running while you try to submit causes everything to blow up.
<bcsaller> we could change the port?
<Makyo> Not a big deal, just forgot I had the server running :)
<benji> Makyo: no, over here!  what are you doing over there?
<Makyo> Bouncing between windows, apparently :)  I'll review after a restart, because apparently a package update requires that.
<benji> actually, a restart sounds good; maybe it will make my camera work again; back in a minute
<benji___> Why does Ubuntu hate me?  Almost every time I reboot I have to rebind my workspace navigation keys.
<bcsaller> benji___: I get that too with things like toggle max state on windows, drives me crazy
<teknico> bcsaller, it happened to me too, so I stopped redbinding them and learnt to love the default bindings :-)
<bcsaller> teknico: I never saw you as a conformist
<teknico> bcsaller, it came as a total shock to me too, it must be the age :-)
<bcsaller> ha
<benji> bcsaller: yep, I use a custom maximize toggle too, wierd thing is that one will get reset and not the other
<frankban> charm accepted! \o/
<teknico> frankban, yes, it was announced on #juju about half an hour ago :-)
<frankban> :-) cool
<benji> <sigh> Attempting to install phantomjs generates an error, therefore I can't land my branch.
<benji> does this make sense to anyone?
<benji> http://paste.ubuntu.com/1566725/
<benji> guihelp: ^^
<hazmat> benji, looks like a download error, for the binary from google code, i'd retry
<benji> hazmat: I figured the same thing.  I retried, no luck.
<hazmat> benji, your on 32 bit?
<benji> yep
<benji> hmm, it looks like the file it is trying to download 404s (http://phantomjs.googlecode.com/files/phantomjs-1.8.0-linux-i686.tar.bz2)
<hazmat> that might be the delta, its possible the link is bad
<benji> 1.7.0 exists; I will try requesting that version
<hazmat> benji, 1.8.1 is also present http://code.google.com/p/phantomjs/downloads/list
<benji> mm
<Makyo> Is https://bugs.launchpad.net/juju-gui/+bug/1087110 no longer a thing?
<_mup_> Bug #1087110: makefile and tests are not run automatically before landing <juju-gui:Triaged> < https://launchpad.net/bugs/1087110 >
<benji> hmm, I wonder why it is trying 1.8.0
<Makyo> benji, there was an update to npm today, for me.  Maybe try that?
<Makyo> s/try/check
<benji> Makyo: nope (I have updated recently)
<benji> hmm, different error from "sudo npm install -g phantomjs@1.8.1"
<benji> guihelp: I haven't been able to get npm to install phantomjs; I have two cards gumming up the lane, therefore I am going to subvert lbox and just land the branches in question.  You have five (5) minutes to object.
<benji> Time's Up!
<bcsaller> benji: can you manually install http://phantomjs.googlecode.com/files/phantomjs-1.8.1-linux-i686.tar.bz2
<bcsaller> opps
<bcsaller> too slow 
<benji> bcsaller: :)
<benji> bcsaller: I tried (in that I tried pointing npm at that URL as well as wget-ting the file and pointing npm at the file on disk; all failed)
<bcsaller> you're sure it was 1.8.1?
<benji> I also tried "npm install -i phantomjs@1.81"
<bcsaller> and not 1.8.0? that was the link I saw before
<benji> yep, I tried several versions
<bcsaller> but have you tried it w/o npm?
<benji> what does "w/o npm" mean?
<bcsaller> you can download the package directly and see about putting it in the right place
<bcsaller> or at least check if the binary will run from the archive for you
<benji> that's worth trying, I'll see about that
<bcsaller> for me it looks like a stand alone binary, you might have to check its library deps with `ldd` and make sure you're not missing anything as you're skipping normal packaging 
<benji> bcsaller: how about just using apt to install it?
<bcsaller> haven't tried, my guess is its too old but you can try that as well 
<benji> untarring it into a temp directory gives me a working (apparently) phantomjs; now, I wonder where I would put it 
<bcsaller> somewhere in your pat
<bcsaller> path
<bcsaller> it just spawns that with some args
<benji> that confuses me, isn't there some sort of npm packagy, javascripty thing supposed to be going on...
<benji> bcsaller: I was supposed to run this command, right? "sudo npm install -g phantomjs"
<bcsaller> npm is being subverted to serve a binary in this case (and not well)
<benji> hmm
<bcsaller> phantom is basically headless webkit
<bcsaller> or I thought it was, might be something else under the hood
<benji> it is (basically headless webkit)
<benji> ok, I have phantomjs installed; "sudo npm install -g mocha-phantomjs" appeared to work
<benji> running lbox now
<benji> eating avocado... mmm
<benji> yay! the tests failed!
<benji> bcsaller: yay, it lives!  Double yay: it cought a test failure that I would have introduced to trunk!
<bcsaller> benji: excellent, sorry about the install trouble
<benji> bcsaller: I will add a note to HACKING that if you have trouble installing phantomjs you can do it manually and outline that; many thanks for the help!
<benji> oh man, I love running the tests in a terminal so much
<bcsaller> yeah, me too
<gary_poster> bcsaller Makyo benji bac, hi.  Neither the menu's "view" choice work nor the double-click work to go from the environment to a service.  I'll file a bug in 30 minutes or so if no-one else has, but if someone is available to file that would be great.  If someone is available to fix, that would be great.
<Makyo> gary_poster, on it, will start with the bug.
<benji> gary_poster: I can file it
<benji> or Makyo can
<gary_poster> Thank you Makyo.  Thanks benji :-)
<gary_poster> Makyo, looks like click on a unit no longer works on http://uistage.jujucharms.com:8080/service/wordpress/ either
<bcsaller> gary_poster: a fix for that was applied a day or so ago, maybe someone merged it out
<gary_poster> ok thanks bcsaller, maybe check with Makyo if there is a quick fix
<bcsaller> gary_poster: it was a trivial, found it, I'll just merge the fix, its putting old code back :-/
<Makyo> bcsaller, where was it?
<bcsaller> Makyo: app.js/handler for *:navigateTo 
<Makyo> bcsaller, ah, alright
<bcsaller> I think all I saw was the console.log and removed the handler, read the second line as arguments 
<bcsaller> *shameface*
<Makyo> On looking at https://launchpad.net/juju-gui should we update the charm store url?
<Makyo> It's still pointing to the ~juju-gui charm.
<gary_poster> bcsaller, ok thank you.  Makyo yes please I think you can
<Makyo> gary_poster, Done and done.
<gary_poster> thank you Makyo!
<benji> protip: if you want to run a subset of the tests in a terminal you can just start the test server (and close the annoying test window it opens) and then run a command like this: mocha-phantomjs "http://localhost:8084/test/index.html?grep=viewport module"
<benji> Since mocha-phantomjs supports reading the test file from the filesystem it would be a nice enhancement to get "mocha-phantomjs test/test_index.html" (or similar) to work
<benji> ...then we wouldn't need a test server to run the tests in a terminal
<bcsaller> benji: or just add .only to the describe or it for the test
<bcsaller> we can change the test-server script to pass through options, grep is a cli option as well, you don't need to modify the url directly
<benji> bcsaller: I didn't see grep in the help for mocha-phantomjs and --grep didn't work (although it didn't complain about it either, which is odd)
<benji> the .only trick is a good one; everyone should know that one, maybe you should mention it in the weekly meeting
<bcsaller> benji: hmm, only mocha takes --grep directly, sorry about that 
 * Makyo dogwalks.
 * Makyo dedogwalks.
#juju-gui 2013-01-25
 * benji suspects gary_poster just got back from dinner.
<gary_poster> benji, heh, about half hour ago, yes :-)
<gary_poster> well, 21 minutes
<benji> I hope it was good.  Probably not as good as beef tongue in Copenhagen, but what is?
<gary_poster> benji, heh, thanks. It was Texas chili from a very local-seeming place.  Very hot.  Good.
<benji> sounds good
<benji> guihelp: has anyone seen this before?  I am trying to do a view.set('container', container);
<benji> in a test but it is ignored
<benji> I have tried tracing through the morass that is YUI's idea of how to treat object attributes but I don't yet understand why
<benji> it is not a "writeOnce" attribute, I have eliminated that
<hazmat> benji, js debugger, or try setting other attributes, most likely i'd guess something else is setting it after your set
<benji> hazmat: nope, immediately after the call a subsequent .get returns undefined
<frankban> benji: what is container? a string? YUI uses Y.one as setter
<benji> frankban: an object
 * benji meditates upon "YUI uses Y.one as setter"
<frankban> benji: what is returned, in your code, if you do "Y.one(container)" ?
<benji> let me see...
<benji> frankban: both before and after the .set Y.one('container') returns null
<frankban> hum, benji, in node_modules/yui/view/view.js, Y.View defines this attr: http://pastebin.ubuntu.com/1569972/
<frankban> so, the setter is Y.one, and it's writeOnce too
<benji> frankban: ah, that is a nice clue; Y.one seems to be a very odd setter to me
<benji> I suspect that means that no one can ever set it (without using the "force" option or digging around in the guts of YUI)
<benji> that's a bit irritating for testing
<teknico> benji, I seem to have the exact same problem you had yesterday when installiing phantomjs globally
<frankban> benji: maybe Y.one is a no-op if you pass an Y.Node instance, I am not sure, but if so, it could eliminate some irritation
<benji> teknico: I hope the note I added to HACKING helped/will help
<teknico> benji, mocha-phantomjs did install, but I still have the Error 127 when running "make test-debug" or "make test-prod"
<teknico> looking
<frankban> teknico: have you installed phantomjs itself?
<teknico> frankban, I run "sudo npm -g install phantomjs"
<teknico> which tries to get the 1.8.0 version, which apparently is not there
<teknico> benji, I'll try doing that, and also add to HACKING a link to the archive to be downloaded :-)
<benji> teknico: good idea
<benji> ooh, the YUI "setter" really isn't a setter; it is a pre-processor called before the value is stored
<benji> therefore Y.one makes sense, that way "container" can be set with either a DOM node or a CSS selector, either of which will be turned into a YUI Node before storing
<benji> "getters" are similarly not really getters, they are a way to post-process a stored value (or override it, I assume) before returning the value to the caller
<teknico> look at that! tests running in terminal, what a beautiful sight ;-)
<benji> indeed
<benji> well, I figured it out, but it's not pretty: view._state.data.container.getter = function() {return 99;}
<teknico> what a not-so-beautiful sight :-)
<teknico> bcsaller1, benji, frankban, Makyo, daily/weekly call in one minute
<teknico> frankban, starting without you
<Makyo> guihelp: All console logging appears to be off in 'devel' mode.  Was this an intended change?
<bcsaller1> Makyo: no, it should still log, though many of the messages were removed 
<goodspud> Thanks for the tidy up off the controls in the bottom bar.
<Makyo> bcsaller1, ah, alright.
<Makyo> Will try again.
<benji> new branch up for review: https://codereview.appspot.com/7196056
<Makyo> benji, Thanks.  Will review in a few.
<Makyo> Assuming no gary_poster calls this week, what with the sprint.
<benji> that is my assumption too
<hazmat> benji, did you ever get your phantom issues sorted?
<benji> hazmat: yep; I ended up manually extracting the archive and putting the phantomjs executable on my path
#juju-gui 2013-01-26
<hazmat> therve, i was wondering where your twisted websocket client lib is at.. didn't see it in the branch
<hazmat> or where you just using autobahn
#juju-gui 2014-01-20
<frankban> hey benji: welcome back! if you are really here, and if you have time, could you please review a quick branch required to fix the quickstart release? https://codereview.appspot.com/54560043
<benji> frankban: sure, I'll look at it right now
<frankban> benji: thanks
<frankban> benji: Gary just did it now
<benji> heh, ok
<frankban> benji: could you please review this very simple branch? https://github.com/juju/juju-gui/pull/78 (I am just trying git)
<benji> frankban: sure
<frankban> thanks
<benji> frankban: +1'd
<frankban> benji: thanks, what am I supposed to do now? add a :shipit: comment?
<benji> frankban: yep
<frankban> benji: so, the procedure is: 1) make a pull request, 2) wait for jenkins 3) ask for a review and 4) :shipit:, correct?
<bac> frankban: that is my understanding
<benji> frankban: yep, with the exception of "wait"; I've never bothered to wait nor heard that that is what we want 
<frankban> benji: ack, cool
<frankban> benji: and my understanding is that when you review a branch ":+1:" is the new LGTM
<benji> frankban: yep
<frankban> ok, sorry we did not choose :smile_cat:
<rick_h_> benji: frankban the wait is in the instructions in the HACKING doc. The idea to wait is so that you don't end up taking up the 20min time for a landing attempt only to hit a known test failure, lint failure, etc. Especially since both the pull request check and the landing will test saucelabs with IE and the like
<benji> rick_h_: is the wait before review or parallel with it?
<frankban> rick_h_: but you don't have to wait before asking for reviews, right?
<rick_h_> for small changes/doc changes/ meh
<rick_h_> benji: parallel
<rick_h_> benji: frankban oh yea not at all a wait for review
<rick_h_> just a wait until hitting :shipit:
<frankban> rick_h_: ack
<benji> sounds good
<bac> frankban, benji: we having a call today?
 * benji needs a reboot... aparently.
<bac> frankban: meeting if you have anything to say.  T+2
<bac> were we a space shuttle we'd be nearing first stage separation
<bac> or SRB detachment
<bac> or something
<frankban> bac: we can skip it for today, I sent an email for everything I did earlier
<frankban> bac: re: quickstart 1.0
<bac> frankban: ok
<bac> well benji is joining...if he gets sound working
<frankban> bac: ok joining
<bac> frankban: no, no pressure!  :)
<bac> congrats on quickstart 1.0 though!
<bac> ah, i love it when an upgrade fails with an unhelpful error and leaves the computer in an unknown state
<benji> jujugui: does anyone know if the order of relations in a deployer file are meant to be taken as ordered?  Bug 1263120 boils down to the charmworld proof mechanism enforcing (requires, provides) ordering so specifying a relation as (provides, requires) is flagged as incompatible.
<_mup_> Bug #1263120: self related services in a bundle fail proof <charmworld:Triaged> <https://launchpad.net/bugs/1263120>
<hazmat> benji, yes they are ordered
<benji> hazmat: great!  thanks
<hazmat> benji, there's an older syntax that's also supported that does relations as dict entries with weight ordering.
<hazmat> fwiw
<benji> ok (this was specifically for the '- ["foo:bar", "baz:bar"]' style)
<benji> I have a charmworld branch up for review: https://codereview.appspot.com/54560044
<jcsackett> benji, bac (and other charmworld folks): i am seeing on staging that queueing is not completing because a query is too large to complete a sort without an index. https://pastebin.canonical.com/103258/
 * benji looks at paste.
<bac> jcsackett: looking too
<jcsackett> i believe an index on branch_spec can solve this. any objections to my building one on staging? it will likely affect staging performance for a bit.
<jcsackett> abentley: if you're around, can you take a look at traceback and weigh in as well? as i recall you did quite a bit with mongo stuff on charmworld ^
<abentley> jcsackett: sure.
<jcsackett> the other solution i can think of is restructuring db_charms so that it doesn't sort in the query, but creates a list and sorts that...it may be a *lot* to keep in memory in the python process though.
<benji> +1 on trying it on staging
<abentley> jcsackett: Not something I've seen before.
<jcsackett> abentley: dig, thanks.
<jcsackett> hm. actually, i just realized that traceback is in a different part of the application...however it reliably occurs on queueing, so that's a reasonable test case.
<abentley> jcsackett: Why do you think branch_spec is the key?  I would have thought the charm.revision, since that's what it's sorting by.
<abentley> sorry, store_data.revision.
<abentley> and, I guess, owner, series, name.
<jcsackett> abentley: i grabbed a different traceback from the log to paste than the one i was initially looking at (i had closed the terminal, then realized an example might make more sense for people). the traceback i saw, on queueing, is sorting on branch_spec
<jcsackett> it is *very* possible, looking at this one as well, that we need more than one index for charms.
<abentley> jcsackett: Ah.
<abentley> jcsackett: Yes, but also find_charms(all_revisions=False) was only meant to be a band-aid.  Things that want the unversioned charm should hit elasticsearch.
<jcsackett> abentley: yes. that is the thing triggering the bad here. let me see if i can grab the queue traceback.
<jcsackett> abentley: actual issue i was investigating https://pastebin.canonical.com/103261/
<jcsackett> same exception, very different traceback.
<abentley> jcsackett: Gotcha.
<jcsackett> so what we've learned is we're having myriad sorting issues. :-P
<abentley> jcsackett: Not sure whether it's strictly necessary for the lp version to be sorted by branch_spec.
<abentley> jcsackett: I think it's two reflections of the same issue: the charms collection has gotten big enough that it needs indices now.
<jcsackett> yeah.
<abentley> jcsackett: Pretty sure that the sorting by branch_spec isn't relevant to usage, since all_charms shoves it into a dict anyway.
 * jcsackett nods
<jcsackett> yeah, so we can probably skip branch_spec and just not sort that query.
<huwshimi> Morning
#juju-gui 2014-01-21
<bac> hi frankban, you on trusty yet?
<frankban> bac: no, but I have a vm running trusty
<bac> frankban: yeah, me too.  have you seen any problems with juju reporting errors about bootstrap tools?
<bac> on trusty
<bac> frankban: like http://paste.ubuntu.com/6791381/
<frankban> bac: yes, I described this (and a workaround) in my email announcing quickstart
<frankban> (sent to gui-peeps)
<benji> All these issues are making me reconsider my desire to upgrade to trusty.
<bac> frankban: doh.  sorry to bother you
<frankban> bac: np
<bac> frankban: so juju on trusty cannot use lxc or ec2.  that's mighty limiting.
<frankban> bac: IIRC you run juju on ec2 using --upload-tools
<bac> oh
<bac> frankban: well, my handbuilt version also seems to work
<bac> will try the latter
<frankban> bac: cool
<bac> benji: yeah, i'd wait for sure before upgrading metal.  i kept my saucy vm, so if i have to mothball trusty for a while its not big deal
<bac> s/not/no/
<bac> frankban: fyi, the latest code for juju-deployer has not problem handling my bundles that have constraints like mem=1G.  i notice on pypi there is a 0.3.0 but our charm is using 0.2.9.  will test our charm now using the new version.
<bac> s/not/no/
<frankban> bac: sounds good, the last branch merged in the deployer is "merge jjo subordinate and constraint diff fixes and unicode yaml repr issue". so it seems that fixed the problem
<bac> righto
<bac> jcsackett: http://staging.jujucharms.com/heartbeat shows no charm-queue and basket-queue.  is that due to your indexing investigation?
<frankban> jujugui you might find this useful (vcs branch name in the prompt): http://pastebin.ubuntu.com/6790927/
<bac> cool
<hatch> morning
<hatch> gary_poster|away I'll take a look at huw's branch
<rick_h_> hatch: I was going to write up the debugging technique for thatone
<rick_h_> hatch: where you comment out the test files, then the tests, to help narrow down what is conflicting
<hatch> oh ok I thought he just wanted it done
<rick_h_> hatch: yea, but he's had some tests failures he's punted like that before. I figure teach a man to fish and all that
<rick_h_> but understand
<hatch> well there is an event cleanup issue
<hatch> rick_h_ do did you want to get the branch landed or would you like me to? 
<rick_h_> hatch: you go ahead
<hatch> ok cool
<rick_h_> you've been much father into it :)
<hatch> man my internet is really slow today for whatever reason
<rick_h_> pipes are cold
<hatch> it's actualy been unnaturally warm 
<hatch> -10C right now, but will warm up quite a bit by mid day
<hatch> rick_h_ so to work on huw's branch is it best that I clone his fork then work directly on his branch so that I can rebase it? Or do you have another technique?
<rick_h_> hatch: I'd just create a branch in my workspace, pull his changes into it straight from his fork, and then work on it and submit it
<rick_h_> hatch: git pull git@github.com:fitztrev/Bookie.git anon-bmark-get  
<hatch> yeah? That won't cause any odd ordering issues with the revase?
<hatch> rebase
<hatch> and the merges etc
<rick_h_> hatch: for example is how I pulled a pull request over and then worked on it to finish it/submit it
<rick_h_> and then I had to go to his pull request and manually close it
<rick_h_> hatch: worth a try. if it messes up just remove your branch and try something else
<hatch> ok I can give that a go
<hatch> sure beats cloning the entire repo on my slow connection this am
<rick_h_> :)
<rick_h_> some days devel and debug are too close together
<hatch> haha yup
 * gary_poster had call and forgot to join, sorry
<gary_poster> thanks hatch
<rick_h_> frankban: didn't you fix this? I thought I remember qa'ing it. https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252295
<_mup_> Bug #1252295: guiserver bundle deployment error is empty <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1252295>
 * rick_h_ goes to load up an env and test it out
<frankban> rick_h_: yes, that can be considered fixed, but right now we have no feedback on what went wrong, just an "unknown error" or similar. we need some changes to land on the deployer to really fix that bug
<gary_poster> hey rick_h_.  Should GUI release wait on your 1257878-2 branch?
<rick_h_> gary_poster: landing it now, yea I was trying to sneak it in
<benji> I'm consistently getting this error from an lbox submit:
<benji> bzr: ERROR: Cannot lock LockDir(chroot-65979408:///%2Bbranch/charmworld/.bzr/branch/lock): Transport operation not possible: readonly transport 
<hatch> wow huw was not kidding when he said he got errors haha
<gary_poster> rick_h_: awesome, thx
<hatch> yeah....this might take a while
<gary_poster> hatch: :-/ ok
<gary_poster> benji, might impoy that you are working in a place where you have not authenticated yourself with lp?  if you run bzr lp-login in that context does it know who you are?  https://bugs.launchpad.net/qbzr/+bug/1094810
<_mup_> Bug #1094810: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~over-garcia/openacademy/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()   <QBzr:Invalid> <https://launchpad.net/bugs/1094810>
<benji> gary_poster: this is my normal place, but I'll try lp-login anyway
<gary_poster> ack
<benji> gary_poster: no dice, it already knows who I am (also, pushing and other bzr operations work)
<gary_poster> benji: ack.  skimmed through other options and didn't see anything obvious.  Sorry.  Maybe make new co and merge across or something? :-/
<gary_poster> benji: https://lists.ubuntu.com/archives/juju-dev/2013-March/000612.html looks awfully similar fwiw
 * benji reads
<rick_h_> gary_poster: if you get a sec wanted to check if I should start the release process after that 404 fix lands? 
<gary_poster> so IOW benji, check if your team membership has changed or if you generally have the privs you expect
<gary_poster> rick_h_: +1 thank you!
<gary_poster> frankban: hi.  Do you think you need anything to make the quickstart release official?  Did you get any testing feedback from external folks, like Jorge?
 * jcastro votes for "do it!"
<gary_poster> :-) cool
<frankban> gary_poster: not yet. oh wait...
<jcastro> I'll debut it tomorrow at the PTS sprint during my charm school
<gary_poster> awesome!
<frankban> gary_poster: I think after that we only need to copy quickstart+urwid packages to the juju stable ppa
<benji> it irritates me that lbox keeps asking me to edit the commit message; I've resorted to "EDITOR=true lbox submit" and am now happy.
<frankban> jcastro: great thank you!
<gary_poster> benji lol in a 10% sad way :-)
<rick_h_> jcastro: woo! Look forward to hearing how that goes
<rick_h_> benji: we can move it to github and ditch lbox ;)
<gary_poster> frankban: "after that": after what?  We need just a bit more QA?
<rick_h_> "I hear you've got a hammer problem, here's a saw"
<gary_poster> heh
<frankban> gary_poster: I meant after jcastro debugging session. I did some QA and it seems to work well, so, if you prefer to just ship it, I am ok with it
<gary_poster> frankban: ack.  jcastro, you had a debugging session with the new release, at least to verify that your plans tomorrow work nicely?  If not, do you have any time for it?
<rick_h_> frankban: +1 on shipping. We had some qa when lazypower and jcastro tested out the 1.0rc1 and I spent some time trying to break it. 
<gary_poster> cool
<lazypower> I can spend more time auditing quickstart if requried
<lazypower> poke me when required and I'll put it in my priority queue
<jcastro> gary_poster, I am getting on a plane today and out of the loop for 2 days but maybe lazypower can dive in?
<gary_poster> ack jcastro, thx.  I think I'm OK with shipit, frankban
<frankban> gary_poster: +1
<gary_poster> yay :-)
<frankban> gary_poster: seeing if I can copy the packages
<gary_poster> frankban: cool.  you should be able to.  if not, lemme know, and I'll see what I can do to make that possible,
<frankban> gary_poster: it seems I was able to do that. publication pending
<gary_poster> frankban: exxxxxxcellent.  muahaha. etc.
<frankban> lol
<rick_h_> lol, /me can see Gary doing the hand motions all too easily
<gary_poster> :-)
<frankban> gary_poster: quickstart published \o/
<lazypower> Congratulations on shipping today!
<frankban> thanks!
<rick_h_> gary_poster: for the release. We're calling this 0.15 with a note on the "no more pyjuju support" in the changelog?
<rick_h_> gary_poster: or are we ok calling it 1.0?
<gary_poster> awesome frankban!  congrats!  Send out your email from yesterday to juju list?
<gary_poster> rick_h_: I'm afraid we are calling it 0.15.  To assuage some concerns with theoretical nothings: the GUI technically still supports pyjuju
<gary_poster> it is only the charm that has changed
<gary_poster> so if someone want to use the new gui with pyjuju they could
<gary_poster> using an older charm
<gary_poster> I think :-)
<gary_poster> maybe worth calling out in release notes.  can use that as excuse for the official 1.0 later when we rip out pyjuju in gui itself
<rick_h_> gary_poster: ok, so I'm calling out that this is the last release? or just leave it out in the notes of the gui itself?
<frankban> gary_poster: sure
<gary_poster> rick_h_: no, leave it out of the GUI.  At most say that this is likely to be the last release of the GUI with pyjuju support
<rick_h_> gary_poster: silence sounds golden to me then. Thanks
<gary_poster> cool ty
<gary_poster> thanks frankban, great
<hatch> in other news: my dogs like bacon
<gary_poster> sky is blue still, as well, then, in Canada?
<hatch> not sure, overcast with a low ceiling
<hatch> it MAY be!
<gary_poster> :-)
<hatch> man these have to be the most obscure test failures ever
<frankban> gary_poster: email sent, do you have any suggestions for my next card?
<rick_h_> frankban: did you see my earlier query about the bugs around the errors and bundles?
<rick_h_> frankban: I thought at least one of the two in the high lane were fixed?
<frankban> rick_h_: pasting from above: yes, that can be considered fixed, but right now we have no feedback on what went wrong, just an "unknown error" or similar. we need some changes to land on the deployer to really fix that bug
<rick_h_> frankban: oh heh, I missed the reply. /me needs to get his mentions split back in irssi. 
<frankban> rick_h_: the WatchDebugLog API does not seem to be ready on core side, right?
<rick_h_> frankban: oic, so this isn't the original swallowing of errors then. 
<rick_h_> frankban: correct, a new revision was pushed up today in the code review
<rick_h_> frankban: after this release I was going to look at maybe poking at the front end bits, but was going to check with the gary_poster first. Maybe something else would make more sense. 
<rick_h_> frankban: can you post your email to the gui blog?
 * rick_h_ wants to share with the world via pretty html links
<frankban> rick_h_: sounds good, I can help implementing the client API in the GUI when we know better how the API looks like
<frankban> rick_h_: re blog post, sure
<rick_h_> frankban: would love the help on that. https://codereview.appspot.com/44540043/ is the commit I've been tracking if you want to peek at it. 
<hatch> I wonder if there is some way to make phantom cache assets
<rick_h_> cache bad
<rick_h_> bad cache! bad!
<rick_h_> I'll take < performance over "impossible to debug wtf"
<frankban> rick_h_: yeah I saw that, the EntityLogRequest parameters with Lines and Tag seems great. Still not sure how a user-admin will access that Debugger API
<hatch> rick_h_ I was thinking caching the YUI stuff not our code :)
 * hatch does a little dance after solving the huw's test issues
<rick_h_> frankban: cool, happy to chat on what I know once I get through the release stuff. So maybe tomorrow lol
<frankban> :-)
<gary_poster> frankban: next card: you are blocked by hazmat on those two with your head right?
<frankban> gary_poster: yes
<gary_poster> frankban: ok.  I know some of the "high" cards are not exciting.  jujucharms ETags, 1230410, or "add link from unit link..." are reasonable.
<benji> gary_poster: should I take the "make releases" card?  (or perhaps split it into multiple cards and take one to start)
<gary_poster> rick_h_: debug log is blocked on TheMue getting that landed, right?
<rick_h_> gary_poster: yes
<gary_poster> rick_h_: :-(
<rick_h_> gary_poster: though I thought some of the UI stuff could 'start'
<rick_h_> making sure the tabs are ok, prepping the idea of storage layer, etc
<gary_poster> rick_h_: coudl you suggest those with a high priority marker on the board please?
<rick_h_> gary_poster: but it's got a short runway until that lands
<gary_poster> Hey TheMue, any estimate on when debug log will be ready for us?
<gary_poster> benji: rick_h_made another card it looks like
<gary_poster> I'll change that one to "jujucharms" release and mark it blocked
<benji> ok
<gary_poster> benji, frankbanif one of you were to identify the jujucharms etag issue that would be fab
<hatch> brb
<benji> gary_poster: I'll be glad to look at it.  Is there more detail somewhere?
<gary_poster> benji: yeah, looking, 1 sec
<benji> (I'm a big fan of "borked" as an adjective, but as a problem description it lacks something.)
<TheMue> gary_poster: API side is in review, I'm currently n the command side, but got troubles with the watcher logic there
<gary_poster> :-)
<TheMue> gary_poster: seems to be the first command using a watcher
<gary_poster> TheMue: API side almost ready for landing, as far as you can tell?  command side watcher logic: it is not an issue with the API, just an issue with how to *use* a watcher API from CLI?
<TheMue> gary_poster: but you're more interested on the server side of the API, don't you?
<gary_poster> yes
<TheMue> gary_poster: I have to detect if the server returns the error or if it is generated by wrong handling on the client side
<TheMue> gary_poster: dimitern already helped me so that I get further step by step
<gary_poster> benji, simply if you reload static resources from jujugui you will see that you get different etags for the same resource.
<gary_poster> getting example
<benji> hmm
<benji> are there multiple back-end servers?
<gary_poster> benji, yup.  you know where this is going.  however, we thought we had the right config to have ETags set by...whatever is stable.  I forget.  Either we are doing that wrong, or something in front of our own serving is getting that wrong.
<benji> my bet is on "something in front"
<gary_poster> yeah.  this task will probably be (1) prove that we are doing the right thing on our side (frankban can probably help do this very quickly) and then (2) work with webops to figure out what else is going on
<gary_poster> benji, hm
<gary_poster> it may be that they fixed this for us magically
<gary_poster> trying to dupe
<benji> fixing is good, communication would be good too :)
<gary_poster> by reloading https://jujucharms.com/juju-ui/assets/all-yui.js and seeing if I can get a non-304
<gary_poster> though I might have both ETags cached?
<benji> wget --no-cache might be helpful
<gary_poster> benji, I can't dupe.  Maybe this is a quick "demonstrate that the problem doesn't exist any more" card? :-)
<gary_poster> TheMue: ack, thank you.
<hatch> rick_h_ so are you going to put a dark stain over the green?
<gary_poster> jujugui call in 10
<benji> gary_poster: ok, I'll hack together a test script that will try to get inconsistent etags; if we don't get any after many requests we'll consider it fixed
<gary_poster> +1 thanks benji
<TheMue> gary_poster: yw, I hope I can solve this last mystery of mankind to get the watcher in for you asap
<gary_poster> :-) cool TheMue
<hatch> gary_poster would you like me to fix some of the remaining small issues with huw's branch and then land it?
<hatch> the remaining issues are trivials 
<gary_poster> hatch: yes please, thank you.  I'd also like to talk to you after call about planning out local charm stuff
<hatch> sounds good
<gary_poster> ty
<frankban> rick_h_: http://jujugui.wordpress.com/2014/01/21/juju-quickstart-1-0/
<gary_poster> woohoo!
<hatch> frankban is there a 'what is quickstart' blogpost somewhere? It should probably be linked from that post :)
<gary_poster> actually we should work with evilnickveitch on this
<gary_poster> hey evilnickveitch, do you have any time today or tomorrow to talk with us about incorporating quickstart into juju docs?
<evilnickveitch> gary_poster, yeah, i saw the announcement
<evilnickveitch> I should add it to my list
<gary_poster> :-)
<gary_poster> ok evilnickveitch, how would you like to prioritize it?  or should I get some feedback from mramm & arosales about that?
<gary_poster> jujugui call in 2
<evilnickveitch> gary_poster, I will put it next I think. I was working on simplestreams, but as quickstart is actually released...
<gary_poster> evilnickveitch: :-) cool
<frankban> :-)
<evilnickveitch> it makes sense to do it sooner. I will take a look at get back to you if I need anything!
<gary_poster> thank you evilnickveitch!
<bac> gary_poster: when is SA?
<gary_poster> bac, 1.5 weeks; first week of Feb
<bac> frankban: i've looked for mramm's reply you mentioned but don't see it? what list was it?
<frankban> bac: you are not CC'd
<bac> frankban: oh, ok
<gary_poster> hey frankban, moved quickstart announce cards to maintenance lane.  Will clear out quickstart cards
<gary_poster> i will move them to backlog just in case we want to look at them
<frankban> gary_poster: cool thanks
<arosales> gary_poster, evilnickveitch ack on getting quick start documented ahead of simple steams
<gary_poster> awesome thanks arosales
<arosales> we just need simple streams by 1.18, and the good stuff in quick start we need to let users know about
<arosales> gary_poster, time wise looking like a day or two given you can provide evilnickveitch with the technical bits needed. Is this correct?
<gary_poster> arosales: sounds good to me, yes.
<gary_poster> evilnickveitch, arosales, frankban should be the tech contact on this.  His timezone should align well with Nick's
<frankban> gary_poster, evilnickveitch, arosales: sounds good
<gary_poster> cool thank you
<evilnickveitch> arosales, frankban gary_poster, cool with me. I have started to have a look
<gary_poster> great
<benji> gary_poster: I have verified that the etag problem still exists:
<benji> % cat out  | sort | uniq -c
<benji>      63   ETag: "48b97-3dfd-4eb136e395640"
<benji>      37   ETag: "4aa32-3dfd-4eb136e395640"
<gary_poster> benji: suck
<gary_poster> benji: but thank you
<gary_poster> benji: confer with frankban before his EoD to get his braindump on this, please?
<benji> gary_poster: sure
<gary_poster> thanks
<arosales> evilnickveitch, thanks
<benji> oh, frankban!  what up with etags?
<frankban> benji, gary_poster: IIRC jc.com is deployed with the legacy haproxy+apache configuration, right?
<gary_poster> frankban: yes
<frankban> ok cool
<frankban> benji: so AFAIK the only piece of code where we handle etags is the apache template, i.e. lines 30-31 of http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/config/apache-site.template
<benji> frankban: are etags settings inferred from the cache control settings?  I don't see etags mentioned in that file.
<gary_poster> frankban: when you get a chance, could you please add some comments to https://bugs.launchpad.net/juju-core/+bug/1271248 ?
<_mup_> Bug #1271248: LXC local has issues in trusty <juju-core:New> <https://launchpad.net/bugs/1271248>
<frankban> gary_poster: sure
<gary_poster> ty
<rick_h_> gary_poster: we wanted to push an updated juju-gui trunk branch that has a moved note right? Is the thought to remove all the files and leave a MOVED which notes the github url and notes?
<gary_poster> rick_h_: yes, precisely
<gary_poster> and thank you for remebering
<gary_poster> +m
<frankban> benji: you are right, that directive seems to just tell the clients that they should revalidate
<frankban> benji: http://httpd.apache.org/docs/2.2/mod/core.html#fileetag IIUC, the Apache default for etags is not sane if you use multiple nodes
<benji> frankban: that sounds like out situation :)
 * benji reads
<frankban> benji: INode MTime Size is the default. I guess the first one is different for each node
<benji> frankban: that matches what I've seen in how the etags vary (the first bit changes while the rest is the same)
<frankban> benji: so if it makes sense to you, we could try adding "FileETag MTime Size" to the template
<benji> yep, that sounds like a winner
<frankban> (assuming the modification time and the file size are the same in each apache instance)
<rick_h_> gary_poster: care to play editor or just ack good 'nough https://pastebin.canonical.com/103326/
<gary_poster> rick_h_: +1 thank you.  suggest you also include link to lp bugs for gui
<rick_h_> gary_poster: rgr, will add
<gary_poster> otherwise fire away
 * gary_poster goes to lunch
<gary_poster> back in a while
<benji> frankban: I'll work up a branch that tweaks the apache config
<frankban> benji: sounds good thanks
 * rick_h_ starts playing taps http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/files
<hatch> rick_h_ are we using github releases for the gui releases?
<rick_h_> hatch: lmao please tell me you mean my other left in this card? https://canonical.leankit.com/Boards/View/102529849
<rick_h_> hatch: no, not at this time. I'm all for it though. It has an api to do it
<rick_h_> hatch: for now they're staying in LP
<hatch> :) leankit direct to card linking is broken
<rick_h_> bah, well the unit dying UI stuff
<rick_h_> wel dying service that is I guess
<hatch> I think I did that already....
<rick_h_> ok, well card in high for that
<hatch> oh yeah I am pretty sure it does that already
<hatch> if you want to test you can spin up a lxc instance and spin up, say, wordpress
<hatch> then destroy it
<hatch> I am pretty sure it goes into a dying state list
<rick_h_> right, but if you look in the *right* image there's a block under the service name that says "this service is ... "
<hatch> ohhh
<hatch> right that's not there
<rick_h_> ok, I'll replace left with right in that card 
<hatch> I really gota stop trying to run virtualbox and parallels at the same time
<hatch> it crashes hard
<hatch> hah
<hatch> and it apparently totally borks my networking hah
<rick_h_> boom!
<hatch> I can't wait till 14.04 so I can install it on metal 
<hatch> rebase conflicts have to be the worst
<rick_h_> hatch: :/ I think the thing is you don't get them that often if things are going smoothly so not used to dealing with them
<hatch> yeah, and now I'm trying to rebase something like 28 commits
<hatch> lol
<hatch> yay think I got it
<hatch> not entirely sure how there were conflicts when merging in order
<hatch> but oh well
<hatch> of course we'll see when the lint and tests pass hah
<gary_poster> leankit direct card linking works fine fwiw: https://canonical.leankit.com/Boards/View/102529849/108600813 for example
<gary_poster> you have to use the link on the bottom right of the card details
<gary_poster> and once you click on it, the card itself is removed from the url (that seems like a mistake on their part)
<hatch> yeah exactly
<hatch> If you put a link to a PR in a comment the PR gets a new line in it saying that it's been referenced elsewhere 
<hatch> ^ on github
<gary_poster> nice
<hatch> jujugui could I get a review/qa on https://github.com/juju/juju-gui/pull/81 plz, it's a long one (huw's branch)
<gary_poster> hatch, on it
<hatch> thanks
<hatch> it'll be nice to finally get this in there
<gary_poster> definitely
<gary_poster> rick_h_: if bac doesn't have the charm fix soon, maybe get this one in
<gary_poster> with a new gui release
<rick_h_> gary_poster: rgr
<gary_poster> not a request, jst an idea
<rick_h_> gary_poster: yea, it's np. The gui part isn't that bad actually. Spent most of the time trying to dbl check docs
<bac> gary_poster: it won't be today.  it doesn't look like the change to juju-deployer 0.3.0 solves the problem and i haven't tracked it down yet
<gary_poster> bac ok.  we need to cut pait sometime soon and make a gui release.  been way too long
<gary_poster> cut bait
<gary_poster> sorry
<rick_h_> gary_poster: I've got a fix in progress for a deployer UI bug as well. So maybe tomorrow we can see where we are and re-start release process
<bac> gary_poster: ok.  perhaps we just do two in short order
<gary_poster> ok
<rick_h_> well, bundle UI bug
<gary_poster> cool
<gary_poster> hatch: qa: SWEEET!  :-)
<hatch> haha, that should be our new QA OK
<gary_poster> :-)
<rick_h_> hatch: got a quick sec to look a mini-bug fix https://github.com/juju/juju-gui/pull/82 please?
<hatch> sure
<gary_poster> hatch, done.  +1 with a few very trivial bits
<hatch> great thanks, I'll get on those after rick's branch
<gary_poster> cool
<gary_poster> it's lookin' pretty snazzy on chrome
<rick_h_> bug spam alert!
<gary_poster> heh, what with you and curtis, it's almost like people are gardening bugs! ;-)  Thank you!
<rick_h_> heh, figured fullscreen is dead, bye bye any bugs dealing with that
<rick_h_> and then...
<benji> gary_poster: I have an Apache configuration tweak that should make etag generation consistent: https://codereview.appspot.com/55210044
<gary_poster> looking
<gary_poster> benji, cool.  yeah, I thought we had something like that already.  so the mtime should be on the basis of the time the gzip was made, not the time it was decompressed?
<gary_poster> if you follow my question?
<benji> gary_poster: right.  I'm deploying a second time the charm right now so as to verify that the etags generated by the second machine match those from the first
<gary_poster> benji, perfect.  thank you!
<benji> my pleasure
<hatch>           newHeight = this.panelsHeight >
<hatch>                                   tabHeight ? this.panelsHeight : tabHeight;
<hatch> gary_poster is this indentation better? 
<hatch> well the tabHeight lines up on 'e' on the previous line's Height in panelsHeight
<gary_poster> hatch, better, but can we break lines somewhere else?  If not, the indentation is at least improved
<gary_poster> newHeight = (
<gary_poster>     this.panelsHeight > tabHeight ? ...)
<gary_poster> ?
<gary_poster> actually
<hatch> I could make it use smaller var names and put it on a single line
<gary_poster> isn't this just max
<hatch> newHeight = panelsHeight > tabHeight ? panelsHeight : tabHeight;
<hatch> there :)
<hatch> oooor
<gary_poster> hatch: newHeight = Math.max(this.panelsHeight, tabHeight)
<hatch> yeah hah that just came to me
<gary_poster> conveys intent better and shorter, for the win, IMO ;-)
<hatch> agreed
<hatch> changing
<gary_poster> cool thanks
<hatch> oh yay now there are conflicts
 * hatch blames rick_h_ 's branch
<rick_h_> bwuhahaha, first to land, first to skate
<hatch> lol
<hatch> u suck
<hatch> that is all
<rick_h_> my 2 line branch must have killed you
<hatch> pretty much
<rick_h_> ok, can't believe after all that there's still > 150 bugs in there
<hatch> poop
<hatch> it's merge has totally put the code in the wrong spot
<benji> etag match verified, we have a lock, awaiting firing command
<rick_h_> woot!
<hatch> *FIRE*
<hatch> .....what are we firing?
<hatch> P
<rick_h_> ok, done with bugs. It's reached depressing point. /me runs away
<gary_poster> benji, merge away
<benji> gary_poster: alreday done
<gary_poster> benji awesome thanks
<gary_poster> rick_h_: don't be depressed :-)
<benji> I'm american, we don't really ask for permision to fire
<gary_poster> heh
<gary_poster> You know, I have a newsflash: Launchpad is slow.
<benji> heh
<benji> it's much slower than it used to be
<benji> no, reverse that
<benji> gary_poster: so, who is the feature-leader of per-unit debug log?  I would like to ask them if they would like me to work on "Auto open/close sidebar when using flyout from unit/inspector" next.
<gary_poster> benji, rick_h_
<benji> (we should assign the green card to the person leading the feature so we don't forget)
<gary_poster> ok good idea, will do
<benji> rick_h_: hi, shall I work on "Auto open/close sidebar when using flyout from unit/inspector" next?
<rick_h_> gary_poster: benji I wonder if maybe the best thing to wrap up release is see if benji can help bac at all? So we can try to get all our releases out tomorrow first?
<gary_poster> if bac thinks it will help +1
<gary_poster> otherwise looking 
<bac> benji: if you've got time i'd welcome some pairing
<gary_poster> yay
<rick_h_> benji: otherwise, sure. You can start that. I'm going to EOD myself
<rick_h_> double yay
<benji> bac: well, I'm almost EOD right now
<bac> benji: as am i
<gary_poster> heh
<bac> benji: maybe just chat for ten minutes?
<benji> bac: ok, do you want to meet up in the morning and see if you still want my help after sleeping on it?
<benji> bac: sure
<bac> today's hangout.
<benji> k
<hatch> rick_h_ lets spin up bigger instances for our CI, it's taking too long!
<hatch> as I say that it finishes
<hatch> lol
 * bac o/
<gary_poster> bye
<rick_h_> hatch: quit complaining. You wanted CI, enjoy CI :P
<hatch> You should know by now I'm never happy
<rick_h_> hatch: patch to parallel the saucelabs bit welcome :)
<hatch> lol
 * rick_h_ thinks it'll have to be done with jenkins job magic ugh
<rick_h_> would prefer we could do it in our makefile scripts
<rick_h_> makefile/scripts that is
<hatch> yeah so it can be put in vc
<rick_h_> and could be used locally as well
<hatch> well I have no idea how it works but maybe if i'm bored one day I can look into it
<rick_h_> honestly the 20min isn't that bad imo. slow down a bit at landing time, watch what you're doing. works for me
<hatch> yeah it's not bad at all
<hatch> just if you push up a small fix then you want to merge then branch from that
<hatch> you have to wait 40 mins to be able to get an up to date repo
<gary_poster> i'm outta here.  see ya tomorry
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: Ah, thanks so much for that fix
<hatch> huwshimi no problem, it was pretty obscure, fresh eyes probably helped :)
<hatch> fileSources[0].name.split('.').slice(-1).toString() hehe gross
<huwshimi> heh
<huwshimi> hatch: So happy to have that all landed!
<hatch> haha yeah that's been a while
<huwshimi> hatch: Thanks for adopting :)
<hatch> I really like the approach though
<hatch> so light weight
<hatch> kind of wish it could generate it's own tabs but that's out of our scope :)
<huwshimi> hatch: heh, yeah, not touching that again until I can help it :)
<hatch> huwshimi haha
#juju-gui 2014-01-22
<rick_h_> frankban: ping, did you see the emails from Gary last night?
<frankban> rick_h_: the ones related to the charm?
<rick_h_> frankban: yes, the charm release
<frankban> rick_h_: already replied, do you see the email I sent just some minutes ago?
<rick_h_> frankban: I've got to get the little guy off to day care but I'll start looking for the webops upgrade process docs for jujucharms after I get back. 
<rick_h_> frankban: ah no, I've got a built in delay running offlineimap
<rick_h_> nvm then ('ll see in 2-4min ish
<rick_h_> how did I I/) ugh, morning
<rick_h_> hah, or offlineimap hung on the server last night and I'm missing a lot of email
<rick_h_> frankban: awesome email, one question back at you
<rick_h_> bac: ping, when you get around this morning it appears charmworld hasn't ingested since the 20th. Did a deploy happen monday? Can you look into it?
<bac> rick_h_: thanks.  i'll look into it later
<bac> rick_h_: deploy was on thursday, the 16th
<rick_h_> bac: thanks. Off to run the boy to day care (and a coffee run) back in a bit. 
<frankban> rick_h_: thanks, replied
 * frankban lunches
<benji> bac: how can I help with the ValueError problem?  Perhaps I should attempt to reproduce it first.
<bac> benji: morning.  i have discovered the problem.  the int() was in jujuclient, a piece of the chain i hadn't looked at
<benji> cool!
<benji> ok, I'll do... the other thing I was going to do, whatever that was
<bac> benji: but the actual problem lies in the deployer
<benji> interesting
<bac> easy peasy fix, though
<benji> cool
<bac> hey, maybe i'll add some tests
<bac> but, benji & rick_h_, the solution will require getting changes made upstream into the deployer and then having the charm use that new version.
<bac> i don't see that happening before noon today
<benji> probably not
<bac> oh, look, i should read my email before starting my day.
<bac> hi frankban
<rick_h_> bac: rgr, not a problem. frankban's got the charm updated and I'll look at getting it deployed
<bac> thanks for looking into the constraints issue.  it turns out the deployer has a utility function called 'parse_constraints' that turns '1G' into a proper int value.  making that call in action/importer.py before calling self.env.deploy does what we want
<benji> bac: why is the deployer parsing these at all, shouldn't it delegate that to juju?
<bac> benji: the juju cli parses them.  the juju api expects a uint64
<benji> ah
<benji> that's unfortunate (because of issues like this)
<benji> next thing you know one of them will be parsing 1M as 1,000,000 and the other as 1,048,576
<rick_h_> bah, and #webops is a ghost town this morning
<rick_h_> I want a long bell pull I can yank on. "The bosses are coming the bosses are coming. Get up and deploy!"
<gary_poster> heh
<rick_h_> gary_poster: backup plan to push it up to AMZ for meeting?
<gary_poster> rick_h_: comingsoon still working; s'ok.  I can still announce the release was made, and jujucharms in progress
<gary_poster> thank you
<rick_h_> ok cool, wasn't sure what extent was required for the meeting. 
<gary_poster> hey frankban, are you familiar with local.jenv/bug 1271341?  Does quickstart handle this?
<gary_poster> #1271341 mup?
<gary_poster> oh, no mup
<gary_poster> mup sadness
<frankban> :-) bug 1271341 come on mup
 * gary_poster pretends to be mup: https://bugs.launchpad.net/bugs/1271341
<frankban> gary_poster: looking
<gary_poster> ty
<rick_h_> "right-click, edit search engines, scroll way down, add new, [Launchpad Bugs, b, https://bugs.launchpad.net/bugs/%s] and done"
<rick_h_> now just b<space>1271341
<rick_h_> and chrome syncs all that across browsers/installs. I forget I set it up originally. 
<rick_h_> (and the right-click is on the address bar to bring up "edit search engins")
<frankban> gary_poster: AFAIK the situation is the following: if the admin-secret is included in envs.yaml, juju uses that, otherwise a random one is generated. In both cases the admin secret is included in environments/[env name].jenv. quickstart is only aware of envs.yaml, and refuses to start if the admin-secret cannot be found there. when creating environments, quickstart always requires and includes the admin-secret fie
<frankban> ld. not sure about whether we can consider jenv files an internal detail or not. anyway, a fix for that should be quite easy to add
<gary_poster> frankban: sounds great, thanks.  I will file a quickstart bug and make a high maintenance card to represent "we need to investigate this" (since IIUC you are not sure yet that we actually need to *fix* this).  Sound right?
<frankban> gary_poster: sounds perfect, in theory we could consider the mandatory presence of the admin-secret field just one of the many quickstart opinions
<gary_poster> heh, agreed :-)
<gary_poster> For the curious, https://docs.google.com/a/canonical.com/presentation/d/1zJGPoNp8PTJCekluHzVy5Dr6aKViNqrg5fkBA7IIWyQ/edit#slide=id.g25d342ae6_35 has the slide I'll use to present our progress.  Comments/suggestions welcome.
<rick_h_> gary_poster: maybe note on quickstart as "fastest way to node 0 hosted gui env"? or the like?
<gary_poster> rick_h_: maybe replace the last quickstart bullet with that?
<rick_h_> gary_poster: +1
<gary_poster> cool thanks
<frankban> gary_poster: I forgot to mention in my email: while "juju-quickstart --gui-charm-url cs:precise/juju-gui-82" worked the GUI icon in the topology is a broken image. I suppose this is due to the ingestion problems in charmworld
<gary_poster> huh
<gary_poster> frankban: you must be right about ingestion problems.  81 is still most recent
<rick_h_> frankban: yes https://manage.jujucharms.com/api/3/charm/precise/juju-gui-82/files/icon.svg
<gary_poster> according to charmworld
<rick_h_> gary_poster: I've put a card up in urgent for the ingestion issue. It's not run some the 20th
<gary_poster> :-( ok thank you
<rick_h_> at least according to heatbeat
<gary_poster> heatbeat, the new way to dance to summer tunes that's sweeping the nation!
<bac> gary_poster: i have a deployer fix made and tested.  i'm trying it out with our charm now.
<gary_poster> bac, great thank you.  that's for the issue you were investigating yesterday, rt?
<bac> gary_poster: yes
<gary_poster> cool
<gary_poster> jujugui, who owns the "investigate MJC not ingesting" card?  May I have a volunteer?
<bac> gary_poster: i am looking
<bac> gary_poster, rick_h_ : i suspect it is related to a problem jcsackett saw and was solving.
<bac> jcsackett: you around?
<gary_poster> bac, ok.  you already have another card active though.  worth dragging benji in?  maybe not: sounds like multiple cooks already
<rick_h_> and no vanguard in webops this morning to help debug the logs
<gary_poster> argh
<gary_poster> Makyo: welcome back! when you get in would like to talk about subdividing relationship line project into task cards.  Afterwards we'll want to talk to rick_h_ about whether it should come before debug log, since it is not landing with speed.
<gary_poster> (in juju core)
<rick_h_> gary_poster: sounds good to me. I can be put to work. 
<gary_poster> :-) k
<bac> benji: do you have access to staging for charmworld?
<gary_poster> rick_h_: for logs, if we need to, I'm +1 on escalating the issue
<benji> bac: last time I tried I was getting strange errors no one could help with
<rick_h_> gary_poster: ok, I have an ops going to do the deploy soon (non-vanguard)
<gary_poster> rick_h_, bac: if we decide we need mjc logs, please make RT then ping #webops and ping me
<rick_h_> I can try to charm my way into getting a little extra if possible
<gary_poster> oh ok
<gary_poster> ok thanks
<rick_h_> try to relate it in together and nab his time
<gary_poster> :-) k
<gary_poster> sounds like a plan
<bac> gary_poster, rick_h_: after a quick look at staging, i see that ingest is failing to start.  the problem is the lack of an index, which is now occuring since the number of charms has grown and exceeded a threshold.  this is the problem jcsackett is fixing.  it is almost certainly the same as affecting production.
<bac> rick_h_: if you do get app.log from production it'll likely show ingest attempting to start every few seconds
<rick_h_> bac: ok good to know
<rick_h_> what index is lacking that's causing ingest not to start? 
<rick_h_> bac: mongodb or ES?
<gary_poster> ok, thank you bac.  If not obvious, I would categorize this as urgent/critical/stop-the-line/eek.  Anything we can do to help move this along (short of running around like chickens with our heads cut off) makes sense to me
<bac> mongo
<rick_h_> bac: ok, so we just need a migration in place to add the index and a deploy then? 
<bac> rick_h_: pymongo.errors.OperationFailure: database error: too much data for sort() with no index.  add an index or specify a smaller limit
<gary_poster> we probably should hjave a retrospective as to why this didn't get caught sooner
<gary_poster> at the very least with some kind of operational alert
<rick_h_> bac: orly, now that's not something I've seen. Mongo up and quits because it's too long? 
<gary_poster> I will add this card
<bac> gary_poster: i was in the discussion with jc but failed to recognize it would cause production to fall over.
<gary_poster> ack
<gary_poster> happens.  but production has been falling over since Monday
<gary_poster> that's what seems to me to be the most obvious failure of some sort
<gary_poster> that we ought to address for future
<gary_poster> make sense?
<rick_h_> bac: ok, it shows JC as out the last two days and back today
<rick_h_> bac: the calendar that is
<bac> gary_poster: my troublesome bundle just deployed successfully.  i'll propose the deployer fix upstream to hazmat and submit the charm change after the new tgz is built
<gary_poster> fantastic thanks bac.  perhaps two candybars are needed
<bac> rick_h_: it must've been an apparition then.
<rick_h_> bac: lol ok. I was mainly looking to see if he's around today. 
<bac> rick_h_: you can review the irc logs to see if i dreampt it up.  :)
<rick_h_> woooooo ghost of charmworld past
<bac> gary_poster: should someone phone jc to check his status?
<gary_poster> bac, ok.  will do so
<frankban> bac: FWIW I replied to your email
<gary_poster> bsc, called, left message :-/
<bac> frankban: i made the change lower in the gui env
<gary_poster> bac
<frankban> bac: sounds good
<bac> frankban: mp here https://code.launchpad.net/~bac/juju-deployer/parse-constraints/+merge/202674
<bac> hazmat: when you have a moment could you review https://code.launchpad.net/~bac/juju-deployer/parse-constraints/+merge/202674
<frankban> bac: that branch looks great
<bac> thx
<bac> gary_poster: wait on hazmat or release the charm with a forked version of deployer?
<gary_poster> bac, forked ( :-( )
<bac> k
<jcsackett> hey bac: gary_poster|away just called me to ask that i speak with you. ingest issues on charmworld?
<jcsackett> apologies if you've now been double pinged by me; not sure i was connected the first time.
<bac> hi jcsackett.  yes, the problem you saw on staging has brought down production and now we need a fix asap
<bac> jcsackett: unsure how far you got.
<jcsackett> bac: ack; brought down production, or just production ingest?
<bac> jcsackett: just ingest.  hasn't happened since the 20th.
<jcsackett> bac: i see.
<bac> jcsackett: but we're looking to do a juju gui charm release today and so we'd like to see it on charmworld
<jcsackett> bac: ack. do you have a traceback from production, or are we just assuming it's the same issue (which is a very good assumption, i think).
<bac> jcsackett: just assuming it is the same based on same heartbeat output
<gary_poster> yay jcsackett and thanks
<bac> jujugui: trivial charm review https://codereview.appspot.com/49720044
<gary_poster> jcsackett: no vanguards today so logs difficult :-/
<frankban> bac: on it
<frankban> bac: done
<bac> thx
<gary_poster> frankban: going to set up a call tomorrow with you and william (and maybe me) to review quickstart to talk through https://bugs.launchpad.net/juju-quickstart/+bug/1271341 and any other upcomg juju changes that might change/affect quickstart (e.g. the ssh key stuff that Tim is working on).  I figured you would quickly walk through what quickstart does, noting needed conversation topics as you go; and then, as time 
<gary_poster> permits, try to resolve those issues.  I think the review list is our first priority though, so we know where we stand.  sound ok?
<jcsackett> bac: take a look at https://code.launchpad.net/~jcsackett/charmworld/fix-enqueue-sort-failure/+merge/202678 for me? this should fix ingest, and we can try it on staging straight away.
<frankban> gary_poster: sounds good
<gary_poster> cool ty
<jcsackett> bac: mind you, this doesn't add indexes, so we're still going to see some issues, but i'm uncertain of the best way to do that on production and this should remove the current problem.
<bac> jcsackett: looking
<bac> jcsackett: voted approved.  didn't mark the MP as 'Approved' as it'll start the landing process.  do it when you're ready.
<jcsackett> bac: and away we go.
<jcsackett> i'll monitor staging and let you know if it does fix it. then we'll have to hound someone to do a production release.
<bac> jcsackett: ping me if you see it merged
<bac> i'm tailing app.log so should notice when it actually starts ingesting
<jcsackett> bac: ok.
<bac> jcsackett: CI rejected your branch
<jcsackett> bac: yeah, i saw. trying to open the jenkins data to see why.
<jcsackett> tests pass locally. :-/
<frankban> rick_h_: jc.com on pyjuju is really surprising :-/
<rick_h_> frankban: yes, that was quite surprising and caught us off guard a bit
<rick_h_> frankban: I thought that was upgraded months ago with charmworld, but maybe only one got done
<frankban> rick_h_: yeah
<frankban> rick_h_: thanks for updating the wiki page
<rick_h_> frankban: np, I'll file an RT to get it moved to -core and upgrade should owrk better
<frankban> rick_h_: at this point I'd also remove sandbox=true from there
<rick_h_> of course I remove pyjuju support
<rick_h_> sandbox? /me thought it needed that
<rick_h_> I'll look at what all it does again. 
<frankban> rick_h_: yes, you are right, it was staging the missing bit
<frankban> rick_h_: sandbox is ok.
<rick_h_> frankban: right, staging messed it up initially. I missed that one while editing
<jcsackett> bac: can you open the results? i think jenkins might actually be down. http://162.213.35.27:8080/job/charmworld-autoland-lxc/105/
<bac> jcsackett: did you connect to the vpn?
<jcsackett> bac: zuh? this may be a thing i missed.
<bac> jcsackett: where does that jenkins run?  is it on canonistack?
<bac> jcsackett: the vpn is required for the qa lab, so nm
<benji> rick_h_: do you have a moment to discuss "Auto open/close sidebar when using flyout from unit/inspector"?
<jcsackett> bac: i believe so. but that's a floating ip.
<bac> jcsackett: ask your fellow orangies
<rick_h_> benji: I think that's getting punted. 
<rick_h_> benji: working with webops atm though, will need a bit to chat
<rick_h_> gary_poster: ^^
<jcsackett> abentley: charmworld qa is on canonistack, right?
<jcsackett> s/qa/jenkins/
<benji> oooo-k
<abentley> jcsackett: Right.
<gary_poster> benji, it's a reasonable job separate from the project.
<gary_poster> benji, want to call?
<benji> gary_poster: sure; how about the daily meeting hangout?
<jcsackett> abentley: which environment? it looks like it may be down. i can't get a response trying to look at test results or anything else (162.213.35.27:8080/job/charmworld-autoland-lxc/105/)
<gary_poster> benji, k (though apparenty it pings some people when we use that? <shrug>) joining
<abentley> jcsackett: It's looked like it was down for weeks now.
<abentley> jcsackett: So maybe they've gone ahead with their plan to switch to something else.
<rick_h_> jcsackett: bac I've got the logs from prod charmworld
<jcsackett> abentley: it seems to be running tests; it's approved earlier branches of mine and has rejected the most recent.
<jcsackett> rick_h_: gimme.
<jcsackett> :-P
<bac> frankban: the juju-gui charm is failing locally with pip install.  perhaps it doesn't like the name i used juju-deployer==0.3.1-prerelease
<rick_h_> jcsackett: bac join #cloud-dev on canonical? I don't think there's info in here but don't want to put it in pub irc
<bac> frankban: it worked fine with juju-deployer==0.3.1
<frankban> bac: uhm, what's the pip error?
<abentley> jcsackett: the env was juju-gui-qa
<rick_h_> jcsackett: it looks like a github issue
<hatch> jujugui lf a quick review on a slight refactor of the drag and drop code https://github.com/juju/juju-gui/pull/83 
<hatch> it's mostly code reorg 
<jcsackett> abentley: thanks.
<jcsackett> looks like juju-qui-qa has lost its floating ips.
<Makyo> gary_poster, rick_h_ sounds good.  Let me take care of filing vacation (whoops), then I'll be all caught up.
<gary_poster> :-) k thanks
<gary_poster> hatch, I have a callin 12.  I'll try to get review done before then
<Makyo> gary_poster, accidentally filed MLK as PTO instead of nat'l holiday, just deny that one.
<gary_poster> ack
<bac> jcsackett: what's the story with charmworld CI?
<jcsackett> bac: still can't see the results, but i think it's a lint failure.
<jcsackett> pushing up a change now.
<bac> cool
<bac> do i need to re-approve?
<bac> tarmac used to be pissy about such things
<bac> gary_poster: juju gui charm on LP is currently broken.  new version being proposed now.
<gary_poster> Makyo: approved/rejected everything as appropriate; sent email to Sarah for 2013 days
<Makyo> gary_poster, cheers, thanks.
<gary_poster> ack thanks bac.  will ask for details on daily call
<gary_poster> hatch, looked good but ran out of time.  get someone else?  or I will return to it after daily call
<bac> frankban: can you look at this https://codereview.appspot.com/49720044 trivial review?
<Makyo> gary_poster, just curious, can I claim airport parking? There's no public transit to the airport from FoCo.
<gary_poster> Makyo: yes
<hatch> FoCo....haha
<Makyo> ?
<Makyo> Fort Collins, sorry :)
<Makyo> FoCo, NoCo.
<hatch> yeah I guessed that
<hatch> we just say Saskatchewan to laugh at people who can't pronounce it
<hatch> lol
<frankban> bac: done
<jcsackett> bac: branch has been merged; should be on staging shortly.
<bac> jcsackett: cool
<bac> jcsackett: new version running: http://paste.ubuntu.com/6797831/
<jcsackett> bac: that lock thing doesn't look good...
<bac> nope
<jcsackett> is it just thrashing?
<bac> jcsackett: i'm not sure what is happening.  if it grabbed the lock but then errored due to the lack of index it should've released the lock.  so i'm not sure why it is starting again with the lock held
 * jcsackett nods
<jcsackett> the lock should release in about 10 minutes.
<bac> jcsackett: i'm going to watch it for a bit.  if i need to manually restart ingest i can
<jcsackett> based on the timestamp.
<bac> yeah, they have a 15 minute cycle
<bac> gary_poster: changes landed to juju gui charm at r155.  https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk
<gary_poster> ty
<rick_h_> bac: gary_poster note that we can't release that until we get the env to juju-core
<rick_h_> bac: so left a 'deploy jujucharms' up there. If we can do another charm release, once I get through everything we can look to deploy that updated charm release. 
<gary_poster> ...on call confused
<gary_poster> will focus soon
<bac> rick_h_: i'm confused to by 'get env...'
<rick_h_> bac: yea sorry. Figured I'd go through it on the call
<bac> ok
<rick_h_> jujucharms.com is on pyjuju, the charm no longer supports it. Things go boom right now
<bac> jcsackett: we really should make those times human readable...  :(
<bac> jcsackett: time outputs in the log, i mean
 * rick_h_ is changing locations pre-call
<Makyo> jujugui call in 10
<bac> jcsackett: stale locked removed on staging and it is now ingesting
<jcsackett> bac: whoo!
<bac> jcsackett: http://staging.jujucharms.com/heartbeat
<jcsackett> bac: already have it opened.
<jcsackett> bac: so we need a charm upgrade and deploy done on production.
<bac> jcsackett: but is it the same issue on production?
<jcsackett> bac: i can't tell. the log i got is corrupted.
<bac> jcsackett: for production we just need an update of the charmworld code, the charmworld charm is ok.  correct?
<jcsackett> bac: no, a revision i landed requires a charm update so the ini file is updated.
<bac> jcsackett: ack
<jcsackett> bac: you're making the request of webops?
<bac> jcsackett: i will
<hatch> jujugui call in 1
<gary_poster> ty
<hatch> Makyo
<Makyo> Sorry, got signed out
<rick_h_> jcsackett: the tarball didn't work I sent you?
<jcsackett> rick_h_: no, the bunzip command says the data is corrupt.
<rick_h_> jcsackett: it's tar bz2? 
 * rick_h_ looks up bunzip
<rick_h_> jcsackett: email on the way untar'd
<hatch> is anyone else getting an email about the daily call being changed every day?
<rick_h_> benji: ping if you want to chat
<rick_h_> hatch: if you look I think it's for dates far in the future
<benji> rick_h_: I'll be there in a sec.
<rick_h_> like on holidays or something. At least the last one I noticed was Oct or something?
<gary_poster> hatch, the bluefin thing?  yeah/
<gary_poster> I could uninvite it :-)
<hatch> rick_h_ yeah it just shows a slew of dates and I can't see anything different, but you're probably right
<jcsackett> rick_h_: this log worked.
<jcsackett> unfortunately, it makes it look less likely that my fix will sort out production, since i don't see the same error.
<Makyo> Vimeo tab crashed 55% of the way through uploading, argh.
<Makyo> I kind of hate computers.
<hatch> you sure it's not Vimeo? It sometimes stops playing a video half way through too lol
<Makyo> heh
<Makyo> Nah, this was a chrome crash.
<hatch> boo urns
<gary_poster> sigh, toilet clog, overflow, upstairs, sigh
<gary_poster> back to review
<hatch> those are the worst! 
<gary_poster> yup :-)
<hatch> I like the new toilets though, because they use such little water it would take like 3 flushes to overflow :)
<gary_poster> lol
<gary_poster> 1960s toilets up here
<hatch> at least here, I don't think we can even buy a 'traditional' toilet anymore
<hatch> we use such little water that they had to increase our water bills because they weren't able to support the infrastructure lol
<gary_poster> that's cool, mostly!
<hatch> downside to being 'green' I guess haha
<gary_poster> hatch +1 on code.  do you need a qa for that?  I have call in 6.
<hatch> gary_poster I qa'd and it worked so if you want to live on the edge....no :)
<gary_poster> Heh ok, I think the edge will be where I live then :-)
<gary_poster> hatch trivial comment request.  shipit otherwise.  If you really wanna you could push comment into next branch. :-)
<hatch> sounds like a plan thanks
<marcoceppi> manage.jujucharms.com api down?
<rick_h_> jcsackett: bac rgr, that was my impression that this looked different
<gary_poster> marcoceppi: we are def having issues.  yes, looks like it.  bac, ^^^
<marcoceppi> gary_poster: cool, as long as you guys are aware :)
<gary_poster> not best timing in the world :-P
<gary_poster> thanks marcoceppi
<rick_h_> marcoceppi: gary_poster looks like deploy is going on
<rick_h_> chat in #webops on it
<gary_poster> rick_h_: oh ok
<gary_poster> marcoceppi: back
<marcoceppi> \o/
<hatch> frankban you still around?
<frankban> hatch: yes
<hatch> so I'm following the README in juju-core which says to use `go get -v launchpad.net/juju-core` but after that go complains that there are no Go source files (which is true) so the readme I'm assuming is missing a step/
<hatch> ?
<frankban> do you have $GOPATH set up?
<hatch> yeah it downloaded all the files
<hatch> I am trying again on a fresh instance but I'm guessing I'll have the same outcome
<frankban> hatch: have you created the $GOPATH directory?
<frankban> mkdir $GOPATH
<hatch> yeah.... oh you know what I did? I forgot the ... after the url
<hatch> I'm not really sure what that does or why it's required
<hatch> go get -v launchpad.net/juju-core/...
<frankban> hatch: it means get recursively everything
<hatch> normally it only gets the top level?
<jcsackett> bac, rick_h_, gary_poster: manage.jujucharms.com appears to be ingesting.
<gary_poster> yay!
<frankban> hatch, rick_h_: I also set up a bzr lightweight checkout following http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/bazaar-usage.txt
<gary_poster> thank you jcsackett, bac
<frankban> if you do that you can skip the cobzr instructions
<hatch> frankban so is that a thing with `go get` that if you don't put the ... at the end then it won't get anything deeper than a single level?
<rick_h_> jcsackett: what was the mjc error about?
<rick_h_> jcsackett: and yay
<frankban> hatch: see "go help packages"
<frankban> hatch, rick_h_: so basically IIRC I followed http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/README#L22 (from line 22) and then http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/bazaar-usage.txt
<jcsackett> rick_h_: so, the problem my branch fixed was removing a sort on a query that we didn't need, b/c the collection is too big to sort without an index.
<jcsackett> that was observably the problem with ingest on staging.
<jcsackett> not to so much on prod, but it appears to have fixed it. ...or there was an unknown issue that updating/upgrading cleared.
<bac> rick_h_: was marco's API issue transient due to the upgrade?
<rick_h_> bac: yes, I believe so 
<bac> cool.  just reading backwards after being afk
<rick_h_> jcsackett: ok, so a restart or something might be hiding a production error? It was 'fixed' as a by-product of updating?
<bac> rick_h_: well, we know the index issue was real and present.  unsure what, if anything, might still be lurking
<rick_h_> bac: rgr, ok
<bac> rick_h_: but to reduce the variables we did the deploy and it now seems (temporarily) happy
<hatch> rick_h_ just fyi, super easy to compile juju if you don't make any stupid assumptions that the docs were wrong
<hatch> :P
<rick_h_> hatch: lol
<hatch> rick_h_ my vm thinks that there are branches on the remotes/origin (my fork) that don't actually exist is there any harm in deleting them as if they do?
<hatch> at least from what you may have run into in the past
<rick_h_> hatch: I'd want better details
<rick_h_> what's the output of git branch -a
<hatch> oh `git remote prune` I think I'm supposed to use
<rick_h_> yea, if you don't clean up your branches when they're merged they hang around and that's valid
<hatch> yeah the issue is that they don't actually exist but it thinks they do
<rick_h_> this is the part that confuses me
<hatch> so it must just be stale and doesn't actually update on pull
<rick_h_> they don't exist locally?
<rick_h_> git fetch updates
<hatch> nope, or remotely
<rick_h_> just run a git fetch and git branch -a should be good
<hatch> yeah no luck, they are still there
<rick_h_> what is one of their names?
<hatch> remotes/origin/viewlet-test-scaffold
<hatch> which doesn't exist in my remote fork
<hatch> or locally
<rick_h_> that shows up in git branch -a?
<hatch> yup
<hatch> there are a lot here
<hatch> which fall into the same category of "don't exist"
<hatch> so a fetch/pull must not update the remote list
<rick_h_> git remote show origin
<rick_h_> hatch: did you add another remote that has those branches?
<hatch> nope
<rick_h_> git remote
<rick_h_> have only the two?
<hatch> the vm hasn't been started in a long time though, and I removed those from another vm
<hatch> it's just odd that a pull/fetch doesn't update the remotes
 * rick_h_ is confused
<hatch> rick_h_ https://www.evernote.com/shard/s219/sh/46bee204-7bc9-42c8-9214-7dbb7739291e/61a736cb9f230a012072cee432333e3c 
<hatch> those are from the git remote show origin command
<hatch> but I'm not entirely sure HOW they get into this state
<rick_h_> hatch: hmm, http://kparal.wordpress.com/2011/04/15/git-tip-of-the-day-pruning-stale-remote-tracking-branches/ has some notes
<rick_h_> hatch: so maybe you've got something setup that auto tracks remote brancheds you've not checked out directly? 
<rick_h_> hatch: and they got removed on the remote end so that tracking reference goes nowhere?
<hatch> ahh that could be why it's stale
 * rick_h_ has none and isn't sure and wonders if it's hatch specific git toys
<hatch> because grb auto tracks remotes
<rick_h_> sounds like a winner 
<hatch> well it is really convenient 
<hatch> :)
<rick_h_> and then you don't know wtf it's doing. Magic...it'll bite ya! :)
<hatch> well no, I knew it was auto tracking, I just didn't know if that tracking failed the branch ref would go stale
<hatch> I figured it would just be cleaned up on pull/fetch
<rick_h_> well it sounds like grb needs its own pull/fetch to auto update that 
<hatch> yeah maybe, it only has 5 commands create, delete, publish, rename, track
<rick_h_> well, maybe you need to add a tweak you something like your version of the juju-sync alias to also prune remotes
<hatch> yeah that's a good idea, I wonder why you would WANT to keep un-pruned branch references
<rick_h_> no idea
<gary_poster> hum.
<gary_poster> ok, call over.
<gary_poster> lunch now
<gary_poster> biab
<rick_h_> heh...hum about the call? or lunch
<gary_poster> call.  for us was mostly fine, except for not being able to align with master spreadsheet
<gary_poster> will describe more later
<rick_h_> rgr
<gary_poster> just was very long, mostly :-)
<rick_h_> hatch: Makyo http://blog.fogcreek.com/we-spent-a-week-making-trello-boards-load-extremely-fast-heres-how-we-did-it/ mainly for the progressive layout chunking
<rick_h_> but interesting lunch read anyway
<hatch> cool i'll check it out
<hatch> I used to use fogz bugz a few years ago
<hatch> ended up bring priced out as the team grew
<hatch> ugh itunes is such a mess 
<hatch> http://venturebeat.com/2014/01/21/dockers-open-source-bet-pays-off-with-15m-round/
<Makyo> gary_poster, I have a little list.  Where should I create the cards?
<hatch> gary_poster in call, whwnever you're ready
<gary_poster> Makyo: one sec, let's talk on your call about it
<Makyo> gary_poster, sounds good.
<gary_poster> Makyo: I expect you feel blocked. :-) if so, I'm ready to talk anytime.  I'm in the 1:1 hangout now
<gary_poster> otoh no rush
<hatch> store/go.js is way to big at 1600 lines :)
<hatch> store/env/go.js that is
<gary_poster> rick_h_: moving per-unit debug log cards to backlog subdivide 6 (currently empty).  s'ok?
<gary_poster> benji will move your card to maintenance as discussed
<benji> gary_poster: k
<rick_h_> gary_poster: rgr
<rick_h_> hatch: got a sec?
<hatch> sure wassup?
<rick_h_> yui ?
<hatch> the jpop singer?
<bac> rick_h_: is the bug you're working on juju-gui or charmworld?  it is assigned to juju-gui but says staging.jujucharms.com
<rick_h_> bac: gui
<rick_h_> bac: that's the ol gui url
<benji> are the "social" buttons in the GUI supposed to work?
<rick_h_> bac: the old gui comingsoon thing
<bac> ahrighto
<benji> if they're just there to taunt people silly enough to want to click on them, that's fine with me; otherwise I'm going to file a bug as my exploritory bug for the day
<bac> benji: they wfm
<benji> hmm
<benji> bac: chrome?
<bac> safei
<bac> safari
<bac> benji: chrome too
<bac> benji: what do they do for you?
<benji> bac: nothing (hence the taunting)
<bac> oh
<gary_poster> benji, sounds like a winner
<benji> I'll ship my laptop to whomever works on the bug.
<gary_poster> lol
<rick_h_> that just means you get to fix it
<bac> rick_h_: is the 'charmworld staging on prodstack' card really ready to go?  if so, can you do a pre-imp with me?
<rick_h_> saves the shipping costs
<rick_h_> bac: I think so sure
<bac> rick_h_: ok, gimme five minutes?
<rick_h_> bac: rgr
<rick_h_> hatch: care to review/qa when you get time? https://github.com/juju/juju-gui/pull/84/
<hatch> sure
<hatch> 20mins?
<rick_h_> hatch: no hurry at all
<rick_h_> bac: https://plus.google.com/hangouts/_/7ecpjtg5oje324k9uvcla65al8?hl=en
<rick_h_> bac go bye bye
<rick_h_> bac: is that cool though? nough said or any other questions?
<hatch> gary_poster when sending the zip to juju we need to specify the series....any preferences to how this is done?
<rick_h_> bah humbug IE
<gary_poster> hm
<hatch> rick_h_ the test failure didn't show which test failed :(
<hatch> gary_poster we need to know before we upload it, so I was thinking a dialogue 
<gary_poster> hatch, can we open the inspector immediately, put the dialog in it, and then change that to become the usual deployment view?  In effect, if not in code
<hatch> hmm
<rick_h_> hatch: yes it did, in the selenium images
<hatch> gary_poster so it would be essentially a blank inspector with the exception of the single input?
<BradCrittenden> laura has posted an opening for a mongo intern in asia. i should apply then move to myanmar.
<gary_poster> hatch, I envision the dialog, wherever it goes, saying the name of the file, a description of what's about to happen, some buttons to choose a series, and a button to cancel teh upload
<hatch> gary_poster ok I'll create another task for that
<gary_poster> hatch, or have it be separate.  TBH, the right answer is to ask luca
<gary_poster> hatch: for this branch, you'll assume precise?
<hatch> right, ok I'll create a card, and it can be done in parallal 
<hatch> right now I'll just assume precise
<hatch> yeah
<hatch> :)
<gary_poster> cool :-)
 * hatch rages 
<hatch> I hit that $%^&*(&^%$#%^&*&^%$#@$%^ power button all the time on this stupid keyboard
<hatch> who puts a power button right above the delete key!!!!
<rick_h_> lmao
<benji> bac: if you would, try the social icons on comingsoon.jujucharms.com
<bac> deaderthanadoornail
<rick_h_> any console log bits?
 * rick_h_ wonders if it's recnetly broken then
<bac> hatch: huh, i think that has happened to me once.  maybe you delete more stuff than me.
<gary_poster> console log is empty
<hatch> bac haha maybe
<bac> rick_h_: maybe they just got bored from never being pushed.
<gary_poster> heh
<bac> i mean, have we seen any posted to twitter?
<hatch> gary_poster email sent to peeps and luca
<hatch> re the dialogue
<gary_poster> hatch, email and card look good, thank you
<hatch> rick_h_ hey what was the IE fix?
<rick_h_> hatch: if (Y.ua.IE) { search._handleInputFocus() }
<hatch> ahhh right, the simulate ie bug
<hatch> man I wish they would fix that
<rick_h_> yep
<rick_h_> me too
<rick_h_> of course the docs don't note that it's an issue at all
<rick_h_> whatever, I kicked it in the butt, it's landing
 * rick_h_ throws down the mic
<hatch> lol
 * rick_h_ is ready to put today to bed
 * gary_poster goes
<gary_poster> bye
<huwshimi> Morning
<hatch> *sigh* looks like I have to write my own xhr code because Y.io doesn't do what I need :/
<hatch> morning huwshimi 
<huwshimi> hatch: Fun evening then?
<hatch> ehh, just feel like I wasted a bunch of time 
<hatch> and every time I try to use YUI it seems like it's falling behind
<hatch> I mean there should be no reason I have to write native XHR to send a blob :/
<huwshimi> hatch: Yeah, not cool
<rick_h_> hatch: what can it not do?
<hatch> rick_h_ http://yuilibrary.com/yui/docs/api/files/io_js_io-base.js.html#l636 
<hatch> I'm pretty confident I cannot pass a blob as 'data' unless it's in a form
<rick_h_> hatch: hmm, maybe chat tomorrow on it? pre-imp 
<hatch> I'm almost done the xhr stuff
<hatch> but sure
<rick_h_> I'd think you could base64 or at worst fake it
<hatch> :)
<rick_h_> meh, ok then. Just make sure to test in all browsers :)
<hatch> haha
#juju-gui 2014-01-23
<frankban> rick_h_: I have some git questions, please ping be when you are available
<gary_poster> frankban and jujugui generally: I am sorry for the short notice but I have to have another call this morning.  I will ping you to reschedule asap, as necessary.  hopefully it won't be too big of a disruption
<hazmat> frankban, fwiw feedback branch merged
<frankban> hazmat: great! thanks
<frankban> gary_poster: np
<frankban> gary_poster: re the quickstart call, I suppose the timeframe we are interested in is from now to the trusty release, right?
<gary_poster> frankban: right
<frankban> gary_poster: cool thanks
<gary_poster> np thank you
<rick_h_> gary_poster: rgr
<frankban> hazmat: I will work on a follow up branch so that the guiserver can use the new feedback stuff, sounds good?
<hazmat> frankban, sounds good, i'll hold off on a new release then
<frankban> hazmat: cool
<frankban> rick_h_: following the git workflow described in the GUI docs, I get this: http://pastebin.ubuntu.com/6802788/
<rick_h_> frankban: what is the current branch you're on?
<rick_h_> git branch -a
<frankban> dying-service
<frankban> rick_h_: ^^^
<rick_h_> frankban: what version of git? 
<frankban> rick_h_:  1.8.3.2
<rick_h_> frankban: so like it's saying the branch isn't tracked yet. So you've not pushed it up yet?
<rick_h_> frankban: e.g. git push origin dying-service
<rick_h_> oh hmm, I do see the branch
<frankban> rick_h_: this happens before and after the branch push to origin.
<rick_h_> so it did not track it. Ah, there's a snippet in the demo .gitconfig I think I must have for this
<rick_h_> frankban: ok, so even though you pushed it's not tracking. You can fix that with the command from the help in the error
<rick_h_> git branch --set-upstream-to=origin/dying-service dying-service
<frankban> in gitconfig I have [push]
<frankban>     default = tracking
<rick_h_> oh, you do have that. Was just getting ready to paste that
<rick_h_> well, let's see if setting tracking helps first and go from how it's not tracking as a follow up
<rick_h_> if you --set-upstream does the rebase command work?
<frankban> rick_h_: trying
<frankban> rick_h_: now I have nano opened, do I need to write the new commit message?
<rick_h_> frankban: so it should bring up an editor for you to choose to keep/squash commits 
<rick_h_> frankban: after you choose which to keep/squash you then get to adjust your commit message
<rick_h_> frankban: see http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
<frankban> rick_h_: I see this in the editor: http://pastebin.ubuntu.com/6802845/
<rick_h_> umm, ok...
<rick_h_> try this please
<rick_h_> git rebase -i HEAD~~~~
<frankban> rick_h_: so to abort that I have to delete all lines, right?
<rick_h_> oh hmm, there's not multiple commits
<frankban> rick_h_: I did multiple commits
<rick_h_> frankban: no, just quit that editor without aking any changes
<rick_h_> frankban: right, but the line "Rebase 1de177e..1de177e onto 1de177e"
<rick_h_> means that the rebase it was trying to do was all on the same commit, nothing to do
<frankban> rick_h_: yeah
<frankban> rick_h_: trying "git rebase -i HEAD~~~~"
<rick_h_> does that look better having the last 4 commits in the branch history?
<frankban> rick_h_: http://pastebin.ubuntu.com/6802858/
<frankban> rick_h_: the last 3 commits are the relevant ones for my branch
<rick_h_> frankban: ok, and the last 3 are yours?
<frankban> rick_h_: yes
<rick_h_> frankban: ok, so you can rebase them here and force push
<rick_h_> frankban: the --autosquash didn't work because you've already pushed all three commits to your remote (origin dying-service)
<rick_h_> frankban: --autosquash tries to help you squash new commits locally that you've done since your last push to help limit your rebase activity to only things you've done.
<rick_h_> so that explains the "Rebase 1de177e..1de177e onto 1de177e"
<rick_h_> and we're still left with the mystery of why it didn't track when you pushed originally
<frankban> rick_h_: how do I have to change that document?
<rick_h_> frankban: k, sec
 * rick_h_ hates how our pastebin doesn't have a reply/edit
<rick_h_> frankban: so the notes at the bottom help you figure out what to do. You want to squash the last two commits into the first so it should look like http://paste.ubuntu.com/
<rick_h_> frankban: when you save that document, it should bring up a new editor window with a diff up top and your changelog history for those 3 commits below
<rick_h_> frankban: and you can edit the commit message to be the complete clean history of what this branch is/does
<frankban> rick_h_: the link you sent is the pastebin home page
<rick_h_> frankban: sorry, http://paste.ubuntu.com/6802873/
 * rick_h_ forgot to put in the username to paste
<frankban> rick_h_: so you pick everything including your first commit, and swuash your other commits, right?
<rick_h_> frankban: correct, it works backwards
<rick_h_> so you're "squashing" the extra commits down into the first and left with one clean one
<frankban> rick_h_: so, we do this so that the juju-gui develop branch only includes relevant changes, one commit for each branch, right?
<rick_h_> frankban: yes, or more if it makes sense
<rick_h_> but this is the git way of replacing the way bzr would layer it's commits on merge to different branches (trunk)
<rick_h_> frankban: and it's why we work off in our own forks until review is done. 
<rick_h_> frankban: so if you look https://github.com/juju/juju-gui/commits/develop you can see I kept two commits for my one branch that landed noting out specifically the IE fix required to land. 
<rick_h_> frankban: once you're ok on that and have pushed it up with -f to force overwrite your remote history, please run git config --list and let me know if push.default was picked up right
<frankban> rick_h_: cool, ok so now doing "git push -f origin dying-service"
<rick_h_> frankban: correct
<rick_h_> and when you go to https://github.com/frankban/juju-gui/commits/dying-service
<rick_h_> it's cleaned and one commit in the history now
<frankban> rick_h_: yes
<rick_h_> which you can use for the pull request to the juju version
<frankban> rick_h_: git config --list -> http://paste.ubuntu.com/6802927/
<gary_poster> frankban: not sure yet when we should reschedule, but we'll do it.  rick_h_can call when you are ready
<frankban> gary_poster: ack
<rick_h_> gary_poster: rgr, sec let me get it fired up
<rick_h_> frankban: afk for a bit
<bac> hazmat: i made the changes you requested in https://code.launchpad.net/~bac/juju-deployer/parse-constraints/+merge/202674.  please merge this branch if you approve.  thanks.
<hatch> I've been reading a lot of people's pipes freezing because of this new weather.... I don't get it, how do the pipes freeze? Aren't they IN the house?
<hatch> or do building practices over there have the pipes in the outside walls or something?
<gary_poster> hatch, basements aren't insulated terribly well, and also the pipes coming into the house are often the problems.  When you don't have to worry about really cold weather very often, you don't have good demonstration that everything is working properly very often
<gary_poster> benji no rush but https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.8vsks3qndr814s6te61qlkqn8g when you wanna
<hatch> ohh gotcha, yeah our pipes come into the house 8ft underground and then everything runs on the inside walls, that must be the difference
<rick_h_> frankban: off call. did you get the pull request ok or hit any other snags?
<bac> gary_poster: what time is our call today?  the email has something different from google cal.
<gary_poster> bac 2pm my time.  ok?
<bac> gary_poster: nm, subsequent email is correct
<gary_poster> sorry
<bac> yes, 2 us/east
<hatch> at least I'm not the only one getting emails from google rescheduling meetings lol
<frankban> rick_h_: on call, will ping later
<hatch> evilnickveitch it would be nice if the headers in the juju docs were hrefs so that we could link to their # without having to do it manually llike https://juju.ubuntu.com/docs/charms-deploying.html#local
<hatch> s/were/had
<bac> gary_poster: i'd like to do the charm testing stuff today and probably tomorrow.  that alright?
<gary_poster> bac sure
<rick_h_> oh right, /me moves my card back and goes to download amulet
<bac> rick_h_: it's on lp but authoritative on github
<rick_h_> bac: yay
<bac> rick_h_: so do i really have to write charm tests until 9pm, per the invitation?
<rick_h_> bac: I plan on cheating and writing a *still hacking...hacking..* bot to make it 
<bac> hey, we should collaborate on that.  clojure?
<rick_h_> hah, been thinking of trying that
<evilnickveitch> hatch, sure, not all of the headers have ids, i have been adding them when i refresh pages.
<evilnickveitch> e.g authors-hook-debug.html
<frankban> rick_h_: is there a way to make git remember the remote branch when pushing?
<rick_h_> frankban: my understanding that's what the config is supposed to do
<rick_h_> frankban: I wanted to walk through a test branch and see if we could dupe or see something slightly off in the last branch
 * gary_poster on call now, and out 9:50-10:40 FWIW (that is, I'll be out in 10 minutes, and back about 50 minutes later)
<hatch> evilnickveitch cool thanks, I just noticed it today as a nice-to-have :)
<frankban> guihelp: could anyone please review and QA https://github.com/juju/juju-gui/pull/85 ? thanks!
<gary_poster> running.  biab
<hatch> frankban sure, it'll take me a bit, doing a couple things at once here
<frankban> hatch: np and thank you
<hatch> frankban do you know if in 1.17.1 they changed the output of juju status in local envs? This is what I get after bootstrapping and deploying the gui https://www.evernote.com/shard/s219/sh/e97b60b5-20e8-4d3e-bded-3c0f62efa179/23d15a7ed70c5bdade557146fc08e377
<hatch> 1.17.1 being trunk 
<frankban> hatch: that does not look right
<hatch> haha nope
<hatch> maybe I'll ask in juju-dev
<frankban> hatch: no idea, worth pinging them
<frankban> hatch: didn't we decide to still use isTrue and monkey patch assert?
<hatch> frankban I thought that was the last-resort method so that we didn't have to fix all of the old ones
<hatch> so any new ones we could do the 'old fashioned way'
<frankban> hatch: :-/ 
<hatch> hey! I'm just trying to save us headaches, blame Chai :P
<frankban> boo chai!
<hatch> there we go! and I agree
<hatch> :)
<frankban> heh
<hatch> I have a huge craving for a SODA
<hatch> i'd say a POP but noone would know what I was talking about :P
<hatch> Makyo so I was doing some research lastnight on the vagrant stuff and it looks like the typical file sharing system is the virtual box file sharing not NFS
<gary_poster> jujugui call in 7 btw
<hatch> frankban I'm just spinning up a juju env to test your branch right now, shouldn't be much longer
<frankban> hatch: cool thanks
<gary_poster> jujugui call in 2
<bac> rick_h_: will webops grab log files via an IRC request or do they require an RT?
<bac> hatch: POP is a smtp protocol
<rick_h_> bac: I've had good luck just getting vangaurd
<hatch> haha
<rick_h_> bac: only once I think I got asked to file an RT
<bac> rick_h_: thx
<frankban> gary_poster: I am available for 1on1 anytime, also tomorrow if that works better
<gary_poster> thanks frankban.  I moved it to tomorrow at today's time. You can change the time in the calendar if that is bad for you 
<hatch> gary_poster we have a regression with the inspector and destroying services https://bugs.launchpad.net/juju-gui/+bug/1271986
<frankban> gary_poster: tomorrow same time works for me
<hatch> frankban qa done
<frankban> hatch: great thanks
<gary_poster> thanks frankban, great
<gary_poster> hatch, looking
<hatch> and in other news - people are asking for putcharm :) http://askubuntu.com/questions/409637/deploy-local-charm-from-juju-gui/
<gary_poster> hatch :-/ do you know if it is in release?  my guess is yes
<hatch> gary_poster it's in frankban's branch so most likely
<gary_poster> yeah
<gary_poster> not horrible, but me no likey regressions.  putting on high list in kanban
<frankban> hatch: did not encountered that while QAing my branch :-/
<gary_poster> pre-existing IIUC
<hatch> frankban it might only happen if the service is pending when you destroy it
<hatch> not sure
<frankban> hatch: never waited for the service to be ready...
<hatch> hmm
<hatch> well then....it was your branch heh
<frankban> hatch: trying it again
<hatch> the bug wasn't caused by you though
<frankban> hatch: maybe it's intermittent
<hatch> oh boy, intermittent failures when the 'test' cycle is 15mins lol
<frankban> this is nothing
<rogpeppe> gary_poster: just checking: if you were implementing the debug-log stream in a REST interface (not RPC-oriented like the API) what would be the most appropriate way of transferring the data? would a long-lived GET request work OK? perhaps a unidirectional websocket connection would be better?
<rogpeppe> gary_poster: i am currently pushing back on the currently mooted design, which uses the normal API for streaming the debug-log data, because it's not a very efficient way of streaming large quantities of data
<hatch> rogpeppe you mean via the RPC?
<rogpeppe> hatch: yeah - that's the current design, which i don't think is quite right
<hatch> I disagree, websockets were designed for exactly this
<rogpeppe> hatch: yes, websockets, but not RPC-over-websockets
<rogpeppe> hatch: so you'd suggest a unidirectional websocket rather than a long-lived streaming GET request?
<hatch> rogpeppe that would be my preference 
<rogpeppe> hatch: ok, cool.
<hatch> I haven't been following the api discussion though
<gary_poster> rogpeppe: interesting question.  long-lived GET feels reasonable at first cut.  I'd be interested in hearing what the strategy was for both sides protecting themselves from too much content/insufficient read speed.  websocket might give more options there
<rogpeppe> gary_poster: well, TCP flow control should do the job sufficiently
<gary_poster> although perhaps "drop the connection when problems happen" is the right strategy
<hatch> long polling is so....1995 :P
<rick_h_> gary_poster: rogpeppe I'd want to peek at how/if multiple websocket lmitations and such. 
<frankban> hatch: FWIW I am not able to reproduce the inpector bug (using my branch). what charm did you use?
<rogpeppe> hatch: the advantage of long polling is that there's zero protocol overhead above TCP
<rick_h_> it's interesting if we can run a couple at a time as we're monitoring a couple of units at a time, or getting something allows multiple watches over the single websocket
<hatch> but really though streaming data like debug-log is what a websocket was pretty much designed for - it's similar to games sending data between the server
<rick_h_> hatch: except that's usually bi-directional
<rogpeppe> rick_h_: you should be able to run any number; but you'd use a connection for each stream.
<hatch> sure, which our current websocket also is
<rick_h_> which isn't needed (I don't think)
<hatch> so you guys would like to open up an additional websocket for each debug-log stream?
<gary_poster> rogpeppe: had to refresh my flow control knowledge.  
<rogpeppe> hatch: that's my suggestion, yes
<hatch> sorry maybe I should just go read the thread
<gary_poster> this is the thread I think? :-)
<hatch> rogpeppe hmm
<rogpeppe> gary_poster: +1
 * hatch is processing
<gary_poster> rogpeppe: I don't see an issue with the GET for this use case atm
<gary_poster> websockets seem unnecessary
<rick_h_> gary_poster: yea, my only thing there was we hit limitations in long-poll of 6? per browser in LP?
<rick_h_> I'm trying to recall when it hit a limit but know some people hit it
<rick_h_> was per domain based if I recall
<gary_poster> true, though we already were thinking that we needed a relatively low limit like that
<gary_poster> yes
<hatch> ok Im ready
<rick_h_> right, but two browsers doubles that and hits limit faster
<rick_h_> two tabs
<rick_h_> etc
<rick_h_> not sure why you'd have it but want to think on it
<hatch> I'm throwing my hat in with websockets because of the limitations rick_h_  mentioned (although I think that's going to be more work for us)
<rogpeppe> i'm thinking that if you want to monitor many units/machines, it would be better to have a single stream multiplexing all of them
<gary_poster> yup
<gary_poster> that seems like a safer choice
<hatch> if we do that, then we can use the current websocket
<rick_h_> rogpeppe: yea, we were going to look at what that number is. 
<rogpeppe> hatch: not really
<hatch> rick_h_ it's different for every browser
<rogpeppe> hatch: the current websocket is strictly RPC-only
<rick_h_> I'm pro second websocket connect from the top of my head
<hatch> rogpeppe oh ok, I'm not familiar with how it's setup on the core side
<hatch> so second websocket which multiplexes the data?
<rick_h_> hatch: right, that allows requesting watches for units 1-5
<gary_poster> how would you add a new stream?
<gary_poster> in the multiplexed story
<hatch> gary_poster just throwing this out there....that ws could also accept requests
<rogpeppe> gary_poster: you'd ask for a new stream with the new set of units/machines
<hatch> or the rpc one could handle that
 * hatch wishes he knew more about how core worked
<rogpeppe> gary_poster: we'd have to be careful about how to deal with the potential overlapp
<gary_poster> Right, the RPC channel affecting the secondary channel on the fly seems a bit odd
<rogpeppe> gary_poster: i don't think that's a good idea
<hatch> so how would one open the secondary connection? It would have to be through the rpc no?
<rogpeppe> gary_poster: because you might actually be talking to two different API servers
<rogpeppe> hatch: the same way charm upload is done now
<gary_poster> feels more natural to let the debug log websocket be bidirectional then
<gary_poster> is that what you are describing rogpeppe?
<hatch> rogpeppe http?
<hatch> so http get to open a connection then bidirectional websocket after?
<rogpeppe> gary_poster: actually, a bi-directional (but not RPC-oriented) websocket connection could work well
<hatch> that feels weird
<rick_h_> rogpeppe: +1
<rick_h_> log socket
<gary_poster> how so hatch?  you open a debug log channel, you tell the debug log channel what you want to hear
<rogpeppe> hatch: you'd open the websocket connection in exactly the same way you'd open the current API RPC connection (except with a different URL path)
<hatch> right sorry my mind was being stupid
<hatch> ignore what I just said
<hatch> I like this idea
<hatch> :)
<gary_poster> :-)
<gary_poster> rogpeppe: so this is trashing existing work, yeah? :-/
<hatch> ok +1 to new non-rpc based bidi websocket 
<rogpeppe> gary_poster: i'm afraid so
<gary_poster> rogpeppe: is the win really worth it?
<hatch> oh poo
<rogpeppe> gary_poster: but i really feel that using an RPC-based API is not good
<hatch> I didn't think this was already implemented
<gary_poster> almost landed, almost approved by william
<rogpeppe> gary_poster: you're usually dealing with a very high latency connection
<rogpeppe> gary_poster: and we'll really feel the slowness if every read of a set of debug messages involves a round trip
<rogpeppe> i haven't looked at the implementation yet. i'll just do so. the adaptation might be easy, in fact
<gary_poster> rogpeppe: on the face of it, it feels like getting current solution landed and planning other solution later would be reasonable.  If this can happen quickly (without slowing things down) then I'm +1; otherwise, if this pushes things out, I'm pretty concerned
<hatch> yeah we would like the feature sooner rather than later
<hatch> *sigh* I swear something is trying to stop me from finishing this branch
<gary_poster> hey jujugui.  Is everyone available for a quick call?  Or alternatively, who is available for a quick call?
<hatch> i am
<hatch> I need a break from trying to build juju-core anyways :)
<frankban> I am
<benji> heh
<bac> sure
<benji> yep
<gary_poster> ok cool
<gary_poster> jujugui, https://plus.google.com/hangouts/_/canonical.com/team-call (Makyo and rick_h_ will fill in later--ping me or come on by)
<hazmat> rogpeppe, whats wrong the log push down the existing websocket connection.. its just multiplexing the connection
<hazmat> argh... what's wrong with
<rogpeppe> hazmat: because if it fills up, then it DOS's the rest of the connection
<hazmat> rogpeppe, meaning the client wasn't consuming fast enough... which could happen either way.. failure recovery is effectively the same though.. reconnect
<rogpeppe> hazmat: no, if the client isn't consuming fast enough and there's a separate connection, there's no problem. TCP flow control will work fine there.
<rogpeppe> hazmat: we're talking about a potentially large volume of data here
<rogpeppe> hazmat: that will probably be very bursty too
<hazmat> rogpeppe, this feels a bit theoretical. the gui isn't going to be subscribing to the entire env all the time, but more targeted as a context, it will close flows when the focus changes.
<rogpeppe> hazmat: we're going to be using this interface for the command line too
<rogpeppe> hazmat: and individual units/machines can produce large quantities of data too
<rogpeppe> hazmat: plus this way is *much* simpler
 * Makyo starts sending emails behind gary_poster's back :T
<gary_poster> Makyo: heh
<benji> I couldn't resist: http://tinyurl.com/g-day-countdown
<hatch> lol!
<hazmat> rogpeppe, individual hooks spewing large amounts  isn't very normal.. disks are finite...  while having a separate stream is nicer for flow, its going to be some rewrite/lost time. not really sure how its simpler isn't the traffic effectively the same?
<hazmat> rogpeppe, also just curious, is this going to include filtering and subscribing to individual contexts of interest (unit/machine), or the current read from the firehose with replay approach?
<rogpeppe> hazmat: if you're talking about using the existing websocket connection to stream data unidirectionally, that's a significant architecture change and would require quite a bit of attention
<rogpeppe> hazmat: the former
<rogpeppe> hazmat: (i've almost done it)
<hazmat> rogpeppe, ah.. simpler because it doesn't need to work around the existing json rpc server, ic..
<rogpeppe> hazmat: yeah.
<rogpeppe> hazmat: i like having one protocol per connection
<bac> rick_h_: we're seeing this on m.j.c.  -- does prod have a different port? ConnectionError: HTTPConnectionPool(host='localhost', port=2464): Max retries exceeded with url: /api/3/bundle/proof (Caused by <class 'socket.error'>: [Errno 111] Connection refused)
<hatch> frankban still hrere/
<frankban> hatch: almost, maybe, go ahead
<hatch> :) frankban I'm wondering if you have ever run into an issue with go where it cannot find some dependencies? cannot find package "code.google.com/p/go.crypto/ssh" for example
<hatch> this error comes when I run `go install` and i have run `go get` already
<frankban> hatch: weird...
<frankban> go get -v?
<hatch> yeah, I didn't get this issue in my vm's but on metal it is throwing this
<hatch> frankban I'm running it again
<hatch> maybe it dropped some before?
<frankban> hatch: it's possible... check inside $GOPATH/src/
<rick_h_> bac: I'm not sure. It'll be in the production.ini
<rick_h_> bac: have them get that file and check the port in the config for the app running
<frankban> hatch: it should contain a directory named code.google.com
<rick_h_> bac: but it sounds like it can't hit itself locally?
<hatch> frankban ok I'll figure this out, it's past your EOD so you can take off :)
<rick_h_> bac: for proof calls?
<bac> rick_h_: yeah, proof calls.  recall this was part of the charmproof subclassing i did to allow us to specify the server?  but it uses the config value in the ini file on both sides of the connection.  same variable.
<rick_h_> bac: is the variable added into the base that the production.ini is generated to?
<rick_h_> bac: I'm trying to look and see. the ini file in production is generated in the charm hooks to be a combination of a base file + overrides
<bac> rick_h_: i don't understand the question
<rick_h_> bac: and I forget what that generation starts with
<bac> rick_h_: oh, that
<rick_h_> bac: so if a new variable is added to the ini file, it must be added to whatever that hook uses as a base and changed by the overrides in production
<bac> rick_h_: i'm looking to see if that port is exposed to the charm. and if so will have them set it.
<bac> rick_h_: but it was not new
<rick_h_> bac: it shouldn't have to be exposed if it's access via localhost?
<rick_h_> at least I didn't think so
<rogpeppe> hazmat: here's the code (well, i haven't actually *run* it) for the log streaming. the deleted code is the currently proposed implementation. https://codereview.appspot.com/56100043/
<bac> rick_h_: not exposed as in "opened firewall".    i mean exposed as part of the charm's config.yaml for juju get and juju set.  sorry for bad word choice.
<rick_h_> bac: ah ok 
<hatch> frankban figured out the issue with the juju-core deps
<hatch> oh he's gone :)
<bac> rick_h_: i'm asking for the production.ini file
<bac> on staging proof.port=6543.  on production it is trying to use 2464.
<rick_h_> right but what is the service running on on prodstack? Do you have the production.ini?
<rick_h_> [server:main]
<rick_h_> use = egg:Paste#http
<rick_h_> host = 0.0.0.0
<rick_h_> port = 2464
<rick_h_> is the default.ini
<rick_h_> staging might change that, wonder if prodstack is on the default port
<hatch> gary_poster looks like my issues with juju-core were related to the vm, it appears to be working as expected on metal....
<bac> rick_h_: yeah, 'port' and 'proof.port' are different in the production.ini file.  hmm, seems like a DRY violation ass biting
<rick_h_> bac: rgr
<rick_h_> bac: so have to trace the code in the charm that's generating the file and see where the mixup is and correct
<rick_h_> bac: but a cowboy patch of fixing the ini file on prodstack should get us unstuck
<bac> rick_h_: i *think*  I.S. maintains a custom version of the charm with custom production_overrides.ini
<rick_h_> bac: ah, is that part of the 'IS block box' bit we don't see?
<rick_h_> gary_poster: when you get a chance can we catch up on the debug log discussion? it was simu-cast and want to make sure I'm caught up
<gary_poster> heh sure
<gary_poster> will ping soon
<rick_h_> rgr
<BradCrittenden> thanks rick_h_
<rick_h_> bac: np, sucky to hit a bug in that. It's not had an issue so far and I don't see anything freaky in looking at the config files
<gary_poster> bac, no rush, but I'm ready in https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.b6tepoq090fnj4qfdg23a3okhg when you are
<bac> rick_h_: dang -- http://manage.jujucharms.com/heartbeat
<rick_h_> bac :(
<marcoceppi> rick_h_: if it makes things easier, I can take your current pull req for amulet, merge it then merge mine and do a quick conflic resolution
<marcoceppi> if that frees you up
<rick_h_> marcoceppi: sec, I've got to finish fixing my sysdeps and add the test deps bits
<marcoceppi> k
<rick_h_> marcoceppi: I'll have an update and rebase it up clean in a few min
<marcoceppi> <3
<hatch> gary_poster There appears to be some sort of bug in juju-core which is returning a 405 when I attempt to post a charm. If noone gets back to me in juju-dev I'll have to wait until Dimiter gets in in the morning
<gary_poster> hatch ack
<hatch> I've also added a card to the needs spec column for fakebackend support. I think we will require the js zip lib which is required for DD'ing of a folder but I figure we should have a call as to weather we even want to support fakebackend support
<gary_poster> hatch, it's not a matter of if we want it, IMO: it's a matter of cost/value.  If we can get it done in a few days it is a no-brainer IMO.  This is teh kind of thing we want to be able to demo.
<gary_poster> if it takes more than a few days, harder call
<hatch> yeah sorry that's what I meant. I don't have any experience with the zip libs in general so hard to say without more research
<bac> rick_h_: sorry dropped out and had a call with gary_poster.  did you dig any further?  i just asked for the new app.log.
<rick_h_> bac: no, was waiting to hear what you found out sorry
<bac> rick_h_: i'll handle this from here, though.
<rick_h_> bac: let me know if I can help
<bac> ugh, deej disappeared.
<gary_poster> benji fwiw, I think @media max-width was the css thing I was vaguely recalling that I mentioned yesterday: https://github.com/huwshimi/juju-gui/commit/cbd64eaa00ff4d956bf956f9fda3dec51ff68504
 * benji looks
<benji> ooh, that's nice
<benji> wait, is that the width of the display or the width of the viewport?
 * benji googles.
<gary_poster> viewport I think
<bac> benji: this error should've been solved by your r479 in charmworld, no?
<bac> 2014-01-23 19:12:36,165 ERROR [charm.update-bundle][MainThread]         E: opens
<bac> tack: The requested relation nova-ceilometer to nova-ceilometer is incompatible
<benji> bac: nope, the error is real, my branch made the error give you a hint about how to fix it (reverse the order of the relation)
<bac> ok
<bac> my misunderstanding
<gary_poster> benji you found "width" in https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries ?  "The width media feature describes the width of the rendering surface of the output device (such as the width of the document window, or the width of the page box on a printer)."
<bac> benji: the hint is logged, fwiw
<benji> bac: cool
<gary_poster> Makyo or others: did you happen to have any ideas for Huw with his projector support branch (https://github.com/huwshimi/juju-gui/commit/cbd64eaa00ff4d956bf956f9fda3dec51ff68504)
<gary_poster> "
<gary_poster>  Unfortunately
<gary_poster> > while I can scale the content I can't get it to fill the browser.
<gary_poster> "
<hatch> ok I think I have found the issue....the post is being made to the gui charm, not to juju-core and not being redirected
<gary_poster> ah
<gary_poster> makes sense
<hatch> guess I should have figured that out sooner :/ 
<hatch> so....anyone want to have a pre-imp on the best approach for this?
<gary_poster> so charm needs change.  for now, to not be blocked by that, you might be able to figure out the juju port, expose it and connect to it directly?
<hatch> can I do that without changes to the charm? from the browser I don't really have access to anything along those lines
<hatch> I could fake it I suppose with a ssh tunnel or something
<gary_poster> well
<hatch> call?
<gary_poster> for pure hackety hack there are options, I think.  ssh is one
<gary_poster> sure
<hatch> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.j0rk5d371ph8331ijtf48t2uj0?authuser=1
<bac> rick_h_: i just watched mjc drive the queued charms and bundles to 0/0
<bac> rick_h_: then it queued back up to ~2350 and 26.
<bac> that all looks normal.  i'm not sure why bundles ever are allowed to go over 26
<bac> but it was at 104 (26 * 4) when i started watching
<rick_h_> bac: well bundles only run after charms right?
<rick_h_> so if charms don't complete then bundles would get backed up over and over?
<bac> rick_h_: yes.  but in one process, until completion
<rick_h_> bac: if it's getting through every so often can we look at it in the morning? so it's not 100% broken.
<rick_h_> bac: I want to finish this thing for marco before EOD and I've got to look at the ingest code again. I must be missing how something is working. 
<bac> rick_h_: yes, tomorrow is fine.  ingest has probably changed a lot since you looked
<rick_h_> we start a process, that fills queues and we empty them one at a time so I would think if we didn't get the charm queue to 0 before the next ingest cycles the bundle ones would get put in a holding pattern
<gary_poster> rick_h_ whenever you get a chance we can hangout and I can tell you the debug log saga AIUI :-)
<rick_h_> gary_poster: sure thing
<rick_h_> gary_poster: https://plus.google.com/hangouts/_/7acpi7muavq74fq2ibqs44nhb0?hl=en
<hatch> it can' t be a 'saga' King will sue you for their trademark
<hatch> lol
<bac> rick_h_: aha -- staging never got the charm updated.  the charmworld app gets updated automatically by CI but the charm has to be one manually.  so apples-mangos
 * bac runs off to hopefully break staging
<rick_h_> bac: yes!
<rick_h_> bac: this is true
<bac> rick_h_: dang, false alarm.  it is running -57, the latest
<rick_h_> bac: so catchup call in the morning and go from there? I got amulet working (well build/tests pass) and sent a pull request in
<rick_h_> bac: and then we can catch up on wtf charmworld hates now
<bac> rick_h_: a-ok
<hatch> gary_poster did you create a card for the gui charm support of putcharm? I don't see one but want to make sure I"m not missing it somewhere
<gary_poster> hatch, no, thought you were.  sorry for miscommunication.  want me to?
<hatch> nope, on it!
<hatch> done
<gary_poster> thank you
<hatch> gary_poster should I assign it to someone? I could take a peek at it but I'm not so sure my python is up to snuff about proxying https :)
<gary_poster> hatch: assign it to frankban, send him a note about the background, and cc me?
<hatch> sure
<gary_poster> thanks
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: Do you use vagrant?
<hatch> I do
<hatch> I also use virtual box and parallels
<hatch> lol
<hatch> so...many...vms
<hatch> did you have a question about it?
<huwshimi> hatch: Trying to get everything set up in os x, just wondering what's easiest?
<hatch> yeah the vagrant workflow is by far the easiest 
<hatch> but the virtual box file sharing is really slow for running things like make lint etc
<hatch> at some point I will add the nfs setup to the vagrant but....some time
<huwshimi> hatch: I think this is the first time I've booted into os x since I installed ubuntu :)
<hatch> haha, I'm waiting for 14.04 before trying to tackle that on this mbp
<hatch> why are you now working in osx?
<huwshimi> hatch: Safari testing
<hatch> ahh
<hatch> huwshimi the vagrant ip is 192.168.33.10:8888
<hatch> just fyi
<huwshimi> hatch: Ah great
<huwshimi> hatch: What box image do you use?
<hatch> umm sec
<hatch> huwshimi it should auto set that up when you set up your vagrant image
<hatch> from the vagrant file...
<hatch> config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/raring/current/raring-server-cloudimg-amd64-vagrant-disk1.box"
<huwshimi> hatch: Oh, so maybe I need to ask what vagrant file you use?
<huwshimi> I'm confused
<hatch> so you should install vagrant then virtual box then type `vagrant up` in your gui dir
<hatch> so have you installed both vagrant and virtual box?
<huwshimi> yes
<hatch> ok so now clone your gui fork
<hatch> and navigate to the root dir in that repo
<hatch> then type
<hatch> vagrant up
<hatch> and wait for a while (subsequent startups will be muuuuuch faster because the image is already set up) 
<huwshimi> oh I see, we have vagrant specific stuff in our tree
<hatch> yup thanks to Makyo 's hard work :)
<Makyo> Shit, what'd I do?
<Makyo> Oh.
<hatch> in fact in London my vm went totally bonkers and I coudln't connect to it through the network there and vagrant allowed me to actually work haha, so I was happy
<hatch> :)
<hatch> Makyo don't worry, this time it's a good thing :D
<Makyo> Whew!
<Makyo> I accidentally a good thing.
<hatch> haha, it was a good idea
<hatch> at some point I'll add nfs support to it
<hatch> gary_poster huwshimi  is the daily call AUS edition on today?
<huwshimi> hatch: I believe so, up to gary_poster I guess
<gary_poster> yes! :-)
<hatch> huwshimi do Australians like their sausage? https://twitter.com/rharris334/status/426472243418247168
<huwshimi> haha
<hatch> lol
<gary_poster> huwshimi and jujugui who wanna: https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.dd77sn7kjl6unba21lutdr0p70
<huwshimi> gary_poster: Haaving to install a plugin. Be right with you.
<Makyo> hÃ¥ving.
<huwshimi> :)
<hatch> huwshimi just for reference http://yuilibrary.com/yui/docs/api/classes/UA.html#property_os
<huwshimi> thanks
#juju-gui 2014-01-24
<bac> hey rick_h_
<rick_h_> bac: morning
<bac> rick_h_: so, it turns out mjc still had a cronjob to do queueing.  that should've been removed in a version of the charm a few back.
<bac> rick_h_: once it was turned off manually everything is normal
<bac> rick_h_: so, i have some charm oddities to investigate.  1) why didn't the config file get written properly and 2) why wasn't the new cron entry written?
<rick_h_> bac: hmm, could it be like a migration story?
<rick_h_> when the charm upgrades it needs to go back and remove the old files it no longer needs
<rick_h_> like dropping tables in a db no longer used 
<rick_h_> staging gets 'rebuilt' more often, though not recently. It does get manually touched and farther from the base charm path I'd guess. 
<bac> rick_h_: the hooks in the charm should handle re-writing those files.
<bac> rick_h_: the only thing i can think of is that I.S. has made some modifications since they muck with the charm before deploying.
<bac> rick_h_: another reason we need a prodstack-based staging server...
<rick_h_> bac: right, but if we drop a file in /etc/cron.d we have to manually remove it on upgrade right?
<rick_h_> the charm doesn't follow old written files to clean up 
<bac> rick_h_: there is a template for creating that file.  it should get re-written based on the changed template
<rick_h_> ok, so it was not 100% removed from existance then?
<bac> rick_h_: no, just one entry was to be removed and another added
<rick_h_> gotcha
<bac> rick_h_: but the version of cron.d/charmworld on prod was the old one
<bac> rick_h_: makes me suspect their novel version has changed something
<bac> perhaps they maintain a modified version of the template
<rick_h_> layers of invisible bug points wheeee
<bac> data centre nightmare: http://www.bbc.co.uk/news/uk-england-london-25873252
<bac> add that to your contingency plans
<hatch> morning all
<gary_poster> hiya
<hatch> lastnight I set my laptop up on my monitor finally....wow my monitor resolution sucks compared to the retina screen lol
<hatch> I need rick_h_ 's 4k 
 * frankban lunches
<rick_h_> hatch: :P
<hatch> as long as I place my monitor far enough away it's ok
<hatch> so that's cheaper I suppose
<hatch> lol
<gary_poster> I want the 4k too.  Kinda tempted to see what Apple comes out with for that though
<rick_h_> yea, why I got this ultrasharp. the dell US and apple displays generally share the same panels
<rick_h_> though I'm sure the apply will be nice with lightning connectors/etc
<rick_h_> while I got usb3
<hatch> I noticed that the laptop screen has horrible glare while my monitor has a matte finish
<rick_h_> matte or bust!
<hatch> yeah, not sure I'd enjoy a 30" glossy screen
<hatch> unless they have better glare reduction than the laptop screen
<rick_h_> some of it's the size I bet as well. lot more surface to catch it
<hatch> yeah, and the window and lights are behind me so that just compounds it
<hatch> buuuut sitll, matte doesn't have the issue :P
<hatch> is the 4k matte?
<rick_h_> yea, I only do matte
<gary_poster> heh
<rick_h_> I got one glossy and it's been in my closet for a long time
<rick_h_> should sell it
<hatch> does it have a 'sparkle' look to it? 
<hatch> on a white screen I can see these little sparkles in the monitor 
<rick_h_> not sure 
<hatch> the internet claims it's from the matte coating
<hatch> frankban any questions re the putcharm stuff?
<frankban> hatch: hey, so what's the target URL? https://{state-server-address}/charms/? what port?
<hatch> dimitern are you around?
<hatch> frankban dimitern wrote the juju-core implementation. so he would know best. From the docs I would assume the state server address on 17070
<hatch> in the email I sent it had the structure of the url 
<frankban> hatch: cool, so 1111 is just something you use for debugging, right?
<hatch> frankban yes sorry, that's just the port I use for my tunnel 
<frankban> hatch: ok thank you. starting the branch now, will ping you later for any questions
<marcoceppi> rick_h_ or bac are either of you guys running trusty?
<bac> marcoceppi: i have a trusty vm but had to stop using it temporarily. can fire it up if needed.
<bac> marcoceppi: but in general i'm running saucy
<hatch> frankban thanks!
<marcoceppi> bac: no, that's fine. there's a dep for amulet that's not building on trusty but builds on all other series
<marcoceppi> wanted to know how to prioritize it for today's test writing sprint
<gary_poster> jujugui call in 10
<gary_poster> wait no
<hatch> I was wondering :D
<gary_poster> what is the calendar reminding me of now :-P
<bac> timewarp
<gary_poster> ah, um.  charm testing writing sprint in 9 :-P
<rick_h_> benji: got a sec?
<benji> rick_h_: sure, want to coopt the dialy meeting hangout?
<rick_h_> marcoceppi: I'm on trusty
<rick_h_> marcoceppi: what dep, I can peek at it?
<hatch> ugh native events are so clunky
<rick_h_> benji: here please https://plus.google.com/hangouts/_/72cpjkbrct4593pml722lph0vo?authuser=1&hl=en
<hatch> I'm spoiled by YUI's event system
<rick_h_> hatch: +1
<marcoceppi> rick_h_: sure, I jsut asked for another build but it's charmworldlib
<marcoceppi> rick_h_: when/if it errors out in the next few mins I'll send it your way
<marcoceppi> it was saying it couuldn't download setuptools.py from the internet
<frankban> hatch: is putCharm already implemented in core trunk?
<rick_h_> marcoceppi: k
<hatch> frankban in trunk yes,
<hatch> you'll have to build it
<frankban> hatch: ack
<hatch> frankban http://bazaar.launchpad.net/~go-bot/juju-core/trunk/revision/2155 the merge
<frankban> hatch: cool thanks
<dimitern> hatch, frankban , sorry, i'm here now
<frankban> hatch: what's the best way in git to get your GUI branch locally? git remote add jeff .. + git checkout -b something + ??
<frankban> dimitern: hey, so the URL for putCharm is https://{state-server}:17070/charms/, correct?
<dimitern> frankban, yes
<frankban> dimitern: cool thanks
<dimitern> fwereade, it's actually https://{apiserver:ip}/charms?url={series}
<dimitern> frankban, sorry, ?series={series}
<frankban> dimitern: ack
<hatch> frankban sorry I missed the ding
<hatch> one sec I'll paste the git commands
<frankban> hatch: cool thanks
<hatch> git checkout -b hatch-local-zip-upload develop && git pull git@github.com:hatched/juju-gui.git local-zip-upload
<hatch> ^ frankban  I'm pretty sure that's the right command
<frankban> hatch: what about the following:
<frankban> $ git remote add hatch git@github.com:hatched/juju-gui.git
<frankban> $ git fetch hatch
<frankban> $ git checkout -b local-zip-upload hatch/local-zip-upload
<hatch> yeah I think that'll also work
<frankban> yeah, and "git fetch hatch" is cool
<frankban> ;-)
<hatch> lol
<hatch> agreed
<frankban> hatch: it worked. so, does your branch work in theory? e.g. I can zip a charm and drop it to the canvas, correct?
<hatch> frankban you bet, it should even console.log the progress, error, and loaded events
<frankban> hatch: cool. now in theory, when in the future I want to test/review one of your branches, I suppose all I have to do is " git fetch hatch" and git checkout ..., correct?
<rick_h_> frankban: yes, you've not setup a new remote that allows you to see what he's got up on github
<frankban> rick_h_: and fetch will always update that remote to what's present in github
<rick_h_> frankban: yes
<rick_h_> frankban: and a normal git fetch should check all remotes
<rick_h_> makefile experts, can I change a variable from within a target block somehow?
<frankban> rick_h_: makes sense, and what's the difference between pull and fetch? pull is for just one branch?
<rick_h_> benji: gary_poster ^
<hatch> frankban pull merges
<rick_h_> frankban: fetch will not pull down any source/code/etc. It's just a fetch of 'metadata' as I understand it
<hatch> fetch just pulls it down
<hatch> the metadata
<benji> rick_h_: environment variable or make variable?
<hatch> yeah
<hatch> :)
<rick_h_> benji: makefile variable
<frankban> cool thanks
<benji> rick_h_: is the value static or does it change (like in a loop)?
<hatch> frankban here is a very simple comparison http://stackoverflow.com/a/292359
<rick_h_> benji: http://paste.ubuntu.com/6808881/
<frankban> hatch: ic
<rick_h_> benji: the nose path can be in one of two places. If it's missing we pip install it and I want to run that check again and update it
<benji> rick_h_: I would probably just re-run the make file (i.e., have make run make)
<rick_h_> ooh, it can do that? /me never thought to try that
<rick_h_> so at the end of $(NOSE): $(PY) block just run make test?
 * rick_h_ is confused how this would work
<rick_h_> ok, so it both works and then doesn't because after it re-runs itself and runs the tests, it goes back to the original test target and runs it with the bad path value
<benji> oh, you want to depend on nose in order to run test... 
<rick_h_> I guess I should just evaluate it in the test block itself
<rick_h_> benji: right
 * rick_h_ looks if I can create a 'locate_nose' function in the makefile and just use that vs $(NOSE)
<benji> that might be an option
<hatch> there was a windchill warning in Orlando yesterday....it was +9C lol
<benji> doing it recusively shouldn't be too bad, you can have a test target that depends on nose like you have now, then have the body of that test target be just "make post-nose-test" which has no prereqs but has the body of your current test target
<rick_h_> benji: ah, gotcha
<rick_h_> good call
<benji> hatch: I was a little surprised it was so cold here this morning, I had to go to my dad's office to fax something early and it was -18C.
<hatch> really? wow I had no idea it got that cold there
<rick_h_> polar vortex of doom!
<rick_h_> canada, quit sending us your cold air
<benji> it doesn't very often :)
<rick_h_> benji: bingo, this works nicely. Thanks
<benji> I just wish we would get 20 inches of snow to go with it.
<hatch> rick_h_ lol, "polar vortex of common place but sensationalized by media"
<benji> rick_h_: cool
<rick_h_> hatch: no, it's darn colder than the past few winters here
<hatch> rick_h_ right, but a polar vortex is not anything special
<hatch> every planet has 2 of them and they change in size throughout the year
<rick_h_> we get some 0F stuff. but not every day for weeks
 * rick_h_ misses 20F and sunny with some snow on the ground
<hatch> this year has had low pressures below the polar region so it allowed the north polar vortex to influence the lower weather patterns
<rick_h_> when his nose hairs didn't freeze getting the mail
<gary_poster> ooh ooh!
<gary_poster> jujugui, call in ten *now*
<hatch> lol
<hatch> TIL: XMLHttpRequests do not throw errors for anything above a total network failure :/
<rick_h_> hatch: no, you have to watch them
<hatch> if (status > 400 && status < 500) { throw!!!!! }
<hatch> such lamesauces
<hatch> erll
<hatch> well
<hatch> if (status > 399 && status < 500) { throw!!!!! }
<rick_h_> if status doens't start with 20 throw
<rick_h_> heh
<hatch> their events are so weird
<hatch> the 'load' event handles everything besides 'progress'
<gary_poster> jujugui call in 2
<mhall119> hi everyone, I need help from somebody who's dealt with webops, I have a django charm that keeps running into problems when I deploy updates
<rick_h_> mhall119: howdy, we're on a team call atm, but happy to see if we can help
<mhall119> thanks rick_h_ 
<hatch> frankban I used `go get` to pull down trunk so I have no idea what revno. Does bzr store the revno in the .bzr folder somewhere?
<frankban> hatch: run "bzr revno" in the branch
<hatch> *facepalm* 2247
<frankban> cool, mine is 2253
<hatch> you were saying that you were having issues with it?
<frankban> hatch: yes
<hatch> hmm, it's working for me, do you have the charm pushed up somewhere?
<hatch> I can test it here
<hatch> if you like
<frankban> hatch: I was having issues to deploy the charm: http://pastebin.ubuntu.com/6808945/
<frankban> hatch: I'll try reverting to your revno
<hatch> permission denied...that's odd,
<hatch> ohh they are working on removing sudo
<hatch> maybe it's broken
<marcoceppi> rick_h_: buildlog for charmworldlib on trusty https://launchpadlibrarian.net/163611830/buildlog_ubuntu-trusty-i386.charmworldlib_0.2.2-0ubuntu2~ubuntu14.04.1~ppa1_FAILEDTOBUILD.txt.gz
<marcoceppi> seems to build fine on all the other series
<rick_h_> marcoceppi: k, will look in a bit
<hatch> frankban were you able to get the charm to deploy? (not sure if you were doing it on the call or not)
<frankban> hatch: yes, it seems to work well now
<frankban> hatch: the path will be /juju-core/charms/?series=xxx . the idea is to expose a /juju-charm/ namespace which proxies all requests (GET, POST) to and from core
<rick_h_> gary_poster: going into delete the trunk series gives me a lot of scary looking warnings. In particular The associated branch will be unlinked: lp:juju-gui
<gary_poster> rick_h_: uh. :-)
<rick_h_> gary_poster: can you +1 that it's just scary and press the button?
<gary_poster> heh ok, will go look
<rick_h_> gary_poster: thanks
<rick_h_> marcoceppi: do the builders not have external network access then? It can't download setuptools?
<rick_h_> marcoceppi: do you have a successful log for me to compare against? 
<marcoceppi> rick_h_: why would it fail for trusty and not others
<hatch> frankban yeah that's what I was thinking too, so do you mean that it will expose a /juju-core/ namespace?
<hatch> rick_h_ downside to deleting it is that we loose all that history and what-not
<hatch> do we need to delete it? :)
<rick_h_> marcoceppi: yea that's why I want to compare
<hatch> maybe if it's scary we just leave it hah
<rick_h_> hatch: yea, I'm wondering as well. I guess it's just confusing for others
<rick_h_> but we know enough
<rick_h_> so meh
<rick_h_> marcoceppi: I want to see if the others downloaded setuptools or if it was something already available to that build.
<marcoceppi> rick_h_: https://launchpadlibrarian.net/163199754/buildlog_ubuntu-saucy-i386.charmworldlib_0.2.2-0ubuntu2~ubuntu13.10.1~ppa1_UPLOADING.txt.gz looks like it's not trying to download. Maybe what comes in trusty py3 vs saucy differs and doesn't include 
<frankban> hatch: basically https://{guiaddress}/juju-core/* --> https://{api-address}:17070/*
<hatch> frankban right ok cool that's exactly what I was thinking
<gary_poster> rick_h_: six deletion attempts, six timeout errors.  how about I rename "trunk" series to "experimental"?
<rick_h_> gary_poster: works for me
<marcoceppi> rick_h_: I see python3-setuptools in saucy but not in trusty
 * marcoceppi looks at pkg
<gary_poster> rick_h_: https://launchpad.net/juju-gui/experimental , marked obsolete
<rick_h_> gary_poster: hah, I went to hit submit and got "lost something?"
<rick_h_> gary_poster: thanks
<gary_poster> welcome, sorry for confusion
<rick_h_> marcoceppi: hmm, it exists. http://packages.ubuntu.com/trusty/python3-setuptools
<marcoceppi> rick_h_: I don't think python3-all pulls it down
<rick_h_> marcoceppi: all ok
<marcoceppi> I dont' explicitly require python3-setuptools
 * marcoceppi fixes
<rick_h_> marcoceppi: so that looks like the failure though. It tries to download it and can't from the builder
<marcoceppi> ta
<rick_h_> jujugui really cool article with some handy 'say you want to do xx' git commands/notes. http://pypix.com/tools-and-tips/pro-git-workflow/
<hatch> it's missing the "say you want to smash it to itty bitty pieces"
<rick_h_> I like the standup one
<rick_h_> "wtf did I do? Hmm, git standup"
<frankban> hatch: localCharmHelpers is undefined in services.js
<hatch> frankban run in devel/debug mode
<hatch> that branch doesn't have it included in prod (sorry)
<frankban> hatch: ok
<rick_h_> hatch: here you go
<rick_h_> * wind chill values will fall to between 15 and 25 degrees 
<rick_h_>    below zero this morning. The wind chill readings will remain 
<rick_h_>    around 15 degrees below zero during the afternoon. 
<rick_h_> * Southwest winds will increase to 20 to 30 mph this 
<rick_h_>    afternoon... gusting at times to 35 to 40 mph. 
<rick_h_> there's our wind chill warning that I just got
<hatch> that's quite the warning
<hatch> ours is Temperature -10C, Windchill -30C
<hatch> you get a lot more information haha
<mhall119> rick_h_: do you have time now to help?
<mhall119> https://launchpad.net/ubuntu-api-website is the project, you'll see one branch for the app itself and another for the charm
<mhall119> the charm works fine in LXC, but in stagingstack it keeps getting db credentials for a user that can't read or write anything to the db
<mhall119> even after webops manually adds permissions/roles, on the next deployment they're erased again
<rick_h_> mhall119: what db is it talking to? 
<mhall119> I just added the grant_perms.py script that is called before doing any DB managment by the charm, but even that can't connect to the DB and set the permissions for the role
<mhall119> rick_h_: postgresql
<mhall119> using pg_bouncer in prodstack, but not stagingstack (unless they've added it now
<mhall119> )
<rick_h_> so the db hook is sending bad data to the charm? Does the user/pass it sends exist?
<mhall119> yes, and it can *connect*, it just has no permissions to do anything
<rick_h_> mhall119: hmm, I've not used the postgres charm so not sure how it creates the users and such. I'd ping someone that's hacked on that. Or find another charm that uses it and compare the db hooks between your app and their to see if it requests/passes anything extra?
<mhall119> rick_h_: I've forked the certification website charm to make mine, it uses the same db hooks
<rick_h_> mhall119: maybe ping stub and see if he's run into it before. I know he's worked on the pgsql charm some
<mhall119> already did, he suggested I add the grant_perms.py from certification charm but that fails because of lack of permissions too
<rick_h_> huh, yea it seems to me you'd have to get a user account that can do something
<mhall119> stub says postgres sets up a role for the user, and it's my charm's job to grant perms to the role (which is what grant_perms.py does), but the user it's given doesn't have permission to grant permissions to the role that was created
<rick_h_> mhall119: heh, chicken meet egg
<rick_h_> mhall119: looked at using the db-admin relation to get a user with super access to create the user for you?
<rick_h_> mhall119: looking at https://jujucharms.com/precise/postgresql-59/#bws-readme there's notes about using db-admin to get a superuser and that user should then have access to grant/do things to create an app user to the database created for use?
<rick_h_> mhall119: given nothing there says why it works locally but not in the stagestack
<mhall119> huh, I didn't know there was a separate user account created by postgresql
<mhall119> oh wait, does it depend on the relation type added?
<mhall119> so, rick_h_, they have 2 instances of my site, one has an added ADMIN_MODE flag set that tells it to run syncdb and migrate and some other db-management stuff, should that node have been given the postgresql:db-admin relation instead of postgresql:db relation?
<rick_h_> mhall119: looking at https://github.com/charms/postgresql/blob/master/hooks/hooks.py#L1110 the roles is pulled from the relation_get('roles'). What does the db-relation-joined hook symlink to? I cant' tell from http://bazaar.launchpad.net/~api-website-devs/ubuntu-api-website/api-website-canonical-is-charm/files/head:/hooks/
<marcoceppi> rick_h_: it was a dep issue, latest build shows it as resolved
<marcoceppi> re charmworldlib
<mhall119> rick_h_: it symlinks to db-relation-changed
<rick_h_> mhall119: no idea as to your question about ADMIN_NODE stuff. I'm just looking at the pgsql charm for the first time myself tbh.
<rick_h_> marcoceppi: yay
<rick_h_> mhall119: hmm, is something setting relation-set roles=$DB_ROLE
<rick_h_> ?
<mhall119> rick_h_: admin_mode is on my charm, it just tells it whether or not to run manage.py commands against the DB when the charm runs
<mhall119> rick_h_: yes, db-relation-changed is setting that now
<rick_h_> mhall119: ok, so that seems a different issue
<rick_h_> mhall119: is that in a fork or something then?
<rick_h_> are they running the right source that sets it?
<mhall119> they have the right source as far as I can tell
<mhall119> I'm thinking now that the admin_mode instance might also be using the regular postgresql:db relation, instead of :db-admin
<rick_h_> well I think a script that assigns roles would need to be a db-admin user in order to run
<mhall119> I've asked for a 'juju status' pastebin in #webops to know
<rick_h_> mhall119: about it not working as is, it seems that the role passed in relation-set needs to be good/valid and I'd question that based on reading https://github.com/charms/postgresql/blob/master/hooks/hooks.py#L1126
<mhall119> what do you mean by good/valid?
<rick_h_> mhall119: all I got though :/
<rick_h_> well what is pgsql expecting to get as a 'role' in there. That roles gets passed to grant_roles function. So that it must be the right name/value for the db to have access to? 
<hatch> nanananana writing-test-man writing-test-man
<rick_h_> hah
<bac> anyone here ever install nagios?
<rick_h_> bac: long time ago we used it at my last job
<bac> rick_h_: where is it on the simple-to-horror scale to get up and running?
<rick_h_> bac: from packages, it's simple to get started. It's horror to manage and use since the UI is awful and so much is scripts/plugin stuff
<hatch> holy smokes that's a lot of loc for some tests
<hatch> 390line diff....yuss I only need one reviewer
<hatch> lol
<rick_h_> hatch: lol
<hatch> hey rick_h_  I appear to have messed something up with my rebase -f in my branch
<hatch> https://github.com/hatched/juju-gui/compare/juju:develop...hatched:local-zip-upload?expand=1
<hatch> it's picked up a previous commit and applying it in this diff
<hatch> any idea how I fix that?
<hatch> create a new branch and apply the hash from the proper one maybe?
<rick_h_> hatch: sec looking
<rick_h_> hatch: so the commit is from your branch?
<hatch> no it's already been merged into develop
<rick_h_> hatch: if it's just in your branch you can always rebase -i HEAD~~~ to tweak it more
<rick_h_> oh
<hatch> somehow it was pulled 'up' or whatever
<rick_h_> sec, I want to figure this out then
<rick_h_> there's supposed to be a way to remove every commit in your branch, update from origin, and then re-layer your commits down again
<rick_h_> and I think that's the way to work with these
<rick_h_> hatch: but yea, I'd just update develop, new branch, cherry-pick your commit you want, and repush
<rick_h_> as far as speed goes
<rick_h_> hatch: try this please
<rick_h_> git checkout develop
<rick_h_> git juju-sync
<rick_h_> git checkout local-zip-upload
<hatch> I don't have juju-sync, I'm just resolving the conflicts in the cherry-pick right now
<rick_h_> git rebase develop
<rick_h_> bah
<rick_h_> well, fine. just git pull juju (or whatever you call it) develop
<rick_h_> and the key is to run in your branch `git rebase develop`
<rick_h_> and see what it does with that
<rick_h_> https://www.atlassian.com/git/tutorial/remote-repositories#!pull
<rick_h_> as well
<rick_h_> git pull --rebase develop maybe?
<hatch> bah, no matter what it keeps pulling in that new one
<hatch> even with a cherry pick of the specific hash
<hatch> hmm
<rick_h_> you broke it
<hatch> damn rebase
<rick_h_> lol
<hatch> oh I think I know how I broke it
<rick_h_> stop doing that then
<hatch> rebase re-stacks commits
<rick_h_> right
<rick_h_> that's the point
<hatch> so when I 'picked' one even though it was older
<rick_h_> you can move commit saround with an interactive rebase
<hatch> it re-applied it
<hatch> instead of leaving it
<rick_h_> huh? pick just means to keep it
<rick_h_> it shouldn't reapply it
<hatch> maybe it does
<hatch> I don't see how else it could have shown up
<rick_h_> no, because you can remove the commit and it should go away
<rick_h_> do you have it in there twice? is that commit in your git log twice?
<rick_h_> with two diff hashes?
<hatch> I think I've got it
<hatch> pushing
<hatch> victory
<rick_h_> did you create a new branch from that existing one?
<rick_h_> instead of from develop?
<hatch> jujugui lf a review https://github.com/juju/juju-gui/pull/86 no qa needed
<rick_h_> looking
<hatch> rick_h_ I updated develop so it's most recent branch wasn't the 'extra' one and then the cherry pick worked without conflicts
<gary_poster> on it hatch
<gary_poster> oh rick_h_has it
<hatch> I think it's about time for lunch
<rick_h_> hatch: yea, it looks like you created the branch from the other feature branch and then did a pull request that contained both changes
<hatch> now to do some Python
<hatch> bring on the semicolons!
<hatch> er.... :P
<gary_poster> semicolons? :-P
<bac> rick_h_: the tickle to run config-changed on mjc stomped all over the cowboyed changes.  that's actually good.  but it wrote out bad data, so my theory seems to be right.
<bac> working with deej to see exactly what they do and how to make it work
<rick_h_> bac: the theory that they're not running the scripts and cowboying things?
<bac> rick_h_: no, that their modified local copy of the charm is not merging in changes we make to the actual charm
<rick_h_> oh ok
<hatch> my cable box goes to channel 41 when I type in 0330
<bac> rick_h_:  sorry i missed deej's last statement.  all good and reconvene on monday?
<rick_h_> bac: sorry, was afk /me looks at history
<rick_h_> 21:44       deej| That's all fixed
<rick_h_> 21:44       deej| The charm's getting updated
<rick_h_> 21:44       deej| It's not getting its new template files though
#juju-gui 2014-01-25
<hatch> jcsackett hey you kickin around?
#juju-gui 2015-01-21
<jcastro> rick_h_, was going to demo the new pages
<jcastro> but like
<jcastro> https://jujucharms.com/u/bigdata-charmers/data-analytics-with-pig-latin/
<jcastro> "add to demo" seems busted there?
<rick_h_> jcastro: :( 
<hatch> ola
<rick_h_> jcastro: the naming of the bundle causes problems for the new stuff to find it in the gui
<jcastro> I was able to demo around it, just wanted to point it out
<rick_h_> hatch: https://pastebin.canonical.com/123888/
<rick_h_> jcastro: yea, if it was pushed to a different branch name it would work
<rick_h_> jcastro: hatch can help point to what it would need to be and maybe correct me since we recently started using the new api if we can update this all together actually
<hatch> ok looking
<hatch> I'm pretty sure that's because it's trying to find the 'old' url
<rick_h_> hatch: right, and it can't
<rick_h_> hatch: so what branch path would it find and can we update to use the new urls?
<rick_h_> jcastro: when is said demo?
<hatch> yeah I think that we still need that old url to be able to deploy using the deployer no?
<hatch> unless using old yaml
<jcastro> this morning on ubuntu-on-air
<jcastro> I already showed it
<rick_h_> hatch: ah right, we've not updated the deployer yet
<rick_h_> jcastro: oh, ok. Sorry then
<jcastro> but in an odd bit of unusualness I checked before the broadcast
<jcastro> so I was able to just not do it without embarrassing us
<hatch> :)
<hatch> good work :)
<rick_h_> jcastro: right, yes, it's not 'busted' just a function of the transition from api v3 to api v4 
<rick_h_> jcastro: and we're not done updating all the things yet
<hatch> yeah - so looks like we can't fix it quite yet
<hatch> :(
<jcastro> yeah I get that
<jcastro> I would still call that busted though. :p
<rick_h_> when you hover it tells you why you can't do it :)
<rick_h_> busted with a nice 'sorry' message :P
<hatch> indeed it does  :)
#juju-gui 2015-01-22
<lazyPower> o/ rick_h_
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1413654
<mup> Bug #1413654: Bundle Export link broken in Juju-Gui 16+ <juju-gui:New> <https://launchpad.net/bugs/1413654>
<rick_h_> lazyPower: :( sorry, will get it looked at asap
<rick_h_> Makyo: ^
<lazyPower> rick_h_:  no worries - its a byproduct of aggressive caching and something going on in the env
<lazyPower> when i completely dumped my browser cache (from day 1) and reloaded the problem resolved itself
<rick_h_> lazyPower: ah ok, so not critical but still :( 
<lazyPower> to note, that GUI unit was upgraded from 16-17 so it might be part of that upgrade process
<rick_h_> lazyPower: ty for the bug report
#juju-gui 2015-01-23
<marcoceppi_> WHOA
<marcoceppi_> I just realized something
<marcoceppi_> no matter where you install the gui, it knows where the bootstrap node is
<marcoceppi_> how does it do that?
<marcoceppi_> rick_h_: the Juju GUI doesn't use apache2 anymore?
<rick_h_> marcoceppi_: no, it's just a python tornado server
<marcoceppi_> rick_h_: also, no matter where you install the gui, it knows where the bootstrap node is. How does it do?
<rick_h_> marcoceppi_: ah right, was looking for that for you earlier but got side tracked in a meeting 
<rick_h_> sec
<marcoceppi_> np, I know you guys are sprinting
<rick_h_> marcoceppi_: think this is it http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L143
<marcoceppi_> rick_h_: oh, sweet, it's an ENV variable
<marcoceppi_> rick_h_: thanks!
<rick_h_> marcoceppi_: np
#juju-gui 2015-01-25
<huwshimi> Morning
#juju-gui 2016-01-26
<arosales> fabrice: jrwren: re https://code.launchpad.net/~marcoceppi/juju-quickstart/recommend-juju/+merge/283745
<arosales> and looking at quickstart as it is today @ https://jujucharms.com/get-started
<arosales> should we also add python-software-properties to recommends?
<arosales> also once the updated packaging is available in juju:stable ppa we should update instructions on this page.
<arosales> this = https://jujucharms.com/get-started
<arosales> marcoceppi: ^ fyi
<jrwren> arosales: there is a catch-22, or dependency cycle there which would mean adding the recommends is a no-op as the python-software-properties from recommends must have already been installed for the add-apt-repository to be used for juju-quickstart to be installed and its dependencies and recommends considered.
<arosales> jrwren: ugh
<jrwren> arosales: :)
<arosales> well I guess that answers that question, but it does sound that post https://code.launchpad.net/~marcoceppi/juju-quickstart/recommend-juju/+merge/283745 being available in juju:stable we can update the install line to just be quickstart
<jrwren> arosales: yes, I agree.
<jrwren> arosales: sounds like ya'll are trying to optimize those install commands?  I know the first command is a noop on all our cloud-images.  add-apt-repository is there OOTB
<jrwren> arosales: and in vivid+ add-apt-repository has an option to do the apt-get update automatically, so on vivid+ it could be `sudo add-apt-repository -u ppa:juju/stable ; sudo apt-get install juju-quickstart`
<arosales> jrwren: ya, working to improve that first user experience
<arosales> jrwren: since this is the client I would have to see what the default desktop behaviour is rather than the cloud image
<arosales> but I think we should go with the least common denonminator
<jrwren> arosales: right. I think LCD is why its 4 commands right now, because it works on precise, trusty, utopic, vivid, wily, xenial
<arosales> what is LCD?
<arosales> jrwren: ^
<jrwren> lowest common denominator
<rick_h_> yes, because lxc uses cloud images 
<rick_h_> so there's the extra step for those bare installs
<arosales> I guess we could have folks using LXC for their client . . .
<jrwren> rick_h_: surprisingly, its the other way around.  desktop image doesn't include the command line tools, because one should be using the gui!
<rick_h_> jrwren: hah
<arosales> seems most folks would be in kvm, vbox, or native
<rick_h_> jrwren: gotcha, I recall the cloud images not having python-software-properties and the like in lxc setups
<arosales> so if I understand correctly only cloud-image use cases need py-software-properties, correct?
<jrwren> arosales: no, its not that simple :(
<jcastro> you kind of always need it
<jcastro> you can't add-apt-repository without it
<jrwren> right, and its not there in some situations. its definitely there in trusty cloud-img
<jcastro> the instructions on the current get-started page look correct, what's the issue?
<arosales> lol jcastro
<jcastro> you can't add it to recommends
<arosales> jcastro: tldr just trying to make the get-started instructions
<jcastro> you wouldn't have access to the juju-quickstart package at all 
<arosales> simple as posslbe
<jcastro> right yeah
<jcastro> we went through this with design
<arosales> re the new mp @ https://code.launchpad.net/~marcoceppi/juju-quickstart/recommend-juju/+merge/283745
<jcastro> the only way to make it simpler is to either ask distro to put p-s-p default everywhere, or update trusty faster
<jcastro> update juju in trusty faster, is what I mean
<arosales> look to see if we could remove software-properties but jrwren educated me on the issues
<arosales> jcastro: agreed on updating those being the fixes, but probably not going to happen before 16.04 with current schedules
<arosales> we'll make this better in juju 2.0, but for now seems we got to live with this extra command
<jcastro> right
<arosales> jrwren: thanks for the info
<jrwren> arosales: you are welcome, sorry it wasn't better answers.
<jcastro> I also tried to get them to fix the copy and paste buttons
<jcastro> but lost that argument
<arosales> its not that bad, but I appreciate the info jrwren 
#juju-gui 2016-01-27
<fabrice> ok back !
<fabrice> I see that stopping everything doesn't change even a small thing
#juju-gui 2016-01-29
<stokachu> is it possible to pull bundle meta/files from a specific revision?
<stokachu> from the charmstore api
<frankban> stokachu: what URL are you using?
<stokachu> frankban: was using theblues library
<stokachu> tried with cs.bundle('data-analytics-with-sql-like-6')
<frankban> stokachu: what's the meta/files endpoint?
<rick_h_> frankban: I showed him the manual calls to the api to get the content 
<stokachu> yea i just wanted to know if i can use a bundle revision with the library
<rick_h_> frankban: I think the thing is the library could use some improvement to check "exists" 
<stokachu> like you can with the charm
<stokachu> for now im using archive_url routine to gives me the proper url
<stokachu> but like rick said it doesn't actually check the charmstore to make sure it's a valid url
<frankban> let me take a look at the code
<jrwren_> a bundle only has 2 files: the bundle yaml,  and README
<stokachu> https://github.com/Ubuntu-Solutions-Engineering/conjure/blob/master/conjurelib/charm.py
<stokachu> to give you an idea of how im using it
<stokachu> the bundle can come in the form of just the name of the bundle or a bundle+rev
<frankban> stokachu: so you want to use met/manifest to get the file list before
<frankban> https://api.jujucharms.com/charmstore/v5/bundle/data-analytics-with-sql-like-6/meta/manifest
<frankban> ???
<stokachu> well i was hoping to just make a single call to the bundle+rev to pull in the default includes with the library
<frankban> stokachu: I am not sure I understood your goal and the problem
<stokachu> oh it works now
<stokachu> maybe i was entering in an unknown revision
<fabrice> stokachu: when you ask for an entity we put the default includes in here https://github.com/juju/theblues/blob/develop/theblues/charmstore.py#L86 but if you want to go through the meta endpoint with that one https://github.com/juju/theblues/blob/develop/theblues/charmstore.py#L73 you will have to provide the includes you want
<stokachu> ah ok 
<frankban> cs.files(self, entity_id, filename='bundle.yaml', read_file=True)?
<stokachu> fabrice, frankban that clears it up
<stokachu> frankban: that's exactly what i was looking for
<fabrice> frankban is always trhe best !
<stokachu> :D
<frankban> fabrice: ok, you'll have a beer in rome
<fabrice> just one ?
<frankban> ONE!
<frankban> and then wine
#juju-gui 2017-01-26
<ryebot> Hey guys, I'm seeing 502 errors whenever I try to `charm attach` a resource. Is something wrong right now, or any idea what I might be doing wrong?
<rick_h> uiteam ^ 
<ryebot> rick_h: ah, sorry, didn't realize you were directing that at me earlier. lame question, but how can I reach them?
<rick_h> ryebot: I'm poking them about it. 
<ryebot> rick_h: oh, awesome, thank you
<rogpeppe> ryebot: have you got the full comand output?
<rogpeppe> ryebot: how big is the resource?
<ryebot> 9.2MB, one sec I'll link you a gist
<ryebot> https://gist.githubusercontent.com/wwwtyro/b8529784d99f7441f02c8b7935fdefdd/raw/282931bf827a4a6638e4b74b3e93ce58eb0ea4e6/gistfile1.txt
<arosales> hmm did we lose rogpeppe ?
<ryebot> arosales: seems like it
<arosales> rick_h: any other folks aware of what may cause "ERROR can't upload resource: cannot post resource: cannot unmarshal error response"
<arosales> blocking some of the k8 development atm :-/
<rick_h> please have them jump in #juju-gui and complain there. 
<arosales> rick_h: we are :-)
<rick_h> arosales: ryebot's been hitting issues and roger is poking at it last I saw
<arosales> that is ryebot 
<ryebot> hello!
<arosales> rick_h: indeed just looks like rog is no longer here
<ryebot> :)
<rick_h> arosales: doh, he's traveling on a train today so guessing he dropped 
<arosales> We can also log a bug a Canonical Ltd, and hold tight there as well. Just wanted to check with folks here since it was holding up some of the k8 dev
<arosales> ryebot: I wonder if you are hitting https://github.com/juju/charmstore-client/issues/96
<ryebot> arosales: yeah, looks like the same 502
<ryebot> arosales: My resource should be small enough (I've uploaded larger), and I am including the version. Hmm.
<arosales> hmmm, indeed. Well I commented on https://github.com/juju/charmstore-client/issues/96
<ryebot> fwiw, Cynerva was able to repro
<arosales> if the uiteam has any sights on the failure, same problem as issue 96, of if we should open a new bug please give us a ping. 
<rogpeppe> ryebot: sorry if you've responded to my questions - my connectivity is terrible currently. probably not worth trying to interact further.
<rogpeppe> ryebot: (i'm in transit)
<ryebot> rogpeppe: np, good luck!
<arosales> rogpeppe: info @ https://github.com/juju/charmstore-client/issues/96
<arosales> rogpeppe: and https://gist.githubusercontent.com/wwwtyro/b8529784d99f7441f02c8b7935fdefdd/raw/282931bf827a4a6638e4b74b3e93ce58eb0ea4e6/gistfile1.txt
<rogpeppe> arosales: ta
<arosales> rogpeppe: thanks for the help
<rogpeppe> arosales: this does seem like the "large attachment" issue
<rogpeppe> arosales: and to fix it we need to support multipart uploads, which is a big change
<arosales> resource = 9.2MB
<ryebot> rogpeppe even at 9.2MB?
<rogpeppe> ryebot: hmm, hopefully not indeed
<rogpeppe> ryebot: unless you've got a slow upload speed
<ryebot> rogpeppe: 6Mbps, not stellar, but enough for larger uploads to work previously
<rogpeppe> ryebot: yeah, should be fine. 30s is when things fall down.
<ryebot> rogpeppe: ah cool good to know, I'm gonna time it
<rogpeppe> ryebot: good idea
<ryebot> rogpeppe: 17s
<arosales> ryebot: could you also add that info to the issue?
<ryebot> arosales: right away
<arosales> upload speed and tine, specifically
<ryebot> arosales: done
<arosales> ryebot: thanks
<ryebot> rogpeppe: arosales figured my problem out, user error
<arosales> ryebot: a solution no less, what was the issue?
<ryebot> arosales: I munged a metadata.yaml file incorrectly and ended up with stale resource definitions
<arosales> ryebot: ah, glad you found the issue
<ryebot> arosales: thanks :)
 * arosales didn't do much but thanks to rick_h and rogpeppe for the replies here
<arosales> ryebot: could you also reply in the issue with your results just for completeness?
#juju-gui 2017-01-27
<ryebot> arosales: ack, done!
<arosales> ryebot: thanks
<ryebot> np!
#juju-gui 2018-01-24
<tychicus> Hi, I have an issue where my controller is stuck in an error loop, I attempted to destroy kibana, elasticsearch, filebeat, packetbeat, and top beat from the juju-gui
<tychicus> the machine-0.log shows an endless stream of the following type of messages
<tychicus> 2018-01-24 16:01:30 ERROR juju.state unit.go:339 cannot delete history for unit "u#filebeat/16#charm": <nil>
<tychicus> followed by
<tychicus> 2018-01-24 16:04:59 ERROR juju.rpc server.go:510 error writing response: write tcp 10.110.0.111:17070->10.110.0.117:34072: write: broken pipe
<tychicus> mongodb is maxing out all available processors, is there anything I can do to get my controller back into a healthy state
