#juju-gui 2013-08-26
<MACscr> ok, so going to be setting up amazon right now, but I plan to actually use for different regions. Is that possible with the gui? Do i just need to change my region in between each change?
<MACscr> er, each deploy
<rick_h> MACscr: you deploy the gui into a bootstrapped environment so which region you use it up to your own juju environment config
<MACscr> rick_h: but i need to use 4 different ones
<rick_h> MACscr: yes, currently. The gui needs to be *in* your environment in order to see what's in there. 
<MACscr> man, juju is not efficient at all
<rick_h> MACscr: so you can use --to to deploy the gui along with another service, or you can start/stop it. 
<rick_h> MACscr: how so? the environments are meant to be isolated and so they are. You can delpoy multiple services on a machine with --to, and you can launch/tear down the gui as you need in each environment. 
<MACscr> i just thought the point of juju was to have a central source to manage and deploy your environments. Now i find out i have to have a separate controller for each cloud (local, maas, amazon, and openstack), then now i have to have 4 more for just amazon
<rick_h> MACscr: well it's using one set of charms and config across them. The same script you use to deploy one thing can work in each cloud. It's 'one' tool. The gui is a helper in that. 
<MACscr> how do i pick what size instance it creates on amazon?
<rick_h> MACscr: using machine constraints https://juju.ubuntu.com/docs/charms-constraints.html
<rick_h> MACscr: the gui is growing support for it deploying with constraints currently (/me is working on it right now actually)
<MACscr> im assuming i can set defaults somewhere though?
<rick_h> yes, it defaults to a small I believe
<MACscr> right, but where can i set it though?
<MACscr> i want to set it to tiny
<rick_h> then you can use the contraints cpu-cores=1 cpu-power=0 and I think it works out to tiny. 
<gary_poster> hi y'all!
<frankban> hi gary_poster, welcome back!
<gary_poster> thanks frankban :-)
<rick_h> gary_poster: howdy stranger
<gary_poster> hey rick_h :-)
<gary_poster> The moment of truth: how many unread emails do I have?  /me waits for Thunderbird to reveal the awful truth...
<rick_h> gary_poster: no way, you didn't check email at all while away?
<rick_h> gary_poster: I hope you purchased a new computer while gone
<gary_poster> rick_h, lol.  I skimmed subjects occasionally.  None of them had a "GUI is on fire" subject line, so I only read the end-of-week summaries.  Otherwise I tried to be pretty strict with myself.
<gary_poster> mm, looks like it is going to be on the order of 2700...
<gary_poster> I'm going to ask for a quick one-on-one catchup from everyone.  I have to take boys to first day of school soon though (in 20 min or so), so won't start for an hour
<rick_h> sounds like a plan
<gary_poster> 2835.  Thunderbird is willing to let me at them now...
<rick_h> see ya thurs gary_poster :)
<gary_poster> rick_h, you out today-wed?
<gary_poster> oh
<rick_h> no, meant the 2800 emails
<gary_poster> I see :-)\
<rick_h> sorry, irc delay
<gary_poster> yeah
 * benji notices that he doesn't have his IRC client running.
 * gary_poster bets benji did that before he reported on it
 * gary_poster takes boys to first day of school
<benji> heh
<rick_h> hatch: when you're around would love to chat on normalizing this constraint representation stuff. 
<sinzui> benji, bac. Do you gentlemen have time to review our bundle work this morning? I have unfinished business with featured, popular, and new bundles that needs discussion
<bac> sinzui, benji: certainly
<bac> sinzui: you want to have a hangout in a bit?
<sinzui> bac, I do. I just left three comments doc
<bac> Who you calling 'doc'?
<sinzui> bac: I think I meant to type "in the gdoc"
 * sinzui finds more coffee.
<sinzui> Excellent news. The power key is not attached to the unity confirmation panels. One small over-reach will power everything off in 2 seconds
<gary_poster> heh
 * gary_poster notes that Francesco's mp needs two reviewers, and then marks the emails as read:  https://codereview.appspot.com/12741051/
<frankban> yes, thanks Gary, guihelp ^^^ anoyone available for reviews + qa of a python branch? 
<gary_poster> hey frankban.  you available for a quick one-on-one in guichat?
<frankban> gary_poster: sure
<gary_poster> ty
<bac> frankban: yes
<frankban> bac: thanks!
<hatch> morning all
<hatch> rick_h: it's already been normalized. you just need to use the service-constraints-viewlet.partial template
<rick_h> hatch: yea, I think I'm in good shape now. I've gotten things adjusted. The whole 'adjust things to Go format' was a lie
<rick_h> hatch: the problem is that there's no clear object/format for constraints (well there's two) and you have to know when to use/build the two
<rick_h> hatch: I was wishing for something that was ConstraintsTemplateFormat ConstraintsDataFormat this morning
<hatch> well the getConstraints method returns the format needed for the template
<rick_h> hatch: right, but that's the *wrong* format for the back end which is where I got tripped up
<hatch> ohh - yet another instance of too many formats for the same data :)
<rick_h> hatch: kinda, and there's no clear names/objects with defined structure to lean on. 
<rick_h> just 'helpers' 
<gary_poster> morning hatch!  ok, who is my next victim...benji, you around for a one-on-one?
<gary_poster> guichat if so
<benji> gary_poster: sure
<gary_poster> thanks benji
<hatch> wb gary_poster!
<gary_poster> thanks hatch :-)
<hatch> kicking off another CI manually, hope it works else I'll have to look deeper
<rick_h> ugh, tests don't use the config-debug or anything do they :/
<hatch> looks like CI is up and running again
<hatch> rick_h: the CI tests do
<rick_h> hatch: yea, was just trying to write up tests for the constraints UI but it's dependant on backend and tried to switch and see how to verify which was used
<rick_h> hatch: ends up defined as DEFAULT_BACKEND, so tests go boom when you switch. 
<rick_h> so maybe I won't try to land this switching the default config. Just raise it as a topic to go through
<hatch> well you can specify the backend when creating your mock app instance
<rick_h> hatch: yea
<rick_h> that's true, maybe I should add a test on each one then. 
<hatch> it's a huge hassle - we should really create a utils method to mock that up
<hatch> creating jujugui instances that is
<hatch> jujugui could I get two reviews on a single line fix and an IE QA plz https://codereview.appspot.com/12942044/
<Makyo> hatch, on it, got the IE bit.
<hatch> thanks, it's trivial so maybe a single review is ok :)
<bac> frankban: doing qa your script has been stuck on "Sending request #10: Next..." for quite a while.  is that to be expected?
<bac> frankban: nm, i was impatient.  it just made progress.
<frankban> bac: yes, it unblocks when the second deployment starts
 * gary_poster has another call now
<rick_h> jujugui 2 reviews and qa please. https://codereview.appspot.com/13224043
<Makyo> rick_h,  on it.
<hatch> ill take one
<rick_h> hatch: do you know if we have any UX directly on the collapsing header/etc? 
<rick_h> hatch: directly/direction
<hatch> rick_h: nope but it would be nice to have the sticky headers with the collapsing headers
<hatch> but collapsing headers are trivial to do
<rick_h> hatch: yea, just something to get the final bits of this 'working' and releaseable
<hatch> did you end up putting constraints on the top like we talked about?
<rick_h> hatch: trying to think if something more accordian (one or the other), collapsing, indicator it *can* collapsce, etc
<rick_h> hatch: yep
<hatch> awesome
<rick_h> hatch: only way to really see/use them atm on charms with any decent config
<hatch> right - I was actually thinking over the weekend that even with collapsing headers, it isn't really discoverable unless you collapse them
<hatch> they could 'start' collapsed though I guess
<rick_h> hatch: yea, that's why I was trying to think on any UX guide on this. 
<rick_h> hatch: because collapsing doesn't get you much really
<rick_h> hatch: I almost wonder if we really need the icons/tab-like view we use in the normal inspector
<rick_h> at least then it's consistent with iconography
<hatch> and easier for discoverability
<rick_h> hatch: yep
<hatch> good idea
<hatch> fire off an email to peeps and luca about it?
<rick_h> hatch: and the wireframes don't really do anything on the ghost-inspector, just 'there is one'
<rick_h> hatch: yea, that'll work. /me forgets email sometimes in the world of immediate irc-ness
<hatch> haha right :)
<hatch> seen that photo of a girl chatting with a guy saying scientists should invent something where people can like talk into their phone and the other people can talk into theirs to reply?
<hatch> lol
<rick_h> lol
<rick_h> I love the one going around recently. bah and now I can't find it
<hatch> ain't that how it happens :)
<benji> sinzui: I'm trying to figure out where the charm version api is; can you point me to it?
 * sinzui asks browser to remember what bac landed
<sinzui> oh, charm, not bundle.
 * sinzui reads routing
<sinzui> benji, this is the url format to get the json for a versioned charm: http://staging.jujucharms.com/~abentley/precise/charmworld-27/json
<sinzui> note the - separating charm name and revision
<benji> sinzui: thanks! 
<hatch> jcsackett: you around?
 * hatch is about to break the 62hour lock by jcsackett
<hatch> going once...
<hatch> twice
<hatch> broken!
<rick_h> hatch: huh?
<hatch> Unable to obtain lock  held by jcsackett@bazaar.launchpad.net on taotie (process #22513), acquired 62 hours, 13 minutes ago.
<_mup_> Bug #22513: during install, in console: fsync failed  <debian-installer (Ubuntu):Invalid> <https://launchpad.net/bugs/22513>
<rick_h> ah
<hatch> that's the second time I've run into that
<hatch> very odd
<hatch> ugh I can't even break it for some reason
<hatch> trying again
<hatch> third time's the charm right
<frankban> Makyo: hi, what's the current status of the go sandbox?
<Makyo> frankban, complete except for perhaps import/export, which I haven't touched.
<hatch> rick_h: oh I bought a new backpack on Friday http://www.thenorthface.com/catalog/ca_ecom/en/sc-gear/equipment-daypacks/router.html should allow me to pack all my stuff in there and not require a checked bag
<frankban> Makyo: cool, but not released, correct?
<Makyo> frankban, I don't believe a release has been made with it, correct.
<frankban> Makyo: thanks, my next charm branch will enable go sandbox support in the charm, and make it the default sandbox mode (i.e. the go sandbox is used even if the environment in which the gui charm is deployed is pyjuju). How does it sound?
<Makyo> frankban, when will that land?  We may want to do a release beforehand so that the user isn't swamped with notifications of errors.
<frankban> Makyo: it is not the charmers charm, it will land the next time we update jujucharms.com, presumably at the end of this week/beginnig of next one
<Makyo> frankban, so long as some gui release of some sort happens between now and then, I'm all for it!
<frankban> Makyo: yes, I'll consider a release a pre-requisite for the deployment
<rick_h> hatch: replies inbound. Did some, not all. reasons listed
<Makyo> frankban, cool, sounds good.
<rick_h> frankban: so I was looking at doing that in my branch as I was working between constraints and such. 
<hatch> jujugui current CI failure an actual code issue with deploying appflower - investigating
<rick_h> frankban: if we do that, I think we should change the default env in env.js and config-debug
<rick_h> frankban: but that breaks some tests which are coded to assume python env
<rick_h> frankban: was going to bring this up on the call today
<rick_h> Makyo: ^^ 
<Makyo> rick_h, oh, hmm
<hatch> rick_h: thanks looks good
<rick_h> hatch: cool
<rick_h> Makyo: yea, I like the idea of switching, but it's a couple of steps that should be coodinated from what I can see
<Makyo> rick_h, yeah, for sure, just like the switch to inspector.
<rick_h> Makyo: yea, the big thing here is failing tests when you switch the default env
<arosales> gary_poster, https://bugs.launchpad.net/juju-gui/+bug/1214821
<_mup_> Bug #1214821: new units added to the canvas overlap old ones <juju-gui:New> <https://launchpad.net/bugs/1214821>
<rick_h> Makyo: in my new tests I did one test for each env and manually build the one I wanted
<arosales> hazmat, ^
<frankban> rick_h: do you think this is a problem for the charm too? I mean, the config is generated by the charm, and my idea was just allowing sandbox=true in juju-core environments, and, when that's set, always change the env to "go" in the generated config.js
<rick_h> frankban: well, I just think if the charm deploys something, we should be testing/deving against it
<rick_h> frankban: so more of a 'good practice' like our deploy/dev environment issue
<hatch> rick_h: don't submit your branch yet plz, current CI issue looks related to the constraints stuff
<frankban> rick_h: that's right, so, is it a tests problem/lack for the go environment in general or just for the go sandbox mode?
<rick_h> hatch: ugh, rgr
<frankban> bac: thanks for reviewing and QAing my branch, I believe QA took some time
<rick_h> frankban: just that the tests default to python env and the tests are coded to that expectation. I didn't chase down the hole far, but changing that default results in 56ish test failures. 
<rick_h> frankban: so if the charm default is go, and we put that in front of users, I'd also like to see us change config-debug and the env default to go. 
<bac> frankban: yes it was slow, but your instructions made it possible
<rick_h> however tests go boom
<hatch> rick_h: https://gist.github.com/hatched/3de377a72e02a6c419a2 when trying to deploy appflower on rapi on trunk
<rick_h> hatch: any hints? e.g. will the fix of the constraints code in this branch help fix the issue? The old branch is generating bad data to the back end
<rick_h> hatch: k, I'll run rapi and see if my branch fixes that then
<hatch> thanks
<frankban> rick_h: could you please file a card for switching the default environment to go and fix tests? If we are lucky, maybe it's only a matter of explicitly specifying what environment to use and where...
<rick_h> frankban: definitely
<frankban> rick_h: thank you
<Makyo> jujugui call in 9 kanban now
<gary_poster> ty
<bcsaller> I have to run someone to the airport in a few minutes, I'm going to have to miss the meeting today, sorry
<gary_poster> hey frankban, would you please remind me to talk to you after the call about whether we can cleanly push GUI server deployer integration into the deployer codebase?  Kapil is keen on doing that, including tests, which would be great by me in order to hopefully reduce our chance of being broken by deployer changes
<hatch> bcsaller: be sure they tip you well
<bcsaller> ha
<gary_poster> bcsaller, ok.  please ping me when you are available.  I'm hoping to have a quick one on one with everyone today
<bcsaller> gary_poster: sounds good, should be back in under 45m
<frankban> gary_poster: sure, sounds good
<gary_poster> cool thanks bcsaller.
<gary_poster> thanks frankban 
<bac> bcsaller: what, you can't drive and use google hangouts on your phone?
 * gary_poster tries to relocate before the call
<rick_h> hatch: I keep getting http://paste.mitechie.com/show/1005/ when I run rapi? Look familiar at all?
<hatch> yeah that's fine
<hatch> that happens around the auth stuff
<Makyo> jujugui call in 2
<rick_h> hatch: new bug :/ http://stackoverflow.com/questions/11300694/chrome-20-websocket-handshake
<hatch> gary_poster: I think i'd like to be part of that onboarding call - sounds like it might help me complete/further one of my allhands tasks
<gary_poster> hatch, ack cool
<sinzui> benji, bac: hangouts died
<sinzui> But with your approval, I am happy to take on featured then maybe new today
<bac> sinzui: are you rejoining us?
<sinzui> trying
<bac> ok
<hatch> gary_poster: Do we still want to show a warning for <IE10 ?
<gary_poster> hatch yes
<hatch> oops
 * hatch reverts
<hatch> :)
<rick_h> hatch: got a fix. Giong to land it with my branch
<hatch> rick_h: awesome thanks!
<hatch> http://connect.microsoft.com/IE/feedback/details/787208/ie10-waiting-for-domains-url-text-occasionally-gets-stuck-on-tabs-title-only-after-refreshing-it
<hatch> UGHHHHHHHHHH
<hatch> closed as won't fix??? how is this not an issue?
<hatch> seriously
<hatch>  /rage
<hatch> now how do I document this so we don't waist time trying to debug it in the future?
<hatch> hmm
<gary_poster> hatch, file a bug and mark as won't fix or invalid or something
<rick_h> +1
<hatch> can do!
<bcsaller> gary_poster: let me know when you are able to catch up
<rick_h> hatch: ok, landed. Giong to fetch food and will look for CI report shortly hopefully.
<rick_h> hatch: thanks for hunting into that!
<arosales> sinzui, do you know if jujucharms.com searching looks at the readme file?
<hatch> rick_h: cool, thanks for fixing it :)
<hatch> jujugui lf two reviews and a IE QA on removing the ie warning https://codereview.appspot.com/13229043/
<rick_h> hatch: looking
<hatch> thanks
<gary_poster> thanks bcsaller.  will ping later.  
<gary_poster> rick_h, gave you #2 LGTM
<gary_poster> bah sorry hatch
<hatch> thanks!
<sinzui> arosales, it does not. Description and summary are the only text that is indexed.
<arosales> sinzui, ok, thanks for the info
<gary_poster> hatch, do you happen to know if the ghost inspector not showing the charm icon is a relatively new regression or something that we simply haven't gotten around to?  I notice that the issue is there in jujucharms.com and comingsoon, so it is likely to be something we haven't noticed/gotten around to
<hatch> gary_poster: we haven't implemented that feature yet
<gary_poster> hatch cool thx
<gary_poster> hatch is it tricky?
<hatch> I'm not sure, I haven't looked into it :)
<hatch> I can thought
<hatch> though*
<rick_h> shouldn't be. I can look at that next since I can't get UX feedback on the constraints today due to holiday
<gary_poster> hatch if you wanna.  I'll make a card for someone
<hatch> ok rick_h can take it so I can do the IE release?
<rick_h> hatch: sounds like a plan to me
<gary_poster> cool thanks
<hatch> rick_h: thought you would find this funny https://plus.google.com/116181126985457119832/posts/XYmPkzu7Cj7
<rick_h> hatch: lol, yea my boy will fetch a minnow from the minnow bucket, but when I caught the pike this weekend he ran to the other end of the dock and watched from there
<hatch> haha awesome
<rick_h> sinzui: ping, got a sec?
<sinzui> hi rick_h 
<rick_h> sinzui: got a quick sec in guichat?
<gary_poster> rick_h, trivial CSS, but we should make ghost inspector fields white
<sinzui> sure rick_h 
<gary_poster> constraints I mean
<rick_h> gary_poster: ok
<rick_h> gary_poster: yea, hoping to do a css cleanup as part of getting things setup/ux cleaned up.
<gary_poster> but make sure that config is still gray/white depending on "default config" toggle
<gary_poster> cool
<gary_poster> rick_h, btw agree with constraints being at top under current circumstances
<gary_poster> hey bac, you available for guichat?
<gary_poster> if not convenient, np!
<rick_h> hatch: yay ci happy
<hatch> yay!
<rick_h> sinzui: are there diff keys for lcy01 vs 02? My key is named lcy01.key
<sinzui> rick_h, they are different
<gary_poster> hey rick_h you available for guichat? :-)  can try someone else if you are on a roll
<rick_h> gary_poster: sure thing
<gary_poster> thanks
<gary_poster> hatch you implemented a version of "replace", right?  (I say "a version" because it has to be rickety given what's available)
<hatch> thinking....
<hatch> thinking....
<hatch> nope the button isn't hooked up
<gary_poster> hatch cool.  Let's replace it with "remove" :-)
<hatch> sounds like a plan to me - want that done for the IE release?
<gary_poster> hatch no, just planning, sorry :-)
<hatch> excellent :)
<gary_poster> benji, sinzui, just to clarify and if this affects your plans, we will plan on having a version of the GUI that talks to version 3 if we use the bundle feature flag, and version 2 otherwise
<benji> gary_poster: that should be fine
<gary_poster> thanks benji
<benji> gary_poster: BTW, it turned out that the charm version task wasn't done, so that's what I'm working on now
<gary_poster> ok cool benji thank you
<gary_poster> bcsaller, you available?  np if you want to wait a bit.
<bcsaller> gary_poster: now is good
<gary_poster> cool, guichat is open bcsaller
<rick_h> sinzui: ping, ok, I can't get in and I don't think I'm supposed to be able to. 
<rick_h> sinzui: got another sec to help me figure out the best way in?
<sinzui> rick_h, really?
 * sinzui tries without orangestack
<rick_h> sinzui: yea, I've updated and gotten a lcy02.key, but I don't see how I can use that to get in. 
<rick_h> since you started it yourself in the ~orange juju environment right? So I think I should have to use the ~orange creds at least. 
<sinzui> rick_h, I can get in without sourcing orange or canoni stacks
<rick_h> sinzui: right, but you created it right?
<sinzui> I did. I used the orangestack env
<hatch> rick_h: https://bugs.launchpad.net/juju-gui/+bug/1217060 any idea what introduced this error?
<_mup_> Bug #1217060: Cannot switch from unit list view to fullscreen browser <juju-gui:Triaged> <https://launchpad.net/bugs/1217060>
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1217062
<_mup_> Bug #1217062: Sidebar won't open from minimized after viewing unit list <juju-gui:Triaged> <https://launchpad.net/bugs/1217062>
<hatch> jujugui there are two blocking bugs for the release in the urgent lane ^
<gary_poster> thanks hatch.  good qa.  rick_h if you have any cycles it looks like you  might be the only expert around today.
<hatch> gary_poster: thanks - just starting on IE for the QA so hopefully those are all the bugs
<bac> benji, sinzui:  could one of you review https://code.launchpad.net/~bac/charmworld/index-charms-in-bundles/+merge/182194 .  it is surprisingly compact.
 * sinzui looks
 * benji is too late.
 * benji gets a soda instead.
<bac> benji: dr pepper?
<benji> heh, nope; Pepsi today
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1217067 another bug from QA
<_mup_> Bug #1217067: fullscreen browser fails to open after viewing unit list in IE10 <ie10> <juju-gui:Triaged> <https://launchpad.net/bugs/1217067>
<sinzui> bac: r=me
<bac> thanks sinzui
<bac> sinzui: could you mark the MP please?
<sinzui> bac, whoa! What did I review and approved then?
<gary_poster> bac you available for a quick one-on-one?
<bac> gary_poster: i am
<sinzui> bac: I /think/ I reviewed and approved it this time.
<gary_poster> bac, cool. guichat when you have a mo
 * sinzui has no idea where the first approved + code went
<rick_h> hatch: looking
<hatch> rick_h: I'm working on bug #1217060 right now
<_mup_> Bug #1217060: Cannot switch from unit list view to fullscreen browser <juju-gui:Triaged> <https://launchpad.net/bugs/1217060>
<hatch> I know the issue but not sure of the best sollution - got a minute for a guichat?
<rick_h> hatch: sure thing
<rick_h> hatch: looks busy
<rick_h> sinzui: you seeing the 503 issues on mjc?
<rick_h> if I hit the urls manual it works
<gary_poster> benji you available for a quick guichat with me and bac?
<benji> sure
<gary_poster> thx
<gary_poster> Makyo, hey.  you available for a quick guichat?  I should stop 12 minutes ago, so hopefully I won't keep you forever :-)
<Makyo> gary_poster, sure, now's best.
<gary_poster> hatch, hey, you have a sec for guichat or are you consumed?
<hatch> sure
<gary_poster> thanks
 * bac -> walk dog
<hatch> do North American phones work in the UK?
<hatch> I am thinking of picking up an HTC One tomorrow but not much point if it won't work :)
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> rick_h:  any chance you are around? I have come up with a simpler sollution to this issue
#juju-gui 2013-08-27
<rick_h> hatch: kinda, fish tank cleaning
<rick_h> while we were chatting my son dumped all the fish food into the tank
<rick_h> emergency cleaning in progress :/
<rick_h> hatch: what solution is this? 
<hatch> lol, well it's pretty trivial tbh heh https://gist.github.com/hatched/2dd9628d46be512cc753
<hatch> ^ rick_h but it comes with an odd bug, if I click 'browse' after viewing the inspector it shows the sidebar opened with only the categories....not the fullscreen
<rick_h> looking
<rick_h> yae, not sure what it's doing. Will have to debug the viewState and see what's getting set
<rick_h> this seems strange imo
<rick_h> we don't need the 67-70 stuff I thought, just left over from debuggin?
<hatch> had to add it back in because it wasn't being set properly
<rick_h> ah, if things are minimized, the old viewmode is never set to _XXXX 
<rick_h> makes sense
<rick_h> yea, die hidden stuff die
<hatch> I'm glad you understand it because I sure don't heh
<hatch> so can i push this up and then email it you to to take over in the am?
<rick_h> well, if we're updating the viewState to sidebar, then the next request we try to remove _sidebar.destroy()
<rick_h> but we never set this._sidebar because it was hidden
<rick_h> hatch: sure thing, I think I understand the issues enough to get it going. 
<hatch> ok great - I really want to use every available hour to try and get this release out tomorrow and there are still the two other bugs
<hatch> thanks - I'll push and email to you
<rick_h> hatch: rgr
<rick_h> luca__: morning, so with your email, the goal is to setup an collapsable accordian effect then? With the three headings always visible and the content of them scrollable?
<luca__> morning rick_h 
<luca__> sort of, Jeff knows what we are after, are you working on it now or can you wait to talk to him?
<luca__> rick_h: because he did it wrong to start with and Gary got a bit annoyed over the wasted effort
<rick_h> luca__: we can wait. not a problem. I'll be getting back to it soon (late today/tomorrow?) and wanted to clarify what the goals were. 
<rick_h> luca__: ah, this is the sticky header business?
<luca__> rick_h: yes :)
<rick_h> luca__: nvm, I got it then. I took a stab at it at one point so I gotcha. 
<frankban> hey hazmat: when you have time, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ? 
<rick_h> jujugui small review please for when people get in and need something to read with their coffee https://codereview.appspot.com/13276043/
<gary_poster> rick_h, did you resolve with Jeff or Ben why it used to be a databinding?  The ony value I can see to the databinding is if the charm is updated and the icon changes, I guess?
<rick_h> gary_poster: the issue before was that there wasn't the store doing icon stuff and I think it started out hoping we could generate the paths/logic in there
<rick_h> gary_poster: but no, I didn't check on why databinding. I remeber talking with bcsaller when he added it and it was a 'show something' because the store integration wasn't ready yet
<gary_poster> ok cool.  if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here
<rick_h> gary_poster: yea, I was going to do data binding thinking it was a case of "if the user opens another charm we can reuse the rendered html and update the data displayed with data binding"
<rick_h> however, the *only* attribute data bound was the icon
<rick_h> so I think it was a case of 'let's just hack this in' gone wild :)
<gary_poster> lol
<gary_poster> oh so that code is *only* for the ghost?  the post-deploy is different code?
<rick_h> gary_poster: no, I think that it's shared. However, the post-deploy can generate the icon the same way
<rick_h> or I just broke the normal way...so take that review request back :/
<gary_poster> rick_h, I dunno, I could go either way.  I assumed it was shared when I said "if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here."  OTOH if you are fairly convinced of the win for the post-deploy scenario, I'll leave you to it
<rick_h> gary_poster: yea, so I'm not sure how it fits atm. Basically I've found that from the store the charm model has a charmId field to generate the icon. 
<rick_h> from the already deployed charm that attribute isn't in the model there. 
<rick_h> however, charmUrl is in both, and that works to generate the right icon url
<rick_h> gary_poster: so working on adding a test to both cases so that if this breaks it shows up
<rick_h> gary_poster: e.g. I broke the icon in the non-ghost case and so adding a test to say it's fixed. 
<gary_poster> rick_h, ok cool.  I'll leave the branch alone for now then.
<rick_h> gary_poster: got it figured out. Missed the service vs charm model case handling in there. Updated with an extra test to catch. 
<gary_poster> cool rick_h, looking again
<luca__> Morning gary_poster, welcome back
<abentley> sinzui: Could we do a catch-up chat this morning?
<abentley> bac: in r362, it looks like you've changed use_context so that __exit__ is run even if __enter__ fails.  Is that intentional?
<gary_poster> hey luca__, thank you :-)
<bac> abentley: it was my intent to register the cleanup early but didn't take into consideration what happens if __enter__ failed.
<abentley> bac: Why did you want to do that?
<bac> abentley: i was working on the problem that adeuring now has with spurious test failures and it looked like the test index was not properly being cleaned up
<sinzui> abentley, sure. I can telling about how charmworld tip is incompatible with 2 migrations and It is time to upgrade pyelasticsearch
<abentley> bac: Ah.  I think we should change it back, though.  It was registering the cleanup as soon as it was safe to do so.
<bac> abentley: i can do that in my current branch
<abentley> sinzui: Now?
<sinzui> abentley, sure
<gary_poster> hey luca__ I just got to your "Juju business assumptions" email.  I'm guessing I should not bother to reply since the deadline is long past now? :-)
<luca__> gary_poster: Heya, no need now, but thanks anyway :D
<gary_poster> luca__, cool :-)
<sinzui> bac, benji, rick_h, The charmworld deployment failed because r363+ is incompatible with two migrations in earlier revisions
<rick_h> hatch: when you're around have a fix for the issue from yesterday. http://paste.mitechie.com/show/1007/ is the diff and lp:~rharding/juju-gui/browser-fix-1217060 is the branch. Adding some tests and will have it up for review later. 
<benji> darn
<rick_h> hatch: then I'll be taking a strong bath for the evils committed
<rick_h> sinzui: :(
<sinzui> I will ask for 3 deployments today to deploy each migration at the point it has code.
<sinzui> that was compatible
<rick_h> migrations are fun! :)
<sinzui> well maybe to because I think one migration was a correction for m16
<benji> we should think about how to avoid this problem in the future
<rick_h> sinzui: time to rollup and redeploy on -core? :)
<sinzui> Not today
<gary_poster> right, benji.  one approach is that we should treat a migration file as a migration in production, and devs have to deal with figuring out how to test re-migrations
<gary_poster> that seems simplest to me, and every other idea I have is a more complex approach for questionable benefit
<benji> gary_poster: I'm trying to remember how we ended up dealing with migrations (or "generations" back then) in the Z4M project.  We ended up in a place that worked really well, but I'll have to remember the details.
<gary_poster> benji, IIRC it was the open source zope generations.  the trick was that ZODB would remember the generation it had, and then run through *all* generations
<gary_poster> from last run to current
<gary_poster> but that is still potentially riskier in a DB/env not as flexible as ZODB
<gary_poster> reasonable but not sufficient, I'd suggest, IOW
<benji> that might be how the mechanism worked, but we came up with a set of procedures that actually avoided most of the mechanism but still worked well; it'll take a while for me to remember
<gary_poster> ok
<hatch> rick_h: ahh you went with the controls binding approach
<rick_h> hatch: yea, I think that contains the 'evil' the most
<rick_h> hatch: I didn't follow where you were headed with the removing of the whole check entirely and such tbh
<hatch> ohh, all I was doing was minimizing the sidebar when the user opened the full inspector
<rick_h> hatch: yea, but then you still have the button to un-minimize visible and such
<hatch> so the check was no longer needed becasue the browser was still on top of the inspector
<rick_h> hatch: so there's UX conflict
<gary_poster> benji could you add Friday card about topic pls?
<hatch> shhhh
<hatch> they wouldn't know
<rick_h> jujugui for the later morning coffee crowd, some light reading https://codereview.appspot.com/13276043/
<gary_poster> rick_h, ugh, I got lost
<rick_h> gary_poster: I'm sory you get lost? 
<gary_poster> give review to someone else rick_h 
<rick_h> ah, you mean review stuff. All good. 
<rick_h> gary_poster: yea, I'll but the western peeps :)
<gary_poster> cool
<rick_h> or jcsackettcif he's aroud today
<rick_h> grrr mobile internet lag
<hatch> rick_h: i'll take one of the reviews
<rick_h> hatch: ty much
<rick_h> hatch: note this is a diff card than the one we've been going over. 
<rick_h> just fyi to avoid crossing the streams
<benji> gary_poster: card added
<gary_poster> thx
<hatch> morning antdillon
<antdillon> Morning hatch
<bac> mark uds keynote talking about cloud-ish now.  http://summit.ubuntu.com/uds-1308/meeting/21887/intro-and-keynote/
<hatch> thx
<hatch> hey it's the GUI!
<sinzui> bac, benji, your revisions are now in production. I think we want a branch to remove the migrations since we know they are not all compatible with tip
<benji> yeah, I think so
<benji> sinzui: I'll make a card
<Makyo> "our less-fortunate brethren" Hah.
<hatch> haha yeah I laughed
<hatch> antdillon: do you have any idea what cellular frequencies are available there?
<hatch> my google fu is returning conflicting details
<antdillon> hatch, GSM 900 or 1800 
<antdillon> hatch, http://www.ofcom.org.uk/static/archive/ra/topics/pmc/document/licencetypes/cellularinfo.htm#4
<hatch> ahh nice the HTC One's in Canada have 850/900/1800/1900 GSM
<rick_h> antdillon: is this rumor of sims in vending machines at the airport true?
<rick_h> antdillon: it seems like a candy land of mobile connectivity
<antdillon> rick_h, Almost, there is all way a booth selling sim cards
<hatch> awww right on
<hatch> guess I'll be going to get the new phone at lunch and unlocking at night haha
<antdillon> rick_h, Or giving them away as long as you put some credit it on it
<rick_h> antdillon: cool, yea I'll have a gsm mifi that'll need some sim love 
<rick_h> since I don't have a GSM phone :( 
<rick_h> stupid verizon
 * hatch steals the wifi from rick_h
