#juju-gui 2013-09-30
<rick_h_> the email it burns!
<gary_poster> lol
<gary_poster> welcome back rick_h_ 
<gary_poster> good to have you back. hope you had a good time
<bac> gary_poster: on stable and dev ~juju-gui-charmers PPA doesn't have saucy builds.  want a card for that?
<gary_poster> bac, sure thank you. high priority has room, and that seems about right.
<gary_poster> rick_h_, when you get a chance, please add this to your list of emails to slog through, or similar :-) : http://jujugui.wordpress.com/2013/09/27/bugs-vs-kanban/
<gary_poster> rick_h_, that is what we agreed, but we are happy to revisit if you disagree and want to be convincing. :-)
<rick_h_> gary_poster: sure thing, I read through that and +1. I think it reads kind of what we had talked about where kanban is committed work and the only 'change' is let's do better to syncing the cards with bugs we've gotten done
<gary_poster> ok cool rick_h_ thanks
<rick_h_> and yea, good time by all, DC Zoo was awesome. VA mountains are awesome. My own bed is awesome lol
<gary_poster> lol great :-)
<rick_h_> and the touareg has a 'spirited' side taking us through back mountain passes with > 8 deg grades and emergency runaway truck lanes and fog so thick you can't see the brake lights of a guy 2 car lengths in front of you. 
<rick_h_> but she loved powering through those 
<gary_poster> lol, sounds fun in a "I hope I don't drive us all off the side of a mountain" kind of way :-)
<rick_h_> yea, let's just say my wife wants me to start double checking the GPS the car produces more often
<gary_poster> heh, yeah, DC has brought that conversation up for us more than once actually.  DC appears to be an anti-GPS zone
<rick_h_> well that part worked well. We got rerouted twice due to traffic conditions. It was crazy, towing a 5,000lb trailer to get the notice "In 1 mile, take the exit on the left" in a 6 lane wide highway
<bac> too much vietnamese food?  i type 'make tet' way too often.
<gary_poster> hey frankban, running make in the charm on saucy is downloading and trying to build bzrlib, even though I have bzr 2.6.0 installed.  This then fails because I do not have libpython-dev installed, afaict.  Shoudl I install libpython-dev and add that to the charm dependencies, or should the charm not being trying to build bzrlib?
<frankban> gary_poster: hi! bzrlib is required by juju-deployer. so, if libpython-dev is not listed in make sysdeps it should be added
<gary_poster> frankban, cool, on it, thanks
<rick_h_> yay, readthedocs fixed their bzr stuff http://charmworld.readthedocs.org/en/latest/api.html
<frankban> guihelp: could anyone please review https://codereview.appspot.com/14125043 ? 1 review + 1 QA. thanks!
<gary_poster> jujugui if you are coming to the resolve/retry mtg with luca it is in less than one minute in https://plus.google.com/hangouts/_/eeadd54f49162797f746e11bc0adc95c87a0e963
<gary_poster> (see your calendar for detaisl)
<gary_poster> luca__, you coming?
<luca__> just grabbing my charger
<luca__> gary_poster: ^
<gary_poster> cool
<benji> frankban: which file in the GUI has the tests for the deployer integration?
<gary_poster> benji, the only gui deployer integration we have so far is from bcsaller
<frankban> benji: did not work on the client side deployer support, you might ask ben
<gary_poster> and it is on the env
<benji> ok; I think I see it now
<bac> hey benji can you review https://code.launchpad.net/~bac/charmworld/fix-icons/+merge/188341 ?  it is a critical charmworld fix for broken icons.
<benji> bac: I'll look right now.
<bac> ty
<rick_h_> gary_poster: so I'll update #1229215 with the first step we talked about
<_mup_> Bug #1229215: Confusing unit retry/resolve UX <juju-gui:Triaged> <https://launchpad.net/bugs/1229215>
<gary_poster> awesome thanks rick_h_ 
<benji> bac: apparently my "right now" is a little off today; the branch looks good.
<bac> thanks benji.  will land and release soon.
<gary_poster> frankban, hey.  I'm still having trouble making the charm.  I'm on saucy fwiw, but I think this issues is a chicken and egg problem.  http://pastebin.ubuntu.com/6175862/  It looks like bzr is trying to build itself, and found a plugin in my .bazaar directory and so tried to include that in docs, but the rvsubmit plugin expected launchpadlib, which exists in my system just fine but has not yet been built in the virtu
<gary_poster> alenv (because it needs bzr to be built).  So, it's a loop.  The solution would seem to be to exclude my plugins from the bzr build step.  I don't see an automatic way to do this, so I just plan to move my ~/.bazaar directory aside manually, temporarily.  Agree, or do you have another idea?
<bac> abentley: i just had a charmworld MP approved.  lander being tested.
<bac> abentley: does it run at :00 ?
<abentley> bac: I don't understand.  I'm trying to restore the lander.  AFAIK, it's not running successfully.
<bac> abentley: last week you asked to be alerted when we had branches to be landed.  i wasn't aware that the new lander was not working.
<abentley> bac: The trigger runs every minute, does that answer your question?
<bac> abentley: that does
<frankban> gary_poster: looking
<gary_poster>  :-P biabfrankban, going to another call
<gary_poster>  supposed to be this: frankban, going to another call :-P biab
<abentley> bac: Okay, so jcsackett reported problems Friday afternoon.  I tried to fix them, but ended up locking myself out of the instance.
<bac> abentley: ok.  please let me know what i should do, if anything, to get my branch merged.  i'm happy to wait a little while but i'd like to do a charmworld release today.
<abentley> bac: Run the tests locally, merge into trunk locally, commit and push trunk.
<bac> abentley: ok, i understand the manual procedure.  i was asking more if you wanted me to wait to see if the lander would work on my branch.  as i said, i'm happy to do that for a limited amount of time.
<abentley> bac: I can't give you an estimate for how long this will take.  The floor keeps collapsing underneath me with every step I take.
<bac> ok.  i'll land manually.  good luck abentley.
<rick_h_> lol benji you don't like my python docstrings with params? :)
<rick_h_> gary_poster: so I think I'm close enough on email atm, if I was sick of email and wanted to code something did you have a place you wanted me to jump into or just grab a bug and go forth?
<benji> nope :)
<rick_h_> benji: do you displlike it on the js @param business as well or python in particular is buggy?
<hazmat> gary_poster, incidentally there are a few bugs around the notifications in the last release.. once you enter the full screen errors you cant go back
<gary_poster> rick_h_, "Make bundle token realer": make the bundle token thing actually do the right thing
<rick_h_> gary_poster: rgr
<gary_poster> hazmat, yeah, thank you, known bug.  for next release (this week) we are simply removing the "all notifications"
<benji> rick_h_: I dislike it in JS too, but at least we have tools that actually parse it there, we're not doing anything like that on the Python side.
<hazmat> gary_poster, cool
<rick_h_> benji: ah, ok.
<frankban> gary_poster: make BZR_PLUGIN_PATH='-user' should prevent bzr from importing plugins from HOME.
<gary_poster> frankban, ah, nice!  I'll add that to Makefile too
<gary_poster> thank you
<frankban> gary_poster: yeah, if it works, adding that to the Makefile sounds great, thank you
<gary_poster> cool
<bac> hey benji i had to fix a ton of pre-existing lint problems in my branch.  could you re-approve https://code.launchpad.net/~bac/charmworld/fix-icons/+merge/188341 ?
<benji> bcsaller: hi, are you in?
<benji> bac: sure
<bac> actually since i'm landing it by hand it doesn't matter
<bcsaller> benji: yes
<benji> bcsaller: cool, a question about the deployer bits: is it (more or less) finished?  I.e., given a deployer file will it deploy the described services, relations, config, etc.?
<bcsaller> benji: It should fire off the env call to an actual backend with the proper data (though that could use more testing) but that call is also implemented in the fakebackend and that will simulate a deploy now
<benji> bac: looks good [but man I dislike a couple of the whitespace rules that linter insists upon, especially the two spaces before inline indents; who does that?)
<benji> bcsaller: ok.  I'm asking because (in my in-development branch that may well be doing something wrong) I don't get correct results when deploying a bundle using its deployer-formatted description.  I'll look deeper.
<hatch> morning
<benji> bcsaller: are there any demo deployer files that are known to work that I can reference?
<benji> hatch: it seems your jetlag-induced early-bird desires have been defeated
<bcsaller> benji: you can export something on the canvas today and re-import that but there is test/data/wp-deployer.yaml as well
<benji> bcsaller: cool, thanks
<hatch> benji: haha, nah had eye doc appt
<benji> ah
<hatch> 20/20....like a boss
<benji> I was 20/13 the last time I had mine checked, but I'm probably down to 20/20 by now.
<abentley> bac: I am ready to try an auto landing.  Will that interfere with you?
<bac> abentley: i just pushed mine
<bac> abentley: so, no.
<abentley> bac: Great.
<gary_poster> I'm, like, 20/5000000
<hatch> lol
<hatch> blind like bat?
<gary_poster> contacts work for me because glasses would tilt the earth off its orbit
<hatch> rofl
 * hatch is gona review/qa frankban's branch
<benji> heh
<frankban> hatch: thanks
<benji> gary_poster: except that your contacts are so thick that you have to take them out to blink
<gary_poster> benji, lol, no, I just have callouses under my eyelids... (might not entirely be a joke, not sure... :-P)
<hatch> haha
<benji> yow
<gary_poster> and, yes, yuck :-)
<benji> I'll make my millions by inventing eye lube for the overly-thick contact market.
<bcsaller> benji: did that file import for you?
<benji> bcsaller: I'm just visually comparing it with my data right now, I haven't tried to import it... one sec an I'll try.
<benji> bcsaller: "Import Environment Failed"
<benji> bcsaller: let me try again on trunk, I may have broken my branch
<bcsaller> testing locally, I didn't expect that to fail
<abentley> jcsackett: I'm afraid bac landed changes that conflict with yours.  However, once you've fixed the conflicts, I believe jenkins will land your changes.
<bcsaller> benji: that did work for me here
<benji> bcsaller: it failed on trunk for me too; this is by dragging and dropping the file; are you using some other mechanism to load the file?
<Makyo> jujugui call in 10
<bcsaller> DnD
<benji> hmm
<benji> bcsaller: oh!  I figured it out: I had the Charmworld API v3 flag enabled, which apparently causes the failure when importing.  I'll look at figuring out why that breaks import.
<bcsaller> benji: ahh, I bet its the change to charm revision searching
<benji> I'll keep that in mind.
<bac> abentley: does your lander run 'make lint' on charmworld?
<abentley> bac: No.
<jcsackett> abentley: thanks!
<gary_poster> jujugui call in 2
<gary_poster> bug 
<gary_poster> bug 1220909
<_mup_> Bug #1220909: Searching for "rabbit" doesn't return the rabbitmq charm <charmworld:Triaged> <https://launchpad.net/bugs/1220909>
<rick_h_> luca__: still around?
<luca__> rick_h_: for another 15 mins or so :)
<rick_h_> luca__: so I'm working on updating the bundle token to be 'correctish' and I'm looking over assets/etc
<luca__> rick_h_: ok
<rick_h_> luca__: the one thing I notice is that we have several sizes of the old charm token and curious if there's thought on that on the bundle side?
<rick_h_> in particular for the autocomplete/quicksearch results display?
<rick_h_> right now I'd imagine they all get the same generic icon + the name of the bundle?
<luca__> rick_h_: thats right
<rick_h_> luca__: the other thing I've not verified yet is 'related charms' ?
<luca__> rick_h_: they only show in the auto-complete if its recommended
<rick_h_> there's related bundles I'd assume, but not verified. They also just get the same generic image 
<luca__> rick_h_: related charms is "charms within this bundle"
<rick_h_> luca__: is that how we treat autcomplete currently? I thought we ditched the idea of search with recommended? /me dbl checks
<luca__> rick_h_: it's a list of the charms within the bundle, it includes summary of each service
<rick_h_> luca__: it seems odd that I can search for rack and get results but a rack bundle would not because it's not recommended?
<luca__> rick_h_: afaik the auto-complete only shows recommended charms
<rick_h_> luca__: ok, that's not true atm
<luca__> rick_h_: wait wait wait :)
<rick_h_> luca__: and since we've been heading down the path of autcomplete being more of a 'quick search' I don't think it should be true
<luca__> rick_h_: the auto-complete is the drop down part which shows results as you type
<rick_h_> luca__: right
<Makyo> hatch, https://codereview.appspot.com/13986043
<rick_h_> http://comingsoon.jujucharms.com/
<rick_h_> enter 'rack'
<hatch> Makyo: thanks will take a look shortly
<rick_h_> and see three options, none of which are reviewed charms
<Makyo> hatch, cool, thanks.
<rick_h_> luca__: ^^
<luca__> rick_h_: it should only recommended stuffâ¦I thought it was only showing recommended stuff hehe
<rick_h_> luca__: now recommended charms are given a higher 'score' in autocomplete and get showed at the top of the list
<luca__> rick_h_: because the add to my canvas in auto-complete is missing
<rick_h_> luca__: but with the idea of it being 'quicksearch' vs 'autocomplete' does that idea still hold true?
<rick_h_> luca__: true, I need to get that in. I'll try to squeeze it in soon. I might be able to drive-by it. It should be a quick/easy update
<luca__> rick_h_: mostly, I can't remember the decision to why it's not just recommended, I think it's like that because we couldn't implement the rest of the UX
 * bac lunches
<rick_h_> luca__: ok, so bundle tokens in the sidebar will be larger than charm tokens and show the icons below. They'll be a simple icon/name in autocomplete and be the generic icon for now.
<luca__> rick_h_: thats fine
<rick_h_> so really just the three sizes, sidebar, fullscreen (for now), and autocomplete
<luca__> rick_h_: ok
<luca__> rick_h_: do you need assets?
<rick_h_> luca__: no, I can use the bundle token svg. I think that's the only *asset* needed right now. 
<rick_h_> luca__: I'm also noticing the orange 'selected' is moved to the left?
<luca__> rick_h_:  ok
<luca__> rick_h_:  that is correct
<luca__> rick_h_: due to the orange triangle
<rick_h_> luca__: ok cool. I think I'm good for now. I'm sure something else will come up. 
<rick_h_> luca__: ah, that makes sense
<luca__> rick_h_: which you should be implementing soon :D
<rick_h_> luca__: glad to be back :P
<luca__> rick_h_: /nudge /nudge /wink /wink
<luca__> rick_h_: rofl welcome back, you was missed :D
<Makyo> bac, I...uh...had other problems with lightweight checkouts.  I may have been lying about what I found.
 * Makyo quietly rebuilds dev evn <.<  >.>