<rick_h> hatch: sure thing. It's what I did before. Wifi'd my phone to the mifi and used it to get directions to dinner!
<antdillon> I can see some wifi wars coming up
<rick_h> hah
<hatch> haha nice!
<hatch> I'm going to get the HTC One because there are awesome Android 4.3 roms for it, ANNND Ubuntu Touch port :D
<rick_h> cool, I'm still holding out for nexus 5. I'm not due up for a couple more months. 
<rick_h> but then I'll be switching to t-mobile and I'll have gsm 
<rick_h> so less of an issue with this traveling
<bac> hatch: i recall last time i was there one of the good deals on pre-paid sims was at tesco, the grocery chain
<hatch> rick_h: yeah I'm sick of waiting, which means a new better phone will come out next week
<hatch> lol
<rick_h> bac: when I tested out the mifi here on ATT to make sure it worked it cost me $30 for 300mb good for 7 days. I've got low expectations. 
<bac> benji: would you have time to look at https://code.launchpad.net/~bac/charmworld/link-to-basket-on-lp/+merge/182415
<benji> bac: sure
<rick_h> bac: in copenhagen I got 1gb of data for 12months for $13
<hatch> hahaha
<bac> rick_h: yeah, we are ripped off and don't realize it
<rick_h> bac: oh we realize it, but lack of options
<bac> rick_h: in VN i could go 3 weeks with heavy data use (i get lost a lot) on a $2.50 top-off
<benji> bac: your branch looks good
<bac> thanks benji
<rick_h> jujugui and hatch in particular, review #2 please for giant hacky bug. Please look away while reading. https://codereview.appspot.com/13282043/
<rick_h> and time to head back from the coffee shop, back in a minute
<hatch> thanks rick_h
<rick_h> Makyo: thanks for the review. Do you have time to look at smaller/more sane other one? https://codereview.appspot.com/13276043/
<Makyo>  rick_h sure
<rick_h> thanks Makyo, appreciate it
<hatch> jujugui guichat in 10
<rick_h> jujugui and the charmworld folks, might be interseted in https://pypi.python.org/pypi/nose-selecttests/0.4
<gary_poster> looks nice.  funny that functionality is not part of nose generally, but yay for plugins I guess
<hatch> rick_h: after your branches land can you let me know so I can re-qa the remaining two bugs in Urgent to see if those fixes fix those bugs
<hazmat> gary_poster, nostalgic for zope.testrunner ? ;-)
<rick_h> hatch: rgr
<gary_poster> hazmat, exactly :-)
<hatch> jujugui guichat in 2min
<gary_poster> frankban, you around for call?
<jcsackett> jujugui: i appear to be the only one on the call...did the appointment hangout get borked, as i can't imagine that's right.
<gary_poster> jcsackett, try guichat
<jcsackett> gary_poster: oh, duh. of course.
<jcsackett> thanks.
<gary_poster> np
<jcsackett> <--- needs more coffee
<bac> jcsackett: i think the link in the calendar is broken
<jcsackett> bac: yeah, it is. i don't know why i was trying to use it instead of guichat.
<frankban> rick_h: https://codereview.appspot.com/12741051
<frankban> thank you
<rick_h> frankban: thanks
<abentley> adeuring: We may want to change our pattern so that instead of creating an index and then putting the mapping, we supply the mapping at index creation time: http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index/
<adeuring> abentley: ah, very intersting. Let me try that. It would most likely fix a problem with temp_index_client()
<abentley> adeuring: Doing a refresh may also give us a way to wait until the index is present: http://www.elasticsearch.org/guide/reference/api/admin-indices-refresh/
<adeuring> right
<hatch> rick_h: the branch fixed the two outstanding urgent bugs
 * hatch goes back to QA'ing
<rick_h> hatch: woot!
<rick_h> hatch: had hoped so. 
<hatch> must have been the state update and some odd race condition
<rick_h> hatch: I think it was the same thing. The viewmode controls weren't bound right in the non-browser state
<gary_poster> Inbox zero!  kinda sorta.  I have a few emails tagged I have to deal with.  But anyway, I'm taking a lunch break in celebration.
<rick_h> woot! only two days, email master!
<hatch> rick_h: found another bug
<rick_h> hatch: stop doing that
<hatch> rick_h: haha sorry :) https://bugs.launchpad.net/juju-gui/+bug/1217449
<_mup_> Bug #1217449: Sidebar won't minimize after viewing unit list <juju-gui:Triaged> <https://launchpad.net/bugs/1217449>
<hatch> can you look at it now?
<rick_h> hatch: reviewing right now, can afterwards
<hatch> ok assigning to you
<rick_h> rgr
<frankban> guihelp: anyone available for reviewing a js branch? https://codereview.appspot.com/13286043 This should land asap, before further env/ws tests are added.
<hatch> frankban: I'll take one if no one else does (just want to finish this QA pass)
<frankban> hatch: thank you
<hatch> rick_h: probably related https://bugs.launchpad.net/juju-gui/+bug/1217450
<_mup_> Bug #1217450: Browse button shows empty sidebar after clicking Juju logo <juju-gui:Triaged> <https://launchpad.net/bugs/1217450>
<rick_h> frankban: looking
<frankban> rick_h: thanks
<hatch> frankban: do we have tests for the Go portion of these tests which you set the default to be 'python' ?
<frankban> hatch: yes, I believe so, everything is more directly tested in the test_env_* files.
<hatch> great
<frankban> hatch: re (actual, expected), is it a JS guideline?
<hatch> frankban: it's the syntax for the nodejs assertion library
<hatch> http://nodejs.org/api/assert.html
<hatch> for the full api
<hatch> it doesn't cause any issues, just creates confusing error messages when the tests fail :)
<frankban> hatch: interesting, I am used to expected first, and I am pretty sure I always did that in all my js branches :-) the error messages are usually confused by default, especially when you use deepEqual :-)
<hatch> oh I know...I also think that expected should be first
<hatch> that's why I left the decision to switch it to you :D
<frankban> thanks hatch, perhaps we can clean up this stuff later with a mechanical branch
<hatch> sure thing
<hatch> rick_h: I'm taking off for an early lunch I believe the two tickets in urgent are related
<hatch> but I*
<rick_h>  hatch yea, looking at them now
<hatch> great thanks a lot!
<hatch> bbl
<benji> abentley: do you have a few minutes to review my "respect charm versions in APIv3" branch? https://code.launchpad.net/~benji/charmworld/versioned-charm-api/+merge/182450
<abentley> benji: looking...
<hatch> rick_h: back
<hatch> need any help with that stuff now?
<rick_h> hatch: no, think I've got it. Just sanity checking and debating on testing/etc
<rick_h> hatch: fixes both of them
<hatch> awesome thanks
 * hatch picked up the HTC One
<hatch> chose a new store this time and was in and out in 10mins
<rick_h> hatch: very cool, jealous. You'll have to let me check in out next week ;)
<hatch> yep, now I'm stuck in a 3 year
<hatch> haha
<rick_h> 3yr?! ouch!
<rick_h> I get ancy before 2yrs
<hatch> it's not like i'm going to go with another provider so it's just picking the option that made the phone the cheapest
<hatch> it was $100
<hatch> I'm pumped that I am able to disable apps now
<hatch> bye bye Facebook
<hatch> although after I get back it'll likely be getting a rom anyways
<rick_h> hatch: I've got one issue I'm not able to see wtf atm
<rick_h> hatch: got a second?
<hatch> yup
<hatch> in guichat
<hatch> rick_h: about to test
<hatch> sorry make hung
<rick_h> hatch: ok, I've got a couple test failures from it working out
<hatch> rick_h: I got it to fail but then if I let it sit, the gui portion goes away
<hatch> lol
<hatch> it's like a few second delay
<rick_h> *UGH*
<rick_h> hatch: make sure to clear cache and such
<rick_h> I don't know...just trying to find some excuse it could be something else
<hatch> now I can't repro :/
<hatch> repro'd
<hatch> now how...
<hatch> it's like there is a race condition
<hatch> sometimes I can see a 'flash' of the inspector as the sidebar comes up
<rick_h> hatch: k, well hack inbound. Give me a few min
<hatch> alright thanks
<abentley> benji: sorry for the delay.  Was ambushed by a UDS session.
<benji> CRIKEY! Isn't she a beauty?!
 * benji watches abently wrestle with the wild UDS session.
<rick_h> hatch: guichat?
<hatch> there
<hatch> rick_h:  :(
<hatch> dbl click > Build > Juju (...and repeat) still happens
<hatch> rick_h: does that not have an issue for you still?
<rick_h> hatch: looking
<hatch> the dbl click is on the service of course
<rick_h> hatch: ok, something is setting renderEnvironment to false. Looking
<rick_h> hatch: ok, so when I navigate with clearAllNameSpaces, it's hitting back into the toggleStaticViews with a url :gui;/service...
<rick_h> then I get the message 'waiting on service data' and that causes anothewr dispatch to go through that clears it
<rick_h> hatch: so my navigate() command isn't 'die gui die' enough
<hatch> lol
<rick_h> hatch: so how would I generate a _navigate that manually set :gui:/
<rick_h> vs :gui:/service...
<rick_h> ?
<hatch> there is a url method on the nsrouter
<hatch> which you pass a config object to
<hatch> and it generates a url for you
<hatch> see line 1307 in app.js as an example
<rick_h> looking
<abentley> benji: "Featured bundle UI" looks redundant with "User innterface to (un)set a bundle as featured".
<benji> abentley: it does, are those card titles?
<abentley> benji: Yes.
<abentley> benji: You're assigned to one, but not the other.
<benji> abentley: will you kill one of them for me?
<rick_h> hatch: I don't get this...I navigate to a fresh url but the url in req.url in toggleStaticViews is still :gui:/service...
<abentley> benji: Done.
<benji> thanks
<abentley> sinzui: Do you know what "charmworld should serve README in same pattern as charm" means?
<hatch> rick_h: so the url in the address bar is empty?
<hatch> minus the hostname
<rick_h> hatch: no, it's got :gui:/service/mongodb
<sinzui> abentley, not immediately
<hatch> oh ok, so then that makes sense?
<sinzui> abentley, and not after a few moments of thought
<rick_h> hatch: no, so I run this.navigate(new_url);
<rick_h> hatch: and in the views the url is the old url
<abentley> bac: What does your card "charmworld should serve README in same pattern as charm" mean?
<rick_h> hatch: guichat again? sorry
<hatch> sure
<sinzui> abentley, bundles need a readme, and the cw page should render it?
<bac> abentley: better?  "(nice to have) charmworld should serve README for bundle in same manner as for charms"
<abentley> bac: Much better.  I didn't understand that it was about bundles.
<bac> abentley: i am going to mark it blocked on my current branch, though
<abentley> bac: Okay.
<hatch> bcsaller: kickin around?
<bcsaller> hatch: yeah
<bcsaller> whats up?
<hatch> mind poping into guichat?
<hatch> with rick and i
<benji> abentley: thanks for the good review; I've made all the requested changes -- I think ;)
<abentley> benji: looking...
<hatch> bcsaller: rick_h gg :P
<rick_h> hatch: heh, let me know how far you get. I can finish up/clean up in the morning. A simple test on the initState should work to make sure it's cleaning 
<rick_h> hatch: that's really the only *change* that's needed is that stupid initState method 
<hatch> haha right
<rick_h> I'm outta here...
<hatch> I'll send you an email with as far as I get
<hatch> have a good night
<rick_h> hatch: sorry to delay the release :(
 * hatch shakes fist
<hatch> lol np
<rick_h> hatch: or feel free to leave it, Probably not getting 2 reviewd and such to release today anyway
<rick_h> I'll have it up ready to go before you start tomorrow
<hatch> oh ok can do that too
<hatch> I can move onto other things
<hatch> ok so I'll leave it then
<rick_h> yea, up to you. I know I'm blocking you and don't want to, but not sure how much you'll get anyway :/
<rick_h> cool, thanks for the help/talk throughs
<sinzui> bac: your revisions are on staging
#juju-gui 2013-08-28
<rick_h> hatch: fyi https://codereview.appspot.com/13242046
<hatch> rick_h: u rock
<hatch> odly enough I didn't get an email about this
<rick_h> you probably did but at first it had no title since it was WIP
<rick_h> the update just came through hopefully
<rick_h> ok, I'm toast for the night. See you tomorrow. 
<hatch> thanks! have a good night
<TheMue> frankban: ping
<frankban> TheMue: pong
<TheMue> frankban: morning
<frankban> hi TheMue 
<TheMue> frankban: i'm currently working on https://bugs.launchpad.net/juju-core/+bug/1194945
<_mup_> Bug #1194945: juju set is overloaded <juju-core:In Progress by themue> <https://launchpad.net/bugs/1194945>
<TheMue> frankban: so on command line service options can be unset with "juju unset mysvc foo"
<TheMue> frankban: and an empty string is allowed for sting options "juju set mysvc foo="
<TheMue> frankban: this leads to internal changes
<TheMue> frankban: and in https://codereview.appspot.com/12867044/diff/5001/state/statecmd/config_test.go fwereade_ reminds me that it may influence the GUI
<frankban> TheMue: taking a look
<frankban> TheMue: so, with unset you restore a default value (as it is found in config.yaml). with set option="" you explicitly set an empty string, right?
<TheMue> frankban: with that change unsetting an option with passing an empty string won't work anymore
<TheMue> frankban: exactly
<TheMue> frankban: and if the option is int, float or bool this would return an error
<frankban> TheMue: how does this influence the behavior of the ServiceSet and ServiceUpdate API calls?
<TheMue> frankban: have to take a look
<TheMue> frankban: as far as i can see right now the setting mechanism works as before. only the implicit unsetting by setting the value of a setting (wow, how many settings ;) ) to "" won't work 
<TheMue> frankban: so the API may need a ServiceUnset too
<TheMue> frankban: does the GUI uses the setting to "" for unsetting to default? or does it "only" provides settings to new values?
<frankban> TheMue: maybe I am wrong, but doens't it already work passing nil values to ServiceSet? 
<TheMue> frankban: sadly not. it's a map[string]string, so "settings["foo"] = nil" is not possible, the value has to be a string.
<frankban> TheMue: OIC, and I double checked we effectively pass values as strings in the API call. From a quick look at the code, I believe we already have a problem with the config (I suspect we pass "null" or something like that when the stripped value is empty, I need to test this). anyway, I guess we will need a UX for differentiating between the "set to empty" and "restore the default" behaviors. and yes, we might want
<frankban>  to implement a ServiceUnset API eventually, (or, just a crazy idea, perhaps change the ServiceSet to be map[string]*string?).
<TheMue> frankban: here I would prefer the ServiceUnset, it would be more explicit
<frankban> TheMue: I'll discuss this with gary_poster when he becomes available, thank you for the heads up
<TheMue> frankban: how is setting to default handled from the users perspective? a button or flag? or the implicit knowledge that setting to an empty value unsets it?
<TheMue> frankban: you have to thank william ;)
<frankban> TheMue: AFAICT we just have input and check boxes. So I guess we don't have a story to restore boolean values to default, and for inputs/textareas we implicitly do that by setting an empty string (but I need to check). That's why I mentioned we need a UX story for the "restore defaults" semantic.
<TheMue> frankban: would be cool, indeed
<frankban> TheMue: ah! what happens when you unset the value? is it just deleted from the db or is the db field set to the charm default value?
<frankban> TheMue: I am asking because I am curious about what we can expect to receive back from the megawatcher when you unset a config field
<TheMue> frankban: how simple/complex is it to install the GUI on a local provider environment? i give a talk about juju end of October and would like to present the GUI there too.
<TheMue> frankban: unsetting deletes the setting
<frankban> TheMue: ok
<TheMue> frankban: will add this to the release notes today
<frankban> TheMue: the deploy story for the GUI is a juju charm, so it should be straightforward to deploy the GUI in a juju-core lxc env. However, never tried the local provider. If for some reason it does not work, then that's something we have to fix.
<TheMue> frankban: ok, will check it
<rick_h> jujugui anyone around for a second JS review of https://codereview.appspot.com/13242046/ to unblock the IE release from hatch 
<rick_h> frankban: that branch up for review is the card in coding in bundles?
<frankban> rick_h: I can take a quick look before lunch if QA is not required
<frankban> rick_h: yes, I'll move it
<rick_h> frankban: hatch qa'd it already so I think it'd be safe to review sans-qa
<rick_h> frankban: cool, will review the charm one and qa it when I get back from dropping the boy off at day care. I should be able to qa it with -core in lxc right?
<frankban> cool rick_h, never tried the local provider (I am usually on ec2), but it's worth trying
<rick_h> frankban: cool yea. <3'ing lxc provider for speed/testing
<rick_h> frankban: gary wants me to get up to speed on the charm so will be fun to poke at. 
<frankban> rick_h: cool
<frankban> rick_h: feel free to ping me if you need any help with the charm/guiserver code
<rick_h> frankban: will do, thanks. 
<frankban> rick_h: review done
 * frankban lunches
<gary_poster> hey bac.  thank you for adding branch to bundle info.  were you planning on adding that to API as well?  I think it would be nice to have there.
<bac> good point gary_poster
<frankban> gary_poster: do we have a story for restoring default config values from the GUI? TheMue reported that the juju-core internals are changing: an empty string no longer means "restore default"
<gary_poster> Thanks bac.  Another question for you.  In https://code.launchpad.net/~abentley/charms/bundles/wiki-bundle/bundle, we have three instances of the "bundle" string.  Am I right that we can at least get rid of the "-bundle" or is that important for preventing some kind of name conflict?
<bac> gary_poster: that portion "wiki-bundle" is user-chosen
<bac>  s/wiki-bundle/gary/
<rick_h> man, that N4 at $199 is screaming "take me to london"
<gary_poster> frankban, interesting.  Potentially connected to https://bugs.launchpad.net/juju-gui/+bug/1214087 (see comment 3) in terms of further complicating the picture.  Investigating.
<_mup_> Bug #1214087: GUI fails to deploy keystone <juju-gui:New> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1214087>
<gary_poster> bac, right, but "wiki-bundle" is a project name, right?
<gary_poster> bac, so mediawiki would be a project
<gary_poster> which could have bundles and charms?
<gary_poster> that seems fine to me, but I wanted to make sure that you all had not identified some concern for overlap
<bac> gary_poster: that name is the "basket" name, the name of the deployer file.  it can contain multiple bundles
<gary_poster> bac, yes, but doesn't that correspond to a project?  I mean...let me get a concrete example
<gary_poster> bac, so given https://code.launchpad.net/~charmers/charms/precise/mediawiki/trunk
<gary_poster> huh...it is not listed in https://launchpad.net/charms/precise/+source/mediawiki
<gary_poster> or https://launchpad.net/charms/+source/mediawiki
<gary_poster> but still it could be
<gary_poster> "mediawiki" is a package
<gary_poster> so
<gary_poster> https://code.launchpad.net/~charmers/charms/bundles/mediawiki/bundle
<gary_poster> is a bundle for the same "mediawiki" package
<gary_poster> right?
<frankban> gary_poster: maybe, even if that seems more related to a check in the Keystone charm. I don't think the new behavior is already merged. But with that landed, unsetting a config passing an empty string will no longer work, and if you do that with int/float or bool config options, an error will be returned
<rick_h> benji: rocks! http://askubuntu.com/questions/108689/how-can-i-get-tab-completion-with-juju-in-zsh
<benji> :)
<rick_h> benji: I was thinking of writing one that parsed the results of `juju help commands`
<rick_h> benji: is there a good reason to not do that before I get started?
<rick_h> ooh, I'll have to MP that with switch added in
<gary_poster> frankban we have no GUI approach for resetting values to my knowledge.  That only happens in the ghost config controls.  I think we are ok for now, though we may well want an explicit way of controlling this in the future
<benji> rick_h: that's what that script does
<benji> see http://bazaar.launchpad.net/~benji/+junk/zsh-juju-completion/view/head:/make-completion.py
<bac> gary_poster: yes, if that is how the devop chooses to name the basket.  i hope this doesn't sound obtuse.  if so, maybe we should talk.
<benji> it was written against PyJuju though, so it could probably use some updating
<rick_h> benji: ah, I was thinking of the _arguments doing that in shell 
<rick_h> benji: gotcha, cool. Thanks. Most helpful.
<frankban> gary_poster: sounds good
<gary_poster> cool thanks frankban
<gary_poster> bac, but the two identical package names (for charm and bundle) should be considered to be related, yeah?
<gary_poster> bac or do you consider the underlying LP concepts to be irrelevant?
<benji> if we are going to be doing much with the CLI, I'd like to generate shell completion in a way inspired by how bzr does it; i.e., there is a subcommand that returns an easily parsable description of all the commands, options, etc.
<rick_h> benji: ah, that's cool
<rick_h> benji: yea, need some zsh subcommand completion awesomeness in there
<rick_h> benji: completing service names to destroy and such would be awesome
<bac> gary_poster: perhaps we can infer relevancy for the official/promulgated ones, if the ~charmers enforce a naming structure.  otherwise, it is user-provided naming and therefore i don't think relevant.
<benji> yep; I'm not sure how best to do it though, caching would seem manditory
<rick_h> benji: yea :/ though for a first pass can wait
<bac> rick_h, benji: did you see allenap's shell script for autocompleting project names within a go environment?  it's pretty nice.
<sinzui> gary_poster, bac, I see i walked into the middle of a conversation. charm/bundle/package names are arbitrary. Convention says they are related. They have changed and that caused confusion in the past
<benji> bac: nope, I havn't.  Sounds cool.
<rick_h> bac: I use a forked/butchered workon script from doug hellman https://github.com/mitechie/workit to project hop
<rick_h> bac: sounds similar?
<gary_poster> bac ok fair enough, thanks.  I'm writing a summary email of some of the stuff we discussed earlier this week, so I'm trying to get the details right.  In that vein, I'm almost done with the email, but I have one other related question.  In https://code.launchpad.net/~abentley/charms/bundles/wiki-bundle/bundle, the last "bundle" could be migrated to "trunk" trivially, once we are ready to go live with a new version o
<gary_poster> f charmworld, right?
<gary_poster> sinzui, ack, thank you.
<sinzui> Novice users often try to version a package in the name and the same happened with charms. Charms don't accept charms with versions unless there are co-installable version.
<sinzui> that is a rare case
<abentley> gary_poster: We're changing the name of bundle branches from "bundle"  to "trunk"?
<gary_poster> abentley, I'm asking whether that would be trivial
<bac> gary_poster: i think not.  (sinzui may correct.) but if it were 'trunk' it would look just like a charm.  using 'bundle' vs 'trunk' as the branch name is all that distinguishes them.
<gary_poster> not the "bundles" series?
<abentley> gary_poster: I think it would be trivial, for us, but it would require changes to the charm store, because it would then treat it as a charm.
<gary_poster> abentley, ah!  got it.  thanks.
<gary_poster> btw, abentley, I much appreciate your participation, but I apologize for unintentionally pinging you with those urls
<abentley> gary_poster: np.
<frankban> gary_poster: re always using the go sandbox in the charm when sandbox==true, I suspect we would have backward compatibility problem, i.e. someone upgrading to the new charm without updating the GUI to the (not yet released) last version. I guess this would be a problem even if we just allow sanbox mode in a juju-core env. do we care about those cases? 
<sinzui> bac, abentley gary_poster , trunk does conflict the store. The store will report an error, but wont break
<gary_poster> sinzui, right.  That adds detail to what abentley said but does not contradict it, right?
<sinzui> right
<gary_poster> cool thank you
<rick_h> frankban: I'm getting errors about no shelltoolbox when running the make command? It looks like it's using a venv, does it not install it in the venv?
<rick_h> hmm, looks like it's not in pypi, so no python package available. 
<frankban> rick_h: it should, it is listed in the tests/requirements.pip file
<gary_poster> gotcha, frankban , your core situation is that I (a user) have an old GUI release with a new charm release, whatever the case.  Mm.  Thinking.
<rick_h> frankban: hmm, did a make clean and trying again. Will see what's up. 
<frankban> rick_h: try "make clean" and male
<frankban> make even
<gary_poster> :-)
<rick_h> frankban: oh, I'm missing something before it, a headers lib. http://paste.mitechie.com/show/1010/
<gary_poster> (and this will be the case for anyone using the ~juju-gui charm until we make the upcoming release)
<frankban> gary_poster: yes
<gary_poster> that's the only part that really bothers me :-P and we should have a release today
<frankban> rick_h: interesting, so something is missing that is required to build apt_pkg
<rick_h> frankban: yea, looking
<gary_poster> hatch btw when you get in that's the third headline for this release: the sandbox mode now has a complete Juju-Core-based implementation, which is now the default
<frankban> gary_poster: ok, I'll just make sure that the "go sandbox activated and used everywhere" lands after the new release
<gary_poster> cool thanks frankban. you agree with that?  I don't see a safe way to do anything else, really
<rick_h> frankban: looks like might be libapt-pgk-dev. Retrying now
<TheMue> frankban, gary_poster: the new behavior is already merged by accident. i'll now do a rollback. but we have then to find a good way for (a) setting string settings to empty strings and (b) unset settings
<frankban> gary_poster: I agree with that, the only other solution would be activating features based on the gui version, but that's not simple to accomplish and probably not worth the effort
<gary_poster> frankban, exactly
<gary_poster> TheMue, for (a) I'm guessing the commandline is the issue?  The API is straightforward AIUI: you send an empty string, and an empty string is stored.
<gary_poster> In the new change I mean
<rick_h> gary_poster: so based on your email my plan was to start looking at adding api3, the feature flag, etc today? or should I grab another inspector bug before heading over there?
<TheMue> gary_poster: yes, sending a string leads to this string stored in case of a string setting
<TheMue> gary_poster: but there's no unsetting
<frankban> TheMue, gary_poster: AFAICT (b) requires a new API call or a change in the current config params (map[string]string -> map[string]*string)
<gary_poster> TheMue, ok.  That seems good for us for now.  unsetting will be a new feature.  Agree with frankban.
<TheMue> gary_poster: and this has been done by sending an empty string before
<gary_poster> ack
<rick_h> frankban: yep, so libapt-pkg-dev is a dep to run the make command. 
<gary_poster> rick_h, let me see how we are doing on inspector.  IE put us behind, and getting the inspector done is what we should do first to get things out the door.
<rick_h> gary_poster: rgr
<gary_poster> rick_h, please grab an inspector one.  I'd rather have a chance to get one thing done and the other thing unstarted than be inprogress on two :-)
<rick_h> gary_poster: k
<frankban> rick_h: yeah, it is already listed in the HACKING.md file indeed: sudo apt-get install build-essential bzr libapt-pkg-dev python-pip \
<frankban>         python-virtualenv xvfb
<gary_poster> rick_h, you good with that under circumstances?
<rick_h> frankban: ah, gotcha. Sorry, just went off the notes. I should have looked at it
<rick_h> gary_poster: sure thing
<gary_poster> cool thanks
<frankban> rick_h: sorry, didn't remember that
<rick_h> frankban: all good, I'm used ot charmworld having the make sysdeps so it's still in make
<frankban> rick_h: so you run "sudo make sysdeps"? that seems a good idea
<rick_h> frankban: yea, it's still a manual listed step so we dont' have to wait for it to run apt on every make command though. So I'd still be 'duh, didn't see that'
<rick_h> frankban: but make <tab> shows the extra step 
<gary_poster> frankban, TheMue, from the GUI perspective, setting config values to their defaults is a non-issue.  We can do it now because we can get the charm, discover the default value, and explicitly tell Juju to use that.  We already have everything available to do that now, pretty trivially.  The CLI would need its own solution though, and that's where that API might come in handy.
<frankban> rick_h: yeah
<frankban> gary_poster: agreed. from the GUI there is no difference in having the default value or no value stored in the juju-core db
<gary_poster> right
<gary_poster> filed #1217884 fwiw
<_mup_> Bug #1217884: Include a way to reset config values to their defaults <juju-gui:Triaged> <https://launchpad.net/bugs/1217884>
<gary_poster> triaged low
<gary_poster> if we get people asking for it we can reprioritize, or if someone wants to champion it on the team, cool
<gary_poster> bac, looking at #1217884.  Out of curiosity, how much work does it look like it would take to get Safari working?  Do things mostly work, or...?
<_mup_> Bug #1217884: Include a way to reset config values to their defaults <juju-gui:Triaged> <https://launchpad.net/bugs/1217884>
<gary_poster> bac sorry I meant to paste #1202408
<_mup_> Bug #1202408: Left panel charm browser inter-cell scrolling in Safari <juju-gui:New> <https://launchpad.net/bugs/1202408>
<gary_poster> This morning is apparently Gary's time to bother Brad as many times as possible
<bac> gary_poster: i do not see the visual effects reported in that bug with jujucharms.com
<rick_h> frankban: so when I enable the build in server I get that chrome websocket issue that came up in the call/fixed on the rapi side.
<gary_poster> bac, oh! so, fix released?
<rick_h> frankban: so this is our tornado server now? It needs the same fix?
<bac> gary_poster: so perhaps whatever styling issues were causing it have been resolved.
<gary_poster> cool.  bac, more generally, though, how far away are we from Safari working well?
<bac> gary_poster: or invalid.  i don't think it was addressed directly just fixed as a by-product
<gary_poster> ok
<frankban> rick_h: yes, the browser now connects to tornado
<frankban> rick_h: what version of chrome?
<rick_h> frankban: ok, so I'm going to file that as a seperate bug, or find the old bug and tie to the charm
<rick_h> frankban: 30
<rick_h> frankban: 31 actually as of today
<rick_h> frankban: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch, the headers need to match from request to reply
<rick_h> frankban: I think rapi was dropping the header? I'll have to look at the diff hazmat did
<hazmat> rick_h, yeah, chrome was setting the value to undefined, i just had it return
<TheMue> gary_poster: thanks for the info, will discuss it with fwereade_ , currently rolling back my last CL
<hazmat> not unconditionally though
<bac> gary_poster: i just poked around at it briefly and saw no issues
<rick_h> frankban: ^ 
<bac> gary_poster: so perhaps we're really close.
<rick_h> frankban: so doesn't effect this branch, but heads up
<frankban> hazmat: so the server must include a Sec-WebSocket-Protocol=undefined header?
<rick_h> frankban: yes
<rick_h> frankban: so that they version headers match
<hazmat> frankban, the server must send back what the client sent, and optionally use it to inform codec selection if it matches something known.
<hazmat> frankban, fwiw upstream has change signficantly.. therve has done a lot refactoring on the twisted ws branch, though it appears to have stalled again
<hazmat> frankban, oh this is with tornado?
 * hazmat pokes at tornado src
<bac> gary_poster: turning on the inspector i do see some icon placement issues
<hazmat> frankban, see select_subprotocol in tornado websocket.py
<hazmat> probably needs to be overridden
<sinzui> abentley, benji, do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/search-featured/+merge/182509
<hazmat> this may just be a chrome beta/alpha bug as well
<hazmat> considering it doesn't really care about the reply
<abentley> sinzui: sure.
<frankban> hazmat: yeah
<bac> gary_poster: and big problems with ff on os x
<frankban> hazmat: IIUC a "return subprotocols[0] if subprotocols else None" in select_subprotocol should do the trick
<frankban> rick_h: thanks for QAing, and great to know that the GUI charm works well on a juju-core lxc provider
<frankban> TheMue: ^^^^
<rick_h> frankban: yep, <3 the faster lxc local stuff. 
<frankban> TheMue: ^^^^ ;-)
<rick_h> frankban: though I need to look into juju ssh, it uses the current username for the ssh so I had to ssh manually ubuntu@xxxx
<TheMue> frankban: ah, great news
<TheMue> frankban: will be a nice show to demonstrate it
<frankban> rick_h: I'll start using it in place of ec2, do you have a ready-made local env conf?
<rick_h> frankban: heh yea,   local: type: local admin-secret: 2c6e61e81c9ad07af67f833129bef2d0
<frankban> cool, thank you
<rick_h> frankban: nice short, and using juju switch to avoid the -e go and such
<gary_poster> bac, ok thank you for details.
<frankban> rick_h: I look forward to migrating the CI (and I guess jujucharms.com) and forget about multiple implementations ;-)
<abentley> sinzui: At 310-311, do you really care about the order?  If not, you can use assertItemsEqual instead.
<frankban> guihelp, anyone available for a second review (no QA) of https://codereview.appspot.com/13340043 ? thanks!
<sinzui> abentley, indeed I don't care.
<abentley> sinzui: r=me
<abentley> benji, bac, sinzui: Can we have a chat about migrations?
<benji> sure
 * benji finds his camera.
<sinzui> abentley, +1
<gary_poster> hey benji, could you verify that https://bugs.launchpad.net/juju-gui/+bug/1202413 is still an issue?  I just tried it on saucy's FF 23 and it is OK
<_mup_> Bug #1202413: Relation drag line persists after clicking <juju-gui:Triaged> <https://launchpad.net/bugs/1202413>
<gary_poster> benji I tried it on jujucharms and comingsoon
<abentley> sinzui: guichat
<adeuring> abentley: could you have a look at the changes in this branch lp:~adeuring/charmworld/spurious-failures ? I know that some stuff can be refactored -- my main point is so far to just reduce test failures... Comments should show why I made each change
<abentley> adeuring: On a call, but I can look after.
 * hatch crosses finger final qa doesn't break ;)
 * gary_poster crosses toes
<gary_poster> easier to type but harder to walk
<hatch> haha
<rick_h> hatch: stop poking the bear! :P 
<rick_h> hatch: actually, it's good stuff. We've found some legit bugs along the way so appreciate the firm stabbing at things
<gary_poster> dran straight!
<gary_poster> darn, even
<rick_h> if we're down to the bugs darn near impossible to figure out, then must mean we're getting down to the last ones
 * rick_h can hope at least!
<Makyo> Last bugs.  I like it.
<hatch> haha
<hatch> *sigh*
<rick_h> hatch: guichat?
<hatch> sure
<hatch> busy
<hatch> gary_poster: I think we need to roll the core-backend debug change back
<hatch> rick_h: is just testing core right now
<hatch> but the sandbox is definitely broken when creating relations
<gary_poster> hatch ok.  you mean the default, right?
<hatch> yep
<gary_poster> hatch, ack.  +1 on doing that and getting this release out the door
<hatch> ugh lots of test failures when I switch back
<hatch> trying now with only the config changed but the default still at go
<gary_poster> hatch, look for that commit and try reverting the commit
<hatch> gary_poster: if I set the default to 'go' and then set the configs to 'python' the tests all pass
<gary_poster> hatch, heh ok
<gary_poster> hatch, and it still works? :-P
<hatch> it appears so :)
<hatch> so looks like we won't be setting go as the default for now
<hatch> now when someone calls me on hangouts, my computer, tablet, cell phone all ring....it's a little much haha
<rick_h> hah
<benji> This is a public apology to bac for incorrectly correcting his use of "monotonically increasing"; he was right, I was wrong.  Let this be a less on to the rest of you... or something
 * rick_h bows before the great and powerful bac
<gary_poster> hatch, ok.  that slows down other tasks--frankban has a branch that was going to switch that so we could move forward with bundles. but...frankban, eh, let's talk.  I think maybe we can still move forward.  It will just be a bit riskier. :-/
<gary_poster> he has a charm branch that was going to switch the sandbox there to use go, I mean
<rick_h> gary_poster: yea, there's a real bug/issue with the ondelta model event that's either not calling or getting the right thing. 
<hatch> gary_poster: I could take a 30min timebox to try and fix
<gary_poster> luca__, do we have an agenda for webteam call?  we will see them in a week, and we potentially have some important things to talk about then, but if there's no topics immediately let's skip it (again)
<luca__> gary_poster: I thought I cancelled it yesterday =O
<gary_poster> luca__, oh cool.  Sorry, just my phone not catching up to the times then :-P sorry, thanks
<luca__> gary_poster: no worries, how is everything?
<gary_poster> hatch, yes, if you are up for it.  Maybe pair with Makyo, or me?
<hatch> ok gimme a few minutes to track it down
<gary_poster> thanks hatch
<frankban> gary_poster, hatch: so there is a problem in building relations in the go sandbox?
<gary_poster> luca__, hectic.  post-vacation catch up combined with more re-prioritization discussions and discussions about Dustin's feedback :-)
<gary_poster> luca__, looking forward to seeing juju.ubuntu.com 1.0 or whatever it is called Monday :-)
<hatch> frankban: yes models.js:975 calls the handler with the wrong information
<hatch> currently looking into the fix
<luca__> gary_poster: haha, hopefully it looks good :) I'll give you a sneak peak when it's in a better shape.
<frankban> hatch: thank you
<hatch> frankban: and it's all your fault :P
<gary_poster> cool luca__ :-)
<luca__> gary_poster: would you like to catchup on anything tomorrow?
<frankban> hatch: that's surprising!
<hatch> lol
<hatch> so it appears that the delta that's coming back isn't including the endpoint data
<frankban> hatch: isn't that code used also for real environments? if so, why relations work in real envs?
<hatch> frankban: rick_h tried it in a real env and it didn't error
<hatch> so possibly sandbox issue?
<rick_h> hatch: but the service also didn't come up since it was in error
<frankban> hatch: more probably, yes
<hatch> frankban: here is the delta data https://gist.github.com/hatched/6367087
<hatch> which I'm certain is incorrect
<frankban> hatch: perhaps you can take examples of how the delta should be from the test_model_handlers.js file, starting from line 351
<hatch> frankban: thanks I'll check it out
<Makyo> jujugui units binding of service-overview viewlet does not work in FF against a real core env.  Any ideas?
<Makyo> (in trunk)
<gary_poster> Makyo, works in chrome?
<Makyo> gary_poster, I haven't checked yet, currently in the process of deploying the charm.
<gary_poster> ack, Makyo.  Worth a check; I'd assume it is browser agnostic, and a diff between our sandbox and the real world, but would be good to verify
<Makyo> gary_poster, yep.  Just can't test from local devel server in chrome.
<gary_poster> oh :-/
<gary_poster> k
<gary_poster> Makyo, old pre-inspector interface works
<gary_poster> ?
<abentley> bac: I'd like to re-enable test_ensures_category_questions.  Can you describe the spurious test failures that caused you to disable it in https://code.launchpad.net/~bac/charmworld/spurious-test-failures/+merge/181418 ?
<Makyo> Checking.
<Makyo> gary_poster, yes.
<gary_poster> k
<hatch> frankban: somewhere between sandbox.js:handleClientAddRelation and sandbox.js:receiveNow it loses the Endpoints object :/
<bac> abentley: the test failed.  spuriously.  these failures are what prompted abel's investigation, that is on-going.  he did seem to correlate some failures with slower machines.
<abentley> bac: Were there any particular error messages you got?
<bac> abentley: i do not recall the exact error conditions for each failure
<bac> abentley: i'd suggest talking with adeuring
<gary_poster> Makyo, hatch is deep in release.  I have no further ideas without digging.  Would you like a pair with me or rick_h, or an initial timebox investigation?  The obvious thing to me is to suspect the deltas; dunno
<Makyo> gary_poster, I know where it's going wrong, if it is, will update once I can test from the charm
<gary_poster> Makyo, cool ty
<abentley> bac: Please report spurious failures more thoroughly.  Even a paste from the console would be very useful to me now.
<adeuring>  bac, abentley: as far as I understand the problem currently, it seems that ES is sometimes just a bit slow, especially when an index is created, deleted or when its mapping is changed. I have a branch that catches many errors.
<abentley> adeuring: I'm looking at that branch you asked me to earlier.  I assume it's the same?
<adeuring> abentley: yes, that's the one I meant
<bac> abentley: there were a set of about 6 tests that were failing in various combinations or not at all.  they were reproducible by sinzui and adeuring in trunk.  the failures were blocking the landing of other work.  the work to fix them was handed off to adeuring.
<adeuring> well, I got meanwhile errors/failures in many more tests....
<hatch> when base.js fires a 'msg' event, can someone tell me what listens for that event?
<hatch> grep is failing me....
<bac> abentley: in the future attaching a failure report to a bug referenced in an XXX when disabling the tests is a fine idea
<abentley> bac: Thanks.
<adeuring> some problems still remain, but they look to me like real ES errors, like this one: sending faile
<adeuring> d shard for [temp_index][3], node[gWVu1uWMSvegY4D7uW2c7g], [R], s[INITIALIZING], reason [F
<adeuring> ailed to start shard, message [RecoveryFailedException[[temp_index][3]: Recovery failed fr
<adeuring> om [Ezekiel][6hy-kGs5Qwe5OSuRjxJrXw][inet[/192.168.2.30:9300]] into [Gregory Gideon][gWVu1
<adeuring> uWMSvegY4D7uW2c7g][inet[/192.168.2.209:9300]]]; nested: RemoteTransportException[[Ezekiel]
<adeuring> [inet[/192.168.2.30:9300]][index/shard/recovery/startRecovery]]; nested: RecoveryEngineExc
<adeuring> eption[[temp_index][3] Phase[2] Execution failed]; nested: RemoteTransportException[[Grego
<adeuring> ry Gideon][inet[/192.168.2.209:9300]][index/shard/recovery/prepareTranslog]]; nested: Engi
<adeuring> neCreationFailureException[[temp_index][3] failed to create engine]; nested: LockObtainFai
<adeuring> ledException[Lock obtain timed out: NativeFSLock@/var/lib/elasticsearch/elasticsearch/node
<adeuring> s/0/indices/temp_index/3/index/write.lock]; ]]
<hatch> ignore me, I missed the defaultfn
<adeuring> restarting the ES server seems to help
<abentley> adeuring: Have you tried ElasticSearchClient.wait_for_startup rather than calling health directly?
<adeuring> abentley: yes, the "yellow" status is quite often not enough.
<abentley> adeuring: Ah.
 * gary_poster laughs at still having "yellow" ping him
<adeuring> abentley: and even the "green" status sometimes not suffient. but a refresh() call seems to help in this case
<Makyo> Ugh, I've made this change before, I know I have >:/
<abentley> adeuring: This makes me worry that the calls may not be fixing the problem, merely delaying execution, and coincidentally fixing the problem.
<abentley> Most of the time.
<rick_h> Makyo: maybe made it in the python side and never got to the go side? Now with go default it's hitting again?
<adeuring> abentley: that's possible. OTOH, it seems that ES responds for several requests before "the work is really finished", so waiting for a certain status may help indeed.
<Makyo> rick_h, it's go only; we're just not passing an argument (and if that argument's undefined, it exits).  I could've sworn I fixed this in the branch where I first added the unit list to the inspector.
<rick_h> Makyo: ok, yea just tossing idea out there on 'what's changed recently' to trigger it
<adeuring> abentley: and I don't see any better way to query the status of the ES server...
<abentley> adeuring: Yes, the health is reasonable, it's the refresh that I worry about.
<Makyo> rick_h, Yeah, now I'm confused too, because the code's there in trunk in the source, but not in the compressed prod file (at least, according to source maps)
<rick_h> Makyo: orly, now that's interesting
<rick_h> Makyo: cache? or build step issue for new js files ?
<adeuring> abentley: well, the documenntation of refresh() says "making all operations performed since the last refresh available for search", so calling it should have some effects
<abentley> adeuring: Right, but if the only operation was creating the index, I would expect that health was the only thing I had to wait for.
<Makyo> rick_h, yeah, I'm not sure!  Poking around further.
<adeuring> abentley: maybe I need to check where exactly I added refresh() calls, but right now I see just one after a run_migration() call. And that call could do more that just create/delete indexes. I would beed to check more closely though to be sure...
<abentley> adeuring: we'll be deleting those migrations anyway, so spurious test failures there don't matter.  The only migration code we're keeping is the bit where we ensure category questions.
<Makyo> rick_h, gary_poster - alright, I found it.  It's disappointing.  rick_h no clue why the sourcemaps are showing out-of-date code, maybe they weren't generated properly.  The issue at the heart of it, though, is that we're now getting units before services. When we get unit-adds, we try to update the list of units stored with the service, which doesn't exist yet.  That list is what's bound in the inspector.
<gary_poster> Makyo, ah. :-/
<adeuring> abentley: right, but I saw also errors in test_search.py, for example. And they were not related to migrations either...
<abentley> adeuring: Right, I
<adeuring> so I think at least the changes I made to testing.__init__ are useful
 * gary_poster wants time for more reliable, non-canonistack testing against juju core.
<abentley> adeuring: Right, I'm talking about the tests of migrations, since that's what you mentioned.  I know that there are other tests that you updated.
<hatch> timebox is up and I have no idea what's going on
<gary_poster> Makyo, I think we talked about this possibility way back when and had an idea of how to approach it.
<hatch> somewhere between receiving the delta and the onDelta call the endpoints get lost - but even the d3 stuff gets the proper data
<Makyo> gary_poster, Yeah, sort by delta type to maintain the hierarchy.  Investigating that now.
<gary_poster> Makyo, cool thanks
<gary_poster> hatch ok.  we have 16 min till call..
<gary_poster> hatch, futz with it for 16 more min, hope for a miracle, and we'll figure out what to do after call?
<hatch> sounds good
<gary_poster> thanks
<abentley> adeuring: Maybe in temp_index_client, you can do client._client.health(client.index_name, wait_for_status='green') instead ofclient.wait_for_startup.  Then you won't need to do it at the bottom, so we avoid an unnecessary call. 
<gary_poster> frankban, LGTM with super trivial typo fix
<adeuring> abentley: Right, might be worth a try
<frankban> gary_poster: thank you
<abentley> adeuring: at charmworld/migrations/versions/tests/test_migrations.py:285, the refresh call should not be doing anything, because index_charm always does a refresh.
<Makyo> jujugui call in 10 kanban now
<rick_h> jujugui small css review with qa please https://codereview.appspot.com/13347043
<adeuring> abentley: really? With these spurious errors it is hard to be sure that a change really helped, but I am pretty sure that the added call made a difference. But that could be in indication that it's just the added minor delay that helped...
<abentley> adeuring: Would we save a lot of code by hardcoding wait_for_startup to "green"?  I only chose yellow because it seemed to work.
<adeuring> abentley: sure, I intended at least to add something like "wait_for_green", but a change to wait_for_startup() would do it too
<abentley> adeuring: Really: search.py:284 sez "refresh=True".
<adeuring> ok...
 * adeuring becomes scared by ES
<gary_poster> rick_h, nice approach to z-index.  We should doc somewhere.  We might forget, but a doc somewhere is better than nothing at all :-P
<rick_h> gary_poster: rgr, will find a place to not it, maybe a giant comment in the top of stylesheets.less
<rick_h> to note*
<gary_poster> rick_h, maybe so, or in rest doc...downsides to both.
<gary_poster> whichever.  something is better than nothing. :-)
<rick_h> gary_poster: yea, thought about rst docs but didn't see anything that fit and adding another doc was :/
<gary_poster> understood.  at some point we should actually have a doc that talks about when to have a new less doc and so on, but doesn't need to be now
<gary_poster> rick_h, gave you a non-qa LGTM, now you just need the real one ;-)
<rick_h> gary_poster: :) thanks
<Makyo> jujugui call in 1
<frankban> hazmat: when you have a chance, coul you please review https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ?
<hazmat> frankban, ack, in uds sessions atm
<frankban> hazmat: thanks, no rush
<Makyo> jujugui https://codereview.appspot.com/13350043 fix for ordering deltas (for showing units in the inspector)
<bcsaller> hatch: can I get 10 minutes before we pair on the other, I need coffee
<rick_h> bcsaller: I'm going to grab food, let me know if the re-propose diffs better or else I'll go find the branch and pull it down
<Makyo> jujugui can I get at least one review on ^^^ - Doesn't need to land before the release, but does need to be a part of my branch, and I don't want to stack too deep.
<hatch> bcsaller: sure thing
<rick_h> Makyo: looking
<Makyo> rick_h, thanks.
<hatch> FYI there is a big movement in the node.js communities to sharing templates between the server and client side - so this is a solved problem as long as python has the proper tools
<Makyo> At least, I don't think it needs to land before the release.  A fix in place would certainly be nice.
<rick_h> hatch: yes, except the issue we've got is that there's a lot of JS in our Y.Views to take api data to the template that would have to be duped
<hatch> rick_h: no, abstracted :)
<rick_h> hatch: it's a rabbit hole. Two projects with different uses never will agree 100%
<rick_h> Makyo: replied
<hatch> well tbh in my mind I see them sharing very few templates as the GUI will no longer have a fullscreen view
<Makyo> rick_h, thanks.
<rick_h> hatch: heh, the fullscreen is 90% sidebar with different max-widths :P
<hatch> haha well ok then they don't 'need' to be shared - they can be allowed to diverge because they are no longer one
<hatch> but honestly though we COULD render the gui under the fullscreen browser
<hatch> which would allow us a quick initial load time AND the gui available
<hatch> I just want one url for everything
<hatch> which I think is what others also agree with
<bcsaller> Makyo: are you sure the delta sorting reflects the real env? It looks like it could but we can't depend on it if its not the case
<Makyo> bcsaller, how do you mean?  The issue at hand is that we can't add units to service.units if service doesn't exist in the db yet.
<bcsaller> I get that, I just want to be that it doesn't reflect a real difference in the way sandbox does deltas vs the live env
<Makyo> bcsaller, it does, as of at least juju-core 1.13.2.  The only difference I see, however, is in the order of the deltas, and this would normalize in both cases.
<bcsaller> Makyo: sounds good, thanks
<Makyo> Still miffed about the no newlines in debug-log, though.  Impossible to see in there.
<hatch> bcsaller: 10mins have passed :P
<rick_h> Makyo: yea, that's annoying as can be
<bcsaller> hatch: yeah, I stiill owe rick a review on his branch, trying to get through that now and then I'll ping you
<hatch> :D sure np
<Makyo> rick_h or bcsaller can you re Â±1 https://codereview.appspot.com/13350043?  Modified slightly so that we don't do arithmetic on 'undefined'.
<bcsaller> Makyo: done
<Makyo> bcsaller, thanks
<Makyo> jujugui (notably hatch) alright if I land this branch, or want to wait for after release?
<hatch> Makyo: land it - if it turns out we can't quickly fix this go issue then it won't be touched anyways
<Makyo> hatch, cool, thanks.
<bcsaller> hatch: ready when you are
<hatch> lets do it!
<sinzui> I can tell this is going to be a good 5 hours of coding, Sweet Transvestite from The Rocky Horror Picture Show starts my coding session
<abentley> I see you shiver with annntici....
<sinzui> pation
<abentley> Oh, that's right.  You used to always have the currently playing track in your bzr commit messages.
<gary_poster> hatch, I figure you are hacking.  ping me when you want to talk.  don't want to get in your way
<hatch> gary_poster: now is fine
<hatch> bcsaller: is just trying some things
<gary_poster> cool hatch joining
<hatch> bcsaller: guichat?
<bcsaller> hatch: one sec, finishing a test
<bcsaller> hatch: ok
<hatch> gary_poster: do you know what your power adapter is called?
<gary_poster> looking
<gary_poster> hatch http://www.amazon.com/gp/product/B003UHYDYO
<hatch> Makyo: can you join us in guichat?
<hatch> gary_poster: after some more research we think we can pop out a fix in ~1H
<gary_poster> hatch great! thank you!
<gary_poster> and thanks bcsaller and Makyo 
<Makyo> Just upgraded a real service from the gui, woo.  Good to see this stuff actually working.
<hatch> boo yeah! Fixed
<bcsaller> hatch: oh, you got it, great
<hatch> yeah but for some reason the relation id is 'undefined undefined'
<hatch> so trying to track that down...
<bcsaller> it was called Key and is the above whitelist, you can turn that into a function if you need some more complex mapping
<hatch> ahh thanks
<hatch> any idea if the interface is on the endpoint?
<hatch> I can't seem to find two services that supply one haha
<bcsaller> hatch: I think that is name
<bcsaller> sorry, was making more coffee
<hatch> bcsaller: guichat?
<bcsaller> rick_h: don't know if you saw, the CR didn't improve but I noted how to generate the diff, if you really can't review it at this point I can try deleting the MP and creating a new branch, but let me know
<bcsaller> hatch: I'm there
<rick_h> bcsaller: no, completely missed it and forgot about it. Sorry
<bcsaller> rick_h: understood :)
 * rick_h kills offlineimap and goes to look at what's up
<rick_h> holy moley!
<rick_h> oh, that's trunk...ugh
<sinzui> abentley, rick_h: My mind is boggling at a test failure. Before I change routing, I am adding tests for the similar routes. The json route tests always fail because there is not content-type (this is an implicit test in the test helper). While I can see the json view helper thinks it is adding content-type, I think it os borked. Can you confirm that http://staging.jujucharms.com/~gnuoy/precise/apache2-1/json doesn't have a con
<sinzui> tent type?
<rick_h> sinzui: don't see content-type headers
<abentley> sinzui: Confirmed.
<sinzui> Will the gui hate me if I ensure content-type is application/json
<rick_h> sinzui: no, but 'just hitting' a url will hat eyou
<rick_h> e.g. I can just pop an api url into my browser and see the json like I'm doing right now to look at gary_poster's bug request question
<rick_h> sinzui: or do you mean only ensuring it's in the response?
<sinzui> looks like webob.Response(json, content_type=u"application/json") doen't add the header
<rick_h> sinzui: no, three's a headers thing to change
<rick_h> sinzui: see the OPTIONS request stuff
<rick_h> sinzui: I think it's request.response.headers?
<sinzui> rick_h, we are passing headers as headerlist=[...] adding Content-Type fixes the response, but will that break the gui?
<rick_h> sinzui: We can double check, but I don't think adding a content-type of json in the response will cause us any issues
<sinzui> oh, are we still using /json? That is the old API point.
<sinzui> Well people in the wild probably are
<rick_h> sinzui: oh, that's the old old stuff. /me missed that
<sinzui> oh, looks like headerlist is mutually exclusive to adding headers as separate args.
<rick_h> bcsaller: I was having a hard time without hte rest of the file for context. Re-sub'd it as WIP just ot look at it https://codereview.appspot.com/13361043
<bcsaller> rick_h: oh, thank you
<rick_h> bcsaller: is there no way to share this code between service.js and bundle.js?
<bcsaller> rick_h: there should be, yes, sorry, still on a call
<rick_h> bcsaller: k, np. 
<bcsaller> rick_h: I didn't have any UX when I stared so I just took what I could to move on, but a base mixin makes sense 
<rick_h> bcsaller: ok, well looked it over put notes in https://codereview.appspot.com/13361043/ but not comfy landing so much code dupe
<bcsaller> rick_h: thanks, thats fine feedback and shouldn't be that long to fix
<rick_h> bcsaller: cool
<hatch> gary_poster: can you pop into guichat?
<gary_poster> ok hatch
 * Makyo -> vet
<hatch> gary_poster: https://bugs.launchpad.net/juju-gui/+bug/1218061 for your email
<_mup_> Bug #1218061: Duplicate relations created when using the go sandbox <juju-gui:Triaged> <https://launchpad.net/bugs/1218061>
<gary_poster> hatch, heh, thanks
<abentley> orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-migrations/+merge/182756 ?
 * sinzui looks
<bac> abentley: sure
<abentley> bac: Thanks.
<bac> thanks abentley, looks good
<abentley> bac: Thanks for the reminder about docs.  I'll do that.
<hatch> are there any plans to collapse the charms in the sidebar to a single one with a dropdown to select the series?
<hatch> or even to only display the series which applies to the current env?
<rick_h> hatch: when doing a search?
<rick_h> hatch: that's part of what needs to be figured out in jcsackett's work
<hatch> yeah there are 4 ceph-osd's one for each series
<hatch> probably woudln't be clear for a n00b what the difference is
<rick_h> hatch: yea, that's what we want to put in front of UX. There was talk of showing series info on the charm token, etc at one point
<hatch> I'd vote for a dropdown in the charm details
<hatch> buuut maybe ceph-osd is a odd one out having so many different versions
<gary_poster> rick_h, you filed a bug or sent an email or anything?  if not, do you want me to?
<abentley> bac: Docs updated: https://code.launchpad.net/~abentley/charmworld/remove-migrations/+merge/182756
<bac> abentley: looks good
<rick_h> gary_poster: on?
<gary_poster> <rick_h> hatch: yea, that's what we want to put in front of UX. There was talk of showing series info on the charm token, etc at one point
<rick_h> gary_poster: this is tied to the 'all category' bug and the UX improvements requested there that jcsackett is working on. 
<rick_h> gary_poster: the goal is to kill the filters, group into two parts, and then show UX to get suggestions on where they want to clean up the issues remaining
<rick_h> gary_poster: so not a bug on it, and it's been hashed over in calls/etc in the past.
<gary_poster> rick_h, oh...it seems only tangentially related, but as long as it is coming up with them I guess that is AOK
<gary_poster> than kyou
<hatch> jujugui looking for a QA/review on https://codereview.appspot.com/13366043/ for release
<Makyo> On it
<hatch> thanks
<gary_poster> hatch, gave you LGTM without qa
<hatch> OOooo riskay!
<gary_poster> heh
<Makyo> hatch, lgtm
<hatch> thanks!
<hatch> gary_poster: https://gist.github.com/hatched/fb98cc122380e74a0ad2 version notes
<gary_poster> hatch for line 2, "almost finished"? :-)  or "significant progress on"
<gary_poster> for line 5, past tense for consistency ("Fixed")
<gary_poster> for line 10, "user"?
<gary_poster> Maybe move lines 6 and 7 to the top, since they are the headliners?
<gary_poster> or do none of that. :-) It's good, thank you!
<gary_poster> hatch ^^
<hatch> all done!
<hatch> :)
<hatch> thanks
 * gary_poster steps away.  thank you all, and see ya tomorry
<hatch> cya!
 * hatch wonders what LP does when making a release that takes 10+min
<hatch> surely LP has to be more powerful than my mini running two VM's :D
<hatch> jujugui 0.9.0 has been released!
<bcsaller> woot
<hazmat> nice
<huwshimi> Morning
<hatch> hi huwshimi how's it going?
<huwshimi> hatch: Good thanks, yourself?
<hatch> good good
<hatch> huwshimi: so are you still on GUI stuff or on to other things?
<huwshimi> hatch: Working on charmworld at the moment
<hatch> ahh cool cool
#juju-gui 2013-08-29
<hatch> shhhhhhhh
<TheMue> frankban: ping
<frankban> TheMue: hi
<TheMue> frankban: hello, it's me again
<TheMue> frankban: I've rolled back the changes regarding ServiceSet due to the API incompatability
<TheMue> frankban: but william told me that you're thinking about an API change make larger settings/unsettings at once
<TheMue> frankban: am i right? in that case we could also use this new API call to allow the explicit unsetting
<frankban> TheMue: as gary_poster mentioned, for the time being we can live with that incompatibility, meaning the GUI users will set string options to an empty string, or receive an error for bool/int/float fields
<TheMue> frankban: the problem is that other parts of the software use the API too, so it should not get incompatible
<frankban> TheMue: you mean, other parts of juju-core?
<TheMue> frankban: yep
<frankban> fwereade_: re large settings/unsettings at once are you referring to the ServiceUpdate for multiple services?
<frankban> TheMue: anyway, I believe you are right, we can take care of options unsetting when we improve the service API calls
<TheMue> frankban: yes, so we should stay in contact then
<frankban> TheMue: sure
<TheMue> frankban: any ideas about it already or do we start on a green field?
<TheMue> frankban: and i have to find a good we to allow setting string options to empty strings by cli without changing the api behavior
<frankban> TheMue: I think William already has some ideas for ServiceUpdate and ServiceDeploy, and some design decision is required
<adeuring> abentley, sinzui: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/spurious-failures/+merge/182901?
<TheMue> frankban: ok, will ask William when he's back
<abentley> adeuring: sure.
<frankban> rick_h: could you please take a look at https://codereview.appspot.com/13386043 ? it's the chrome dev fix.
<hatch> Makyo: review done
<Makyo> hatch, thanks.
<Makyo> hatch, none of the others are sprited, can we defer that to a separate branch?
<Makyo> A sprite-ageddon, if you will.
<Makyo> Will respond to comments instead of here, sorry.
<fwereade_> frankban, hey, sorry, I don't recall what the progress was on ServiceUpdate
<fwereade_> frankban, I had a feeling you were doing something with it
<hatch> Makyo: yep np
<rick_h> frankban: sure thing
<frankban> fwereade_: ServiceUpdate is implemented for a single service. And for now it takes SettingsStrings as a map[string]string, so there is no way  to unset an option. TheMue proposed a new API call for that. Anyway, I had the crazy idea of changing SettingsStrings to be a map[string]*string, not sure that applies well.
<frankban> rick_h: thanks
<frankban> fwereade_: from the GUI perspective, rather than unsetting an option, we could set the default value for that option.
<TheMue> frankban: unsetting an option is one part of the game, but setting a string option to an empty string another one
<TheMue> frankban: and this shouldn't been done with ServiceSet, because here option="" is interpreted as unsetting it. and this should not be changed
<frankban> TheMue: yes I know, I was just saying that, from the GUI perspective, a default value in the juju-core db == no value. And that we can react without too may problems to possible changes in how Service(Set|Update) are implemented.
<TheMue> frankban: ok
<hatch> rick_h: you around?
<rick_h> hatch: yep
<rick_h> with that lovely post-dentist "I've been touched in strange places" feeling :P
<hatch> just a very small FYI on your zIndex branch - the sidebar now shows above the 'modal' blackout when removing relations and the dialogue pops up
<hatch> I hate modals so I would remove the modal
<hatch> buuuuuut
<rick_h> hatch: ok, well, they should be adjusted. I tried to set a 'standard' for where z-indexes should lie and they can be adjusted clearly now.
<rick_h> hatch: I added a doc chunk to the top of the stylesheet.less walking through it
<rick_h> should be a two-liner
<hatch> ahh cool cool
<hatch> I just noticed it in QA but it was definitely not blocking lol
<rick_h> hatch: k, yea my bad. I tried to look over anything with a manual z-index to make sure it looked safe, but was hard to tell 
<hatch> yeah that's dynamic I think
<rick_h> frankban: looks good, small note on the doc comment
<hatch> working from the laptop today....boy is the console ugly
 * hatch can't wait for rick_h to fix it for me