<bac> Makyo: ok.
<gary_poster> frankban, hey https://plus.google.com/hangouts/_/fcf9a8c4670d9c371763980ac16e8f3ba7de77b2
<gary_poster> oh frankban actually lets go to the meeting one
<gary_poster> the next one
<frankban> gary_poster: ok joining
<gary_poster> frankban, if not clear, https://plus.google.com/hangouts/_/4dc220a25e4e00a204f48f8e64644c392635a78d
<hatch> Makyo: much better :) just qa'ing
<hatch> bcsaller: so are you going to tackle the bundle details page or did you want me to take that branch back?
<bcsaller> hatch: Oh, feel free, I still have a little time on this one
<hatch> ok I'm going to move the visualization integration into a separate card
<bcsaller> hatch: there is a different card for that already
<hatch> oh ok
<hatch> refreshing
<Makyo> hatch, thanks! Big diff against trunk, re-qaing before I land.
<hatch> Makyo: oh ok yes plz do :)
<hatch> rick_h_: do you have a second to explain to me what's going on with this token? I'm trying to find what handles the click event? It doesn't appear to be the container or the token?
<rick_h_> hatch: sure thing
<rick_h_> bac: can you join us for a sec? https://plus.google.com/hangouts/_/59268b0ddde3ebb3799023f43c35e7d5d1a2f80b?hl=en
<gary_poster> Makyo, congrats on eagle landing :-)
<Makyo> gary_poster, haha, thanks :)  it'll be good to have in the GUI
<gary_poster> definitely!
<hatch> jujugui does anyone know what a bundle id is?
<hatch> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki says ~bac/wiki/3/wiki
<hatch> so does that mean there is no reference to the Ubuntu version?
<hatch> or that it's a bundle?
<gary_poster> hatch currently that would be jc:~bac/wiki/wiki IIRC.  Also, see this page:
<gary_poster> http://staging.jujucharms.com/~bac/bundle/wiki/wiki
<gary_poster> oh.  apparently it is jc:~bac/wiki/3/wiki  ?
<gary_poster> that's a bit odd
<gary_poster> since it is against charms
<rick_h_> gary_poster: yea, looking at the api to see what charmworld wants for an ID to be passed to locate a charm and get its details
<rick_h_> so /api/3/xxx/yyy/zzz
<hatch> yeah basically I need to know what the ID is so that I know how to parse it
<gary_poster> hatch do you have url for an api 3 search result?  that would probably tell us what we need to know
<gary_poster> oh there we go
<hatch> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki
<rick_h_> gary_poster: do they not have a series info on them?
<gary_poster> no rick_h_ there is only one series, bundle.  So here I have something for you
<rick_h_> gary_poster: yea, trying to figure out from the api docs http://charmworld.readthedocs.org/en/latest/api.html#terminology to actual calls how things map up to build urls
<gary_poster> this is the kind of result you get from a search: http://pastebin.ubuntu.com/6176395/
<gary_poster> e.g. you go to http://staging.jujucharms.com/api/3/search and search for "bac" (don't do this, it loads everything :-P)
<rick_h_> gary_poster: right, what's a 'basket' then? Just a grouping so I might have a bunch of bundles in my rharding basket?
<gary_poster> rick_h_, basket is deployer file
<gary_poster> rick_h_, deployer files can contain multiple bundles
<gary_poster> so they decided to call deployer files baskets
<rick_h_> so you might have multiple bundles in a single deployer file...ah that starts to fit
<rick_h_> ok, so the bundle details view might have multiple bundles in it?
<gary_poster> so if you look at ~bac/wiki/3/wiki
<rick_h_> or are we only working on one at a time?
<gary_poster> ~bac is the owner of course
<gary_poster> wiki is the basket
<gary_poster> sorry, the first one is.  3 is the basket revision
<rick_h_> gary_poster: right, ok. so we're dealing with one at a time. 
<gary_poster> and the second "wiki" is the bundle name
<gary_poster> yes
<hatch> so what should the url be then? on jujucharms.com ?
<hatch> jujucharms.com/bundle/~bac/wiki/3/wiki ?
<rick_h_> so to ID it we'd need to know it's a bundle, the basket, the owner, the revision, and the name of the bundle in the basket
<gary_poster> yeah
<gary_poster> rick_h_, both of these work:
<gary_poster> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/3/wiki
<gary_poster> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki
<gary_poster> so if you don't have revision you can get head
<rick_h_> gary_poster: right, because rev is HEAD
<gary_poster> yeah
<abentley> jcsackett: Looks like it landed fine, I'll update the revno now.
<jcsackett> abentley: yes; i'm sorry were you waiting for me to confirm?
<abentley> jcsackett: No, I was on lunch.
<jcsackett> abentley: well ok then. :-)
<rick_h_> gary_poster: can you join us then for a sec?
<rick_h_> hatch: has a valid question
<rick_h_> gary_poster: or not if you're busy :)
<hatch> rare...I know
<hatch> lol
<gary_poster> :-)
<rick_h_> or benji or bac if they're free. 
<gary_poster> what url rick_h_ 
<rick_h_> https://plus.google.com/hangouts/_/59268b0ddde3ebb3799023f43c35e7d5d1a2f80b?hl=en
<rick_h_> gary_poster: are all bundles required to have an owner? e.g. no ~charmers default? Or is that not true
<hatch> jujugui I've noticed that the failures for api restarting have lasted a very long time now, do we know if any changes were made to alter that code or is canonistack just being itself?
<Makyo> We could just use https://www.google.com/webdesigner/ for the GUI.
<hatch> google is making Dreamweaver, what? lol
<gary_poster> rick_h_, don't quite understand your question.  ~charmers may own a bundle.  The "promulgated" flag determines whether that bundle is the recommended one, as with charms
<gary_poster> hatch that looks like Canonistack to me :-(
<gary_poster> either that or juju
<gary_poster> but probably canonistack
<rick_h_> gary_poster: ok, so having a bundle without a ~owner is legit as it is in the case of a charm. 
<gary_poster> rick_h_, oh I see, yes.  promugated.
<gary_poster> l
<rick_h_> gary_poster: since bundles weren't in LP I wasn't sure how that worked out. If all bundle urls would requie an explicit ~owner
<gary_poster> rick_h_, bundles are in LP.  See "Branch" in http://staging.jujucharms.com/~bac/bundle/wiki/wiki for instance
<gary_poster> (links to https://code.launchpad.net/~bac/charms/bundles/wiki/bundle)
 * gary_poster needs to go to lunch :-)
 * gary_poster goes to lunch and a walk
<hatch> enjoy!
<abentley> bac, jcsackett: I believe Jenkins is fully restored now.  Please ping if you have any problems.
<bac> thanks abentley
<abentley> bac: np
<bac> rick_h_, hatch: have you seen https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit
<rick_h_> bac: no, good to know
<hatch> rick_h_: looks like they do want `bundle` in the url
<rick_h_> hatch: so they want it in the charmworld url, doesn't mean we need it in the gui url
<hatch> see Actual Example URLS
<rick_h_> hatch: so the browser Store object will need to build that correctly
<rick_h_> hatch: right, those are all charmworld urls
<rick_h_> hatch: staging/manage are charmworld
<hatch> no they are on jujucharms.com it says
<rick_h_> http://staging.jujucharms.com/ is not the gui
<hatch> ohh damn woops I totally didn't even click on that
<rick_h_> hatch: ah, I see that there's a GUI url there
<hatch> and yeah
<hatch> lol
<rick_h_> hatch: but I'm sure we can negotiate
<rick_h_> hatch: the smaller we can make it the better 
<hatch> my issue with these user readable urls is that they aren't really readable at all haha
<hatch> they might be 'pretty' but not really readable
<hatch> unless of course you know what you are looking for
<rick_h_> hatch: well, sharable, twitter, printable on flyer -able
<hatch> :)
<rick_h_> hatch: but yea, that's been the curse with what we HAVE to have vs what is really human readable
<hatch> rick_h_: see (where your cursor is) the valid urls
<hatch> (or so I am assuming)
<hatch> I don't know if we can do all of those without /bundle/
<rick_h_> hatch: just closed it. 
<hatch> https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit#
<rick_h_> hatch: calling
<rick_h_> bac benji gary_poster so there's a bundle series but it's not part of the id?
<benji> rick_h_: are you asking if that is the case or why that is the case?
<rick_h_> benji: I guess both. Is this true and intentionally true
<bac> the 'series' is part of the id.  it is just always 'bundle'
<benji> yes to both
<benji> since it will never change, making it part of the ID didn't make much sense
<rick_h_> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki series is precise?
<bac> ah, i was referring to the url
<rick_h_> so can I get a precise and a saucy version of the bundle for bac's wiki?
<rick_h_> it would seem no since series isn't part of the url/id?
<rick_h_> unlike charms
<benji> right, bundles aren't segmented into series
<hatch> but they have a series property?
<hatch> so you need a new deployer or bundle for different serieses?
<benji> I don't know why they would have a series property.  I can't see what it would mean.
<hatch> http://staging.jujucharms.com/api/3/bundle/~bac/wiki/wiki
<rick_h_> benji: that's our confusion
<hatch> it's there?
<benji> hatch: define "it" and "there"
<hatch> series
<hatch> in the result of the api call
<benji> hatch: yep, it's returned from the URL you gave
<hatch> benji: so bundles DO have a series, but the only way for a user to determine that is not by the ID but by inspecting its details
<hatch> an author will need to make different bundles for different series
<rick_h_> benji: yea, but you said it makes no sense for bundles to have a revision so it confused us that the api call provided one, yet it's not part of the id to have multiple revisions of the same bundle
<benji> I'd say that bundles having a series is a bug.
<rick_h_> benji: ok, makes sense now. Thanks for the clear up
<hatch> benji: ok so would the author make a new deployer or new bundles for series?
<hatch> precise-wordpress, saucy-wordpress etc etc
<bcsaller> are we sure bundles are limited to a series?
<bcsaller> I'm not
<hatch> well the parts in it are
<hatch> so if you're using 'precise' charms the bundle only works on precise
<hatch> well
<benji> hatch: it would depend on their goal; I wouldn't be surprised if some name them according to series
<bcsaller> hatch: a bundle is more than one charm, they might not all be the same series, maybe LTS with the DB but new series for some new appserver
<benji> that makes me wonder if juju supports mixed series environments
<hatch> bcsaller: right - but is that supported?
<bcsaller> I thought it did
<bcsaller> we can check on another channel, but we did used to be able to do this
<hatch> benji: is the charm api going to match the bundle one at some point? re the revision being /3/ instead of -3 ?
<rick_h_> bcsaller: yea, I don't think anything stops it. It's just confusing and as benji says can be considered a bug
<rick_h_> bcsaller: the charms define what series they are in their definitinos and can be corss series, though I'm not sure how juju would do with bringing up the 'right' series  images for each charm
<benji> hatch: I'm not aware of any plans to do that.  I'm also not aware of the difference being intentional, but I would suspect it was.  
<bcsaller> bundles can include a default series to resolve charms from, but they can include explicit charm urls as well 
<rick_h_> bcsaller: but urls incldue the series. It's never optional
<benji> ah, so "series" is really "default charm series"
<bcsaller> rick_h_: it used to be, but maybe not anymore 
<bcsaller> rick_h_: and what if they say -HEAD
<bcsaller> I guess that would still have series though
<hatch> then you're cray-cray
<hatch> but yeah :)
<bcsaller> really? package.json says things like that 
<rick_h_> bcsaller: so revision is different. We have allowed that to be ignored, -HEAD, or an int
<hatch> bcsaller: I know - and I wish that they would delete every module without locked down deps from npm :)
<bcsaller> hatch: and maybe for packages that makes sense, but charms are configuration and runtime flow around packages and usually not a specific version but any in that series
<bcsaller> and so the newest is usually expected to be the best one
<hatch> well that's the same everywhere but that's not always the case
<hatch> buut anyways - as long as Juju can deploy each charm to the proper series that's alright
<hatch> not sure how it'll know which one to deploy on the providers
<hatch> but I'm sure there is an answer for that
<gary_poster> the charm is for a series
<hatch> gary_poster: right, but if a bundle contains charms for multiple series does Juju handle deploying it to the proper series?
<gary_poster> hatch, yes.
<hatch> that's pretty coooooool
<gary_poster> :-)
<BradCrittenden> benji: for a bundle to be 'featured' it must first be promulgated, right?
<benji> bac: that is my understanding
<bac> benji: and what's the process for marking it promulgated?
<benji> bac: If I recall correctly, there is none. :/
<bac> \o/
<bac> well, my work here is done
<bac> benji: ok, so i'll write a killer test and we'll just hope it works in real life
<benji> heh
<hatch> rick_h_: do you remember where the app makes the XHR request to get the charm data?
<rick_h_> hatch: that's all in the Store object. 
<rick_h_> hatch: the Store is theonly thing allowed to make calls to charmworld
<hatch> ok because this is what I have right now https://manage.jujucharms.com/api/3/charm/bundle/~bac/wiki/3/wiki
<hatch> so I need to make the 'charm' part optional
<rick_h_> hatch: so api3 should already provide the calls
<rick_h_> hatch: just a matter of getting it the data
<rick_h_> hatch: actually, don't see bundle calls, so maybe it needs a new call for bundle vs charm()
<gary_poster> benji, bac, to make a charm promulgated, you log onto charm world as a charmer and you have the ability to bless a charm.  I would guess it is the same for bundles.  There is a UX for that now for charms.
<rick_h_> gary_poster: that's for 'featured' but not promulgated. I thought that was part of the LP/branch process?
<gary_poster> I don't know whether it exists for bundles. Do you all?
<hatch> who chose the word promulgated? lol
<gary_poster> rick_h_, I may be confused then.  I don't know what promulgated means then.  bac, benji, I think this is something to clarify with Rick and/or Orange squad.
<rick_h_> gary_poster: yea, abentley do you know what the rules are for promulgated and bundles?
<rick_h_> gary_poster: originally, any charm owned by ~charmers was promulgated
<rick_h_> and the UI is to feature things which show up in the featured section on the front page
<rick_h_> then the promulgation rules changed so that the juju gui charm could be 'reviewed' even though ~charmers didn't own it
<rick_h_> I'm not sure how that was implemented in the end
<gary_poster> rick_h_, oh and by featured you mean added to the list of editorially gardened featured charms
<abentley> rick_h_: I believe the charms in any basket that's linked to a series are considered promulgated.
<rick_h_> gary_poster: correct
<abentley> rick_h_: s/charms/bundles/
<rick_h_> gary_poster: benji bac ^
<gary_poster> abentley, rick_h_ how do you link something to a series?
<gary_poster> (in this case the bundles series?)
<rick_h_> gary_poster: well that gets interesting when bundles don't have a series. Except benji said they did have a series and it was always bundle
<gary_poster> right, they do, they have a single static series
<rick_h_> so that definition/workings might need some shake down
<abentley> gary_poster: I don't know.  sinzui? ^^
<rick_h_> might need two? bundle/promulgated?
<rick_h_> no sinzui here atm
<abentley> rick_h_: No, there's a different between having a series and being linked to it.
<rick_h_> I've ping'd sinzui to jump in here for a sec if he's got a minute
<rick_h_> abentley: gotcha
<abentley> rick_h_: All sourcepackage branches *have* a series, but only one branch is linked to it, typically ~charmers/*/trunk
<rick_h_> thanks sinzui 
<rick_h_> sinzui: so the question came up about how to mark a bundle as promulgated
<sinzui> You don't
<rick_h_> sinzui: and abentley mentioned that linking a branch to a series does it currently, and we were wondering how that was done/worked?
<rick_h_> currently meaning for charms
<abentley> rick_h_: Oh, for charms they use a script.
<sinzui> Members of ~charmers can run charm-promulgate to that links a branch to series package in Lp
<sinzui> only they can run it.
<sinzui> They can also do in the Lp UI, though I doubt they know that
<rick_h_> sinzui: ah ok. And is/was there a plan for bundles and this? 
<sinzui> yes, though I have not read the script to know if it does something charmy
<gary_poster> sinzui, we could ask them to do it via LP for bundles, though, it sounds like?
<rick_h_> sinzui: cool, is the script in charmworld src to look at or just handed to someone? e.g. where can we find it? 
<sinzui> doesn't look like it enforces trunk
<bac> rick_h_: not in charmworld afaict
<sinzui> rick_h_, gary_poster, bac: I think they run charm-tools promulgate  -owner-branch lp:~user/charms/bundles/bundle-package/bundle --series bundles
<rick_h_> sinzui: ah, part of charm tools. Very cool then. 
<gary_poster> cool, thanks sinzui!
<sinzui> If it does not work, I think we can fix the script in a matter of minutes!
<bac> thanks sinzui
<hatch>  I'm looking for ideas as to what to call a bundle and a charm because 'charmview' is no longer a good name
<hatch> chundle? :D
<gary_poster> hatch, DeployableView
<gary_poster> DeploymentView
<bcsaller> BundleView?
<gary_poster> It's supposed to handle both IIUC
<gary_poster> charms and bundles
<hatch> yeah it looks like they might share a lot of the same code
<hatch> I'll know once I'm done to be sure
<gary_poster> BundleOrCharmView might actually not be as bad as it seems :-)
<hatch> haha
<hatch> new BundleOrCharmView(yourGuessIsAsGoodAsMine); //mohohahahaha
<bcsaller> lol
<bcsaller> CharmworldEntityView 
<gary_poster> heh
<gary_poster> (to the mohahaha etc.)
<gary_poster> yeah bcsaller's is nice.  I like the stupid simplicity of BundleOrCharmView though :-)
<hatch> yeah but everythign else we do is with big fancy words, like promulgated
<bcsaller> or Stack ;)
<hatch> so we can't just go lame on this one
<hatch> hahaha
<hatch> stack
<hatch> lol
<bcsaller> BundleOrCharmOrStackView ;)
<hatch> lol
<hatch> CharmworldEntityView sounds good, so does DeployableVIew though
<hatch> well I guess I'll see if they do share enough code for it to matter
<hatch> we don't need fullscreen views for this bundle view do we?
<gary_poster> why wouldn't we hatch?
<hatch> oh I thought it was going away
<hatch> or not soon enough I guess
<gary_poster> hatch yeah it is, but...exactly
 * gary_poster updates hoping it doesn't kill his system, prior to restarting
<gary_poster> If I never come back, I left a GUI charm branch for Antonio on Launchpad...
<gary_poster> ...Jeff can have my horse...
<hatch> yusssssss
<gary_poster> ...and I leave my six-shooter to Benji...
<bac> gary_poster: it looks like the webops have their hands full today and won't get to our charmworld RT.  benji has agreed to shepherd it tomorrow.
<gary_poster> ok cool thanks bac.  Have a fantastic vacation!
<bac> gary_poster: not done yet
<bac> :)
<bac> but thanks
<gary_poster> bac, oh, ok, I take it back then ;-)
<bac> well, just premature
<gary_poster> :-)
<hatch> it's been put on a 2h setTimeout
<hatch> ok so now when you visit localhost:8888/bundle/~bac/wiki/3/wiki/:flags:/charmworldv3/ you get a details page
<hatch> as much crap as I give rick_h_ for the browser not making any sense......well no, it still doesn't make any sense
<hatch> EHHHH seee what I did there? :P
<hatch> kik
<hatch> lol
<hatch> no...nothing? well I thought it was funny :)
<gary_poster> :-P
 * gary_poster restarts
<hatch> man it's frustrating that bzr doesn't deal with renaming files well
<bac> hatch: huh?
<hatch> bac: it shows the whole file as a diff instead of a rename
<hatch> so you lose all of your 'real' diff
<bac> hatch: i think you've done something wrong.  did you use 'bzr mv'?
<hatch> bac: no I just renamed the file
<bac> even that should work.  put it back and then use 'bzr mv' to rename it.
<hatch> ok will try that
<bac> hatch: i'm not trying to convert you but generally when you find bzr doing something incredibly stupid then you may have done something where there is a different way that gives expected results.
<gary_poster> +1 on all of that fwiw
<hatch> re-proposing will see if it works this time
<hatch> thanks
<hatch> and yeah - you're probably right :)
<hatch> the issue is that when you have a git problem, a quick google search solves everything, there just aren't that many q&a's for bzr I guess
<hatch> most just point to the docs which don't help if you don't know what's happening :)
<hatch> and actually I've seen this rename issue from others so I just assumed that's how it was :D
<bac> benji or jujugui: one review of  https://codereview.appspot.com/14151043 please?
<hatch> sure
 * bac walks dog. will be back later.
 * benji is too late.
<hatch> bac: done
<hatch> bac: doesn't look like that technique worked either https://codereview.appspot.com/14153043 diff is still the whole file
<hatch> oh well I'll just update the description to point to where the changes were
<bac> hatch: what does bzr diff say on your command line?
<hatch> bac: `bzr diff --old ../../trunk | vim - ` shows me the same as what codereview says
<hatch> so it must just deal with mv's as delete/create
<hatch> instead of rename
<bac> Makefile => makefile
<bac> renamed:
<bac>   Makefile => makefile
<bac> === renamed file 'Makefile' => 'makefile'
<bac> er, that's not right
<hatch> and the diff shows nothing?
<bac> http://paste.ubuntu.com/6177338/
<hatch> hmm that's odd
<hatch> I did the exact same thing
<hatch> I'll try reverting it and re-applying
<hatch> bzr mv charm.js charmworld.js
<hatch> bac:  odly enough https://gist.github.com/hatched/1ed747f2c33ba1a629ba
<hatch> the output is very similar to what you said
<hatch> s/said/had
<hatch> but the diff still shows a full add/delete
<gary_poster> that's just how it represents it in the diff, IIRC
<gary_poster> I'm running away.  Juju local conquered me again. :-/
<gary_poster> ttyl
<hatch> gary_poster: ohhh ok I gotcha
<hatch> cya
<hatch> wow they have some big hardware outside digging up the road, shaking the whole house haha
<hatch> rick_h_: hey if you pop your head in here could you take a look at https://codereview.appspot.com/14153043 and let me know if this is on the right track for your impl
<rick_h_> hatch: dinner and such atm but will peek later tonight.
<hatch> yeah no rush
<huwshimi> Morning
<hatch> mornin huwshimi
<hatch> what's Tuesday like?
<huwshimi> hatch: Rainy
<hatch> yeah that's what I'm hearing :/
#juju-gui 2013-10-01
<bac> hatch: you still around?
<bac> or bcsaller?
<bcsaller> I am 
<bcsaller> bac: whats up?
<bac> bcsaller: hey i've got a problem where 'make check' when run by lbox fails 90% of the time.  makes it really hard to land branches
<bac> bcsaller: that's the hell i'm stuck in now.  would you mind landing a branch for me?
<bac> bcsaller: it is bzr+ssh://bazaar.launchpad.net/~bac/juju-gui/featured
<bcsaller> yeah, you have the LGTM's and all?
<bac> bcsaller: yep, it's ready to go
<bcsaller> I'll give it a go
<bac> between gjslint dumping core and this problem i've been poking at it for quite a while now
<bac> bcsaller: thanks a bunch
<bcsaller> The random port for make test-server sometimes means that it can timeout while loading the YUI code in debug mode, I've seen that once or twice, but mostly it works from the CLI which didn't interfere with lbox for me
<bcsaller> trying make check now
<bcsaller> bac: landed it
<bac> thanks ben
<bac> with that i'm outta here
 * bac -> ich bin ein berliner
<rick_h_> hatch: I'm going to have to introduce you to bzr mv
<rick_h_> hatch: notes sent
<rick_h_> hatch: looking good, lots of notpicking and a couple of bigger decisions to debate tomorrow
<davecheney> hello, can anyone help me debug a gui problem ?
<davecheney> http://paste.ubuntu.com/6177888/
<davecheney> run this script to create an environment
<davecheney> then, using the gui, try to create a relation between p1 and w1
<davecheney> then p1 and w2
<rick_h_> davecheney: will give it a shot here in a sec
<davecheney> thanks
<davecheney> rick_h_: if you already have an enviroment running
<rick_h_> davecheney: all good, will try with lxc 
<davecheney> the issue is you cannot create two relatoins from p1 to anything
<davecheney> afte the first one
<davecheney> all the remaining services are grey and will not accept a relation from p1
<rick_h_> davecheney: so yea, I can confirm it but when I force the second relation via the cli it's a different type, website vs reverserproxy?
<davecheney> that is just a label
<davecheney> if you do
<davecheney> add-relation w1 p1
<rick_h_> well those are two different interfaces that haproxy supports
<davecheney> or p1 w1
<davecheney> it's just a label
<davecheney> defined by the order of the relation
<davecheney> they are both the http interface
<rick_h_> davecheney: ah, ok cool
<davecheney> so if you do p1 w1
<davecheney> it's called reverse proxy
<davecheney> if you do w1 p1 it's called website
<davecheney> it would be good if the gui would say
<davecheney> label:interface
<davecheney> rather than just label
<davecheney> for example when relating mediawiki
<bcsaller> trunk should do that actually
<davecheney> you have two mysel interfaces
<rick_h_> davecheney: ok, do you mind filing a bug on it then? I'm guessing we don't have good logic for multiple targets for an interfaces, but then again mysql works fine with two services on one interface. 
<davecheney> db:mysql
<davecheney> db_slave:mysql
<davecheney> rick_h_: what title should I use for the bug ?
<rick_h_> davecheney: so I'm testing the apache2 charm and the wordpress instances and apache2 provides three relation types
<rick_h_> once i use one, the next time I try to relate, only two optinos are available. 
<rick_h_> I'm not an expert on juju relations, should it be completely possible to reuse the same relation type against many services?
<rick_h_> davecheney: so the bug I'd go with "unable to relate multiple services with a single service on the same relation
<rick_h_> or does that not make sense to other heads?
<rick_h_> maybe with/to
<davecheney> rick_h_: sounds like it
<davecheney> afaik there is no limit on the number of peers of you can relate a service too
<davecheney> lemmie ask hazmat 
<davecheney> hazmat: is there a limit to the number of relations to a service ?
<rick_h_> thanks davecheney, let me know the bug # and I'll add it to the kanban under bugs to peek before I head to bed tonight
<hazmat> davecheney, no
<hazmat> davecheney, there is a notion of such in the charm metadata though
<hazmat> its not acted upon
<hazmat> also the gui solves once for requires
<hazmat> effectively from a semantic perspective only provides  are unlimited as a relation endpoint
<hazmat> peers are self established and effectively have a rel max count of 1
<hazmat> s/self/auto
<hazmat> they shouldn't appear in the gui as a valid rel target, but some display nesc for peer rel errors
<davecheney> hazmat: i don't understand anything you just said
<davecheney> can haproxy have more than one service related to it ?
<hazmat> semantically no
<hazmat> it requires http
<davecheney> hazmat: i can do it with the cli
<davecheney> and when I try the same, add-relation w2 p1 action in the gui
<davecheney> from eithre p1 to w2
<davecheney> or w2 to p1, it does not work, all the other services are greyed out
<hazmat> hmm.. yeah.. it does look like it works for haproxy. for most services it doesn't
<davecheney> hazmat: where is the bug ?
<hazmat> ie. you can't relate wordpress to multiple mysql for examples logically
<davecheney> the gui
<davecheney> or the charm ?
<hazmat> davecheney, the charm actually supports this, i'm talking about the way the gui auto solves the valid relation endpoints for drag targets (by ghosting non valid targets)
<hazmat> their's some assumptions made beyond the base model
<davecheney> hazmat: ok, rick_h_ , thanks will log a bug
<hazmat> hence the phrase semantically
<hazmat> because otherwise you get errors for the vast majority of requires dependencies uses
<hazmat> which don't support multiples here
<davecheney> hazmat: rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1233462
<_mup_> Bug #1233462: gui does not allow multiple relations between wordpress and ha proxy <juju-gui:New> <https://launchpad.net/bugs/1233462>
<davecheney> hazmat: but it works with mysql and wordpress
<hazmat> davecheney, its only supported by the charm with explicit service config
<davecheney> what is the difference ?
<hazmat> davecheney, how
<hazmat> davecheney, wordpress can only use one mysql db
<hazmat> not multiples
<davecheney> hazmat: ok, so is this a charm bug or a gui bug ?
<hazmat> it only works for haproxy charm, because its specifically implemented via charm config
<hazmat> davecheney, neither
<davecheney> what is explicit service config ?
<hazmat> charm config
<hazmat> you have to configure the haproxy charm for this to work, relating to multiple upstream services
<hazmat> otherwise its just broken
<davecheney> hazmat: lets not get bogged down with what haproxy does when it gets that second relation
<rick_h_> you know what, now that you say that this has come up before
<davecheney> my issue is, i can do something on the cli that I can't do in the gui
<hazmat> davecheney, why not? its perfectly relevant to the gui behavior here
<hazmat> which is don't let me casually get a bunch of broken services
<hazmat> by accidental relation creation
<davecheney> hazmat: ok, please answer this
<davecheney> how does the gui know ?
<davecheney> where is the metadata that explains that ha proxy can only have one relation on the website:http relation ?
<hazmat> davecheney, fufilled requirements ('requires') are considered satisified if they have an established relation
<davecheney> sorry, reverseproxy:http relation
<davecheney> hazmat: please don't talk charm speak to me
<davecheney> i don't understand it
<davecheney> speak plainly and use the words I use
<davecheney> which are add-relatoin, gui and cli
<hazmat> relation endpoints, are one of three types .. peer, client/require, server/provider
<hazmat> peers are auto established on deploy, no need for add-relation
<davecheney> ok
<hazmat> client <-> server ... the gui will only do a client as a valid add-relation target, if doesn't have a another client-server relation
<hazmat> servers can do unlimited clients
<davecheney> what
<davecheney> stop
<davecheney> "he gui will only do a client as a valid add-relation target"
<davecheney> please explains this bit
<davecheney> i don't understand
 * hazmat sighs
<hazmat> g+?
<hazmat> davecheney, https://plus.google.com/hangouts/_/2e5dc0e9a9e103bfccc16a95c045b1a2ce449249?hl=en
<rick_h_> hazmat: mind if I jump in to catch up?
<hazmat> rick_h_, sure
<davecheney> sorry, i don't ahve my teleconference kit with me
<davecheney> i'm at a coworking space
<davecheney> we can do this another time
<davecheney> all i'm looking for is the magic bit of configuation in the charm that says 'i can have multiple relations'
<davecheney> which i'm guessing is provides an requires
<davecheney> requires is at most one
<davecheney> provies is many
<hazmat> nutshell yes
<hazmat> davecheney, put another way the only charm that supports multiple requires relations that doesn't result in broken usage i  know of is haproxy
<davecheney> provides:
<davecheney>   website:
<davecheney>     interface: http
<davecheney> ^ from ha proxy 
<davecheney> ahh, but wordpress doens't have a requires
<hazmat> yes.. both haproxy and wordpress provide http.. but haproxy has to require an upstream http.
<hazmat> and even then haproxy requires explicit service configuration to be set for this usage to work
<davecheney> provides: - The deployed service unit must have the given relations established with another service unit whose charm requires them for the service to work properly. See below for how to define a relation.
<davecheney> requires: - The deployed service unit must have the given relations established with another service unit whose charm provides them for the service to work properly. See below for how to define a relation.
<davecheney> from our docs
<davecheney> brilliant ...
<davecheney> hazmat: looking at the mysql charm
<davecheney> it provides db:mysql to many clients
<davecheney> and requires salve:mysql-oneway-replicatoin to many clients
<davecheney> there is a limit: n field in the docs
<davecheney> but it is not implemented
<hazmat> requires: to one client
<hazmat> er.. requires: to one provider
<davecheney> hazmat: so you are saying i can only have one master and one slave ?
<hazmat> no.. you can have several slaves
<hazmat> you said it requires: x... 
<davecheney> so i can do juju deploy -n2 mysql slave
<hazmat> all requires: are in common usage to one relation (which is implemented and constrained as such by the gui) 
<davecheney> the juju add-relation m1:slave slave:master
<davecheney> sorry, terrible names ?
<hazmat> number of units has nothing to do with relations
<hazmat> number of services does
<davecheney> aaaaaaahhhhhhhhhhhhhhhh
<davecheney> now I understand
<davecheney> so i cannot do
<davecheney> juju deploy mysql s1 
<davecheney> juju deploy mysql s2
<davecheney> juju add-relation m1:slave s1
<davecheney> juju add-relation m1:slave s2
<davecheney> because that is what I *think* is happening with the haproxy example
<hazmat> not quite
<hazmat> juju add-relation m1:master s1:slave
<hazmat> juju add-relation m1:master s2:slave
<hazmat> the haproxy to not result in a something broken does
<davecheney> rick_h_: that is the bug
<davecheney> the name of the relation shuld be reverseproxy
<davecheney> not website
<hazmat> davecheney, that's a judgement call
<hazmat> davecheney, we basically color / label the relations by the name of provider afaicr
<hazmat> in the gui
<hazmat> or is it the other way around.. don't remember.. i tried both ways.. one worked better for the majority
<davecheney> right
<davecheney> so it's wordpress, website:http <> haproxy reverseproxy:http
<hatch> oh good you guys are discussing that bug
 * hatch reads the backlog
<hatch> I seem to remember this exact issue being brought up by someone else
<hatch> I wonder if this can be better documented/illustrated somewhere
<davecheney> hazmat: as I read it, wordpress provides website:http
<davecheney> which means many services may require it
<davecheney> is that correct ?
<davecheney> hazmat: the short version is
<davecheney> haproxy can only proxy one service
<davecheney> the gui is doing the right thing
<davecheney> the client is doing the wrong thing
<hatch> I hope that's right, I spent a long time on those darn endpoint calculations :D
<hatch> (in the gui)
<hatch> unless of course that's not the case, then it was someone else :P
<davecheney> LP1233462
<davecheney> #1233462
<_mup_> Bug #1233462: gui does not allow multiple relations between wordpress and ha proxy <juju-gui:New> <https://launchpad.net/bugs/1233462>
<hatch> davecheney: not sure if you saw, but all of your previous bugs have been fixed and committed waiting for release
<davecheney> hatch: nice
<davecheney> thanks
<davecheney> i look forward to consuming them
<hatch> davecheney: ok I'm not the utmost expert in this field but as per your bug I would bet that the GUI is acting correctly
<hatch> unless you have done some magic in the hook for the requires
<hatch> so maybe the CLI allows you to do it because you 'might' want to do it??
<davecheney> hatch: the gui only consumes metadata.yaml, right ?
<hatch> the GUI gets it's metadata from charmworld
<hatch> 'formatted' metadata
<davecheney> hatch: my point is, nobody reads the hooks
<davecheney> they are opaque
<hatch> agreed
<hatch> thenagain noone reads the source of any module they include into their system :D
<davecheney> hatch: when I say noone, i mean the gui, the cli, etc
<davecheney> their contents do not influcnce the gui endpoint calculations
<hatch> correct
<hatch> there would be no way they could
<davecheney> 12:28 < hatch> unless you have done some magic in the hook for the requires
<davecheney> ^ so this isn't possible
<hatch> well you can write whatever you want in your hooks - so that might be why the CLI allows it
<davecheney> hatch: in that case, the gui shuld allow this as well
<davecheney> which sounds wrong
<hatch> hmm
<hatch> yeah I can't really disagree with that
<hatch> guess that's not really up to me which one is doing it wrong :)
<hatch> but looking at how, for example mysql has it's relations set up, I would hazard a guess that you are only ever supposed to have a single require per endpoint
<gary_poster> The email! It doesn't stop! <whimpers>
<rick_h_> gary_poster: we need an email protection program that mirrors the witness protection program
<gary_poster> rick_h_, lol sounds good
<rick_h_> you get sent away and you can't tell anyone where you went
<gary_poster> as long as you don't have to deal with the subsequent fallout, +1 :-)
<TheMue> gary_poster: i've commented in https://bugs.launchpad.net/juju-core/+bug/1224568 what's now reported in case of a hook error
<_mup_> Bug #1224568: Improve hook error reporting <juju-core:In Progress by themue> <https://launchpad.net/bugs/1224568>
<TheMue> gary_poster: could you check if this is ok for you?
<gary_poster> TheMue, awesome, thanks, yes!  looking
<gary_poster> TheMue, could you include a concrete example there or in a pastebin?
<gary_poster> TheMue, fwiw, it sounds perfect so far. :-)
<TheMue> gary_poster: ok, will add it
<gary_poster> thank yoU
<rick_h_> luca__: for these images in the bundle token, are they centered, left align, right align? Say a bundle has 3 tokens, where do we want them?
<hatch_> all-over-the-place!
<TheMue> gary_poster: done
<gary_poster> TheMue, ack and thanks!  on call, will review after call
<hatch_> the power went out here last night - I remember when everything wasn't battery powered and that mattered :D
<rick_h_> heh
<rick_h_> yea, it's kind of cool how if you UPS up the internet gear you can keep going without power for a while
<hatch> we are very close to the local switch, so I'm goign to assume that if we get a 'real' outage we would also lose internet
<hatch> but I have no idea what's inside those big green boxes
<hatch> :)
<hatch> so...it's been a couple days since the finally of breaking bad...I hope people can stop talking about it now
<hatch> :P
<rick_h_> benji: got a sec to chat charm id in the bundle api response?
<benji> rick_h_: sure
<hatch> rick_h_: did you get a chance to read my responses to your comments?
<rick_h_> hatch: little bit. I basically read "we'll talk tomorrow" and left it at that :)
<hatch> haha ok cool, I'm trying to find out if there are icons for bundles
<hatch> it doesn't look like it
<hatch> the docs mention a 'has_icon' property but that's not retured
<rick_h_> hatch: yea, sec otp
<rick_h_> hatch: ok, got a sec if you want to chat then?
<hatch> calling
<rick_h_> benji: so I'm looking at that deployer file and I see that in the services list the key is db, and there's a 'charm' attribute in there that says mysql
<rick_h_> benji: the rest don't have a charm name, but the key looks like the name
<rick_h_> benji: is there any rule of thumb on this atm?
<benji> rick_h_: I'm 80% sure that the key is the service name, not the charm name (e.g., "intranet" not "apache2")
<rick_h_> benji: ok, so I should look to be adding a firm name attribute for our use then as it's a bit inconsistent in the deployer format of the api call
<benji> rick_h_: +1
<benji> rick_h_: I'm begining to think that the GUI-needed details should not be superimposed on the deployer data, but "beside" or "above" it in the data layout
<benji> that way if an attribute is added to the deployer data we don't have to worry about key collisions
<hatch_> so remember when I said a 'real' poweroutage
<hatch_> lol
<hatch_> ka-boooooom goes the transformer
<rick_h_> benji: true, we used the idea of 'metadata' in the other api calls for things that might need to expand/be additional info. Maybe that idea makes sense here
<rick_h_> benji: though that won't work with the current deployer stuff since it would nest the deployer info one level down into the object. Maybe a reserved 'metadata' keyword the deployer can promise to not use? Single key safety?
<rick_h_> this of course assumes that the deployer ignores things it doesn't care about which I've not verified
<benji> rick_h_: I think I'm -0 on a reserved keyword (for two main reasons: 1) from an information architecture view point it doesn't sit right, and 2) coordinating with other people is hard/irritating ;)
<rick_h_> benji: yea, but then how were you thinking of making it 'above/below'?
<rick_h_> benji: do you mean on the api call itself? I think we were in agreement for a api/3/bundle/~bac/wiki/3/wiki/details new call?
<benji> for the search results use, its easy
<benji> right for /detais we just either make a top-level object with two keys ("bundle" and "charm_details" perhaps)
<rick_h_> gotcha, yea. So in that new call I'd probably do keys like 'deployer' 'metadata'
<rick_h_> and anything in deployer is the same format you'd expect, and the metadata is the consistant "extra" we've had in other calls
<rick_h_> the name kind of sucks in this case, but I'd rather keep that key consistant with the rest of the api
<rick_h_> http://staging.jujucharms.com/api/2/charm/precise/apache2-2 like here where the doctype was part of metadata
 * rick_h_ thought we used it elsewhere as well...
<benji> rick_h_: yeah, I don't really like "metadata" in isolation there, but the consistency argument makes sense
<rick_h_> benji: right
<rick_h_> frankban: ping, got a sec?
<frankban> rick_h_: sure
<rick_h_> frankban: so, I think your fix is ok. It does the job, but it gets around the issue vs fixing the issue it appears
<rick_h_> frankban: so when I test trunk, I minimize, reopen, the details are there but then get blanked
<rick_h_> frankban: as if something stepped in and deleted it. This is very visible in IE because of the sloweless of it
<frankban> rick_h_: yes, the sidebar.render() makes them disappear
<rick_h_> frankban: your fix re-renders it, which seems pretty smooth in chrome (it deletes and rerenders quickly) but then in IE it's really noticable that it was there and then gone and then back again
<rick_h_> frankban: so I'm wondering if the "best" fix isn't to try to get at the deletion vs rerendering?
<frankban> rick_h_: it depends: I don't know why we are re-rendering the sidebar, and if the reason also applies to the details
<rick_h_> frankban: k, looking through the code now. I know there was a bug around something there. Trying to recall. 
<frankban> rick_h_: thanks
<rick_h_> frankban: https://code.launchpad.net/~rharding/juju-gui/more-state-issues/+merge/182459 is the branch that did it. It was cleanup related. A couple of bugs are tied to it
 * gary_poster goes for a quick walk.  back in time for call.
<rick_h_> frankban: the second to last item in the MP description fit in there. We forced re-render because of an odd chain of paths where there's no ._sidebar instance but the viewmode didn't change. I'm trying to recall the path that hit that. 
<rick_h_> frankban: hangout?
<frankban> rick_h_: sure
<rick_h_> frankban: https://plus.google.com/hangouts/_/c28ca959a840aa4051c5bdcd11f691bfe11d92c7?hl=en 
<Makyo> jujugui call in 10
<luca__> gary_poster: I'll get back to you tomorrow on the build relation thing, I want to think it over a bit
<hatch> Makyo: the new Krewella cd 'Get Wet' is out, not sure if you're a fan? https://itunes.apple.com/ca/album/get-wet/id689472430
<luca__> gary_poster: the solution we have in the pipe line is a button that appears on hover over the top of the service block, but the service block design has not be solved.
<Makyo> hatch, not heard of them, but will take a look :)  While we're at it. Chibitech finally released an album instead of singles, if you're into chip stuff: http://chibitech.bandcamp.com/album/moenes-vol-1-the-idol-composers-groove /cc jcsackett 
<hatch> will have to take a look after the call
<Makyo> Ofc
<Makyo> jujugui call in 2 :)
<hatch> Makyo: my dogs hate your music
<hatch> lol
<Makyo> Hahahah
<frankban> rick_h_: it seems the sidebar shows up before routeDirectCharmId is called
<Makyo> hatch, currently stuck on http://www.youtube.com/watch?v=l2f6UbMnlq4 though
<rick_h_> frankban: yes, I'm looking now. I think the bug is in the cleanOldViews and the viewmode state change
<rick_h_> frankban: when you go from minimized to sidebar the old sidebar is still there, even though _cleanOldViews should have run .destroy() on it
<hatch> Makyo: slightly different than this version of The Fox http://www.youtube.com/watch?v=jofNR_WkoCE
<Makyo> Do I want to click this?  Will this make me want to strangle someone?
<Makyo> Yep.
<hatch> lol!
<Makyo> C'mere hatch.  Stranglin' time.
<hatch> what does the fox say? ding ding ding ding ding ding lol
<Makyo> James got the woot shirt with that on it.  Sigh.
<hatch> lol
<rick_h_> frankban: so http://paste.mitechie.com/show/1026/ I think fixes it
<rick_h_> frankban: the destroy is called in _cleanOldViews but it never removed the html. This causes the flicker effect when it's made visible again. Fixing the destroy fixes the flicker
<hatch> Makyo: http://www.youtube.com/watch?v=mbyzgeee2mg by the same guys
<Makyo> That video is so ridiculous :P
<hatch> lol
<rick_h_> frankban: so this gets to the point that originally we kept the html around so that minimize/unminimized where instant user experiences
<frankban> rick_h_: that's great! so we were seeing a ghost of the old sidebar
<rick_h_> frankban: but then we ended up with invisible html holding events on the DOM that it should not have and started to clean it up
<frankban> rick_h_: makes sense. and the updateVisible fix really shows its effects, right?
<frankban> rick_h_: ok, bzr pushed the changes, if you want to do a quick final QA. I'll change the test as you suggested and then land the branch, ok?
<rick_h_> frankban: rgr, looking now. Sorry for the delay, had someone at the door. 
<rick_h_> frankban: so one more thing then
<rick_h_> frankban: rather than add the force flag, I think it would make sense for the _cleanOldViews to also remove this._details if it exists and the old viewmode we're removing is sidebar. 
<rick_h_> frankban: then we don't need the force bits at all?
<frankban> rick_h_: makes sense, so in _shouldShowCharm, if we have a charmID but not a _details, we return true
<frankban> (and we don't need force)
<rick_h_> frankban: well the viewmode should have been changed though...I'm looking. It seems shouldShowCharm might be off?
<rick_h_> frankban: so it should work the way it is right? If we have a charm id, and the viewmode changed (minimized to sidebar) then we should show the charm
<rick_h_> we then call renderCharmDetails which checks "is there already a details rendered under this._details"
<rick_h_> frankban: so if we clean up this._details in the _cleanOldViews then that check will work correctly and we'll be fine
<frankban> rick_h_: ok, I'll check it tomorrow, and repropose
<rick_h_> frankban: ok, sounds good. Sorry to run you through it all. 
<rick_h_> thanks for tracing it through
<frankban> rick_h_: no worries: your solution is simple and clean, thanks for helping me
<gary_poster> hey hatch, did you see https://bugs.launchpad.net/juju-core/+bug/1224568?
<_mup_> Bug #1224568: Improve hook error reporting <juju-core:In Progress by themue> <https://launchpad.net/bugs/1224568>
<hatch> looking
<hatch> gary_poster: odd that I have it 'affecting' me but I don't get the update emails
<hatch> thanks for pointing it out
<gary_poster> hatch, look for subscription information on right of bug
<gary_poster> "You are not subscribed..."
<gary_poster> click on link to change
<hatch> weird, so what's the point of 'affects' ? haha
<gary_poster> hatch, I think it was introduced as a way to reduce people adding "+1" comments
<hatch> ohh
<hatch> this is looking great
<hatch> do that's going to be coming in 1.16?
<hatch> so*
<gary_poster> hatch yeah I think so
<gary_poster> hatch, so he means all of those keys come in the unit state keys right?
<hatch> just reading the diffs
<hatch> ok yes so basically he added a new Data param which includes those keys
<hatch> basically exactly what we asked for
<gary_poster> hatch, so those keys are nested in "Data"?
<hatch> right
<gary_poster> cool.
<hatch> yeah so we can modify the contents of Data all we want without stirring up a mess down the road
<gary_poster> oic
<bcsaller> we don't set status, core does
<hatch> we have the keys to core's house
<hatch> ;)
<hatch> I can't seem to link to a line in the diff, but there is now a StatusData key
<bcsaller> I've read the diff
<hatch> the only question I have....is I see the data there for the errors
<hatch> but I don't see how we can tell if it's an error
<hatch> see comment #4 and #5 on the bug
<hatch> oh nm
<gary_poster> hatch, status, yeah?
<hatch> yeah my brain has just been failing lately
<gary_poster> :-)
<hatch> err = u.SetStatus(params.StatusError, "lol borken", nil)
<hatch> we should totally use those error messages
<hatch> haha
<gary_poster> :-)
<benji> oh, the test server port changed; is the new port number random or fixed?
<gary_poster> benji, random
<benji> that's irritating
<gary_poster> benji, I didn't love it but could work around it.  Ben introduced it to reduce people running tests of one branch when they are actually testing another/  what's your issue with it?
<gary_poster> jujugui, charm review in https://codereview.appspot.com/14226043/
<benji> I use browser and command-line history to recall previous test runs (i.e., ones with a "grep=" bit)
<bcsaller> benji: it wouldn't be hard to optionally read the port from the shell env
<benji> it's probably not worth the additional complexity
<rick_h_> bcsaller: yea, maybe limit it to just lboxing vs all test runs?
<bcsaller> its very little complexity 
<bcsaller> process.environ.JUJU_TEST_SERVER_PORT || 0 (not sure I have the spelling right on nodejs env access, just guessing)
<hatch> +1 on checking if open
<hatch> I ran into the issue described but just dealt with it :)
<benji> Yeah, if we're not checking to see if the port is already in use, choosing a random one is worse than using a static one.
<benji> If we are checking to see if the port is available, we could just default to the current (er, old) port number if it is available
<gary_poster> Makyo, should I wait release on bug 1214821
<_mup_> Bug #1214821: new units added to the canvas overlap old ones <juju-gui:Triaged> <https://launchpad.net/bugs/1214821>
<gary_poster> Makyo, IOW are you almost done?  Inclined to forge ahead
<Makyo> gary_poster, don't wait up.  It's relatively small, but will involve a lot of QA on my end.
<gary_poster> cool thanks Makyo 
<hatch> hey only 26errors after the refactor, not bad :)
<rick_h_> hatch: :)
<benji> jujugui: review up: https://codereview.appspot.com/14216044
<hatch> benji: I'll take it
<hatch> no qa notes?
<hatch> or is this the 'unable to do' branch?
<benji> hatch: well, you can do it, but it won't work :)
<benji> you have to enable the charmworldv3 flag
<hatch> benji: lol, so if I use the v3 flag It'll work?
<benji> hatch: no: if you use the v3 flag (and search for "wiki") you will see some bundle tokens that if dragged to the canvas will generate an error
<hatch> oh ok then
<gary_poster> benji, you have a sec to review my charm branch? https://codereview.appspot.com/14226043/
<benji> gary_poster: sure
<gary_poster> thanks benji
<hatch> benji: done
<rick_h_> jujugui small review please https://codereview.appspot.com/14222044
<hatch> is manage.jujucharms.com down?
<hatch> it's giving me a 403 on my api requests
<hatch> rick_h_: sure
<rick_h_> hatch: nope, but the nav is messed up 
<hatch> who's responsible for manage?
<rick_h_> hatch: us :)
<rick_h_> hatch: what's the issue?
<hatch> shit those guys are so unreliable!
<hatch> OPTIONS https://manage.jujucharms.com/api/2/charm/precise/ceph-16 403 (Forbidden)
<gary_poster> benji ^^^ is this the rollout
<rick_h_> hatch: oh, https is down, http is responding to calls oops
 * Makyo dogwalk, appt, etc.  Back at normal EoD, will work some after.
<gary_poster> oh
<rick_h_> I would guess rollout issue with apache there. It should be redirecting http to https
<benji> gary_poster: jjo is actively working on the rollout
<gary_poster> benji ack thanks
<rick_h_> heh, well now it's down down
<hatch> lol - ok well glad we are doing something on it
<hatch> would have been awesome if there were some warning ;)
<benji> that's what you get for complaining; the next time you get a time out
<hatch> lol!
<benji> :)
<gary_poster> jujugui, I am doing release QA, so if you could hold off on landing that would be convenient.  :-)
<rick_h_> gary_poster: rgr
<gary_poster> thank you
<hatch> rick_h_: done
<rick_h_> hatch: thanks. 
<rick_h_> time to go get the boy and do flu shot time. Running away. 
<hatch> lataz
 * hatch thought flu shots were for old people and babys
<rick_h_> hatch: and husbands of doctors...
<hatch> lol yeah good point I guess
<hatch> haha
<rick_h_> day care and doctors bring home lots of bugs for home-body people like me to fight off 
<hatch> yeah - I think that every time I go shopping I get sick
<hatch> lol
<benji> gary_poster: your branch looks good
<gary_poster> Thanks benji
<hatch> I'm going to grab some lunch while manage is spinning back up
<gary_poster> jujugui, release notes.  comments corrections welcome.  http://pastebin.ubuntu.com/6180930/
 * hatch after he reads the release notes
 * hatch still can't believe people turn off cookies
<gary_poster> lol
<hatch> gary_poster: lgtm
<gary_poster> thanks hatch
<benji> the most common lie in release notes: "soon"
<bcsaller> lots of good fixes 
<hatch> soon is relative :)
<gary_poster> :-)
<gary_poster> yes, definitely agree bcsaller
<benji> the notes look good to me
<gary_poster> thanks benji
<gary_poster> qa looks good to me.  found an issue, reported it, but not a showstopper.  proceeding with release.
<benji> abentley and/or sinzui: can you join be and jjo in #webops?  The charmworld upgrade is going poorly and I have to leave for a doctors appointment in 20 minutes.
<jcastro> http://askubuntu.com/questions/352427/juju-gui-charm-api-did-not-respond
<jcastro> anyone ever see this before?
<jcastro> I've never even seen that error before this
<rick_h_> jcastro: there was a deploy back at 19:07ish that had things down for a minute?
<rick_h_> that's a hair under an hour ago and this post is showing about 31min ago?
<rick_h_> jcastro: just a guess, but I'll bet it hit that as apache restarted and hatch hit the same thing in doing some testing. I'd just follow up if it's still an issue and if not then carry on. 
<hatch> jcastro: rick_h_ yes manage.jujucharms.com is down still
<hatch> I'm not sure who's doing the work on it?
<hatch> it's been down for quite a while now
<rick_h_> hatch: oh, didn't notice it was still down :(
<hatch> yeah now it's holding me up....who do I need to lend a hand to to get it back up?
<rick_h_> benji: news from jjo? hatch maybe join #webops and see if there's news to follow up there
<hatch> will do
<hatch> jcastro: I can reply to that askubuntu post
<hatch> I should create an account anyways
<hatch> :D
<hatch> jcastro: done http://askubuntu.com/questions/352427/juju-gui-charm-api-did-not-respond/352444#352444
<_mup_> Bug #352444: Banshee.exe crashed with SIGSEGV <amd64> <apport-crash> <apport-failed-retrace> <banshee (Ubuntu):Invalid> <https://launchpad.net/bugs/352444>
<hatch> I also subscribed to juju and gui tags so hopefully as new ones come up I can help with them
<gary_poster> jujugui, release was made, but holding off on announcement till charmwoprld is back
<gary_poster> benji, you landed in middle of release, but was ok :-P
<benji> gary_poster: darn!  I was so focused on finishing before I had to go I messed up.
<gary_poster> benji, np :-)
<benji> I guess in an ideal world we would have a gate on that.
<hatch> we do don't we?
<hatch> because you release from your own machine
<hatch> :)
<gary_poster> benji, do I understand correctly that the deployment problem is that pyjuju/zookeeper fell over badly?
<benji> gary_poster: that is at least part of it
<hatch> it's times like this I'm glad I'm not in devops
<hatch> er
<hatch> sysops
<gary_poster> oh, there's more benji?  I saw sinzui point out http://staging.jujucharms.com/heartbeat
<gary_poster> is that an issue?
<benji> gary_poster: that status is 25% better than it was when I left
<gary_poster> benji, that's staging
<benji> oh, darn
<gary_poster> http://manage.jujucharms.com/heartbeat
 * gary_poster needs to step away
<huwshimi> Morning
<hatch> ahoy!
<hatch> you missed all the downtime this afternoon - came up just in time for you to be productive ;)
<hatch> but a GUI release went out
<hatch> so that's cool
<huwshimi> :)
<gary_poster> hey huwshimi.  yeah, "exciting" afternoon. ;-) Have a good day.
<huwshimi> hehe
<hatch> haha - so when manage went down I kept working on my branch - and it all still works
<hatch> lol, yussss
<hatch> man sometimes i get some super odd content requests on my blog...
<hatch> and not just once either
<hatch> like requests for php files, aspx files ?
#juju-gui 2013-10-02
<rick_h_> hey, mjc appears up yay
<hatch> yup!
<hatch> I'd be interested to know what the issue was
<hatch> rick_h_: gl on the winter tire search - it's damn near impossible to compare tires because no one has experience with both :) so 'ratings' are essentially worthless
<hatch> so flip a coin ;)
<rick_h_> hatch: yea, when I got tires on the subaru it seemed I found some really good info. Now I can't seem to find anything
<hatch> buy the same ones for the bee dub
<rick_h_> then again I got a couple different ones and I was always happy with them. 
<hatch> vee*
<rick_h_> well, they're not around any more
<hatch> oh boo
<hatch> I think I have the x-ice on my truck
<rick_h_> and the subie tires were all season with decent winter tread. I'm just getting straight winter since I need to get 17" wheels anyway (19'
<rick_h_> s on there now)
<rick_h_> so first time doing the full swap of wheel and all for seasons
<hatch> I think I'm going to go with something with some more tread next time though for deeper snow
<rick_h_> yea, the blizzak has a little more tread
<rick_h_> I'm leaning that route atm
<hatch> yeah - the ice performance of either will probably be neglegable
<rick_h_> yea, but ice ice is rare. I more want to go play when 6" falls
<hatch> ohh haha
<rick_h_> I don't like getting trapped in the house. I always need to prove I can go out and get a coffee :)
<rick_h_> 12" came down during the day, we need to get some milk from the farthest store for the morning hehe
<rick_h_> but it's the whole family safety thing. If I spend decent $$ and it performs better when I'm dodging the idiot spinning his wheels on the curve running into me...priceless
<rick_h_> tires make such a difference. More so than a lot of vehicle/traction control systems 
<hatch> well it's the only thing connecting those couple tonnes to the road :)
<hatch> holy smokes winter tires have gone up in price
<hatch> ohhhh nm heh
<hatch> I was reading it wrong
<rick_h_> yea, tires + wheels are going to run me close to 1500-2000 :/
<hatch> ahh - yeah I already have another set of wheels so I'm lucky that way
<rick_h_> though getting the 17" tires will save a chunk. Started out looking at 18" ones
<hatch> also saves me from having to pay to switch them over
<rick_h_> yea, bell tire will do storage for $60 ish a season
<hatch> don't you have a huge yard?
<hatch> lol
<rick_h_> so that's worth it to me to just swap the wheels out, put them into storage, and I'll see you in 6mo
<rick_h_> no, not really. My garage is full of woodworking gear
<rick_h_> if I had built my dream shed I'd be cool, but didn't do that this year. 
<hatch> yeah ours goes into the shed
<rick_h_> I've got a baby plastic shed full of lawn gear. At least that's out of the woodshop now. 
<hatch> ohhh - yeah a couple years ago I picked up a nice big tin one
<hatch> used
<rick_h_> nice
<hatch> yeah it was a steal, but we had to take it apart
<hatch> but I think I saved like $800 from new
<hatch> so I was ok with that :)
<rick_h_> yea, that's good stuff. You put it on dirt or pour a pad down?
<hatch> built a 2x6 floor and put it on that so if I need to I can just drag it wherever I want
<hatch> and I had the spare 2x6's
<hatch> haha
<rick_h_> nice!
<hatch> honestly though, it'll probably never move
<hatch> my $/km that I spent on that truck is just nuts lol
<hatch> I need to get in it every morning and drive it around or something
<hatch> haha
<rick_h_> thanks frankban 
<frankban> rick_h_: thanks for QA and suggestions.  /login/data/wordpress-api-response.json 404 is very annoying
<rick_h_> frankban: the /test/data?
<frankban> rick_h_: make test-prod (and therefore lbox propose/submit) fails intermittently here with this error: http://pastebin.ubuntu.com/6183447/
<rick_h_> frankban: hmmm, usually when I would get that there'd be some error where a navigate would occur breaking the loading of test data. I'm guessing some /login test is doing something bad
<rick_h_> strange that it's intermittent
<frankban> rick_h_: yeah
<gary_poster> I'm going to take my "lunch" early.  back in about an hour.
<rick_h_> gary_poster: have fun
<hatch> mornin
<rick_h_> morn
<rick_h_> is the design meeting on? No one's there? luca__ gary_poster ?
<luca__> rick_h_: yup, coming now
<gary_poster> aiiiie!
<gary_poster> I closed the thing and lost my chat!
<gary_poster> boohoo hoo
<benji> ???
<gary_poster> I had info I wanted n the google hangout chat
<gary_poster> and forgot to copy it out
<gary_poster> :-(
<benji> yeah, info in hangout chat is so easy to loose
<benji> IRC logging for the win
<gary_poster> yeah, that or a google doc.  hopefully I will learn my lesson :-(
<hatch> they finally added a 'do not mute' button when typing
<hatch> so that's cool
<hatch> no more js console hacks
<hatch> To solve this issue I create an ssh tunnel to it, but I'm guessing that's not the real story for this guy...or is it?  http://askubuntu.com/questions/346991/juju-gui-public-ip
<hatch> I'll reply in kind if it is
<hatch> rick_h_: looks like you can upgrade your favourite tech toy http://www.engadget.com/2013/10/02/fitbit-force-wristband-watch/?utm_medium=feed&utm_source=feedly lol
<rick_h_> hatch: ugh, stupid thing. 
<rick_h_> hatch: pebble > fitbit
<rick_h_> not going to go that route
<rick_h_> hatch: as to the SO question, check with jcastro but I think you can configure lxc to not use nat, but bridged networking? Maybe they can tweak a config to get the IP to be exposed naturually. Otherwise, yea it needs a tunnel
<jcastro> we need a Best Practice for LXC networking with Juju
<hatch> jcastro: sounds good
<hatch> in the meantime....? shall I reply with the tunnel instructions?
<hatch> :)
<jcastro> sure
<jcastro> I need to do a call on the list for common workflows
<rick_h_> hatch: there's a question on the bridge side here with an accepted answer http://askubuntu.com/questions/231666/how-do-i-setup-an-lxc-guest-so-that-it-gets-a-dhcp-address-so-i-can-access-it-on
<rick_h_> hatch: might at least link to it as a potential method to follow up on
<hatch> sure thanks
<rick_h_> which links to http://askubuntu.com/questions/256304/public-ip-address-for-lxc-container/311003#311003
<_mup_> Bug #311003: [Patch] Fix linking when with --as-needed --no-undefined <HPLIP:Triaged> <https://launchpad.net/bugs/311003>
<rick_h_> lol, welcome to the internet
<rick_h_> link -> link -> ...which one do I want!!!
<hatch> so the UK is censoring the internet, our city is trying to zone for the newly allowed strip clubs...man people are afraid of nekkid ppl!!
<adeuring> abentley, benji: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/proof-lib-path/+merge/188871 ? (tiny diff)
<benji> adeuring: sure
<adeuring> thanks!
<hatch> replied http://askubuntu.com/questions/346991/juju-gui-public-ip/352764#352764
<_mup_> Bug #352764: If kwallet is disabled, network manager plasma widget does not connect to wirelessly <knetworkmanager:Fix Released> <plasma-widget-networkmanagement (Ubuntu):Fix Released> <https://launchpad.net/bugs/352764>
<hatch> thanks mup but that wasn't a bug
<gary_poster> hey frankban what happened to https://codereview.appspot.com/13900044/ ?  looks like it never landed?
<gary_poster> but I thought this was fixed
<benji> adeuring: your branch looks good
<frankban> gary_poster: looking
<adeuring> benji: thanks!
<Makyo> jujugui call in 10 kanban now
<gary_poster> jujugui call in 10
<gary_poster> darn!  :-P
<Makyo> \o/
<gary_poster> lol
<frankban> gary_poster: ah, do you remember that we discussed the switching to the ServiceUpdate call and realized it was not backward compatible? I created and landed another branch to fix that bug: https://codereview.appspot.com/13917043/
<gary_poster> frankban, ah right!  could you mark those (MP and RV) as dead so future generations are not confused? :-)
<frankban> gary_poster: sure :-), sorry for the confusion
<gary_poster> np
<gary_poster> ooh, someone soon will be able to have the bug number 1234567
 * gary_poster starts filing bugs...
<frankban> :-)
<Makyo> jujugui call in 2
<gary_poster> Makyo, wassup?
<Makyo> gary_poster, juju is eating my machine
<hatch> nom nom nom
<Makyo> Going to run a quick errand so we actually have food for lunch besides eggs, won't be long.
<hatch> mmm foood
<hatch> i forgot breakfast again
<hatch> damn
<hatch> I love it when auth fails while lboxing AFTER it's run lint and tests...ugh lol
<hatch> jujugui anyone else having issues lboxing?
<hatch> error: use of closed network connection
<hatch> 3 times in a row now?
<rick_h_> hatch: not an issue early this morning when I landed mine, but that sounds like LP issues. 
<hatch> yeah, well will try again I guess!!
<benji> hatch: I've gotten that error recently (but it cleared up when re-run); I too suspect an LP issue (probably a timeout)
<hatch> here it goes
<hatch> 5th time is the charm :)
<hatch> does anyone know how to copy text in the terminal with the mouse in tmux when you have `setw -g mose-mouse on` ?
<hatch> btw gary_poster using `bzr mv` worked properly this time - not sure what happened last time
<rick_h_> hatch: middle-click is what I use to copy all text into the terminal
<hatch> hmm no middle click
<hatch> oh into the terminal
<rick_h_> shift-insert then I think?
<gary_poster> hatch, good.  yeah, has always worked for me
<hatch> I need out of the terminal
<hatch> tmux now captures the mouse highlight it seems
<rick_h_> hatch: then highlight with the mouse and then middle-click it where you want it to go
<hatch> as soon as I release the highlight is gone
<rick_h_> not sure
<hatch> yeah it's pretty odd
<hatch> rick_h_: would ya mind? https://codereview.appspot.com/14175046/
<rick_h_> hatch: sure ting
<rick_h_> thing
<hatch> coolio
<rick_h_> hatch: comments and qa issue inbound
<hatch> rick_h_: reading thanks
<hatch> rick_h_: fixed - reproposing
<rick_h_> hatch: k, sec and will relook
<hatch> rick_h_: sorry have test failures again
<hatch> lboxing again
<hatch> gary_poster: thought you would want to know that Dell just upgraded the XPS 15 laptops.... :P
 * hatch ducks
<gary_poster> hatch, heh :-P
<hatch> rick_h_: ok reitveld has the new stuff
<rick_h_> hatch: k, looking
<rick_h_> hatch: so then did you bzr grep all BrowserCharmView and look for the data passed in?
<hatch> yeah did I miss one?
<rick_h_> hatch: no, just asking
<hatch> doesn't look like it
<hatch> oh ok
<hatch> but I also use `ack-grep` :)
<hatch> does bzr grep work better?
<rick_h_> hatch: cool, sorry. My review is to ask questions and prod thinking vs just "here's my list"
<rick_h_> hatch: bzr grep just makes sure to only limit to files in the bzr content
<hatch> oh ok - that might be better because then it'll skip any of the built files
<rick_h_> git has the same thing. Handy for ignoring files you don't care about easily
<rick_h_> yep
<hatch> I'll try and remember to use that
<hatch> I used to have 'ack' (OSX) set up to ignore anything in the .gitignore so I guess that just stuck :)
<hatch> rick_h_: found out how to copy in tmux with my settings hold 'shift' or in iterm(OSX) hold 'option'
<hatch> just fyi
<rick_h_> bah, I want to bank my bug credit for my next QA day :P
<rick_h_> hatch: cool, not a problem here so must be some mac-ism or something. Good to know I guess
<rick_h_> hatch: and LGTM thanks for the updates
<hatch> thanks!
<hatch> rick_h_: do you have tmux capturing your mouse scroll?
<hatch> so you can scroll up/down in tmux with the mouse?
<rick_h_> hatch: hmm, I do that in my terminal I think. 
<hatch> that setting appears to trigger the issue
<rick_h_> so no, guess I don't
<rick_h_> benji: ping, got a sec?
<benji> rick_h_: sure
<benji> rick_h_: video chat or here?
<rick_h_> benji: video please, sec will set up
<benji> rick_h_: try this benjiyork.com/chat
<rick_h_> connecting
<benji> rick_h_: you were my first chat using that thing, other than not having a mute it worked well
<hatch> what is it?
<rick_h_> benji: yea, worked fine. Backgroud noise on the road there but other than that sounded good and loaded up quick
<rick_h_> <3 the nice url 
<benji> heh
<benji> yeah, me too
<rick_h_> https://code.launchpad.net/~rharding/charmworld/bundle-metadata/+merge/188905 for a WIP with notes on why some stuff is changed. Feel free to smack my hands with the rule where I'm going against the new grain
<rick_h_> appreciate the time to peek at it
<benji> rick_h_: looking
<rick_h_> heh, there's some silly stuff in the mid-mode. #185 for instance is meant to be the upcoming icon helper method but it looks just like the next block in the if 
<benji> rick_h_: why the new constant empty dict being returned from _extract_charm_id?
<rick_h_> benji: confusion. Typo going back/forth between methods since I added the third param to the bundle things to help find bundles
<rick_h_> benji: chalk it up to mid-work
<benji> k
<rick_h_> benji: so get_file returns the bytes, but none of the extra info for serving the file like content_type and such?
<rick_h_> or nvm, that's the gridfs object so should have the content-type in there 
<benji> ok
<gary_poster> need to get kids from school.  back soon
<benji> rick_h_: your branch looks fine to me
<rick_h_> benji: cool
<rick_h_> benji: the file hashes in the basket db can be yaml?
<benji> rick_h_: I don't understand the question. 
<rick_h_> benji: I'm looking at how the files are getched and noticed in the unquote_yaml. nvm, that's the period escaping stuff. Ignore me
<rick_h_> man, is today monday or something?
<benji> heh
<benji> It's Monday somewhere.
<rick_h_> that and I keep typing backet vs basket
<rick_h_> I can't seem to hit 'as' in a row
 * gary_poster here
<gary_poster> oh rick_h_...you available to talk in 5?  you are probably past your EoD, yeah?
<rick_h_> gary_poster: I can talk in 5
<gary_poster> cool thanks
<gary_poster> rick_h_, uh "five minutes"... https://plus.google.com/hangouts/_/d909f7c1b9c8db56be05af4887e38eef6587a85c?hl=en if you are still ok :-)
<rick_h_> benji: still around?
<benji> rick_h_: yep
<rick_h_> does fs.put(content, contentType=content_type)
<rick_h_> *** TypeError: must specify an encoding for file in order to write unicode
<rick_h_> ring a bell? Trying to manually put a file into fs. Looks like all we do is shove a string of content in but getting this when trying to do it via pdb
<rick_h_> the code is currently just silently passing without any files added to the gridfs
<rick_h_> content is just a u'Test Content' for a test file 
<benji> rick_h_: I don't think I've seen that error in that context, but the problem is that it wants a string and it doesn't know what encoding it hould use.  de-unicode your string and you should be fine.
<rick_h_> hmm, guess it just doesn't like the unicode. I see it in the docs now. Ignore me some more
<rick_h_> but still isn't there...ugh. after an fs.put() and then an fs.list() is empty
<rick_h_> hmm, there it goes. Ok. maybe I just timed it wrong. Stupid 'eventually consistent' not liking my pdb points
<benji> heh
<rick_h_> yay! test passes. 
<rick_h_> thanks for the help today benji. 
<benji> my pleasure
<rick_h_> benji: #1190944 is the orig of your markdown bug
<_mup_> Bug #1190944: The copyright header of README.md in the charm is shown <charm> <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1190944>
<benji> rick_h_: thanks, I'll mark mine as a duplicate
<benji> I changed 1190944 to "Low", it was "Medium"
<hatch> jujugui I'm investigating the bug -re gary_poster email
 * hatch wishes everyone replied to emails from the top :D
<hatch> gary_poster: I'm a little confused here - it appears that it -works- in the gui but does not in the console....
<hatch> the email conflicts itself
<hatch> nm I was able to reproduce
<hatch> bcsaller: ping
<bcsaller> whats up?
<hatch> avail for a quick call?
<hatch> re this email
<hatch> https://plus.google.com/hangouts/_/4cec75a250f0b68cdf45f3c060a997dbdccb9c3b?hl=en
<hatch> bcsaller: hangout is not working lol
<bcsaller> nope
<bcsaller> hatch: happy to say its a charm issue if we can get away with it, but we should make an attempt to detect it somewhere in the pipeline then
<bcsaller> and update the docs
<bcsaller> its a bit sad that there isn't an easy fix on our side though
<hatch> go javascript? ;)
<hatch> bcsaller: so can you think of any other ideas besides formatting the keys?
<hatch> we could restrict to a single level of recusion?
<hatch> nah that could still break the YUI ones
<hatch> so basically only formatting the keys will help
<bcsaller> hatch: I think we detect the case and inform the user. I would like to test that you can actually get/set those keys in a core env though
<hatch> yeah i'm spinning up one right now
<bcsaller> in which case its really matter of enforcing proper policy that it doesn't work
<hatch> takes a long time :)
<bcsaller> yeah
<bcsaller> hatch: I suppose we could fork, fix and offer up the charm with s/\./\-/ in the key access
<hatch> heh - yeah that would probably be the best way
<hatch> bcsaller: although I wonder if it requires the keys in that format
<hatch> so we would need to format them again in the charm
<hatch> hah
<bcsaller> we'd have to change config.yaml and the hooks 
<hatch> right - I mean, I wonder if it uses the same keys to set the values in Hadoop
<hatch> I Know nothing of how Hadoop works to know if those are valid keys
<hatch> and of course launchpad is showing the files are empty...
<bcsaller> http://manage.jujucharms.com/charms/precise/hadoop/hooks/config-changed ::170 ish
<hatch> so yes
<hatch> heh
<hatch> :/
<bcsaller> hatch: well, it looks like it uses the name twice, once in the dot form and once to lookup the juju value, which could change
<hatch> right, we could change the key value in juju
<hatch> ok I'll update the ticket with this
<hatch> see where we are going with this
<hatch> mostly because it's STILL starting
<hatch> lol
<hatch> bcsaller: yuss it breaks on juju-core
<hatch> :)
 * hatch does a happy dance
<bcsaller> ha, good
<huwshimi> Morning
<bcsaller> at least my understanding of the world is correct. So we can do a number of things now. Warn in the GUI, warn on the CLI, and warn when we proof/ingest the charm
<bcsaller> well, on ingest it would be a fail
<hatch> yeah ok I'll write this all up in the ticket
<bcsaller> hatch: it does look simple enough to fix in the wild, but still a pain
<hatch> yep
<bcsaller> moring huwshimi 
<bcsaller> if I could type
<hatch> morning huwshimi
<huwshimi> heh
<hatch> ahh just call him sashimi
<hatch> :P
<hatch> I probably spelt that wrong
<rick_h_> hatch: what's up? What bug? You working around '.' in something? Charmworld does the escaping/dealing with that usually
 * rick_h_ doesn't see a gary email/bug at the top of the email
<hatch> rick_h_: ttps://bugs.launchpad.net/charms/+source/hadoop/+bug/1234365
<_mup_> Bug #1234365: juju-gui does not give option to pass configure paramter <hadoop (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1234365>
<rick_h_> hatch: ah, so this is purely on the gui talking to juju side and not around charmworld
<rick_h_> hatch: nvm, ignore me then
<hatch> already done
<hatch> :P
<hatch> jk
<rick_h_> :P
<hatch> rick_h_: honestly though, shouldn't charmworld have seen the config options using .'s and failed the injest?
<rick_h_> hatch: no, we escape the . in storage of mongo and unescape during api calls
<rick_h_> hatch: as you say in your note, it's valid from the cli and such
<rick_h_> hatch: it's up to the client to deal with the issue once we've worked around the '.' not being able to be stored in mongodb itself
<hatch> rick_h_: well no the CLI throws an error if you try to access/set that config option
<rick_h_> huwshimi: https://code.launchpad.net/~jcsackett/juju-gui/charm-slider/+merge/152418 is the branch that initially added it. I'd search for a branch afterwards that removed the widget from the codebase for the final version
<rick_h_> huwshimi: well then yea, I'd talk to marcoceppi about having proof blow up in that case and then charmworld would have rejected it
<rick_h_> huwshimi: and the proof tool will tell the author when they write the charm not to do it before they ever submit/get through any review process
<rick_h_> sorry hatch ^^
<huwshimi> rick_h_: Thanks for that
<marcoceppi> rick_h_ huwshimi: if proof is missing functionality (hatch ?) feel free to open up a bug against charm-tools with a description. I'm gearing up for a 1.1 release before the cloud sprint and will try to include anything you guys need
<rick_h_> huwshimi: np, it was in the code for at least a few weeks I think
<huwshimi> rick_h_: haha
<marcoceppi> (also patches accepted)
<rick_h_> marcoceppi: so does it sound reasonable/is it known that having config options in the charm with a '.' in the name is bad?
<hatch> marcoceppi: ok I will do that, thanks https://bugs.launchpad.net/charms/+source/hadoop/+bug/1234365 to see the issue in question
<_mup_> Bug #1234365: juju-gui does not give option to pass configure paramter <hadoop (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1234365>
<marcoceppi> rick_h_: I'm not awayre of an issue with a .
<marcoceppi> rick_h_: I know that's a problem with charm names
<rick_h_> yea, that's the rub I guess. hatch so we should dupe that the cli hates charms with a . in a config name, maybe even email the juju list about it, then update proof to check and erorr on it
<rick_h_> problem goes away :)
<hatch> oh charmtools is written in python
<hatch> yeah you wouldn't want me to issue a pr
<hatch> :D
<gary_poster> hey hatch thanks a lot.  I read backlog and bug.  looks like you have it in hand.  if you have to go, send me an email to hand off.  If you end up staying up late on this to resolve, send me an email and then take some corresponding time tomorrow
<gary_poster> I have to go take care of kids and house meanwhile :-)
<gary_poster> ttyl
<hatch> gary_poster: waiiiiit
<hatch> see your email
<gary_poster> hatch here
<hatch> i JUST sent a follow-up with Narinder
<hatch> would you like me to do the mechanical change and 'hope' it works? or wait for Kapil?
<hatch> I'm ok with either options
<gary_poster> hatch ack.  so the mechanical change would be to change the values in config and then try to figure out where the charm consumes the config values and change them?
<gary_poster> hatch did you verify that juju set fails?
<hatch> right - it does a sort-of mapping to build the XML config file
<hatch> yes, it does fail
<hatch> so I could change the hook to use the new config values and hope that it still works - but like I mentioned in the email, I don't even know what constitutes 'running' for Hadoop so I wouldn't know how to test it beyond a basic juju deploy
<hatch> I'm sure I could learn, but not in a couple hours haha
<gary_poster> cool.  we should clarify that.  I'll shoot a quick email reply to confirm that.  hatch, how quick would it be for you to make that change?  easy?  or easier for Ben if he is around?  If it's a matter of 30 minutes, you could simply offer a mechanical branch and let Kapil or Narinder know its existence.  They would then see the issue
<hatch> I could probably do it in <1H if it's simply a case of doing a mechanical change and pushing it back up for someone else to take from there
<gary_poster> hatch do it, if you are willing.  Thank you.  I will have a reply for you to review in just a sec.  then I really need to run
<hatch> sure - I'll just need to find where the source is kept
<hatch> http://bazaar.launchpad.net/~charmers/charms/precise/hadoop/trunk/files/head:/hooks/
<hatch> all the files are empty?
<hatch> jcastro: are you around?
<gary_poster> hatch they are all symlinks
<gary_poster> its a common pattern
<gary_poster> hatch see hadoop-common and ganglia-common
<hatch> ohhhhh
<hatch> interesting pattern
<hatch> ok I'll do the mechanical change and then push it up
<gary_poster> cool thabnks
<hatch> have a good night
#juju-gui 2013-10-03
<hatch> any bash experts in?
<bcsaller> hatch: not an expert but I might be able to help
<hatch> bcsaller: oh np I figured it out already
<hatch> thanks though
<bcsaller> heh, ok
<hatch> in fact I think I found a bug in the Hadoop bash script
<hatch> copied it wholesale into a script to test and it failed...so I was like wtf hah
<hatch> but since you're here mind taking a look at a diff?
<hatch> https://gist.github.com/hatched/fc70d29198df22cf32ad
<hatch> I'm assuming that the size of the diff is because there were trailing whitespaces?
<bcsaller> hatch: I'm guessing line 174 was where your question was :)
<hatch> nope, see 126 vs 132
<hatch> that being on the next line caused it to not work in my test script
<hatch> so I wasn't sure how to debug it
<hatch> bash -x filename
<hatch> the -x was what I needed
<hatch> now I have to figure out how the heck to deploy a charm from my launchpad account
<hatch> :/
<bcsaller> ahh, that I could have told you, you put set -xe at the top of scripts to get the echo/exit on error behavior
<hatch> oh cool
<hatch> what does the -e do?
<bcsaller> exit on error
<hatch> ahh cool
<bcsaller> x is the echo
<hatch> learn something new every day
<hatch> :)
<bcsaller> looks like it should work, you verified that was all the usage of config-get/set? its not in the relation hooks or anything?
<bcsaller> or are they all symlinks?
<hatch> all symlinks
<hatch> interesting approach but smart
<hatch> now I'm trying to test it but I can't figure out how to deploy it lol
<hatch> looks like it's gota be local
<hatch> hmm I want to deploy a local charm via the GUI
<hatch> I wonder if this is a rare occurance
<bcsaller> yeah, it doesn't work by default
<hatch> I'm not actually sure how you would do it withou a local charmstore
<hatch> but it would be cool if we could select a dir to deploy
<bcsaller> hatch: we've talked about a number of longer term plans for how to do this, but currently I think your instinct was correct a local charm store and maybe changing the config settings to point the API endpoint there
<hatch> yeah I'm definitely not going to attempt setting up a local charmstore
<hatch> :D
<hatch> I gota go cook supper soon haha
<bcsaller> me too
<rick_h_> hatch: it's a charm, you can push your branch up and get it in the official store
<rick_h_> hatch: just 'juju publish' it. It'll be under your username, etc.
<rick_h_> https://jujucharms.com/fullscreen/search/?text=apache look at the 'more charms' section :)
<hatch> rick_h_: oh cool thanks good to know
<hazmat> hatch, thanks
<hazmat> anyone know how to get personal charms to show up in the gui search?
<hazmat> hmm.. looks like its a manage.jujucharms.com issue.. 
<rick_h_> benji: is charmworld still sans lbox?
<benji> rick_h_: some people have claimed that it works for them, but I haven't been able to get it to work.  The problem may be the way I have lbox installed on my LXC container.  
<rick_h_> benji: hmm, that's what I'd be doing so if you're willing to do LP review I'll skip it then. 
<rick_h_> benji: writing things up and will ping once done if you've got time to peek at it. 
<benji> rick_h_: sure
<rick_h_> benji: https://code.launchpad.net/~rharding/charmworld/bundle-metadata/+merge/188905 (one line lint fix just pushed and will sync in a min)
<rick_h_> thanks!
<rick_h_> benji: and so the idea is that with this we get support for the trailing bits of a url after the id, so going to add a bundle/some/id/charmdetails to provide the different payload format withthe charm details per our previous discussion?
<rick_h_> does that jive with what you recollection of our talk on Tues?
<benji> rick_h_: makes sense
<benji> rick_h_ (and gary_poster): I need to run an unscheduled child to daycare, I'll be back in about 15 minutes
<gary_poster> ok benji 
<rick_h_> thanks benji 
<frankban> luca__: hi, could you point me to any css/html resources for building a webpage similar to juju.ubuntu.com?
<rick_h_> benji: when you get back want to see if you've got a sec for a chat. A question came up from my call with gary
<rick_h_> frankban: there's the base resources. /me goes to look where they shared that. 
<frankban> rick_h_: thanks
<benji> rick_h_: I'm available now.
<rick_h_> benji: want to use your chat thing? 
<benji> rick_h_: sure: benjiyork.com/chat
<rick_h_> frankban: so there's a lp project of shared base css/etc resources and I'll have to dig for it. If luca__ comes by he might remember the link. The web team in HQ runs it
<rick_h_> it's like ubuntu bootstrap
<luca__> frankban: rick_h_ heya
<luca__> frankban: rick_h_ this is the link: https://dl.dropboxusercontent.com/u/46840621/Web%20style%20guide/v3/get-started.html
<luca__> frankban: rick_h_ it's work in progress but should be what your looking for
<rick_h_> benji: http://bazaar.launchpad.net/~bac/charms/bundles/wiki/bundle/view/head:/bundles.yaml
<frankban> hi luca__, thanks!
<luca__> frankban: rick_h_ if you need any help or information, ping Anthony Dillon (ant on IRC) and he should be able to fix anything
<rick_h_> http://charmworld:2464/~bac/bundle/wiki/wiki
<rick_h_> https://manage.jujucharms.com/~bac/bundle/wiki/wiki
<rick_h_> frankban: luca__ http://bazaar.launchpad.net/~ya-bo-ng/ubuntu-brand-guidelines/trunk/files is what I was thinking of I think
<gary_poster> hey jujugui, I feel not good.  Going to go lie down for a few. back when I can; will periodically check email
<rick_h_> gary_poster: good luck
<gary_poster> ty
<jcastro> when we remove stuff in the GUI
<jcastro> does that destroy-service or destroy-unit?
<rick_h_> jcastro: there's the option for each, not following you. 
<jcastro> http://askubuntu.com/questions/353114/how-can-i-know-which-machine-juju-is-actually-using
<jcastro> I am wondering if people think they're removing units
<jcastro> but are not
<rick_h_> I know lxc has a thing where destroy service doesn't remove the machine, maybe azure has an issue there? 
 * rick_h_ checks some code quick
<jcastro> yeah, since this is an azure one I was wondering that too
<jcastro> nice to know people are trying it on azure!
<rick_h_> well, so destroy service calls destroy service. I'd be curious to know if the gui instance was recent enough to have the inspector. In the older UI I could see where destroy unit might be what he clicked vs service destroy. 
<rick_h_> when you destroy a unit does the underlying machine get removed?
<rick_h_> guess, the only real way to chase it would be to try it out and see if we could dupe it. 
<jcastro> I'm going to ask him to mail me, I have a bunch of other questions to ask him
<jcastro> more about "hey so did our docs suck?" and so on
<rick_h_> jcastro: ok cool. Let us know if you can help when you get more details. Knowing more of what version of the Gui he was using, what he actually did, etc
<rick_h_> I don't know if any of us have tried things on azure yet so cool to know it at least got going and working :)
<frankban> jcastro, rick_h_ : from the GUI we send a DestroyService API call. ServiceDestroy does not destroy the machine (and I believe this behavior is shared by all providers). AFAICT there is no API for destroying a machine. DestroyServiceUnits also seems to leave the machine up.
<jcastro> yeah the thing is this guy thought he was running X VMs, but was really running X+whatever.
<jcastro> that's going to cost people money
<jcastro> then they're going to say "wait, but I told the GUI I didn't want those services anymore, why are there blank machines running up my bill?"
<frankban> jcastro, rick_h_: That's right. I believe we will handle that as part of our machine/containerization story. Right now the GUI does not manage/expose machines at all, and as I mentioned my understanding is that there is no API to do that (we will need an API for all the provisioning CLI commands).
 * jcastro nods
<frankban> jcastro: you might want to ping gary_poster when he's back, he surely have a better knowledge of the problem
<jcastro> I think in the meantime ... would it be a bad thing to note this in the docs or the charm readme? Like in huge letters?
<jcastro> I am just envisioning some guy trying out juju at work and running up this huge bill
<jcastro> and his boss getting stuck with the check with a mental image of juju... that thing that cost me money.
<frankban> jcastro: yes, that's a good idea, I'll make a card
<rick_h_> frankban: oh, I thought it was just an lxc thing which is how I end up doing things. Knowing is half the battle I guess
<frankban> rick_h_: yeah, that's the same on ec2. It's the way juju-core works when you just destroy a service
<frankban> rick_h_: pyJuju did that differently: destroy-service == bye bye machine
<jcastro> yeah, I think we should bring in design at the sprint too. We need to ensure that the GUI always is upfront on how many instances are running for real
<jcastro> we can't let that be hidden or put behind somewhere where it won't be discoverable
<rick_h_> frankban: ahhhh, maybe that's where I'm confused then. I only moved to juju-core once lxc came out
<rick_h_> jcastro: yea, there was work on ideas for a 'machine view' during the last sprint, but that's work that's a little bit out atm
<benji> abentley: I have a demo bundle I want to get into charmworld, will it be picked up automatically, or is there something I have to do?
<frankban> rick_h_: created a card in maintenance high: GUI Charm: document that machines are not removed when you destroy services from the GUI
<jcastro> rick_h_: yeah I get that, but maybe there's some low hanging fruit somewhere
<jcastro> rick_h_: if you don't know how juju works it looks like the gui is lying to you
<rick_h_> jcastro: yea, just meant the idea is on the radar. 
<abentley> benji: It will be picked up automatically, as long as the naming conventions are right.
<benji> abentley: great, thanks
<abentley> benji: file must be named "bundles.yaml", series must be "bundles", branch must be named "bundle"
<abentley> benji: This just got picked up automatically yesterday: http://manage.jujucharms.com/~abentley/bundle/charmworld/staging
<benji> abentley: I think I have it right.  I branched from bac's bundle, which appears to work
<Makyo> 40 minutes -> 10 minutes.  I kind of hate this battery.
<rick_h_> Makyo: replacement battery?
<Makyo> rick_h_, I guess so.  It's been less than a year, though, so I'm mostly just disappointed.
<rick_h_> Makyo: gotcha, yea mine is just over a year and getting to that time so battery on the brain
<rick_h_> Makyo: http://paste.mitechie.com/show/1027/ ?
<Makyo> .182222
<rick_h_> wow!
<rick_h_> so when you charge it up now, it's only going to 18% of the original capacity
<rick_h_> and it's less than a year old?!
<Makyo> Yeah, I got it just before Copenhagen.
<rick_h_> mine's at 75% and on the replacement block. 
<rick_h_> hit 1yr around july I think
<rick_h_> crazy
<Makyo> Oh well.  Sent in a support ticket.  If the solution is to buy a new battery, that's fine, will just have to wait.
<rick_h_> yea, if less than a year that seems a warranty issue for sure
<Makyo> I checked, it's just about a year, got it about this time last year, from the looks of it.  I didn't do the "periodically drain the battery" thing, though I'm not sure if you need to do that anymore.
<rick_h_> yea, it should destroy it that bad :/
<Makyo> Damn.
<rick_h_> heh, warranty die yesterday?
<Makyo> Last week.
<Makyo> Oh well.
<hatch> Makyo: well time to get the Air setup for dev :)
<Makyo> Haha, I guess!
<Makyo> I'll have it set up by Oakland, for sure.
<Makyo> It kinda works now, just not ideal.
<hatch> it has 8GB or 4GB?
<Makyo> 4
<Makyo> So lboxing will take a while.
<hatch> ahh - well you might want to run Ubuntu on metal then if you want some better perf outa it :)
<Makyo> It works fine for actual dev work, tbh.
<hatch> oh that's cool - I was a little worried the vm would use too much ram
<Makyo> I have it somewhat constrained, but it's also a very light-weight installation of ubuntu server, rather than desktop.
<benji> abentley: how long should I wait for my bundle to be picked up before becoming concerned?  It has been well past the 15 minute enqueue/ingest cycle.
<abentley> benji: It should only take 15 minutes, so I'd be concerned now.
<benji> darn
<abentley> benji: What's the branch?
<benji> abentley: https://code.launchpad.net/~benji/charms/bundles/wiki/bundle
<abentley> benji: Nothing obviously wrong to me.
<benji> abentley: thanks for looking
<hatch> well I have now spilt two cups of coffee on my desk today....w t h
<abentley> benji: So, it's up on staging, kinda.  http://staging.jujucharms.com/~benji/bundle/wiki/wiki
<benji> abentley: the kinda part being the "Internal Server Error"? :)
<abentley> benji: Yes.  I think it's because your bundle doesn't have a series.
<benji> ah
<benji> I added a series, we'll see how that works.
<benji> I'm confused though because it worked on my local charmworld
<abentley> benji: /home/webops_deploy/charmworld/charmworld/templates/bundle.pt refers to ${bundle.data.series}.  I don't know how it worked on yours.
<benji> abentley: well, I didn't view the page, I was hitting the API with the GUI, but that isn't working on production either so I'm still confused
<abentley> benji: Your bundle isn't showing on production, so that's a separate issue.
<benji> mmm, good point
<benji> I'll try pointing my GUI at staging.
<sinzui> bac: benji, jcsackett : I jot hate mail from charmworld staging: https://bugs.launchpad.net/charmworld/+bug/1234780
<abentley> sinzui: Yes, I triggered it by visiting benji's bundle: http://staging.jujucharms.com/~benji/bundle/wiki/wiki
<benji> yep, we'll have to fix... something so bad bundles won't go down in flames like that
<abentley> sinzui: But there's a separate issue: that bundle isn't appearing on production, even though it's had plenty of time to ingest.
<sinzui> abentley, from when?
<abentley> benji: ^^
<sinzui> benji, abentley we killed a stale proc from before the bad release to get charms ingesting again.
<benji> sinzui: 09:11:01-0500
<sinzui> okay, that is just minutes after we completed. I think the cron or run-forever queuing is broken in production
<sinzui> abentley, I think we just need supervisord running to queue. and cron will ingest about every 2 to 4 times per hour
<abentley> I'm pretty sure cron does the queueing and supervisord manages the ingest.
<abentley> sinzui: ^^
<sinzui> abentley, yep. This is what webops created to make cron happy (i think) https://pastebin.canonical.com/98319/
<abentley> sinzui: Looks sane to me.
<sinzui> I will enquirer about it
<hatch> jujugui call in 10
 * hatch is pretty pumped that he beat Makyo to it today
<Makyo> Whoa whoa whoa.
<Makyo> Coffee is WAY more important than this.
<hatch> rick_h_: so I've noticed that `bzr grep` doesn't give line numbers or syntax highlighting - am I missing a flag or something?
<sinzui> abentley, benji looks like mthaddon found the issue, crontab was manually put in the wrong place in production. He is fixing it
<rick_h_> hatch: no, that's ack stuff. I just open the file and use vim /xxx
<hatch> oh ok, then back to ack it is :)
<Makyo> jujugui call in 2
<hatch> damnnn
<Makyo> Hahaha
<rick_h_> benji: my new desktop env pulled your charm in
<benji> rick_h_: good; I think production is on its way to being fixed
<rick_h_> cool
<Makyo> luca__, ping
<sinzui> abentley, benji : I misspoke. I still have no idea what is not always running to ensure we ingest
<benji> mmm
<luca__> Makyo: heya
<luca__> Makyo: I need to check the upgrade stuff
<abentley> sinzui: You can try running bin/ingest-queued manually to see if the queue's getting stuff.  Remember to set INI and run as ~charmworld.
<Makyo> luca__, yeah, have a sec after daily meeting?
<luca__> Makyo: sure, just ping when your free
<sinzui> abentley, I don't want to manually run. that is what got the last ingest sorted. I want to know what is not runnung
<abentley> sinzui: I was suggesting manually running as a way to determine what's not running.  If the queue is full, then you know that cron is happy.  If it's empty, then you know that it's not happy.
<sinzui> okay, I will ask again if the queue is full
<Makyo> luca__, https://plus.google.com/hangouts/_/9ad52af076c648af1c3c61fcda614bb034cfc336?hl=en
<luca__> Makyo: give me 2 mins :)
<Makyo> luca__, okay
<luca__> Makyo: coming now
<hatch> well I finally had to turn the heat on... 16C is too cold :)
<gary_poster> hey rick_h_ & benji, am I right that this is something we need to address asap? https://bugs.launchpad.net/bugs/1234780
<_mup_> Bug #1234780: Dict has no attribute series <bundles> <charmworld:Triaged> <https://launchpad.net/bugs/1234780>
<sinzui> abentley, I think we will ingest https://pastebin.canonical.com/98468/
<sinzui> abentley, I think queuing via cron is bad
<sinzui> I could ask for a manual queue, wait 15 minutes and verify all it good. then return to the question of why cron is not
<abentley> sinzui: I'm pretty sure I changed the default delay to 1 minute, not 15.
<sinzui> abentley, not on staging and that is where we stole the crontab from
<abentley> sinzui: I meant the default delay for ingest-queued.
<sinzui> oh
<rick_h_>  gary_poster I'm not sure. Do we have the idea of a proof for bundles? this seems like if it's a required attribute then proof/ingest would catch/ignore it
<rick_h_> gary_poster: so I guess yes we should adress but unsure how atm
<gary_poster> rick_h_, doesn't that look like a problem in the charmworld code, not the bundle?
<gary_poster> AFAICT the traceback is saying that the template is trying to look at the data as an object, not a dict
<rick_h_> gary_poster: well, series is expected to exist. The question is, can a bundle not provide it? (reasonable to expect it to always be there) or is it ok to not have and thus the template/charmworld needs to update to deal with the lack of it
<gary_poster> rick_h_, the bundle has a series: http://bazaar.launchpad.net/~benji/charms/bundles/wiki/bundle/view/head:/bundles.yaml
<rick_h_> gary_poster: ah ok then. Yea. 
<gary_poster> rick_h_, but data is a dict, so the code would have to say /series
<rick_h_> strange if it's an issue there it dodn't show befoer
<gary_poster> or ['series']
<gary_poster> cool rick_h_ , thanks.I'll make a card for bug
<rick_h_> gary_poster: cool, will coodinate with benji when he's back around then and peek at the code after I fix up these review changes
<gary_poster> cool
<gary_poster> thank you
<abentley> gary_poster: benji just added the series.
<gary_poster> abentley, oh! so it was what rick_h_ said: bundle had the problem, not code?
<gary_poster> other than proof equivalent needed in charmworld
<abentley> gary_poster: I think series is supposed to be mandatory.   But the error handling could stand improvement.
<rick_h_> gary_poster: yea, I think we had a chat with marcoceppi once about the idea of updating the proof tools to be able to detect or be told to proof using rules for charm or bundle in one command
<rick_h_> and then run proof against both types on ingest 
<gary_poster> got it, thanks abentley and rick_h_ 
<abentley> gary_poster: (Now that it has a series, it's not broken: http://staging.jujucharms.com/~benji/bundle/wiki/wiki)
<gary_poster> gotcha
<abentley> sinzui: successful test run, from creating the container, through running the test suite, to destroying the container.
<sinzui> abentley, there is a fix for that in 1.15.1
<abentley> sinzui: A fix for succcessful test runs?
<sinzui> abentley, sorry. I am in too many places
<sinzui> any I just put my mouth the the production firehose. prod will email me
<rick_h_> abentley: benji is charmworld landing still just mark approved and tarmac comes along and grabs it? I've not been following it lately.
<abentley> rick_h_: It's still just mark approved, but it's all-Jenkins, no Tarmac.
<rick_h_> abentley: ah, very cool. Thanks.
<rick_h_> abentley: hmm, I can't see the "approved" in the drop down for status here? https://code.launchpad.net/~rharding/charmworld/bundle-metadata/+merge/188905
<rick_h_> ah, pending approval to the charmworl developers team. 
<rick_h_> can anyone approve me in please or add the Juju Gui Hackers team? sinzui abentley ^
<abentley> rick_h_: You should see it if you're a member of the branch owner team, Juju-Jitsu Hackers.
<rick_h_> abentley: looking
<rick_h_> abentley: ah, I am not. Asking back in now. 
<rick_h_> will need an ok on that one as well. 
 * rick_h_ is feeling the repercussions of losing super orange powers
 * rick_h_ wonders how benji got to submit 
<benji> rick_h_: that (just mark it approved) is my understanding
<rick_h_> benji: right, but I'm not member enough to have permission to makr it approved
<rick_h_> benji: I only see the options to mark it as WIP, needs review, merged
<benji> rick_h_: hmm, want me to do it?
<abentley> rick_h_: He's a member of yellow squad.
<rick_h_> benji: I'm not seeing you in the group abentley mentioned either though. Chasing the permission chain
<rick_h_> benji: if you don't mind until I get admins to approve my requests to join their teams
<sinzui> rick_h_, I have approved you
<rick_h_> sinzui: thanks
<rick_h_> I'll ask gary_poster to update yellow squad when he's got time. 
<rick_h_> thanks sinzui got it marked approved now. 
<gary_poster> rick_h_, everybody is in yellow.  probably should retire yellow instead but enh
<rick_h_> gary_poster: thanks for the update
<gary_poster> rick_h_, I mean, I added you and everyone else in gui
<gary_poster> welcome
<hatch> rick_h_: is 'editorial' the token list?
<hatch> it feels like it should be the details view?
<rick_h_> hatch: editorial is the default content in the side panel which is the three containers (featured, popular, new)
<rick_h_> they're 'editorial' selected charms to show on page load by default
<hatch> uhh wut?
<rick_h_> hatch: so in the sidebar View you can load two bits of content: editorial content or search results content
<hatch> lol
<rick_h_> which are each a View
<hatch> so editorial is not editorial
<rick_h_> hatch: call?
<hatch> it's the token list
<hatch> sure
<rick_h_> hatch: sure it is, it's three containers (and used to have the listed categories) and such
<gary_poster> hey bcsaller I'm playing around with the visualization via tests and would like to make faster progress.  you have a sec for a hangout?
<marcoceppi> rick_h_: how close are bundles to being ready?
<marcoceppi> I'm planning on pressing a release before cloud sprint, if you'd like that in there I need to know sooner than later
<marcoceppi> also, can someone fill in this guy with a roadmap to being able to use "--to" in the gui? http://askubuntu.com/q/353262/41
<rick_h_> marcoceppi: so we can ingest/show them in manage.jujucharms.com now. hatch will have a details view in the gui next week, and so parts of it will be giong on next week
<rick_h_> marcoceppi: so yea, bundles will be pre-sprint and so bundle support in proof would be greatly appreciated :)
<rick_h_> marcoceppi: for the ask ubuntu gary_poster would have to provide the best answer, but I think it's part of a big chunk of work for 14.04?
<marcoceppi> rick_h_: if you haven't already, I need deets! https://bugs.launchpad.net/charm-tools/+bug/1222833
<_mup_> Bug #1222833: charm tools should proof bundles as well <Juju Charm Tools:New> <https://launchpad.net/bugs/1222833>
<marcoceppi> sample no longer works
<rick_h_> bcsaller: are you a deployer expert to know which all fields are required/optional in a file format? Can you comment in ^^ bug?
<rick_h_> or maybe frankban since I know he did a lot of that in the server bits. 
<gary_poster> marcoceppi, rick_h_ I answered the askubuntu thing.
<rick_h_> gary_poster: thank you. 
<gary_poster> rick_h_, benji is your best bet.  frankban has EoD'd
<rick_h_> gary_poster: right, no hurry. I figured I'd shoot for someone that's used the deployer/messed with that code itself wouldhave the best knowledge 
<gary_poster> cool rick_h_.  thx
<benji> rick_h_: I would have to read the code to see what is required, but I would assume "services" is the only required key ("services" should be made optional by charmworld)
<benji> oops, that second "services" should be "series"
<gary_poster> benji, I'd guess proof could go farther if desired--validating the deployer format generally, yeah?
<rick_h_> gary_poster: yea, one items was to check it's valid yaml/json
<gary_poster> yeah, reasonable
<benji> gary_poster: yep; for one thing, it could check for a bug I have seen, which is relation names not being correct in the bundle (it will obviously need net access to load charm details to do that, though)
<rick_h_> stuff like that I think charmworld can do easier. I'm not sure proof should be online?
<rick_h_> proof doesn't check everything ingest does, but it's a basic linter
<rick_h_> curious what marcoceppi thinks on that part though. 
<gary_poster> marcoceppi, I am making a card for us to give you some details.  how soon do you need them?  and thank you, btw. :-)
<rick_h_> benji: isn't there an issue with setting kwarg defaults to mutable types? Is dict() considered immutable?
<benji> rick_h_: dict() just returns an empty dict, so it is the same (mostly) as using {}, so yeah, you wouldn't want to use that as a default (unless you really do, but still you probably shouldn't because it will confuse people)
<rick_h_> benji: ok, just noticed it in get_bundle_data and hasn't seen dict() used and wondered if it somehow got around the badness of using {}/[] for kwarg defaults
<benji> rick_h_: the "issue" isn't so much a bug or anything like that, it's that people often don't understand default keyword arguments are evaluated when the function is read, not every time it is called, so a mutable default could be changed by the function from one call to another
<rick_h_> benji: rgr, which from a factory method creating different versions seems like a particularly troubled spot to reply on those defaults
<rick_h_> benji: but yea, all good. Thanks for the sanity check. I'll tweak in a drive by in this branch
<benji> rick_h_: yeah, for the code in question it will technically work, but it is an attractive nuisance; I agree that it should be tweaked
<bcsaller> rick_h_: looks like you have that resolved?
<rick_h_> bcsaller: rgr, thanks
<bcsaller> gary_poster: did you still want to chat about the vis stuff?
<gary_poster> bcsaller, yeah, thanks.  1 sec...
<gary_poster> bcsaller, calling on https://plus.google.com/hangouts/_/58de968d2a9ae12f362336b9c9a13fb586d4c581?hl=en
<bcsaller> very odd
<marcoceppi> gary_poster: sooner the better. By Wednesday if you want me to have time to get it in the release
<gary_poster> ok thanks marcoceppi 
<marcoceppi> rick_h_: proof probably shouuld, orange has opened a bunch of bugs about this IIRC
<gary_poster> hey hatch, is your branch working enough for me to use as a basis for playing around with integrating Ben's visualization?  If so, could you push it somewhere and let me know the address?
<hatch> gary_poster: I have 12 failing tests I'm just finishing up now, then it'll be ready to propose
<hatch> so can you give me a few minutes to eval these failures then I'll get back to you
<gary_poster> hatch, cool.  if it is working in qa then I can use it, test failures or no.  so, please push it soon-ish however that turns out
<hatch> oh ok, yeah as long as you aren't going to base any real code off of it, just incase the tests expose changes that need to be done
<hatch> gary_poster: lp:~hatch/juju-gui/bundle-view-url  http://localhost:8888/bundle/~benji/wiki/wiki/:flags:/charmworldv3/ to view
<gary_poster> ok thanks hatch!
<hatch> no problemo
<hatch> I -really- wish I knew why phantom crashes when being run in the foreground
<hatch> it's gota be these 'get' logs
<benji> abentley: please let me know when you have time for a short call about the ingest process and backfilling
<abentley> benji: Okay.  Probably in 30.
<benji> abentley: thanks
<hatch> jujugui could I get a quick review and qa on https://codereview.appspot.com/14355043 thanks
<bcsaller> hatch: pulling it down now
<hatch> thanks
<abentley> benji: I'm free now.
<benji> abentley: ok, one second; I left my camera outside
<hatch> bcsaller: thanks for the review - I'm not really clear on the direction you want me to go with your comments
<benji> abentley: try benjiyork.com/chat
<bcsaller> hatch: sounds like you want to make changes in later branches then and go as is?
<hatch> bcsaller: yeah I want to try and do atomic changes and work towards the final goal - I think the reviews/qa's will be easier this way
<bcsaller> then I'll +1 it
<abentley> benji: I get a black screen that says "Initializing..." with Firefox
<benji> abentley: ok; I'll create a hangout then
<abentley> benji: Chrome works.
<abentley> benji: Or at least it says Connecting... and shows my face.
<hatch> bcsaller: cool thanks
<hatch> gary_poster: I'm going to be submitting that branch now just FYI
<gary_poster> cool hatch thanks!
<gary_poster> I'm playing with integrating.  I'll put my face on the card.
<hatch> Makyo: Loving OneTab :) thanks for the tip
<Makyo> Yeah!
<Makyo> It's not perfect, but it's a pretty good grouping solution to cut down on memory footprint from multiple windows.
<hatch> yeah I have 54 windows in it right now haha
<hatch> tabs*
<Makyo> Yeah.  It's also kind of neat that you can restore one, or a whole group, or publish the list.
<Makyo> Oh, so these aren't battery crashes.  23 LXCs crashing the machine.
<Makyo> BEcause I'm not destroying machines.
<bcsaller> ouch
<Makyo> I have everything tuned way down to try and increase battery, though, so I guess it's both.
<hatch> lol
<abentley> sinzui: Complete test run in lxc: http://162.213.35.27:8080/job/charmworld-autoland-lxc/lastBuild/
<gary_poster> bcsaller, good news is that I have it working.  (we do need fakebackend, it turns out, to load bundle into db).  Not as good news is that the one good bundle we have doesn't render very well.  I suspect that the root cause is that the bundle does not have x-y annotations.  The symptoms are that I see a lot of errors trying to draw relation lines ('Invalid value for <line> attribute y2="NaN"') and I only see a single
<gary_poster>  charm (because they are all on top of one another. So...
<bcsaller> gary_poster: wp-deployer? I thought that did have annotations, we even test the positions
<bcsaller> oh... from the store
<bcsaller> yeah...
<bcsaller> there isn't really any auto layout
<bcsaller> the assumption being these things will be placed, but thats an area to work on for sure
<gary_poster> so a few options/things to consider...
<gary_poster> (1) we can ask marco to enforce that bundles have x-y coords
<abentley> benji, rick_h_, sinzui, jcsackett: I'm switching over to doing the landings with testing "make sysdeps".  (by using an lxc).  Sorry in advance for any bumpiness.
<gary_poster> that will probably be the cheapest option and a reasonable short term solution
<gary_poster> (2) auto layout
<benji> abentley: so it will be a "fresh" system each time the tests are run?
<gary_poster> maybe there are only two ;-)
<abentley> benji: Right.
<benji> very cool
<bcsaller> gary_poster: well... auto layout is a spectrum 
<gary_poster> fair enough
<bcsaller> we could pack them like we do now but the layouts are un-attractive 
<gary_poster> bcsaller, if we can do a "it doesn't fall over" story for this case it would be a win
<gary_poster> but bcsaller I think we ought to say that #1 is required.  WDYT?
<gary_poster> that way all bundles from store at least will be ok
<bcsaller> #1 +1
<gary_poster> although
<gary_poster> we should have a nice story for loading
<gary_poster> bcsaller, does the "drag file on GUI" import story work for deployer files again?
<hatch> rick_h_: any chance you are about to land the token bundle click branch?
<bcsaller> they are supposed to capture additional human thinking about a deployment and position conveys some information 
<bcsaller> gary_poster: it works with things like test/data/wp-deployer.yaml that have a single import target
<bcsaller> gary_poster: otherwise you need the bundle target name and a UI to select it
<bcsaller> but if you provide that it works that way too
<gary_poster> bcsaller, 'cause if so, then we could enforce #1, and say "to add position information, go to jujucharms.com, import, and the export".  But yeah, that's not good enough for the multiple bundle story :-/
<gary_poster> that is...
<bcsaller> gary_poster: but that isn't really how the store will expose them anyway, right?
<gary_poster> even if we build the UI to choose which bundle you want...
<bcsaller> they index and return as singles?
<gary_poster> bcsaller, yes, but the point of aggregation was to make it easier to develop deployer files with multiple bundles--that is, to support the inheritance story in order to encourage better maintainability of similar bundles
<gary_poster> if you inherit
<gary_poster> then the import/export story is broken
<gary_poster> unless we allow you to import, choose bundles one at a time and position, and then export together
<bcsaller> our fake importer should support it, but yeah, still no ux
<gary_poster> well, no
<bcsaller> and for export, it only does a single 
<gary_poster> bcsaller, I'm not expressing myself well.  I blame my sleep condition. :-) Can we try a hangout very quickly?
<bcsaller> sure
<hatch> :/ I would really like to figure out what's up with the CI
<gary_poster> hey benji you around?
<gary_poster> bcsaller, Makyo, hatch I am not going to make it to tonight's Australian call.  I will update calendar.  Sorry about that.
<Makyo> Alright.
<Makyo> Feel better!
<gary_poster> Thank you Makyo 
<benji> gary_poster: yep
<gary_poster> benji, yay.  Could you do the following quickly?  (1) go to jujucharms.com (or comingsoon) (2) drag the file of your official bundle into comingsoon
<gary_poster> (3) position the services
<gary_poster> (4) export it again
<gary_poster> (5) push to your branch
<gary_poster> the idea is that then you will have position information for your services
<gary_poster> which will make rendering the bundle much better
<gary_poster> *and...*
<gary_poster> jujugui, esp people working on bundle bits, you might be interested in my comment #3 of https://bugs.launchpad.net/charm-tools/+bug/1222833
<_mup_> Bug #1222833: charm tools should proof bundles as well <Juju Charm Tools:New> <https://launchpad.net/bugs/1222833>
<benji> gary_poster: well, the flag doesn't seem to "take" on jujucharms.com, but I can do it locally (I wonder if that is a bug, maybe something to do with the rewrites)
<gary_poster> benji, you mean annotations don't carry over
<gary_poster> if so, another thing we have to fix
<benji> gary_poster: nope, I mean that my bundle doesn't show up in the search, presumably because the flag is being ignored
<benji> gary_poster: but, indeed, the annotations are not included in the export I just did
<gary_poster> benji, pastebin it for me pls?
<benji> gary_poster: http://paste.ubuntu.com/6189871/
<gary_poster> bcsaller, ^^^
<benji> (the raw export has some other issues too, but I assume those are known)
<gary_poster> benji, only issue I saw was js undefined.  others?
<benji> gary_poster: yep, that's the one I was referring to
 * bcsaller checks, I thought we had tests around that and that file came from an export
<bcsaller> hmm, I'll look into this, I don't see the annotations either
<bcsaller> and I suspect why
<rick_h_> hatch: no, the one branch landed and I'm workingin charmworld for a bit
<rick_h_> benji: do you nkow how to get access to the jenkins results? Looks like I've got failing CI tests?
<rick_h_> benji: https://code.launchpad.net/~rharding/charmworld/bundle-metadata/+merge/188905/comments/433299
<hatch> rick_h_: ok do you have anything I can use? Or can I just implement it?
<rick_h_> abentley: oh ok, so maybe my failures are results of changes going on then?
<rick_h_> hatch: kind of. Where are you headed atm?
<benji> rick_h_: I have done it but don't remember much about it.  The main thing is to set up a VPN into its private world, then those 10.xxx.xxx.xxx URLs will actually go somewhere
<benji> the VPN setup is documented.... on the wiki?
<hatch> rick_h_: well if it's not that then I'll continue on with the bundle view stuff
<rick_h_> ugh, ok. I'll look for that then. vpn to the QA lab bits?
<abentley> rick_h_: Yes.  I've given up for the day and switch back to not testing "make sysdeps".  Just making sure your branch lands.
<hatch> but would like to keep this moving forward and not clash with bcsaller stuff
<rick_h_> abentley: ok, looks like it failed a few times but no helpful info in the note.
<rick_h_> hatch: call?
<hatch> sure
 * Makyo -> dogwalk
<abentley> rick_h_: Sure there was info.  One of them points out that you didn't enter a commit message.  The rest link to the actual failed builds so that you can see exactly what happened.
<rick_h_> abentley: right, thanks for the commit message. 
<rick_h_> abentley: I mean the failures give the link but I've got to get the QA vpn notes to get that info. I'll work on that. Thanks
<gary_poster> bcsaller, when I drag a file with the contents from http://pastebin.ubuntu.com/6189887/ onto the GUI sandbox, I get "Deployer Import Unsupported
<gary_poster> Your environment is too old to support deployer file imports directly. Please consider upgrading to use this feature."
<abentley> rick_h_: No you don't.  It's a public IP on canonistack.
<gary_poster> am I doing something wrong?
<rick_h_> abentley: oh, it must have shut down. It's merged now
<abentley> rick_h_: Oh, wierd.  Sometimes it's using the public ip, sometimes the private.
<rick_h_> I swear I was just looking at it
<abentley> rick_h_: Anyhow, congrats on landing revno 404
<rick_h_> abentley: woot
<abentley> rick_h_: The public site is http://162.213.35.27:8080/
<abentley> rick_h_: I'll have to see what IPs it's dropping in the merge proposals later.
<bcsaller> ok, so QA issue one,  manually doing a wp/mysql pair and moving them and then in the console, app.db.services.get('annotations') gives me two empty objects so that appears broken
<bcsaller> I'm looking at the import issue now
<rick_h_> abentley: ok cool thanks. Glad tests passed, I got nervous with failed CI runs
<gary_poster> bcsaller, could you make "urgent" cards for what you find and tackle 'em?
<bcsaller> gary_poster: that file imported for me with trunk
<gary_poster> bcsaller, you just drag the file on, right?
<bcsaller> gary_poster: are you using api3 flag? I wasn't
<gary_poster> bcsaller, did you try comingsoon?  I was trying that, and normal jujucharms, without api3 flag
<gary_poster> will try trunk
<bcsaller> gary_poster: yes, dnd, import with successful notification
<gary_poster> k
<gary_poster> bcsaller, confirmed.  it works on trunk locally, but not on comingsoon or jujucharms for me
<bcsaller> neither the gui db or the fakebackend have position annotations on the service models, something is wrong there, the export code should still pick them up at a glance though
<bcsaller> wonder how we introduced a bug here w/o seeing it in the tests :(
<bcsaller> I will add a card and start on it though
<gary_poster> thanks
<gary_poster> g'night all
<gary_poster> hey hatch
<hatch> ahoy!
<gary_poster> could you ask huw to look at the styling of the bundle detail pages we have now
<gary_poster> and change/style your page accordingly?  also
<hatch> sure thing
<gary_poster> I'm heading out
<gary_poster> but
<hatch> yeah no problem
<gary_poster> thanks!
<hatch> get better!
<gary_poster> if you want to play with the bundle vis yourself, and take over, here's what I did
<gary_poster> lp:~gary/juju-gui/bundle-detail-view-2
<gary_poster> it works nominally
<gary_poster> but we need position annotations for the canonical example we have to not look horrible (with broken relations and charms on top of one another)
<hatch> cool will look
<gary_poster> I don't know what to do with it.  if you have any ideas, hatch, go for it.  test? land?  I dunno. :-)
<gary_poster> thanks!
<gary_poster> ttyl
<hatch> cya!
<hatch> morning huwshimi
<huwshimi> Morning
<hatch> so gary isn't feeling well so he cancled our meeting, but would like you to change/style the bundle detail pages which can now be accessed in the application
<huwshimi> hatch: Sure I can take a look at that.
<huwshimi> hatch: Is it in trunk but not on comingsoon?
<hatch> ok so on a fresh trunk you will need to use the url to access them directly so that is.... http://localhost:8888/bundle/~benji/wiki/wiki/:flags:/charmworldv3/
<hatch> and you'll need to change to the staging charmworld in your config-debug.js file
<hatch> as per benji's email "Working bundle for developing visuals"
<huwshimi> Ah I see
<hatch> I'll be around so if you have any trouble getting that going I can help
<huwshimi> hatch: Do you know if the tabs are supposed to work yet?
<huwshimi> The only thing wired up appears to be the name...
<hatch> right that's all that is wired up so far
<hatch> I'll get you the link to the mockups
<huwshimi> hatch: Oh, well not really anything I can do then yet :)
<hatch> https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1d3VVX0FFVEJ3S2s
<hatch> well you could hook the stuff up :)
<hatch> it's all changes in the markup
<hatch> the data is being passed to the template
<hatch> you can see it in subapps/browser/views/bundle.js
#juju-gui 2013-10-04
<gary_poster> hey huwshimi.  only here for a sec
<gary_poster> did what Jeff say make sense?  You can get everything working now, I think.  just give us ids to fill
<gary_poster> you saw those markups Jeff gave you?
<gary_poster> I mean mockups
<gary_poster> ok huwshimi, I hope it does. :-) We are really behind on the bundles and it would be really wonderful to have the pages hooked up and ready for content
<gary_poster> so if you can do it today, that would be really appreciated.  if you make progress and can hand it over to someone for tomorrow that would be fine too
<gary_poster> and of course if you are in the middle of something then tie that up first.
<gary_poster> I'm disappearing again.  Thanks and sorry I messed you huwshimi 
<gary_poster> heh missed
<huwshimi> gary_poster|away: Oh, sorry Gary
<huwshimi> Guess I'm a couple of minutes too late
<hatch> *yawn*
<benji> good morning frankban 
<frankban> hi benji 
 * benji need coffee.
<benji> [that typo is evidence of said need]
<frankban> :-)
<frankban> luca__: is there a way to use the style framework offline? i.e. everything works well when you load the css from http://assets.ubuntu.com/sites/guidelines/css/latest/ubuntu-styles.css. but if you download it to serve it locally it is unable to find absolute resources, e.g. /sites/ubuntu/latest/u/img/logos/logo-ubuntu-grey.png
<luca__> frankban: Heya, I'm not sure, I'll get Ant to get in touch.
<rick_h_> oops, team changes yesterday gets me juju core code review messages. boom goes the email
<benji> gary_poster: I hope you're feeling better.
<gary_poster> benji, yeah, thanks, much better.  slept mostly through the night.  My best guess is that the dizziness was largely caused by me taking aleve as a painkiller.  When you haven't taken it before or for a long time it can cause dizziness the first few times
<gary_poster> (I read)
<benji> wierd, I hadn't heard that
<rick_h_> that the naproxin stuff right? /me isn't up on drugs, let's the wife do that
<gary_poster> rick_h_, yeah
<rick_h_> ah yea, I've got some prescription strength levels of that for my headaches. It can mess you up a little bit. 
 * benji makes another cup of coffee and considers spiking it with naproxin.
<gary_poster> :-)
<rick_h_> hah
<rick_h_> benji: got a sec to chat this morning?
<frankban> and local provider is working again! (juju-core trunk + raring)
<rick_h_> frankban: woot
<benji> rick_h_: sorry, I was AFK when you messaged and just noticed; sure; benjiyork.com/chat again?
<rick_h_> frankban: looking at the deployer docs and such I don't see that it supports specifying a charm version?
<rick_h_> benji: yea, appreciate it
<rick_h_> hmm, hoped it might work in FF nightly
<rick_h_> but stuck on init
<frankban> rick_h_: I am not a deployer format expert, but can't you do that e.g. with charm: "cs:precise/wordpress-15"?
<gary_poster> frankban, lp:~juju-gui/juju-gui/redirect-server is freakin' awesome so far...still looking. :-)
<frankban> gary_poster: thanks! I also updated the html/css bits to make it less ugly
<gary_poster> cool
<rick_h_> benji: frankban thanks for the hints. It looks like I need to dupe http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/charm.py#L43 to figure out what charm is referenced
<gary_poster> hey frankban.  when you have a chance, please take a look at https://docs.google.com/a/canonical.com/document/d/1Dk2hqIyxficLVU5oMwylFEkDTlcvSHzVLtiaMZIpYlc/edit?disco=AAAAAGu4cFw#heading=h.147n2zr (this is company internal until release).  I'm going to offer that we can try to make the behind-a-firewall story much better by including tarball and dependencies for default install, if it means we can get it done in ti
<gary_poster> me to change the paper.  would like to talk to you about it later today
<frankban> gary_poster: ack will look
<gary_poster> thanks
<gary_poster> frankban, hey.  I have trivials (http://paste.ubuntu.com/6192310/) plus would like to talk through what would be necessary for blocking.py to give gradual status messages
<gary_poster> frankban, lemme know when you are available and let's have a quick call
<frankban> gary_poster: now is ok, or if you want I'd have a quick look to the doc you linked and then ping you
<abentley> benji: due to what appears to be a massive bug in the Jenkins charm, charmworld landings are temporarily disabled, because THE JOB HAS BEEN DELETED.  I'll be working on fixing this.
<benji> abentley: yow
<rick_h_> abentley: benji can we have branches that don't end in trunk as the branch_spec in charms in charmworld?
<rick_h_> abentley: doh on the deletion
<benji> rick_h_: nope, they are skipped at injest time
<rick_h_> benji: yay! /me auto adds + '/trunk' to the branches
<abentley> rick_h_: No, we can't.  We used to accept "trunk1" in some places, but that's been removed now.
<gary_poster> frankban, sorry had to step away.  yeah, take a look at the doc then let's talk
<rick_h_> note to self, do not [d for do in db.charms.find()] or else your terminal will hate you
<benji> rick_h_: do we have to do that?  I'm afraid that violating the DRY priciple that way will hurt us later.
<rick_h_> benji: I'm trying to find some way. the branch urls are just lp:charms/precice/mysql. All the branch info is ~charmers/precise/mysql/trunk
<rick_h_> benji: there's a 'short_url' which seems like it might work, but it changes if the owner is part of the path based on promulgated or not
<benji> rick_h_: I thought we were going to require cs: URLs for now
<rick_h_> benji: no, based on that deployer code I linked above, it parses out both options
<rick_h_> http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/charm.py#L43
<frankban> gary_poster: I think I got the point (dependencies from juju-gui ppa and GUI release tarball from launchpad). ready when you want
<gary_poster> frankban, https://plus.google.com/hangouts/_/09f0eba2a4a142cec1a74248752179060763c265?hl=en
<rick_h_> benji: it actually does even more. If the charm is just mysql and there's a series in the bundle then it builds the charm as promulgated version of precise/mysql and latest rev
<rick_h_> benji: http://paste.mitechie.com/show/1028/ is not complete but what I'm looking at atm 
<benji> rick_h_: right, I know the deployer can do more, but we can suport a subset of the charm identifiers allowed to start with (as we support a subset of other deployer features already)
<rick_h_> benji: I geuss it seems we'd have bad visuals if we don't support what's out there currently? I didn't realize it was a real option. 
<benji> everything is an option
<rick_h_> hah
 * benji is hit over the head with the zen master's walking stick.  The zen master says, "I'm glad to know that was an option."
<benji> rick_h_: there is definately a tension between supporting everything the deployer does and wrapping ourselves around an axle just to support every nook and cranny
<benji> My point is that if we get something working, expanding that is better than taking forever to get everything working (and not allowing ourselves the option of leaving unimportant bits out).
<hatch> so.....has anyone else started to get a TON of emails?
<rick_h_> benji: understand, but I'm looking at "make these deployer files 'work' and they're doing this stuff 
<benji> rick_h_: where did you get the deployer files?
<rick_h_> benji: so yes, the cs: from this morning helps, and I'm about got it working. 
<rick_h_> will try to cut bait and finish up what I do have that should work. 
<rick_h_> benji: the ones in charmworld now. They're in the production manage.jujucharms.com. Those api calls are what I am working with. 
<rick_h_> that's why I was using bac's one. It's passed proof/lint/anything else charmworld should reject, except I'm finding it's not the whole story
<rick_h_> so learning as I go this morning
<benji> rick_h_: ok, just note that the three bundles I am aware of were just made up on the spot, so its not like they are real bundles people are using
<rick_h_> benji: right, but they should follow charmworld expected rules of bundles. They're what are getting sent to the Gui to develop the bundle front end. 
<rick_h_> benji: it's what we're desiging everythign in the gui around 
<abentley> benji, rick_h_: landings should be working again.  The issue was caused by an incompatible plugin.
<rick_h_> abentley: awesome, thanks!
<benji> rick_h_: I just don't want you to be trapped.  We don't do any validity checking of bundles and the few we have were made up, so the fact that a bundle is in the DB means nothing.  It may be that we should be adding gates instead of supporting the garbage we've let in thus far.
<benji> abentley: good to hear
<benji> (the working part, not the incompatability part)
<rick_h_> benji: understood. That's what I'm learning. It's why I went to the deployer source code to see what is going on and worked from that.
 * abentley did not think that was a potential side effect of jenkins plugins.  He was wrong.
<gary_poster> hatch, with great power comes great quantity of emails :-P
<hatch> lol
<hatch> rick_h_: I thought you would be interested to know that I have fixed the colours on my laptop console by removing zsh
<hatch> something between the skins and zsh caused it to go wako
<Makyo> While I'm glad our product seems a little unbelievable, I got a comment on the openstack deployment vid to prove that it can be done and I wasn't just messing around in a sandbox. Do we have anything for that, or should I, like, try to do it in LXCs?
<hatch> Makyo: is this a youtube comment?
<Makyo> Of course :P
<hatch> ok then there is only one reply "go %#$@!% yourself"
<hatch> thats how they talk
<hatch> it's not vulgur there
<hatch> lol
<Makyo> Hah!
<hatch> cultural differences and all that
<Makyo> It was polite enough! "It would be great if you also could post the post openstack running and configurations.... just a proof that it works."
<Makyo> If I can do it in in LXCs, I can try, but if we already have docs on this, that'd be great.
<Makyo> Not sure who to ping?  jcastro? evilnickveitch?
<hatch> ohh haha
<gary_poster> Makyo, did you get luca__'s ok on the upgrade charm UX?
<luca__> gary_poster: yes, a small text amend but it looks good
<Makyo> gary_poster, UX is fine, I have some quick style changes to make.
<gary_poster> and hgi :-P
<gary_poster> luca__, Makyo awesome! thanks!  will be great to get out next week
<gary_poster> Makyo, added card :-)
<Makyo> gary_poster, oh, cool, thanks.
<jcastro> the one on the homepage is real
<Makyo> Should be quick.
<jcastro> it won't work on LXC though
<Makyo> jcastro, alright.  Yeah, that video is the one with the comment.
<hatch> jujugui call in 10
<gary_poster> foiled again!
<Makyo> I've got a bunch of Dell d600s downstairs.  Maybe I could set those up as a cloud.  40gb drives, 1g ram, 700mhz processors, no batteries...
<hatch> mohohahahaha
<gary_poster> :-) thanks
 * hatch hands Makyo http://www.bestcars2014.info/images/car-battery-2.jpg
<abentley> benji, rick_h_, jcsackett: I've restored "make sysdeps" testing via LXC for landings.  Let me know if you have any issues.  (And if it doesn't land or reject it within 10 minutes of clicking "Approve", that's an issue.)
<rick_h_> benji: can you jump on stand up a sec early so I can ask a bundle model ? please?
<rick_h_> abentley: rgr, thanks for the heads up
<benji> rick_h_: sure
<Makyo> hatch, I'd like to see the adaptor for a laptop to a car batter :P
<hatch> lol
<jcastro> Makyo: you could link to the bundle
<jcastro> Makyo: jamespage can tell you which one to exactly link to. 
<jcastro> but for the next video we should do some post-install stuff to prove it's running
<jcastro> like quickly deploying something on top and showing it working, etc.
<Makyo> jcastro, yeah, I agree.  We need to do more, now that the inspector's up, as well.  I'll do a quick one this weekend for a simple wordpress install or something.
<hatch> I wana do one too.....uhhhhh
<hatch> *whines*
<gary_poster> jujugui for weekly call, I'm hoping to go through discussion quickly, and then move to bundle coordination discussion
<gary_poster> hatch, you can make one too :-)
<hatch> haha
<gary_poster> jujugui call in 2, btw
<Makyo> Go ahead :P  I just use audacity for audio, recordmydesktop for video, and kdenlive for mixing.
<hatch> lol, maybe I'll do it in OSX?
 * hatch ducks
<Makyo> I may do audio on the MBA in the future.
<hatch> might be able to use ScreenFlow in OSX to record the vm in fullscreen
<evilnickveitch> hatch, Makyo, if you are recording videos, remember people need to be able to make out what's going on at the size they play them back!
<Makyo> evilnickveitch, hehe, alright, will do better about that :)
<hatch> evilnickveitch: do you know of a quality screen recorder for Ubuntu?
<rick_h_> gtkrecordmydesktop is the thnig I've used
<hatch> so that's a no....:P
<Makyo> hatch, it's really easy.  You select the window you want to record, and hit record :P
<hatch> haha yeah but then there is all the audio, webcam, audio, editing, etc
<evilnickveitch> hatch, sadly recordmydesktop is the most reliable for ubuntu
<Makyo> It'll do audio.  Why do you need webcam?
<Makyo> I only do editing in kdenlive because I used an external mic.
<evilnickveitch> It does audio (but make sure you test it!)
<Makyo> Because it's nicer :P
<hatch> yeah I think I'll buy ScreenFlow in OSX and see if it'll capture the VM nicely
 * Makyo shrug
<hatch> http://www.webupd8.org/2013/06/simplescreenrecorder-powerful-screen.html looks like it has some nice features
<hatch> gary_poster: with your branch did you get 36 errors from d3?
<gary_poster> relation errors?  if os, yes
<gary_poster> so
<hatch> ok yes they look like it - it also only displays a single charm (mysql)
<rick_h_> benji: did we still need to chat then on whatever we started with? 
<benji> rick_h_: I don't remember what we were talking about
 * benji prepares to be informed.
<rick_h_> how to add my bits to the bundle model in a way that doesn't suck
<rick_h_> and if they need to be added at all I guess
<rick_h_> I'm tempted for a first pass to just build my dict manually before calling json_response vs handing json_response the Bundle object and work around it all atm
<rick_h_> and then see where we end up when ingest needs to get updated for some of this stuff
<benji> rick_h_: ok, hangout?
<rick_h_> benji: sure
<benji> rick_h_: darn, I clicked "ignore"
<benji> rick_h_: what is the URL?
<rick_h_> https://plus.google.com/hangouts/_/7f679d12f867648c21aba4729b2e67e6d4b0e649?hl=en
<bcsaller> gary_poster, hatch: what was the resolution on the fakebackend in vis talk? sorry I had to duck out for that other call
<hatch> still ongoing
<gary_poster> hey marcoceppi, would like to talk about bundle proof with you (bug 1222833).  I need a break/lunch, but you available sometime in the afternoon to talk?
<_mup_> Bug #1222833: charm tools should proof bundles as well <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1222833>
<marcoceppi> gary_poster: yeah
<marcoceppi> gary_poster: I'm available in the next 30 mins
<marcoceppi> gary_poster: just ping me when you're back
<benji> nothin like a little lunch-time pressure-washing to clear your head
 * rick_h_ is jealou, I want to get a pressure washer
<rick_h_> jealous that is
<rick_h_> I was looking at them and low pressure wands for helping to wash the camper
<benji> rick_h_: I borrowed this one from my parents; I bet they would let you borrow it
<rick_h_> lol, sure thing. I'll send UPS down in a minute to get it
<rick_h_> benji: nice one? /me was debating how big/etc to go. They're kind of $$ tools
<benji> rick_h_: middle of the road: decent briggs and stratton engine, pretty high pressure, three swappable nozzles, and a cleaning solution vacuume thingie for oil stain cleaner
<rick_h_> benji: any good names for "find me a charm by using these bits to figure out which one I really want"? 
<benji> candiates: find_charm, search_for_charm, find_matching_charm, resolve_charm
<rick_h_> benji: resolve, I like that. resolve_charm_from_bundle_info
<benji> sounds good
<gary_poster> marcoceppi, sorry was lunch plus walk :-) lemme know when/if you are available
<marcoceppi> gary_poster: I'm avail now
<gary_poster> making hangout...
<gary_poster> marcoceppi, https://plus.google.com/hangouts/_/4113610a552d0e523218cf29ecd65bfb2e92d888?hl=en
<hatch> Makyo: do you need a review?
<Makyo> hatch, yeah, sorry, eating.  If you could, that'd be great
<hatch> will do
<rick_h_> benji: nothing bad about me manually keeping store_revision and revision in sync? building factory test data?
<rick_h_> benji: there is 'one true' revision these days now that we support revisions? The store one?
<rick_h_> bah, so I shouldn't be searching on the revision field, the store_data.revision field
<benji> rick_h_: there are three revisions, the bzr revision from the branch, the charm revision from the file on disk, and the charm store revision (an auto-incrementing number)
<rick_h_> benji: right, so the /precise/mysql-13 is the store_revision value right?
<benji> exactly
<hatch> check this out https://www.flowdock.com/ it allows you to chat down the right side (with IRC integration) and your 'activities' happen on the left - things like commits, reviews etc
 * Makyo dogwalk
<gary_poster> hey hatch, what's the url for seeing the existing working-ish bundle again?
<hatch> gary_poster: /bundle/~benji/wiki/wiki/:flags:/charmworldv3/ sorry I didn't see the ping
<gary_poster> thanks hatch np.  have a great weekend
#juju-gui 2014-09-29
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey
<rick_h_> woot! crossed 2k views! https://www.youtube.com/user/celebrateubuntu
<huwshimi> :)
<huwshimi> rick_h_: The release seems to have gone well :)
<rick_h_> huwshimi: yea, so far. Kind of more quiet than I expected, but we'll see.
<rick_h_> 2k views but no comments and 5 thumbs up last time I looked heh
<rick_h_> and no comments on any of the blog posts or reddit share 
<rick_h_> heh, ugh AVERAGE VIEW DURATION 1:42
<rick_h_> Makyo: has it beat AVERAGE VIEW DURATION 1:55
<rick_h_> morning 
<lazyPower> morning rick_h_
<rick_h_> morning lazyPower 
<lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1375251
<mup> Bug #1375251: Juju gui malforms display with missing x/y coordinates on existing env w/ charm upgrade <juju-gui:New> <https://launchpad.net/bugs/1375251>
<lazyPower> if there's any additional info you need feel free to ping me. This env is long-standing.
<jcsackett> good morning jujugui. can i get reviews on https://github.com/juju/juju-gui/pull/589 and https://github.com/juju/juju-gui/pull/588, please?
<kadams54> jcsackett: taking a look
<jcsackett> kadams54: thanks.
<jcsackett> hatch: you're kill-mv branch bounced off the lander. :/
<jcsackett> s/you're/your/
<jcsackett> hatch: sauce is showing several failures that look valid, which is disturbing since it passed CI.
<rick_h_> frankban: I've got the node entered and it's 'commissioning'
<rick_h_> not sure how long this takes, will start to enter the second node and see how it goes
<frankban> rick_h_: yeah I see, great
<rick_h_> frankban: it mentions 'a properly configured dhcp server' can you figure out how to check if the maas install set up dhcp correctly or if there's something else to do?
<frankban> rick_h_: there is a maas-dhcp-server upstart, but it says it's stopped
<frankban> rick_h_: service maas-dhcp-server status
<frankban> will take a look
<hatch> jcsackett: yeah they are all 'real' failures
<jcsackett> hatch: whoo.
<jcsackett> hatch: this flag is a real bear.
<hatch> I'm going to have to go through the entire test suite and fix every instance of env creation
<jcsackett> hatch: you, me, and rick_h_ should talk, b/c the env/go.js updates have a similar issue.
<hatch> well I would like to get this landed before any more go
<hatch> it touches so many parts of the app
<frankban> rick_h_: also note that "apt-get upgrade" shows lots of maas related packages ready to be upgraded, including maas maas-cli maas-cluster-controller maas-common
<frankban>   maas-dhcp maas-dns maas-region-controller maas-region-controller-min
<frankban> not sure we want to do that
<rick_h_> frankban: oh yea probably should. This install is a bit old
<stokachu> rick_h_, http://paste.ubuntu.com/8458814/ line 108, have you or anyone else run into this issue before?
<jcsackett> hatch: i'm happy to coodinate landings and block on you getting yours done, but i would still like to chat if you've got a moment?
<rick_h_> stokachu: lookihng
<rick_h_> stokachu: yes! we got that in one of our upgrades. We had to manually remove the directory I think. 
<jcsackett> hatch: b/c i'm not entirely the best update for the env/go.js issue. :/
<rick_h_> stokachu: are you in a position to destroy/reploy the services? Is this on an upgrade?
<jcsackett> s/i'm not entirely/i'm not entirely sure of/
<stokachu> rick_h_, yea we could do that
<rick_h_> stokachu: was this a charm upgrade? 
<rick_h_> just to help us narrow down and make sure it's something like what we've seen before? Or an initial deploy?
<hatch> jcsackett: yeah sure just 2 mins, can't get the camera to work
<jcsackett> hatch: dig; i'm chilling in the standup chat.
<stokachu> rick_h_, this is a fresh deploy
<stokachu> new bootstrap and everything
<rick_h_> stokachu: oh, then no I've not seen it. 
<rick_h_> stokachu: /me digs into that log more
<rick_h_> hmm, same error though...what kind of race can there be there ugh. 
<rick_h_> stokachu: will file a bug and start looking into it closer. Thanks for the traceback/log
<stokachu> rick_h_, thanks man really appreciate it
<stokachu> rick_h_, one thing that may help reproduce it is to run the deploy and let it sit for a few hours
<stokachu> and then issue another service deploy to trigger that config-changed hook
<stokachu> see if fails then
<rick_h_> stokachu: so you've got juju deploy juju-gui and then another command later?
<stokachu> rick_h_, yea like a relation join that triggers this config-changed hook
<rick_h_> stokachu: gotcha, ok thanks!
<rick_h_> stokachu: have added notes to #1373875 and will update there when we can replicate/thing we have a fix. 
<stokachu> rick_h_, awesome thank you
<frankban> stokachu: did you pass any specific options to the GUI?
<stokachu> frankban, just a plain juju deploy
<stokachu> no constraints etc
<stokachu> rick_h_, that a private bug?
<frankban> stokachu: what triggered the config-changed hook at line 108?
<rick_h_> stokachu: yes, it was started by IS when we hit the one upgrade snag
<stokachu> rick_h_, gotcha
<stokachu> frankban, we think it was mysql doing a db-relation-changed against nova-cloud-controller
<stokachu> and seemed that juju-gui randomly errored then
<rick_h_> frankban: sometimes config-changed is run by juju and I think there's a missing safety check there or something
<stokachu> yea i dont know the rules in which config-changed gets triggered but i seem to recall it gets trigger by a lot of events
<stokachu> related or not
<frankban> rick_h_: I see, I think we should just manually remove the symlink before re-creating it
<rick_h_> frankban: rgr
<rick_h_> frankban: probably easiest/safest 'always will work' hack
<jcsackett> rick_h_: so, do you mind if maintenance is temporarily super saturated? we have *many* branches in play for kill-mv-flag and i'd rather not group them into the one card as we're closing in on done.
<jcsackett> jujugui: can i get one more review on https://github.com/juju/juju-gui/pull/589 and https://github.com/juju/juju-gui/pull/588 ? both are relatively small and QA is already done (thanks kadams54!)
<rick_h_> jcsackett: rgr, ok. As long as we can get it cleaned out during the day today
<jcsackett> rick_h_: dig.
<jcsackett> hatch: is notifier on IE a legit, or is that one that fails randomly? https://saucelabs.com/jobs/7fb5041fe9c44ec68b8636e981f659cc 
<hatch> looking
<hatch> that's spurious
<hatch> notifier tests are async in a synchronous world :)
<Makyo> jujugui call nowish.
<rick_h_> bqh
<rick_h_> bah
<kadams54> whoops, be there in a jiff
<hatch> jujugui anyone know if you can buy sim cards in the airport in brussels?
<rick_h_> hatch: so I saw a thing that there's a phone rental store in the airport for it
<bac> hatch: dunno.  i'm curious too
<rick_h_> http://www.brusselsairport.be/passngr/shops/airport_terminal/shopping/5253/
<rick_h_> jujugui ^
<bac> hatch: spain and france are horrible for getting SIM cards.  :(
<hatch> cool thanks
<hatch> stepping out to grab a coffee bbiab
<frankban> guihelp: I need reviews for https://codereview.appspot.com/147360043 . anyone available? thanks!
<rick_h_> frankban: do you know much about debugging upstart scripts?
<hatch> ugh this branch is so frustrating
<hatch> lol
<frankban> rick_h_: I am not an upstart expert, but logs should go to /var/log/upstart/<name>.log
<rick_h_> frankban: yea, they're not which is the fun part
<frankban> :-/
<frankban> rick_h_: which upstart job are you trying to debug?
<rick_h_> frankban: the maas-dhcp-server is not starting
<rick_h_> frankban: I found some cases of old ip addresses and worked past a couple of issues in the setup
<rick_h_> frankban: and now stuck on that one, I've gotten it configured, and it should work from what I can tell, but no log output about why it's failing to start
<rick_h_> frankban: and the upstart script will need to be picked apart a bit to manually run/process and try to figure out what it's unhappy about
 * rick_h_ goes to make up some lunch
<hatch> kadams54: still need someone to look into this? I'm sending off another test run
<kadams54> hatch: I'm spinning up an EC2 instance, I'll ping you once that's ready to go.
<hatch> kadams54: wasn't the issue with sandbox?
<kadams54> Yes, but I'm comparing sandbox with a real env to see where things go wrong
<kadams54> Someplace fakebackend.js is failing to properly mimic the real env.
<hatch> ohh I thought you had said that was already solved
<jrwren> rick_h_: basic check: is there a line in the /etc/init/maas-dhcp-server file that says "log" ?
<jrwren> rick_h_: also, you could add a line which says "output" and it should output to console
<rick_h_> jrwren: I don't see anything that says log
<jrwren> rick_h_: add it to make upstart log output to /var/log/upstart/<name>.log
<hatch> rick_h_: mind if I hop on that search box bug?
<rick_h_> hatch: not at all ty
<rick_h_> hatch: seems like a state fall down in there
<hatch> yeah this issue used to exist
<rick_h_> hatch: did you and kadams54 sync up ok then?
<hatch> we fixed it, then apparently it's back
<rick_h_> heh wheee
<hatch> rick_h_: yeah I guess he is going to test some ec2 stuff first
<kadams54> rick_h_, hatch: trying to get an EC2 env setup to compare real env vs. fakebackend.js and see where fakebackend.js is going off the rails.
<rick_h_> ok cool
<kadams54> rick_h_, hatch: unfortunately attempt #2 to set things up using quickstart just failed with a utf8 decoding stacktrace
<kadams54> Any ideas?
<hatch> don't use quickstart?
<jrwren> file a bug?
<hatch> eat a sandwitch?
<hatch> sandwich even
<kadams54> I'm wondering if EC2 is wonky right now due to the Xen stuff that's hit the fan.
<frankban> rick_h_: it is possible that dhcpd is failing because no subnet is present in /etc/maas/dhcpd.conf ?
<hatch> Makyo: the card you're working on is already done
<Makyo> ...well, bonus :D
<hatch> yeah it's part of the commitStatus stuff
<Makyo> Is it coupled in with other work?
<Makyo> Okay.
<hatch> it was required to do the uncommitted/waiting on ack/committed 
<hatch> stuff
<hatch> but there may be some extra stuff that could be cleaned up I supopse
<Makyo> I'll take a look to be sure.
<Makyo> Otherwise, I'll just move it along.
<hatch> excellent
<hatch> hope I saved you a ton of work haha
<Makyo> Yeah, I'll certainly take it.
<frankban> rick_h_: dhcpd is now running
<frankban> rick_h_: I restarted maas and now the conf file includes the 10.0.0.0 subnet
<rick_h_> frankban: rgr, rebooting the node here to see if it picks it up now
<rick_h_> frankban: woot!
<rick_h_> frankban: we have network booting
<frankban> rick_h_: really? yay!
<rick_h_> frankban: yes, fetching archivese/etc
<frankban> rick_h_: it was not obvious at all
<rick_h_> frankban: yea :/ thanks for hacking on that
<frankban> rick_h_: I'd assume maas would regenerate the conf file when saving the network configuration
<frankban> rick_h_: I think a celery job failed to update the dhcp conf
<frankban> rick_h_: nuc2 is ready
<rick_h_> frankban: woot!
 * rick_h_ power cycles nuc1
<frankban> rick_h_: they are both ready
<rick_h_> frankban: woot!
 * rick_h_ does a happy dance!
<frankban> rick_h_: should we start them, or is it juju work?
<rick_h_> ok, so now the question, can we stop then and start them and stop then
<rick_h_> frankban: going to try to stop them
<rick_h_> ok, that didn't work, guess ready doesn't mean running
<rick_h_> so trying to start them
<frankban> yeah
<rick_h_> hmmm, no luck there either
<frankban> rick_h_: what's the error?
<rick_h_> frankban: The action "Start selected nodes" could not be performed on 2 nodes because their state does not allow that action.
<rick_h_> frankban: had the same with stopping the node
<frankban> rick_h_: have you seen the popup that appears when you mouse over the start button in a node detail page?
<frankban> rick_h_: something about registering a ssh key
<rick_h_> frankban: oh, nope didn't see that 
<frankban> rick_h_: but shoulds't be juju in charge of provisioning (i.e. starting) machines in maas?
<rick_h_> frankban: maybe? outside of my docs reading to date on this now
<frankban> rick_h_: I very quickly try to do that (juju bootstrap -e maas)
<frankban> I can
<rick_h_> frankban: rgr
<frankban> rick_h_: ok launched
<rick_h_> https://code.launchpad.net/~jtv/maas/bug-986185-start-node-requires-ssh-key/+merge/103536 at least found the message :)
<frankban> rick_h_: did you allocated nuc1, or is it juju going?
<rick_h_> frankban: didn't touch anything
<frankban> rick_h_: cool, this can be a good sign
<rick_h_> wahoo!
<frankban> rick_h_: http://pastebin.ubuntu.com/8460003/
<rick_h_> frankban: ok, so ssh keys next
<frankban> rick_h_: it seems so
<rick_h_> https://maas.ubuntu.com/docs/nodes.html
<rick_h_> frankban: so there's some ssh key notes there, but it seemed like part of the virutal machine docs
<rick_h_> frankban: worth a quick try?
<frankban> rick_h_: the popup says to add ssh keys from http://maas.jujugui.org/MAAS/account/prefs/
<rick_h_> frankban: oh missed that sorry. 
<rick_h_> too many convos at once
<rick_h_> frankban: so reading https://maas.ubuntu.com/docs/juju-quick-start.html
<rick_h_> frankban: it says "There is no need to explicitly add an SSH key to MAAS when using Juju; it will automatically put your public key on any hosts that it starts up."
<rick_h_> frankban: that reads to me that the ssh key should match up with the juju one? can you add your public key on there and retry your test?
<frankban> rick_h_: heh, reading here it seems that my keys are "useful" but not strictly required: https://juju.ubuntu.com/docs/config-maas.html#edit-or-create-the-configuration
<frankban> rick_h_: but I can try
<rick_h_> frankban: hmm ok, /me goes back to that paste to read that error more carefully
<hatch> jujugui it appears that the BrowserSearchView class is not used anywhere in the app....can someone verify this? Just want to make sure my grepping didn't fail
<frankban> rick_h_: retrying with a public key in the envs.yaml
<rick_h_> frankban: k
<rick_h_> hatch: at first look search.js and charmbrowser.js are not used
<rick_h_> hatch: we did update that and such, but surprised we never got around to removing the old code
<hatch> yeah that's what I was thinking - I just didn't want to cut it out without a second eye on the grep :)
<rick_h_> hatch: yea, git grep says the two classes there aren't used
<frankban> rick_h_: in that same page, one of the steps for juju is Adding an SSH key...
<rick_h_> frankban: on which page, the juju one or the maas on?
<frankban> rick_h_: perhaps the meaning of the sentence you quoted is something like "there is no need to add your (as a juju user) ssh keys in order to access the nodes via ssh"
<frankban> rick_h_: https://maas.ubuntu.com/docs/juju-quick-start.html#adding-an-ssh-key
<jcsackett> jujugui: still looking for reviews on https://github.com/juju/juju-gui/pull/590 and https://github.com/juju/juju-gui/pull/591. the test failure on the first of those is spurious--a successful build is linked to from the comments.
<rick_h_> frankban: k yea. I think we can try this out with your ssh public key side and see if it works. If it does, we should probably add a shared one for the team or something. Maybe it'll make sense to add a user account for each person on the team with their own public key
<hatch> jujugui for those going to brussels https://www.youtube.com/watch?v=2fw7ls-53RM :)
<kadams54> jcsackett: I'll look at those as well.
<jcsackett> kadams54: awesome, thanks. :)
<kadams54> hatch: you mean I've been learning French for nothing?!?
<rogpeppe> hatch: dutch?
<hatch> apparently it's bilingual 
<jcsackett> it's like 80% french in brussels.
<kadams54> Je suis une chaussure rouge
<hatch> oh really?
<kadams54> See?!?
<jcsackett> so "parlez-vous anglais?" is a bit more useful. :p
<hatch> well damn you interent
<kadams54> I'm all set.
<hatch> kadams54: you're a red shoe?
<hatch> lol
<hatch> well if it's mostly french then yay
<hatch> I know infinitely more French than Dutch lol
<kadams54> Damn Canadians.
<jcsackett> eh, there's still 20% dutch, hatch. :p
<hatch> well if they don't speak english then I'm sol no matter what language they choose
<hatch> so...just making sure I can switch the language program to english :P
<kadams54> Hablas espaÃ±ol?
<hatch> un poco
<jcsackett> i wish i spoke spanish; would be very handy here.
<hatch> kadams54: a tumar classes en Duolingo
<frankban> rick_h_: added a key to maas, and trying to bootstrap juju with another one
<rick_h_> frankban: rgr
<kadams54> Yeah, I'm hitting up Duolingo for the French right now.
<hatch> which is probably wrong - I suck at the male/female parts of spanish
<hatch> why can't languages be single sex
<Makyo> jujugui quick clean-up branch for reviews/qa: https://github.com/juju/juju-gui/pull/592
<hatch> Makyo: on it
<frankban> rick_h_: what's the series running in the nucs?
<rick_h_> frankban: I set it to trusty
<rick_h_> frankban: in the maas ui
<frankban> rick_h_: cool
<rick_h_> frankban: http://maas.jujugui.org/MAAS/nodes/node-149f5df2-47e2-11e4-9745-eca86bffcfed/edit/
<rick_h_> I was confused as it seems like it should be juju determining that I guess, but :/
<jcsackett> Makyo: i'm looking too.
<rick_h_> Makyo: already gave a +1 :P
<jcsackett> Makyo: nm, i'll let hatch do #2 then. :p
<hatch> Makyo: commented on the pr - lemme know your thoughts
<hatch> Makyo: actually....a machine is an object not a model....bleh
<hatch> I'll delete that comment :)
<hatch> well it could go on the model list 
<hatch> I suppose
<rick_h_> hatch: it's not ideal but it's grep-able and usable and better than 'new'
<hatch> machineList.isNew(model)
<Makyo> hatch, yeah, though this method of always using .commitStatus gives us something to search for, as opposed to indexOf or regex on 'new'
<Makyo> Bleck, I don't like it.
<hatch> oh no question it's better than regex on 'new' heh
<hatch> alright, I'm ok with leaving it as is
<frankban> rick_h_: last attempt, same key.pub on the client and on the server
<rick_h_> frankban: ok
<hatch> the latest installment in the saga that is Installing Fiber - they are now trenching my yard to run the conduit to the house
<hatch> this fiber better be a religious experience after all this headache lol 
<Makyo> nnvffhgrbjvniidukdfhedbvbcnlttejvb
<Makyo> Sorry :P
<hatch> yeah I agree!!
<hatch> :P
<hatch> I'm having no luck in tracking down what handles the autocomplete token clicks 
<rick_h_> hatch: bwuahahahaha
<rick_h_> :P
<rick_h_> hatch: it's the same event that catching clicks on the tokens in the sidebar
<hatch> lol hey it's all your fault - you and your events :P
<rick_h_> hatch: autocomplete tokens are...token
<rick_h_> tokens
<rick_h_> if I recall correctly
<hatch> that's what I thought too - but the handler for those aren't being called when I click on the category tokens
 * rick_h_ dusts off the old memory
<rick_h_> hatch: looking
<hatch> in charmbrowser.js there is a .token click hanlder
<hatch> that handler doesn't get called when you click on the category tokens
<rick_h_> hatch: oh, but it's different because the AC widget has a selection made
<hatch> ohhhhhhh 
<frankban> rick_h_: now I have to go. I'll try again later, I see that one of the steps in the docs is juju sync-tools, executed it, but still no luck. this is the failing (repeated) command: http://pastebin.ubuntu.com/8460289/
<frankban> good night!
<rick_h_> frankban: ok, maybe tomorrow seeif you can catch any of the #maas guys to help out if possible
<hatch> rick_h_: thanks you got me going again :)
<rick_h_> frankban: if not, we'll look into it more tomorrow
<hatch> cya frankban
<rick_h_> hatch:       this.ac._onItemClick = function(ev) {
<frankban> rick_h_: I'll do
<hatch> yup found it now thanks
<hatch> totally forgot that categories were actually a list item
<kadams54> guihelp: Working sans quickstartâ¦ juju deploy --to 0 juju-gui && juju expose juju-gui
<rick_h_> kadams54: correct
<kadams54> juju status reports: public-address: ec2-54-69-157-181.us-west-2.compute.amazonaws.com
<rick_h_> kadams54: and the services is listed as 'started'?
<kadams54> But I'm not seeing anything when I pull that up in a browser
<rick_h_> kadams54: or still 'pending'
<rick_h_> kadams54: https://ec2-54-69-157-181.us-west-2.compute.amazonaws.com/
<rick_h_> kadams54: works for me 
<kadams54> Yeahâ¦ I just realized juju status was reporting exposed as false
<kadams54> So I re-ran and that fixed. *sigh*
<rick_h_> gotcha
<hatch> :)
<hatch> kadams54: also if you change the juju-gui-source it'll take a while but the status reports will always be green
<hatch> so you will just have to keep trying every few mins
<kadams54> Yeah, I watch the debug log for that
<rick_h_> jujugui off to the doc, biab
<jrwren> I need some help with $(shell...) in make. The Makefile has APT_BASED := $(shell command -v apt-get ; echo $$?)  and later compares to zero, but this is always false because of the output from command -v
<jrwren> so I change to APT_BASED := $(shell command -v apt-get >/dev/null ; echo $$?)   and make just hangs
<jrwren> so I tried APT_BASED := $(shell { command -v apt-get ; echo $$?; }|tail -1)   and that also just hangs.
<jrwren> yet APT_BASED := $(shell { command -v apt-get ; echo $$?; }|head -1)   puts the value I expect into the APT_BASED variable (just not the value I want)
<jrwren> hrm. I should have asked before rick_h_ left. I know how much he loves make.
<hatch> haha yup 
<kadams54> hatch: Ready when you are to chat on this card.
<kadams54> guihelp: how are the various delta handler methods in handlers.js invoked?
<hatch> kadams54: ok just eating lunch
<hatch> so in a few
<hatch> kadams54: from the delta 
<hatch> it's all synchronous so you should be able to traceback
<hatch> look at the parse_delta methods
<hatch> there are many
<kadams54> The deltas come back via WS?
<jrwren> find the issue. it was not where I thought. Make kind of sucks somtimes.
<hatch> correct
<hatch> jrwren: only sometimes? :)
<jrwren> hatch: :)   more often than not, I am a make fan.
<jrwren> hatch: I'm even crazy enough to tell the grunt/gulp crowd that make does all that, better.
<hatch> jrwren: well since those are typically just a wrapper over shell commands :)
<hatch> but make is sure ugly.....like real ugly
<hatch> kadams54: ok still need to chat?
<hatch> jcsackett: holy crap that branch landed
<hatch> jcsackett: https://github.com/juju/juju-gui/pull/587/files here is the final diff if you're curious
<jcsackett> hatch: whoo!
<jcsackett> hatch: just one more hell-branch to go. :p
<jcsackett> hatch: that's a much smaller diff than i expected. nice.
<hatch> yeah I just hope it doesn't block other peoples branches from landing with some wako new spurious falure
<hatch> so I ran it a few times before landing
<hatch> just to be safe
<hatch> hmm this search bug is a little bugger to fix
<hatch> technically it's working as it should....
<hatch> ahh stupid #$%^&(*^(*& javascript
<hatch> kadams54: just ping if you still need to chat
<hatch> jujugui lf a review and qa on https://github.com/juju/juju-gui/pull/593
<jcsackett> hatch: looking.
<hatch> thanky
<hatch> now which card to pick
<hatch> hmmmmm
<rick_h_> hatch: notifier
<rick_h_> hatch: or the inspector cleanup of old code
<hatch> oh that damn notifier
<hatch> sure I'm up for a challenge
<rick_h_> hatch: yea, those are the two big things for this cleanup week imo
<rick_h_> hatch: especially as the new work on the sidebar will be all around the inspector code
<hatch> jcsackett: if you don't mind https://github.com/juju/juju-gui/pull/594 here is one just removing old unused search code
<hatch> rick_h_: ahh right
<hatch> rick_h_: mind taking a quick glance at my branches in PR so I can land em?
<hatch> they are both small
<rick_h_> hatch: in a mtg atm but can later tonight
<hatch> alrighty
<jcsackett> hatch: i can look at that one too, sure.
<hatch> thx
<hatch> rick_h_: is there a notifier card? Or am I blind?
<rick_h_> hatch: not yet no
<hatch> alright I'll create an investigate card
<rick_h_> hatch: peek at it, get a plan, and let's pow wow later
<hatch> a o k 
<hatch> brb taking dogs out
<hatch> back
<hatch> jrwren: make huge bank from the advert on your blog?
<hatch> and your about page is incorrect :)
<kadams54> jujugui: https://github.com/juju/juju-gui/pull/595 is ready for review and QA.
<hatch> kadams54: made a request to review
<hatch> in the *
<hatch> rick_h_: you still pokin around?
<rick_h_> hatch: kind of what's up?
<hatch> just wondering if you wanted to chat about this notifications business
<rick_h_> hatch: cool if you're ready, let's do it fast
<rick_h_> standup room?
<hatch> yup
<hatch> Makyo: didn't you fix this? https://bugs.launchpad.net/juju-gui/+bug/1365260
<mup> Bug #1365260: deployer bar commit button stays active after confirm <mv> <juju-gui:Triaged> <https://launchpad.net/bugs/1365260>
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> enjoy your time off
<huwshimi> hatch: Hey, yeah, well I spent three of the four days painting :)
<huwshimi> hatch: But I moved into the new office room yesterday!
<hatch> haha awesome!
<huwshimi> hatch: After our trip I'll finish moving in here, build a new desk and bookshelves and make it all nice
<hatch> going to get a standing desk?
<huwshimi> hatch: Probably not, I used to do that a bit, but I think I'm better off sitting down and then getting out for exercise
<rick_h_> huwshimi: morning
<huwshimi> rick_h_: Hey
<rick_h_> huwshimi: have a sec to chat?
<huwshimi> rick_h_: Sure
<rick_h_> huwshimi: meet you in the standup room
<huwshimi> ok
<jrwren> hatch: how is it incorrect?  details man!
<jrwren> hatch: make zero bank for the ads. I should remove that.
<hatch> your new employer
<hatch> :)
<jrwren> hatch: huh?
<jrwren> hatch: oh! my ABOUT page. I can't read :)
<hatch> lol
#juju-gui 2014-09-30
<rick_h_> huwshimi: review in, thanks for the great stuff
<rick_h_> hatch: you do your blog post?
<fabrice> morning
<luca__> Hi urulama 
<luca__> Rick said I can make some cards on the Juju GUI kanban
<luca__> do you know which column I should put them on?
<fabrice_> luca__: I suppose I would put them under ready to code 
<luca__> thanks fabrice_ 
<luca__> Iâll add them there
<luca__> rick can move them if need be
<fabrice_> luca__: he will be there in 90 minutes most likely so you can check with him
<luca__> thanks :)
<urulama> luca__: hey, was otp
<luca__> urulama: no worries
<luca__> urulama: I have added them now
 * urulama gets worried :D
<urulama> luca__: where did you put it?
<luca__> ready to code in the urgent section
<urulama> luca__: oh, robin will be happy :)
<luca__> urulama: haha, heâs sitting near me. Heâs on it :)
<frankban> marcoceppi: morning, any idea about why I get "ssh: connect to host 10.89.138.144 port 22: Connection refused" from ec2 when running juju-test? the same environment works when bootstrapped directly
<marcoceppi> frankban: what flags were passed?
<luca__> urulama: I just made the Urgent section of ready to code go red!
<luca__> urulama: rick_h_ is not going to be happy with me
<luca__> lol
<frankban> marcoceppi: yes | juju-test --timeout=60m -v -e "ec2-precise" 20-functional.test
<urulama> luca__: that is a great good morning welcome!
<marcoceppi> frankban: so, I need to check if juju test is still making an isolated environment, if so you'll need to reset your JUJU_HOME to access the environment
<frankban> marcoceppi: reset my juju-home?
<marcoceppi> frankban: not reset, sorry, override
<marcoceppi> juju-test, used to, create an isolated JUJU_HOME from the users, copy over the credentials for just that environment and bootstrap from it. This way we didn't polute people's JUJU_HOME. This was fine until juju started creating it's own SSH keys
<marcoceppi> actually, we're not doing that anymore, good
<marcoceppi> hum. Why can't you access it
<frankban> marcoceppi: the weird stuff is that it worked since yesterday or a couple of days ago. btw this is the full output: http://pastebin.ubuntu.com/8464993/
<marcoceppi> frankban: could it just be that the instance took too long to come online?
<frankban> marcoceppi: tried several times, trying again
<marcoceppi> it's weird that it's listing the internal IP address. I mean, nothing has changed in juju-test in months
<frankban> marcoceppi: I don't exclude this can be some oddity on my local configuration, it's just weird that it works when the environment is bootstrapped manually
<marcoceppi> frankban: that is totally werid
<marcoceppi> the bootstrap command is literally a Popen to juju bootstrap
<frankban> marcoceppi: yeah I know that
 * marcoceppi scratches head and wakes up a bit more
<frankban> marcoceppi: uhm, same error, Connection refused
 * frankban bbiab
<rick_h_> luca__: hah
 * luca__ starts hiding up his desk
<rick_h_> frankban: need me to test something out to see if I get the same issues?
<frankban> rick_h_: it would be great, to double check there is not something crazy here
<rick_h_> frankban: what branch are you running and I'll pull it done and try to run the tests
<rick_h_> frankban: is this the symlink branch?
<frankban> rick_h_: "make ftest JUJU_ENV=ec2" in charm trunk could dupe the problem
<rick_h_> ~juju-gui-charmers/charms/trusty/juju-gui/trunk/ ?
<rick_h_> frankban: ok, starting up
<frankban> rick_h_: the dev branch should work: lp:~juju-gui/charms/trusty/juju-gui/trunk
<frankban> rick_h_: thank you
<frankban> rick_h_: in maas, I tried strating a node and It doesn't seem I am able to ssh into it (even without juju involved)
<rick_h_> frankban: is this from the maas host?
<rick_h_> frankban: and did you generate an ssh key on that user?
<rick_h_> frankban: or you're letting juju generate the ssh key and then usnig juju ssh?
<frankban> rick_h_: yes, from the ubuntu user in the maas host, and yes, quickstart generated the keys for me, and added them to the preferences before starting the node
<frankban> rick_h_: could it be we need to do that before commissioning the node?
<rick_h_> frankban: I can't imagine, it's wiped with a new ubuntu image when it's bootstrapped I had thought, but perhaps not
<frankban> rick_h_: I'll try to commission the node again
<rick_h_> frankban: rgr, tests are running here. 
<rick_h_> frankban: juju-test.conductor DEBUG   : State for 1.21.0: started
<rick_h_> juju-test.conductor.20-functional.test DEBUG   : Running 20-functional.test (tests/20-functional.test)
<frankban> darn
<frankban> rick_h_: so this is something on my side
<rick_h_> that's on the main branch, I'll try the dev branch as well
<frankban> thanks
<frankban> rick_h_: what charm-tools version are you using?
<rick_h_> 1.3.3-0ubuntu1~ubuntu14.04.1~ppa1
<rick_h_> and the other branch is running tests here as well
<rick_h_> brb
<frankban> rick_h_: can I see the initial output from make ftest?
<rick_h_> frankban: sure
<rick_h_> https://pastebin.canonical.com/117908/
<rick_h_> frankban: ^
<frankban> rick_h_: aha, trying to manually connect to ec2 I get "Received disconnect from 54.74.124.239: 2: Too many authentication failures for frankban"
<rick_h_> oh :/
<frankban> rick_h_: I removed some old ssh keys and now it works :-/
<rick_h_> frankban: woot
<frankban> marcoceppi: is it possible that the juju-test failure was caused by too many keys in ~/.ssh?
<frankban> rick_h_: nuc1 is still in commissioning state, do you have any logs to check what's wrong with maas?
<rick_h_> frankban: let me log in and check the maas logs in /var/log/maas
<rick_h_> frankban: hmm, bunch of errors OAuthUnauthorized: 'Expired timestamp: given 1411951792 and now 1412009155 has a greater difference than threshold 300'
<marcoceppi> frankban: that's weird, but...possibly?
<rick_h_> frankban: oh, I probably have to power cycle the node, let me try that out. 
<frankban> rick_h_: thanks
<rick_h_> hmm, I thought maas would control power on the nodes. wonder if there's a missing step for that as well
<frankban> there are power parameters in the node edit page
<rick_h_> maybe I need to set it to static ip so that I have an ip there. 
<rick_h_> I've got the amt stuff setup for dhcp
<rick_h_> frankban: ok, it's ready
<frankban> rick_h_: uhm... no success with ubuntu@guimaas:~$ ssh 10.0.0.100
<rick_h_> frankban: yea, I think I need to change them to static ips to complete the power settings
<rick_h_> frankban: if you try to 'start' the node it can't and http://askubuntu.com/questions/481947/maas-unable-to-start-commisioned-nodes
<rick_h_> goes into power settings, I'll work on hooking up kvm and fixing their amt setup
<rick_h_> oh, never mind lol
<rick_h_> I just managed to do a stop, so I guess 'ready' means it is started
<rick_h_> frankban: and you're doing a deploy? looks like they're both allocated now?
<frankban> rick_h_: I started them bot, in order to try connecting to those via ssh
<rick_h_> ok
<frankban> rick_h_: I receive pings back from both nodes, but ssh hangs
<rick_h_> frankban: ok, so maybe not open?
<rick_h_> firewall/etc wise?
<frankban> rick_h_: maybe
<rick_h_> http://askubuntu.com/questions/173112/what-is-the-maas-node-login hmm, seems we're on the right path
<frankban> rick_h_: yes we did everything there
<rick_h_> frankban: ok, hooking up kvm on one of them sec
<luca__> rick_h_: frankban free for a call for 2 mins?
<frankban> luca__: I am
<rick_h_> luca__: yes
<luca__> rick_h_: frankban Iâll make a hangout
 * rick_h_ goes to get a quick drink
<luca__> frankban: https://plus.google.com/hangouts/_/gwtlakndzaeym3q5jvmwk7aq24a?authuser=1&hl=en-GB
<luca__> frankban: rick_h_ https://plus.google.com/hangouts/_/gqnbftvjxao6zsvpnnaehd2viya?hl=en
<luca__> rick didnât pick up the last call
<rick_h_> frankban: ok cool, I can ssh to nuc1 now
<rick_h_> it took forever going through a big install for 10min, but it's up now
<frankban> rick_h_: me too \o/
<rick_h_> going to power cycle nuc2 and see what it does
<rick_h_> the lack of visibilty kind of sucks
<rick_h_> I need to figure out how to do the remote kvm over the browser to these things
<rick_h_> I think the amt stuff supports it
<frankban> guihelp: anyone for a quick review of a doc-only branch? https://github.com/juju/juju-gui/pull/596
<rick_h_> frankban: looking
<rick_h_> frankban: lgtm ty much I kept meaning to add that in
<frankban> rick_h_:  thank you!
<rick_h_> frankban: when you cut the charm release can you do a micro gui release with the bug fix from hatch's work please?
<rick_h_> frankban: and the nuc2 is up and showing ssh key info so think that's set as well
<rick_h_> frankban: hopefully it all works now!
<frankban> rick_h_: is Jeff's fix merged?
<rick_h_> frankban: yes
<frankban> rick_h_: cool, so I'll restart the process
<rick_h_> https://github.com/juju/juju-gui/pull/593
<rick_h_> frankban: sorry, missed you had started it 
<frankban> rick_h_: np
<frankban> rick_h_: is it the only thing worth being included in the changelog?
<rick_h_> frankban: I believe so, /me dbl checks
<rick_h_> frankban: yes, that's it. Other stuff is small/internals
<frankban> rick_h_: stopping the nucs and trying juju
<rick_h_> frankban: rgr
<rick_h_> frankban: any luck? I didn't see the nuc shut down
<frankban> rick_h_: quickstart failed: ERROR waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist
<rick_h_> frankban: ugh
<frankban> rick_h_: /var/lib/juju/nonce.txt should be created by cloud-init AFAICT
<rick_h_> https://lists.ubuntu.com/archives/juju/2014-May/003849.html 
<rick_h_> yea
<frankban> rick_h_: trying to bootstrap without quickstart
<frankban> rick_h_: 2014-09-30 13:47:54 DEBUG juju.utils.ssh ssh_openssh.go:129 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -i /home/ubuntu/.juju/ssh/juju_id_rsa -i /home/ubuntu/.ssh/id_rsa ubuntu@10.0.0.100 /bin/bash 
<frankban> rick_h_: it seems this still fails
<rick_h_> frankban: ok, booo and such. 
<rick_h_> frankban: let me hard code ip addresses on the boxes for their power settings and such and see if we can find something to try 
<frankban> rick note that without the trailing /bin/bash the command succeeds when run on a shell
<rick_h_> frankban: hmm, that's interesting, I can't imagine bin/bash isn't allowed ?
<frankban> rick_h_: everything is possible on "Weirdness Tuesday"
<frankban> rick_h_: yeah it exited with the same (ambiguous) error
<frankban> rick_h_: https://bugs.launchpad.net/juju-core/+bug/1314682
<mup> Bug #1314682: Bootstrap fails because of virt-manager config <bootstrap> <juju> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1314682>
<rick_h_> frankban: resetup the amt on the nucs to 10.0.0.101 hard coded ip and 10.0.0.102 
<rick_h_> frankban: I've adjusted the dhcp config in the mass that 10.0.0.100-105 is static allocated
<rick_h_> and 10.0.0.200-250 is dynamic
<rick_h_> frankban: and readding the two nodes to maas, hopefully with more success this time
<frankban> rick_h_: thanks
<rick_h_> bah, how did it get to be .104?!
 * rick_h_ is about to have a fit and start chucking nucs
<hatch> would they then be  called "nuc chucks" ?
<hatch> oh c'mon that was hilarious 
 * rick_h_ stops grinding teeth long enough to chortle at it
<hatch> lol
<hatch> rick_h_: so the MAAS experience was not designed for non sysadmins hey?
<frankban> jujugui heads up, working on a new GUI release now, please don't land changes
<hatch> oh is this to fix the upgrade issue?
<jcsackett> frankban: ack.
<rick_h_> hatch: it's actually more of a total install issue
<rick_h_> hatch: so bigger than ugprades, and including your search fix as part of the release
<hatch> kadams54: your latest PR update is missing a test for the float branch
<hatch> rick_h_: ahh ok
<hatch> maybe we can do bi/weekly releases now :)
<kadams54> hatch: you know a charm with float config? I looked for one in all of the featured charms and couldn't find any.
<hatch> I thought you did because it was in your parsing code
<hatch> hah
<kadams54> I did in my parsing code because the docs say configs can have floats :-)
<hatch> oh well then the tests should test for that
<hatch> I added another comment
<frankban> rick_h_: any idea about why 1.2.1 xz is 5.1MB and 1.2.0 is 8.5? https://launchpad.net/juju-gui/+download
<rick_h_> frankban: not off the top of my head no
<frankban> rick_h_: note that 1.1.1 is 5.1
<rick_h_> frankban: maybe I had something on my system that made a bad tarball?
<frankban> rick_h_: ok, I'll continue with the process
<frankban> rick_h_: the manual build on CI step failed: http://ci.jujugui.org:8080/job/juju-gui-merge/698/console
<rick_h_> jujugui call in 10
<rick_h_> frankban: rgr looking
<frankban> rick_h_: do I need to use juju gui or juju gui merge?
<rick_h_> frankban: wiped the workspace and retrying. Worst case I'll have to ssh in and git fetch in the tree
<rick_h_> frankban: looks like it's running your sha now http://ci.jujugui.org:8080/job/juju-gui-merge/699/console
<frankban> rick_h_: cool thanks
<rick_h_> frankban: sorry, head is in 5 different places and I'm not 100% following
<frankban> rick_h_: no worries, long time did not make a gui release, it's an interesting process
<rick_h_> frankban: oh, I see what you're doing yea heh that should be just juju-gui
<rick_h_> frankban: the -merge job will attemt to land a pr that's not there
<hatch> agreed, release is confusing
<frankban> rick_h_: ok trying on "juju gui" (trying not to ping everyone)
<hatch> kadams54: to avoid failures in CI you can run make check before pushing
<rick_h_> frankban: all good
<kadams54> hatch: yeah, one day I'll get that commit hook setup :-)
<rick_h_> bac: call?
<rick_h_> jujugui afk for a few min I need a coffee break
<hatch> heh this notifier code is so old it's not even using Base.create()
<frankban> jujugui uploaded the new GUI tarball, you can now land branches
<hatch> thanks frankban
<rick_h_> frankban: <3
<frankban> rick_h_: now running the charm tests
<hatch> rick_h_:  I think this bug is invalid now? https://bugs.launchpad.net/juju-gui/+bug/1218011
<mup> Bug #1218011: full notification list is difficult to read and to use <juju-gui:Triaged> <https://launchpad.net/bugs/1218011>
<rick_h_> hatch: yea, not really sure. we don't really get that many notifications at once these days
<Makyo> jujugui quick branch for review/qa https://github.com/juju/juju-gui/pull/597
<hatch> Makyo: not able to remove the environment.js stuff eh? :)
<Makyo> hatch, wasn't any.
<Makyo> That whole file was just dead code.
<Makyo> I was ready for that branch to be a million times harder than it was.
<hatch> haha gotcha
<hatch> Makyo: so were there no tests for this code? 
<hatch> I mean, obviously not if they didn't fail 
<Makyo> hatch, as far as I can tell, every use of the code had been removed, the file was just left there.
<hatch> heh...but wow
<Makyo> Someone did my work for me :)
<hatch> haha nice
<frankban> rick_h_: gui/charm release done, and now to wait for ingestion. done for the day, have a nice evening!
<rick_h_> frankban: night thanks!
<bic2k> if I have a single machine with three services on it and I destroy one service on it, should it destroy the entire machine? I'm reproducing right now to confirm thats what happened.
<rick_h_> bic2k: does it do it in a live env? we have a known bug that it does it in the demo mode that's being worked on atm 
<bic2k> rick_h_ I really hope I'm in live mode, otherwise I've been pretending to update our services all morning ;-) So yes :-D
<rick_h_> bic2k: ok, kadams54 ^
<bic2k> rick_h_ is appears that I removed the service in juju-gui and juju-gui decided not to show the machine anymore, but `juju status` still shows it with the other services and a refresh of the gui shows it... may just be a bug in destroying services on the UX side
<rick_h_> bic2k: rgr, makes sense and we'll add the note to the current wip to make sure we fix that
<kadams54> bic2k: thanks for the report. Does the machine show back up with a refresh?
<bic2k> kadams54 ya, machine reappears on refresh.
<kadams54> whew
<hatch> bic2k: did you have the charms in containers or all on the root machine?
<bic2k> hatch all root machine charms
<hatch> ok I think I know what the issue is
<hatch> kadams54: it's probably because when the service is destroyed it matches on the machine assuming it's in a container but it's not
<kadams54> hatch: yeah, but destroying a service shouldn't destroy the container, regardless of whether it's root or not.
<hatch> true true
<hatch> bic2k: https://bugs.launchpad.net/juju-gui/+bug/1375918 
<mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:New> <https://launchpad.net/bugs/1375918>
<kadams54> guihelp: So I've traced bic2k's issue (and likely some of the WIP cards) to this line: https://github.com/juju/juju-gui/blob/develop/app/models/handlers.js#L211 Does anyone know why we'd want to invoke machine delta processing as part of unitInfo delta processing?
<hatch> hmmm
<bic2k> hatch stack traced added to #1375918
<mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:New> <https://launchpad.net/bugs/1375918>
<kadams54> That particular line of code been there since April of last year.
<hatch>  bic2k thanks
<bic2k> feeling like QA this morning :-)
<hatch> kadams54: ohh we process the delta information so that we can add the unit information to the machine models
<kadams54> OKâ¦ but just straight up passing the same action (as we currently do now) is dangerousâ¦
<hatch> bic2k: haha - it's odd that no one else ran into these issues before but I'm glad you're helping us by reporting it :)
<hatch> kadams54: how do you figure?
<hatch> oh because the action is remove
<hatch> haha duh
<kadams54> hatch: Because in this case, the action (remove) only applies to the unit. But since we pass it into the machine delta processingâ¦
<kadams54> Ditto for adding a unit.
<hatch> good find
<kadams54> Ditto (probably) for just about any action on the unit.
<hatch> wow how have we never noticed this (or any of our users) in a year
<kadams54> It sounds like we want *:unitInfo actions to trigger an update:Machine action.
<hatch> well we'll still need new units to add machines 
<kadams54> hatch: it was sorta noticed. I wrapped it in an if statement that prevented trying to create machines when there is no machine ID. But that's not a complete fix.
<hatch> because we'll need machines to place units on in the event that the machine delta comes in afterwards
<hatch> wana have a quick chat about this in standup?
<kadams54> hatch: Yeah, that's what I'm getting at here. I think we need to nail down exactly what the behavior ought to be.
<hatch> ok joining
<kadams54> hatch: will be there in a moment
<hatch> jujugui I need a review on https://github.com/juju/juju-gui/pull/598 plz and thx
<hatch> bic2k: looks like kadams54 has a good way forward on fixing the 'remove root machine' issue 
<Makyo> On it
<hatch> bic2k: and the expose toggle is also being worked on now :) we are stomping your bugs into the pavement :P
<arosales> hatch: I recall a javascript console "trick" to change the name of the provider in the GUI do you know what that is?
<hatch> arosales: I don't but I can figure it out, 1 min
<hatch> testing....
<hatch> arosales: yui.one('#environment-name').set('text', 'My rockin env');
<hatch> that of course will only work until you refresh 
<hatch> arosales: that won't however change the one in the machine view - would you like one for there as well?
<hatch> arosales: here use this one instead   app.env.set('environmentName', 'this environment is the best');
<hatch> that one will update it throughout the app
<arosales> hatch: thank you sir
 * arosales will write it down this time ;-)
<hatch> haha
<hatch> that also will only work until you refresh
<hatch> :)
<hatch> then it'll reset to whatever Juju says the environment name is
<arosales> ack
 * hatch lunching
 * Makyo runs to the store over lunch, back in a few.
 * rick_h_ goes to doc, back later
<hatch> hmm what card to work on
<hatch> jujugui if the user has conflicted config changes should we block them from comitting their changeset? Or simply notify them?
<jcsackett> hatch: i'm sort of leaning towards block until they resolve.
<hatch> jcsackett: I am too but also not sure if that's very good UX
<jcsackett> hatch: it's not great, but just notifying and then paving over isn't either.
<hatch> it may not be clear that there is a conflict even with it in the changeset list
<jcsackett> the conflict likely indicates there's something setup that's not good.
<jcsackett> hatch: so then we need better UI about what's wrong.
<jcsackett> hatch: when you say notify, do you mean like we do with machines that can't be destroyed?
<hatch> maybe allow them to click commit - but then pop up that black tooltip
<jcsackett> b/c that works for me--don't do the thing we aren't sure about and pop up an error about why.
<hatch> so user clicks the commit button, it opens the changeset list, they miss the 'conflict' section and they see that the commit button is now disabled but not sure why
<hatch> it's not clear that the conflicts must be resolved
<hatch> ( it doesn't help that we don't have a mockup for this ) :)
<hatch> jcsackett: I'll block it and work on some way to make it clear that this needs to be resolved first
<jcsackett> hatch: kick it to UX.
<hatch> I ain't got no time for their jibber jabber
 * jcsackett laughs
<hatch> of course there is a bug in YUI's model list map function
<jcsackett> BUGS EVERYWHERE.
<hatch> lol
<hatch> wow this branch was a little too easy....I bet the tests are going to be impossible
<hatch> hah
<rick_h_> hatch: yes, block but lead them straigh to the problem
 * rick_h_ is back from damn doc trying to break my arm
<hatch> haha
<hatch> rick_h_: https://github.com/juju/juju-gui/pull/599
<hatch> rick_h_: thanks for the comments . I'll take a screenshot and send it to luca et'al for some more design input - maybe the background colour should be red or something...iunno
<rick_h_> hatch: yea, needs to be called out for sure
<rick_h_> jujugui going to eod and run away night all
<hatch> enjoy
<huwshimi> Morning
#juju-gui 2014-10-01
<hatch> hey huwshimi
<huwshimi> Hey
<huwshimi> hatch: How's things?
<hatch> going good - just trying to get everything done before next week
<hatch> seems these things always happen a week too early haha
<huwshimi> :)
<rick_h_> morning party people
<rick_h_> frankban: how goes this morning?
<frankban> rick_h_: I was going to send you an email
<frankban> rick_h_: I was able to give internet access to nodes, by doing the following:
<frankban> - add a default 10.0.0.1 gateway to the MAAS network;
<frankban> - fix the POSTROUTING netfilter rule in the host, i.e.
<frankban>   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
<rick_h_> cool, yea that's what I was just looking at in some google searches
<frankban> rick_h_: Next error was related to juju tools: "cannot execute binary file: Exec format errorâ.
<frankban> See https://bugs.launchpad.net/juju-core/+bug/1325968
<frankban> so the fix seems t be --constraints arch=i386
<rick_h_> ugh
<frankban> rick_h_: with that constraint, juju finally bootstrapped!
<rick_h_> yay!
<frankban> rick_h_: so now I am testing quickstart with and without the constraints flag
<rick_h_> frankban: <3 ok very cool. Glad you're unblocked enough. Thanks for helping throgh all this fun stuff
<rick_h_> frankban: let's make sure we add notes to that maas doc so that we can make sure this works out as the hope is we'll have a maas lab going forward
<frankban> rick_h_: yeah it was ages since my last iptables command ;-)
<rick_h_> no kidding, I got that far last night and took that as a sign I was done :)
<rick_h_> iptables and multiple glasses of wine never mix lol
<frankban> :-)
<frankban> rick_h_:  now running ".venv/bin/python juju-quickstart --constraints arch=i386" fingers crossed
<rick_h_> frankban: cool, maybe did I install i386 ubuntu on the maas controller?
<frankban> rick_h_: unrelated, but ssh always disconnects me after a few minutes with a broken pipe
<frankban> rick_h_: the kernel is 64 bit
<rick_h_> frankban: yea, I wonder if I've got a network thing going on. It kept doing that to me ssh'ing out on my laptop last night
<rick_h_> frankban: but my desktop stayed connected the whole time, so it's strange
<frankban> rick_h_: the nodes are i386, and that's where tools are used
<rick_h_> frankban: ic, but the nodes can be anything right? We can set them as amd64 in maas and it should install the right images from it's list of images?
<frankban> rick_h_: in theory yes, in theory...
<rick_h_> lol
<rick_h_> frankban: ok, so you ssh'd in and verified they were running i386 images?
 * rick_h_ is trying to phrase a reply to the bug and if we can dupe it we should work with juju core on it
<frankban> rick_h_: no I have not but in the edit node page i see "i386/generic" arch
<rick_h_> frankban: oh? oooh, ok. 
<rick_h_> I was looking at nuc2 which is amd64
<rick_h_> so maybe it's my failing to setup maas correctly
<rick_h_> frankban: when you're test is done let me know and we'll edit the node and try to recomission it
<frankban> rick_h_: ok
<rick_h_> and see if we can get updated software on it
<rick_h_> and then make it work sans constraint :)
<frankban> rick_h_: woot, all's good for now: http://pastebin.ubuntu.com/8472118/
<rick_h_> yay!
<rick_h_> so now the other thing to document is sshuttle into the 10.0 network on there so you can get at the gui
<frankban> rick_h_: quickstart has not finished yet
 * rick_h_ really doesn't want to redo this setup but wonders if trying to put all the nodes on the public network would be best
<frankban> rick_h_: so, GUI deployed, but then quickstart exited with an error: juju-quickstart: error: unable to connect to the Juju API server on wss://nuc1.maas:443/ws: [Errno -2] Name or service not known
<frankban> so, dns is not working
<rick_h_> hmm, yea
<rick_h_> so maas is setup and supposed to manage dns, but I bet it's because I set the dns on the hosts to google or something vs itself
 * rick_h_ looks up format of dig commands
<rick_h_> dig nuc1.maas @10.0.0.1
<rick_h_> works so cool
<rick_h_> frankban: ok, updated resolv.conf and the nameserver for the 10.x interface and just a normal cli "dig nuc1.maas" returns now
<frankban> rick_h_: cool, so, I'll re-run quickstart on the bootstrapped environment and this time it should be able to connect to the gui server
<rick_h_> frankban: rgr
<frankban> rick_h_: done, quickstart completed successfully: http://pastebin.ubuntu.com/8472146/
<frankban> \o/
<rick_h_> woooooooo!
<rick_h_> it's early...but a happy dance it is
<frankban> rick_h_: destroying the environment
<rick_h_> hold on if you can
<frankban> ops
<rick_h_> ok, np
<frankban> rick_h_: another thing I noted, when destroying an environment the node is left to Releasing failed status, and you need a manual "release" fot it to be back in ready state
<rick_h_> frankban: yea
<frankban> rick_h_: but I guess it's not our problem
<rick_h_> frankban: ok so sshuttle -v -D -r ubuntu@maas.jujugui.org 10.0.0.0/24
<rick_h_> let's me load up maas on http://10.0.0.1/MAAS
<frankban> rick_h_: cool, should wer try to switch nuc1 to amd64?
<rick_h_> frankban: so the hope is that line will let us load up the gui and environment stuff once it's brought up
<rick_h_> frankban: yea, let's do that
<rick_h_> frankban: ok switched and comissioning
<frankban> rick_h_: cool thanks
 * rick_h_ wishes he had all the kvm stuff setup to watch it and make sure it's going...doesn't trust maas enough yet
<rick_h_> frankban: yea, on the release node stuff, it's new and we've got some issues from the experimental branch
<rick_h_> frankban: you'll be happy to know our big problem before was lack of the amt control tools package installed
<rick_h_> frankban: the new software shows the error while before I assumed maas handled that bit
<frankban> rick_h_: yay for experimental maas
<rick_h_> definitely, so maas was never powering on/off our machines as hoped
<frankban> ic
<frankban> rick_h_: one confusing bit is that nuc1 pretends to have 10.0.0.151 addr, but when it starts it's on 10.0.0.100
<rick_h_> frankban: yea, I'm not sure what's up with that to be honest. 
<frankban> rick_h_: ok the node is ready
<frankban> rick_h_: running quickstart without constraints
<rick_h_> frankban: rgr
<frankban> rick_h_: at least we now my branch with maas support works and generates a reasonable configuration
<rick_h_> frankban: :)
<rick_h_> frankban: yea, I had hoped it would be very little different other than generating the proper environments.yaml
<frankban> rick_h_: yeah, it's basically just it
<rick_h_> and then 3 days of getting maas and juju happy lol
<rick_h_> across timezones 
<frankban> lol
<rick_h_> hmm, it's green and says deployed?
<frankban> rick_h_: yeah, qucikstart still bootstrapping
<rick_h_> cool
<frankban> rick_h_: and now it's deploying
<frankban> rick_h_: so bootstrap succeeded without constraints
<rick_h_> woot
<rick_h_> lol, every change one step closer...and closer...and closer
<frankban> waiting for the new shiny cs:trusty/juju-gui-9 unit to be deployed
<frankban> rick_h_: done! quickstart is ready
<rick_h_> sweet, so with the shuttle command can you load the gui in your local browser now?
<frankban> trying
<rick_h_> it works here https://10.0.0.100/login/
<frankban> rick_h_: it works!
<rick_h_> woot!
<rick_h_> jujugui we have a maas ! rock on frankban 
<frankban> rick_h_: password is 109b105fe8b699f4b0a2555563502331
<rick_h_> hah, /me wants to deploy something!
<frankban> rick_h_: machine view shows 0-state service 4xGHz, 8.0GB,
<frankban> \o/
<rick_h_> nice!
<frankban> we might want to strip the final comma there ;-)
<rick_h_> and with machine view we can container on that thing and deploy crazy stuff
<rick_h_> lol
<urulama> rick_h_, frankban: did anyone tried juju-gui on manual? i can play with that tonight before going to bed as I wanted to test using mongo shards and multi CS units
<frankban> rick_h_: ghost charm on the bootstrap node?
<rick_h_> frankban: yea, should work
<rick_h_> urulama: 'juju-gui on manual'?
<frankban> rick_h_: in a container?
<urulama> rick_h_: manual environment
<rick_h_> urulama: oh hmm, not sure. 
<rick_h_> frankban: yea, lxc it up
<urulama> rick_h_: ok, i'll let you know
<rick_h_> frankban: my understanding is that the lxc container will get a root 10.0.0.xx ip from dhcp
<rick_h_> frankban: and be able to be exposed at the root network level
<rick_h_> urulama: I think with machine view now you could bring up the machines, add them, and they'd show up in machine view
<rick_h_> urulama: and then you could deploy to them directly
<rick_h_> urulama: but you'd have to add them and such via cli/manual stuff first? 
<rick_h_> ok, bringing up elasticsearch on nuc2 hopefully
<frankban> rick_h_: nuc2 is pending, 0/lxc/0 is pending. man, this GUI thing seems to work just fine
<rick_h_> frankban: <3
<rick_h_> frankban: sometimes, we do damn good work :)
<urulama> rick_h_: yes, adding will have to be done by add-machine unless there is code in GUI that makes this "add-machine" call. 
<rick_h_> urulama: right, it makes an add-machine call but I think in manual you have to provide extra info to that call as to where the machine to add is located
<rick_h_> urulama: and the gui doesn't do that
<frankban> rick_h_: http://10.0.0.155:2368/ \o/
<urulama> rick_h_: ok.
<rick_h_> frankban: woot, ghost looks green and exposed
<rick_h_> haha! 
 * rick_h_ does another round of happy dance and notices son is up...time to prepare for day bare biab
<rick_h_> frankban: you rock thanks again for the pita work on this!
 * rick_h_ goes afk for a little bit
<frankban> and it's not "Just a blogging platform.". it's more "just a blogging platform deployed via a GUI which manages juju on top of a maas controller"
<urulama> rick_h_, frankban: did you try deploying openstack? :P
<frankban> urulama: I don't even know where to start to do that. but for our scope, ghost is as good as openstack ;-)
 * frankban lunches
<urulama> frankban: https://jujucharms.com/bundle/~james-page/openstack-on-openstack/25/openstack/?text=openstack
<rick_h_> frankban: urulama http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/ :P
<urulama> rick_h_: even better :)
<rick_h_> frankban: urulama so I think I'll end up getting a 3rd nuc so we can easily test out bundles on two empty nodes and maybe then we can get openstack on them :P
<rick_h_> oh boo, elasticsearch failed
<rick_h_> oh, it can't reach out to the internet
<rick_h_> no, it did reach out ok. It just got a forbidden for some reason ok
<frankban> guihelp: is anyone available for taking a look at https://codereview.appspot.com/151200043 (quickstart/python)? thanks!
<frankban> rick_h_: thanks for the nice email
<rick_h_> frankban: <3
<bac> frankban: i can look
<frankban> bac: thanks
<bac> ah, i've missed rietveld.
<hatch> like honestly?
<bac> compared to reviews on github, yeah.
<frankban> +1
<hatch> the only difference I can see is that you can queue up review comments
<hatch> but you can also do that on github wtihout clicking 'submit'
<bac> hatch: so you keep each comment in limbo and then submit them all at once?
<hatch> no because queuing up the comments doesn't really bother me :) 
<hatch> but it is possible
<bac> hatch: i also don't like how it collapses and hides your comments when a new revision is pushed.  i find it very hard to follow the review and determine if everything has been addressed.
<frankban> hatch: there are other little things that I miss. For instance, better handling of long lines (when reviewing go code it is useful), ability to comment unchanged code and above all, a way to review patches and follow the review discussion that doesn't drive me crazy
<hatch> reitveld frequently 'forgets' comments when saving so it's really a catch 22
<bac> no, it is a toss up.  it is definitely not a catch 22.  :)
<hatch> lol right
<hatch> maybe if reitveld wasn't so ugly I'd like it more
<hatch> gota get some designers up in that house
 * rick_h_ changes location back to the house. afk
<bac> see, when doing the review i made a comment about some user-facing text but when i did the QA i saw my comment was bogus.  deleted it.  approved the review. no noise from premature comment sent out.
<bac> frankban: +1
<hatch> lol
<hatch> hey luca__
<luca__> hi hatch 
<frankban> bac: thanks
<bac> frankban: amazing that it was so simple!
<bac> rick_h_: you need to add a photo of your MAAS to that document
<hatch> luca__: sent an email to ya regarding the commit summary
<bac> rick_h_: i tried to ssh to the maas but cannot connect.  did you do an ssh-import-id for all of us?
<luca__> hatch: I havenât seen any email...
<luca__> hatch: I just got an email
<hatch> :)
<luca__> hatch: I didnât know this feature was coming!
<hatch> yeah we like to keep you on your toes :P
<luca__> hatch: haha
<hatch> I'm going to land this as is but would be nice to tweak it a bit for the next release
<luca__> hatch: maybe we should schedule a call so you can talk me through it, it seems pretty straight forward.
<luca__> hatch: do we have to land it?
<hatch> well if I don't the code could go stale 
<luca__> ok
<hatch> I'm pretty much free whenever
<luca__> ok
<hatch> with the exception of the standup in 45
<hatch> er 30
<kadams54> guihelp: am I correct in thinking that a revived model (from a LazyModelList) should fire change events automatically?
<hatch> kadams54: yes
<kadams54> hatch: *sigh*
<hatch> lol why?
<hatch> that sounds like a good thing
<hatch> and pretty much the only reason to revive :P
<kadams54> hatch: it would be a good thingâ¦ if that's what I actually saw happening.
<kadams54> hatch: http://pastie.org/private/kndmzbqg3syfm9zgeh21pg
<hatch> looking
<kadams54> That's the change I made. But now my onChange handler function isn't being called at all.
<hatch> and you're sure the revive is being called?
<kadams54> Yeah, got a breakpoint on it
<hatch> and what's the event handler?
<hatch> just the registration part
<kadams54> I'll double-check though. I'm also wondering if something is breaking in event propagation.
<hatch> I'm guessing that there is something wrong with your event registration
<frankban> bac: I can add your keys, what pait are you using? I see four in your lp page
<frankban> pair even
<kadams54> this.addEvent(db.machines.after('*:change', this._onMachineChange, this));
<kadams54> hatch: ^
<bac> frankban: just run 'ssh-import-id bac', if it hasn't been done
<frankban> bac: cool
<hatch> kadams54: yeah that won't work
<bac> frankban: i should probably prune what i've got on LP
<frankban> bac: done
<bac> frankban: and i'm in.  thanks.
<hatch> kadams54: lazy model list doesn't have a change event for attribute changes
<hatch> kadams54: and unfortunately reviving doesn't add the lml as a bubble target
<kadams54> The previous approach, of manually firing the change event, was buggy because the event object wasn't populated with the same info that a change would have in a ModelList.
<hatch> ahh
<hatch> well you can fire a custom event facade 
<hatch> the second param of fire() 
<hatch> nbd just another YUI bug that'll never get fixed now ;)
<rick_h_> bac: woot welcome to maas :)
<kadams54> hatch: yeah, I know I can fire a custom event facade, but that means trying to populate it with the same info that YUI does for changes in a ModelListâ¦ and I'd like to avoid that.
<hatch> well you only have to populate it with the information that your handlers expect
<hatch> which shouldn't be too much
<bac> rick_h_: so you have some poor man's maas?  no orange box?
<rick_h_> bac: yea, I've got a 'rick bought 3 nucs, a switch, and a internet plan with static ips' maas
<bac> rick_h_: nuc-nuc-nuc
<rick_h_> bac: so it took months to come up vs an orange box taking 10min
<kadams54> hatch: the whole point of an event architecture is to decouple so that the code firing the event doesn't have to know about the code subscribed to the event.
<kadams54> hatch: I mean, if that's what I have to do, I'll do it. I'm just hoping there's a better way.
<bac> you should name them larry, moe, and curly
<rick_h_> bac: hah!
<hatch> not without patching lazymodellist
<rick_h_> bac: .95 manual focus lens just arrived wheeee!
<hatch> rick_h_: can't you just turn off auto focus to get a manual focus? ;)
<bac> rick_h_: which one?
<rick_h_> bac: voightlander 17.5mm for m4/3
<bac> that'll be a real challenge to focus i would think
<rick_h_> bac: so m4/3 focus peaking ftw
<rick_h_> it'll take some practice for sure
<rick_h_> but focus peaking should hopefully help
<rick_h_> the hard part is I'm used to setting aperture priority and hitting go
<bac> being that wide, you've got some leeway
<rick_h_> so now it's more set aperture on the lens, focus with peaking, adjust shutter speed to get desired exposure manually
<rick_h_> but .95 is wiiiide open
<bac> wait, can't you leave it in AP and let the camera set shutter speed?
<rick_h_> it doesn't know the aperture since it's done on lens
<rick_h_> it has no contacts to talk to the camera
<rick_h_> the camera thinks there's no lense there
<bac> rick_h_: no, but it has a meter.
<bac> rick_h_: no different from my rangefinder
 * rick_h_ will have to check it out and try
<bac> a step in the right luddite direction for sure
<rick_h_> bac: ah cool. So the aperture shows 0.0, but it does adjust SS for me when I hit go
<bac> rick_h_: but your exif data will be hosed!
<rick_h_> yes, no exif data :/
<bac> mine guesses based on having two out of three data points
<rick_h_> gotcha
<bac> it writes to a different exif field showing that it is not sure
<hatch> I just use my cell phone
<frankban> rick_h_: are you available for a quick second review of https://codereview.appspot.com/151200043 ?
<hatch> < --- professional
<rick_h_> frankban: already looking
<frankban> thanks
<rick_h_> frankban: done, thanks for the changes. The goal will be to work on the release and completing the FFE bugs in the package for utopic after this please.
<rick_h_> bac: now that's shallow https://www.flickr.com/photos/7508761@N03/15411328085/ :)
<bac> rick_h_: 404
<rick_h_> doh, perms
<rick_h_> reload
<frankban> rick_h_: cool thanks, I'll work on a 1.4.4 release after landing this
<rick_h_> frankban: awesome. 
<hatch> rick_h_: that's some seriously shallow dof
<hatch> what;s that, 1"?
<rick_h_> hatch: 5 or 6
<Makyo> Oooh.  Jealous.
<rick_h_> jujugui call in 4
<rick_h_> kanban it up please
<bac> so is my mic not working?
<rick_h_> bac: yea, mic fail
<rick_h_> camera fail
<bac> rogpeppe: under "Mailing List" do you have an Unsubscribe button?
<rogpeppe> bac: yup
<rick_h_> rogpeppe: filter or spam catch it?
<bac> rogpeppe: nm, https://launchpad.net/~juju-gui-peeps/+mailing-list-subscribers
<rogpeppe> rick_h_: i'm looking in Spam
<bac> you are on it.
<rick_h_> "gui maas now available...pretty much" is the exact title
<rogpeppe> rick_h_: i don't think so. when did you send the mail?
<bac> rick_h_: does everyone really have access?  frankban had to manually add me
<rick_h_> bac: no, I need to go through and import ssh keys
<rick_h_> bac: but you me and frankban can now add that in
<rogpeppe> rick_h_: i'm guessing it might just be delayed
<bac> rick_h_: okey doke
<rick_h_> bac: I'll try to run through everyone's LP ids at lunch
<rick_h_> rogpeppe: shared the doc with you and included the email contents in the share notice
<rogpeppe> rick_h_: thanks
<rogpeppe> rick_h_: when did you send the email? was it today?
<rogpeppe> rick_h_: i've got that. i wonder what happened to the mailing list message.
 * rogpeppe is concerned that he may have missed lots more
<hatch> Makyo: did you forget to mark this one as committed? https://bugs.launchpad.net/juju-gui/+bug/1365260
<rick_h_> rogpeppe: whoa, you're not on yellow in LP strange
<rogpeppe> rick_h_: hmm. i am in ~juju-gui-peeps though.
<rick_h_> rogpeppe: added you, should hopefully be all set, not sure on the peeps list but at least on the team wise
<rick_h_> rogpeppe: yea
<rogpeppe> rick_h_: no archives, i'm guessing
<rick_h_> rogpeppe: no, nothing much that you'd be interested yet I don't think
<rogpeppe> rick_h_: cool
<rick_h_> rogpeppe: it's been very gui/machine view focused so far though it's starting to warm up with storefront stuff
<rick_h_> it's handy as the UX team is also on that list, and a few core folks like ramm, kapil, etc
<rick_h_> I'll try to remember to check next time I see something go across
<rick_h_> jujugui ok added ssh keys for the LP users  fabricematrat evarlast jcsackett hatch kadams54 makyo uros-jovanovic martin-hilton rogpeppe to the maas server
<rick_h_> jujugui so if you're not on the list or can't get in let me know
<rick_h_> bac: thanks for the prod
<kadams54> rick_h_: sweetâ¦ will check it out in a bit.
<hatch> rick_h_: so what "can't" we deploy here? Does MAAS create vm's ? So it'll look to us like a bunch of machines? Or does it still only look like 2 machines?
<rick_h_> hatch: it's two machines and you can lxc at will
<rick_h_> so can install most anything you want but bundles of 5 machines can't work
<hatch> ahh so is that where openstack comes in? to create vm's?
<rick_h_> hatch: yes, thought without juju can you bring up a node with bare ubuntu image
<hatch> so MAAS is really the hardware layer then openstack is the vm layer then juju is the orchestration layer
<hatch> we got this stack!
<Makyo> hatch, sorry, bio break.  I'll mark it as committed.
<Makyo> Actually, should be released
<hatch> ahh yes
<jcsackett> jujugui: i need two reviews and a pretty serious (requires real env) QA of https://github.com/juju/juju-gui/pull/600
<hatch> jcsackett: I can get on it once I'm finished mine but I'm running into some testing oddities that are being less than awesome
<hatch> want to get this finished first
<rick_h_> jujugui ok break time for lunch afk
<kadams54> Also lunching.
<hatch> rick_h_: luca brings up a good point in his email re the conflict blocking - should I bench this branch until we can come to an agreement on a real plan?
<rick_h_> hatch: well, I think we should leave the notification for now. 
<rick_h_> hatch: at least it's visible and non-blocking
<rick_h_> hatch: and it's more info that we have today (no hidden config issues) 
<rick_h_> hatch: and we can work out the blocking path
<hatch> rick_h_: ok so remove the blocking of the commit?
<rick_h_> hatch: that's my idea atm, how does that sound?
<hatch> works for me
<hatch> I'll respond to the email with luca
<rick_h_> hatch: k
<hatch> jcsackett: lol nice typod bug
<hatch> containser all the things!!!
<hatch> our minimum wage just went up to $10.20/hr 
<hatch> and there goes the cost of living by the same increase 
<hatch> lol
<hatch> jujugui does anyone know why the inspector breaks when the gui loses connection to its server? Anyone looked into this in their spare time? 
<hatch> jujugui I need reviews and qa https://github.com/juju/juju-gui/pull/599
<hatch> jcsackett: still need reviews and all that?
<jcsackett> hatch: i do. looking to trade?
<hatch> shitty trade but ok
<hatch> :P 
<rick_h_> bwuahahahha
<rick_h_> jujugui I've put the two big bugs into the urgent lane for next steps. They're big enough I'd like to do another release once we get those in. 
<hatch> cool
<hatch> rick_h_: well there goes Ember from the list https://twitter.com/jdalton/status/517370990532497409
<hatch> :)
<rick_h_> hello
<rick_h_> bah
 * rick_h_ test
 * rick_h_ never thought ember was on the list
<rick_h_> hmm, why did that not go out 3 times in a row :/
<hatch> everything is on the list :) I'm being open minded!!!
<kadams54> hatch: is there any way to set e.target when firing an event? I tried: list.fire('change', {foo: 'bar', target: model}) and the target that came through on the other side was still list (and not model).
<kadams54> hatch: Right now I'm considering, as a hack, something like this: http://pastie.org/private/cp1wjtfuigw4bsdxfhhynw
<kadams54> (with comments, of course)
<jcsackett> rick_h_: just letting you know i was able to successfully get onto the maas stuff.
<hatch> kadams54: looking
<hatch> kadams54: so it won't let you set the target?
<kadams54> hatch: doesn't seem to.
<hatch> kadams54: http://yuilibrary.com/yui/docs/api/classes/EventTarget.html#method_fire
<hatch> yeah looks like it will
<hatch> see the arguments definition
<kadams54> Yeah, I know, which is why I though my first approach would work. But that's not the story told in the debugger.
<hatch> well no, the change event has a facade set
<hatch> so it'll overwrite what you're trying to pass
<hatch> kadams54: I think your approach in that pastie is acceptable with comments as per why it's there and where it's coming from
<hatch> kadams54: there are other psudo appropriate ways to do it - setting a custom facade for the event...but no, that's even harder to reason about :)
<hatch> just fyi :)
<hatch> jcsackett: your branch qa's well on sandbox - I'm going to take lunch then will qa the real env
<bic2k> which is the preferred place to file bugs/feature requests: launchpad or github?
<rick_h_> bic2k: launchpad
<rick_h_> I think issues is disabled in github
<rick_h_> jujugui running away for the day. jcsackett if you don't get a second review I'll try to look at it tonight after 
<urulama> rick_h_: have fun
<rick_h_> urulama: get out of here :P I can't EOD before you TZ law
<urulama> :D
 * urulama goes *puf*
<hatch> jcsackett: +1
<jcsackett> hatch: whoo! thanks.
<jcsackett> so glad to be closing in on landing that mofo.
<jcsackett> that db.reset call and 'var db =' thing in the tests were total PITAs to track down.
<hatch> yeah I bet
<hatch> jcsackett: I can't reproduce #1376353 nor does the var in question exist
<hatch> are you sure you didn't have some local branch with a typo?
<jcsackett> hatch: you mean the one about not switching back to services that i filed?
<hatch> yeah
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1376353
<hatch> lazyPower: ping
<lazyPower> pong
<hatch> I'm looking at your bug here https://bugs.launchpad.net/juju-gui/+bug/1375251
<hatch> what do you mean by 'environment clone' ?
<lazyPower> i copied the same entry in environments.yaml (its a manual clone provider, read: DO)
<lazyPower> and deployed a "fresh environment" - with fresh vms and saw the same behavior
<hatch> oh ok so you upgraded from 7 to 8 in the new env and it was the same issue?
<hatch> and you say switching to machine view at any time clears the xy coords? This is very odd - I've never seen that before
<hatch> I wonder if this is a DO specific issue
<jcsackett> hatch: what do you mean the var in question doesn't exist?
<jrwren> jcsackett: was it you that fixed the mysterious jenkins crashing spawned process bug?
<hatch> jcsackett: this._containserHeader is undefined
<jcsackett> jrwren: i think so? you mean the fact that the dev server wouldn't stay up?
<jcsackett> hatch: right, that it's undefined is the problem.
<jrwren> jcsackett: yes. Was there anything other than BUILD_ID=dontkillme environment variable?
<jcsackett> jrwren: nope, that's all it took.
<lazyPower> hatch: actually on the new env it was a straight deployment of 8
<jrwren> jcsackett: thanks.
<jcsackett> jrwren: yw.
<lazyPower> hatch: and yes, switching to machine view at any time clears x/y coords. :(
<lazyPower> hatch: i can run a sample deployment and hand over creds if you want to inspect
<hatch> jcsackett: right but do you see the var name? It doesn't exist in the app
<hatch> lazyPower: ok this must be a DO only issue because I know of a few others using the mv on ec2 without issue in a prod env
<hatch> did you use the DO plugin?
<hatch> or just manually assign the machines?
<lazyPower> i use the DO plugin
<jcsackett> hatch: i don't know what you mean. the line exists in the code, and is coming up undefined. 
<jcsackett> hatch: i do indeed see this._containersHeader
<hatch> jcsackett: oh so the bug has a typo?
<hatch> lazyPower: ok I'll install the plugin and such and give it a try
<hatch> although I'm guessing the issue is DO specific 
<jcsackett> hatch: yup, bug has a typo, i've updated.
<hatch> ok so just tried on develop and alls well
<hatch> in fact I qa'd your branch with it and no issues
<jcsackett> hatch: there is indeed no containers header in my personal env.
<hatch> so possible that yours is broken?
<jcsackett> hatch: how?
<hatch> well I just had a fresh env on ec2 running on develop and it worked as expected
<hatch> I can try again 
<jcsackett> hatch: where do we do the whole "provider has these sorts of containers" thing?
<jcsackett> hatch: it may also be a charm upgrade issue.
<hatch>  environments.providerFeatures = {
<hatch> go.js 2185
<rick_h_> jcsackett: to force headers/etc add :flags:/containers
<rick_h_> jcsackett: it overrides the normal provider settings
<jcsackett> rick_h_, hatch: right, my env is manual, we have nothing for that.
<jcsackett> which i think means anyone trying to use our stuff with the digital ocean plugin is going to have issues too, since iirc that's just a wrapper around manual.
<rick_h_> jcsackett: ok, seems like manual provider is something we might have to check out. Sounds like both your bug and lazyPower's here is causing us issues?
<hatch> yeah this sounds like a manual provider issue
<hatch> I'm in the process of setting up the DO plugin to give this all a try
<rick_h_> ok, so in our list of providers/featuers we offer is manual in that list?
<jcsackett> rick_h_: no.
<rick_h_> I bet that's the issue. We've got the list of features per provider and we're missing one now
<hatch> negative
<jcsackett> i suspect adding it to that with no allowed containers we'll work.
<jcsackett> s/we'll/will
<hatch> oh waitasecond
<jcsackett> we should probably have a sane fallback.
<rick_h_> jcsackett: rgr
<jcsackett> hatch: ??
<hatch> these are all named off the env name?
<rick_h_> hatch: off the provider juju tells us we're using
<hatch> ohh ok *phew*
<rick_h_> hatch: but we didn't include 'manual' I bet and that's blowing up
<hatch> yeah - and what does manual support? nothing?
<rick_h_> :/ no idea
<rick_h_> I'd say to fix the bug we start with nothing
<hatch> haha sounds good
<rick_h_> and land that for the updated release EOW
<hatch> hazmat: any idea if manual provider supports containers?
<rick_h_> and then we can explore making it nicer going forward.
<jcsackett> rick_h_: manual supports nothing, b/c it'll have the same no bridging issue as ec2.
<hatch> ahh ok
<hatch> that makes sense
<rick_h_> hatch: jcsackett right, with manual it could be any platform, we can't tell if lxc or kvm will work/etc
<rick_h_> it could just be my old laptops in a row in a closet
<lazyPower> hatch: manual supports --to lxc:#
<hatch> hmmm
<jcsackett> lazyPower, hatch: technically, so does ec2.
<hatch> heh true
<jcsackett> we say "nope" to containers b/c while you can deploy, you can't then properly use those services without going into the server and mucking with the lxc bridge.
<rick_h_> lazyPower: if you deploy wordpess in an lxc on ec2 and expose it...no worky
<lazyPower> well none of the networking works in terms of --to containers
<rick_h_> lazyPower: so we've cut back that in the GUI to help prevent a lot of bug reports around that until juju supports routing those network connections
<lazyPower> but you can still do it. you're just expected to handle the routing yourself.
<rick_h_> lazyPower: it does in maas :) and juju will support ec2 around end of cycle
<lazyPower> ooo
<lazyPower> fantastic
<rick_h_> lazyPower: rgr, so we have :flags:/containers to enable it anyway
<jcsackett> rick_h_: confirmed, :flags:/containers makes everything work. i'm updating the bug in case someone else encounters this before EoW.
<rick_h_> jcsackett: rgr
<rick_h_> jcsackett: ty much
<jcsackett> rick_h_: hey, happy to help with my own bug. :p
<jcsackett> i love being an actual user of the thing i work on.
<hatch> :D
<hatch> lazyPower: what are you saying in your video? "ssh (tack) keygen" ?
<hatch> your DO video
<lazyPower> yep
<lazyPower> tack = -
<hatch> isn't that a dash? 
<lazyPower> its a 'tack' when i say it
<hatch> lol ok
<lazyPower> but i can see why you'd think its a dash
<hatch> - = en dash â = em dash
<hatch> could that be why? :P
<lazyPower> you've forgotten a very distinct dialect
<lazyPower> - = sysadmin 'tack'
<hatch> ohh - tbh I've never heard it called a tack before
<lazyPower> hack at -
<lazyPower> see what i did there?
<hatch> haha
<hazmat> hatch, definitely does
<hazmat> re containers
<hazmat> hatch, and with the rudder/flannel charm they can talk across hosts
<hazmat> though that makes things work across hosts in any provider
<lazyPower> wait
<hatch> hazmat: right but juju doesn't support the routing so If I created two lxc containers using manual provider and installed wordpress in one and mysql in the other - I couldn't relate them
<lazyPower> we have phaux networking charms that solve this?
<hazmat> hatch, on the same host it would just work
<lazyPower> hazmat: why are we not talking about this more prominently?
<hatch> rick_h_: ^
<hazmat> hatch, across hosts you need one of my container sdn charms
<hazmat> hatch, currently its published as rudder
<hazmat> but upstreamed changed names 
<hatch> ohh so if I had two machines the units couldn't communicate
<hazmat> hatch, let me dig you up the readme
<hatch> I think I'll still set it as disabled in the GUI for now :)
<hazmat> no
<hazmat> hatch, so this charm does the magic sdn across hosts http://bazaar.launchpad.net/~hazmat/charms/trusty/rudder/trunk/view/head:/readme.txt
<lazyPower> and suddenly hazmat just gave birth to the most amazing thing I've heard all day
<hazmat> hatch, it should be a configuration option on gui
<hatch> right but joe user won't know that relations won't "just work" which = GUI bugs which aren't our fault
<hazmat> lazyPower, your right it deserves talking about it
<hazmat> hatch, make it an option
<hatch> you can enable container support using the 'container' flag in the gui
<hazmat> lazyPower, i'm hoping to bring it up at brussels as we should do this or weave as our default sdn, 
<hazmat> as opposed to the broken by default on providers, let's do a works on all providers by default
<lazyPower> I'll give ita go - when you sent the rudder email to the list, it was only 10k feet over my head
<lazyPower> now that you've just put it out there in plain english, i want to blog about this as well
<hazmat> ie. we do the opposite for security groups/firewalls.. we should have universal iptables and then provider specific customization around implementation
<hazmat> as an optimization
<lazyPower> man, we've had this for what, over a month now?
 * hazmat hides
<hazmat> gotta run EOD family time
<lazyPower> o/ tc hazmat
<hatch> cya thanks hazmat
<rick_h_> Makyo: hatch do you guys think we could crank out https://bugs.launchpad.net/juju-gui/+bug/1376464 in one day during sprints?
<hatch> oo fancy
<hatch> where would it go? :)
<rick_h_> no, simple, in the drop down menu in the upper right
<rick_h_> under help and feedback
<rick_h_> or maybe even on the keyboard shortcut menu would be good
<hatch> so that might cause some issues because the flags ususally need to be set pre-init
<rick_h_> hatch: yea, maybe we even go so far as to do a page reload on save
<hatch> so maybe the dropdown could modify the config file
<hatch> then reload
<hatch> yeah
<rick_h_> hatch: meh, I'm thinking straight localstorage
<hatch> ahh that would also work nicely
<rick_h_> and then on load read the key or don't at all the config points
<hatch> yeha that would be a cool project
<Makyo> Yeah
<Makyo> That sounds good.
<rick_h_> hatch: Makyo ok, goal is to do that monday and show it in a lightning talk. 
<rick_h_> hatch: Makyo feel free to hack during flights :P
<Makyo> Hahah
<Makyo> Sounds good.
<rick_h_> I like the idea of putting the checkboxes/etc in the keyboard help
<rick_h_> because people don't know that's there either and it's out of the way regardless of what happens to the header later in life
<hatch> yeah the flag code would need a minor addition to check localstorage
<rick_h_> hatch: right
<hatch> but should be straight forward
<Makyo> Yeah, exactly.
<rick_h_> ok, noted to the bug
<rick_h_> thanks guys
<hatch> rick_h_: maybe in the dropdown a link to open the 'developer tools' for the gui
<hatch> would give us a place to put random dev type things
<rick_h_> hatch: yea, I'm worried about that moving around 
<rick_h_> hatch: longer term
<rick_h_> hatch: but yea, we can find a home
<bic2k> this one is a feature request: https://bugs.launchpad.net/juju-gui/+bug/1376487
<hatch> oh nice one :)
<hatch> bic2k: question - would you want that zoom level saved only on your machine? Or cross the environment?
<hatch> cross env might make for some....interesting...results for differing screen sizes :)
<bic2k> thats why I suggest localStore for it
<bic2k> chances are if you are accessing juju-gui from different machines they will have different browser sizes. That being said, you could store the top x,y offset for all viewers and the zoom locally for maximum effect
<bic2k> but really, per device probably makes the most sense
<bic2k> its easiest to do, dumb in the right ways
<hatch> best kind of enhancements :P
<rick_h_> hatch: is your blog post up?
<bic2k> blog post for?
<rick_h_> hatch: or is tumblr hating still?
<bic2k> ACK, never mind me
<rick_h_> bic2k: machine view post he had prepped but never made it public
<bic2k> rick_h_ thanks ;-) I thought I was in a different window when I read that
<rick_h_> :)
<hatch>  rick_h_ still having issues I'll get it up tonight no matter what
<rick_h_> hatch: gotcha
<rick_h_> huwshimi: morning
<huwshimi> Morning
 * rick_h_ heads off to coffee shop, biab
#juju-gui 2014-10-02
<jcw4> rick_h_: back by any chance?
<rick_h_> jcw4: what's up?
<jcw4> quick question
<jcw4> (and if not it can wait)
<rick_h_> shoot
<jcw4> running juju-gui against local dev version of juju
<jcw4> HACKING.rst is bit-rotted
<rick_h_> jc	:(
<jcw4> is there a quick howto somewhere?
<rick_h_> jcw4: that's it. If it's bitrotten we need to fix it
<jcw4> I have juju local running
<jcw4> the instructions aren't clear how "make devel" hooks up with the local env
<rick_h_> jcw4: oh it doesn't :)
<jcw4> it talks about api-port but doesn't say where exactly
<rick_h_> jcw4: it uses a fake backend (all JS) in devel/etc
<jcw4> have to deploy a charm?
<rick_h_> jcw4: rgr
<rick_h_> best way to go
<jcw4> so any dev changes on the gui side have to be packaged and redeployed?
<jcw4> i.e. no runtime code changes?
<jcw4> on the juju-gui side
<rick_h_> jcw4: so what we do is there's a config on the charm for 'juju-gui-source' 
<jcw4> okay
<rick_h_> that takes a branch name you can set
<rick_h_> and it'll download/load from github/etc
<rick_h_> jcw4: or you can use a tarball at a url, etc
<jcw4> i see
<rick_h_> jcw4: so normally we dev against our fake provider, and then when we QA on live env we'll deploy, set the source to our branch, and test stuff out
<jcw4> hmm, in this case I want to play on the -core side and tweak on the -gui side simultaneously...
<jcw4> okay
<jcw4> that helps a lot
<rick_h_> jcw4: yea, will be interesting. 
<jcw4> if I can improve the docs I will
<rick_h_> jcw4: there are configs on the charm to not use the minimized JS and such
<jcw4> oh
<rick_h_> but it'll take some poking to get at the source in the build dir/etc
<jcw4> okay I'll be sure to check that too
<rick_h_> jcw4: and the normal "make devel" won't work since you won't have a bunch of dev tools
<rick_h_> so it's kind of hacky
<jcw4> hehe
<jcw4> no worries
<rick_h_> but it's enough to get decent tracebacks/etc just to not have it minified
<jcw4> now that I know it's not supposed to 'just work' I'll get my boots on
<rick_h_> jcw4: but yea, config optinos for the source, for enabling the console (console.log/error), and for debug mode should come in handy
<rick_h_> (config options on the charm)
<jcw4> in summary - I'll build the charm with options to keep source un minified
<jcw4> deploy to local juju
<jcw4> and then hack around in the charm dir to tweak code
<rick_h_> deploy to local juju, then once it's up change the config options (or set them on deploy using a config.yaml file)
<jcw4> k
<rick_h_> just like a normal charm, they're just set via "juju set ..."
<jcw4> k 
<rick_h_> see https://jujucharms.com/trusty/juju-gui-9/#configuration
<jcw4> I saw that but now it makes more sense
<jcw4> tx rick_h_ 
<rick_h_> jcw4: cool, np
<rick_h_> there, get annoyed, write some code :P https://github.com/juju/juju-gui/pull/601
<rick_h_> huwshimi: if you're up for a GUI review ^ appreciate it 
<rick_h_> huwshimi: but if you're slammed for luca, that comes first
<huwshimi> rick_h_: OK, I'll take a look if I get a chance
<rick_h_> and booya, managers coding ftw1
<rick_h_> err !
<huwshimi> rick_h_: A couple of notes about the styles, I'll do a proper review later if I don't run out of time today.
<rick_h_> huwshimi: thanks
<rick_h_> huwshimi: I knew you'd call me out on that :P
<huwshimi> rick_h_: There's no excuse :)
<rick_h_> huwshimi: but but but ... yea
<huwshimi> hehe
<rick_h_> ok, time to head home night all 
<huwshimi> rick_h_: Night
<hatch> rick_h_: jcw4 you can hack on the deployed charms code by ssh'ing into the juju-gui instance 
<jcw4> rick_h_: just figured that out a little bit ago
<jcw4> thanks!
<huwshimi> Luca__: Hey are you around yet?
<rick_h_> morning
<frankban> morning rick_h_: do you need a review for your card in maintenance? link?
<rick_h_> frankban: yes please
<rick_h_> antdillon: what are you doing around here?
<antdillon> rick_h_, ha couldnt stay away
<rick_h_> antdillon: I'm going to tell your boss to send you home
<rick_h_> antdillon: did you have your kid?
<antdillon> rick_h_, yeah little girl Chloe
<rick_h_> antdillon: woot! congrats!
<antdillon> rick_h_, thank you very much
<antdillon> rick_h_, dont tell my boss ...
<rick_h_> frankban: can we join our call early please? e.g. now? I want to squeeze it in before I leave for the doc please
<frankban> rick_h_: now is ok
<rick_h_> ty
<rick_h_> jujugui heading off to the morning doc apt. I'll be back in a bit. 
 * frankban lunches
 * rick_h_ is back
<rick_h_> jujugui can I get a second review of https://github.com/juju/juju-gui/pull/601 please and I'd appreciate a second QA as I'm unable to dupe the issue frankban had and curious if others can replicate
<frankban> rick_h_: I had a second QA comment, fixing my first one FYI
<rick_h_> frankban: oh oh oh I see now. You're right, they're not checked based on current value on load. That's bad on my part I'll update in this branch
<rick_h_> should be a simple read/set checked=checked thing in the template
 * rick_h_ misread it at first
<frankban> rick_h_: cool thanks
<rick_h_> jcsackett: around to chat on the feature flag branch?
<jcsackett> rick_h_: rick_h_ ping you in a few? trying to work my way through a mountain of PRs
<rick_h_> jcsackett: rgr
<jcsackett> all small, should be done in just a bit.
<rick_h_> all good, just wnat to make sure I unblock as soon as I can
<rick_h_> unblock you that is 
<jcsackett> rick_h_: that took a bit longer than i thought. you free?
<rick_h_> jcsackett: otp atm
<jcsackett> natch. :p
<jcsackett> well, i'll start reviewing your branch, then.
<rick_h_> jcsackett: free now
<rick_h_> jcsackett: get in while the 10min last :)
<jcsackett> rick_h_: coming to the standup hangout now.
<hatch> running to grab a coffee
<rick_h_> jujugui call in 4 kanban please
<rick_h_> frankban: call
<bac> frankban: did you get a response from homebrew?  after the initial acceptance updates seemed to be automatic in the past.
<frankban> bac: I know, it's like this: https://github.com/Homebrew/homebrew/pull/32866
<hatch> rick_h_: jcsackett fixed the manual provider issue - just need tests now
<hatch> DO is so darn fast compared to ec2 lol
<jcsackett> hatch: whoo!
<hatch> *sigh* the go.js test file is over 2k lines
<luca__> rick_h_: Iâve assigned a card to Huw to build the new footer design, is that ok?
<hatch> jujugui I need a review and qa for a manual provider bug
<hatch> https://github.com/juju/juju-gui/pull/602
<hatch> we have a new footer design? luca__ what did I tell you about changing the design?? HUH HUH?? :P
<hatch> rick_h_: next card of choice for me?
 * hatch started a new js framework last night
<hatch> hmm I sure wish apple had a 4k thunderbolt display - having a hub in the monitor would sure be nice!
<hatch> frankban: thanks for the review
<hatch> frankban: did you qa?
<frankban> hatch: I am bootstrapping a manual env for the first time
<hatch> Ooo :)
<hatch> on Digital Ocean?
<frankban> no, on a vmware machine locally ;-)
<hatch> oh haha I never even thought of doing that :)
<frankban> hatch: it worked pretty fast
<frankban> now switching to your branch
<rick_h_> hatch: can you see if kadams54 or Makyo need help. Priority is to look at getting those up for landing so release is possible tomorrow
<rick_h_> hmm, luca is gone
<kadams54> hatch: I'll need QA shortly ;-)
<hatch> kadams54: lemme know! 
<kadams54> hatch: code changes are minor, so it's mostly QA.
<hatch> I'm a boss at qa
<hatch> I can break anything
<hatch> :P
<hatch> jujugui has anyone else been able to add the calendar in Sarah's email? 
<kadams54> hatch: yeah, just did it.
<hatch> hmm - you used the url and went to Add Url?
<rick_h_> hatch: I've got it from before and can't share it it seems
<hatch> it says that the url is invalid for me
<Makyo>  I got it by pasting the email address in 'Add a coworker's calendar"
<hatch> ahhhh
<hatch> there it goes
<hatch> thanks peeps
<kadams54> http://cl.ly/image/132H0Y3R0l3V
<hatch> kadams54: haha that's cool how did you do that?
<kadams54> cloud.app
<kadams54> https://www.getcloudapp.com
<kadams54> I've started sending animated GIF screenshares instead of typing up 6 page tech support e-mails to friends and family. Very handy.
<hatch> darn osx only
<hatch> we need some of thse for Ubuntu
<frankban> hatch: done
<hatch> awesome thanks
<hatch> kadams54: do you know if this cloudapp will work in fullscreen vm? So I could use it from osx in my ubuntu vm?
<kadams54> I don't, sorry.
<hatch> I have screencloud for Ubuntu but it doesn't do 'video'
<hatch> which would be helpful for some things
<kadams54> Yeah, definitely. Cloudapp just added the video feature in the last release; I was pretty excited to see it.
<Makyo> jujugui reviews/qa please! https://github.com/juju/juju-gui/pull/603
<hatch> I'm on it
<hatch> BOOM, just like that
<Makyo> Thanks.
<hatch> but now you have to review mine :P
<Makyo> Fiiiiine
<kadams54> hatch: you need a second in addition to Makyo?
<hatch> nope frankban got the review and qa
<kadams54> I'm running make check right now for my PR :-)
<hatch> Makyo: I think you missed the 'clear all' functionality
<hatch> wait nm'
<hatch> I am bling
<hatch> blind even
<Makyo> Oh, just forgot that in the QA instructions
<hatch> code looks good - qa'ing
<hatch> Makyo: now that we have this functionality it's quite odd that you can't expose in the ghost inspector
<hatch> thoughts?
<hatch> and done
<kadams54> hatch: https://github.com/juju/juju-gui/pull/604 is ready for QA
<kadams54> ;-)
<Makyo> hatch, it's a little weird, yeah.  Was going to make that a followup.
<Makyo> ...which you said.  So yeah.
<hatch> :)
<hatch> man doing work like this is such a relief post MV release :)
<hatch> frequent releases ftw
<kadams54> Continuous deployment, baby.
<hatch> lol I wouldn't quite go that far :) we do ship a packaged app afterall
<hatch> kadams54: lol got to love the branches where the test loc's FAR exceed the code changes
<kadams54> actual code < test code < time spent on manual QA
<kadams54> Whee!
<kadams54> Plus I had a comparison error yesterday that manifested by breaking other, unrelated parts of the code, even though the QA stuff worked fine. Also whee!
<hatch> kadams54: just a request for the future - if you move code could you add a reviewer comment to point that out so reviewers don't have to stare at the diff for changes when none happened
<kadams54> Ah yeah, good point, will do.
<kadams54> The tricky thing is that some of that did change, so I'll annotate with comments
<hatch> ahh yes plz do :)
<kadams54> Some tests moved into a describe block. New tests were also added to that same describe block.
<kadams54> OK, new tests annotated. The rest of the test deltas is just reorg.
<hatch> thanks
<Makyo> jujugui stepping out over lunch to fedex some things.  Back after.
<rick_h_> jujugui kind of cool, have blog stats from google in image form on the mv blog post http://uploads.mitechie.com/lp/mv-blog-stats.png 
<bac> rick_h_: it was so good, 700 people came back to read it again1
<bac> s/1/!/
<rick_h_> lol
<bac> or that was you 700 times
<rick_h_> well you know me and my refresh button issues 
<hatch> man google maps 'create map' is missing a huge feature "add points from starred" :/
<benji> hi all
<benji> hatch: I have a YUI question for you.  We have an issue on the Landscape project involving clicking on links handled by event handlers before all of the JS has run, causing either nothing to happen or the wrong thing to happen.  Is there a standard YUI approach to that problem?
<hatch> wb benji
<hatch> long time :)
<benji> :)
<hatch> no there isn't a standard problem but there is a common technique to solve it though
<hatch> the first step of course is to try and reduce that time :)
<hatch> the second is a raw js handler which catches all clicks on A's and then queues them up
<hatch> once YUI comes online it re-fires them 
<hatch> s/problem/solution
<hatch> benji: but with that said you should be able to get a running YUI instance within a second
<hatch> hopefully less than 500ms tbh
<hatch> so you might have an architecture problem there
<benji> hatch: good stuff, thanks!
<hatch> anytime
<rick_h_> benji: using a combo loader?
<benji> rick_h_: I honestly don't know.  I've tried to stay away from the JS stuff for a while, but I think I've built my tolerance back up enough to look at it again. ;)
<hatch> lol
<hatch> benji: really try to reduce the load time to be a non-issue first - implementing this can be a hassle. I've done it before :)
<hatch> granted that was 4ish years ago hah
<kadams54> jujugui: heading out, should be back online in two hours.
<benji> hatch: yeah, I'm a little surprised that it can take as long as it does for everything to get into a working state
<hatch> you may have a big blocker in there somewhere
<hatch> ahh machine view is so bawler 
 * hatch feels like he has gold teeth and a rap album when he uses it
<bac> hatch: you don't own any rap albums?
<hatch> maybe some but none with my name on them
<bac> has anyone gotten the 'cloud track' calendar to show up on their freedom-hating phone? it eludes me.
<hatch> bac when you go to "Calendars to display' do you have a button 'Calendars to sync' ?
<hatch> if so - go there and you can add it to the list
<bodie_> how do I get my version of the gui charm up on my local provider?  I'm also going to tweak a simple charm to play with a new backend feature.  I assume this info is in HACKING, but I must be missing something
<bodie_> there's a "local" charmstore you can use, right?
<hatch> bodie_: use the --repository flag when deploying via the CLI
<hatch> https://juju.ubuntu.com/docs/charms-deploying.html#deploying-from-a-local-repository
<bodie_> sweet, thanks
<jcsackett> rick_h_: updates to the kill-mv-env branch sent.
<rick_h_> jcsackett: rgr
<hatch> once you have the GUI up and running you can then drop local charm zip files onto the GUI canvas bodie_
<bodie_> oh, that's handy.  thanks hatch
<hatch> no problem
<hatch> what are you hacking on?
<bodie_> actions
<hatch> ahh cool - I want those
<hatch> :)  
<bodie_> what about to hack on the gui charm itself?  I guess you'd use upgrade?
<bodie_> yeah, we just got the worker / unit bits nailed down finally, and we have the skeleton api landed too
<hatch> I'm not sure about upgrading the gui charm via the gui :) never tried that
<hatch> should work though...heh
<bodie_> what could possibly go wrong?  :P
<bodie_> I was thinking more about using the CLI for that, though
<hatch> sure thing - if you want to hack on the actual GUI code in a live env you can do that too
<hatch> without having to modify the charm
<bodie_> ah, juju upgrade-charm --repository
<bodie_> oh
<bodie_> hm
<bodie_> I guess that's what HACKING covers, right
<bodie_> something about that doc just didn't make things clear to me
<hatch> yeah run `juju help upgrade-charm` for detailed instructions
<bodie_> ok.  thanks again for the pointers
<hatch> np I'll be here for a while yet
<hatch> if you have any more
<hatch> hmm in qa'ing kyles branch I'm having an issue with the gui charm not upgrading the ws
<jcsackett> hatch: lemme know if you want me to test your branch on my env.
 * rick_h_ steps out to throttle someone at a t-mobile store
<jcsackett> rick_h_: when you're back from throttling if you can look at my mv-flag branch so i can move it to landing. :)
<hatch> jcsackett: hey it has been merged
<hatch> jcsackett: it would be awesome if you could qa kyles branch with me
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1376901 I found this bug while doing it so I'd like another set of eyes
<mup> Bug #1376901: Destroying a machine with a container on it causes machine view to break <juju-gui:New> <https://launchpad.net/bugs/1376901>
<hatch> Makyo: https://bugs.launchpad.net/juju-gui/+bug/1375251 requires you to deploy the env using the DO plugin
<mup> Bug #1375251: Juju gui malforms display with missing x/y coordinates on existing env w/ charm upgrade <juju-gui:Triaged> <https://launchpad.net/bugs/1375251>
<Makyo> hatch, yeah, I was just hunting for that.  Have a link handy?
<hatch> Makyo: from lazyPower http://blog.dasroot.net/juju-digital-ocean-awesome/
<hatch> awesome tut
 * lazyPower hattips
<lazyPower> thanks for the feedback
<lazyPower> fyi, thats also in the documentation now
<lazyPower> juju.ubuntu.com/docs/provider-digitalocean.html
<hatch> oh cool
<hatch> the video was really awesome but too bad the sound wasn't quite there
<lazyPower> https://juju.ubuntu.com/docs/config-digitalocean.html   rather
<kadams54> guihelp: Anyone around to provide a second QA and review on https://github.com/juju/juju-gui/pull/604 ?
<hatch> yeah definitely needs another qa
<kadams54> We need more West Coasters ;-)
<rick_h_> kadams54: will look in a bit
<rick_h_> jcsackett: will look
<jcsackett> hatch: i can take a look. be a bit to spin his branch up on ec2.
<hatch> kadams54: haha we used to 
<kadams54> jcsackett, rick_h_: thanks
<kadams54> Switching locations, will be back shortly.
<jcsackett> hatch: so, i'm not going to be able to qa it. amazon is saying it has insufficient capacity. :p
<hatch> lol
<hatch> use DO
<rick_h_> jcsackett: maas time!
<rick_h_> :p
<rick_h_> jcsackett: :+1: ty!
<jcsackett> rick_h_: awesome, thanks.
<jcsackett> rick_h_: the bug is an ec2 bug, alas.
<rick_h_> jcsackett: rgr
<hatch> my internet is super flaky mind if I skip on the aus call rick_h_?
<rick_h_> hatch: np
<rick_h_> hatch: thanks for the updates today to get ready for release <3
<hatch> yeah this fix release is going to be really nice
<hatch> especially if we can keep up doing releases like this
<hatch> really nice to do
<rick_h_> hopefully
<rick_h_> though new feature starts next week so it'll slow down a bit, but smaller features and more releases is good, out of MV's shadow
<huwshimi> Morning
<huwshimi> rick_h_ hatch: Sorry I'm late
<rick_h_> huwshimi: all good
<rick_h_> huwshimi: joining late myself
<bac> hi huwshimi
<bac> urulama-afk: i've submitted a pull request to your CScharmTools branch with working ngram searches.
<huwshimi> bac: Hey!
<bac> huwshimi: have you not left yet?  better hurry or you'll miss opening cocktails.
<huwshimi> bac: haha, yeah, it's a bit like that...
#juju-gui 2014-10-03
<rick_h_> does leankit load for anyone?
<rick_h_> oh there it goes
<huwshimi> rick_h_: Loading fine for me
<rick_h_> huwshimi: thanks, yea I think my net flaked for a minute
<huwshimi> ah cool
<rick_h_> kadams54: <3
<kadams54> rick_h_: I feel like I'm filling out forms in triplicate with this issue :-)
<rick_h_> kadams54: hah
<rick_h_> morning
<urulama> rick_h_: hey
<rick_h_> friday!
<rick_h_> wheeeee
<urulama> indeed
<rick_h_> frankban: bummer on the blockage on quickstart. I thought those were in. 
<frankban> rick_h_: morning, yeah, we need to wait
<rick_h_> bah humbug, don't they know I'm impatient? :P
<frankban> :-)
<rick_h_> "Pull requests 0" in the gui github yay
<rick_h_> frankban: you free to start up a gui release before EOD? 
<frankban> rick_h_: I think so and would be happy to, we are just completing our branch now, release notes appreciated ;-)
<rick_h_> frankban: sure thing, I'll pull them together while you guys wrap up
<frankban> rick_h_: thanks
<rick_h_> frankban: http://paste.ubuntu.com/8485322/
 * rick_h_ goes to make up some coffee 
<frankban> rick_h_:  thanks a lot
<frankban> rick_h_: I'll start the release process after lunch if that's ok
<rick_h_> frankban: rgr
<frankban> rick_h_: 1.2.2 or 1.3.0?
<frankban> (your branch is actually a new feature)
<rick_h_> frankban: I'd just do a 1.2.2 
<rick_h_> frankban: it's small and not backwards incompatible really
<frankban> rick_h_: ok
<rick_h_> more a 'pro user' hidden secret :)
<frankban> rick_h_: so, Madison branch will not be included right?
<rick_h_> frankban: correct, that's not far enough and will take time/is only on the DO plugin atm 
<frankban> rick_h_: ack, ok
<rick_h_> it'll prod us to do regular releases another week wheeee
<frankban> jujugui heads up, starting the GUI release process, please do not :shipit:
<rick_h_> frankban: rgr let's get this release train going!
<rick_h_> heh, /me looks at kanban board pretty empty 
<rick_h_> lazyPower: man, you've got me frame-by-framing your shared video trying to figure out what that GUI error was
<luca__> rick_h_: am I allowed to link to a kanban card in this IRC? :)
<rick_h_> luca__: sure
<luca__> Can I get a status update on this card https://canonical.leankit.com/Boards/View/102529849/111301446
<rick_h_> loading
<luca__> I need that implemented for monday
<rick_h_> luca__: hmm, not sure. Does look like it moved last night. 
<luca__> rick_h_: ok
<rick_h_> luca__: ok, I'll ask jcsackett to take that over in his morning
<luca__> thanks
<rick_h_> luca__: and we'll get it landed asap
<luca__> rick_h_: sweet
<rick_h_> hatch: Makyo as you wake up heads up release in progress, no landings. Board looks clean but just fyi
<hatch> thanks
<frankban> jujugui: release is in progress, but I just uploaded the tarball, so develop is unlocked
<rick_h_> thanks frankban 
<lazyPower> rick_h_: which video?
<rick_h_> lazyPower: the preview of power php one
<rick_h_> lazyPower: there's a bundle error that's shown but I just saw the error go by and took some work to get to see what it was
<lazyPower> arosales did that one. He might have more info as to what was happening
<rick_h_> yea, seems like just a bad bundle
<rick_h_> lazyPower: just giving you a :P for freaking me out thinking there's some bug in a public video on the gui for a minute
<lazyPower> <3
<rick_h_> jujugui call in 9 kanban please
<arosales> rick_h_: lazyPower: bundle in question is @ http://bazaar.launchpad.net/~ibm-demo/charms/bundles/turbo-lamp/bundle/view/head:/bundles.yaml
<arosales> I just needed to show how to install the full solution and show one service coming up.  There may still be some issues with that bundle, but would like to hear them if folks find them
<arosales> I did remove the version so it could just deploy the latest
<rick_h_> frankban: rogpeppe1 ^
<rick_h_> fabrice: ^
<rick_h_> errr by & I mean call time
<rogpeppe1> rick_h_: what's bad about that bundle??
<hatch> rick_h_:  sorry which card was it that you wanted me to hop on?
<rick_h_> rogpeppe1: so there was an error about the bundle not having a metadata.yaml file
<rick_h_> rogpeppe1: sorry, the mariadb charm from that bundle
<rogpeppe1> rick_h_: ah
<rick_h_> hatch: if that's fixed, removing pyjuju would be an awesome end to 'clean all the things' week
<rick_h_> rogpeppe1: so in the video you see teh GUI report and error and took some playback control fun to freeze the frame to see what the error was
<hatch> oooo yay
<rogpeppe1> rick_h_: ah, nice
<rick_h_> hatch: pick something else if you want, but it's on my wishlist so merry christmas to me? :P
<hatch> nah I want it gone also
<hatch> it
<hatch> yeah I'm moving this card to already done
<hatch> Pretty confident that the old code was removed
<rick_h_> jujugui taking down guimaas to prep it for lightning talk on monday
<rick_h_> frankban: do you have a .juju/environments.yaml for the guimaas? looks like it's all been blown away?
<rick_h_> oh wrong machine ignore me
<frankban> rick_h_: so, it's no longer in /home/ubuntu/.juju/environments.yaml?
<frankban> rick_h_: oh ok
<rick_h_> frankban: ignore me, case of the friday's 
<frankban> :-)
<frenda> If I install juju-gui will be result the same as: https://jujucharms.com ?
<rick_h_> frenda: almost. jujucharms.com is setup in a demo mode with some of the charm config values changes
<rick_h_> frenda: however, if you deploy it in a live environment, it helps you control that juju environment, so it's not the exact same 'demo mode'
<frenda> As I described in #juju, Is suitable for my aim? I'm going to make a hosted solution for my app such as: www.ghost.org ?
<frenda> Is it*
<rick_h_> frenda: looking at the other channel traceback
<rick_h_> frenda: there's tools there for doing that but it's not setup out of the box to just do it. 
<rick_h_> frenda: you'd want to charm up your software and work out how to install it to a cloud provider with lxc containers or something to help create enough client density
<rick_h_> frenda: https://www.youtube.com/watch?v=pRd_ToOy87o&list=UUJ65UG_WgFa_O_odbiBWZoA gives you some idea of hosting ghost with juju and how it looks in the gui
<frenda> >  there's tools there for doing that
<frenda> Do you know any tools? A search phrase?
<rick_h_> frenda: sorry, no. I mean there are building blocks in juju to do that. If you did things like charm your app, setup proxy ability, script the deployment of the services for new users via the juju api, etc
<frenda> ah, ok
<frankban> rick_h_: charm precise ftests failed on setting the branch source: http://pastebin.ubuntu.com/8486711/
<frankban> rick_h_: git is giving more troubles
<frankban> rick_h_: I'd be inclined to test on trusty, and if it succeeds there, proceed with the release and add a card
<rick_h_> frankban: rgr, that's a known issue I thought? 
<frankban> rick_h_: it seems to be intermittent though, the last release worked
<frankban> rick_h_: I'd just disable that functionality on precise, I'd add a card for that and proceed with the release if you afree
<frankban> agree ven
<rick_h_> frankban: yea, that's true. I didn't get that failure in my release either
<rick_h_> frankban: rgr sounds good ty
<frankban> rick_h_: release done, charm pushed, waiting for ingestion
<rick_h_> frankban: ty much
 * rick_h_ gets some lunchable
<Makyo> hatch, have you reproduced that bug on digitalocean?  I get weirdness, to be sure, but not that one, and not in version 9.
<Makyo> Oh, shoot, just realized I was on dev version of juju, let me poke around in 1.20 land
<hatch> Makyo I was not able to reproduce it however lazyPower says he can do it at will
<Makyo> hatch, lazyPower investigating in 1.20.8 now.
<Makyo> lazyPower, did v9 or v10 play any better than v8?
<lazyPower> Mayo I have not upgraded past 8
<rick_h_> 10 out today wheeee
<lazyPower> I can give it a go later and sync on Brussels art reproduction
<lazyPower> *makyo ^
<Makyo> lazyPower, sure, that sounds good.  I've got some stuff I can poke at until then.
<lazyPower> Sorry. Fat fingers Ã phone makes for interesting typos
#juju-gui 2014-10-04
<jcw4> rick_h_: trivial PR : https://github.com/juju/juju-gui/pull/605 -  I believe websocket protocol is always wss:// now, never ws://
<rick_h_> jcw4: yea, that looks like it's configured via the config-debug.js "socket_protocol" now thanks
<rick_h_> jcw4: will be on a plan soon so afk for a bit. Sorry for the lack of response if you need anything
<jcw4> rick_h_: no worries, thanks for the info, safe travels
#juju-gui 2015-09-28
<tvansteenburgh> frankban: i just put juju-deployer-0.6.0 on pypi, any chance you could do a ppa release?
<frankban> tvansteenburgh: I'll do a release tomorrow if that's ok, is it urgent?
<tvansteenburgh> frankban: tomorrow would be great, thanks!
<frankban> cool
#juju-gui 2015-09-29
<mhilton> morning all
<frankban> tvansteenburgh: deployer 0.6 released
<tvansteenburgh> frankban: thanks!
#juju-gui 2015-09-30
<dimitern> hey GUI team ;)
<dimitern> I'm trying to import a bundle in the GUI and getting "Error generating changeSet
<dimitern> There was an error generating the changeSet. See browser console for additional information"
<dimitern> there's nothing in the console log of the browser
<dimitern> frankban, fabrice, (others eu-based?) ^^
<frankban> dimitern: weird that there is nothing in the console
<frankban> dimitern: could you please paste me the bundle?
<dimitern> frankban, yeah - it's https://jujucharms.com/mediawiki-scalable/10
<dimitern> frankban, I've modified it slightly for a demo - the only changed thing is adding constraints; the YAML is valid (used yamllint.com) - http://paste.ubuntu.com/12623296/
<frankban> dimitern: uhm... if I just click add to demo in that page the uncommitted state is generated correctly
<dimitern> frankban, here's my test env: https://52.29.12.21/
<dimitern> frankban, 23351c36e3b1df5d7dc256673a2203e9
<frankban> dimitern: so I believe that the GUI server does not know about the spaces constraints
<dimitern> frankban, ah :/ too bad
<dimitern> frankban, can I patch it somehow for the demo?
<frankban> dimitern: do you need to deploy the GUI as part of the demo or is it already set up?
<dimitern> frankban, I need some way to both show the deployment and deploy the bundle, and I didn't want to use juju-deployer
<dimitern> frankban, I deployed the gui first --to 0 
<frankban> dimitern: ok, but the juju-gui charm is deployed pre-demo right? so that you can hack on it before the demo
<dimitern> frankban, yes, absolutely
<frankban> dimitern: ok, let me deploy it in a local env so that we can try this
<dimitern> frankban, I even plan to deploy the bundle before the demo and just show the gui and poke with the CLI a bit
<dimitern> frankban, local env won't work for the spaces constraints - they're ignored everywhere but on amazon for the moment
<dimitern> frankban, and you need to use 1.25 or master
<frankban> dimitern: I don't want to deploy the bundle myself, I just want to make it load as uncommitted state
<dimitern> frankban, ah, got you ok
<dimitern> frankban, fwiw spaces constraints have exactly the same format as tags - comma-delimited,using ^ to indicate "not"
<frankban> dimitern: ok
<frankban> dimitern: I was able to ave that bundle imported as uncommitted state
<frankban> dimitern: first: juju ssh juju-gui/0 sudo nano /usr/local/lib/python2.7/dist-packages/jujubundlelib/validation.py
<frankban> dimitern: use the editor to update _CONSTRAINTS so that it includes a 'spaces', line
<frankban> dimitern: then restart the gui server: juju ssh juju-gui/0 sudo service guiserver restart
<frankban> dimitern: at this poijt your bundle should work
<frankban> point even
<dimitern> frankban, awesome! thanks - will try it now
<frankban> dimitern: cool
<dimitern> frankban, it did import fine after this! thanks again :)
<frankban> dimitern: yes, we should update bundlelib and make a new charm release with that little change. is spaces constraints for 1.26?
<dimitern> frankban, it's for 1.25 even
<frankban> dimitern: ok, I'll add a card, good that we found this hack for next week
<dimitern> frankban, yeah, a bit last-minute, but you know how it is with such demos :)
<frankban> dimitern: heh, all good
<dimitern> frankban, hmm.. there might be more needed btw - i'm watching the deployment as it happens and it seems the spaces constraints were not applied
<frankban> dimitern: uhm... that's the GUI side
<dimitern> frankban, could it be because the gui adds machines first and then deploys --to them, rather than using ServiceDeploy API ?
<dimitern> frankban, I've exported the current bundle from the GUI and indeed the constraints from the bundle are not there - http://paste.ubuntu.com/12623497/
<frankban> dimitern: let me check the resulting bundle changes
<dimitern> frankban, ok
<frankban> dimitern: ok so the bundlelib does not handle service constraints, but only machine constraints :-/
<dimitern> frankban, right, is there another lib to modify then?
<frankban> dimitern: so the server side fix is easy enough, not sure about the client side JavaScript
<dimitern> frankban, just running: juju add-machine --constraints spaces=dmz did the right thing from the CLI
<frankban> dimitern: in your bundle, can you add spaces to machines rather than services?
<dimitern> frankban, yes - I'll try now
<dimitern> frankban, I tried importing this bundle - it worked, but still the machine didn't end up in the right place (i.e. spaces constraints were ignored) - http://paste.ubuntu.com/12623583/
<frankban> dimitern: ok trying
<frankban> dimitern: ok these are the corresponding changes and they look reasonable (spaces is in there): http://paste.ubuntu.com/12623599/
<dimitern> frankban, yeah - the machine constraints look sane, but the service it seems it's not supported - that's fine, as long as the machines end up in the right place
<frankban> dimitern: in the javascript console, network tab, you should be able to see the websocket requests made by the GUI (there is a WS filter), I am bootstrapping another env
<frankban> dimitern: service constraints are not currently handled
<frankban> dimitern: that's a current limitation of the GUI
<frankban> dimitern: I mean, the changes do not include service constraints, and this needs to be changed
<dimitern> frankban, ok, I'm looking at the network log + ws filter
<dimitern> frankban, if we can make at least the machine constraints work, it will be great
<frankban> dimitern: the machine constraints should already work
<dimitern> frankban, but not for spaces=..
<dimitern> frankban, unless I need to patch some other place?
<frankban> dimitern: let's see what's sent to the server
<dimitern> frankban, I see no WS requests.. let me try destroying and re-deploying the last bundly
<dimitern> bundle
<frankban> dimitern: to check ws requests we can also try the following: juju set juju-gui builtin-server-logging=debug
<dimitern> frankban, I've seen the api WS after refreshing the page, committing now and will see what happens
<dimitern> frankban, I've added the logging before this
<frankban> dimitern: juju ssh juju-gui sudo tailf /var/log/upstart/guiserver.log
<dimitern> frankban, there's quite a lot, let me paste it
<frankban> dimitern: note that it will include passwords
<dimitern> frankban, yeah, hence - paste.c.c - https://pastebin.canonical.com/140855/
<frankban> dimitern: that does not seem to include the deployment calls
<dimitern> frankban, what should I look for? Type: ChangeSet ?
<frankban> dimitern: AddMachines?
<dimitern> frankban, just a sec
<dimitern> frankban, not found - let me check earlier in the log
<dimitern> frankban, this is the full log so far - https://pastebin.canonical.com/140857/
<dimitern> frankban, no addmachines 
<dimitern> frankban, oops sorry
<dimitern> frankban, it seems I've hit a js exception which left the gui paused in the debugger, so the change set was not committed, doing it now
<frankban> dimitern: ok client -> juju: {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"Series":"trusty","Constraints":{}}]},"RequestId":13}
<frankban> dimitern: I've found the bug, and that's a GUI bug
<frankban> dimitern: the constraints are empty there
<dimitern> frankban, ah! ok
<dimitern> frankban, yeah, sound like a bug
<frankban> dimitern: can you confirm that no constraints are applied (not just the spaces one)
<dimitern> frankban, yes - none of the services deployed by the gui have any output from juju  get-constraints <svc>
<frankban> dimitern: so the GUI server return a change with constraints (after the  little hack). the GUI has those constraints in its internal uncommitted state, but when turning the uncommitted state into actual API calls the GUI does not send the constraints to AddMachines
<dimitern> frankban, nailed it then :)
<frankban> dimitern: yes looking at the code I can confirm that constraints are ignored by the AddMachine client call
<frankban> dimitern: so we have two GUI bugs (service constraints are ignored server side by the bundlelib, machine constraints are ignored client side by the GUI). I am sorry about that, so the deployer (or quickstart) could be an option at this point
<dimitern> frankban, hmm - wait a sec - is the gui using "AddMachines" client API or "AddMachinesV2" ?
<frankban> dimitern: {
<frankban>         Type: 'Client',
<frankban>         Request: 'AddMachines',
<frankban>         Params: {MachineParams: machineParams}
<frankban>       }
<frankban> dimitern: so facade version shoudl be 0, the request is Client.AddMachines
<dimitern> frankban, yeah, actually it doesn't matter - both end up calling the same backend method on the apiserver
<dimitern> frankban, so AFAICS it constraints are present in machineParams they are honored
<dimitern> s/it/if/
<frankban> dimitern: they are not, but we can try the ultimate hack
<dimitern> frankban, :) sure?
<frankban> dimitern: so... juju set juju-gui juju-gui-debug=true 
<frankban> dimitern: this is required so the GUI is served from non-minified files that we can edit on the unit
<dimitern> frankban, ok, done
<frankban> dimitern: now edit the /var/lib/juju-gui/juju-gui/build-debug/juju-ui/store/env/go.js file on the GUI unit
<dimitern> frankban, I'm there
<frankban> dimitern: search for "_addMachines:"
<frankban> (without quotes)
<dimitern> frankban, yeah - the method I presume?
<dimitern> @method _addMachines
<frankban> dimitern: add "Constraints: param.constraints," after Series in the machineParam definition
<dimitern> frankban, done and saved - restart guiserver or just refresh the gui?
<frankban> dimitern: just refresh the GUI should be sufficient
<frankban> dimitern: hard refresh is better (shift + referesh)
<dimitern> frankban, I even did ctrl+shit+f5 for good measure - now adding a machine with some constraints via the gui
<dimitern> frankban, ..aaand it seems it worked! - I can see r3.xlarge spinning up after adding mem=16000
<frankban> dimitern: now we should try it with a bundle
<dimitern> frankban, yep, but first let me destroy all but the gui first..
<dimitern> frankban, ok all is nice and clean now - redeploying the modified bundle with machines constraints specified..
<dimitern> frankban, will it screw things up if I use machine ids like "1", "2", in the bundle? I mean - my last machine ID is 14, so should I change the to: - "X" and machines: "X" to use the next ID 15 etc?
<frankban> dimitern: the machine ids in the bundle are not related to the identifiers in the actual environment, it's just a way to assign units to machines
<dimitern> frankban, ah, cool!
<frankban> dimitern: so you should always be able to use 1, 2 etc.
<frankban> dimitern: at least that's how we intended it in the spec, hope that the GUI reflects that :-)
<dimitern> frankban, ok, here goes nothing ... fingers crossed and all - committing .. :)
<frankban> dimitern: now it's a good moment to tailf guiserver logs
<dimitern> frankban, hmm.. ok - will do - it's doing fine for now though..
<frankban> dimitern: \o/
<dimitern> frankban, hmm.. not really - constraints are still ignored AFAICS - checking the logs now
<dimitern> frankban, yeah - AddMachines still has empty constraints
<frankban> dimitern: okso they are passed when ading machines manually, but they are still ignored when deploying an uncommitted state
<dimitern> frankban, right, so can we fix this? sorry I'm taking so much of your time for this BTW, it's really appreciated - even if we can't fix the above, it should still be possible to do the demo by first manually adding machines and then deploying the bundle's units to them
<frankban> dimitern: investigating
<rick_h_> frankban: dimitern only half read the traceback, would this work with your branch frankban ?
<rick_h_> frankban: dimitern 1 to work around the gui issues and two to perhaps follow a shorter path on the future work?
<frankban> rick_h_: my branch?
<rick_h_> frankban: bundle deployment branch
<dimitern> rick_h_, hey there :) btw this is actually the first time I'm using the gui for more than 2m :)
<frankban> rick_h_: machine constraints should work, not the services ones because the changes format reflects the one used by the GUI, and I have cards for fixing that
<rick_h_> dimitern: sorry it's not going magically for you :/
<rick_h_> frankban: ok figured I'd ask
<frankban> rick_h_: but it's worth trying. my impression is that dimitern was trying to use the GUI, otherwise also the deployer would probably work
<rick_h_> dimitern: this is part of the fun of keeping up with core features when we miss/don't have the support through all the tool chain unfortunately
<dimitern> rick_h_, it's totally fine, not complaining :)
<rick_h_> frankban: well for a demo in front of sabdfl I'd like to avoid using the deployer if at all possible
<rick_h_> frankban: and if it could use the upcoming stuff that makes him smile...mega win
<dimitern> rick_h_, +1 me too
<dimitern> frankban, rick_h_, guys, I need to step out for ~30m, will ping you when i'm back
<frankban> rick_h_: +1
<rick_h_> frankban: if the gui can be made to work that's all good as well
<frankban> rick_h_: I've found the problem with the API call, and now machine constraints work with the hack I described above if you manually add a new machine. they are still ignored if you use ecs. I checked and ecs.changeSet includes the correct args as returned by the GUI server, so we'll need to investigate where we loose them
<rick_h_> frankban: understand. 
<frankban> dimitern: oh wait
<frankban> dimitern, rick_h_ actually go.js handles machine constraints, I didn't see the if (param.constraints) {
<frankban>           machineParam.Constraints = self.prepareConstraints(param.constraints);
<frankban>         }
<dimitern> frankban, rick_h_, I'm back now
<dimitern> frankban, so then change another method?
<frankban> dimitern, rick_h_ so basically this is fixed in pyramid-fork (not ready to use)
<frankban> dimitern, rick_h_ looks like we need to backport https://github.com/juju/juju-gui/pull/821
<urulama> frankban: is this the only branch needed to be backported?
<frankban> dimitern: so basically the change that needs to be done in go.js is not the one I suggested, but the one at https://github.com/juju/juju-gui/pull/821/files. so add a bunch of lines at the beginning of prepareConstraints
<frankban> dimitern: could you please try to copypasta those lines?
<dimitern> frankban, I see.. ok I'll try this diff from the PR now
<frankban> dimitern: the diff will not apply
<frankban> dimitern: the pyramid-fork branch has a very different file structure
<frankban> dimitern: copypaste is your only options, and it's just those lines in the PR
<frankban> dimitern: you only need the changes in go.js, other stuff are tests and makefile
<frankban> urulama: yes that's the only brancvh to be backported for now, but then you'd need a gui release
<frankban> urulama: let's see if the hack works
<dimitern> frankban, yeah, I'll cherry pick it manually and add the lines 
<frankban> dimitern: cool, let me know how it goes
<urulama> frankban: ok, let's see. we have some gui bugs to fix, so it can land alongside those
<dimitern> frankban, sure, will be 1/2h perhaps - need to eat something :)
<frankban> urulama: this is actually a big bug, meaning machine constraints are not applied when deploying bundles. it didn't hit us because there are not so many bundles with constraints
<urulama> frankban: did you already add a defect card for this?
<frankban> urulama: it's a task in urgent
<urulama> kk
<frankban> urulama: what we need after seattle is 1) update jujubundlelib so that it sends service constraints and it allows "spaces" as a constraint 2) update the GUI ecs to reflect the changes in jujubundlelib, 3) release jujubundlelib and the GUI 4) update bundlechanges as well 5) update guibundles to use newer bundlechanges and to send the service constraints
<urulama> frankban: maybe someone can pick it up even during Seattle
<frankban> urulama: 1) might include other changes, since we are modifying the protocol, I have cards for all the changes we want to make
<urulama> frankban: cool, ty
<frankban> urulama: yes, but I'd like to have a pre-impl call with the implementer before
<frankban> urulama: these are the changes I'd like to make to jujubundlelib/bundlechanges protocol: 1) support service constraints, 2) in addService changes, make the charm argument a placeholder pointing to the correspondig addCharm change, 3) remove the num_unit argument from addUnit changes, since it will always be 1 unit, 4) maybe s/deploy/addService in the addService method, for consistency
<urulama> frankban: how come 3) will always be 1?
<frankban> urulama: because each addUnit change only adds a single unit
<frankban> urulama: so if you want to add 10 units you get 10 addUnit changes back
<urulama> frankban: ah, ok, misread that num_unit as part of bundle yaml ...
<urulama> frankban: multitasking ftw :)
<urulama> frankban: ok, noted. this can probably wait till end of Seattle
<frankban> urulama: I think so
<dimitern> frankban, it *almost* worked :)
<dimitern> frankban, {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"Series":"trusty","Constraints":{"arch":"amd64","cpu-cores":1,"cpu-power":300,"mem":3840,"root-disk":8192}}]},"RequestId":21}
<frankban> dimitern: so now the constraints are passed, all but the spaces one correct?
<dimitern> frankban, spaces are not included though - the bundle has this line: constraints: "arch=amd64 cpu-cores=1 cpu-power=300 mem=3840 root-disk=8192 spaces=dmz"
<frankban> dimitern: I would not expect anything different ;-)
<dimitern> frankban, right - could it be because it's not a string but an array?
<frankban> dimitern: is it?
<dimitern> frankban, well, as json it should be serialized the same way as "tags=foo,^bar" (IIRC "tags: ["foo", "^bar"]")
<frankban> dimitern: how the server expects spaces to be passed?
<frankban> dimitern: so the comma separated string is not ok?
<dimitern> frankban, nope, it should work the same I guess..
<dimitern> frankban, I can't see any specific handling for "tags" or "networks" (I wouldn't expect it for the latter, but at least the former is useful)
<frankban> dimitern: there is
<frankban> dimitern: so first I think we should add "spaces" to the genericConstraints list in go.js
<frankban> dimitern: the in prepareConstraints there is a piece of code like http://pastebin.ubuntu.com/12624766/ and we should do the same for spaces if we need to send an array
<dimitern> frankban, trying it now
<frankban> dimitern: something like http://pastebin.ubuntu.com/12624773/ I guess
<dimitern> frankban, \o/ !! it worked
<frankban> dimitern: wheeee
<dimitern> frankban, I think this gives me enough to prepare for the demo - just let's summarize what was needed in order to get there:
<frankban> dimitern: well, that was not straightforward, apologies for that, really!
<dimitern> frankban, no, it's fine, seriously - we should sync-up more often with you guys and use the gui a *lot* more
<dimitern> frankban, would it work if I just patch go.js with the last 2 changes ? (i.e. not touch guiserver ?)
<frankban> dimitern: you still need to allow spaces in validation.py
<dimitern> frankban, I guess since service cons are not used, it's not worth specifying them in the bundle for services, just machines?
<dimitern> (I have them in both places now)
<frankban> dimitern: so the bundle should only include machine constraints
<dimitern> frankban, exactly
<frankban> dimitern: service constraints are ignored
<dimitern> frankban, yeah
<frankban> dimitern: still you'll need to add 'spaces' to _CONSTRAINTS in validation.py, because I believe the same function is used to validate service and machine constraints
<dimitern> frankban, I see, ok
<dimitern> frankban, and also enable the juju set juju-gui juju-gui-debug=true
<frankban> dimitern: then you need to apply the changes in go.js, excluding the one I suggested intiially, just the backport and the two most recent ones
<frankban> dimitern: yes, otherwise the minified files are server, and your changes do not have effect
<frankban> (go.js changes)
<frankban> dimitern: so, for sanity, I'd suggest to 1) deploy the GUI 2) apply the juju-gui-debug=true option 3) change validation.py and go.js and 4) restart the GUI server
<dimitern> frankban, sweet - all written down in my notes, will retry the whole thing from scratch tomorrow, just to make sure it's fine
<frankban> dimitern: since we are not planning to release a GUI before seattle, you could script that as well 1) deploy 2) set 3) scp 4) ssh
<frankban> dimitern: sure, and you'll find me here tomorrow
<dimitern> frankban, sweet! thanks a million for all your help! :)
<frankban> my pleasure
#juju-gui 2015-10-01
<dimitern> frankban, rick_h_, just FYI - I managed to patch the 1.4.5 release's guiserver and go.js and simply deployed juju-gui from a local repo with juju-gui-debug enabled by default - simplifies our demo steps and works great! :)
<frankban> dimitern: yay!
<lazypower> Just circled back to the publish proposal. +1 - thanks for linking that rick_h_ 
<rick_h_> lazypower: awesome ty
#juju-gui 2016-10-04
<konobi> howdy all
<konobi> I'm having a problem with juju-quickstart
<konobi> it appears that juju is doing inspection of the private key it's trying to use, does that sound right?
#juju-gui 2016-10-05
<konobi> does this look like a juju-quickstart error: `ERROR there was an issue examining the environment: cannot create credentials: An error occurred while parsing the key: asn1: structure error: length too large`
#juju-gui 2019-09-30
<fabriceincafe> hi, it's fabrice, I am in a coffee place but can't join irc so using kiwiirc on this juju gui channel