<gary_poster> bac, sorry for missing time.  May I move our call to 2 PM
<rick_h> hatch: console is ugly?
<rick_h> oh, your tmux/zsh issues?
<hatch> yeah I tried to customize it....and broke it
<gary_poster> oh bac not here right
<gary_poster> forgot
<frankban> gary_poster: one review+qa is also valid for charm branches, correct?
<frankban> rick_h: thank you!
<gary_poster> frankban, sure.  we haven't agreed to it yet, but sure, give it a try and report back. ;-)
<frankban> ok thanks :-)
<frankban> gary_poster: and, if it's not clear, I am +1 on that proposal, including possible team reviews of parts of the code, as discussed in the juju ml
<gary_poster> frankban, cool :-)
<rick_h> frankban: thank you for fixing it up. My use of chrome dev can continue!
<hatch> nice
<frankban> :-)
<rick_h> hatch: ooh, new YUI and Template landed
<hatch> ok so at our rate in about 3 months I'll get to upgrading it :P
<frankban> rick_h: juju-core + lxc + juju switch is really cool. and, for when you need pyjuju, a virtualenv + virtualenv wrapper + a single symlink work well ("workon pyjuju" and you are done)
<sinzui> hi bac: Would you have time today to review https://code.launchpad.net/~sinzui/charmworld/support-gui-charm-urls/+merge/182924
<hatch> brb running to drop the car off at the shop, back in 15
<Makyo> jujugui call in 9 kanban now
<gary_poster> jujugui, I'll attend http://summit.ubuntu.com/uds-1308/meeting/21899/servercloud-s-juju-new-user-ux/ which conflicts with our standup. :-/  I feel like I need to be at both.  Makyo, would you mind running and taking some basic notes of anything important not covered by the kanban?
<Makyo> gary_poster, sure.
<gary_poster> thank you Makyo 
<Makyo> jujugui call in 2
<sinzui> abentley, benji : Would you have time today to review https://code.launchpad.net/~sinzui/charmworld/support-gui-charm-urls/+merge/182924
<hatch> jujugui can I get a review/qa https://codereview.appspot.com/13249045/
<hatch> bcsaller: did you QA?
<hatch> thanks for the review
<bcsaller> I didn't
<hatch> you should :D
<rick_h> hatch: I can qa, looking at now
<hatch> cool thanks
<hatch> rick_h: I was thinking the same thing as your perf comment and figured that it was virtually insignificant either way
<rick_h> hatch: yea, I guess I just wanted to raise it. 
<benji> jcsackett: your next dev environment: http://www.youtube.com/watch?feature=player_detailpage&v=8SkdfdXWYaI#t=545
<hatch> benji: that's real cool
<jcsackett> benji: that is awesome.
<benji> :)
<hatch> rick_h: so a couple days of use with Sense 5 and I can tell you that it has some cool features but I muuuuuuch prefer stock android
<rick_h> hatch: yea, I'm all nexus/stock any more
<hatch> I'm hoping I can get the Zoe camera app apk for the stock OS
<hatch> but I won't do that until I'm back home
<hatch> dont' want problems while away hah
<hatch> I wish tracking numbers had a delivery time
<hatch> yuss finally someone else who agrees with me that the search is broken :P
<hatch> our power is growing
<hatch> gary_poster: I was thinking of tackling 1214087 but the comments are a little confusing
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1214087
<_mup_> Bug #1214087: GUI fails to deploy keystone <juju-gui:Triaged> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1214087>
<hatch> it reads to me that it's a charm problem but then you want us to only send changed config values?
<gary_poster> hatch, yes
<gary_poster> hatch, you see why?
<hatch> yep
<hatch> so should this ticket be renamed then?
<gary_poster> hatch, fwiw, openstack is quite arguably our most important Juju story right now
<hatch> and I'm guessing keystone is part of that?
<hatch> heh
 * hatch googles keystone
<gary_poster> :-) yeah
<hatch> oh yeah that is a pretty important part
<gary_poster> :-)
<hatch> ok I'll add that to the config save
<gary_poster> hatch I wouldn't rename bug because both should happen: we can only send changes, because that is reasonable; and keystone charm should not be so persnickety :-)
<gary_poster> cool hatch.  ghost config is more important than post-deploy config if you have to choose
<gary_poster> thank you
<hatch> https://bugs.launchpad.net/charms/+source/keystone/+bugs odd this picks up the wrong status for our ticket
<hatch> gary_poster: in attempting to reproduce the issue using rapi I get an error that it can't understand the constraints...not the config error
<hatch> I'd like to reproduce the error first so I know that it's fixed or not
<gary_poster> hatch ack on call.  could be that the "undefined" thing is a problem
<hatch> ok I'll peek into that first
<hatch> ok the error is `juju.errors.ConstraintError: Could not interpret u'mem' constraint: need more than 1 value to unpack`
<hatch> I should mention `u` prefixes every json key value
<hatch> the data being sent is correct
<rick_h> hatch: that's a python thing, ignore it
<rick_h> hatch: basically saying it was a string 'mem'
<rick_h> u'mem' means unicode string
<hatch> ohh ok
<hatch> the syntax looks to match the syntax in the python tests
<hatch> rick_h: looks like we can't deploy anything on rapi in the new inspector
<hatch> because of the constraints
<hatch> do you have time to pair on this?
<rick_h> hatch: sure thing
 * rick_h can catch up
<hatch> cool guichat
<hatch> gary_poster: here is the constraints issue https://bugs.launchpad.net/juju-gui/+bug/1218555 working on it now
<_mup_> Bug #1218555: Constraints are sent in the incorrect format with new inspector to rapi <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1218555>
<hatch> $50 to get the unlock code from my carrier.....
<Makyo> Main laptop battery: ~40 mins. Backup laptop battery: ~20 mins.  I hope the flight to London involves power outlets :|
 * hatch searches for a cheaper code
<hatch> Makyo: :'(
<gary_poster> ack and thanks hatch
 * gary_poster not really here for a bit, because of early morning/late day Thursday
<sinzui> benji, abentley . I deployed your revisions to staging. Mine works, but I did not notice the bread crumbs changed: http://staging.jujucharms.com/~gnuoy/precise/apache2-1
<benji> I... don't think I know anything about bread crumbs.
<abentley> sinzui: having bad internet weather here.
<sinzui> benji, abentley. Maybe I should put "revision" in the breadcrumbs.
<sinzui> abentley, floods again?
<abentley> sinzui: No, just random slowness.  Sunny today, actually.
<benji> the "Apache2 1" at the end is suspect
<sinzui> benji, my current branch will reverse the breadcrumbs and put them in the page title, I don't think revision is important, though we might want to keep it because it distinguishes it from the versionless charm
<sinzui> BC: Home/ Gnuoy/ Precise/ Apache2  revision1
<benji> yeah, I think including the revision helps people know that they're looking at a particular revision which would seem to be important
<sinzui> Title: Apache2 revision 1 : Precise  : Gnuoy : Juju Charms.
<sinzui> Oh, we still say "Charm Browser" in the heading. That must say Juju Charm Browser or just Juju Charms
<rick_h> bcsaller: I saw Makyo reviewed. So if we can't dedupe the code then is it cool to leave current feedback as more tests required then? The code on things like sub relation indicators, exposed indicators, positioning tests, x/y annotation verification, etc need to be added?
<bcsaller> rick_h: thats cool, yeah. In the end more of this will be broken out into smaller functions and the level of reuse can go up, and there are somethings like sizes that should become configuration rather than hardcoded values 
<rick_h> bcsaller: k, I don't want to hold up things and wanted to double check what the plan is from here then. 
<abentley> orangesquad or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/prefix-bundles/+merge/182992?
<bcsaller> rick_h: Honestly I expect that the drawing code in there will undergo quite a bit of change once UX sees it, there is very little info on what people want, this is more a 'show capabilities' branch for now
<benji> abentley: I'll take a look
<abentley> benji: Thanks.
<abentley> benji: What trailing slash do you mean?
<benji> abentley: the import_filter is a prefix of the branch path, right?
<abentley> benji: right.
<benji> abentley: therefore, a filter of "XXX/foo" would match "XXX/foo/bar" and (erroniously) "XXX/foozzle", right?
<abentley> benji: I wouldn't consider the second erroneous.
<benji> hmm, maybe I misunderstood the purpose of _filtered_payloads.  I thought it was meant to match on path segments, not just on a character-by-character basis
<abentley> benji: No, it is just a prefix.
<benji> abentley: so, would it ever make sense to use it to match part of a path (like my second example)?
<abentley> benji: In reality, if it starts with "f", it has to be "feisty", anyhow.
<benji> ok, I guess it's not worth worrying about then
<hatch> so hows everyones afternoon?
<rick_h> the shed base is reinforced, shelves setup, and more crap shoved in it. now to cool off in the basement, phew
<hatch> gota love some good time in the yard
<hatch> or garage
<hatch> :)
<rick_h> yea, sprinkler folks moved the head under the shed out of the way so can put things back together
<rick_h> yea, I can't wait until winter to get back into the woodshop
<rick_h> I'm getting an aching for some woodworking. Need more hours in the day
<hatch> yeah - winter is when I can work on the cars
<hatch> summer should be the time, but who has the time!
<rick_h> right, as much fan as camping has been, looking forward to finishing up our last trip in Oct and winterizing it
<hatch> I thought you park it indoors?
<rick_h> yea, but it's not heated. 
<rick_h> just a large warehouse style building
<rick_h> so protected from the elements, but no promise it won't get cold in there
<hatch> ahh gotcha
<rick_h> hatch: is your branch up for review? /me missed that go by
<hatch> I am just lboxing now
<hatch> from my laptop though so it'll take 4 evaaaa
<rick_h> ah, ok. 
<hatch> rick_h: I'd like it if you could QA this because it needs a QA on all three backends but I realize it's past your EOD https://codereview.appspot.com/13252045/ so tomorrow would be fine too
<huwshimi> Morning
<hatch> mornin huwshimi
<gary_poster> hi huwshimi.  my wife is still at dr.  I'll ping you when I am available.  hopefully soonish
<huwshimi> gary_poster: No problems, any time.
<gary_poster> bcsaller, did you ever get your necessary reviews?
<huwshimi> gary_poster: Happy to postpone if it's getting to late for you. We'll be in the same room on Monday :)
<bcsaller> gary_poster: one LGTM and now we are down to one with requests for tests paralleling the service module
<gary_poster> huwshimi, heh, true, but I think we should talk.  can do it now.  you ready?
<huwshimi> gary_poster: Yep
<gary_poster> bcsaller, oh ok, so two reviews but one response in progress, cool thx
<hatch> gary_poster: whenever you have a moment - do we have a mockup for the way the unit relation view is supposed to look like? Or just make it look decent?
<gary_poster> hatch, no mockup.  decent, based loosely on existing design (which is engineer design, but whatever :-) )
<hatch> hey, I've always said engineers develop the best UI because it's the most efficient lol
#juju-gui 2013-08-30
<gary_poster> :-)
<antdillon> Hi guys, is there anyone online from the juju gui team?
<rick_h> antdillon: yep
<antdillon> rick_h, Hey, thanks. Just a quick question about the browse section of jujucharms.com 
<rick_h> antdillon: sure thing
<antdillon> rick_h, Were linking directly to charms from the new juju.u.com website
<rick_h> antdillon: ok
<antdillon> rick_h, For example using this URL: https://jujucharms.com/precise/mongodb-15/
<antdillon> rick_h, Is there a way to link that wont go out of date?
<rick_h> antdillon: yep, so for now it needs to be -HEAD vs -15
<rick_h> antdillon: in the future we hope to be able to drop that, but it's not complete yet
<antdillon> rick_h, As in https://jujucharms.com/mongodb-15/
<rick_h> antdillon: oh...ditch the precise...ugh no. We don't have anything for that and not sure it would work as most charms don't exist outside of precise atm
<antdillon> rick_h, Because we dont want to link them to percise when saucy is out
<rick_h> https://jujucharms.com/fullscreen/search/?series=raring&text= for instance is raring's charm list
<rick_h> antdillon: yea sorry, we'll have to deal with updates when we know we want to update them. I don't think you'll want saucy links when saucy is out
<rick_h> antdillon: you'll want to use https://jujucharms.com/precise/mongodb-HEAD
<antdillon> rick_h, Ok cool, I'll leave it with precise in the url
<antdillon> rick_h, Thanks for the help. Might be worth thinking about creating short links to the charms for sharing
<rick_h> antdillon: yep, it's a bit complicated since you need to match your juju environment version to the charm version and such
<rick_h> antdillon: but will bring it up on the call today and might be a good sprint topic in Oct
<antdillon> rick_h, https://jujucharms.com/precise/mongodb-HEAD/ the tweet link tweets to https://jujucharms.com/precise/mongodb-15/
<rick_h> antdillon: yea, we should fix that. -HEAD is relatively new
<antdillon> rick_h, Cool thanks
<gary_poster> hey antdillon.  charms are per series, and generally in Juju we care about the LTS charms not the dev/6 mo. release charms.  So what you raise is an interesting question but not pressing until we start thinking about T/14.04
<gary_poster> (the next LTS IIRC)
<antdillon> gary_poster, Cool I understand
<gary_poster> cool
<antdillon> gary_poster, So should use -HEAD for all charms?
<gary_poster> antdillon, yes, for now.
<bac> gary_poster: i'm here today
<gary_poster> yay bac!  100%, or?
<gary_poster> as in feeling 100%
<bac> no, but i'm faking it.  :)
<gary_poster> bac, heh, ok, take it easy
<marcoceppi> hey guys, what does the charm use to serve the pages? Apache?
<gary_poster> marcoceppi, atm, yes.  with bundle work upcoming, it will be a custom Tornado server
<gary_poster> marcoceppi, btw, one of hatch or Makyo will join you guys in doc sprint when their day starts in a few hours
<luca__> can someone tell me the commands in the CLI to import and export a bundle or charm to Juju?
<luca__> gary_poster: rick_h ^
<rick_h> luca__: I'm not sure I've not tried it out yet :/
<rick_h> bac: or marcoceppi do you know?
<luca__> rick_h: useless! :P
<gary_poster> luca__, you use the juju deployer, not the CLI
<rick_h> luca__: as usual :)
<gary_poster> I mean, that is the CLI, not juju itself :-)
<marcoceppi> luca__: there is no cli yet, though I'm trying to write a plugin for it
<marcoceppi> For exporting an environment
<marcoceppi> importing you use juju-deployer
<gary_poster> marcoceppi, I thought Kapil was working on the exporter, or had one?
<luca__> so if I want to import and export something now via the terminal, how do I do that?
<marcoceppi> gary_poster: maybe? we had jitsu export, but those aren't compatible IIRC
<luca__> I want the commands for the juju.ubuntu.com website
<gary_poster> marcoceppi, yeah I thought Kapil was adding it to deployer.  maybe a good idea to sync up with him
<marcoceppi> gary_poster: ack, thanks
<gary_poster> luca__, there is no export command at this time
<luca__> gary_poster: right
<luca__> gary_poster: ok
<luca__> gary_poster: and is there a way to interrogate the charm store via the command line? like search for stuff? see a list of charms?
<marcoceppi> luca__: there's a set of tools called `charm-tools` that can search the store and list charms
<rick_h> luca__: oh oh, this one I do know :P
<marcoceppi> luca__: they're being rewritten to be executed as `juju charm search`, etc
<rick_h> marcoceppi: oh, heads up, api3 with bundle support is coming soon
<rick_h> marcoceppi: in case this is what's using the charmworld api
<marcoceppi> rick_h: I have no idea what that means, but is sounds awesome
<gary_poster> luca__, for import...I think it is nasty: you have to get a certain branch (https://code.launchpad.net/~juju-deployers/juju-deployer/darwin) and then...I forget
<gary_poster> I mean, nasty in comparison to "install package foo"
<luca__> marcoceppi: how soon will that happen?
<marcoceppi> luca__: you can install charm-tools right now and use them as `charm search`, `charm list`, etc
<frankban> guihelp: could anyone please review https://codereview.appspot.com/13424043 ? thanks!
<rick_h> marcoceppi: I linked you to http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/api.rst so it means a nwe version of the api with bundles support is coming 
<marcoceppi> luca__: it's got a lot of tools actually, ppa:juju/pkgs to install charm-tools
<rick_h> frankban: looking
<frankban> rick_h: thank you
<marcoceppi> rick_h: ah, awesome! will v2 stay around for a while?
<rick_h> marcoceppi: yes, but won't get bundles so limited to old scope
<marcoceppi> rick_h: ack, thanks for the heads up
<gary_poster> luca__, this is pertinent to your deployer import questions: https://docs.google.com/a/canonical.com/document/d/1i_sdbswSovHygc8URsh30zTBx_2G9VZBLlb3qbUmfCM/edit#heading=h.8dx2qatdl279
<gary_poster> luca__, prerequisites section and #1 of "Steps to be done in front of  a live audience"
<luca__> gary_poster: I see, thanks
<hatch> morning
<rick_h> hatch: morning, want to chat when you get your morning cup of joe please
<hatch> rick_h: prolly won't be for another 30
<rick_h> hatch: np, just putting in first dibs since you stuck your head up :P
<gary_poster> morning hatch. :-)  You and/or Makyo are scheduled to join in doc sprint today.  I'm loathe to lose either of you, but given constraint and inspector work, I'm inclined to ask Makyo to do it.  That postpones his Go relation work.  Is that ok?
<abentley> bac: I'm documenting the 3.0 API.  It looks like a 3-part bundle-id is always treated as owner/basket/bundle, never basket/revision/bundle.  Do we consider this a bug?
<hatch> gary_poster: yep that'll be fine, I would like to push to get the inspector unflagged
<gary_poster> great hatch, thanks
<benji> bac: I think you worked on the view that renders /bundles/{basket}/{bundle}/json.  Is that right?
<hatch> frankban: thanks a ton for the QA/review I'll look into fixing that shortly
<frankban> hatch: np
<bac> benji: yes
<rick_h> benji: abentley we have a view /json? 
<hatch> luca__: antdillon hey guys looks like the place in Heathrow that sells sims is in terminal 1 security and I land in 3, do you know of anywhere else close that I should go to pick up a sim card?
<benji> bac: I can't seem to see a view for /bundles/{basket}/{bundle} (no "json"), do you know if that exists?
<abentley> rick_h: I didn't think so.
<rick_h> abentley: yea, that was the 'old' api stuff so same to dupe it over 
<antdillon> hatch, Near terminal 3 or the office?
<abentley> rick_h: "same to dupe it over"?
<rick_h> abentley: /same/shame to pull that convention over
<abentley> rick_h: +1
<bac> benji: no it has not been implemented as it was going to be part of the SEO work
<hatch> antdillon: well I plan on going from the airport to the science and natural history museum (sunday) so i'd like to get it before then but close to the office would suffice as well and I can pick it up Monday
<benji> bac: ok, thanks for verifying 
<frankban> gary_poster: I am going to 1) test the charm-upgrade + set builtin-server story, 2) make fixes if required and then 3) merge juju-gui into charmers. is it ok?
<gary_poster> frankban, yes, thank you!
<bac> abentley: i'm not sure about your question based on the URLs we listed in the google docs "spec".
<abentley> bac: So, on API 3, there's a way to get a specific revision of an unpromulgated charm: owner/basket/revision/bundle.  For a promulgated charm, basket/revision/bundle won't work.  That seem asymmetrical, though perhaps the intent is that you use owner/basket/revision/bundle for that, too?
<antdillon> hatch, You should be able to walk into any phone shops in london and pick up a sim card. There are hundreds in london (like starbucks)
<bac> abentley: that is my recollection of the discussion.  if we have a use case for the api to support unrevisioned access let's list it in the doc.
<abentley> bac: We already have unrevisioned access.  What we don't have is revisioned access with unspecified owner.
<bac> abentley: how would that work?  revisioned access for a bundle with no specified owner?  two different people could have a given (basket, bundle) at the same revision.  which do we pick?
<abentley> bac: We would pick the promulgated one, as we do for two-element bundle ids like "basket/bundle".
<hatch> antdillon: ohh ok :) any certain network I should try and get on?
<hatch> I'll likely be using primarily data
<antdillon> hatch, EE is good, I use them. You might be able to get 4G?
<hatch> ahh cool
<hatch> I think I am stuck on GSM because of the radios in my phone
<hatch> they use a different 4g frequency here I think
<antdillon> hatch, Then you'll be flighting, 4G is faster then most wifi's
<hatch> yeah that's the same here
<antdillon> hatch, Ah ok
<hatch> I just don't want to spend $0.65/txt, $2/min, $15/MB :)
<antdillon> Of course, that's nuts!
<hatch> I think I'll add everyone to my G+ and then use hangouts to communicate once I Have data
<hatch> assuming others have data....
<jcsackett> rick_h: can i get you to look at https://codereview.appspot.com/13289046 ?
<rick_h> jcsackett: sure thing
<abentley> rick_h: We were going to have "/download" for bundles so that deployer could use those urls directly.  bac changed "/download" to "/json" for consistency with charms.
<gary_poster> jcsackett, I didn't see you were back.  how are you?
<rick_h> abentley: not following. What's /download for?
<jcsackett> gary_poster: i'm alright. tho my typing speed is considerably slower. :-P
<gary_poster> jcsackett, ack.  glad you are on the mend.  not sure if I want to hear exactly what happened or if I would faint. :-)
<abentley> rick_h: $juju deployer -c http://manage.jujucharms.com/bundles/~owner/basket/revision/bundle
<rick_h> abentley: ah, interesting. I didn't realize that deployer was grabbing from charmworld vs the store like charms. 
<abentley> rick_h: We don't store bundles in the store at all.
<rick_h> abentley: ok, so ignore me if /json isn't part of matching the deprecated api 
<marcoceppi> Found a weird bug in the GUI
<rick_h> abentley: hmm, so the deployer won't set the json request headers to send the response on headers vs url change?
<rick_h> marcoceppi: shoot man
<abentley> rick_h: I still think it should be /download, not /json.
<rick_h> abentley: yea, I'd prefer that it send content-type in the request but oh well
<abentley> rick_h: putting it in the URL rather than request headers makes it much easier for a user to control.
<rick_h> abentley: yea, understand. 
<abentley> rick_h: Also, we can provide a download link that way.
<marcoceppi> rick_h: yesterday I searched and visisted ~marcoceppi/precise/discourse, which took me to ~marcoceppi/precise/discourse-20. So I went to -HEAD because I wanted to refresh it after I updated the charm in the store and watch the magic. Now when I search the URL it takes me to is -21 but the content is still -20 (as well as -HEAD) it's like there's some severe cache or something
<marcoceppi> rick_h: does https://jujucharms.com/~marcoceppi/precise/discourse-21/ show location as -20 ?
<rick_h> marcoceppi: yea, looking
<rick_h> marcoceppi: and shows head as r64?
<rick_h> marcoceppi: maybe ingest error on changes?
<hatch> rick_h: ready when you are
<rick_h> marcoceppi: run proof?
<rick_h> hatch: I'm good I think.
<marcoceppi> rick_h: just shows a W about hook not executable
<hatch> rick_h: ok in guichat
<marcoceppi> rick_h: the change was purely hook based, nothing in metadata changed
<marcoceppi> but the serach results show the right version (commits and downloads)
<marcoceppi> and takes me to -21
<rick_h> marcoceppi: will have to look into staging to see if there's an import error
<marcoceppi> rick_h: ack, gotchya
<rick_h> marcoceppi: I'm all confused, the branch is r64, the rev in the file is 17
<rick_h> marcoceppi: so not sure where the 20/21 is even coming from tbh
<marcoceppi> rick_h: that's charm-store version
<marcoceppi> rick_h: which is independent of bzr version and local revision file
 * marcoceppi holds back on this
<rick_h> marcoceppi: k, will check in a sec.
<abentley> bac: When a 3-element bundle-id is specified, it looks like we treat the three elements as owner, basket, bundle, but then we return only promulgated bundles.  Is this a bug?
<adeuring> abentley: could have a look here: https://code.launchpad.net/~adeuring/charmworld/spurious-failures-2/+merge/183183 (a bit longer than the core 5 lines I expected yesterday, but not terribly long either...)
<abentley> adeuring: sure.
<abentley> adeuring: r=me.  Thanks.
<adeuring> thanks
<bac> perhaps it is abentley.  please file a bug or make a note in the doc if you wouuld.
<abentley> bac: I've filed bug #1218949
<_mup_> Bug #1218949: Cannot retrieve head revision of an un-promulgated bundle over API 3. <charmworld:Confirmed> <https://launchpad.net/bugs/1218949>
<bac> thanks abentley
<rick_h> jcsackett: inboud
<rick_h> marcoceppi: cool yea seeing the store sees https://store.juju.ubuntu.com/charm-info?charms=cs:~marcoceppi/precise/discourse 21
<rick_h> bac: gary_poster there's a config conflict in comingsoon it looks like?
<rick_h> http://comingsoon.jujucharms.com/juju-ui/assets/config.js
<bac> rick_h: i'll look
<gary_poster> than kyou
<rick_h> thanks bac 
<hatch> ok now where was I
<rick_h> abentley: have a sec to give me a hand searching this issue for marcoceppi?
<abentley> rick_h: sure.
<rick_h> abentley: guichat?
<abentley> rick_h: yup.
<bac> rick_h: try now
<gary_poster> Hey Makyo, I want to reply to rogpeppe's email in which he asked me what the ordering change was that broke the GUI.  IIRC, new relations were being sent before services?  That doesn't sound right unless the deployer was involved.  any quick details I can pass on?
<Makyo> gary_poster, units before services; when we were receiving units after services, the delta triggered adding the unit to a ModelList attached to the service.  If it was before, the service didn't exist.  The solution was sorting the deltas 
<gary_poster> cool thanks Makyo, will pass on
<rick_h> marcoceppi: so working on it still, it's fine on staging http://staging.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21 and the proof errors listing in production appears to only do reviewed charms so filed #1218966, 
<_mup_> Bug #1218966: proof errors appear to only display for revewied charms <charmworld:Triaged> <https://launchpad.net/bugs/1218966>
<rick_h> marcoceppi: have to go to IS now and have them help get at the logs on production to see what error is thrown. Note that, on production, it stopped at r60, so r61 probably introduced something it didn't like. https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21
<marcoceppi> rick_h: thanks, I wanted to blog/share that link eventually, so I appreciate you looking in to it
<frankban> gary_poster: charmers' charm is up to date
<gary_poster> awesome, frankban thanks.  Do you want to send out an announcement/request for testing, or do you want me to?
 * marcoceppi looks at rev 60
 * marcoceppi 61*
<frankban> gary_poster: please do it, thanks! for the jujucharms.com upgrade i'd wait till Monday
<gary_poster> ack frankban, completely agree :-)
<frankban> gary_poster: the upgrade being: 1) upgrade-charm and 2) set builtin-server=true
<gary_poster> cool
<rick_h> frankban: gary_poster does the constraints issue that hatch is working on effect release though? e.g. will users end up not beign able to deploy?
<gary_poster> rick_h, no.  frankban made a charm release not a gui release
<hatch> with the new inspector
<rick_h> gary_poster: k, ignore me then. 
<gary_poster> :-) np
<rick_h> marcoceppi: heads up that I do see these errors http://paste.mitechie.com/show/1012/ not sure if those are outdated or what. 
<hatch> my laptop has been acting up today.......plz don't break plz don't break plz don't break
<marcoceppi> rick_h: redmine and charm-helper are dead and gone, not sure why it's pulling those
<frankban> gary_poster: FWIW, we can know from the outside if a GUI is run by the Tornado server visiting the /gui-server-info URL (without the trailing slash)
<gary_poster> ah cool frankban good to know, ty
<jcsackett> rick_h: thanks for the review. good catch on the needed cleanup.
 * benji wonders if the call time has changed.
<hatch> jujugui - guichat 4 mins ago!
<Makyo> hatch, calendar says 9:30?
<hatch> for real???
<gary_poster> jujugui postponed 30 minutes
<hatch> lol
<hatch> oops we all missed that
<abentley> bac or benji: could you please review https://code.launchpad.net/~abentley/charmworld/api3-docs/+merge/183206 ?
<benji> abentley: I'll take a look
<abentley> benji: Thanks.
<Makyo> jujugui call in 10 kanban now.
<rick_h> abentley: why is bundles/bundleid plural?
<abentley> rick_h: I don't know.  I didn't implement it.
<rick_h> abentley: ok
<rick_h> abentley: r=me
<abentley> rick_h: Thanks, but benji was looking at that.
<rick_h> abentley: ok
<rick_h> abentley: well, you can have two, figured I'd peek at since I'll be looking shortly
<abentley> rick_h: Cool.
<benji> abentley / rick_h: well if we have one, that is enough
<benji> I did enjoy the ASCII art table, though.
<rick_h> benji: abentley bac is there any opposition to dropping the s on bundles/bundleid for consistency ?
<abentley> benji: Yay for ASCII art in ReST.
<abentley> rick_h: I am in favour of dropping the s.
<benji> abentley: if you /really/ like reST tables, have I got something for you: http://pythonhosted.org/manuel/table-example.html#fit-table-example
<benji> (and that document which shows how to write tests to test documents, itself includes tests to show that the document is correct)
<gary_poster> jujugui call now
<bac> rick_h: i am not opposed.
<rick_h> bac: yay!
<gary_poster> jcsackett, ping for call if you can come
<rick_h> bac: can you drive by that on your current work or should I create a seperate branch?
<bac> rick_h: i'll do it as a follow-on.  i'll make a card
<rick_h> abentley: filed a bug based ont he log from prod. https://bugs.launchpad.net/charmworld/+bug/1219001
<_mup_> Bug #1219001: production error on several charms "KeyError: 'branch_deleted'" <charmworld:Confirmed> <https://launchpad.net/bugs/1219001>
<rick_h> abentley: looks like a bunch of charms are hitting this keyerror and don't get ingested
<hatch> jujugui ok well if anyone wants to mee up sunday during the day or for supper/after pm me your cell #
<abentley> rick_h: saw.  Huh.
<gary_poster> hatch, I'll probably email you in that case.  won't have data
<gary_poster> if you miss it np
<hatch> gary_poster: sure thing - my plan is to head from the airport to get a sim then to the science/history museum
<gary_poster> ok cool
<hatch> texts cost me $0.65 so I want to get that new sim asap :)
<frankban> gary_poster: I've found a charm bug in the wss url handling when a real pyjuju env is used. Will self review, land, and include in charmers ASAP: https://codereview.appspot.com/13432043
<abentley> rick_h: I don't understand how we get that far without setting branch_deleted.
<gary_poster> thank you frankban 
<hatch> frankban: so in moving the constraints stuff into the env/store/python.js deploy method that fixes rapi and go sandbox but breaks python sandbox :/
<hatch> so not sure what's up with that....sandbox must be broken
<frankban> hatch: ISTM that the python sandbox still expects to be able to call deploy passing an array of constraints
<frankban> hatch: maybe?
<abentley> rick_h: That data should already be set when charms are enqueued.
<rick_h> abentley: k, did you want the log file?
<hatch> frankban: so I put the formatting in the deploy method in python.js so it's breaking somewhere after the rpc call
<abentley> rick_h: Yes, please.
<rick_h> abentley: it's 30M compressed so didn't send/attachj it
<hatch> so must be fakebackend.js is broken then?
<rick_h> abentley: uploading, will take a sec
<frankban> hatch: and sandbox receives the rpc call right?
<hatch> frankban: I can never remember the sequence of events, putting in breakpoints now heh
<rick_h> marcoceppi: got the logs off production there's a bug for it to follow #1219001. Sorry for the issue
<_mup_> Bug #1219001: production error on several charms "KeyError: 'branch_deleted'" <charmworld:Confirmed> <https://launchpad.net/bugs/1219001>
<hatch> frankban: found the problem, it's in the Service model
<frankban> gary_poster: charmers updated
<frankban> hatch: interesting
<abentley> rick_h: I don't see any KeyError on branch_deleted since June 13.  I don't think it can be the cause of this issue.
<rick_h> abentley: oh, crap I went to the end of the file and searched backwards for discourse and didn't read the timestamp :/
 * Makyo runs to go get the phone unlocked for real.
<rick_h> abentley: oh...then my bad, let me invalid that bug and go back. 
<frankban> hatch: constraintsStr getter?
<marcoceppi> rick_h: oh, branch_deleted ?
<rick_h> marcoceppi: ignore me, I found an error in the log from a month ago..back to researching
<hatch> frankban: yeah - I don't see any other place to modify the constraints data
<rick_h> whoa, just lost power...on laptop battery atm. 
<frankban> hatch: good luck, and have a nice weekend!
<rick_h> note to self, put desktop on UPS
<hatch> frankban: could change it back in the fakebackend
<hatch> frankban: you too! see you Monday/Tuesday
<rick_h> yay power is back
<hatch> I don't know anyone else with an off brand phone with a micro sim hah, guess I'll just have to buy the unlock code and hope it works once I get there :)
<rick_h> abentley: so I don't see anything in the log. I do notice that discourse r64 is listed in the http://manage.jujucharms.com/recently-changed view
<rick_h> abentley: so now wondering if there's a mongo vs ES issue? is recently changed pulled straight from mongo while the charm data is pulled from ES? or not true?
<hatch> oh sweet check out the new relation lines on the GUI http://www.ubuntu.com/cloud (scroll down)
<gary_poster> heh cool
 * hatch wonders who's repo that's in lol
<hatch> I actually think they look pretty cool
<hatch> of course they are missing the labels but the green adds some nice color
<hatch> it could even indicate relation status (if there is such a thing)
<hatch> rick_h: so documentation to get the lxc and go stuff up and running?
<hatch> unless you just want to QA this branch for me and we can do that later
<hatch> (would be my preference :) )
<rick_h> hatch: :P I can QA
<rick_h> hatch: http://marcoceppi.com/2013/07/compiling-juju-and-the-local-provider/ is what I went with
<rick_h> well, some of that, not all needed
<rick_h> environments is a 2-liner change and juju switch ftw
<hatch> rick_h: ok just linting and making sure the tests pass then I'll repropose
<hatch> thanks
<rick_h> hatch: rgr
<hatch> I just really want to get this landed instead of potentially fighting getting the system up and running
<marcoceppi> hatch: I recommend just using juju-core from ppa:juju/devel, the local provider afterwards is pretty easy
<hatch> marcoceppi: so instead of compiling from source
<rick_h> hatch: yea, don't compile
<rick_h> I didn't do that part
<hatch> ok cool - I'll keep notes of what I do then and write another blog post about it
<rick_h> just ppa and then walked through the rest for environment/starting up
<hatch> can't hurt right? :)
<rick_h> hatch: +1
<marcoceppi> hatch: Yeah, that was me being lazy and killing two birds with one blog post
<hatch> lazy lazy
<hatch> hey are you still in Japan?
<hatch> I just realized it's probably 2am there if you are :D
<rick_h> abentley: guess not, both _find_charm and series_charm_changes are on mongo
<hatch> rick_h: https://codereview.appspot.com/13252045/  this fixes the bug but not frankbanks request to normalize the config formatting
<hatch> that's coming soon, just wanted to get that bug qa'd first
<rick_h> hatch: ok, so I'm doing the -core qa section?
<hatch> yes plz
<hatch> rick_h: wouldn't hurt to do the others too, it's pretty quick
<rick_h> hatch: ok, starting up
<hatch> thanks
<jcsackett> rick_h: did you QA my branch, or do i need to hunt down QA?
<rick_h> jcsackett: sorry, did not QA. I can shortly
<abentley> rick_h: It looks like something is wrong with the way we find the head revision in mongo.  I don't know whether it's a bug in the data or a bug in the code.  Elasticsearch does recognize that 21 is the head revision.
<abentley> rick_h: I thought recently-changed was all-mongo.
<rick_h> abentley: yea, I think it is. Both seem all mongo. 
<rick_h> abentley: sorry, back/forth in qa'ing/etc. 
<rick_h> abentley: so the api uses sort=[('store_data.revision', pymongo.DESCENDING)])
<rick_h> abentley: and the charm_changes don't specify a sort :/
<abentley> rick_h: This uses elasticsearch: https://manage.jujucharms.com/api/3/search?series=precise&owner=marcoceppi&name=discourse
<jcsackett> rick_h: cool, thanks.
<rick_h> abentley: right, but https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-21 is what I was looking at pulling old data
<rick_h> abentley: that's using charm/_find_charm right?
<rick_h> abentley: we were looking at why https://manage.jujucharms.com/api/2/charm/~marcoceppi/precise/discourse-HEAD returns rev 60 in the changelog and links to disource-20
<abentley> rick_h: Right, it's using _find_charm.
<marcoceppi> So, when does this UI show up? http://www.ubuntu.com/cloud
<abentley> rick_h: And I'm saying I don't know whether it's a bug in the code or the data, but Elasticsearch looks right.  So it's less likely to be a bug in the data.
<rick_h> abentley: right, gotcha
<abentley> rick_h: Because we update them in sync.
<rick_h> abentley: I figured since the recent changed had the data it was maybe how the query/data was looked at
<abentley> rick_h: Haven't had a chance to look at that implementation yet....
<rick_h> hatch: I can't deploy anything. I get the error "Could not deploy the requested service." with/without constraints
<hatch> what's the error in the console?
<rick_h> abentley: can I hand this off to you then? I've got to qa hatch and jcsackett's stuff atm and you're closer to the action
<rick_h> hatch: none :/
<hatch> guichat?
<rick_h> hatch: sure
<abentley> rick_h: okay.
<rick_h> hatch: if it'll load for me
<rick_h> hatch: invite me in please
<hatch> ok sec
<rick_h> jujuhelp how would I get debug js files in a charm deployed jujugui?
<jcastro> hey rick_h 
<jcastro> do you have sinzui-like powers for the store?
<gary_poster> rick_h, look in charm options.  looking for you...
<jcastro> actually, I mean abentley 
<rick_h> jcastro: how so?
<rick_h> gary_poster: yea, don't see any 'debug' charm options
<jcastro> so we renamed the rack charm to "rails"
<jcastro> https://jujucharms.com/fullscreen/search/precise/rails-1/?series=precise&text=rails&type=approved
<jcastro> but this is not showing the proper charm
<jcastro> mims said something like "they need to flush"
<gary_poster> rick_h, :-( you are right. I think t must be conflated.looking
<abentley> jcastro: I don't think he has special powers.  I think he has to hand-craft urls, but I can do that, too.
<jcastro> awesome
<rick_h> gary_poster: i've tried logging into the service and running make devel, but then it can't talk to the back end
<abentley> jcastro: You know that the store doesn't have a concept of rename, right?
<rick_h> gary_poster: I tried to set the back end to go, no sandbox, and I just get ws errors
<jcastro> abentley: hah, nice.
<rick_h> gary_poster: I assume I'm missing whatever listens on the ws end for go
<m_3> abentley: hi
<m_3> abentley: so we just need to get any cache related to lp:charms/rails and lp:charms/rack regenerated
<gary_poster> rick_h, I'm guessing source mapping is insufficient
<abentley> m_3: Why do you say that?
<m_3> abentley: so we removed lp:charms/rack
<gary_poster> rick_h, staging turns on debug mode :-(
<m_3> abentley: and pushed an --overwrite to lp:charms/rails
<gary_poster> we should have a separate flagfor that
<rick_h> gary_poster: yea, ok cool
<m_3> abentley: the overwrite was from a lp:~charmers/charms/precise/rack/trunk branch
<m_3> abentley: and there is no longer a ~charmers owned "rack" branch
<m_3> so flushing those from the cache and re-injesting lp:charms/rails should handle the changes we need
<abentley> m_3: There is nothing that would make the "rack" charm disappear.  The charm store deliberately never deletes anything, regardless of whether you delete the branch.
<m_3> abentley: ok, that's secondary to getting it to recognize the overwrite of lp:charms/rails
<m_3> abentley: note that the previous version of lp:charms/rails had bzr revno of like 44... the new one has like bzr revno of 11 or 12
<abentley> m_3: Are you talking about the charm store or the charm browser?
<m_3> abentley: both ideally... I haven't tested if the store is seeing the latest... only the browser
 * m_3 testing store now
<rick_h> gary_poster: ping, can you join guichat?
<gary_poster> rick_h, yes, 60 sec
<abentley> m_3: This looks related to the issue marcoceppi was having; If you search, you find precise/rails-1, but when you try to look up precise/rails-1, you get precise/rails-0.
<abentley> m_3: I think it is unlikely that clearing squid is going to change that.
<m_3> abentley: bummer
<m_3> abentley: any suggestions?
<abentley> m_3: I am already trying to diagnose this bug.  Your case is helpful, because I can reproduce it on staging, where it should be much easier to diagnose.  But it's on me.  There's not much you can do directly to solve it.
<m_3> abentley: yeah, marco described his issue... sounds like the same
<m_3> abentley: thanks!
<hatch> gary_poster: U. Da. Man.
<gary_poster> hatch, lol, yay!
<abentley> rick_h: I believe you were looking at the API3 version of _find_charm.  The API2 version lacks the sort, and I think that's the code path on production.
<rick_h> gary_poster: so yea, it needs to be an int and it works in the constraints
<rick_h> gary_poster: thanks
<gary_poster> cool rick_h ! thank you both :-)
 * gary_poster continues writing emails :-P
<rick_h> abentley: oh! yea
<rick_h> abentley: should be able to tell by changing the api version in the same request, /me tries it
<Makyo> jujugui: those going to London, if you want to take the Heathrow express instead of Piccadilly (15m vs. 60m): https://gist.github.com/makyo/6393509
<rick_h> abentley: hmm, that didn't get it though https://manage.jujucharms.com/api/3/charm/~marcoceppi/precise/discourse-HEAD
<gary_poster> cool Makyo thanks
 * rick_h is going to get lost at least twice
<Makyo> Phone won't unlock, so I won't be reachable.
<bcsaller> Makyo: you'll still be able to use public wifi many places though so it can be a help
<Makyo> bcsaller, Yeah, still bringing it, of course, just no need giving out my number.
<abentley> rick_h: I don't know what revision production is on, but I am certain it's before 371, because it accepts any random number for revision in API3: http://manage.jujucharms.com/api/3/charm/precise/rails-5
<Makyo> $50 for those stupid unlock codes :P
<rick_h> abentley: ah, nvm then
<hatch> Makyo: $25 http://www.cellunlocker.net/
<hatch> Makyo: also thanks for the tip about the express
<abentley> rick_h: staging is on r373, so on staging, API 3 pukes if you give it a non-existent revision.
<Makyo> hatch, I have the codes, I mean, I just can't unlock a rooted phone, and I can't unroot it right now.
<hatch> what phone?
<hatch> you should be able to unlock it without a code if it's rooted
<bac> jujugui: at the top of the hour i'm going to turn off the cronjob that pulls new releases to comingsoon in preparation for a demo on monday.
<benji> sounds good
<hatch> bac: with the new or old inspector?
<bac> hatch: as it currently is on comingsoon
<hatch> ahh ok that should be fine then
<hatch> just can't deploy using rapi is all
<hatch> with the new inspector that is
<gary_poster> hatch, the reason behind this is that the inspector will be demoed Monday in an official capacity (see peeps list)
<gary_poster> jujugui we don't have times on the spreadsheet.  I'm arriving Sunday morning at 7AM.  Anyone else similar?
<hatch> 9:30
<hatch> gary_poster: if you click on them the time is in the top bar
<gary_poster> oh!
<hatch> someone formatted it incorrectly
<bac> gary_poster: you get the direct on AA?
<Makyo> gary_poster, I formatted it to datetime
<gary_poster> bac, yeah
<hatch> Makyo: thanks
<bac> cool.
<gary_poster> oh thanks Makyo awesome
<gary_poster> Jeff I might not wait for you at the airport, but if you want to hang out we can
<gary_poster> hatch I mean :-)
<hatch> I wouldn't wait for me either :P
<hatch_> rick_h, https://gist.github.com/hatched/e72f3db21afec05592b3 solution :D
<jcsackett> rick_h: any luck QAing?
<hatch> bcsaller: Makyo mind taking a peek at that gist I posted above... I need to loop through a list of constraints (of any kind) and convert the numbers to integers but leave the strings alone...this technique works by running parseInt and then comparing the two values with type cooersion - thoughts?
<bcsaller>  checking
<Makyo> hatch, sure
<Makyo> hatch, When I ran `juju set-constraint mem=2G` with core on the command line, the gui reported it as 2048.  This would set it to 2 if I use 2G, correct?
<Makyo> '...if I use 2G in the gui, correct?'
<gary_poster> Makyo that might be a commandline trick unsupported by the API
<rick_h> jcsackett: bah, sorry. hatch's qa'ing ran crazy and I didn't get to it
<gary_poster> either way we should document it, and maybe make it nicr
<hatch> MakyoL if you typed 2G in the input then it would send 2G to the back end and fail
<hatch> we will need client side formatting for these constraints for sure
<Makyo> hatch, constraints[cons] = parsed would set it to (int)2, right?
<gary_poster> but making it nicer might be a separate step for later.  for now "send an int in M" would be nice help text
<hatch> yes but consVal != parsed in that case
<hatch> so it would set it to the string value
<gary_poster> well, not that exactly :-P
<rick_h> jcsackett: link me please? pulling back up my lxc
<bcsaller> hatch: I don't think this is proper, you might want to check if it can parse as a number and apply a mapping but if things like 2G need support then its either fancier or a passthrough 
<Makyo> Oh, sorry, was mistaken about the ==.  Alright.
<BradCrittenden> jujugui: comingsoon locked down at r992
<hatch> bcsaller: the Go backend requires they be ints
<gary_poster> thank you bac
<bac> until monday this time
<hatch> but we also need to support things like 'i386'
<hatch> so we can't simply parseInt all fields
<hatch> some need to be strings, some don't
<bcsaller> also I'd do the loop with Object.key(constraints).forEach(...), for..in sometimes ends up with issues
<bcsaller> the linter will ask for that ifOwnProp check
<hatch> not if i turn that off :P
<hatch> but anywho....the technique though....that should work?
<rick_h> jcsackett: nvm, got it, qa'ing now
<hatch> I haven't found any situations where it fails
<hatch> js's type cooersion works pretty well here
<hatch> bcsaller: (ps yes I will change it to keys() ) :)
<hatch> going to grab some lunch, thanks for looking at that
<rick_h> jcsackett: fullscreen doesn't work for me :/
<abentley> rick_h, marcoceppi, m_3: I believe I understand what's going on, and I've filed the following bugs: #1219064 #1219061 #1219062
<_mup_> Bug #1219064: API 2 does not ensure the latest revision is selected <charmworld:Triaged> <https://launchpad.net/bugs/1219064>
<_mup_> Bug #1219061: charm pages do not display the latest revision <charmworld:Triaged> <https://launchpad.net/bugs/1219061>
<_mup_> Bug #1219062: Old JSON API does not ensure it retrieves the latest revision <charmworld:Triaged> <https://launchpad.net/bugs/1219062>
<rick_h> abentley: awesome...kinda. Thanks for taking that through!
<marcoceppi> abentley: thanks for looking in to it
<abentley> basically, it's the same kind of mistake in three places.
<rick_h> jcsackett: qa-no-ok let me know if you can't repeat the same issues
<gary_poster> abentley, all three are either solved in API 3, or will be solved when the GUI is forced to use API 3?
<jcsackett> rick_h: huh, fullscreen worked earlier, but isn't now. looking.
<abentley> gary_poster: as of r371, API3 is not affected, but production is not on r371 yet.
<abentley> gary_poster: The three places are API 2, the old JSON api and the charm browser views, so API3 doesn't directly affect them.
<gary_poster> ack abentley.  I just was verifying that we can effectively solve or invalidate all three issues by converting the GUI to use API 3
<gary_poster> and my takeaway is "yes"
<gary_poster> so, assuming you agree, thank you :-)
<abentley> gary_poster: That will fix the GUI, but not charmworld.
<gary_poster> abentley, only API 2 though, right?  And once the GUI uses API 3 we can regard API 2 as kaput, and related bugs as invalid?
<gary_poster> or are other important clients using API 2?
<abentley> gary_poster: I'm not talking API2, I'm talking about the web site  that charmworld provides.
<gary_poster> oh
<gary_poster> sorry for misunderstanding abentley.  got it.  thanks
<abentley> gary_poster: Anyhow, I consider these bugs critical, and trivial, so I expect to fix API2.
<gary_poster> abentley, oh ok cool.  thanks
 * benji falls into a lint pile like quicksand.
 * benji pulls himself out via a conveniently placed vine.
<benji> does anyone actually use lbox with charmworld?  the .lbox.check fails with ImportError: cannot import name MAXREPEAT for me
<abentley> benji: Sounds like you're trying to use it with the wrong python.  But no, AFAIK, no one uses lbox with charmworld.
<benji> I just figured it out as you said that.  I was using a python from my host instead of from my lxc instance.
<gary_poster> OK, I'm outta here.  Talk to everyone Monday, and see some of you!
<hatch> have a good one gary_poster - I can email/msg/hangout you when I end up with data
<hatch> see ya on the other side
<hatch> Makyo: still round? did you look into unlocking your phone while it's rooted?
<Makyo> hatch, yeah, instructions are 'unroot, unlock, reroot'.
<hatch> oh....darn!
<Makyo> So I'll just stick with wifi.
<Makyo> Both the hotel and (I'm assuming) the office will have it.
<Makyo> I can turn on int'l roaming in an emergency, of course.
<hatch> yeah would have to be one heck of an emergency for $15/MB lol
<Makyo> Hah, I was thinking for voice, granted :)
<Makyo> A True Emergency
<Makyo> In case I need to dial 0118 999 881 999 119 725 3.
<bac> i hope you didn't do that from memory
<Makyo> bac, No, but now it's stuck in my head.
<hatch> lol what is that number?
<Makyo> A joke :P  Emergency is 999, that's from IT Crowd.  http://www.youtube.com/watch?v=ab8GtuPdrUQ
<hatch> ohhh :)
<hatch> lol
 * bcsaller places computer in backpack to leave for airport
#juju-gui 2013-09-01
<hatch> ahoy
<rick_h> party hatch 
<hatch> rick_h: hey u in the hotel?
<rick_h> hatch: yep, just back from the grocery store
<rick_h> needed some viddles, this whole 'travel through the night' thing confuses the schedule
<hatch> cool, I gotta find me a SIM , everyone I found didn't have one for my phone :/
<rick_h> hatch: :( I got lucky and got one at the airport terminal. <3
<hatch> haha I've been awake for 27 hours so far
<rick_h> hatch: hit up the guys down stairs. They make a big deal of the 'ask me anything' guys at the hotel
<rick_h> hatch: let me know if you need company and maps. I've got the mifi loaded up for the week
<hatch> cool will do, I dug the 'check yourself in' thing 
<rick_h> yea, cool
<hatch> yeah we should meet up for supper
<rick_h> hatch: definitely
#juju-gui 2014-08-25
<urulama> morning, frankban
<frankban> hi urulama 
<urulama> regarding my comment on support for start/end in /meta/stats, i guess i mixed it with /stats/counter
<urulama> https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw/edit#bookmark=id.9k72szsuel9z
<urulama> which is probably the endpoint for the results for web (charm broswer), like downlaods in the last 7 days, 30 days, half year, all time ...
<frankban> urulama: yeah, so the stats counter already works for some of that
<urulama> frankban: yes, great side-effect :)
<frankban> urulama: do we really want to allow deletion of partial ids?
<urulama> frankban: deletion?
<frankban> urulama: yes, DELETE archive
<frankban> This deletes the given charm or bundle with the given id. If the id does not mention a specific series or revision, all the series and revisions of the given id are deleted.
<urulama> frankban: good point. 
<urulama> frankban: it does make sense from the API point of view. But maybe it is best to delete only concrete api and request a user to do /expand-id and iterate on all
<urulama> s/concrete api/concrete charm
<urulama> frankban: maybe we could do two phase process. delete on charm id just removes a charm from being available, but not from the store. and one needs to "confirm" later to remove all "deleted" charms from the store permanently?
<frankban> urulama: +1
<frankban> urulama: uhm, I'd be not inclined to add state to the server.
<frankban> urulama: +1 on having to specify a fully qualified url, but I'd be -1 on the two steps process: it complicates the server and also the client
<urulama> frankban: ok. then let's just do fully qualified url part (gonna change the docs)
<frankban> urulama: thank you
<urulama> frankban: working on DEL part of archive?
<frankban> urulama: yes
<frankban> urulama: creating a card
<urulama> frankban: tnx
 * urulama cooks lunch
<bac> jujugui: the internet man is on his way.  i may be going on and off line a bit in the next hour as he attempts to fix the problem.
<urulama> bac: good luck
<urulama> bac: i found out yesterday, that 100/10 line here costs only 5eur more then my current 10/10 ... will go upgrade soon
<urulama> (per month)
<jrwren_> frankban: updated https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 and https://codereview.appspot.com/132770043
<frankban> jrwren_: cool
<frankban> jrwren_: why there is no Delta from patch set in reitveld?
<frankban> jrwren_: how do you update the mp on reitveld?
 * jrwren_ looks.
<jrwren_> frankban: lbox propse
<frankban> jrwren_: uhm, that's what we are supposed to do, weird...
<frankban> jrwren_: ok, I'll take a look ASAP
<hatch> morning all
<jrwren_> morning hatch and all
<hatch> jrwren_:  so I watched some of those starcraft games this weekend, those guys are a little nuts
<hatch> haha
<hatch> I'd probably die in their scouting runs :P
<jrwren_> hatch: you watched live stream? did you see me in the crowd? :)
<hatch> I did, but no I didn't see you, the crowd was really dark and the feed was actually quite poor quality
<jrwren_> hatch: Awesome. I hope you enjoyed it. It was very fun to be there live.
<hatch> yeah I bet, I couldn't stop laughing at the start "aww they think they are real sports people"
<hatch> lol
<jrwren_> hatch: They have higher revenue than the NHL.
<hatch> well, maybe the league but not the players :)
<jrwren_> hatch: truth!
<hatch> watching some talk was like bringing be back to highschool haha
<jrwren_> hatch: how so?
<hatch> oh, well they were like 17
<hatch> so they talked like they were 17 haha
<hatch> no doubt about the skills though
<jrwren_> hatch: ha! Yes. A lot of the players are very young.
<hatch> It seems to be a very balanced game, even if one screwed up earlier in the game that wasn't a sure thing that they were going to lose
<hatch> it was possible to come back sometimes
<hatch> and the best-of-three was a good idea
<jrwren_> yup.
<hatch> they need to have an old-person league
<hatch> haha
<hatch> or maybe a minimum salary so that old people with families can compete :D
<hatch> kids don't have any money, if they want to get real money intot he sport they need adult competitors :)
<urulama> frankban: i'll take a look at the PR right after the call
<frankban> urulama: cool, I am updating it with another test
<frankban> urulama, jrwren_ : https://github.com/juju/charmstore/pull/80 is now ready for review
<jrwren_> hatch: I am pretty sure they know what they are doing, but I do wish for an old person league so I can play ;)
<hatch> jcsackett: you in yet? Can you kick ci and then kill the node server?
<jcsackett> hatch: as in restart the jenkins service?
<jcsackett> sure.
<jcsackett> hatch: though i know nothing of a node server.
<hatch> jcsackett:  when you kill the running tests in CI you then need to ssh into the machine and do a ps for the node server
<hatch> kill it
<hatch> then the tests will run again
<hatch> if you don't it'll just give an ERRADDRINUSE error
<jcsackett> hatch: it would appear restarting the jenkins process handles that; as there's no node in ps output.
<hatch> oh interesting
<jcsackett> hatch: i'm starting a build manually to make sure things can pass (or fail for the right reasons)
<hatch> I triggered another build of huws branch
<hatch> oh hahah
<jcsackett> nm, i see your build. :0
 * hatch is speedy this am
<hatch> it must have been kiting yesterday - 9C 35KM winds and pooooooouuuring rain 
<hatch> set up was bruuuuuuutal
<jcsackett> ...that's interesting, your build died almost instantly, hatch. i've started another--i think it might have been a bad sha.
<hatch> ohh maybe
<jcsackett> hrm.
<jcsackett> and this one died another way. fun.
<hatch> jcsackett:  looks like npm issues
<hatch> to the twitters!!!!
<jcsackett> yup.
<hatch> hmm no reports of it being down
<jcsackett> i suspect it's a problem with CI.
<jcsackett> largely b/c i don't like jenkins.
<jcsackett> or, more correctly, largely b/c jenkins doesn't like me. :p
<hatch> lol is it REALLY jenkins fault? Or is it that Jenkins is so magical you have no idea what broke? :)
<jcsackett> jenkins isn't really magical; it's just awkward.
<jcsackett> but it's so awkward i have no idea what's broken.
<hatch> haha true
<hatch> jrwren_: highschool doesn't start at 8:30 there? 
<rick_h_> morning party people
<jrwren_> hatch: quite often 7:30ish
<hatch> mornin mr vacation man
<hatch> jrwren_:  that's just nuts! elementary is 9 and hs is 8:30 here
<urulama> rick_h_: :) how's it going?
<jrwren_> hatch: Canada is better than the US in almost every aspect.
<hatch> haha, well education is handled at the provincial level......buuuuut I'll take it!!! 
<rick_h_> hatch: howdy, want to do me a favor? I didn't get the luca bugs turned to cards before I left
<rick_h_> hatch: can you create those, with gui class of service, etc today please?
<hatch> rick_h_:  sure
<rick_h_> hatch: ty much
<hatch> now go vacate
<hatch> vacation?
<hatch> vacationation?
<hatch> not sure what the act of vacationing is
<rick_h_> hatch: sore, very sore.
<hatch> rough plane ride?
<rick_h_> the whole walk bus carry a 4yr thing is getting long
<rick_h_> naw, just putzing around SF
<rick_h_> google and the bus drivers seem to like to disagree on how to get somewhere
<hatch> oh haha
<hatch> yeah 4y/o are getting big
<hatch> :)
<rick_h_> yea, he gets tired by the EOD makes carrying a 40# lump a bit exhausting to my own day lol
<rick_h_> but having fun, beautiful weather. Did the bay boat tour thing yesterday
<hatch> oh nice - get some good pics?
<rick_h_> we'll see, took a ton. 
<hatch> awesome 
<hatch> where to today?
<frankban> jrwren_: review done
<jrwren_> frankban: thanks.
<rick_h_> hatch: Cal acadamey of science, japanese tea gardens, and hoping to hit up a fishing pier down by the golden gate for some sunset pics
<hatch> more walkin!
<hatch> maybe you can get the kit some rollerskates :)
<hatch> kid*
<rick_h_> lol
<rick_h_> hopefully he grows some strong leg muscles :P
<hatch> haha that's also an option 
<hatch> although probably not nearly as entertaining 
<hatch> friends of ours are teaching their daughter how to rollerblade 
<hatch> holy is that funny :) of course she can't see us laugh :D
<rick_h_> there you go, he sees kids with a scooter and wants one
<rick_h_> I need to see if a store around here has one of those
<hatch> oh yeah, those are STILL big
<rick_h_> then again I might end up carrying a scooter and a boy back to the apt
<hatch> who would have thought...
<hatch> hahaha
<jcsackett> hatch: so, i ran manually via ssh, and got the npm erradinuse thing this time, but ps show's no node--is it a different process?
<hatch> ^ rick_h_ CI is borked again.....wasn't it the node process that was still running?
<jrwren_> I need one more OK: https://codereview.appspot.com/132770043/
<rick_h_> hatch: it'll either be a python or .sh process that starts the node one
<hatch> jcsackett: ^
<jcsackett> dig.
<jcsackett> thanks.
<rick_h_> jenkins  50559  0.0  0.1  41348  8164 ?        S    Aug22   0:00 python ../bin/http_server.py 8888
<rick_h_> jcsackett: hatch often it's more clean to | grep jenkins
<jcsackett> rick_h_: yeah, found it, killed it. thanks.
<hatch> cool thanks
<jcsackett> whoo! looks like tests might be running. i'll try restarting a build in a moment.
<hatch> jujugui call in 5 kanban it up!
<hatch> jcsackett: Makyo I see you guys have both interacted with this bug - I think it's resolved? https://bugs.launchpad.net/juju-gui/+bug/1340666 
<mup> Bug #1340666: Clicking the destroy icon does not destroy the machine or container <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1340666>
<jcsackett> hatch: no idea if it's fix released, but Makyo was definitely working on it weeks ago, and it sure seems like the trash icon deletes things on develop.
<jcsackett> hatch: pretty sure its safe to mark as fix committed
<hatch> thanks
<hatch> jujugui call now
<hatch> hey huwshimi
<bac> i forgot to point out my new glasses!  you are all crisper today.
<jcsackett> bac: nice. :)
<jcsackett> bac: are they also warby parker?
<bac> hey hatch how was my audio?  internet fixer came today
<hatch> jujugui sorry I forgot to mention I created cards for all of lucas bugs last week so there are a lot of cards in project 1 - some can be combined, lemme know if you have any questions about them
<bac> jcsackett: no, another boutique i found:  costco
<hatch> bac:  it was actually pretty good
<bac> jcsackett: they refused to use my old frames.  :(
<frankban> urulama: do we have a card for logging in the charmstore?
<bac> jcsackett: and i had the "dr nick" of opticians do the exam.  pony tail and everything.
<urulama> frankban: no
<frankban> urulama: ok do you want me to create one?
<urulama> frankban: we discussed it a bit with Roger, as we want to log the events in such a way, that they can be easily processed, even map-reduce style
<bac> hatch: they replaced the ethernet connector that plugs into the antenna. it is a) PoE and 2) exposed to the elements.  they should just proactively replace them every six months.
<urulama> frankban: so, there's no card for that, yet
<hatch> bac:  heh yeah maybe you could grab a few and do it yourself :) or pre-schedule the replacements
<urulama> frankban: on what level did you mean to do it?
<frankban> urulama: I am not tackling that now, but my branch includes a TODO (add logs), so I must ensure a card at least exists for logging
<jcsackett> so, much as "bad wolf" has become the default error message for tests, "yelling goats" should be our new random string.
<urulama> frankban: aaa, the new rules ;D
<urulama> frankban: i'll put one on deck
<frankban> urulama: thanks!
<bac> hatch: for the price of a set of crimpers that isn't a bad idea
<hatch> bac:  I also wonder if they have 'weather proof' ones 
<hatch> like maybe putting some of that heat-shrink-wrap stuff over it
<hatch> lazyPower: I upgraded the Ghost version in my charm this weekend and started looking into testing - can you remind me of what tests I'd need to get it promulgated in trusty?
<kadams54> jujugui: hey all, sorry I missed standup today.
<bac> jrwren_: second review on your quickstart branch.  you should be good to go now.
<hatch> it's ok, you now owe us all coffee and doughnuts 
<hatch> :P
<kadams54> Count on it.
<hatch> kadams54:  :P Did you have anything to note about your branch?
<kadams54> I'll steal them from the hotel's breakfast at the next sprint.
<kadams54> ;-)
<hatch> lol
<jrwren_> bac: Thank you.
<kadams54> hatch: No, not really. I spent most of my day on Friday working to get the last piece of the unplaced units work landed.
<hatch> ok cool 
<kadams54> hatch: Which it did. And that makes me very happy. But now it's time to forge on and get this MV stuff wrapped up :-)
<hatch> kadams54:  if you look at the kanban I created cards for all of luca's bugs last week, so there is a ton to choose from, some can be combined as well so if you are looking for something take a peek at the red ones :)
<kadams54> Excellent :-)
<urulama> frankban: done the PR review, had some comments, but when resolved, LGTM! Tnx.
<frankban> urulama: thanks
<hatch> oo mongo is getting document level locking 
<hatch> that'll be nice 
<hatch> first step to transactions :)
<frankban> urulama: I am thinking about your suggestion to delete the blob first and the entity after
<frankban> urulama: I made it like that because from the user perspective it's better to have a 404 (no entity) rather than an entity found and then a weird error because the blob is not there
<urulama> frankban: ah ... nevermind the comment, the code is correct. i somehow mixed referece=blob name, enitty=blob in my mind :)
<urulama> frankban: removing the comment
<frankban> urulama: thanks
<urulama> jujugui: EOD for me. have a good day
<frankban> good night urulama 
<hatch> night urulama
<urulama> btw, anyone watched Guardians of the Galaxy or Lucy? can't decide which one to go to watch today (both look good for some brain-shut-down time) :D
<kadams54> urulama: Guardians, for sure.
<urulama> kadams54: tnx, Guardians it is :)
<hatch> urulama:  heard great things about gotg, let me know :)
<urulama> hatch: sure thing
<urulama> A fresh advice from my friend: don't carry the kid on your shoulders when he's having an ice cream :D :D
<hatch> haha
<jrwren_> What shall I do when make test runs fine for me, but lbox submit runs make test and it fails? It seems we have different source files.
<hatch> jrwren_:  be sure you update your local source with the remote source
<hatch> that used to happen to me when the remote source and my source had diverged so the tests were no longer valid
<hatch> (not sure if that's the case here)
<jrwren_> i'll bzr pull upstream then.
<jrwren_> thanks hatch 
<hatch> worked?
<jrwren_> yes
<kadams54> jrwren_: that's good, because my suggestion was gonna be to throw something out the window.
<hatch> jrwren_:  great :) glad to help
<hatch> mbruzek: are you using the Ghost charm for your blog?
<lazyPower> hatch: he sure is :)
<hatch> awesome - ok now that people are actually using it, I'll put some more effort into it haha
<hatch> lazyPower: did you see my previous q about the tests?
<lazyPower> hatch: and re: your question this morning - bare minimum of unit tests, but we'd like to see amulet tests (you can choose one or the other depending on yoru skill level.)
<hatch> there isn't really a ton of code, I think i'll just go for amulet tests
<lazyPower> hatch: i'll ping you later this week about it, but i'm going to be moving my ghost blog from an ansible deployment to the juju charm, and document the process of how easy it was to get moving with juju to migrate a ghost blog.
<hatch> tbh I'm not entirely sure how to unit test shell-outs heh
<lazyPower> so expect some more heat around your charm.
<lazyPower> you cant.
<hatch> great (about using the charm)
<lazyPower> system calls can be stubbed if you're reading response data from the call
<hatch> boo (about unit testing shell-outs)
<lazyPower> otherwise, you're just assuming it happened and gave a zero return code. that's about it.
<hatch> yeah - the code wasn't written with testing in mind so I may have to do some refactoring 
<hatch> but i'll start with the amulet tests
<hatch> integration tests are the most important
<hatch> proving that it actually works
<lazyPower> that's an excellent place to get moving. I'm looking forward to that merge landing in the queue
<lazyPower> if you want any help/pointers on amulet, feel free to reach out. mbruzek is also an amulet master
<hatch> the version in my gh repo is running ghost 5.0 btw
<hatch> er 
<hatch> 0.5.0
<lazyPower> i'm a -stable kinda guy. I use whats in the charm store unless i *really* need something else, and then i deploy from personal namespace. I'm getting away from doing local charm deployment as much as possible
<lazyPower> the overhead of remembering to upgrade charms locally is something I can't be asked to do
<hatch> haha np - I'll try and get on those tests quickly
<hatch> probably wont be until wednesday though
<lazyPower> no rush :)
<lazyPower> I may wait until you land your amulet tests before id o the migration so i can highlight the fact its a tested charm
<lazyPower> and make sure you ping whomever does your review to update the quality info on ghost, that'll give you another star on quality
<lazyPower> we *should* be doing that anyway, but i typically forget :(
<hatch> sure that's fine
<mbruzek> Hey hatch just got back from lunch catching up on the scroll back.  I AM using ghost and I CAN help you with amulet.
<hatch> mbruzek:  I was asking specifically about the ghost charm :) because I wrote it and wasn't going to put a ton of time into it until others were using it :)
<mbruzek> hatch, I am using the ghost charm.
<hatch> excellent - well please file any bugs or feature requests on the GH repo :)
<hatch> https://github.com/hatched/ghost-charm
<mbruzek> GH ?  Not Bazzar ?
<hatch> the gh repo is the source of truth, lp is just a compile-to target :)
<hatch> mbruzek:  so how do you have your env set up? Are you using mysql/apache?
<mbruzek> roger that.
<mbruzek> Actually no.
<mbruzek> don't get mad
<mbruzek> But I am using haproxy 
<mbruzek> I realize this is not a way to do it in production.
<mbruzek> But I am using the haproxy charm and ghost charm to run my blog
<hatch> that's fine :)
<hatch> haproxy works pretty well
<hatch> you should look into using mysql though
<mbruzek> why?  sqlite not going to keep up?
<hatch> if you're just using the built in sqlite db, you'll have to manually transfer everything if you ever upgrade the charm
<hatch> harder to do backups...etc
<mbruzek> hatch, I had a question about the configuration.  When I tried to set the "host" to the actual IP address my blog goes dark.
<hatch> mbruzek:  yeah typically you want to just leave it at 0.0.0.0 and let the image handle it
<hatch> tbh I can't think of a time when you'd want to specify the ip
<mbruzek> hatch OK that is what it is set to now
<hatch> but maybe if you were running some fancy network set up and you wanted it to use a specific ip
<hatch> are you running haproxy and ghost on the same machine?
<mbruzek> hatch yes.
<mbruzek> juju deploy cs:precise/haproxy --to 0
<mbruzek> juju deploy cs:precise/ghost --to 0
<mbruzek> juju add-relation ghost haproxy 
<mbruzek> It was as simple as those three commands.
<mbruzek> hatch, I will look at adding mysql.
<hatch> mbruzek: awesome - yeah just curious really :)
<hatch> mbruzek: so if you switch to mysql you'll have to manually port the posts over 
<hatch> (sorry) that's not done in the charm yet
<mbruzek> Oh darn, all 2 of my blog postings
<hatch> haha - mbruzek I am very interested in that procedure though - I'm sure others will need to do the same
<hatch> keeping the blog post id's the same (if it doesn't automatically) 
<hatch> etc
<hatch> I'd even like to include it in the readme if it's small enough, or an a supplementary file in the charm even
<hatch> OR
<hatch> if it's really easy, PR's accepted :P
<hatch> (the charm is in javascript) :D
 * mbruzek shivers
<hatch> hah yeah it was a challenge in some places but it's written in JS because Ghost is a js project
<mbruzek> understood. 
<hatch> evening fabrice
<fabrice> evening !
<Makyo> jujugui need some reviews/QA (especially QA) on clearing ECS changes  https://github.com/juju/juju-gui/pull/508 
<hatch> Makyo:  I'll take one
<hatch> got to grab some lunch first
<Makyo> Sure
<kadams54> Makyo: working on my own PR but as soon as I wrap that up I'll dive into the QA queue.
<kadams54> guihelp: my own PR for QA: https://github.com/juju/juju-gui/pull/509
<hatch> jcsackett:  I found an easier way to accomplish what I needed https://github.com/hatched/juju-gui/commit/9da0a126618b4a86f94e1f9a806bcc25102ae24f does this conflict with what you're working on?
<hatch> if it does....it's a race to see who lands first :P
<jcsackett> hatch: not even a little bit.
<hatch> jcsackett:  great - my original version was much bigger
<hatch> heh
<hatch> I've also found an issue with the token rendering that will need a refactor post 1.0+
<hatch> the tokens are never cleaned up even if they don't exist any longer (the machine is destroyed)
<hatch> they aren't shown in the dom, but they are still instantiated
<jcsackett> hatch: fun times.
<hatch> kadams54:  spin up a juju env, I'll need a qa shortly :)
<kadams54> lol
<hatch> jujugui lf reviews and a qa https://github.com/juju/juju-gui/pull/510
<hatch> kadams54:  this is the fix to the bug you found in the last branch
 * kadams54 warms up his wrecking ball
<kadams54> Which begs the questionâ¦ how exactly do you warm up a wrecking ball? I mean, besides the Miley Cyrus way.
<kadams54> hatch: On it.
<hatch> lol
<hatch> Makyo:  review done
<hatch> I'll hold off on qa until the bug kadams54 found is fixed
<hatch> there was one issue
<Makyo> Cool, thanks
<hatch> kadams54:  I don't understand your comment - it sounds like the issue that the previous branch fixed
<hatch> the tokens should never disappear 
<hatch> just update
<hatch> kadams54:  can you check to make sure you have cleared your cache and all that
<huwshimi> Morning
<hatch> oh huwshimi I thought you were working the night shift ;)
<hatch> or, I suppose the graveyard shift
<huwshimi> :)
<huwshimi> hatch: I replied to your comments
<hatch> thanks going back through again
<hatch> the test failure was a legit one
<hatch> ^ huwshimi
<hatch> huwshimi: +1'd with a comment request
<huwshimi> hatch: Oh, all I can see is that the build was aborted. I'll run locally
<hatch> huwshimi:  http://ci.jujugui.org:8080/job/juju-gui/1678/console
<hatch> CI hang so there was a bunch of messed up runs
<hatch> hung*
<huwshimi> oh I see
<huwshimi> hatch: ugh, it runs fine locally :(
<hatch> huwshimi:  try running test-prod
<huwshimi> ah ok
<huwshimi> oops, silly mistake
<huwshimi> kadams54: If you're around, just need a +1 on my branch if you're happy: https://github.com/juju/juju-gui/pull/507
<hatch> huwshimi:  imho if he doesn't pop in in the next couple hours - jfsi
<hatch> :)
<huwshimi> :)
<huwshimi> hatch: Well there was a QA OK and no code comments...
<hatch> huwshimi:  the other thing is that when you're submitting branches that are multiple cards, can you put in the pr, the cards which are in that branch, or inversely the pr in the cards
<hatch> maybe he thought your code was perfecto!
<hatch> so perfect in fact the +1 was not even necessary 
<huwshimi> hatch: Yep, I put the pr in both cards, I can do the opposite as well if that helps
<hatch> oh I missed that heh
<hatch> my workflow is usually from GH to kanban
<huwshimi> hatch: Yeah, me too, I'll put the titles in a comment or something
<hatch> just fyi the title and the body of the first post are what gets written into the git log for the merge commit
<hatch> so that's why we have been putting the qa comments in an extra comment
<huwshimi> hatch: Yeah, I thought I could do it with the QA comment
<huwshimi> hatch: I wish cards had unique ids, would make this stuff much easier
<hatch> ugh I know 
<hatch> well....they do
<hatch> but they aren't really accessible hah
<huwshimi> concrete just about to be poured under the house for my new office :)
<hatch> you are getting a basement?
<hatch> I'm not entirely sure how concrete gets poured under a house without there also being a big hole :)
<huwshimi> well yes, the garage under the house is being converted into a room for me to work in
<hatch> ohh interesting
<hatch> don't you park in your garage?
<hatch> :)
<huwshimi> hatch: I just park in the driveway, it's a bit too small
<hatch> ahh gotcha
<hatch> well yay! in that case :)
#juju-gui 2014-08-26
<huwshimi> hatch: Yeah, it'll be nice to move out of the bedroom :)
<hatch> haha, yeah - I've been thinking of adding a furnace into my garage and turning it into an office so I can get out of the house....so far that plan has not worked out :)
<huwshimi> hatch: Yeah, it's nice to have a nice separate space. I'll actually have to walk out the front door to go to work now :)
<hatch> haha, that'll be nice :)
<huwshimi> yeah :)
<huwshimi> ok, I'm going to ship this
<bac> hola huwshimi
<huwshimi> bac: Hello!
<bac> huwshimi: how's it going?  all wintry?
<huwshimi> bac: Not so wintry today: http://www.rosebay.tased.edu.au/webcam/medium.jpg
<huwshimi> (that's a semi-live shot)
<huwshimi> a little snow left, but 18C today
<bac> huwshimi: very nice!
<bac> hobart sprint!
<hatch> huwshimi:  also, you probably noticed - I added a ton of new cards into Project 1 from lucas qa 
<hatch> lots of ux'y bits there, some of which can probably be combined
<huwshimi> hatch: Yeah, no problems.
<hatch> bac, I agree!
<hatch> huwshimi:  one comment on review, just doing qa now
<huwshimi> hatch: Ah thanks, I haven't even finished typing up my qa notes!
<hatch> haha, ok I'll wait
<hatch> I just finished this weeks homework so was just about to shut down before I saw your branch :)
<huwshimi> hatch: Just added
<huwshimi> nothing complicated
<hatch> on it
<hatch> huwshimi:  qa issue, posted in the review - I'm not sure what the mockups say about this
<huwshimi> hatch: Are we really doing custom radio buttons!?
<hatch> huwshimi:  well we do custom checkboxes...so why not radios!
<huwshimi> I guess...
<hatch> the technique is the same at least :)
<hatch> huwshimi:  tbh that's probably low priority, I can ask luca about it in the morning if you like
<huwshimi> it's ok, it's just potentially a whole lot of work
<huwshimi> hatch: The more menu exists in the mockup for an empty container column
<hatch> yeah? Kind of odd, no?
<urulama> morning all
<huwshimi> urulama: Morning!
<urulama> hey there, huwshimi
<hatch> urulama:  morning!
<huwshimi> hatch: yeah, it doesn't seem ideal
<hatch> huwshimi:  ok if that's in the mockups comment as such in the PR then it's gtg
<urulama> hatch: you still up? :)
<hatch> urulama:  heh yeah - just finished homework, and saw huw's branch up
<hatch> listening to the Chillout channel on di.fm
<urulama> hatch: :)
<huwshimi> hatch: Thanks a lot for the review
<hatch> huwshimi:  np, should be good to land - but someone else should probably review it in the am as well
<urulama> hatch: that's a mongo class, right?
<huwshimi> yep np
<hatch> urulama:  yeah, second week
<urulama> hatch: ask if you pass it, if you implement proper n-grams :) 
<hatch> urulama: haha
<hatch> well patterns are this coming up week
<hatch> so we'll see
<hatch> https://university.mongodb.com/courses/10gen/M101JS/2014_Aug/syllabus
<hatch> does that link work if you're not logged in?
<urulama> hatch: no
<hatch> ahh darn
<hatch> well yeah, doesn't look like they dig into any advanced querying 
<urulama> np, let me know if n-grams pop up in class, please :)
<hatch> you bet
<hatch> so far I'm at 100%
<hatch> pressure is mounting
<hatch> I have to now maintain that
<hatch> lol
<urulama> :)
 * urulama goes hunting for food
 * hatch goes hunting for sleep
<hatch> night all
<rogpeppe> mornin' all
<urulama> rogpeppe: morning
<rogpeppe> urulama: hiya!
<urulama> rogpeppe: hey. how was your double-weekend (4days)? :D Hope you managed to catch a breath and re-energize 
<rogpeppe> urulama: good, thanks.
<rogpeppe> urulama: definitely needed it :-)
<urulama> rogpeppe: great to hear! 
<urulama> jujugui: need to jump out for 10min
<jcastro> urulama, you can post what you mailed me as an answer!
<urulama> jcastro: done
<jrwren> morning all
<jrwren> Updated: https://github.com/juju/charmstore/pull/77  Needs review, especially rogpeppe.
<rogpeppe> jrwren: cheers, will look
<urulama> jrwren: morning
<jrwren> urulama: good morning
<urulama> jrwren: how's quickstart going? let me know when you're finished with revision API and quickstart. I've added some cards for the CS search if interested.
<jrwren> urulama: quickstart is done. revision is in review, hopefully with not too much left todo
<urulama> jrwren: good news :)
<rogpeppe> while i'm looking at jrwren's branch, here's nice little algorithm problem i came across when writing some tests for the PutMeta stuff. Here's some code: http://play.golang.org/p/1rUf8iNBhq . The challenge is to fill in the body of Reorder. I think it should be trivial, but I haven't quite worked out a nice method yet.
<rogpeppe> urulama: ^
<jrwren> i was always terrible at that.
<urulama> rogpeppe: saved it for the evening :)
<urulama> crap. i managed do bork my juju environment.
<rogpeppe> urulama: how's it borked?
<urulama> rogpeppe: without any evironments, juju status hangs in the air, have to terminate it. Also, can't destroy environments. strange. I'm on another VM currently, but will have to look what happened
<rogpeppe> urulama: is this using ec2 or local?
<urulama> rogpeppe: local
<rogpeppe> urulama: do you know what you did to bork it?
<urulama> rogpeppe: i'll do history revision later, will try to reproduce on the new one.
 * urulama lunches
<kadams54> guihelp: looking for reviews on https://github.com/juju/juju-gui/pull/509
<kadams54> hatch: when you have a moment, let's talk about https://github.com/juju/juju-gui/pull/510
<hatch> sure, gimme a few
<urulama> rogpeppe, frankban: how do i upload someBundle.zip using /archive API?
<rogpeppe> urulama: POST to /archive/id
<rogpeppe> urulama: with an appropriate content hash
<urulama> not working. posting mediawiki.zip fails as it expects series, and if series are added, it expects a charm and therefore metadata.yaml
<rogpeppe> urulama: e.g. /archive/precise/foo?hash=4544f44f33f3f4f43
<frankban> urulama: series is "bundle"
<rogpeppe> oh sorry, i missed that it was a bundle
<rogpeppe> what frankban says
<urulama> {"Message":"cannot read bundle archive: archive file \"bundle.yaml\" not found","Code":""}
<urulama> but there is bundles.yaml :)
<frankban> urulama: heh, we don't like plural
<urulama> frankban: indeed, there shall be only one!
<urulama> :)
<hatch> kadams54:  ok wassup? 
<hatch> did you make sure you were running on the new version?
<rogpeppe> urulama: are you expecting it to work with bundles.yaml ?
<kadams54> hatch: So the problem I ran into I *think* is different from what was fixed earlierâ¦
<urulama> the first bundle that i took from LP (mediawiki) has bundles.yaml inside
<hatch> can you add steps to reproduce in the PR?
<urulama> rogpeppe: also all docs reference bundles.yaml not bundle.yaml
<hatch> without steps to a qa issue, the issue is basically useless 
<kadams54> hatch: It's the same steps you outline for QA.
<hatch> yeah when I follow those on any os the tokens never leave the UI
<kadams54> hatch: After I click on deploy, the tokens disappear. Old behavior was that the uncommitted state was removed, but they didn't disappear.
<hatch> tbh I don't even think it's possible for them to do so 
<hatch> are you using ec2?
<kadams54> That's running in Chrome/Ubuntu on a local lxc.
<hatch> and you're sure you're running my PR?
<hatch> what if you switch to develop? Same?
<jcsackett> kadams54: i'm doing QA/review on your branch now.
<kadams54> jcsackett: thanks
<kadams54> hatch: I'll verify against develop
<rogpeppe> urulama: unfortunately the recent bundles specification doesn't mention the name of the bundle.yaml file...
<jcsackett> hatch: i've pushed up my changes to the branch of omg; i think it resolves everything now.
<hatch> jcsackett:  cool thanks, I'll take a look
<rogpeppe> urulama: but i'm pretty sure that "bundle.yaml" is correct
<rogpeppe> urulama: the old format allowed a bundle to actually define several bundles
<urulama> rogpeppe: this makes old bundles incompatible with new CS
<rogpeppe> urulama: that's definitely true, yes
<rogpeppe> urulama: that was a deliberate decision - there are quite a few differences
<urulama> rogpeppe: aaaaa, ok. 
<rogpeppe> urulama: we simplified and generalised some aspects of it
<hatch> jcsackett:  when you get a moment can you also QA #510? kadams54 is reporting a qa issue that shouldn't even be possible :) 
<jcsackett> hatch: sure, i'll see if i can reproduce.
<jcsackett> it'll be a few, though.
<hatch> yeah no rush
<hatch> jcsackett:  hey you have a real failure in your update
<hatch> test failure *
<jcsackett> huh. that doesn't come up locally.
<jcsackett> that'll be fun to sort.
<hatch> heh make sure you try test-prod
<jcsackett> doesn't make check run that?
<jcsackett> or does check only do test-debug?
<hatch> honestly I have no idea
<hatch> I run `make lint test-debug test-prod`
<hatch> I'm sure it does though
<hatch> I've just noticed some of the test failures come from running under prod lately
 * jcsackett nods
<jcsackett> hatch: seeing if i can reproduce kadams54 qa error on your pr now.
<hatch> thanks
<hatch> sorry it's got to be on a real env.....but at least lxc is pretty fast :)
<hatch> jcsackett:  I'm doing my mongo U stuff in an lxc....lovin it, it's not cluttering up my primary machine :) I can't believe I didn't do this workflow before
<jcsackett> hatch: lxc's are nice. :)
<jcsackett> hatch: you should also check out vagrant-lxc, which i've heard good things about if you like vagrant.
<jcsackett> hatch: i can't reproduce his error, but i've found a different one.
<jcsackett> i'll add notes to the PR.
<hatch> thanks
<hatch> jcsackett: oh very odd issue
<hatch> kadams54_:  there's the internet I expect....
<hatch> lol
<kadams54_> :-) Not my internet - I walked away while waiting on juju-gui-source to take and forgot to plug my laptop in.
<kadams54_> Power settings kick in and turn off network after so many minutes of inactivity.
<kadams54_> I suspect most of my timeouts are due to inactivity/working on my Ubuntu desktop + forgetting to plug in.
<hatch> ohh haha I gotcha
<hatch> I have this mac mini that's not being used I was thinking of turning into an Ubuntu box....not sure about it though because I love the portability of my laptop
<hatch> jujugui call in 10
<urulama> frankban: i can get bunle into the CS (meaning that charms have been validated), however, /ID/meta/bundles-containing always returns [] 
<frankban> urulama: what's ID in that request?
<urulama> frankban: so the bundle looks like: http://paste.ubuntu.com/8150598/
<urulama> frankban: and id is either mysql or /precise/mysql or even /precise/mysql-0
<urulama> frankban: and id is either mysql or /precise/mysql or even /precise/mysql-1
 * hatch pats jcsackett on the back...."It'll be ok....it'll be ok" ;)
<frankban> urulama: ok will check after the call
 * jcsackett holds up sign at hatch. the sign says "NO"
<hatch> lol
<urulama> hatch: did you try to diagnose it yourself?
<hatch> urulama:  yeah it's a broken thunderbolt port
<hatch> they need to run their own diagnosis though, then order a new logic board
<hatch> then next week I'll need to take it in again to get it replaced
<urulama> hatch: nice :)
<hatch> urulama:  yeah the good news about apple products is that I can go somewhere, sit there while they fix it, then take it home
<hatch> any pc stuff you have to leave it there for a while and such
<hatch> or ship away
<jrwren> unless they say "we need to keep it."
<urulama> frankban: i can get meta on any of the charms in the bundle so all are there
<frankban> urulama: and the bundle is there, correct?
<urulama> it is
<hatch> jrwren: heh, I made it very clear that I need it to work
<urulama> frankban: get on /archive returns a zip
<urulama> frankban: with proper content
<frankban> urulama: bundle-metadata?
<jrwren> hatch: thanks for the tip. I shall remember that next time.
<hatch> jrwren:  yeah I called last week and booked the appointment for thursday morning so I will wait and they can fix it then return it
<hatch> if I would have dropped it off then yeah
<urulama> frankban: all there
<urulama> frankban: {"Services":{"haproxy":{"Charm":"precise/haproxy","NumUnits":1 ... 
<urulama> frankban: /v4/precise/haproxy/meta/bundles-containing returns [] though
<frankban> urulama: is it empty if you specify any-series=1 and any-revision=1?
<urulama> frankban: no, just tried
<urulama> frankban: having both =1 returns the bundle
<urulama> frankban: two revisions even, which is ok!
<urulama> frankban: any-revision=1 must be set to get results. 
<frankban> urulama: it should work with just any-revision in theory, if the id is precise/haproxy
<urulama> frankban: it does
<frankban> urulama: this is because the bundle does not include a full URL
<frankban> urulama: services specify unrevisioned charms, so no full URL match succeeds
<frankban> urulama: this is the current behavior, we can change this so that the last revision of the charm matches the bundle, but this also mean what's valid today will be no longer tomorrow.
<frankban> urulama: generally speaking, I believe those kind of bundles are broken by design ;-)
<frankban> urulama: could you please double check passing a bundle with fully qualified charm urls?
<urulama> frankban: on it
<frankban> urulama: thanks, that bundle should be included in the results without specifying any-revision
<urulama> frankban: charm with revision returns the bundle without any-* flags
<urulama> frankban: man, this will be PITA to use in real life :) 
<urulama> frankban: esp. if bundles will specify "hand-made" charms
<frankban> urulama: I am not sure about the real uses of that api call, but if you think there are use cases that can be helped by the different behavior, then we can discuss that and change the spec
<frankban> urulama: but there is a cost server side
<urulama> frankban: looking from the GUI perspective, if a bundle is "neat", than charm will show it's bundles. but not all of them (when revision is not set), so we need another check if the charm is the latest one, we should not care about revision and show also the bundles with /bundles-containing?any-revision=1
<frankban> urulama: ok, so the server should check if the current charm is the last revision, and in that case, also include the bundles with revisionless charms. this is doable, would you like to make a card?
<frankban> urulama: we can also decide whether this is something we tackle now or later, if the need for this is demonstrated
<urulama> frankban: i'll think about it for a sec ... i don't see any problems with it and we do get results consistent with the behaviour of the system
<urulama> frankban: for now, i'll just add a comment to the doc
<frankban> urulama: sounds good
<hatch> jcsackett: so your bug that you found in my branch.... does the icon show up on the machine? and not the token? Or just doesn't show up on the token?
<hatch> And you were saying on develop it shows up once you click on the token? Where does it show up on?
<urulama> frankban: naaa, it's not ok. any-revision will of course also include all bundles that reference old charms, which should not be shown. 
<urulama> frankban: so latest charms should only show bundles that include charms without revision, but not behave as any-revision=1
<jcsackett> hatch: one you commit changes (1 machine with 1 unit on the root container), the machines show up as committed with no units. on develop, once you click on the machine (not the root container), you see the service unit icons.
<jcsackett> on your branch, when i click tokens, i still see no units.
<jcsackett> hatch: develop is *also* wrong, i think, but it's less wrong.
<hatch> yeah - so do the squares show up and no icon?
<hatch> or just nothing?
<hatch> (I'm spinning it up atm) 
<hatch> I THINK the tokens aren't being updated properly and my changes exacerbate the problem 
 * rogpeppe grabs a bite to eat
<frankban> urulama: IIRC that's what we discussed in London. the behavior of that call should really depend on the goal/where it will be used. the meaning can be either what you propose or "give me all bundles that references (or used to reference) this charm"
<jcsackett> hatch: nothing shows up.
<jrwren> rogpeppe: how generic do you need this? can you use sort.StringSlice or sort.IntSlice instead of sort.Interface ?
<jcsackett> hatch: no squares, no indication of units at all.
<frankban> urulama: I haven't a strong opinion, so if you want I am +1 on changing that
<frankban> urulama: so +1 on adding a card. that said, I still feel this is a corner case and we should discourage publishing bundles with revisionless charms
<urulama> frankban: let's leave it for now as it is
<urulama> frankban: charm-related might need a fix though ... the results contain old revisions of the same charm
<urulama> frankban: ah, and that is in both requires and provides ... i'll add a card for that 
<frankban> urulama: I am not sure that's an error
<frankban> urulama: old revisions of the same charm are still related
<urulama> frankban: i'm not sure if i'd like to see such results as user.
<frankban> urulama: clients can further filter their results, but they can't if we don't provide them
<frankban> urulama: if in the spec we state that the api call "returns all charms that are related to the given charm", then not including old revisions can be condusing from the client perspective
<rogpeppe> jrwren: i want it like i described, because then it's generally applicable
<urulama> frankban: ok, it might make sense if i want to se what other revisions of the same charm have this, true. 
<frankban> urulama: indeed, we also have a test specifically checking that we return multiple revisions of the same related charm. 
<urulama> frankban: added this comment in the doc "We currently return all revisions of the same charm as well. Depending on the ranking of the results, we might add a flag "[&not-self=1]" to filter such results."
<urulama> so in case top 10 related charms are just revisions most of the time, we might drop them ... 
<frankban> urulama: perhaps only-latest=1?
<frankban> urulama: for what charm are you seeing the same charm to be related?
<urulama> haproxy
<urulama> and apache2
<urulama> frankban: other charms don't seem to have this, indeed
<frankban> urulama: that's because they both require and provide http I guess
<urulama> frankban: yes
<frankban> urulama: so technically they are related to self
<urulama> frankban: and technically it's ok to return themselves :)
<frankban> urulama: yeah
<frankban> urulama: and I know, relations stuff is horrible ;-)
<urulama> frankban: :)
<urulama> frankban: as long as we know what to expect and when, all is fine. 
<hatch> heh parsing relations....oh I remember writing the code for that in the GUI
<hatch> I hope they don't ever change the rules because I never want to touch that again
<rogpeppe> it's fine for a charm to both require and provide the same interface. it's a bit like a func(int) int
<urulama> rogpeppe: sure, it's just a matter what user expects to get from "which are related" ... something we'll measure and correct if needed :)
<rogpeppe> urulama: yeah. we could just exclude self from the results if necessary.
<jcsackett> hatch: i've pushed a testfix for my PR, all seems well now if you get time to review.
<jcsackett> i'm grabbing some lunch
<kadams54> guihelp: anyone else run into this error when setting juju-gui-source? http://pastie.org/private/syp0svijdtezstyc4t9amg
<kadams54> I seem to get it pretty frequently and today I can't seem to shake it.
<hatch> kadams54:  look into the logs to see what the error is
<hatch> kadams54:  are you trying to change the repo on precise?
<hatch> jcsackett:  I've found a number of issues around dragging units to newly created machine containers
<hatch> tbh I'm not entirely sure wth is going on heh
<hatch> sometimes the image src is just 'src' 
<jcsackett> hatch: on your branch, or QAing mine?
<hatch> on develop 
<hatch> just switching to my branch now
<hatch> you can even get into a place where it'll deploy the service but no units
<jcsackett> hatch: yeah, unit icons on tokens are kind of a mess.
<hatch> then you can't delete the service, ever
<hatch> this is a little frustrating 
<hatch> jcsackett:  ok now I see the issue with my branch vs develop
<hatch> what to do, what to do
<frankban> urulama, rogpeppe, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/81 (charmstore). no rush and thank you!
<kadams54> hatch: http://pastie.org/private/ipvckjbsobugmfnmaiw - just seems to indicate the git process died with a non-zero exit code.
<kadams54> I'm changing the repo on trusty.
<hatch> kadams54:  what did you set the config to?
<hatch> can you paste the line?
<kadams54> hatch: juju set -e local juju-gui juju-gui-source="https://github.com/juju/juju-gui.git develop"
<hatch> try `juju set -e local juju-gui juju-gui-source="develop"`
<hatch> there might be an issue in specifying the same repo as the default repo
<kadams54> So re-running `juju set` doesn't seem to do anything. I don't see any more entries in the log filesâ¦ how do I force a retry/restart and get it out of the error state?
<hatch> kadams54:  you have to resolve the issue
<hatch> then re-set
<hatch> juju resolved juju-gui/0
<hatch> juju set ...
<kadams54> Ah
<kadams54> My juju education continues.
<hatch> :)
<hatch> jcsackett:  so I'm proposing that I land my branch as is and then do a follow-up to fix the icons wholesale for the tokens
<hatch> they are so broken I really don't know what to do wrt my branch if that's the blocker
<hatch> thoughts?
<jcsackett> hatch: works for me.
<jcsackett> marking as so on your PR.
<hatch> sounds good thanks
 * rogpeppe is done for the day. finally solved my algorithm problem; i'm still sure there's a nicer solution!
<rogpeppe> g'night all
<hatch> night rogpeppe
<hatch> good luck with the algo :)
<rogpeppe> hatch: perhaps you could do better? here's the code: http://play.golang.org/p/paZzZJYZdd
<hatch> rogpeppe:  what is it supposed to do?
<rogpeppe> hatch: order one slice according to the ordering in another
<rogpeppe> hatch: i tried to make the comments explanatory, but perhaps not well enough :-)
<hatch> haha ok I'll take a look if I get some time
<kadams54> hatch: Finally was able to get a full real env re-test done on #510. I wasn't able to reproduce the original bug, but I did encounter a new one. Since you shipped that PR, not sure where I should report it?
<hatch> kadams54:  is it caused by my branch?
<kadams54> Yes
<kadams54> Didn't see it on develop
<hatch> ok then yep file it on that PR
<hatch> er
<hatch> post it on the PR
<kadams54> hatch: Well, never mind. I can't reproduce it consistently. Only happened once in 5 tries. When I autoplaced a unit and then deployed, it flipped back over to an unplaced unit while waiting for juju-core to ack, then on ack (correctly) became a deployed unit on a deployed machine.
<hatch> oh that's very odd
<hatch> this was on a real env?
<hatch> lxc?
 * Makyo -> appointment 
<kadams54> hatch: Yeah, lxc.
<hatch> kadams54: that's very interesting, I'm not even sure how that's possible tbh
<kadams54> I'm fine with dropping it for now, since I can't get it to happen more than once.
<kadams54> Just something to watch out for
<kadams54> See if it starts happening more
<hatch> yeah definitely - this mv is a mess
<hatch> not anyones fault heh
<hatch> just been modified and stuff so often
<hatch> we'll have to go back and reorg it afterwards 
<kadams54> whee!
<kadams54> Makyo: (For when you get back) Is PR#508 ready for another look?
<hatch> jcsackett: +1'd
<hatch> kadams54:  do you still need another?
<jcsackett> hatch: thanks!
<jcsackett> jujugui: i could use one more review (no qa needed) of https://github.com/juju/juju-gui/pull/505
<kadams54> hatch: on #509? Nope.
<hatch> kadams54:  ok then, lets get it shipped :)
<kadams54> hatch: Yeah, working on changes right now based on the feedback :-)
<hatch> ohhh ok ok
<hatch> sorry I thought it was done-done
<kadams54> Hold your horses
<kadams54> ;-)
<hatch> lol
<kadams54> guihelp: I have a question about the bug I'm currently working on. Some places in the UI machine constraints are displayed as CPU/memory/architecture. Other places its CPU/memory/disk. Anyone know which it should be? Disk? Arch? Both?
<hatch> kadams54:  so...this is an artifact from old juju to new juju
<hatch> as far as what's correct and what's required
<hatch> I have no idea
<hatch> kadams54: probably best to send an email to peeps
<hatch> cpu-power cpu-cores mem arch tags disk
<hatch> I think those are all the ones from core
<kadams54> hatch: done
<hatch> kadams54:  great
<hatch> tags are something to do with MAAS btw
<hatch> not sure what though heh
<hatch> jcsackett:  are you going to rebase and ship your branch?
<hatch> Makyo:  do you need any reviews or anything for your branch?
<Makyo> hatch, just got back.  Yeah, I think I do
<hatch> ok looking again
<Makyo> thx
<hatch> Makyo: so is something supposed to happen when I click the button?
<hatch> I have mysql, wordpress, relation, extra units, extra machines, extra containers
<hatch> when I click the button nothing happens, no errors
<Makyo> Anything in the ECS should be wiped out.
<Makyo> Confirming on my end.
<hatch> and the deployer bar should update, remove all the stuff from the canvas?
<Makyo> Correct.
<hatch> yeah, nothing is working... lemme try clearing the cache
<hatch> Makyo:  yeah can you check locally again? updating develop
<hatch> because the button clicky no worky
<jcsackett> hatch: i am still waiting for a second review.
<hatch> I can add it to the PR but I just want to be sure there isn't something totally weird going on heh
<Makyo> hatch, I see what happened.  Will fix that in a second.
<hatch> cool
<Makyo> Give me two minutes.
<hatch> jujugui jcsackett needs one more review (no qa) 
<kadams54> hatch: I'll take a look
<hatch> thanks sir
<Makyo> hatch, pushed
<hatch> ok re-testing
<kadams54> hatch, jcsackett: done with review, looks good.
<hatch> Makyo:  thanks - all good except one template issue
<jcsackett> kadams54: cool, thanks.
<Makyo> hatch, yeah, I'm breaking from designs already per kadams54, so it doesn't really make sense there (probably why the designs didn't have it there).  I'll see what I can do, I guess.
<hatch> Makyo:  I meant the message didn't make any sense 
<hatch> it's saying things will be committed but it's clearing them
<Makyo> hatch, because you aren't even supposed to be able to clear them at that point.
<Makyo> That wasn't in the designs at all.
<hatch> oh haha - that's where it should be imho
<hatch> lol
<Makyo> I added it there when kadams54 brought it up.
<hatch> !
<hatch> haha gotcha
<Makyo> Yeah, same
<Makyo> I'll see if I can do something nondestructive.
<hatch> ok cool
<hatch> might be worth sending an email to luca/peeps about that
<hatch> kadams54:  I don't see your timeoff in the calendar, did you put it in hr. ?
<jcsackett> ah man, i synced with upstream and now i have test errors.
<hatch> :(
<huwshimi> Morning
<hatch> morning huwshimi
<huwshimi> hatch: If you set a default value for an ATTR on a view it automatically sets that value correct? e.g. http://paste.ubuntu.com/8154026/
<huwshimi> Or do you have to set it on init?
<hatch> nope that's correct
<huwshimi> well that's no help then :)
<hatch> lol what's the issue?
<huwshimi> hatch: It's undefined!
<hatch> can you show me some code?
<hatch> like maybe push up what you're working on
<huwshimi> hatch: Yeah, just pushing it up
<hatch> cool
<hatch> hows the new floor? Probably take a couple weeks to be completely cured?
<huwshimi> hatch: I'll head down later and try walking on it :)
<hatch> haha, well it should be easily walkable by now
 * hatch has poured a few garages and driveways in his day
<huwshimi> nice
<huwshimi> hatch: Here it is undefined: https://github.com/huwshimi/juju-gui/compare/toggle-hardware#diff-947e688a9f9e23383a48af542be63bbfR98
<hatch> looking
<hatch> huwshimi:  lol, one sec
<hatch> huwshimi:  the machine view panel uses an incorrect syntax for Y.Base.create()
<huwshimi> oh
<huwshimi> Great!
<hatch> the ATTRS needs to be in the statics argument, not the prototype :)
<hatch> want me to wip up a quick diff for you?
<huwshimi> hatch: Ah, I thought it looked a bit funny there actually
<hatch> :) yeah so you should probably do that in a separate branch
<hatch> just in case it causes issues
<hatch> it 'shouldn't'
<hatch> but...ya know :)
<hatch> I can review and qa if you want to do it now
<huwshimi> ok
<huwshimi> hatch: https://github.com/juju/juju-gui/pull/512
<hatch> on it
<huwshimi> thanks!
<hatch> huwshimi:  done!
<hatch> speeeedy
<hatch> :)
<huwshimi> hatch: Thankyou, happy for me to shipit?
<hatch> yup letrrip
#juju-gui 2014-08-27
<hatch> any vim users here? I'm trying to find out what the equivalent of 'x' is but instead of delete, backspace
<hatch> ahh upper case x
<hatch> X
<hatch> hmm which doesn't work
<hatch> kadams54:  you use vim?
<kadams54> Yes.
<hatch> what is 'backspace' ?
<hatch> x = delete
<hatch> I found online that says X = backspace
<hatch> but that doesn't work
<hatch> oh crap now it is
<hatch> :/
<hatch> hah
<hatch> it's a little clumsy though I suppose
<kadams54> hm
<kadams54> I can't say I've ever seen it function as backspace
<kadams54> Usually just delete
<kadams54> But given the various navigation shortcuts, I've never really needed backspace
<hatch> yeah I'm slowly learning vim heh
<hatch> very slowly
<hatch> probably just in time for some other editor to come out that's superior
<hatch> :P
<hatch> kadams54:  do you also use jj as your escape?
<kadams54> no
<kadams54> I use escape as my escape
<kadams54> I do have my leader key mapped to comma
<kadams54> http://walking-without-crutches.heroku.com/image/images/vi-vim-cheat-sheet.png
<hatch> leader key?
<kadams54> Yeah, it's important when you start talking about vim plugins
<hatch> so you reach all the way up to escape every time you have to exit from insert mode?
<kadams54> For example, there's one called NERDTree that adds a file browser on the left side, similar to what you see in a lot of the editors.
<kadams54> You access that by hitting <leader>+n
<kadams54> And yes, I reach all the way up
<hatch> ugh, yeah definitely couldn't do that :)
<kadams54> I've done it enough times that it doesn't feel awkward.
<hatch> even the vim website has jj as the example for remapping haha
<hatch> my escape key is so far away I have to actually move my hands off of the keyboard :)
<kadams54> Based on that shortcut, it looks like Shift+x is backspace
<hatch> yeah, I figured it out, I kept hitting caps (which is remapped to ctrl)
<kadams54> I knew someone who mapped caps to escape
<kadams54> https://github.com/carlhuda/janus
<kadams54> Even if you don't use Janus, there are some really good links for learning Vim in the readme
<hatch> I need caps as ctrl for tmux
<hatch> well, and everything else that uses ctrl :)
<kadams54> Alright, I'm heading to bed.
<kadams54> Have fun learning how to be a real programmer ;-)
<hatch> lol
<hatch> night
<urulama> jujugui: https://github.com/juju/charmstore/pull/82
<urulama> jujugui: revision-info was not under the implemented endpoints
<urulama> jujugui: i just merged it as it was just api reordering
<urulama> frankban: good point, will do.
<frankban> urulama: great thanks
<frankban> rogpeppe1: could you please also take a look at https://github.com/juju/charmstore/pull/81 when you have time?
<urulama> frankban: added card for weekly discussion
<frankban> urulama: cool
<urulama> frankban: one more thing from the QA test ... we did not define what happens to the revision numbers when uploading the same archive. Currently, rev.num. is increased with every POST. I would suggest that it is only changed if SHA is different. 
<frankban> thinking
<frankban> urulama: that sounds reasonable. so, for series/charm-name, if a previous revision exists and has the same hash, publish is basically a no-op.
<frankban> rogpeppe1: ^^^
<urulama> frankban: i would say so, yes. no upload. no rev inc.
<rogpeppe1> urulama: i'm not sure
<urulama> rogpeppe1: heya, morning ... any counterexamples why we would want to inc the revision?
<rogpeppe1> urulama: it just seems like a reasonable invariant that if i do an upload, i get a new revision
<rogpeppe1> urulama: (changing this will also break current test logic, but i guess that's by the by)
<urulama> rogpeppe1: on the other hand, if i double click the link in the gui (making a mistake), i get 2 versions
<urulama> rogpeppe1: breaking test logic would be ok in this case :)
<frankban> rogpeppe1: FWIW a nice side effect of this change is that the ingestion logic can be simplified
<rogpeppe1> frankban: only if the zip archives are deterministically made from the VCS info, i guess
<urulama> rogpeppe1: that is a good point
<rogpeppe1> urulama: i'm wondering about situations where we *want* a new revision, regardless of the content
<urulama> rogpeppe1: i tried to find one, but couldn't
<rogpeppe1> for example, we might want to associate some revision-info with the new revision, in extra-info
<urulama> rogpeppe1: except that it is really easy to test everything :)
<rogpeppe1> urulama: i don't quite get why it makes it easier to test
<urulama> rogpeppe1: you just upload 10 same zips and can get expand-id, revision-info, charm-related, bundles-containing showing more than one ... and deleting one still returns results
<rogpeppe1> urulama: how is that different from current?
<urulama> rogpeppe1: no, no, current implementation is easier for testing.
<rogpeppe1> urulama: ah yes
<urulama> rogpeppe1, frankban: I've just made a mark in the doc about the revisions increase. And let's leave it as it is, as it is easier to understand what's happening with each POST. In case it turns out that we want a NOP POST, we can change later.
<rogpeppe1> urulama: sgtm
<frankban> rogpeppe1: with that change, it would be harder the case when you need different revisions of the same charm in tests. Tests requiring different charms would still work reusing the same charm implementation. for the former case, it should not be hard to implement a factory that just increases the revision number before returning the archive impl. urulama: sounds good
<urulama> rogpeppe1: could you take a look at this "investigate how juju-core pings for upgrades" for the next task? The aim of this is that we'd like to have a number of live charms (deployed and used) in some recent time frame.
<rogpeppe1> frankban: yeah, it wouldn't be too hard. but i don't really see that it's that important. the important place to do this logic is at the client side (we need to make the hash of the archive available to clients, if we don't already)
<rogpeppe1> urulama: sure
<frankban> rogpeppe1: sure, I mentioned that just to understand if I see the possible problems
<frankban> urulama: re the card "store: Update bundles to support multiple revisions and make available over api v4": it seems you confirmed this already works in your QA, I guess we can move the card to done
<urulama> frankban: i was looking at this already, guess Rick added it ... yes, this can be removed. done.
<frankban> cool thanks
 * urulama likes when things get resolved without extra effort :)
<frankban> :-)
 * frankban bbiab
<urulama> frankban: after PR 81, we only support https? (because conf.validate will fail if user and pwd are not set) 
 * urulama lunches
<frankban> urulama: no, we still support http, but we require auth for POST/DELETE archive
<frankban> urulama: so I guess we'll need to add to options to the charm
<urulama> frankban: to options to the charm?
<frankban> urulama: sorry, two options to the charm
<frankban> urulama: like superuser-name/superuser-password or something like that, so that the charm can generate the cnfiguration file for charmd with the proper options
<urulama> frankban: do we need this?
<jcastro> rick_h_, I'd like to feature a bundle
<jcastro> but it appears like I can't self feature like I can with charms
<urulama> jcastro: rick_h_ is on well deserved holidays
<jcastro> oh boo! :)
<jcastro> can any of you guys feature a bundle?
<urulama> jcastro: not sure if such functionality is possible right now
<jcastro> well, we have featured bundles already, so it exists
<urulama> jujugui: anyone with access to do featured bundles?
<jcastro> BradCrittenden, this sounds like something you would know
<BradCrittenden> urulama: yes i should be able to.  anyone in, what ~charmers, shoule be able
<bac> urulama: what bundles?
<urulama> bac: something jcastro needs ... jcastro what bundles?
<jcastro> elasticsearch please!
<jcastro> bac, ^
<jcastro> brand new and shiny!
<urulama> bac: speaking of ES :D :D
<bac> jcastro: this one: http://manage.jujucharms.com/bundle/~charmers/elasticsearch/cluster
<bac> jcastro: if you login, and visit that page do you not see a "Feature" link?
 * bac teaches fishing
 * bac done
<bac> jcastro: if you visit that link now you should see an 'unfeature'.  urulama you might try it as well to see if  you're in the correct groups.
<urulama> bac: i am not :)
<urulama> bac: just kidding, yes, i see unfeature link
<bac> oh, good
<jcastro> I was at that page, I just totally missed the link!
<jcastro> ah nuts, on my screen, the featured bundles collapses, so you can't really see it on the list. :-/
<jcastro> there's no way to change the order of the featured bundles is there?
<jcastro> I'll just unfeature mongo for a bit
<urulama> jujugui: taking the kinds to visit my parents ... be back in 20min
<hatch> jujugui there are a ton of branches from huw from last night - I'll do one review for them all, I'll need one more, any volunteers ? 
<lazyPower> hey hatch, i'm getting some weird artifacting on the gui using Chrome Version 36.0.1985.143 -  http://i.imgur.com/a4HCoEX.png
<lazyPower> this persists through a page refresh
<hatch> lazyPower:  yeah....
<hatch> this appears to be a chrome bug
<lazyPower> ok i haven't filed a bug or looked for one to contribute to - i was more confirming its known behavior
<hatch> it only happens on some icons though
<hatch> so we may be able to fix it by fixing some icons
<lazyPower> strange that they were working fine before - any clue as to what's stemming the icon issue?
<lazyPower> older svg spec?
<hatch> lazyPower: honestly I have no idea, it displays fine in all other browsers
<hatch> I spent a couple hours trying to track it down before but no luck
<hatch> if you come accross something let me know....the bug is...
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1358671
<mup> Bug #1358671: Charm icons not rendering properly <juju-gui:Triaged> <https://launchpad.net/bugs/1358671>
<hatch> maybe if you could add that image to the bug
<hatch> ya know - more people, higher priority :)
<lazyPower> already done :)
<hatch> great - but you'll see that it's only certain ones - primairly the wordpress and mysql ones
<lazyPower> i've seen it happen to the category icons as well - but its random
<lazyPower> it doesn't always rear it's head, and its not always on the same icons
<lazyPower> it typically happens when i'm zoomed out and zoom back in
<hatch> hmm
<lazyPower> also, moving the charm squircle appears to make it re-render the svg properly
<hatch> yeah...odd
<hatch> since nothing changes in the gui
<hatch> the markup is identical when you drag
<hatch> so it's definitely a chrome bug
<hatch> just not sure how to workaround it
<lazyPower> throw more javascript at it
<lazyPower> :P
<hatch> haha
<hatch> Makyo:  jcsackett your branches ready to land now?
<jcsackett> hatch: doing the rebase to cleanup this very moment.
<hatch> coolio
<Makyo> Was hoping for another +1, but can land whenever.
<hatch> it's going to be in a queue behind huw's branches heh
<hatch> Makyo:  don' you have 2?
<Makyo> Didn't last I checked.
<Makyo> Oh, there it is.
<Makyo> Sometimes GH streams comments, sometimes not.
<hatch> yeah i've noticed that
<hatch> we might be back down to 0 open pr's again today :)
<hatch> assuming of course CI doesn't totally shit the bed
<jcsackett> hatch: big assumption.
<hatch> lol
<hatch> jujugui call in 2
<hatch__> kadams54: 
<kadams54> joining
<kadams54> Hangouts is telling me to wait :-)
<bac> jrwren: it is an unwieldy solution
<urulama> bac: if you're out next week, and Friday is your product management day, could we spend some time tomorrow on ES schemas for current version and start working towards schema for charmstore v4?
<urulama> bac: by we, i meant you, jrwren and me
<bac> urulama: yes i think that's a good idea
<bac> urulama: and the following week i'll be working in UTC+2, so we can collaborate like crazy!
<urulama> bac: aaa, i misunderstood that you are offline ... ok, ok, then np, no need to change activities
<urulama> bac: you'll be French! :D
<bac> urulama: no you were right.  next week i'm out.  the following week i'm working from UTC+2
<hatch> world traveler! 
<urulama> bac: hehe, ok, then schema it is tomorrow and soon, you'll be French! 
<bac> i will not actually *be* french.  i will be in france.
<bac> i think gillam gets to spend the week working with our host guillaume in a winery, eating baguettes.
<bac> now that's french
<frankban> :-)
 * urulama gets hungry
<urulama> bac: but you can enjoy their lunches, where wine is of course big part of it 
<bac> maybe not
<frankban> jrwren: FYI I think the design team already has some stuff re dominant charm color (IIRC they did something on the client side). I might be worth asking them
 * frankban now wants escargot + bourgogne wine for dinner
<jrwren> frankban: Thanks, I'll ask. Should I just email luca? That design team?
<frankban> jrwren: yes
<luca> jrwren: antdillon is the best person to talk to about the colour thing
<antdillon> jrwren, hi
<antdillon> jrwren, are you looking for the generic icon stuff?
<jrwren> Now I want to make baguettes.
<urulama> antdillon: luca pointed at you about that dominant colour :D
<hatch> jrwren:  need barley for that? haha
<rogpeppe1> bac: just had a brief glance at elastigo. looks like it's just a very thin wrapper around normal http methods. doesn't look like it adds enough value to justify it as a 3rd party dep
<rogpeppe1> bac: perhaps useful for the struct definitions
<jrwren> antdillon: I think so, yes.
<jrwren> antdillon: predominant background color of the svg.
<rogpeppe1> bac: but i'd tend towards defining an API that we want to use and defining marshaling types as necessary, with reference to the elastic search API docs
<rogpeppe1> s/API/Go API/
<antdillon> urulama, oh that colour lol ... what you need jrwren ?
<jrwren> hatch: I've considered wheat futures too :)
<urulama> antdillon: just how to get it :D
<luca> urulama: currently what I think Ant uses is pretty simple and we would like to tweak it once we can see itâs application when running on a proper database
<luca> antdillon: ^
<bac> rogpeppe1: interesting
<hatch> jrwren:  haha
<antdillon> urulama, jrwren currently I pick the colour of the pixel at 10x10 on the charm icon and apply that colour to the hero row background colour
<jrwren> antdillon: DONE! :)
<urulama> rogpeppe1: khm. you sure it's worth it? then we have to track ES development and update that ...
<urulama> jrwren: NONONONO! :D :D
<jrwren> 10,10 when the svg is sized to what?
<rogpeppe1> urulama: do we really trust the author of elastigo to do that? also, isn't the elastic search API versioned?
<urulama> luca, antdillon: so the "better" algorithm is not used? surely we must do better than that :D
<hatch> so I can help ya'll out with this
<hatch> pretty simple really
<jrwren> urulama: luca said they would like to tweak it, so maybe we default to this but allow the value to be set via POST?
<hatch> render the svg to a canvas, then go pixel by pixel reading the colour data
<antdillon> jrwren, the icons are currently displayed at 45px but when grabbing it with js it can be anysize
<rogpeppe1> hatch: that assumes we can render svg...
<hatch> rogpeppe1:  why can't we?
<hatch> what are we? amatures!!!!!
<hatch> no but really...why can't we
<hatch> :)
<rogpeppe1> hatch: maybe we can - we'd need a library for doing svg->raster in go
<antdillon> urulama, we only wanted to select the background colour of the charm icon
<urulama> jrwren: we have SVG code in go, why not just do something smarther ... but yes. the first implementation can take the colour of 10,10 pixel :D
<rogpeppe1> hatch: 'cos i don't really want to write one from scratch
<antdillon> urulama, I took an average of all colours before but if resulted in some ugly colours
<hatch> rogpeppe1:  right - the proper tool for the job here is to use phantom/casper etc
<rogpeppe1> if we've got a bitmap icon, it would be easy to take the majority pixel colour
<jrwren> I found this: https://github.com/ajstarks/svgo   I don't think CC attribution makes for a good software license :(
<hatch> unless there is a svg to raster go tool
<urulama> didn't someowne in jujugui write the go code for svg already? 
<urulama> someone even :D
<hatch> Makyo:  wrote a svg renderer yes
<jrwren> urulama: hatch thanks.
<frankban> urulama: Makyo did, but generating the svg is different than converting it to a raster in order to do pixel counts
<rogpeppe1> hatch: wasn't that something that generated svg to be rendered elsewhere?
<hatch> ^ that
<urulama> a, ok, generator ... not renderer. ok.
<hatch> so anyways, to do this is pretty trivial using phantomjs buuuut that requires phantomjs dependency heh
<hatch> can I propose having a microservice for this task?
<rogpeppe1> i guess this isn't *too* far away http://godoc.org/code.google.com/p/draw2d/draw2d
<rogpeppe1> but i suspect that svg is quite involved to parse and render, as every web standard is
<hatch> http://www.svgopen.org/2011/papers/34-SVGo_a_Go_Library_for_SVG_generation/
<jrwren> its *just* xml. :p
<hatch> lol riiiight
<hatch> urulama:  is a microservice an option?
<urulama> hatch: i'd like it not to be :D
<hatch> haha, well it probably 'should' be, they are all the rage now :)
<hatch> easy to test, upgrade, etc etc :P
<Makyo> SVGo was less than ideal, but oh well.
<frankban> rogpeppe1: exec.Command("convert", "input.svg", "output.png") ? ;-)
<urulama> :D
<Makyo> That'd work, heh
<Makyo> ImageMagick's a heavy dependency, but probably already on the system.
<hatch> think so?
<Makyo> Maaaybe?
<frankban> it is if the charm installs it
<hatch> haha
<jrwren> hatch: nice paper. I still find the CC attribution license strange.
<rogpeppe1> hatch: that doesn't render it
<rogpeppe1> hatch: it just produces svg
<rogpeppe1> hatch: which can be rendered elsewhere
<rogpeppe1> https://groups.google.com/forum/#!topic/golang-nuts/IonhQBFfg7o
 * rogpeppe1 tries to think of a way we can avoid the problem
<urulama> does anyone knows how much "cpu" does rendering of svgs take?
<rogpeppe> *producing* svg is easy
<rogpeppe> *consuming* it is hard
<hatch> jrwren:  rogpeppe no idea, I just found it while googling 
<urulama> maybe postprocessing job is not that bad of a solution
<hatch> :)
<hatch> I'm not sure if go has a library for parsing png pixel data but you can do it via js and canvas 
<hatch> but that requires phantom or th elik
<hatch> e
<hatch> although it sounds like the current winning solution requires imagemagick
<frankban> hatch: IIRC png handling is in the go stdlib
<hatch> which also isn't very small 
<urulama> jrwren: just do the get/post methods for the colour for now
<urulama> jrwren: and luca will be super happy, he'll be able to test and change colours on the fly :D
<hatch> frankban: ahh yes there is one that returns an Image interface....nice
<rogpeppe> frankban: yeah, that's an option, i guess
<rogpeppe> urulama: it's probably not too bad, if you're not running an external command that's reading and writing to the filesystem :-)
<hatch> so in that case imagemagik + that is probably the best option
<urulama> rogpeppe: no, no ... no disk involved
<hatch> why is disk bad?
<rogpeppe> wow, svg really is huge. http://www.w3.org/TR/SVG/single-page.html
<rogpeppe> hatch: bitmaps are easy to do in go
<hatch> rogpeppe:  right but you have to get from svg to png
<hatch> first
<rogpeppe> hatch: yeah
<urulama> i guess python has svg rendering lib?
<jrwren> so huge it took a decade to get browser support
<hatch> ohhhh kadams54 - how goes the reviews on huws stuff?
<rogpeppe> hatch: i'm wondering if we could just do it with an external process that processes svgs and adds background colour metadata
<hatch> rogpeppe:  thats what I suggested earlier :P
<rogpeppe> hatch: the downside of that is that you're not guaranteed a background colour in a timely way
<urulama> hatch: and that's what it looks will be at least a short term solution ...
<hatch> rogpeppe: what? 1s too slow? how long do you think it'll take? lol 
<hatch> it'll only need to be done when it's updated
<urulama> luca: from your perspective, could we have a delay on the charm colour when uploaded?
<rogpeppe> hatch: i was thinking of something entirely external to the charm store server, that just crawls charms that needs their bg colour updating
<luca> urulama: I would like a small delay so it has more impact
<urulama> luca: can we use PNGs instead of SVGs in charms ;)
<hatch> rogpeppe:  oh I was thinking that when a new charm is updated the charmstore would send the svg out for parsing 
<hatch> so it'll only need to be done once per icon update
<luca> urulama: ooooo, I donât know. I doubt it.
<rogpeppe> hatch: yeah, it could do that - that's essentially the "run the convert command" approach
<hatch> rogpeppe:  yeah - imho that's the best way because it's a bunch of code/process that will sit dormant 99% of the time
<rogpeppe> actually, i do know how we could do it in Go
<hatch> so might as well separate it out
<urulama> rogpeppe: with a queue. send an ID in the db, svg-renderer is a charm, related to the CS mongo, it takes the ID, process it ... 
<hatch> ^ that
<urulama> rogpeppe, hatch: classical batch system ... 
<hatch> yep, and if the svg has this 'major-colour' param then you can skip it 
<hatch> you could put it on a micro then, really
<rogpeppe> urulama: i'm not sure exactly what you mean by "send an ID in the db"
<rogpeppe> urulama: ah, perhaps you mean "from the db" ?
<urulama> that :)
<rogpeppe> urulama: you'd have to be careful how you find the next id to send
<urulama> when archive is posted?
<rogpeppe> urulama: what happens if the charm store goes down just after that?
<urulama> it's the same as cleaning up the blob/name mess
<rogpeppe> urulama: i think you'd need some kind of queue in the database, holding all the ids that still need colours
<hatch> it could just whip through the charms to find ones which are missing the metadata then send those out
<Makyo> jujugui trivial review/QA https://github.com/juju/juju-gui/pull/518
<hatch> even if there are 100,000 charms it'll only take seconds at most to query 
<urulama> rogpeppe: another collection?
<rogpeppe> urulama: yes, that's what i was thinking
<rogpeppe> urulama: when a charm is added, you add its id to the "needs external processing" queue
<rogpeppe> urulama: but then you run into issues trying to make it scalable
<rogpeppe> urulama: for example, what if you want to have several workers processing requests from the queue concurrently. then you need some kind of a lease system.
<hatch> rogpeppe:  honestly though - how long do you think it'll take that you need to do it like that? :)
<rogpeppe> jeeze, this is a lot of proposed mechanism to get 3 bytes of data.
<urulama> rogpeppe: that's why i was first suggesting batch system 
<urulama> rogpeppe: INDEED!
<urulama> luca: we don't need clours! :D
<jrwren> yes, I do not like these proposed mechanisms. I'd prefer to write Cgo to librsvg
<urulama> luca: colours even
<rogpeppe> jrwren: let's not add cgo as a dependency
<rogpeppe> jrwren: directly, at any rate
<rogpeppe> jrwren: we could perhaps have a separate binary
<jrwren> rogpeppe: why is that?
<luca> urulama: I disagree :P
<rogpeppe> jrwren: because cgo is evil :-)
<urulama> jrwren: I don't like something that is cpu intensive (or might be) to be needed when archive is posted
<jrwren> urulama: do we know it is cpu intensive? Its like the clock time of the processing task will be far less than time for network xfer of the post.
<rogpeppe> jrwren: and more concretely, it admits lots of potential C loopholes like buffer overruns etc
<jrwren> s/like/likely/
<urulama> jrwren: /me goes and look for that, have no idea about svg rendering requirements
<frankban> another possibility is the client (the GUI) to do that the first time using the "print to canvas" approach, then sending the result back to the server to be stored, subsequent requests don't need recalculation, and sooner or later the billions of GUIs out there will cooperatively do the job for us
<hatch> you're all talking like we are writing some system to manage google scale svg parsing, when atm we have, what, 100?
<hatch> and at what rate will they be added, max 1 per day?
<frankban> hatch: 100 * numSeries * numRevisions + the same for private charms
<hatch> we don't show icons for private charms
<jrwren> hatch: lets say customer X wants to sping up a new charm store, maybe they have a charmstore per department. Lets say they have these for prod, pre-prod, QA and dev envs.
<frankban> hatch: oh we do
<frankban> hatch: local charms
<hatch> right local charms
<jrwren> hatch: I share your concern of overengineering. I feel it is not quite as simple as we have just 100.
<rogpeppe> yeah, i'm thinking along jrwren's lines. when we bootstrap a new charm store, we don't really want to spend a great amount of time rendering svgs for all the charms
<hatch> ok 100 was an exaggeration 
<rogpeppe> i'm more concerned with the extra dependencies and complexity than the cpu time though, in all honesty
<hatch> we don't really store and need to parse svg's for all revisions do we?
<urulama> hatch: yes, but taking some time to find a proper solution is better then just do the wrong one because we can :D
<hatch> haha true
<hatch> so maybe the first step is hack something together real quick to see how long it takes to parse
<hatch> something imagemagik and go 
<hatch> then you'll actually know, this takes X ms to parse
<hatch> who knows, it could be so darn fast that it doesn't matter :)
<urulama> hatch: trying to use google for that, but we might have to do that, yes
<jrwren> time for i in `seq 1 1000 ` ; do rsvg-convert memcached/icon.svg > icon.png ; done  
<jrwren> my stupid quick get an idea for it test ^^^
<jrwren> 19s
<jrwren> on my old slow server
<hatch> 19s to convert 1000svg's to pngs?
<jrwren> yes
<urulama> wow!
<hatch> that's pretty fast :)
<jrwren> I know, kinda slow.
<hatch> lol
<jrwren> that also spawned 1000 processes, which is not insignificant
<hatch> jrwren:  what's the old slow server?
<jrwren> E8500
<hatch> oh ok, so not really that slow
<jrwren> That is a 6 year old CPU.
<hatch> right, but doesn't your script only use a single core?
<jrwren> but compared to clouds where we run, yes, its lightning fast.
<jrwren> yes, script is single core.
<hatch> yeah so a person could multi-thread it
<urulama> hatch: when you start talking about using cores, you know it's slow ;)
<hatch> urulama:  haha
<hatch> well if you put it on a quad core it'll cut it by 3/4 :)
<jrwren> i don't know how rsvg-convert is implemented.
<rogpeppe> jrwren: i was also looking at rsvg-convert
<hatch> no idea
<urulama> jrwren: let's stay with the get/post implementation
<rogpeppe> it works ok even when the source and destination are pipes too
<jrwren> urulama: ok.
<urulama> not saying to stop discussing about the solution
<urulama> just that we'll start with that
<hatch> Makyo:  I thought that we weren't going to show uncommitted units in the icon status bar? 
<hatch> am I getting my discussions cross?
<Makyo> Oh, I don't know.  Was there a discussion on that?
<Makyo> I took the path of least resistance, but can go that way, too.
<jrwren> In general, do we have specific performance requirements?
<urulama> jrwren: please take a svg from a charm and repeat the test?
<jrwren> urulama: that was a svg from a charm.
 * urulama drops a jaw on a floor
<urulama> that. is. slow.
<jrwren> 52/s sure is not fast.
<hatch> luca: you here?
<luca> hatch: hi
<jrwren> urulama: but again, that is a terrible test.
<hatch> luca:  the status bar on service icons, are we supposed to show uncommitted units in there?
<hatch> or ignore them from the status bar?
<urulama> jujugui: see you later
<luca> hatch: ignore them for the time being but that may change, I wanted to see how it worked
<hatch> cya urulamau
<kadams54> urulama: have a good one
<hatch> luca:  I'm just asking because Makyo is working on it atm, and it's easier to show them, vs hide
<hatch> but from a UX standpoint....does it make sense to show them?
<Makyo> hatch, luca I can show them with one CSS tweak as uncommitted blue fwiw
<hatch> yeah
<jrwren> I guess 52/s isn't THAT bad. 19ms sounds faster.
<hatch> lol
<hatch> jrwren:  add moar coars 
<Makyo> I kind of like it because then I can see how much I'm going to add in proportion to how much I already have.
<hatch> Makyo:  good point
<hatch> I'm good with it, just want luca's approval so we don't get another bug report :PPP
<Makyo> no prob
<luca> Makyo: you want to show them in the bar?
<rogpeppe> jrwren: here's the source for rsvg-convert, FWIW: http://paste.ubuntu.com/8160919/
<jrwren> rogpeppe: https://git.gnome.org/browse/librsvg/tree/rsvg-convert.c :)
<rogpeppe> jrwren:  :-)
<Makyo> luca, I do personally, but you're the designer :)
<hatch> haha
<rogpeppe> what i don't really get is why we can't implement this logic in the client, that's going to be rendering the svgs anyway
<Makyo> Let me screenshot
<luca> Makyo: ok
<luca> Makyo: I wanted to see how it worked in the GUI, it might be best to play with it there and then remove if necessary
<jrwren> rogpeppe: its a fair question. Why is meta/color in the spec?
<luca> Makyo: I wanted the health bar to depict health only
<rogpeppe> can't the client grab the svg, render it, pick out a pixel as appropriate, and use that
<rogpeppe> ?
<Makyo> luca, that makes sense, yeah.
<jrwren> rogpeppe: exactly.
<hatch> rogpeppe: jrwren: it's cpu intensive and quite a bit of overhead to do it all the time instead of just showing a provided hexcode
<luca> Makyo: should we try it with for the time being and then I can see how it feels and works?
<hatch> many cpu cycles around the world wasted for what? FOR WHAT? 
<Makyo> https://www.dropbox.com/s/e6z5k2betv6xoqy/Screenshot%20from%202014-08-27%2010%3A57%3A30.png?dl=0
<Makyo> luca, ^
<hatch> ;)
<Makyo> luca, sure, it's easy to back out.
<luca> Makyo: cool, will the blue also show in the inspector?
<Makyo> luca, we don't have the status bar in the inspector anymore, but it does still list uncommitted units with the blue uncommitted indicator.
<hatch> Makyo:  that's because it's broken ;)
<luca> Makyo: thats a bug, the health bar should be visible in the inspector
<rogpeppe> hatch: it might be worth trying to see how much time it actually takes when done client-side
<Makyo> Oh, then yeah, it'll show there.  The CSS affects both status bars
<Makyo> (and I'll see about fixing that)
<hatch> rogpeppe:  it has to load the svg, render it to a canvas, read the pixel data, determine which colour is the predominant one, then set the bg colour - on every page load
<hatch> vs, set background-color: #xxxxxx
<jrwren> hatch: ty, that is a good use case.
<Makyo> hatch, have the clients send the data back to the server to store, call it distributed :D
<jrwren> hatch: doesn't it load the svg and render it anyway?
<rogpeppe> hatch: well, on every page load that uses an svg we haven't seen before, i guess. or is it not possible to cache stuff client side?
<hatch> well no it caches the svgs
<hatch> but it'll need to render it to a canvas and do the processing every time
<Makyo> Could dump it in localstorage
<Makyo> Or whatever the KV pair thing is.
<jrwren> hatch: doesn't it do that anyway? or does it need this background color for some case where the svg is not rendered?
<hatch> yeah, but this is all vs setting a hex code as the bg
<hatch> jrwren:  svg is rendered as an image
<hatch> not into a canvas
<jrwren> oh! image not...
<jrwren> hatch: thank you. I see now.
<hatch> I'm not saying it's not possible - just that it's a lot of overhead for every pageload vs doing it once serverside and setting the bg colour of the container element
<hatch> code-wise it's also pretty trivial, just cpu intensive (and we only have a single thread)
<hatch> Makyo:  could you take a review of huw's branches?
<hatch> I'd like to get them landed
<Makyo> hatch, sure
<hatch> thanks
<rogpeppe> another possibility is to make it part of the charm uploader's responsibility
<hatch> Makyo:  thanks for the reviews!
<hatch> Makyo:  so you're leaving it with the uncommitted in the status bar? Just checking so I can +1 if so :)
<Makyo> hatch, yeah, it's easy enough to remove, and will give luca et al the chance to play with it.
<hatch> coolio
<Makyo> Will fix the status bar in the inspector next.
<hatch> +1'd
<hatch> awesome
<luca> Makyo: hatch thanks guys
<hatch> ugh ci
<hatch> jcsackett:  I don't know what bitch planet is but it sounds interesting.....
<jcsackett> hatch: scifi comic by kelly sue deconnick. modern reworking of 70s era "prison planet" films.
<hatch> interesting, guessing it's good?
<jcsackett> it hasn't actually started yet; launches in december.
<jcsackett> but everything else she's written has been awesome.
<jcsackett> she maintains a blog she posts art and stuff to for it, which is where that image came from.
<hatch> ahhh
<jcsackett> hatch: also, i am now running my blog on ghost, using the charm. :)
<hatch> *squeeeeee*
<hatch> what's your setup like? haproxy? apache?
<jcsackett> haproxy -> ghost -> mysql
<jcsackett> haproxy and ghost running on the same machine.
<hatch> cool, how much is it going to cost you per mo?
<jcsackett> $20. it's two 1024 linode instances; used manual provider.
<hatch> ahh cool, you should blog about it :)
<jcsackett> i did have to clone it and deploy a local version to get it out on trusty.
<hatch> I need to figure out a way to use the charm to redirect my tumblr urls to their respective ghost ones
<jcsackett> i intend to.
<hatch> yeah sorry about no trusty one - I need to write amulet tests before the trusty one will get promoted
<jcsackett> yeah, that's going to be difficult; i kept my tumblr and use ifttt to repost stuff from my blog to it.
<hatch> but what about people visiting the tumblr urls?
<hatch> they need to redirect, no?
<jcsackett> for me, no. i didn't get enough traffic to the individual urls to worry about redirection issues.
<hatch> ohh , I get about 5000 uniques per month so I kind of have to
<jcsackett> wow, nice.
<hatch> well....I guess :) 
<jcsackett> i ... don't. :p
<hatch> I have no idea why I get so much traffic tbh 
<hatch> I don't actively promote it or anything
<jcsackett> weren't you once upon a time a biggish name in YUI community places?
<hatch> I need to do some url rewriting or something, but I'm not sure if the apache charm supports such a thing, I'm not even sure where to start....maybe fork the apache charm and write my own?
<hatch> I was, but I only have a couple posts about YUI
<jcsackett> so, the apache charm takes a jinja template to set the vhost stuff.
<jcsackett> you could probably get it to then do rewrites that way.
<jcsackett> i couldn't even get it to work as a front end though, so gave up and did haproxy.
<hatch> jinja for vhosts? 
<hatch> heh
<hatch> no? What did it do?
<hatch> it should 'just work' 
<hatch> haproxy and apache2 both accept the same relation endpoint
<jcsackett> hatch: it did not "just work" when i related it. :p
<hatch> hmm, interesting
<jcsackett> haproxy did, so i didn't bother debugging.
<hatch> any errors or anything?
<hatch> oh ok
<hatch> I'll have to look into that because I don't think haproxy does url rewriting
<jcsackett> hatch: no juju errors. the hook executed just fine.
<hatch> I need 'something' to redirect with 301's 
<hatch> ohh maybe it does......
<hatch> Makyo:  qa'ing
<hatch> Makyo:  qa done, little issues
<Makyo> hatch, what do you mean 'spacing on the deployed status bar'?
<hatch> see the photos
<hatch> the gap on top is much bigger than on the bottom
<hatch> are the photos not showing up?
<Makyo> hatch, shit, sorry, privacy badger got them.  Will fix that.
<hatch> ahh different hosts
<Makyo> Yeah.
<Makyo> Got it
<Makyo> Still not quite sure what you mean on spacing\
<hatch> ok on the ghost one you see the huge empty space?
<Makyo> Yeah, I see that.
<hatch> ok and the deployed one, there is a space above and below the status bar
<hatch> the space above it is much larger before the divider line than the one below it
<Makyo> Alright, will see about trimming.
<hatch> but good work finding the issue :) 
<hatch> that one was a big oops
<Makyo> Yeah, didn't know about the mv flag in CSSland
<hatch> kadams54:  did you want to pass your branch off for the time you're gone?
<kadams54> hatch: I'm going to try to get it finished up tonight.
<hatch> kadams54:  ok cool, if you don't plz push it up and send an email to peeps
<kadams54> Will do
<hatch> man the icon rendering on tokens is real broken heh
<hatch> been working on it all day tracking down the issues
<Makyo> hatch, repushed, for whenever
<hatch> Makyo:  thanks, i'll probably look at it tonight, I'm in my own special version of hell right now
<hatch> :)
<Makyo> hatch, np, good luck
<huwshimi> Morning
<hatch> Makyo:  thanks, I 'think' I just got it
<hatch> sometimes it's the smallest things.....i am beginning to hate javascript
<hatch> lol
<hatch> morning huwshimi
<huwshimi> hatch, Makyo: Thanks for all the reviews!
<hatch> np :) the damn ci was runnin almost all day haha
<hatch> gw
<hatch> thanks for doing all them
<huwshimi> np
<hatch> huwshimi:  hey I'm heading out for a while, need anything before I take off?
<huwshimi> hatch: I'm all good. Have a good one
<hatch> you too, cya
<huwshimi> bye
#juju-gui 2014-08-28
<urulama> jujugui: when using juju, please use logging: juju bootstrap --logging-config="<root>=DEBUG;juju=TRACE"
<frankban> urulama: morning
 * frankban lunches
<hatch> morning
<hatch> luca are these same bugs on chrome osx?
<luca> hatch: yea, though it seems to be popping up in parts that were unaffected
<luca> hatch: or I didnât notice them
<hatch> the issue doesn't happen in any other browser though, correct?
<hatch> jujugui is anyone running chrome canary? Are you having svg rendering issues like reported here https://bugs.launchpad.net/juju-gui/+bug/1358671
<mup> Bug #1358671: Charm icons not rendering properly <juju-gui:Triaged> <https://launchpad.net/bugs/1358671>
<urulama> Chrome Version 37.0.2062.94 ... works fine
<urulama> hatch: is thath jujucharms.com?
<frankban> hatch: I've seen that issue with my chrome on linux: 36.0.1985.125
<hatch> yeah I'm just wondering if it's fixed in canary
<hatch> canary isn't available for linux unfortunately
<hatch> guess I can grab it for osx
<hatch__> Makyo: you in yet?
<hatch__> luca:  are you running chrome canary? Can I get you to run chrome canary? :)
<luca> hatch: I have chrome canary
<luca> hatch: and yes, as far as I can tell it doesnât happen in any other browser
<hatch> luca:  can you plz make sure it's updated and use it for a while to see if the issue persists? There is another issue with the charms with the default icon (it's just grey) but it doesn't appear to have the rendering issues of the others
<hatch> luca:  I need to file a bug with chrome and go through the process of setting up a repro and all that - so if it's fixed on canary then we can just wait :/
<luca> hatch: I can confirm the bug does not appear in chrome canary
<luca> hatch: though the deafult icon is missing
<hatch> it's just dark grey right?
<luca> hatch: yep
<hatch> luca:  ok phew - that's an issue I can handle
<luca> hatch: lol
<hatch> :) can you plz use canary for a while with it? 
<hatch> just to be sure
<luca> hatch: sure
<hatch> I'm in Ubuntu land so it's hard for me to actually use it frequently
<hatch> thanks!!
<luca> hatch: lol
<luca> hatch: since it works in canary, does that mean that when they send another update the svg charm icon bug will be fixed and that itâs not our problem/
<luca> ?
<hatch> yep
<luca> hatch: I see, weird bug
<hatch> yeah, chrome is falling appart 
<hatch> it's 100% slower than safari for our tests atm
<hatch> and absolutely destroys my battery life
<luca> hatch: really? jeez
<hatch> luca:  yeah...lets just hope they do another release before we push out mv :)
<hatch> or we'll have to do all of our marketing shots in osx
<hatch> lol
<hatch> or *gasp* windows!
<luca> hahaha never!
<hatch> lol
<hatch> luca:  see now that the issue is restricted to a single svg, and happens 100% of the time, it'll be so much easier to debug/create a repro for
<luca> hatch: I bet hehe
<urulama> jujugui: i forgot about that i have parents meeting today, i'll be out for a daily call today, but be back later ... 
<hatch> good luck
<hatch> other parents can be so catty 
<hatch> :P
<urulama> :D
<hatch> I've been listening to http://www.di.fm/chillstep while working this week - pretty good work tunes
<urulama> hatch: i put my Hue lights to "concentrate" mode :)
<hatch> haha, and what mode is that? red?
<hatch> dim red?
<hatch> no blue
<hatch> yeahhhhhh blue
<urulama> hatch: bright white :)
<hatch> lol
<hatch> jujugui call in 8
<hatch> jujugui call in 2
<hatch> kanban it up!
<Makyo> Hangouts freezing for me
<hatch> bac: call
<Makyo> hatch, https://en.wikipedia.org/wiki/The_Treachery_of_Images
<hatch> yep, I can honestly say I've never seen said pipe
<bac> what about http://en.wikipedia.org/wiki/The_Son_of_Man
<hatch> ohh I think I've seen that one
<jcsackett> Makyo: you said we were showing blue in the health bar for uncommitted units?
<jcsackett> i'm qa-ing your branch and i'm seeing uncommitted units just not accounted for, it looks like.
<jcsackett> Makyo: to be clear, i'm fine with the health bar not showing them at all; i just want to confirm what i should be seeing.
<Makyo> jcsackett, they were two separate branches; I don't think the blue-uncommitted branch was merged into the inspector-statusbar branch.
<jcsackett> Makyo: oh, right. i am conflating things.
<jcsackett> Makyo: never mind then. :p
<lazyPower> rick_h_: https://bugs.launchpad.net/charmworld/+bug/1360374
<mup> Bug #1360374: bundle proof is unaware of MAAS tagging <charmworld:Confirmed> <https://launchpad.net/bugs/1360374>
<lazyPower> this is a blocker for some of the newer bundles we are getting
<hatch> lazyPower:  he is on vacation until Monday
<hatch> best to send an email
<hatch> ok all, I'm out for a bit, bbl
<bac> lazyPower: i can look at that issue this afternoon
<lazyPower> bac: thanks.
<hatch> bac:  so....the guy fixed the issue with a power thingy-a-ma-bob reset :/
<hatch> bac in case you want to try it on your computer I can give you the details
<hatch> jcsackett:  r u able to do a review on #520 and #521?
<jcsackett> hatch: i can in a few sure.
<hatch> thanks 
<hatch> muchly
<hatch> one more token bug down, one more to go (on sandbox)
<hatch> I hope these sandbox fixes also fix the issues in the real env's
<hatch> heh
<marcoceppi> hey, is the guiserver proxy aware?
<marcoceppi> seeing an issue deploying a bundle behind an HTTP proxy
<hatch> marcoceppi:  I'm not entirely sure what you mean
<hatch> as long as the gui can wss to the guiserver and the guiserver can wss to juju
<marcoceppi> deploying a bundle is failing
<marcoceppi> because the guiserver can't seem to get to charmstore, but juju via CLI can deploy the charm fine
<marcoceppi> also, this is all second hand info
<hatch> ohh ok, hmm well any idea if the gui can deploy the charm not in a bundle?
<marcoceppi> let me find out
<hatch> thanks
<hatch> tbh it's been a long time since I've done anything in the guiserver but as far as I understand there is only one place where it goes and reaches out to the charmstore
<hatch> marcoceppi: Is it this one? bug #1362749
<mup> Bug #1362749: bundle deployment failed on juju-gui with proxy <juju-gui:New> <https://launchpad.net/bugs/1362749>
<marcoceppi> hatch: looks like it, fwiw, deploying a single charm works
<marcoceppi> oh, that's the person that told me about i
<hatch> marcoceppi:  ahh ok yeah that's very odd, frankban is the guy to talk to about this one as he knows it best
<hatch> I'll point it out to him
<marcoceppi> hatch: thanks
<hatch> I REALLY hate how launchpad doesn't feel it necessary to include a link to the bug on status update emails
<kadams54> guihelp: need reviews/QA on: https://github.com/juju/juju-gui/pull/523
<kadams54> hatch: didn't have the internet connectivity I thought I'd have this morning, but am now connected again. That PR means I can officially relax and enjoy my swap days :-)
 * Makyo -> appointment
<hazmat> rogpeppe1, rick_h_ ping
<hazmat> marcoceppi, hatch i've got a fix and mp ready to fwiw
<hazmat> rogpeppe1, rick_h_ nm
<rogpeppe1> hazmat: pong
<rogpeppe1> hazmat: if you still care :-)
<hazmat> rogpeppe1, i don't ;-)
<rogpeppe1> hazmat: :)
<hazmat> rogpeppe1, was curious about any deployed charm store changes.. 
<hazmat> rogpeppe1, cause $ juju publish use to give events.. and feedback and part of the new spec was deprecating that (replacing it with...)
<rogpeppe1> hazmat: nothing in the new charm store has been actually deployed yet
<hazmat> rogpeppe1, great :-) 
<rogpeppe1> hazmat: any thoughts you have around the issue would of course be appreciated...
<hazmat> rogpeppe1, i'll be in london starting sunday incidentally for the week.. if by chance your around.
<rogpeppe1> hazmat: i'll be on the isle of skye
<hazmat> rogpeppe1, basically publish cli pulled the events to give charmers feedback on issues with their charm
<hazmat> sounds exotic
<rogpeppe1> hazmat: which is only about 14 hours drive away :-)
<hazmat> rogpeppe1, a validate endpoint might also suffice if there are  no more events..
<rogpeppe1> hazmat: no actually, 11h
<rogpeppe1> hazmat: the eventual aim is to have people publish their own charms
<rogpeppe1> hazmat: rather than have a central ingestion process
<rogpeppe1> hazmat: but in the meantime (until identity is more sorted) we'll probably have a similar issue. 
<hazmat> rogpeppe1, yes.. re publish own charms.. probably also want central ingest
<hazmat> need both
<hazmat> rogpeppe1, seems like a long way away.. as in what happened this cycle..
<hazmat> rogpeppe1, brussels in october.. many fine beers ahead ;-)
<rogpeppe1> hazmat: looking forward to that
<rogpeppe1> hazmat: happy memories of previous brussels trip, some years ago now
<rogpeppe1> hazmat: another thing we want to do is provide an external validation command that does the same validation that the charm store will do
<rogpeppe1> hazmat: we *could* add events again, i guess, too.
<hatch> hazmat: oh ok awesome
<hatch> hazmat:  you're going to brussels as well? Awesome I'll have a beer drinking buddy :)
<marcoceppi> thanks hazmat
<hatch> hazmat:  thanks for making the fix for that bug
<huwshimi> Morning
<hatch> morning hazmat
<hatch> er 
<hatch> morning huwshimi
<huwshimi> hatch: How's things?
<hatch> ohh decent
<hatch> I solved the token icon bugs
<hatch> just working on the tests
<hatch> your branch which renders the nested containers is going to cause me issues
<hatch> buuuuut oh well :)
<huwshimi> hatch: Oh, sorry about that :)
<huwshimi> hatch: Actually that branch could do with another review if you have some time? https://github.com/juju/juju-gui/pull/522
<huwshimi> hatch: What was the issue with the icons?
<huwshimi> I mean, what was the solution?
<hatch> huwshimi:  here is a wip https://github.com/juju/juju-gui/pull/524
<hatch> basically there were many....
<hatch> haha
<hatch> this fix is also just a stop-gap 
<hatch> there is still some rendering issues with things disappearing before re-appearing
<hatch> buuuuuut those issues are too deep to fix
<huwshimi> hatch: Oh , this is not for the issue where the svg is all messed up then?
<hatch> oh, no that issue is a chrome bug
<huwshimi> Ah I see
<hatch> it's -mostly- fixed on canary
<hazmat> hatch, g'morning ;-)
<hatch> haha sorry
#juju-gui 2014-08-29
<rogpeppe1> anyone know how to get a list of all charms? i used to use http://manage.jujucharms.com/api/2/charms?text= but it doesn't seem to produce many results now
<urulama> rogpeppe1: that or just simplu /api/2/charms should return all results :(
<rogpeppe1> urulama: yeah
<urulama> rogpeppe1: that or just simplu /api/3/charms should return all results :(
<rogpeppe1> urulama: and it did when i used it last
<rogpeppe1> urulama: but it's changed now
<urulama> rogpeppe1: what about http://manage.jujucharms.com/api/2/search?text=*
<rogpeppe1> urulama: more results, but i bet there are more than 85 charms total...
<urulama> rogpeppe1: not sure ;) http://manage.jujucharms.com/charms
<rogpeppe1> urulama: there are 285 rows in that table...
<urulama> rogpeppe1: i know, was joking 
<urulama> rogpeppe1: search code: http://bazaar.launchpad.net/~juju-gui-bot/charmworld/trunk/view/head:/charmworld/search.py
<hazmat> frankban, ping.. could you have a look at https://bugs.launchpad.net/juju-gui/+bug/1362749
<mup> Bug #1362749: bundle deployment failed on juju-gui with proxy <juju-gui:New> <https://launchpad.net/bugs/1362749>
<hazmat> i've got a mp attach to it
<frankban> hazmat: I reviewed it this morning, thanks for the patch!
<hazmat> frankban, oh.. awesome. thanks
<frankban> hazmat: if you merge it to the dev branch I can work to make a charm release today (if the fix is urgently required)
<hazmat> frankban, sounds good.. responded on the mp
<hazmat> frankban, people in front of customers think everything is an earth shattering fire drill.. let's hold off on the release and the merge for a moment, i haven't gotten confirmation yet regarding the fixes working in the field (they work locally sans proxy and the same fix by hand also worked in proxy env).. the very brief in-field testing got a complaint about login not working with the changes but afaics that's not possible.. waiting for field op to come b
<hazmat> ack online to take further.
<frankban> hazmat: cool, my suggested os.getenv('no_proxy', os.getenv('NO_PROXY')) basically do the same, but since you're mirroring code in urllib, that's all good, thanks
<hazmat> frankban, yeah.. same behavior.. i like your spelling better
<frankban> hazmat: sounds good
<hatch> morning all
<urulama> heya
<hatch> apparently I've worked at Canonical too long today....all the ads on sites I frequent are about finding a new career lol
<hatch> guys....I can be a web developer in only 9 months and work at goggles!!!!!
<urulama> hatch: what an offer!
<urulama> :)
<hatch> I know right?!?!?
<hatch> hmm....lets see what THIS add will sell me
<hatch> oooOOooo I can get a degree in criminal psycology 
<hatch> psychology even 
<hatch> ^ that's probably only funny to the north americans :)
<urulama> and play in news series, Saskatoon CSI
<hatch> lol!
<hatch> I can also get a degree in video editing
<hatch> maybe I can get BOTH and make a tv show Saskatoon CSI
<hatch> :)
<urulama> and do the web page for it!
<hatch> hahahaha
<hatch> damn I'd be unstoppable 
<hatch> THIS add doesn't even tell me why I should quit....just that I should 
<hatch> probably because "my aunt made $10,000/month working from home"
<hatch> lol
<hatch> ahh internets 
<hatch> jujugui call in 10
<rogpeppe2> hatch: i probably won't be able to make it. internet is pretty sketchy currently.
<rogpeppe2> jujugui: looks like connection has dropped nowq
<hatch> urulama_: any idea how decent the public transit is there?
<urulama_> hatch: its fine
<hatch> cool
<urulama_> hatch: the metro and tram seem to be close
<urulama_> hatch: we are 100m away from one of the best known traditional beer pub :)
<urulama_> hatch:  A La Mort Subite
<urulama_> probably does not need translation ;)
<urulama_> and really close to another one, Au Bon Vieux Temps
<urulama_> and another  Le Corbeau
<hatch> haha excellent
<jcsackett> hatch: oh god, "isBrowserSupported" issues again...
<hatch> jcsackett:  lol - best, errors, ever!
<hatch> Makyo:  nice tat!
<Makyo> hatch, hah, thanks
<hatch> hurt?
<Makyo> Nah, it felt good yesterday.  Just feels like sunburn today.
<hatch> oh that's good, another guy I know got one the other day too, except the edges are blurry, not sure how that happened
<Makyo> Depends on the artist and the needles, I suppose.  I wanted the sharp outline
<hatch> yeah, it's really cool
<hatch> are you already plannign your next one?
<hatch> ;)
<Makyo> Hah! It'll be a bit, though James wants to get something together.
<hatch> ahh that'll be cool
<jcsackett> jujugui: i need two reviews on https://github.com/juju/juju-gui/pull/525 (ignore the listed status, there's a link to a passing test run in comments)
<Makyo> On it
<jcsackett> thanks, Makyo.
<Makyo> jcsackett, sorry it took so long, stylesheets weren't regenerating, couldn't figure out why
<jcsackett> Makyo: no worries. :)
<hatch> http://yahooeng.tumblr.com/post/96098168666/important-announcement-regarding-yui
<hatch> No Mo YUI
<jcsackett> so...dart then, i guess? :p
<jcsackett> jujugui: i need one more review (no qa) on https://github.com/juju/juju-gui/pull/525
<hatch> jcsackett:  on it
<jcsackett> hatch: thanks.
<hatch> today is just not my day, even the mv code is driving me nuts
<hatch> jcsackett: +1'd even though I hate the fragmentation lol
<Makyo> jujugui should deleting the last unplaced unit of a service with no other units delete the service?
<Makyo> I hate corner cases >:T
<hatch> Makyo:  nope
<Makyo> hatch, good answer!
<hatch> lol
<hatch> it's technically allowable to have 0 units and a service
<Makyo> True.
<Makyo> (and easy)
<hatch> gota love when the easy way is the right way :)
<jrwren> ugh.  http://yahooeng.tumblr.com/post/96098168666/important-announcement-regarding-yui
<hatch> jrwren:  oh you're late to the party
<hatch> I already posted that
<hatch> :P
<jrwren> ah, when my net was down.
<jrwren> i missed all the lamentation?
<hatch> nah there wasn't much
<hatch> switching to Dart tomorrow though while everyone is off
<jrwren> hahahaha. switching it all, eh?
<hatch> all in one night
<hatch> I actually could switch the entire app to TypeScript in about 10 minutes.....buuuuut
<hatch> pregreplace(|\.js|, 'ts')
<hatch> ok less than 30s
<hatch> :D
<jrwren> hatch: yay TypeScript
<hatch> tbh I have been pushing for us to use TS for a long time
<hatch> :)
<jcsackett> hatch: hatch i don't think i've ever heard you say anything about typescript before.
<jcsackett> hatch: also, what do you mean "fragmentation"?
<hatch> jcsackett:  maybe it was before you guys joined 
<hatch> jcsackett:  you had to touch so many things to mark things disabled
<hatch> it's not your fault - just how mv grew
<jcsackett> hatch: oh, yeah.
<jcsackett> you think you hated it? try writing it. :p
<hatch> lol!!
<urulama_> jujugui: have fun, see you all next week
<bac> hi jcsackett
<jcsackett> hola bac.
#juju-gui 2014-08-31
<huwshimi> Morning
<rick_h_> huwshimi: howdy
<huwshimi> rick_h_: Great news over the weekend :)
<rick_h_> huwshimi: oh yea?
<rick_h_> huwshimi: how goes things?
<huwshimi> rick_h_: About YUI
<rick_h_> huwshimi: :P
<rick_h_> huwshimi: yea, I emailed the thread on it this weekend
<huwshimi> rick_h_: It'll be interesting to see what we come up with.
<rick_h_> huwshimi: yea, will take some work and we've got some WIP that means we should peek at things. I'd like to see us lead the way here, but that'll come with some costs of velocity
<huwshimi> yea
<huwshimi> rick_h_: I think we've got the most invested in YUI too
<rick_h_> yea, we're definitly not going to be rewriting upteen thousand lines of code tomorrow
<huwshimi> :)
<huwshimi> That's good
<huwshimi> rick_h_: Do you have any initial thoughts about what stacks might be worth looking at?
<rick_h_> angular will come up, everyone wants jquery
<huwshimi> rick_h_: Do you like it?
<rick_h_> I'd like to look at react and what it would take to build some tools around it
<rick_h_> but we're in a nice position we can stick with modern browsers and don't need much of jquery/etc
<rick_h_> I'm not a fan of jquery or angular
<rick_h_> angular has too much magic, makes it hard to debug, and won't scale out well to our needs. Though angualr 2.0 is supposedly coming and will help
<rick_h_> bah, uploading pics and streaming a movie makes for lack of bandwidth for even irc to stay working
<huwshimi> ouch
<huwshimi> rick_h_: I guess one of the hardest parts for us is how to migrate to a new stack without a big rewrite
<huwshimi> JS makes it hard to isolate components
<rick_h_> huwshimi: yea, basically we'll have to find an adaptor on either the YUI end or the new end
#juju-gui 2015-08-24
<rick_h_> cory_fu: ty for the bundle v4 support MP's. I've asked Makyo to peek and help make sure everything looks cool and we've no suggestions from our end.
<cory_fu> Awesome, thanks.  We need these changes to get the big data bundles passing the test runner.  I tried to make the minimal changes to include support, so definitely LMK if it could be addressed better, though I would like to see a fix out as soon as possible so we can see our bundles passing.  :)
<rick_h_> cory_fu: understand, Makyo will look today and so can help provide feedback pretty quickly
<cory_fu> Thanks
<Makyo> cory_fu: +1
<cory_fu> Excellent.  Thanks
<cory_fu> I do wish there were a better way to distinguish the bundle formats.  Adding a "version" or "format_version" or such field would be really n ice
<Makyo> cory_fu: agreed :/ We went through similar hoops in bundlelib.
<cory_fu> Adding a top-level key that is required for v4+ and defaults to v3 seems like it would be reasonable to me, but that's just off the top of my head
<rick_h_> cory_fu: we thought about it, the issue is that we're asking the user to tell us and it's a chance for a user to get it wrong
<rick_h_> cory_fu: so it's awesome from a lib developer standpoint, but a pita for a bundle writer/user standpoint as it's one more thing to break
<cory_fu> There is that.
<rick_h_> cory_fu: so we take the burden in the hopes the devs appreciate it and buy us beers one day :)
<cory_fu> rick_h_: OTOH, there are clearly constraints that the user already has to conform, and we provide tools to help them do so (proof).  Allowing the user to be explicit about the version they *intend* seems like it would actually lead to fewer confusing errors.
<cory_fu> I guess the current heuristics are fairly reliable due to the drastic change in the format, though
<rick_h_> cory_fu: yea, I can be convinced we're wrong for sure. Honestly, we've not had the uptake in folks using it since we released it because they didn't "HAVE TO" so we don't have good data either way
<rick_h_> cory_fu: but just fyi'ing on the picture there as it was thought about for sure
<cory_fu> Well, I'm sure the lack of support in the rest of the tooling (proof, deployer, bundletester, etc) didn't help uptake, and all of that is now changing
<rick_h_> cory_fu: <34
<rick_h_> err <3
<cory_fu> heh
<cory_fu> I read that as "less than rule 34" and was a little concerned.
<rick_h_> my typing is horrible today, must have gotten my fingers more bit up fishing than I thought this weekend :P
<cory_fu> Ouch
<rick_h_> those bass tear up your thumbs when you lip them hah!
<cory_fu> ha, I'm sure
<sinzui> hi bac, jcsackett, Do either of you have time to review https://code.launchpad.net/~sinzui/juju-quickstart/all-regions/+merge/268961
<rick_h_> Makyo: ^ ?
<Makyo> I'll take a look rick_h_ sinzui
<rick_h_> Makyo: ty much!
<Makyo> I'm glad we've finally settled where Amsterdam is.
<Makyo> +1
<rick_h_> Makyo: can you land that if that's cool please?
<Makyo> rick_h_: sure
<Makyo> rick_h_: Embarrassing, but I only ever used lbox to merge code on launchpad.  Do I need to do anything other than mark it as merged?
<rick_h_> Makyo: you have to run the lbox submit thing. 
<rick_h_> Makyo: basically if you can run tests then you bzr branch, merge it into trunk, push to  trunk. 
<Makyo> rick_h_: ack. Will take a bit to get that updated.
<rick_h_> Makyo: understand
<Makyo> rick_h_: sinzui I did the thing! \o/  
<Makyo> Been forever since I worked with bzr, sorry for the delay.
<sinzui> thank you Makyo 
#juju-gui 2015-08-26
<frankban> tvansteenburgh: hi, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-bundle-v4/+merge/267540 ? we need that to be merged and released, thank you!
<tvansteenburgh> frankban: will do
<frankban> ty!
#juju-gui 2016-08-31
<rock__> Hi. I deployed OpenStack on LXD using https://github.com/openstack-charmers/openstack-on-lxd. I have created "cinder-storagedriver" charm . I pushed the created charm to public charm market place(charm store). So Using JUJU GUI when i was trying to deploy "cinder-storagedriver" charm by adding relation  to "cinder" it was throwing an error.
<rock__> ERROR: Relation biarca-openstack:juju-info to cinder:juju-info: cannot add relation   "biarca-openstack:juju-info cinder:juju-info" : principal and subordinate applications' series must match.
<rock__> Manually , When I was deployed our charm by taking from charm store then it is able to deploy and able to add relation to cinder.
<rock__> But I can able to deploy my charm through juju cli by taking from charm store. And I can able to add relation to cinder successfully. 
<rock__> sry. As part of debug,  I deployed juju-gui as $juju deploy cs:juju-gui-134 on our setup. But it was showing series as trusty even we have choosen xenial.
<rock__> I am thinking this is JUJU-GUI issue.
<rock__>  (or) Is it some other issue? Please anyone respond to this issue.
#juju-gui 2017-08-29
<bdx> hey, just checking out the status beta at staging.jujucharms.com - looks awesome, nice work!
