#juju-gui 2013-07-01
<rick_h> morning
<rick_h> anyone have links to the new UX I can peek at. I got a link in a hanguot from sinzui the other day but I can't find it in the juju-gui g-docs folder now :/
<jcastro> hey guys, I need a relatively complex screenshot of something in the GUI
<jcastro> anyone have anything handy?
<rick_h> jcastro: complex in the form of a big deploy in the environment?
<jcastro> yeah
 * rick_h tries to look up how to load the gui with the old large rapi json setup
<jcastro> yeah! something hairy.
<rick_h> whoa, takes a little bit to load up the rapi on this, not sure I ever ran this before lol
<rick_h> hmm, not that crazy after all. Just a lot of notes. 
<rick_h> jcastro: http://uploads.mitechie.com/lp/gui-large-json.png is what the large.json looks like
<rick_h> jcastro: not sure if you need something w/ w/o the browser and such
<jcastro> dude that is perfect
<rick_h> k, then there you go
<jcastro> rick_h: it'll be in my blog post today!
<rick_h> jcastro: is that ok to blog the browser?
<jcastro> I cropped
<jcastro> only did the blocks/canvas
<rick_h> gotcha, cool
<jcastro> yeah the thought crossed my mind while I was drafting
<jcastro> "oh wait, I like my job!" snip.
<rick_h> yea, it's kind of strange since the proejct/source is open and anyone can see it
<rick_h> will be nice when it's all past
<jcastro> security through "no one is deploying from trunk"
<rick_h> sinzui: ping, got a sec to chat?
<sinzui> rick_h, maybe in 5
 * sinzui is with IS about canonistack environments
<rick_h> sinzui: rgr, shoot me an invite when you're free please. I want to sanity check the upgrade path and such for adding this download field
<sinzui> rick_h, jcsackett: do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/drain-ingest-queue/+merge/172353
<rick_h> sinzui: I can in a sec
<rick_h> sinzui: trade ya https://code.launchpad.net/~rharding/charmworld/total-stats/+merge/172356
 * sinzui looks
<Makyo> jujugui call in 6 kanban now
<rick_h> sinzui: r=me
<Makyo> jujugui call in 2 - Gary's out; if anyone has a burning desire to run the call, cool.  I will if not.
<sinzui> rick_h, I expect DISTRO_CHARM_DATA in charmworld/views/tests/test_charms.py to be updated. I think it documents which attributes are exposed by the old API. I believe we want to add the new attr and be certain we don't loose it when we drop old API. Am I wrong?
<rick_h> sinzui: looking
<rick_h> sinzui: I'm coming up empty with bzr grep DISTRO_CHARM_DATA 
<rick_h> ?
<sinzui> oh, was it not landed...
<sinzui> ah!
<rick_h> I pulled trunk this morning?
<rick_h> or thought I did
 * rick_h goes to try agasin
<sinzui> rick_h, not out problem. abentley cannot land his branch until exodus is available. He will need to update his branch since yours is r=me and can land now
<rick_h> sinzui: ah ok
<rick_h> jcastro: screenshot looks good in the blog post :)
<jcastro> YEAH!
<Makyo> Oh, forgot to mention in the call, did a blog post this morning about service placement. http://jujugui.wordpress.com/2013/07/01/focusing-on-services/
<rick_h> sinzui: staging went boom it appears?
 * rick_h wonders if I did that :/
 * sinzui looks
<sinzui> rick_h, it can go down for 15 minutes if it thinks it needs to do a full ingest and it was not previous configured to do so
<sinzui> has it been more than 15?
<rick_h> sinzui: not sure, just noticed it
<rick_h> sinzui: I figured there had been enough time post-merge for things to happen
 * sinzui visits the server because he has no oops in email
<rick_h> sinzui: yea, it appears the wsgi app isn't running. apache is just dying
<sinzui> apache is running. I think you mean the the app is down 
<sinzui> I see it stopped about 30 minutes ago
<rick_h> sinzui: right, wsgi (app, pyramid, etc)
 * sinzui tries to manually
<sinzui> ingest is angry.
 * sinzui considers new dequeue power as a possible fix
<rick_h> sinzui: :/ ok. I guess I did do something. /me tries locally again. 
<sinzui> rick_h, I see this in the errors: http://pastebin.ubuntu.com/5817422/
<rick_h> sinzui: yea, that's just a bad charm. It should carry on I thought. 
<sinzui> I will dequeue, then restart to give ingest a chance to start
<rick_h> sinzui: rgr
<rick_h> sinzui: yea, it seems to run ok here locally so hoping I didn't break anything. 
<sinzui> the webapp is up http://staging.jujucharms.com/
<sinzui> search works
<rick_h> sinzui: cool, looks good. I just wanted to see the downloads stuff in the api ok
<sinzui> rick_h, I will look further at the logs to look for the root cause
<rick_h> sinzui: k, let me know if you think I need to peek at something. 
<rick_h> jujugui jcsackett sinzui can I get a pair of reviews please? https://codereview.appspot.com/10832043 As noted, ignore the giant json files (2) and it's known that this won't QA against mjc at the moment. 
<benji> rick_h: I'll lake a look.
<rick_h> benji: ty much
<rick_h> sinzui: and when you get a sec, want to verify what's next highest in priority please. 
<sinzui> rick_h, there was an error in migration for the config-changed event, preventing the app from restarting
<sinzui> http://pastebin.ubuntu.com/5817453/
<rick_h> sinzui: :/ ok. In my test it ran fine. Will follow up with a check for the other key first then. 
<rick_h> sinzui: so that migration did not succeed. I'm safe to update it in place correct?
<sinzui> rick_h, I think we cannot assume the charm_data has the key. There are 5  charms that are invalid in the store, so cannot possibly have the value
<rick_h> sinzui: rgr
<rick_h> sinzui: yea, and in my limited set pulled down locally didn't have any of those
<sinzui> rick_h, You want to move your migration to the next number. Replace your old number with a no op.
 * sinzui looks at review
<sinzui> rick_h, nm.
<rick_h> sinzui: on the no-op, nevermind?
<sinzui> rick_h, since your migration did not complete, I don't think migrations could have incremented the number. I think you can update your migration script as it is
<rick_h> sinzui: cool, that matches my thinking. 
<rick_h> sinzui: did you want to sanity check this then? It's small enough that I'd like to get up vs reset db and pull down all of the charms in the db to try to get the bad ones
<rick_h> sinzui: https://code.launchpad.net/~rharding/charmworld/fix-downloads-migration/+merge/172386
<sinzui> rick_h, Looks good
<rick_h> sinzui: cool
<sinzui> rick_h, do you want to see the staging oops?
<rick_h> sinzui: sure. I'm assuming it'll oops until the migraiton hits. 
<rick_h> sinzui: guessing it's an attr not found issue on the sort from ES since the migration didn't pass muster
<sinzui> http://pastebin.ubuntu.com/5817523/
<rick_h> sinzui: yea, that's the ES error if downloads isn't in the charm to do the order by for the /interesting url. Once this change lands and migrations take place should be good 
<sinzui> ^ rick_h Since the server was offline for the migration, everything should be migrated. Ingest is not involved in the oops
<sinzui> of, I thought the change had just landed.
<sinzui> s/of/oh/
<rick_h> sinzui: it's approved, but has to go through jenkins
<rick_h> sinzui: so should be a few minutes
<sinzui> oh, right, it does not claim to be merged
<Makyo> Remembered I totally had a dream about our comment style last night.  I'm not sure how I feel about that.
<rick_h> Makyo: time to seek help
<sinzui> rick_h, LGTM
<rick_h> sinzui: thanks
<rick_h> here jenkins jenkins...here boy...
<rick_h> sinzui: branch is merged now it appears. Might get some error emails as I poke at staging again.
 * sinzui nods
<rick_h> sinzui: ping, got a sec to help me out? Sorry, but can't get mutt to open the old ssh config email to access stagnig myself
<rick_h> sinzui: and I'd like to not leave things broken at EOD
<sinzui> staging fell over?
<rick_h> sinzui: well, the numbers aren't updating as I'd expect post-merge
<sinzui> oh
 * sinzui looks
<rick_h> sinzui: and I can't get into staging to verify if it's still upgrading, the migration didn't run/errored again, etc
 * rick_h had hoped all would be well at this point
<sinzui> oh, I think this is my fault
<sinzui> I did not clear the upgrade error from last effort
<sinzui> rick_h, sorry. this is my fault. I do need to address the charm error before tarmac can do its job
<rick_h> sinzui: ah, ok. Then I won't feel so bad then. Thanks for the heads up. 
<rick_h> I've got to run and pick up the plate for the camper from the dealer before they close today, but I will check in tonight or tomorrow morning then. Thanks for the help today sinzui. Appreciate it.
<sinzui> rick_h, np. I will do the QA as best as I can given that I need your branch to kick the charm back to life
<benji> jujugui: I could use a couple of reviews for my drag and drop critical fix branch: https://codereview.appspot.com/10834043
<sinzui> rick_h, everything looks good. After resolving, I used juju charmworld set revno=191 and waited for the reconfiguration: http://staging.jujucharms.com/api/2/charms/interesting shows me  downloads and downloads_in_past_30_days.
<Makyo> benji, on it.  Code LGTM, QAing.
<rick_h> sinzui: thanks! looks good now. 
<sinzui> np
<rick_h> benji: around still?
<rick_h> benji: curious about your email and the two bits around config panel/"charm site being down" 
<benji> rick_h: I got this message in a popup "Charm API server did not respond"
<rick_h> benji: ok, do you know what url that was? Was it consistent? We're not aware of any issues on the server today. Staging had issues during QA but nothing is pointing at it. 
<benji> rick_h: XMLHttpRequest cannot load https://manage.jujucharms.com/api/1/charms/interesting. Origin http://localhost:8888 is not allowed by Access-Control-Allow-Origin. 
<rick_h> benji: ah, please pull from trunk. api 1 has been deprecated about a week now and should be api2
<rick_h> https://manage.jujucharms.com/api/2/charms/interesting should be the updated url and trunk should generate that for you. 
<benji> rick_h: I was doing a binary search to find the point a regression was introduced, so that's not in the cards 
<benji> I'll add this to my list of why having self-contained dev builds is good.
<benji> :/
<rick_h> benji: ah, gotcha. :/ then we'll have to runa local charmworld instance. api1 has been removed from the server. So less that the server was down, and more that it's using an old version that won't be responding 
<rick_h> benji: yea, I know jcsackett and I do that since we work on both parts of the code and often have to have them sync'd. 
<rick_h> benji: please make sure to make some noise when you feel the server is 'down'. If it is and we've not said anything we need to jump on that and if it's something else we might be able to save you some time. 
<benji> will do; thanks for the info
<rick_h> benji: so fyi, r272 removed api1 from the charmworld source. Running charmworld should be an easy bzr branch ... && make sysdeps && make install && make run
<rick_h> sinzui: we should probably deprecate old apis into a 'dead end' route that displays a warning as well. 
<sinzui> +1
<rick_h> sinzui: will file a bug real quick
<huwshimi> Morning
<rick_h> huwshimi: howdy
<rick_h> huwshimi: if you get a chance would like to chat on the controls stuff. 
<huwshimi> rick_h: Sure, if you've got a minute
<rick_h> huwshimi: yea, let me get my headphones
<rick_h> huwshimi: invite on the way
<rick_h> darn it, how do you just create an empty hangout any more
<huwshimi> rick_h: Dunno, didn't get an invite
<rick_h> huwshimi: yea, you don't show up in my list so just trying to create an empty one but can't seem to figure out how to do that any more
<rick_h> huwshimi: https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997?authuser=1
#juju-gui 2013-07-02
<gary_poster> hey benji, thanks for the report.  frankban and teknico are out this week, so it is all North America to get this done.  (1) could you give me more details on manage.jujucharms.com being down yesterday?  I didn't hear anything else about it, and that's a big deal (if not directly related to the release issues).  (2) Was Makyo helping you yesterday?
<rick_h> gary_poster: I talked with benji about it. Going back in revisions caused the code to try to use a deprecated api endpoint
<benji> sure...
<rick_h> gary_poster: I'm working on a branch currently that displays a 410/deprecation message for that going forward. 
<benji> yep, the only thing that was down was the old version of the API that is no longer being served
<benji> (we should consider making the GUI dev environment self-sufficient)
<gary_poster> rick_h, benji, ah excellent.  that one is off the list of worries then :-)
<benji> :)
<benji> I should have followed-up that email.
<rick_h> benji: yea, we went back/forth on running a local charmworld instance before but hadn't hit a real need. http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/index.rst is the getting started guide for it. 
<gary_poster> yeah, charm world needs to be very reliable and highly available so the only driver I have for work like that is off-network development
<rick_h> gary_poster: right, the trouble is that as we change things the data format gets tied to the api versioning and it causes issuse when you want to go back in time like this
<gary_poster> benji, was Makyo available to help you with #2 and #3 from my email yesterday
<gary_poster> rick_h, ack.  the only issue there is time, I think
<rick_h> well, in this case it's more we've been trying to de-couple the data format from the api data presented but anyway...
<benji> gary_poster: he was available, but we didn't work together on it; I had a bit of a communication fail and didn't reallize there was anything critical to do until about lunch time so I only had time to work on the drag and drop issue and do the binary search as far as I got
<gary_poster> benji, ok thanks.  I think getting him involved may be faster and more productive than the binary search at least for the relation lines issues.  I'm not sure what the best approach is for the config issue
<gary_poster> maybe binary
<gary_poster> I have two meetings this morning before daily call
<gary_poster> and I have to get a document about bundles finished this week, which means today and tomorrow, and ideally finished today
<gary_poster> so I'll be primarily focusing there
<rick_h> gary_poster: is this 'config' issue that dragging a charm to 'deploy' it doesn't open the config in the right panel for the charm? It was working for me on uistage yesterday. 
<benji> that sounds fine with me; once he is available I'll work with him on it, until then I'll finish up the search for the introduction of the two bugs
<gary_poster> rick_h, from benji's email: "I also noticed what seems to be a
<gary_poster> bug in that the config panel is not displayed when deploying the
<gary_poster> service."
<gary_poster> I hadn't seen that either.  can try to dupe
<rick_h> gary_poster: right, I guess I'm asking "is config panel the config panel I think it is?"
<gary_poster> heh
<rick_h> ok, well if others are unable to dupe maybe I'm following along ok.
<gary_poster> good question rick_h, maybe that's a question for benji.  like I said I will try to dupe.  I interpreted it as the pre-inspector config panel
<rick_h> because I know we've fixed that config panel on deploy twice now. 
<gary_poster> yeah
<rick_h> and I did it last time so threw me off that it wasn't working
<gary_poster> was thinking we must not have tested that properly :-/
<gary_poster> unit I mean
<benji> yep, I was referencing the "old" config panel 
<gary_poster> k
<gary_poster> will try to dupe
<gary_poster> benji I had to hard reload the browser, then it worked fine
<gary_poster> the config panel I mean
<gary_poster> benji, well, the sizing is broken :-(
<gary_poster> but it shows
<gary_poster> wait a sec
<gary_poster> sometimes does sometimes doesn't?
<benji> good stuff
<gary_poster> benji, it is broken after a DND
<gary_poster> but works after an Add button
<benji> interesting; I'll try the same
<gary_poster> benji, I suspect this has something to do with translating the charm info
<rick_h> gary_poster: benji ok, does DND not go through the same deploy event maybe? There's a tweak needed when creating a Charm model instance from a BrowserCharm
<benji> it could
<rick_h> it's in the event for the deploy button 
<gary_poster> rick_h, benji, yeah hatch was saying something about this
<benji> rick_h: on trunk, no it does not; that is one of the changes my review fixes branch will include
<rick_h> http://paste.mitechie.com/show/976/
<rick_h> benji: ah ok. Yea, if options aren't mapped to 'config' then it won't show all the config fields to edit
<benji> it is odd though, because I am seeing the same behavior in pre-DND versions of trunk
<rick_h> benji: yea, it was broken for a little bit and I fixed it in the last couple of weeks
<rick_h> benji: which is why I was surprised it wasn't working :/
<rick_h> but that was through the add button since it was pre-dnd
<rick_h> #1190265 to be exact
<_mup_> Bug #1190265: adding a service does not load all config <charmbrowser> <juju-gui:Fix Released by rharding> <https://launchpad.net/bugs/1190265>
<gary_poster> benji, specifically to dupe, you need to *first* DND with a given charm.  Subsequently, all deployments of that charm, including with Add, don't work.  conversely, if you start with Add, DND will work.  Also, switching to messing with another charm resets.
<rick_h> gary_poster: I'd imagine that the charm model is cached and is missing the config attribute
<gary_poster> rick_h, yeah, figured it would be something like that
<rick_h> gary_poster: so any other work around that model will fail
<benji> gary_poster: that makes sense; thanks for the info
<gary_poster> welcome
<gary_poster> Makyo, hi.  when you get in I'd like to know if you have a task in allhands now.  If you do, please go ahead and fill those in and we can do the signing dance
<gary_poster> hatch, you might also have your issues resolved in allhands.  Could you verify, and if everything is ok, also enter your goals?
<gary_poster> (when you get in :-) )
<rick_h> adeuring: r=me
<rick_h> jcsackett: looking over yours now
<adeuring> rick_h: thanks!
<hatch> morning
<hatch> gary_poster: alright I'll check it out
<gary_poster> morning hatch, thanks
<rick_h> jcsackett: lgtm with inbound notes. 
<hatch> gary_poster: allhands done! (hopefully correctly this time) :)
<gary_poster> great thanks hatch, will look soon :-)
<hatch> rick_h: woah you bought a book on dead trees??? ;)
<rick_h> hatch: yea, programming reference material doesn't work great on 6" digital form factors imo
<hatch> haha nope it doesn't
<benji> Makyo: are you in?
<Makyo> benji, yep.
<benji> Makyo: we should work on the relation line offset issue, when you are available
<Makyo> benji, wrt service menus?
<Makyo> gary_poster, submitted.
<gary_poster> yay, thanks Makyo :-)
<benji> I don't understand the question.  They are initiated by the service menu...
<gary_poster> benji, he's talking about #3 on my original email
 * benji re-reads.
<Makyo> benji, the service menu has been removed for OSCON under the serviceInspector flag to bypass that.  It is a problem that needs to be fixed, but it'd be good to prioritize with other inspector panels.
<benji> Makyo: oh, nope, this is without any flags
<gary_poster> sinzui, rick_h, I notice that download counts are currently absent in the charm browser.  I know there's been some work here.  Is that a known issue?
<jcsackett> rick_h: agree that it would be better to land it with the flag, but i wanted eyes on it now. i can delay landing if sinzui sees no problems with that in our workflow.
<rick_h> gary_poster: yes, we're waiting on a backend deploy to provide the data
<Makyo> benji, I suppose I was under the impression that it had be deprioritized because the menu was going to be removed. I suppose I could pass off Francesco's branch to focus on this, though.
<hatch> jujugui can I get some reviews https://codereview.appspot.com/10690046/ thanks :)
<sinzui> gary_poster, we haven't deployed yet
<bac> hatch: i'm about done with one
<rick_h> gary_poster: since it's displayed/hidden and not error prone and we're asking for a deploy figured it was 'safe' for a short run
<hatch> bac: ahh cool thanks, as you will notice I didn't really use much of what you had already :) sorry
<rick_h> jcsackett: no, it's basically a refactor as is, so did LGTM it but was looking for the config side and took a sec to realize it wasn't there
<bac> hatch: why is display.serviceName not rendering?
<bac> on the settings page?
<rick_h> adeuring: can you peek at https://code.launchpad.net/~rharding/charmworld/old-api-endpoints/+merge/172549 please?
<adeuring> rick_h: sure
<benji> Makyo: Gary made a criticial card for this and asked that you and I work on it, so prioritizing it seems appropriate
<rick_h> adeuring: thanks, maybe I can get it in while sinzui's on calls and get it in before the deploy 
<Makyo> Buh.
<Makyo> Okayl
<hatch> bac: looking
<Makyo> jujugui, Someone take Francesco's branch?
<jcsackett> rick_h: ok.
<jcsackett> sinzui: call?
<hatch> bac: the model may not have a displayName property
<sinzui> gary_poster, there wont be an interruption caused by the deploy because the fast-and-safe process is being used now. But with a robust server, we are allowing mediocre charms to be visible. There are a lot of charms that haven't ever been deployed (from the store).
<sinzui> jcsackett, yes
<hatch> rick_h: lemme know how those books are - if they are good I'll pick some up too :)
<rick_h> hatch: will do
<benji> Makyo: I don't think there is anyone else available.  It'll probably be there for you when we get done.
<adeuring> rick_h: r=me
<rick_h> adeuring: thanks
<Makyo> benji, Okay.  So you're on #3 from the email, then?
<benji> Makyo: nope, #2
<benji> although, I am able to dupe without drag and drop
<Makyo> benji, I haven't been able to reproduce that one.  Give me a sec to try some more.
<benji> it looks a lot like a bug from a couple of months ago
<Makyo> How so?
<hatch> benji: I'm a little confused by your email - it sounds like you are reproducing number 3 not 2
<benji> hatch: my reading of 3 is that it requires a feature flag be enabled to reproduce; I am not enabling any feature flags
<benji> hatch: it may be that I am describing a new bug
<hatch> ok but #2 is that the relation line breaks after they are connected
<hatch> so it sounds like you're talking about #3
<hatch> maybe we need a quick chat
<benji> hatch: I see that as well as the end of the relation line being offset while tracking the mouse cursor position
<hatch> yeah the offset is #3 and it's caused by the menu
<gary_poster> apparently my laptop is going to fail randomly over the next few days
<gary_poster> something to look forward to :-)
<hatch> haha uh oh
<hatch> blame the hardware right?
<gary_poster> heh yeah, or the guy who installed the modifications to it (me) :-)
<gary_poster> if anyone said anything to me after rick_h told me that we were waiting on a backend deploy to provide the data, I missed it, fwiw
<benji> I told you nitrous oxide wouldn't be good for your laptop.
<rick_h> gary_poster: just saying it'll be fixed later today :)
<rick_h> so yes, known issue
<gary_poster> :-)
<gary_poster> cool thanks rick_h 
<rick_h> sinzui: the deprecated api endpoints branch is merged so when we do the deploy can we include that as well?
<rick_h> benji: so heads up ^^ old api endpoints will soon 410 Gone to help debugging that stuff. 
<benji> thanks for the info, rick_h 
<Makyo> benji, can you test with  lp:~makyo/juju-gui/rel-fix ?  If that works, I'll explain what happened.  If not, then it's probably not worth it :)
<hatch> bac: maybe I missunderstood the purpose of this branch - I thought it was primarily a UI branch so I never hooked up the 'saving' of the new settings
<Makyo> Wait, hold on benji 
<benji> heh
 * benji holds.
<Makyo> benji, Sorry, forgot commit.  It's ready now.
<benji> k
<bac> hatch: huh.  if that's the case we need to make certain there is a card in place for hooking things up.  the casual observer would assume that the fields were live.
<hatch> the wireframe doesn't have a UI for 'save' so I wasn't really sure what to do haha
<hatch> I suppose it could look like the one in the pre-deployment panel
<gary_poster> arosales, sinzui are you all able to come to the design GUI meeting
<arosales> gary_poster, on my way, wrapping up a meeting
<benji> Makyo: your branch appears to fix both flavors of issue 2.  I can't reproduce any relation line problems with it.
<Makyo> benji, re: pending relations?  I still have yet to reproduce the bug described in #2, with a completed relation.
<jcsackett> jujugui: could i get a second review of https://codereview.appspot.com/10870043
<benji> Makyo: if by "pending" you mean "clicking on 'Build relation' and dragging one end of the relation around", yes.  Also the "wait a little while and the relation line end no longer is in the right position" flavor of #2
<Makyo> benji, I just reproduced that right as you said it, heh.  
<hatch> jcsackett: on it
<jcsackett> thanks, hatch.
<Makyo> gary_poster, can we get some confirmation/clarification on which problem is #2 and which is #3?  If this fixes one of them, I'd like to propose.  If it's more complex than that, I'll switch.
<benji> Makyo: you reproduced the second (lets call that one "unstuck relation lines")?  Is that on your branch or an unfixed branch?
<gary_poster> Makyo, sorry on call.  happy wih landing incremental improvements
<benji> Makyo: my reading of #3 is that reproducing it requires a feature flag be enabled.  I have not enabled any while working on this.
<Makyo> benji, yes.  The only thing I fixed was in the mousemove event handler when creating a relation.
<Makyo> benji, I suppose we can agree to disagree.  Can we disambiguate differently to pending and created?
<benji> Makyo: we can call them whatever we want.  There are two fairly different bugs described in https://bugs.launchpad.net/juju-gui/+bug/1195934 which Gary called "2" in his email.
<_mup_> Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934>
<benji> (note that I can reproduce the pending relation bug without drag and drop)
<hatch> jcsackett: the branch is looking good - but should it not be configurable and set via the config.js files?
<jcsackett> hatch: this is one step; subapp needs to support a variable default. the next step is the config flag.
<jcsackett> this bit seemed like something i wanted eyes on earlier, and was landable without the second bit.
<jcsackett> rick_h: got a sec to chat?
<rick_h> jcsackett: sure
<hatch> jcsackett: sure thing - review done
<Makyo> benji, that'
<Makyo> That's what I reproduced.
<Makyo> The fix is for #3. No flags, because it's a problem with creating a relation from the service menu (which was removed with the flags we have)
<benji> Makyo: define "that"
<Makyo> benji, A created relation pointing to where a service used to be if you drag services around and let the simulator cycle a few times.
<benji> I do not drag anything to reproduce the bug I am talking about.  
<Makyo> benji, That being the pending relation line showing up somewhere offset from the cursor when you move your mouse?
<benji> Makyo: yep
<benji> Gary's repro instructions are in this comment of the bug he labled "2": https://bugs.launchpad.net/juju-gui/+bug/1195934/comments/2 (but I don't have to do step 3 to repro)
<_mup_> Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934>
<benji> (and I don't have to use drag-and-drop to deploy the services to see the problem)
<Makyo> benji, My reading is that refers to a created relation line, rather than a pending one, since it's a verification of the attached image.  I reproduced the behavior in the bug description, and my branch is for an unrelated problem (that of starting the relation build process from the service menu)
<benji> Makyo: I agree with your reading too.  The problem is, as best I can tell, is that there are actually two bugs being described there.  
<hatch> benji: Makyo I was the one who found these bugs so I can probably help you decide which is which :)
<benji> Makyo: perhaps we should do some screen sharing so we can be explicit about what we are doing to reproduce each bug
<hatch> sounds like a plan
<Makyo> Sure.
<Makyo> in guichat
<hatch> jcsackett: PBDD lol
 * jcsackett laughs
<Makyo> benji, hatch https://codereview.appspot.com/10873043
<hatch> on it
<hatch> Makyo: there is only a single `svg g` right?
<Makyo> hatch, yes.
<Makyo> Same construct is used for pending relations created via the long-click method, which is why that works and this didn't.
<hatch> ok - can you create a property to store that? it's making a DOM query every time the mouse moves now :)
<hatch> I kind of wish YUI would cache those queries but I suppose I understand why it doesn't
<Makyo> jujugui call in 6 kanban now
<hatch> woops thanks Makyo
<Makyo> hatch, done, reload rv
<bac> Makyo: is that your card in maint?  add your face?
<Makyo> face: added
<hatch> Makyo: thanks! lgtm'd
<Makyo> jujugui call in 2
 * Makyo manages to make a coffee before then. Might as well attack migraine with everyone's favorite vasodilator.
<gary_poster> argh
<bac> Makyo: you already have two reviews: benji and hatch
<Makyo> Oh.  Bonus.  Thanks bac
<bac> Makyo: i put my name on it but they beat me to it
<hatch> https://codereview.appspot.com/10690046/
<bac> hatch: the problem with service.displayName is not really an issue as the wireframes just have 'Service settings'.  so you should change to that static string.
<hatch> ahh ok
<hatch> I was just about to go through this new wireframe
<hatch> looks like it has a cancel and confirm button for settings
<hatch> so that answers that question
<bac> yeah, old and new both have that
<bac> ('Service settings' i mean)
<hatch> gary_poster: this dropbox example is still a WIP?
<gary_poster> hatch, yes
<hatch> ok 'll hold off then as I'm sure my comments are just things he hasn't gotten to yet :)
<gary_poster> :-) cool
<hatch> hehe firefox only - who would have thought
<hatch> ;)
<hatch> benji: thanks for the review
<benji> my pleasure
<Makyo> benji, hatch https://codereview.appspot.com/10876044
<hatch> Makyo: on it
<hatch> Makyo: this is great that these fixes were so trivial - I am wondering if these things should be documented somewhere - like an idiots guide to our d3 system :)
<Makyo> hatch, that's one of my goals.
<hatch> eggcelent :)
<sinzui> Yesterday "pending" meant local juju deploys is broken. Today "pending" means local juju deploys might work.
<hatch> SchrÃ¶dinger's Pending ?
<hatch> you never know what pending means until you observe it :)
<sinzui> hatch exactly. Pending public address might mean juju doesn't have cloud-templates to build the lxc. pending status means the contain built, and I am waiting the the charm to tell me don't attempt to call a script you haven't unpacked yet.
<hatch> this sounds like a future bug request in the making ;)
<sinzui> I think the problem is ultimately between th seat and the keyboard.
<hatch> "error: pebkac"
<sinzui> Though, maybe juju should admit it depends on cloud-utils to deploy to lxc
<sinzui> hmm, I cannot see how cloud-utils got uninstalled since lxc-templates requires it.
<hatch> bcsaller: can we remove the 'simulator started' console logs? :-)
<bcsaller> fine by me
<hatch> fyi all - the font mime type warnings will be going away in chrome soon...YAY!
<rick_h> can i get some reviews on this please? Since it's a -req branch from Huw's work which has not been reviewed I couldn't get reitveld to do the diff cleanly. https://code.launchpad.net/~rharding/juju-gui/new-controls/+merge/172631 
<bcsaller> hatch: that was there when it defaulted to off and had a hot key trigger for dev work, but its not needed now
<rick_h> hatch: jcsackett sinzui  Makyo ^^
<rick_h> it won't be anything that lands until huw's work completes and he'd pull this into his work to land
 * sinzui looks
<hatch> bcsaller: ahh ok - I just notice it spams the test logs, will remove :)
<rick_h> hatch: yea, saw that. Very cool
<rick_h> hatch: one day, we might get an empty console on load! :P
<hatch> lol keep dreaming
<hatch> rick_h: reviewing
<rick_h> hatch: oh come on!
<hatch> haha
<rick_h> hatch: thanks for the peek at the review bit. 
<hatch> yesterday it was 30c and 50% humidity - was pretty sure I was going to melt
<rick_h> hatch: yea, it's finally cooled off here the last couple of days. 
<hatch> it's so hot the wind refuses to blow
<hatch> rick_h: so how am I supposed to comment? just ping you in here?
<rick_h> hatch: yea, or you can leave comments in the MP there. 
<hatch> index.html:15 spacing issue
<rick_h> hatch: I've got a reitveld review up but it sucked ina bunch of extra stuff. 
<rick_h> https://codereview.appspot.com/10877043
<hatch> i'd say haha
<sinzui> rick_h, does this branch have revisions other than trunk
<rick_h> hatch: but I'd like to get my bit 'ok'd' and huw can pull it into his work safely
<rick_h> sinzui: yes, it's dependent on huw's branch in the MP
<sinzui> yeah, I see "download" changes and drag-drop changes
<rick_h> https://code.launchpad.net/~huwshimi/juju-gui/visual-update-1
<hatch> bac: could you take another look at my branch and LGTM if you like
<rick_h> sinzui: yea, MP kept the new trunk updates out of the way, but reitveld wants to bring things from trunk that have changed as well
<bac> hatch: ok
<rick_h> sinzui: why I tried to stick to the LP MP first
<sinzui> rick_h, I think you can tell lbox your branch depends on another to limit the changes shown
<rick_h> sinzui: I did, this is with the -req="" flag used
<sinzui> rick_h, its okay. I know how to get a diff of just your changes.
<rick_h> lbox propose -cr -v -edit=true -req="lp:~huwshimi/juju-gui/visual-update-1"  (command used)
<sinzui> ah, Lp is correct
<gary_poster> hatch, bcsaller, benji, Makyo hi.  please head over to allhands and do the counter-sign sometime in the next hour or so
 * hatch has no idea what you're talking about but looking ;)
<hatch> countersigned!
<hatch> unless I screwed something up again :P
<rick_h> hatch: quit breaking things!
<hatch> ""The objective sheet can't be anymore updated"" lol
<hatch> rick_h: oh I got this down!
<hatch> I don't think I'll be able to break it again until next year
<hatch> rick_h: your widget events should be documented with @event and IMHO the controls should be a view instead of a widget
<Makyo> gary_poster, done.
<rick_h> hatch: so they don't share a common parent to be a view and it's splitting an existing widget so kept the things working. Plus the widget doesn't 'render' output like the view would
<gary_poster> cool thanks guys.  hopefully it will show up in my list of tasks soon.
<gary_poster> but anyway your side is done
<rick_h> hatch: so disagree? :) I could make it a pure JS class vs a widget, but again just trying to split work on existing code. 
<sinzui> rick_h, I seethis.publish(this.EVT_TOGGLE_FULLSCREEN);
<sinzui> but you removed the definition of EVT_TOGGLE_FULLSCREEN
<rick_h> hatch: as for the @event, you're right. /me goes to look at someone doing that right to copy
<Makyo> jujugui, Can I get another look at https://codereview.appspot.com/10876044/ ?  Last critical.
 * sinzui thinks it is undefined
<rick_h> sinzui: thanks, yea that sohuld be the two new events fullscreen/sidebar
<hatch> rick_h: reviewing to see if I can be convinced (re widget)
<Makyo> Oops, second to last, sorry.
<benji> Makyo: I'll review it if you still need one (I was lunching)
<rick_h> hatch: yea, I can be convinced to drop Y.Widget I suppose, but not to a Y.View. 
<Makyo> benji, Sure, that'd be good.  Thanks.
<hatch> rick_h: so the idea is that this progressively enhances an element already on the page to add these events and the like?
<rick_h> hatch: rgr
<rick_h> hatch: the navigation header has already been rendered in index.html and this binds browser events to it
<rick_h> sinzui: pushing that fix now, hatch fix also includes @event docs in the new widget.
 * sinzui looks again
<hatch> cool - ok so will agree that a view probably isn't the right way, but a widget is way to heavy
<hatch> could this go in an app.js extension?
<hatch> er
<hatch> browser app extension
<rick_h> hatch: no, it needs ot be in the browser subapp to go through it's viewState code. 
<rick_h> ah, hmm...well maybe kinda. It puts some UX responsibility up to the app level like that. Maybe a View extension...
<hatch> do you agree that a widget for this is too heavy?
<benji> gary_poster: countersigned
<rick_h> hatch: yes, I agree that it's heavier than needed, but trying to split work vs ditch widgets. 
<rick_h> hatch: and it's a single instance, each view destorys/recreates as you toggle so not a lot of overhead. 
<gary_poster> thanks benji
<hatch> brb 2min will think about it
<bac> hatch: done
<hatch> bac: thanks
<gary_poster> rick_h, is the charm store something that runs per environment, or is it something that runs in a known location, like m.j.c?  I don't understand what the charm store is, or how m.j.c uses it.  I only understand that it is the way that Juju finds charms.  Can you explain or give me a pointer to an explanation?
<rick_h> gary_poster: heh, I've always been a bit fuzzy myself. sec, let me get the url. 
<gary_poster> thans
<gary_poster> k
<sinzui> gary_poster, the charm store is a website without pages
<gary_poster> sinzui, ah ok thanks
<gary_poster> rest API sinzui ?
<sinzui> gary_poster, yep rest and json. The charm browser aggregates data from it Lp, jenkins, and a local run of proof
<rick_h> gary_poster: so the only instance I know of for it is https://store.juju.ubuntu.com and we get stats like downloads from it via api calls like https://store.juju.ubuntu.com/stats/counter/charm-bundle:precise:apache2
<gary_poster> sinzui, so m.j.c essentially just provides indexing of the data in the charm store?
<hatch> rick_h: I'm probing for some input in #yui as I think that the binding could be moved into a bindUI method in the subapp
<rick_h> hatch: no, at least the toggle can't be moved there. 
<rick_h> hmm, well maybe it *could* I guess. I use a delegate stuff now
<sinzui> gary_poster, that plus normalisation to ensure the charm can be accessed
<hatch> sure and you could still do that
<hatch> there is nothing saying you couldn't do that Y.one('#content') in a bind method
<rick_h> hatch: yea, just that right now the app has no idea about HTML structure/etc. It's all in views and they are easy to test that way. 
<gary_poster> sinzui, rick_h, ok, thank you very much.
<rick_h> it feels really really ditry to me
<hatch> right
<hatch> see in a past project we had a view which managed the navigation
<sinzui> gary_poster, These charms for example cannot be deployed, and until last week, we could not even show in the browser until we sanitised them: http://manage.jujucharms.com/tools/store-missing
<hatch> but we have all but avoided that
<rick_h> hatch: like I said, if I *had* to I'd move it up to the subapps/views/view.js that they all share. It's handlig the widget currently. 
<gary_poster> ah, I see what you mean sinzui
<hatch> rick_h: ok....yeah that looks good - can you do that? :-)
<rick_h> hatch: I guess I'm saing I agree that it's heavy-weight, but for a quick refactor to help aid Huw in UX redesign that's more work in a new path than this is meant for. 
<hatch> ohh ok
<rick_h> hatch: yea, I could. 
<hatch> rick_h: oh sorry, I never sent
<hatch> LGTM for now....... :P
<gary_poster> benji, Makyo looks like you are making progress.  have you fixed 2 or 3 of the 4?
<gary_poster> I mean, which one. :-)
<gary_poster> 2, or 3
<Makyo> gary_poster, both relation branches have landed.
<Makyo> Oops, will update board.
<gary_poster> Makyo, fantastic.  so the only thing left is the configuration issue, benji?
<benji> gary_poster: 1 (yesterday), and 2b and 3 have landed (I'm pretty sure), and right, my issue is the last which I believe I'll have done in the next 30 minutes or so
<Makyo> All instances of 2 and 3 have landed as of two minutes ago or so.
<gary_poster> benji, Makyo, great! thanks.  computer would stop crashing, things would be great. :-)
<benji> a computer never crashes if it's off
<gary_poster> :-)
<sinzui> jcsackett, do you have a few minutes to hangout to discuss why failed to to get my dequeue branch into review?
<jcsackett> sinzui: give me 10 minutes?
<sinzui> thank you
<jcsackett> sinzui: Ok, sending invite now
<jcsackett> ...or not. 
<sinzui> jcsackett, Is the landlord kicking you out every time you invite people to your party?
<jcsackett> sinzui: It kept telling me you aren't around. 
<jcsackett> Shall I call again?
<sinzui> yes
<hatch> bcsaller: the 'please take a look' email didn't include a link :)
<bcsaller> hatch: https://codereview.appspot.com/10760046/ and corrected on the card
<hatch> cool thx
<hatch> that was odd it was missing the link
<bcsaller> propose didn't pick up the -cr flag for some reason
<hatch> ahh
<gary_poster> sinzui, am I right that there is no way to get information about an earlier revision of a charm from m.j.c, but we can get pretty much everything from store.juju.ubuntu.com?  If we knew a precise revision, would their be a clear path to getting that information from the store?  Relatedly, how do you find out the API of store.juju.ubuntu.com?
<sinzui> gary_poster, I don't think there is a clear way to get info about a revision. We discussed pulling each zip from the store, unpacking them, then scanning them for data
<gary_poster> ah
<gary_poster> wow
<gary_poster> I found https://juju-docs.readthedocs.org/en/latest/internals/charm-store.html
<gary_poster> reviewing a bit
<gary_poster> sinzui, is that how you handle a charm head as well--m.j.c scans them too?  Or does the store give more for the charm head than it appears to?
<sinzui> We only use the store to get the download counts and a report about the store's sense of quality
<gary_poster> ah ok
<sinzui> We use the Lp branch for history, files, and proof
<gary_poster> oh
<gary_poster> so...could you do the same for old versions?  or that's not reliable/efficient, because bzr version does not equal charm version? ?
<benji> jujugui: critical bug fix up for review: https://codereview.appspot.com/10887043
<hatch> on it
<bac> benji: me too
<benji> thanks guys
<bac> benji: done
<benji> bac: thanks!
<sinzui> gary_poster, these are the two URLs the cb users to talk to the store:
<sinzui> https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui
<sinzui> ^ get the current version of the charm
<sinzui> ^ which tells us the version number
<benji> bac: I had to google OAO, it was a close call between "over and out" and "Opticians Association of Ohio"
<sinzui> gary_poster, https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui-61
<bac> i've never been to ohio
<sinzui> gary_poster, ^ is a variant to to see an older version
<bac> in my rich fantasy life i am a helicopter pilot, however
<sinzui> gary_poster, this is the url to get the download counts for a charm: https://store.juju.ubuntu.com/stats/counter/charm-bundle:precise:juju-gui?format=json
<hatch> benji: this doesn't look like it effects the new inspector - did you QA the new inspector with this branch?
<benji> hatch: I don't think it will effect the new inspector - no I didn't
<hatch> mind doing that so I don't have to make it? :)
<hatch> make just takes so long on this thing hah
<gary_poster> bac, lol
<gary_poster> x 2
 * Makyo -> vet.
<hatch> bcsaller: review done
<gary_poster> sinzui, ah ok.  so really everything is in place to get the historical information in about the same way you are currently getting the trunk info, IIUC
<bcsaller> hatch: thanks, following up
<sinzui> yes
<sinzui> gary_poster, 1. record the version we have now and mark the current one so that it is indexed for search.
<benji> bac: lol
<sinzui> gary_poster, 2. add a proc to get the history of the old revs, then queue them for ingestion so that they can be directly looked up
<benji> hatch: how do I enable the new inspector?
<hatch>  /:flags:/serviceInspector/
 * gary_poster just did that without the preceding space :-P
<hatch> which coincidently freenode does not understand /:flags:/
<hatch> gary_poster: lol same haha
<gary_poster> :-)
<hatch> coincidentally even
<benji> hatch: it appears to work, in that the fields are visible, but the panel itself is all kinds of jacked up... it that normal?  (i.e., it is too big to fit on the screen, the colors are such that it is just about illegible, if I click on an existing service to show the inspector and then click on a charm in the browser to deploy it the inspector stays above the browser)
<hatch> yup that's all known
<hatch> ok thanks for checking that
<hatch> :)
<benji> cool
<hatch> lgtm'd
 * benji lands.
<hatch> gary_poster: after benji 's fix lands I believe that's all 3 so I can start the QA again - do we still want to release?
<gary_poster> hatch, all 4 even.  we do very much want the release, thank you.
<hatch> yeah....4 :)
<benji> hatch: branch landed
<hatch> benji: thanks, rockin the QA now
<hatch> gary_poster: when I make a relation using the service-menu it's connection point on the 'starting' service is off center and pops back to place when you move the service, it's proper when using the long click. This is hardly a breaking issue just thought I'd point it out
<gary_poster> hatch, ok.  I'm ok with releasing with that, though if Makyo has a quick fix that's cool too.
<hatch> ://///
<gary_poster> hatch, ?
<hatch> well there is some wakoness that I can't reproduce
<hatch> so trying to reproduce to see if it's a one time thing or if it's a real issue
<hatch> when you drag & drop the icons are left in the dom behind the environment
<hatch> ^ we should have a ticket for that
<hatch> I'll make
<hatch> the height calculation for the view-container that the (old) service inspectors get rendered into is too high by 18px
<hatch> (should fix before release)
<hatch> gary_poster: when switching between views it shows the brown background for a second (sometimes) which exposes the icons left in the DOM (https://bugs.launchpad.net/juju-gui/+bug/1197152) not sure how much of an issue this is...
<_mup_> Bug #1197152: Drag & drop icons are left in the DOM after dropping <juju-gui:New> <https://launchpad.net/bugs/1197152>
<hatch> actually forget that, they aren't just in the dom, they are appended to the end of the dom
<hatch> benji: still around?
<benji> hatch: yep; I've been half-following along
<hatch> guichat real quick so I can show you?
<hatch> this drag and drop just won't die haha
<gary_poster> hatch that sounds like a trivial fix?
<benji> hatch: I'm sure I know what is happening.
<hatch> benji: ok cool, as long as you can repro
<hatch> I was just going to step through the repro steps
<benji> If they are in the bug, that will be best.
<hatch> ok I'll detail it out a bit
<hatch> benji: updated with full repro steps
<benji> great
<hatch> the charm page has lost it's scrollbar someways along the way
<hatch> looks like a side effect of some responsive word
<hatch> work*
<hatch> benji: if you wouldn't mind including this fix for the height calculation issue https://gist.github.com/hatched/b68e07f1832c1c085ceb
<hatch> 1 char diff....awww yeah
<hatch> ;)
<benji> hatch: sure
<hatch> thank yas
<hatch> now the question is....why wont' this charm page scroll :/
<hatch> oh odd - it works fine on devel but not on prod
<hatch> ok must have been a cache issue
<hatch> benji: any luck with that DD issue?
<gary_poster> heh, guessing not
<gary_poster> bcsaller, https://codereview.appspot.com/10760046/ LGTM with trivia;
<gary_poster> l
<hatch> hah ok - I guess release will be pushed till tomorrow :)
<hatch> there are some odd issues wrt delta updates while dragging
<hatch> but I'm certain that's the 20 of the 80/20 rule especially for a pre 1.0
<gary_poster> hatch, did he tell you he was working on it?  From the sound of it would be easy to fix
<hatch> I guess I just assumed
<gary_poster> hatch, delta updates with dragging: curious, but maybe file a bug?
<hatch> yeah as soon as I can create a repro heh
<gary_poster> heh
<hatch> I'll dig into the dd stuff
<hatch> maybe it is trivial
 * gary_poster wanted my nice shiny release
<gary_poster> thank you
<gary_poster> !
<hatch> lol
<hatch> ""LOL, that's deep, man. :-)""
<bcsaller> it should only update annotations on a dragend event, that sounds off
<hatch> I have 'fixed' the drag icon issue but I don't like it
<hatch> bcsaller: are you aware of any way to get the dragged item from the d3 drop event?
<hatch> I can only see the svg stuff in the event
<bcsaller> hatch: I can look
<hatch> well I don't want to waste your time
<hatch> I Just find it odd that the DOM event doesn't include reference to the dragged element
<hatch> well the event is actually being caught as 'mousemove'
<bcsaller> hatch: it looks like all that code, is in topology/service.js and the dragend handler should be doing it. That gets both the box  (the visual model) and the datamodel under it is its handler so you can see how its done
<hatch> maybe I can put the reference in the charmData that it sends
<hatch> now I'm just talking to myself
<hatch> sorry hah
<bcsaller> oh, this is the charm token thingie, haven't looked at how that is done
<bcsaller> happy to chat about it soon
<bcsaller> hatch: let me know if you need to talk about it
<hatch> bcsaller: nope, this way is a lot nicer thanks
<hatch> just needed some sound boarding :)
<gary_poster> biab
<hatch> I'm so confused about bzr shelve
<hatch> Changes shelved with id "1".
<hatch> bzr: ERROR: No changes are shelved with id "1".
<hatch> good thing I did a good ol diff dump before that
<huwshimi> Morning
<hatch> morning huwshimi how are things?
<huwshimi> hatch: Good thanks, yourself?
<hatch> good good just taking another stab at releasing hah
<huwshimi> Fun!
<hatch> yeah I am pretty sure I just squashed the last but
<hatch> bug
<hatch> even
<hatch> arg
<hatch> there is definitely something messed up when you drag and a delta comes in
<hatch> Makyo: happen to be around still?
<Makyo> hatch, barely.
<hatch> deltas coming in while dragging jumps the service away from your cursor to last known position - known issue?
<Makyo> I believe so, yeah.  Let me hunt.
<Makyo> For brevity's sake, is this on improv or simulator?
<hatch> both - happens on simulator faster though
<hatch> for obvious reasons
<Makyo> 1 sec
<hatch> jujugui looking for reviews for critical bug fix https://codereview.appspot.com/10872044/
<Makyo> hatch, was existing, but there's a 1 line fix if you want to put it in that same branch.
<hatch> ok can do
<hatch> diff me!
<Makyo> http://pastebin.ubuntu.com/5838912/
<hatch> cool thanks I'll add that in
<Makyo> Will review, too.
<hatch> thanks
<hatch> hmm wth
<hatch> I don't think annotations are sent on drag end when using dd
<rick_h> hatch: comments inbound. 
<rick_h> hatch: couple of questions due to quick run through. 
<hatch> thanks rick_h Makyo
<rick_h> huwshimi: you get my email? Everything cool then?
<hatch> ok the annotations are being updated
<hatch> but it doesn't appear to be effecting the relation line
<rick_h> of course not :P
<hatch> bah I gota go eat supper, might try and get back to this tonight
<huwshimi> rick_h: Yep, that's great. Thanks very much. I haven't pulled it yet, but will let you know if I hit any issues.
<huwshimi> (I agree with not doing the minimised search for now too)
<rick_h> huwshimi: ok cool. Let me know how it goes
<huwshimi> rick_h: Cheers, thanks for getting to it so quickly.
#juju-gui 2013-07-03
<bac> hi luca, do you have assets for the new expose slider?
<luca> bac: hmmm
<luca> bac: I'll have to have a look, Jamie (Vis designer) is on holiday this week...
<bac> luca: it's ok if you don't as i'll just use the old ones and sub them out later.
<luca> bac: it might be best to use the old ones
<bac> hey, good idea!  :)
<rick_h> jcsackett: jujugui can I get a second review on huw's design rework initial branch please? https://codereview.appspot.com/10902044/
<benji> rick_h: I'll take a look
<rick_h> benji: thanks
<rick_h> benji: qa-wise it leaves the old toggle button, but my branch (second in the series) will remove it. 
<benji> I assume that's the browser toggle button
<rick_h> benji: actually it leaves the min/max button in the upper right corner of the browser bit
<benji> k
<gary_poster> benji, did you see hatch's email?
<benji> gary_poster: I saw his branch land, but I didn't see a human-generated email.
<gary_poster> benji, "Critical drag & drop preventing release," I'm afraid
<gary_poster> that is the subject
<gary_poster> to peeps list
<benji> <sigh>
<gary_poster> rick_h, why don't you bring up the clear search thing to UX?
<gary_poster> might as well see if it was an oversight at the least
<rick_h> gary_poster: ok, will do. 
<rick_h> oh luca... :)
<benji> Either my approach to this task is wrong or our code in this area has some systemic issue (or both!).
<gary_poster> benji, it certainly has highlighted what appears to be some major fragility.  If the necessary steps for proper deployment are abstracted into a few functions that would be a win for the future, at least.
<benji> rick_h: do I need to QA that branch too?
<rick_h> benji: you can, but I've done qa. I should have marked that in the comment sorry. 
<rick_h> benji: why I mentioned the one known qa issue atm
<benji> cool
<rick_h> my follow up that fixes that qa issue is already reviewed yesterdy and I'll land right after this one gets the ok and I submit for him. 
<rick_h> thanks benji 
<benji> my pleasure
<gary_poster> rick_h, fwiw, I clarified the new search widget behavior mocked up by ant with luca yesterday.  If the charm browser is minimized, environment (service) search results come first, and charm search results come second.  Otherwise, the order is reversed.  This is the only difference.
<gary_poster> (between minimized and not minimized)
<rick_h> gary_poster: ok, but do we have environment search?
<gary_poster> rick_h, nope :-)
<gary_poster> rick_h, I suggest punting on it for OSCON
<gary_poster> rick_h, it will probably be trivial to implement
<gary_poster> but we have too many "probably trivial to implement" things in the queue, and some serious burns from some of them
<rick_h> gary_poster: yea, the big thing I know we waited on was that you can search, but then when you click you can't load all the data we need to fill out a charm view
<gary_poster> rick_h, what do you mean?
<gary_poster> oh
<rick_h> gary_poster: so there was talk of trying to get juju to enable access to file content like config.yaml/etc but that never picked up priority from juju
<gary_poster> rick_h, I *think* that the search of services is supposed to focus the environment view on the service, not open the charm.  I'm pretty sure that's the case actually.  the inspector is responsible for showing charm info for a service
<gary_poster> not the charm browser
<gary_poster> so the service search would walk through the services in the local JS db, and if it finds some that seem to match, include it in the result list.  If the user clicks on the service in the list, the environment pans to the service and opens its inspector
<rick_h> gary_poster: ok. 
<gary_poster> if we don't have the inspector, we simply pan for now
<luca> gary_poster: I'm working through the dirty input thing and worked out a solution for saving or discarding unsaved changes but I was thinking about the multiple settings in 1 input field problem. I've always had a system in the wireframes that allow users to save each individual setting but you mentioned a while ago that it wouldn't really be a good idea to do that. I've now catered for a "savE
<luca> save" feature for settings but if we get multiple settings per input field then it gets really complex to sort out which setting to choose from
<luca> gary_poster: I'm not sure if I've worded this at all coherently
<gary_poster> :-)
<luca> gary_poster: what I;m saying is, if we have each setting input field saveable then it's an easier process if you get multiple inputs. Is it even a problem now that we came up with a solution for the scale units thing?
<gary_poster> luca, yeah, I'm not sure what you mean about multiple settings per input field.  Do you mean the case when you are editing a field and someone else has changed the field since you started?
<luca> gary_poster: yes
<gary_poster> ok
<gary_poster> I'm still not entirely caught up with you I think, but getting there. :-) scaling units is a separate control.  The "save" would need to apply to, say, all of the configuration options together, or all of the constraints.
<gary_poster> basically the sections you have in the UX divide things up pretty well.
<gary_poster> if there is one control, we can do it immediately
<gary_poster> if there are multiple controls, we need a save
<luca> gary_poster: yeah but if I'm editing "Setting X" and Steve edits "Setting X" do we need to offer conflict resolution?
<gary_poster> if it is changed, yes
<luca> gary_poster: ok, so
<gary_poster> and generally that is the case within a section
<gary_poster> so if I am editing config
<gary_poster> and changing setting X
<luca> gary_poster: If I edit 10 settings, and Steve edits 6 of those settings we should offer conflict resolution on those 6 settings?
<gary_poster> then I want to know if config setting X changes, or any other config setting
<gary_poster> luca, we need to handle the situation, yes.
<luca> gary_poster: ok, It's a tricky one to solve
<gary_poster> luca, similarly, if I edit 1 setting, and Steve edits another setting in the same section, I should see Steve's change, and it should be highlighted.
<luca> gary_poster: I imagine saving after each setting change would be the easiest way to A) check for a conflict and B) solve a conflict. It could get really messy if we're dealing with multiple conflicts.
<gary_poster> it is not a direct conflict, but I should be aware of the world changing, as it might interact poorly with what I'm doing
<gary_poster> luca, that is not a good solution practically because (A) settings can work together and (B) saving settings can trigger arbitrary amounts of work.
<gary_poster> we don't want to trigger work for an incomplete command
<gary_poster> where a "command" would be a set of settings
<luca> gary_poster: ok, so we need a solution that can handle multiple conflicts
<luca> gary_poster: which shows when the settings were last updated
<luca> gary_poster: and can highlight new changes
<gary_poster> luca, single setting works for unit target count FWIW
<gary_poster> luca, shows when the settings were last updated?
<gary_poster> luca, I would be *very* fine with a simple practical solution.
<luca> gary_poster: yeah to show whoever goes into the GUI if it was updated recently or not
<gary_poster> luca, we won't have that info in many cases.  The GUI could have it if it has been running, but juju will not deliver it
<luca> gary_poster: I see, ok
<gary_poster> luca, simple practical solution: for instance, we could simply warn the user of different settings as they arrive. If they can see what they are, they can deal with them.  We might not need to stop their flow, just let them know that something else is going on.  We could always show saved values, and then highlight when those "saved" values change.  Alternatively, I would even be OK with heavy-handed solutions as an interim
<gary_poster>  solution, like forcing the user to select between the form values and the saved values en masse
<gary_poster> Though I'd prefer to be a bit more flexible than that, at least
<luca> gary_poster: no cross team meeting today
<gary_poster> ok cool luca, works for me, though please ask ant to tell us if he is ok with Huw's SASS plan
<luca> gary_poster: He's writing an email as we speak :)
<gary_poster> luca, cool thanks :-)
<hatch> morning
<hatch> hey benji I see you have picked up that card - any luck? need a hand?
<benji> hatch: no particular luck but I may have some questions in a bit that you can help with
<hatch> alright
<hatch> benji: how are those questions coming? :)
 * hatch is itching to get this released
<hatch> tbh I'm not sure how much help I'll be
<benji> hatch: none at the moment; we can pair if you want
<hatch> sure just let me grab a coffee
<hatch> benji: i'm in guichat
<hatch> Makyo: in yet?
<Makyo> hatch, yep.
<hatch> mind poping in guichat for a quick sec?
<gary_poster> hatch when you are available lemme know and we can have a weekly call.  No rush: I'm available up until the team call.
<hatch> gary_poster: ok I handed off to Makyo for the time being
<sinzui> orangesquad. I just reported https://bugs.launchpad.net/charmworld/+bug/1197435 . I will fix this now and then update the rt to deploy because I don't want this bug to go to production.
<_mup_> Bug #1197435: KeyError 'summary' accessing a key that is now an attr <oops> <regression> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1197435>
<matsubara> gary_poster, hi there
<gary_poster> matsubara, hey! on call will ping
<matsubara> gary_poster, I'd like to test the tarmac setup for juju-gui. 
<matsubara> I'll wait for your ping then :-)
<benji> gary_poster: update, Makyo recognized the problem and has a one-line fix.  He'll be adding a test and proposing the branch soonish.
<hatch> figures it would be a one liner lol
<gary_poster> yay benji and Makyo!
<Makyo> Hmm, this was actually fixed by my second branch, yesterday, but the test was stumping me.  Think I've got it now.
<Makyo> benji, quick +1 on tests?  One added to check that positions and hasBeenPositioned are set if provided, another checking that annotations are set if hasBeenPositioned is set. https://codereview.appspot.com/10876044/
<benji> Makyo: sure, looking
<gary_poster> matsubara, hey
<gary_poster> you need a branch to test, I'm guessing?
<hatch> this fix looks like a lot more than one line ;)
<Makyo> hatch, We renamed 'dragged' to something more indicative that the service has been intentionally positioned, plus I added tests per benji.  Same code, in the end.
<hatch> reviewing
<Makyo> I'm in the process of landing, FWIW.  I have three LGTMs, one from you :)
<hatch> Makyo: so how does changing the name fix the issue....or is this just an enhancement on this branch and a fix is in another?
<hatch> ohh nm
<hatch> ln288
<Makyo> jujugui call in 10 kanban now.
<hatch> benji Makyo thanks for tackling that issue.....here is to hoping I can finally do the release ;)
<matsubara> gary_poster, yes
<Makyo> jujugui call in 2
 * benji wonders aloud if rick_h is in today.
<hatch> shoot things have changed in trunk since yesterday
<hatch> I think going forward we need to start making release branches
<hatch> and holy smokes I think this QA will pass
<matsubara> gary_poster, the jenkins job just finished. Would be ok to disable it and set up the tarmac one in its place so we can test pre commit landing for the next branch?
 * hatch grumbles about the lack of a 'home' button in the charm browser
<gary_poster> matsubara, sure, though let's wait till Jeff makes a release, which will hopefully be soon.  hatch, agree?
<hatch> gary_poster: matsubara very soon, just finishing up the QA
<matsubara> ok. hatch, please let me know when you're done so we can continue. :-)
<hatch> QA ..... passed *he says expecting it to explode*
<hatch> matsubara: ok will do, probably 15-20
<matsubara> thanks hatch 
<hatch> gary_poster: there is some wako url stuff goign on but I don't think it should block the release....
<hatch> when viewing a service and then you click relations the url is
<hatch> localhost:8888/:gui:/service/haproxy/relations/#/:gui:/service/haproxy/relations/
<hatch> not sure where the # is coming from...
<hatch> jujugui ^ anyone know what's up with that
<gary_poster> seen that before hatch.  not worth blocking release.  seeing if I can find source really quickly
<gary_poster> hatch:
<gary_poster> app/views/service.js:              charmUrl = (charm ? getModelURL(charm) : '#');
<gary_poster> ?
<gary_poster> mm probably not
<hatch> shall I make the changes to changes.yaml in trunk then push or should I create a new branch then merge the changes in?
<hatch> ^ process pedantics :)
<gary_poster> hatch I suggest the former
<hatch> sounds good
<hatch> in the changes.yaml there is a - > on some lines
<hatch> oh that's multiple lines
<hatch> nm
<hatch> gary_poster: are we talking about the new inspector in the changelog?
<gary_poster> hatch, sure can, but clarify it is hidden behind feature flag and in progress
<hatch> gary_poster: sounds good https://gist.github.com/hatched/e0ac58187f4bbc544273 did I get all the points?
<gary_poster> hatch: "Export environment to YAML from keyboard shortcut." -> "Export environment to Juju deployer YAML format from keyboard shortcut (shift-d)".
<gary_poster> or similar
<gary_poster> hatch: "Added relations to Go sandbox." -> "Added relations to Go sandbox (Go sandbox still in progress)."
<hatch> fixed
<hatch> thanks
<gary_poster> thanks hatch good
<hatch> hmm the make distfile is failing
<hatch> there are no uncommitted changes
<hatch> there is a shelve (that probably shouldn't matter)
<hatch> does the FINAL=1 need to be an environment variable?
<gary_poster> hatch, the commands as given wfm
<gary_poster> or have in the past I mean
<gary_poster> Make will usually do the right thing
<hatch> I wish it gave me a real error
<hatch> can I clear out the bzr shelve?
<hatch> maybe that's what's going on
<hatch> parent branch: bzr+ssh://bazaar.launchpad.net/+branch/juju-gui/
<hatch> ahah
<hatch> it was the shelve
<hatch> alrighty qa'ing the tarball
<hatch> arg
<hatch> drag and drop doesn't work in FF
<hatch> I was sure it did in the first QA
<hatch> ^ gary_poster
 * gary_poster whimpers
<hatch> of course this is after I already tagged a release
<gary_poster> hatch, wfm on uistage
<hatch> hmm ok lemme clear the cache again
<gary_poster> hatch, no it failed after I cleared the cache
<hatch> *grumble grumble grumble*
<hatch> WELL then
<hatch> so the drop target is no longer getting caught
<gary_poster> hatch works for me again? :-/
<gary_poster> nack soon
<gary_poster> b
<hatch> hmm something is wrong here... the icons are sticking around too
<hatch> *sigh*
<gary_poster> hatch I don't see problem any more
<gary_poster> as I said
<hatch> isn't working for me in OSX FF
<hatch> lemme try in Ubuntu
<hatch> ok works in Ubuntu FF
<hatch> ok so works in OSX Chrome and Ubuntu Chrome/FF
<hatch> heh
<hatch> I suppose that's releaseable
<hatch> I'll create a bug right now
<gary_poster> hatch I can get it to fail intermittently in Ubuntu FF
<gary_poster> it *seems* to be a timing issue
<gary_poster> hatch, if I drag it and hold it for a second or two and then release it always works
<hatch> ok let me try that in OSX
<gary_poster> if I drag it and release it as fast as I can it fails intermittenty
<gary_poster> l
<hatch> ok even that doesn't help in OSX
<hatch> when I drag as fast as I can in Ubuntu it works every time haha
<gary_poster> heh
<gary_poster> and sigh
<gary_poster> ok release it and make the bug, I agree
<gary_poster> thanks
<hatch> can do!
 * hatch pushes the release down the stairs
<hatch> oops
<gary_poster> quick lunch
<hatch> :)
<gary_poster> :-)
<jcsackett> rick_h, jujugui: can i get two reviews on https://codereview.appspot.com/10916043/
<hatch> benji: https://bugs.launchpad.net/juju-gui/+bug/1197486 ;)
<_mup_> Bug #1197486: Charm drag and drop does not work in OSX FF <juju-gui:New> <https://launchpad.net/bugs/1197486>
 * hatch waits for a laptop to be thrown through my window
<hatch> :D
<benji> I'll requisition a new MBP immediately.
<hatch> lol
<hatch> benji: just fyi - I am still releasing just pointing that out :)
<sinzui> rick_h, your download count changes are in production now
<hatch> uuuuuuugh!
<hatch> can someone check out trunk, fire up rapi, try and drag and drop in FF on Ubuntu ?
<hatch> It's refreshing the page when I do that
<Makyo> wfm, hatch
<Makyo> Oh, rapi, just a sec.
<Makyo> hatch, reproduced.  It refreshes to eg http://localhost:8888/precise/glance-17
<hatch> ok we clearly can't release with that
<hatch> son of a
<benji> oh man
 * benji tries to reproduce the bug.
<hatch> I'm starting to get irritated heh
<hatch> (at dd)
<hatch> hey my numpad works in my vm's now.....
<hatch> silver lining?
<Makyo> It's feeling race-condition-y caused by the relative slowness of rapi as compared to sandbox
<hatch> but it only happens in FF
<hatch> ok I fixed it
<hatch> benji: Makyo can you please add evt.preventDefault(); into the canvasDropHandler method
<hatch> (after evt is defined of course)
<benji> hatch, Makyo: I will.
<hatch> thanks /me hopes it helps
<Makyo> benji, hatch will test on my branch, just to have a third set of eyes
<hatch> excellent
<hatch> I have no idea why the heck this just started now
<Makyo> Good so far.
<hatch> great - it looks like it's working here too (OSX FF still broken but whatever)
<Makyo> hatch, good with rapi and sandbox, FF and Chrome
<hatch> excellent - benji any issues to report?
<benji> hatch: I am still seeing the refresh. I'm investigating.
<hatch> that's not comforting
<jcsackett> sinzui: can you take a look at https://codereview.appspot.com/10916043/
<benji> hatch: it was a typo on my part; it works fine with the preventDefault()
<hatch> ok awesome
<hatch> so now how do I remove the pushed tag heh
<gary_poster> hatch you don't.  Just call this 0.7.1 and trash 0.7.0
<hatch> sounds like a plan
 * hatch restarts the process
 * hatch smashes hands with hammer
<hatch> :P
<hatch> I'll rename 0.7.0 to 0.7.1  ?
<benji> ok, I'm going to go get lunch now and try not to drag or drop anything while I'm at it
<hatch> lol
 * sinzui looks
<sinzui> jcsackett,  Why is next() removed from the sidebar method?
<hatch> Makyo: I have proposed the fix branch - mind giving it a quick sanity check before I submit? https://codereview.appspot.com/10920043
<Makyo> hatch, LGTM
<hatch> thanks
<hatch> submitting
<jcsackett> sinzui: typo. i'll fix it.
<jcsackett> well, not typo so much as misdirected delete.
<sinzui> jcsackett, once we arrive at the sidebar we are done?
<sinzui> jcsackett, I think you mean next() still belongs there...you had an errant dd
<jcsackett> sinzui: that is what i am trying to say, yes.
<jcsackett> sinzui: if isJujucharms is true, sidebar doesn't get called by default.
<jcsackett> sidebar should not be modified.
<sinzui> jcsackett, okay. LGTM. I need to step away to rescue my wife from a garage.
<jcsackett> sinzui: ok, thanks.
<jcsackett> jujugui: can i get one review of https://codereview.appspot.com/10916043/, please?
<hatch> sinzui: jcsackett I am concerned that next() was removed and noone noticed, that should have broken something
<hatch> (reading from the sidelines)
<gary_poster> hatch!  you didn't yell/scream/whoop-n-holler about actually making a 0.7.1 release successully!  yay! :-)
<bac> hatch: call when you get chance?
<hatch> gary_poster: I haven't compared the tars yet....it could still screw up
<hatch> lol
<hatch> bac: sure....5 mins
<gary_poster> heh
<hatch> gary_poster: I'll also post to the blog with the release once I have finished the checklist
<hatch> w00t w00t!!! RELEASED
 * hatch does a little jig
<hatch> bac: ok guichat?
<bac> sure
<gary_poster> sinzui, questions for you.  (1) on http://uistage.jujucharms.com:8086/ if you look at the new charms, it includes 10 charms that you cannot click on and that you cannot find in search results.  What is the intent there?  (2) the openvpn charm has an icon, it seems, even though it is not reviewed.  how can that happen?
<gary_poster> Other bugs:
<gary_poster> (not for any particular audience, but tied to Huw's branch)
<gary_poster> - the config panel is 10 pixels down from the proper location
<gary_poster> - the tab does not expand to the right of the charm details
<gary_poster> - the tab does not change color to orange when minimized
<sinzui> gary_poster, Anyone can add a charm, it is up to the subapp to ignore it.
<hatch> benji: how did you do the bullet points in your release blog post? manually?
<sinzui> I think 2 is a regression
<gary_poster> - the search field changes size when you minimize
<benji> hatch: I don't remember exactly.  I do recall it involved vim though. 
<hatch> oh hah ok I'll do it manually
<hatch> thanks
<hatch> oh they are li's
<hatch> it must accept html
<hatch> Makyo: is that how you got your headings on your blog post? raw html in the input?
<Makyo> hatch, no.
<Makyo> Go to /wp-admin, posts, new post
<Makyo> That'll give you the full WYSIWYG editor.
<hatch> ohh ok
<hatch> thanks
<Makyo> There'll be a dropdown for paragraph types, etc.
<sinzui> gary_poster, I am not certainly about http://manage.jujucharms.com/~nextrevision/precise/openvpn
<sinzui> gary_poster, I can see the charm is new, so it is shown. It is not reviewed. Few new charms will ever be reviewed, so they will not show up in search unless you choose to see all
<sinzui> gary_poster, so http://uistage.jujucharms.com:8086/fullscreen/search/~nextrevision/precise/openvpn-2/?series=precise&text=openvpn will show it
<gary_poster> sinzui, fwiw that url does not show it
<sinzui> rick_h, jcsackett ^ per gary_poster's question to me. I think there is a regression. We are showing icons for unreviewed charms. Note that new charms are rarely/never reviewed, so while they are shown on the home page, search will only reveal them if [ ] Reviewed charms is unchecked.
<gary_poster> sinzui, if you expand the 10 new charms, none of them will display
<gary_poster> http://uistage.jujucharms.com:8086/~james-page/precise/nvp-transport-node-28/
<gary_poster> http://uistage.jujucharms.com:8086/~maarten-ectors/precise/storm-0/
<gary_poster> http://uistage.jujucharms.com:8086/~med/precise/squid-rp-mirror-0/
<gary_poster> http://uistage.jujucharms.com:8086/~daisy-pluckers/precise/hadoop-cassandra-0/
<gary_poster> etc.
<sinzui> gary_poster, when I tap Storm in the new section I see the details
<gary_poster> sinzui, all of them work in fullscreen ("browse") mode
<gary_poster> sinzui, none of them work in GUI/sidebar/"build" mode
<sinzui> ah
<sinzui> rick_h, jcsackett ^ gui is not getting the details for new charms from the sidebar
<jcsackett> sinzui: looking.
<gary_poster> jcsackett, if the sidebar thing is a quick fix I'd love to have it today.  The icon thing we can push to next week without issue
<jcsackett> gary_poster, sinzui: i agree there is an error, i am not sure it is a regression. i have never actually seen behavior on paths with '~' in the charmbrowser, tbh.
<jcsackett> unless someone else confirms a path like this used to work, it's possible this was never parsed correctly.
<jcsackett> but that does provide a clue.
<sinzui> jcsackett, indeed. New are very different from the kind of charms most users work with
<gary_poster> jcsackett, I'm messing around. search uses a sightly different approach, fwiw... http://uistage.jujucharms.com:8086/sidebar/search/~juju-gui/precise/juju-gui-68/?series=precise&text=gui
<gary_poster> jcsackett, I'm pretty sure that the urls used to look like this:
<gary_poster> http://uistage.jujucharms.com:8086/sidebar/~nextrevision/precise/openvpn-2/
<gary_poster> that works fine
<jcsackett> yeah, we removed showing the default viewmode in urls a little bit ago, and i don't know that we ever looked at '~' paths then.
<gary_poster> gotcha
<jcsackett> i have a clue where it's breaking.
<gary_poster> yeah I like that change
<gary_poster> jcsackett, please let me know if you have time to get this out before EoD.  You want me to file a bug with this or the icon thing?
<gary_poster> I mean, let me know when you think you know :-)
<gary_poster> matsubara, release was made about 40 minutes ago.  I suspect this is your EoD about now?
<jcsackett> gary_poster, sinzui, i have a fix.
<gary_poster> awesome thanks jcsackett 
<hatch> blogs posted birds tweeted
<jcsackett> need to put tests in for it, then i'll put it up.
<gary_poster> cool
<gary_poster> thank you
<jcsackett> yw.
<hatch> ....0.7.2 /me stomps his feet and grumbles
<hatch> :)
<gary_poster> sorry :-)
<matsubara> gary_poster, nope, not yet.
<jcsackett> in the meantime, jujugui, can anyone please review https://codereview.appspot.com/10916043/ ? :-P
<jcsackett> i have one, just need a second.
<gary_poster> heh
<Makyo> jcsackett, on it.
<jcsackett> awesome, thanks Makyo.
<hatch> jcsackett: why did you not notice that it failed with next() gone?
<hatch> something should have seriously broken
<benji> jcsackett: do you need a second?
<matsubara> gary_poster, so, can I disable the job and put the tarmac one in place? It'd be nice to test with jcsackett branch
<gary_poster> matsubara, go for it
<jcsackett> benji, nope, just the one, Makyo got it.
<benji> k
<jcsackett> hatch: i suspect that got deleted in a quick fix for lint, which didn't break tests.
<jcsackett> benji: thanks for asking, though. :-)
<bcsaller> hatch: ping me when you can have that call
<hatch> hmm routing is tough to test too
<hatch> I suppose the review was enough this time
<hatch> bcsaller: lets do it!
<bcsaller> gary_poster: if you're still interested we'll have that call now
<hatch> in guichat
<hatch> bac: your in guichat
<gary_poster> cool thanks bcsaller .  I'll join for a bit, though I'll try to make myself drop out to finish up doc before EoD
<abentley> sinzui: Could you please give me a mid-implementation review of https://code.launchpad.net/~abentley/charmworld/slow-migrations/+merge/172895 ?
 * sinzui looks
<matsubara> gary_poster, ok. changes done. once there's a new MP, tarmac will pick it up
<gary_poster> matsubara, when is your EoD?
<gary_poster> how long from now?
<matsubara> gary_poster, I'll be around for another 2h
<gary_poster> perfect thanks matsubara 
<matsubara> gary_poster, my last test was done with this branch: https://code.launchpad.net/~juju-gui/juju-gui/juju-gui-test 
<gary_poster> cool
<matsubara> gary_poster, so basically the tarmac jenkins plugin branches from lp:juju-gui, merges the changes in the MP, pushes the branch to ci branch on LP (https://code.launchpad.net/~jujugui-lander/juju-gui/jenkins-branch) and then passes that branch to the juju-gui test runner to use as --origin. Once the tests pass, it merges the changes into juju-gui or notify failures in the MP. Does that sound like what you needed?
<sinzui> abentley, while I review your branch, do you have time for my MP? https://code.launchpad.net/~sinzui/charmworld/charm-object-damn-it-2/+merge/172898
<abentley> sinzui: Sure.
<abentley> sinzui: r=me.
<gary_poster> matsubara, sounds perfect!  thanks!
<matsubara> gary_poster, don't thank me yet. let's see if works first :-)
<gary_poster> lol, ok
<bac> hatch: thanks for the help.  the data binding update worked.
<hatch> no problem glad it worked :)
<abentley> sinzui: any thoughts so far?
<sinzui> yes. I will save what I have so far
<hatch> gary_poster: I think that bcsaller and I have come to a great middle ground between what we need now and what will provide us with an easy-upgrade-path later
<sinzui> abentley, I add my first comments. I have 100 more lines to go
<gary_poster> hatch, bcsaller, great!  I look forward to reading about it. :-)
<hatch> and I actually haven't had lunch yet so I think I'll head out to grab some
<gary_poster> heh, ok, enjoy
<hatch> have a great holiday everyone
<gary_poster> thank you!
<hatch> see ya Monday
<hatch> annnnd anytime :)
<gary_poster> :-)
<sinzui> abentley, I don't have any other comments
<gary_poster> jcsackett, I see the MP.  Should I review?
<jcsackett> gary_poster, that would be awesome. i was just about to ping.
<gary_poster> cool, on it
<jcsackett> gary_poster: hm, looks like it hit LP, but not rietveld yet.
 * jcsackett is looking at the terminal still sitting on the rietveld step.
<gary_poster> :-)
<gary_poster> s'ok, trying qa
<abentley> sinzui: Thanks!
<jcsackett> sinzui: can you look at https://codereview.appspot.com/10914044 it's the new charms fix.
<jcsackett> gary_poster: review is up on rietveld ^
<gary_poster> ack on it thanks jcsackett 
<Makyo> Update on unit controls: https://codereview.appspot.com/10763045 Fixes ghost inspector (something leftover from an old branch), and also squashes a bug where the units attr of a ServiceModel wasn't updating on ServiceUnitModel.remove.
<Makyo> bac is tagged on the card, but anyone from jujugui..? ^^^
 * sinzui looks
<gary_poster> jcsackett, qa == thing of beauty, joy forever.  will look at code now.  Makyo if it is fast will look.  need to go soon to get back for call with Huw
<Makyo> gary_poster, not terribly fast, would like QA.  Go call :)
<jcsackett> "qa == thing of beauty, joy forever" is going to be my new slogan.
<gary_poster> Makyo, ack :-)
<gary_poster> heh
<Makyo> gary_poster, Cheers on the Keats, too :)
<gary_poster> :-)
<sinzui> jcsackett, LGBT
 * jcsackett laughs
<sinzui> oh damn
<sinzui> LGTM
<gary_poster> lol
<gary_poster> jcsackett, LGTM :-)
<sinzui> jcsackett, do you have 2 minutes to look at https://code.launchpad.net/~sinzui/charmworld/charm-object-damn-it-3/+merge/172916
<jcsackett> sinzui: yes.
<jcsackett> sinzui: r=me.
<sinzui> thank you jcsackett
<bac> Makyo: i'm looking
<Makyo> bac, cheers.
<bac> Makyo: is clicking on 'details' supposed to do *that*?
<Makyo> bac, This is only implementing the units list and the add/remove unit controls.  We don't have an inspector viewlet for that yet.
<bac> Makyo: whew
<Makyo> read: I sure hope not in the future :)
<bac> Makyo: ah, it is 'env' in both config base and derived configs that cause that recursion error
<Makyo> bac, Yeah, something leftover from before, I guess.
<bac> Makyo: done
<Makyo> bac, cheers, thanks.
<huwshimi> Morning
<gary_poster> jujugui, call now in guichat for weekly call australian edition
<huwshimi> rick_h: Around, by any chance?
<huwshimi> gary_poster: Pushed that change.
<huwshimi> gary_poster: Would you like me to sneak the change to fix the config panel top positioning into this branch? That way I can  land both of them today...
<gary_poster> huwshimi, yes please :-)
<huwshimi> gary_poster: OK, give me a couple of minutes
<gary_poster> will do
<huwshimi> gary_poster: Pushed.
<huwshimi> well... I'm in Australia so it's still pushing
<huwshimi> OK, complete :)
<gary_poster> huwshimi :-) back and looking
<huwshimi> gary_poster: Thanks
#juju-gui 2013-07-04
<gary_poster> huwshimi, sorry went in and out with other obligations.  qa is good, code looks good.  could you lbox propose again so rietveld shows the new changes?  I will then give LGTM.  YOu can land yourself, right?
<gary_poster> Or do you need me to?
<huwshimi> Will do. I can land (assuming it works).
<gary_poster> huwshimi, cool thanks.  btw did you mean to hide the search when you minimize?
<gary_poster> that functionality isn't ready yet maybe?
<huwshimi> gary_poster: Yeah, the search doesn't work yet (so removed it).
<huwshimi> gary_poster: It also looks from that prototype that the search will be for the canvas when the sidebar is minimised.
<gary_poster> huwshimi yeah I asked luca about that.  he said he simply wanted the priorities reversed
<gary_poster> so
<gary_poster> when the sidebar or fullscreen is open
<gary_poster> you get charm search results first, and canvas/environment service results second
<gary_poster> when it is minimized
<gary_poster> services are first and charms are second
<huwshimi> Ah I see
<gary_poster> I wouldn't be surprised if what you have now is what we can deliver for OSCON in this regard
<gary_poster> but we'll see
<huwshimi> gary_poster: We have no autocomplete at all at the moment
<gary_poster> huwshimi, yeah.  I'm not sure if autocomplete is required or not for that.
<huwshimi> gary_poster: Changes should be there now...
<gary_poster> huwshimi, yes, looking thank you
<gary_poster> huwshimi, LGTM
<huwshimi> gary_poster: Thankyou.
<gary_poster> thank you huwshimi!
<gary_poster> have a good week
<huwshimi> gary_poster: Thanks you too
<gary_poster> hatch fwiw trunk will be ready for 0.7.2 once huwshimi's branch lands, I think :-)
<huwshimi> gary_poster, hatch: Merged.
 * hatch walks into an empty office
<rick_h> benji: still need anything?
<hatch> hey rick_h
<huwshimi> Morning
#juju-gui 2013-07-05
<hatch> morning huwshimi thanks for the changes - I put 0.7.2 out this am
<huwshimi> hatch: Np, thanks for the release.
<hatch> man we can get 30yr mortgages now
<hatch> that's nuts!
<huwshimi> hatch: You couldn't before?
<hatch> nope 25 was the max
<huwshimi> hatch: That's what most people have here
<huwshimi> (30)
<hatch> to me the calculation doesn't make much sense
<hatch> save only about 8%/mo
<hatch> but i might be missing something as I'm just using the bank calculator :)
<hatch> our house prices are just nuts now so maybe that's why they added it
<hatch> in 'nice' areas they are going for $400/sqft
<hatch> for a house with a yard, and the like
<hatch> morning
<bac> morning hatch
<hatch> mornin bac
<hatch> I tried to watch a video this morning on msdn.com - it required silverlight which was out of date so it wouldn't play
<hatch> :/
<hatch> at least it includes the ability to download the video heh
<hatch> Mak-yooooooooooo
<hatch> welcome to the empty office
<Makyo> Hah!  Yeah.
<hatch> I bought the new Magic The Gathering app on android
<hatch> last night
<hatch> big mistake
<Makyo> Oh yeah? 
<hatch> first there are a lot more rules than when I stopped playing ohhhh 8 years ago :)
<hatch> and I probably played it for like 3h haha
<bcsaller> I used to play that when it first came out
<Makyo> Yeah, exactly.  I tried looking into it a few years ago and got lost when it started to pick up in popularity again.  Hadn't played since elementary school.
<bcsaller> you just made me feel old
<hatch> the cool thing about the app is that it tells you what each things do
<hatch> bcsaller: first came out? lol wow
<Makyo> Oops :)
<bcsaller> heh
<hatch> I think my first box was Ice Age
<bcsaller> I can take it
<Makyo> Mine was Revised.
<Makyo> Wait, am I the youngest? :P
<hatch> in magic card years....it does appear so
<rick_h_> howdy hatch 
<bcsaller> hatch: you were talking about this yesterday. Check out the graph on price per sq ft http://www.trulia.com/real_estate/San_Francisco-California/market-trends/
<bcsaller> I think 1br are the worst
<hatch> bcsaller: wow....how the heck can anyone afford to buy there? haha
<hatch> $850k for a 1500sqft condo.....jeeeeeeze
<bcsaller> people buy these things?
<bcsaller> this is earthquake country :)
<hatch> lol
<hatch> at least there there isn't any more land to build on
<hatch> we have a lot of land
<hatch> lol
<Makyo> Friend of mine just bought a house in Redwood City recently, actually.  $820k :P
<bac> so are we having a meeting?
<Makyo> I thnk its on reclaimed land, too.
<Makyo> Oh, yeah, jujugui call in 2 - just a daily.
<benji> jujugui: I'm having audio/video problems.
<Makyo> benji, no worries, though we finished pretty quick.  No surprises from the call; bcsaller and hatch may be proposing today.
<benji> sounds good; thanks for the update
<hatch> benji: http://oscargodson.com/posts/why-i-dont-use-coffeescript.html lol
<hatch> rick_h_: hey I just noticed that i can't deploy some charms on trunk
<hatch> is this a known issue?
<Makyo> Boo.  83 tests failed.
<hatch> boo
<hatch> man typescript with visual studio is so cool
<hatch> too bad VS requires Windows
<Makyo> Huh, everything passes in the browser.  Maybe a make clean is in order.
<hatch> check to make sure that you aren't trying to log something with a circular reference (like a Y.Node)
<hatch> phantomjs barfs on that
<Makyo> Oh, didn't save. :P
<hatch> lol
<hatch> Makyo:  var service = this.model || this.get('model')  was really just a suggestion :)
<hatch> maybe we should have a code for 'must change' and 'would like changed' :D
<Makyo> hatch, ah, okay.  I usually just put "<change> maybe? Up to you." in the comment.
<Makyo> It's a style thing, though, so no biggie.
<hatch> how about 'IC' implementers choice :)
<Makyo> I just always have to force myself to read that as assigning the model to the variable, and not 'true'.
<hatch> ahh yeah
<hatch> need the brackets for that
<hatch> :)
<Makyo> Yeah.  Just habit.
<Makyo> Anyway, I'm fine just using words, rather than Sekrit Codes to say that, unless rv can interpret that like LGTMs.
<hatch> haha
<hatch> it probably can't
<hatch> lgtm'd
<Makyo> Cheers, thanks.
<hatch> two spaces after periods look so funny to me
<Makyo> Yeah, it's what I was taught in elementary school. I'm trying to break myself of the habit, but it's hard.
<hatch> yeah I'm pretty sure it's purely a style choice now so neither are 'wrong'
<Makyo> True. One space is preferred by a lot of publishers, but it usually doesn't matter on the net, since white space collapses :P
<hatch> haha - which is so odd imho
<hatch> why do I need non breaking spaces....like CMON!!!!
<hatch> :)
<Makyo> Well, if you indent your HTML and still have a max width, that could get odd in deeply nested text :)
<Makyo> I mostly write in markdown these days, anyway :P
<hatch> haha yeah ok I suppose
<hatch> yeah markdown is really nice
<Makyo> Yeah, definitely.
<Makyo> Only problem I've run into is the wordpress plugin treats hard-wrapped paragraphs literally and inserts <br/>s
<hatch> ahh - I ran into that on my blog on Tumblr and ended up finding a hidden option to switch it to raw HTML - so I have to type the <p>'s manually but at least then I don't get any odd artifacts
<Makyo> Ah, yeah. Tumblr has a strange idea of markdown, as it is :P
<hatch> yeah I'm really looking forward to http://tryghost.org/
<hatch> if it lives up to it's hype it should be a great platform (written in node)
<Makyo> Oh?
<Makyo> I mostly use WP or Jekyll+Disqus, but this looks neat.
<hatch> is `peeps` our 'private' mailing list?
<hatch> I always get those two mixed up
<Makyo> Yeah.  You can go to https://launchpad.net/~juju-gui-peeps and see the private banner
<hatch> ahh ok cool
<hatch> when I come across a blog post in another language I'm all like "man why isn't this in English" I wonder if non English speakers say the same thing :)
<hatch> well except "why isn't this in X" :)
<bac> did y'all get invited to the leankit kanbanaroo party?
<Makyo> bac, Haha, no.  What is it?
<hatch> nope I didn't either!
<bac> it's a street party at Agile2013 sponsored by leankit
<bac> i think benji should go since it's in nashville and he's localish
<benji> "kanbanaroo" - that's pretty funny
<hatch> haha it is
<Makyo> Probably not as exciting as Bonnaroo.  More efficient, though.
<hatch> leankit really needs to work on their performance
<hatch> I have to refresh the page every day
<hatch> Makyo: after doing these releases should I delete the cards in Releasable? Or is there some other thing to do to those?
<bcsaller> they get archived I belive 
<bcsaller> believe
<Makyo> Yeah, I think archived.  Might be worth waiting until Gary gets back, though.
<hatch> yeah - there is a way to archive to 'Done' but that's a good idea, dont' want to have to manually move them all somewhere else :)
<hatch> Makyo: since you haven't yet committed your branch could I request one more 'improvement'? :) Add env to the attributes of view-container.js to match config base
<Makyo> hatch, Sure, still poking around at tests.
<hatch> yeah no rush - I also added env to it, so I can add it if you don't want too :)
<Makyo> hatch, You mean just in the ATTRS?
<hatch> yeah just so that anyone looking at it can see that it's expecting the env attribute
<Makyo> hatch, Sure.  I'll add it after db, so if you do add it yourself, it won't conflict.
<hatch> ok great thx
 * hatch slides this into his ammo box for Typescript conversion discussion
 * hatch expects to be shut down hard during that discussion
<hatch> :P
<hatch> bac: reviewing
<bac> jujugui: reviews https://codereview.appspot.com/10964044/
<bac> thanks hatch
<bac> thanks benji
 * bac relocates
<hatch> benji: this just looks funny but I think it's cool :)  (svcInspector ? this.inspector : this).get('model')
 * bac relocated
<hatch> I guess the new spot was not wifi friendly :)
<hatch> bac:  find a new wifi friendly location?
<hatch> :)
<hatch> aww man I have a databinding issue I can't seem to track down
<hatch> bcsaller: this is all your fault
 * hatch walks away successfully pushing the blame away
<hatch> lol
<bcsaller> what did I do this time?
<hatch> no I actually think this is me
<bac> hatch: i tried oceanfront but had to retreat
<hatch> bcsaller: when we edit a config field, it goes into 'conflicted' then you click 'save' and it's still conflicted when the model updates
<hatch> so I wrote the conflict part so it's actually my fault... ;)
<hatch> bac: aww man that would be so cool, working on the beach
<bcsaller> save would have to clean all conflicted state, unless that was somehow the last UI opportunity to confirm what your doing (in an overwrite situation)
<hatch> yeah there are a few different possible things here
<bcsaller> but I think we won't need that if the real conflict UX is sufficient 
<hatch> so you're saying that they have chosen to keep their own data so it's not really in conflict
<hatch> so on save, blow out the conflicts and force the changes to the other user
<hatch> a clearConflicted method would be trivial to write heh
<hatch> as long as that's the story
<bcsaller> hatch: that makes sense to me, we could optionally change the text on the save button when conflicts are detected to say something like Save (overwrite Juju changes) or something
<bcsaller> and if there are none, it just says save
<bcsaller> either way though it clears the state
<hatch> excellent idea
 * hatch steals and claims it as his own
<bcsaller> ha
<bcsaller> there is not 'team' in idea. Somehow I don't think that expression will catch on
<bac> hatch: removing those function references does cause breakage.
<hatch> bcsaller: lol I like that one
<hatch> bac: hmm ok let me review the code again
<hatch> bac: what is the error?
<hatch> Makyo was able to remove those and his code doesn't look any different...
<bac> re-running
<Makyo> hatch?
<Makyo> Oh.
<Makyo> Misread.
<hatch> sorry didn't mean to ding
<Makyo> That's fine, just misread.
<rick_h_> hatch: not sure on the issues deploying hcarms. Guess files bugs on them and we can look. 
<hatch> rick_h_: ok seems like today is your day off so this can wait until you're back :)
<rick_h_> hatch: yea, I'm out in the wood. This is my 30min of internet for hte day. 
<rick_h_> have to ride my bike up to the club house to get on crappy shared wifi
<rick_h_> just long enough to do a little git push and reply to a few emails
<hatch> man I think a fighter just did a flyby my house
<hatch> holy that was loud
<rick_h_> hatch: well file bugs on which charms at least so we can look into it post-holiday. 
<rick_h_> hatch: even better if it's something you can give an error from as it seems it must be client side. Maybe bad config unable to parse or something? However I think we sanity check that stuff already
<bac> hatch: unsurprisingly, when i remove the def of this.inspector.exposeService then calling this.inspector.exposeService() is an error.
<bac> hatch: should that fcn be defined in a different context?
<hatch> ahhh yes
<hatch> I missed that sorry
 * hatch is a bad reviewer
<hatch> this.exposeService
<hatch> rick_h_: well now I can't get them to fail....ignore me clearly I've lost my mind
<rick_h_> hatch: even better, self fixing bugs!
<hatch> haha
<rick_h_> ok, back to no signal-ville. git push and email replies accomplished. 
<hatch> cya
<hatch> bac: did that work for ya?
<bac> hatch: yep, after also defining the flags in my test.
<hatch> great
<bac> hatch: relook? https://codereview.appspot.com/10964044
<hatch> thanks I'll get on it right away
<hatch> bac: lgtm'd with one request
<bac> dagnabbit
<hatch> it's a small one :)
<bac> hatch: thanks
<bac> bye all.  have a nice weekend.
<abentley> $ juju destroy-environment
<abentley> WARNING: this command will destroy the environment.
<abentley> This includes spilling oil, contaminating the earth, polluting the air, and destroying other resources. Continue [y/N]
<Makyo> Hahaha
#juju-gui 2013-07-07
<huwshimi> Morning
<rick_h_> huwshimi: morning
<huwshimi> rick_h_: Hey there.
#juju-gui 2014-06-30
<rick_h_> urulama_: howdy
<urulama_> rick_h_: hi
<rick_h_> urulama_: pm
<rick_h_> welcome back luca!
<luca> hey rick_h_, hows it going? 
<rick_h_> luca: heh, I'll tell you in an hour?
<luca> rick_h_: lol sure
 * rick_h_ goes for coffee and breakfast now that first meeting is done wheee
<bac> rick_h_: i just entered leave into hr system
<rogpeppe> rick_h_: one thing occurs to me: do we want clients of the store to be able to update individual files in charms/bundles? for, example, do we want them to be able to change a README independently of the rest of the files in a charm?
<rick_h_> rogpeppe: no, I don't think so. 
<rogpeppe> rick_h_: ok, that's cool
<rick_h_> rogpeppe: if you wanted to do something like that it'd fall under resources. 
<rick_h_> a resource could be some single doc referenced, but a change to the base of a charm I think is a new charm version
<rick_h_> bac: doh, I've got to catch up on that holiday update email. 
<rick_h_> bac: thanks, will approve here shortly. 
<luca> rick_h_: can you give me the link to your work items doc?
<rick_h_> luca: hmm, https://docs.google.com/a/canonical.com/document/d/14XvT-6RjHKjUhGJLuwMC1y7JCkUeuUv-XxjYsPtWhng/edit ?
<luca> rick_h_: cheers
<bac> rick_h_: i got the jenkins details from mgz and now need to get an account and credentials from curtis
<bac> i think he starts a little later than us
<rick_h_> bac: rgr
<rick_h_> a morning person he is not :)
 * rogpeppe lunches
<rick_h_> jujugui make sure to welcome urulama and jrwren today. Will do face to face in the standup but if they hit you up with any questions/etc they're our new locals
<bac> welcome urulama and jrwren
<kadams54> Hi jrwren and urulama!
<urulama> hi all
<rogpeppe> urulama, jrwren: yo!
<urulama> ok. finished the traveling form.
<urulama> so, hi all, glad to be part of juju :D
<jrwren> yo.
<hatch> rick_h_ hey with the new EOY dates should we delete the old entries in hr and create new ones?
<hatch> and g'morning :)
<rick_h_> hatch: yea if you can try
<hatch> ok here goes.... *puts on helmet* I'm going in
<rick_h_> hatch: I found they didn't collide for me
<hatch> oh ok, maybe it'll be ok here too
<rick_h_> hatch: yea, for me I had to add one more day off from my holiday stash :(
<hatch> yeah looks like I do too
<rick_h_> hatch: cool, yea so no surgery required
<rick_h_> jrwren: did you get the leankit invite?
<rick_h_> jrwren: you and urulama up for meeting in the standup hangout 10min before the call to get a board overview?
<urulama> rick_h_: fine by me
<rick_h_> urulama: k, will ping in 15 and we'll meet early for a run down
<jrwren> i can hangout anytime, I guess. I'm still trying to figure out all this account info stuff.
<jrwren> i got distracted reading the wiki. does anyone use the voip stuff?
<rick_h_> jrwren: cool, take your time and let me know if you hit anything that's not clicking
<rick_h_> jrwren: most of us don't. The only main interaction is calling into the conf call system for large meetings
<rick_h_> jrwren: honestly, we use hangouts almost for everything until we hit the 15person limit
<rick_h_> that and irc
<jrwren> the, i'll low prioritize that.
<jrwren> *then
<rick_h_> jrwren: if you can signup for leankit soonish that'd be great so I can get you access before the call
<jrwren> ok
<jrwren> hrm, google apps weirdness
<rick_h_> yea, dualing accounts takes some getting used to
<hatch> easy peasy!!
<rick_h_> hah
<rick_h_> hatch: are you supposed to be lake-fronting it today?
<hatch> rick_h_ yeah but it's bloody pouring! 
<jrwren> i did this 1mo ago when old job switched to google apps. was no problem with all chrome, but a little different because google is pointing to me LP account
<rick_h_> hatch: poor guy
<hatch> rick_h_ yeah tough life...
<rick_h_> jrwren: yea, the 2fa fun
<Makyo> jujugui callin 10
<Makyo> Buh. Coffee hasn't reached my fingers yet.
<rick_h_> urulama: jrwren https://plus.google.com/hangouts/_/canonical.com/daily-standup
<rick_h_> or https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 if this is your second google account :)
<bac> Makyo: thanks for the stickers.  the many, many stickers.  :)
<Makyo> bac, Hah, glad they made it.    Should keep you stocked up for a while.
<bac> Makyo: yes, now i can juju-power my fridge, microwave, water heater, ...
<Makyo> We already have internet-enabled fridges, it's only a matter of time.
<kadams54> juju add-unit fridge
<kadams54> er
<kadams54> juju add-unit -n100 fridge
<kadams54> web scale appliances
<hatch> haha
<kadams54> AaaS - Appliances as a Service
<rick_h_> jujugui call in 2
<rick_h_> Makyo: ^
<jrwren> i should have said in standup, I have to run out for 30min, brb
<rick_h_> jrwren: rgr
<rick_h_> hey luca, how did the meeting go?
<rick_h_> actually, I'll ask in PM :)
<bac> Makyo: it was inevitable: https://flic.kr/p/oa9D3B
<Makyo> Hahaha!  Fantastic!
<rick_h_> bac: awesome
 * rick_h_ goes to find food before the next meeting
<hatch> bac haha nicw
<jcsackett> hatch: are there any major tripping points for the dispatched service/unit detail views, or is that going to feel a lot like dispatching the local charm stuff?
<kadams54> rick_h_: wanted to follow up more on your comments to Jeff and I about visual treatments/wireframes for deleting units and whatnotâ¦
<kadams54> rick_h_: it's actually one of the last TODOs in my code :-)
<rick_h_> kadams54: sure thing in the visuals for inspector v3 there's some stuff in the inspector where removed units are moved into a grouping and there's a 'are you sure' step for removing the service, the last image in the group on the right
<hatch> jcsackett it will be pretty easy
<rick_h_> kadams54: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1cWQ4TmRmRXJBc0E
<jcsackett> hatch: awesome. i'll start in on that then.
<hatch> jcsackett the inspector dispatcher will need to instantiate the inspector with a 'select this unit' flag, then after it's instantiated it will need to open the dropdown, select the unit, etc etc
<hatch> jcsackett so 'easy' but lots of work
<kadams54> rick_h_: OK, taking a lookâ¦
<hatch> jcsackett but you won't have to reinvent the wheel like you did with the local inspector stuff
<rick_h_> kadams54: sure thing, let me know if you want to walk through it
<rick_h_> kadams54: but honestly, I think they'll be follow up cards
<kadams54> rick_h_: hah! yeah, that was going to be my next question.
<rick_h_> kadams54: so be aware, but I'd move forward with the 'backendish' cards now and we'll clean up the UX as a follow up
<kadams54> rick_h_: Excellent, we're on the same page then.
 * rick_h_ feels like a winner!
<hatch> jcsackett I'll probably be still online, so ping me if you have any q's 
<jcsackett> hatch: will do.
<kadams54> guihelp: looking for a review and a tiny bit of QA on https://github.com/juju/juju-gui/pull/412 (The first build failure has already been fixed, soâ¦ fingers crossed.)
<kadams54> Heading out for dr. appt.
<rick_h_> good luck kadams54 
<hatch> hey is ci down?
<rick_h_> hatch: seems so, /me looks
<hatch> did MS decide to upgrade the instance? lol
<rick_h_> hmm, our other one is down as well :/
<rick_h_> network issue? 
<hatch> posssssssssibly
 * rick_h_ is checking dashboard
<rick_h_> oh boy
<rick_h_> jujugui all our azure vms are gone, working with our account holder to figure out what's happened
<rick_h_> bac: can you please go to the dashboard and make sure we pull down our last backups of both?
<bac> uh oh
<rick_h_> bac: and look at setting up a shared account info for bringing up a new CI under ec2 (ssh key, etc) and I'll setup some credentials in a few minutes
<bac> rick_h_: are you asking me to recreate our jenkins on ec2?
<rick_h_> bac: to get ready to
<rick_h_> bac: get the backups in place, generate a shared ssh key, whatever else we need to setup a shared env correctly
<bac> rt
<rick_h_> bac: because if this doesn't move forward very fast with MS then we'll bring it up and recreate it 
<jrwren> does it run on US West?
<rick_h_> jrwren: was east I believe
<rick_h_> but the mvs are just gone, the storage buckets are still there though
<hatch> heh that's no good
<hatch> anything I can help with?
<rick_h_> hatch: no, not unless you know where azure would log "by the way all your machines belong to us" messages
<rick_h_> :)
<hatch> lol no sorry - is there an access log? Maybe one of us accidentally clicked 'delete all!!!!!!'
<jrwren> maybe I'm following the scavenger hunt incorrectly and I killed it :)
<hatch> uh oh , the tweens woke up are taking selfies....my internet just slowed to a crawl
<rick_h_> http://uploads.mitechie.com/lp/azure-ci.png :(
<hatch> what the heck....
<bac> rick_h_: i see we have backups as of 6/29 20:00Z (us) and 6/26 (blues)
<rick_h_> :(
<rick_h_> jujugui CI is down and out. We've identified the issue and bac is recreating the environment. 
<rick_h_> jujugui so all code landings will have to wait until it's back up. Sorry for the delay if bac needs a hand please jump and help him. 
<kadams54> Sorry, I may have missed something while I was awayâ¦ is it just me, or is CI down?
<jrwren> 14:56   rick_h_| jujugui CI is down and out. We've identified the issue and bac is recreating the environment.
<jrwren> 14:56   rick_h_| jujugui so all code landings will have to wait until it's back up. Sorry for the delay if bac needs a hand please jump and help him.
<kadams54> Ah thanks jrwren!
<bac> jujugui: i'm having trouble getting azure to bootstrap.  if this latest attempt fails i'm moving to ec2.
<kadams54> bac: OK, thanks for the update.
<rick_h_> bac: rgr thanks for trying
<bac> ha, must've scared azure.  next try came right up.
<bac> rick_h_, jcsackett: what were the two jenkins instance called? jenkins and jenkins-the-blues?
<bac> rick_h_: who controls the dns entry?
<rick_h_> bac: I do, let me know what cname to point to
<rick_h_> bac: that works. 
<kadams54> rick_h_, hatch: I've got my choice of services, containers, or machines on these delete cards. Any recommendations about what to tackle next?
<hatch> well machine and container are one and the same
<hatch> I suppose there are some nuances, but I'm not sure one can be done without the other
<hatch> kadams54 so machines/containers will also have some cascading tasks which need to be done
<hatch> like removing placeUnits onto a ghost machine 
<kadams54> hatch: sounds to me like you're voting for services :-)
<hatch> nah that will also have cascading tasks. 
<hatch> remove relation
<hatch> remove addUnits
<hatch> remove setConfigs
<hatch> heh
<hatch> kadams54 so probably doing remove containers/machines will be the best place to start
<hatch> it'll have the least 'extras' I think
<rick_h_> kadams54: the other thing is to take a break and go look at the upgrade service UX and such as well
<kadams54> rick_h_: I'm not seeing any cards for the upgrade service UXâ¦ do they need to be created?
<rick_h_> kadams54: hmm, /me looks thoght it was there
<hatch> jcsackett how goes the inspector unit stuff?
<rick_h_> Makyo: can help get you some direction
<rick_h_> kadams54: oh, huw got it in progress
<jcsackett> hatch: alright; my lxc was fubared for a chunk of the day, so i haven't gotten as far as i would like.
<hatch> ahh, do you dev in a lxc ?
<jcsackett> hatch: i do. don't like to install lots of crap on the main machine, and don't care for VMs.
<jcsackett> mind you, apparently LXCs have their own flaws. :p
<hatch> haha, interesting, I never thought of that, I also have an issue with install bloat after a year of working on stuff
<hatch> lxc's would sure help that
<kadams54> rick_h_: looks like there's another UX-ish card for adding uncommitted cues to service view/blocks
<jcsackett> hatch: it also has the benefit of meaning i'm always developing on a system that's at least the same ubuntu release as our production instance.
<rick_h_> kadams54: sure, that'll get you into some fun stuff
<hatch> jcsackett yeah good call - I'm really trying to get Ubuntu to run properly on this hardware, it's not going so well, the dual gpu is really a gong show
<hatch> rick_h_ how id the new laptop? have 14.04 on it yet?
<jcsackett> hatch: what are you using?
<rick_h_> hatch: yea, 14.04 on it, got the touchpad going a bit better
<rick_h_> but it's a mix bag
<hatch> jcsackett OSX with a vm
<hatch> jcsackett I'd like to work with someone to get the drivers are fixed up but I'm guessing whoever is writing it would need the machine for quite a while
<bac> jujugui: trying to install dependencies on CI machine following HACKING guide.  calls for python-selenium but one is not found.  anyone know where it comes from in precise
<Makyo> jujugui review/qa for destroy service in ECS https://github.com/juju/juju-gui/pull/413 (also, just found some coyote kill in the yard, going to be afk while I get that taken care of)
<huwshimi> Morning
<rick_h__> morning huwshimi 
<huwshimi> rick_h__: hey
<rick_h__> huwshimi: heads up, CI went boom today and we're recovering still
<rick_h__> huwshimi: so no landing/test runs for the moment. 
<huwshimi> yay!
<rick_h__> heh, like a snow day?
<huwshimi> :)
<rick_h__> huwshimi: do you have anything to merge?
<huwshimi> rick_h__: Not yet. Probably today sometime though.
<rick_h__> huwshimi: ok cool
<hatch> Makyo i'm reviewing your branch, fyi
<Makyo> Thanks
<hatch> Makyo looks good - looks like the approach we discussed worked well
#juju-gui 2014-07-01
<rogpeppe2> mornin' all
<rogpeppe2> urulama: hiya
<urulama> rogpeppe1: morning 
<rogpeppe1> urulama: how's it going?
<rogpeppe1> urulama: i just responded to your comments on the bundles spec, BTW
<urulama> great, thanks, had some time this morning to read the docs
<urulama> agree to keep things simple
<rick_h__> morning
<urulama> morning
<bac> hey rick_h__ (i got disconnect after my last ping)
<rick_h__> bac: morning
 * rogpeppe1 now has a keyboard with all keys in place
<rick_h__> yay?
<rogpeppe1> darn fiddly, replacing those hinges
<rogpeppe1> yay!
<rick_h__> hah, laptop keyboard?
<rogpeppe1> only one hinge slightly broken on installation, seems ok so far
<rogpeppe1> rick_h__: yeah
<rogpeppe1> rick_h__: broken after i spilled cream on it the other day at the end of the hangout
<rick_h__> oh :(
<rogpeppe1> rick_h__: not broken by the cream, but broken when i took the keys off to clean off the cream...
<rick_h__> I did some tea with honey once. Yea, those scissor switches are a pain to get off and back in place
<rogpeppe1> it's the tiny little plastic protrusions which are so so so easy to break
<rogpeppe1> and you actually have to exert a reasonable amount of force in *just the right* way to get it in
<rogpeppe1> anyway, lunch!
<rick_h__> jrwren: morning
<rick_h__> jcsackett: can you and jrwren get together and go through the issues jrwren hit yesterday on getting cloud providers going and help find if there are existing bugs around the issues? 
<jrwren> oh boy.
<rick_h__> jrwren: well if you're going to find broken stuff we need to make sure they're going to be addressed :)
<jrwren> agreed.
<jrwren> this shall be a fun dive. 
<rick_h__> I think the azure one is likely to be the timeout issue that bac hit before
<jrwren> yup, that is what made me think its a bug.
<rick_h__> and there's an email thread around apt-get upgrade timing out juju in azure
<jrwren> the joyent one might be the same or similar bug.
<jrwren> but bac said it worked the next time. that was not the case for me.
<jrwren> I think bac was using 1.18, I was using 1.19.[34]
<rick_h__> jrwren: ok, haven't seen anything on joyent, but we don't use it actively
<rick_h__> yes, because environment upgrades are only supported from stabel to stable releases
<jrwren> understood.
<rick_h__> he moved back to 1.18 (stable is even) while you were on 1.19 (odd is dev)
<rick_h__> so it's more important to figure out the bugs/issues in 1.19 to make sure they're addressed before 1.20 is released (1-2wks)
<rick_h__> jrwren: but get wit jcsackett when he's around and see if he can help find bugs, intro you in #juju if there's questions, etc. 
<jrwren> sounds great.
<rick_h__> jrwren: and in between time move forward with the tasks using other cloud providers so that you can move forward
<jrwren> i'll jump in on my own too, so i'm not entirely blind.
<rick_h__> ok
<jcastro_> jrwren, welcome to Canonical!
<jrwren> jcastro_: thanks!
<jrwren> consider me your friendly chaos monkey.
<jcastro_> I heard
<jcastro_> <3
<jcsackett> jujugui: i have crap all for internet at home. TWC claims it will be fixed this afternoon. running to the coffee shop.
<bac> jujugui: http://ci.jujugui.org:8080/ may be happy again but i guess we won't know for sure until a controlled branch is proposed/approved.  please let me know when you do so.
<bac> jcsackett: ping
<bac> marcoceppi: where do i file a bug against a charm?  precise/jenkins specifically?
<marcoceppi> bac: https://bugs.launchpad.net/charms/+source/jenkins
<bac> marcoceppi: thanks.  i poked around but couldn't find it.
<rick_h__> bac: there's a branch from Makyo to alnd
<rick_h__> bac: we can use to test the lander part at least
<bac> rick_h__: ok
<bac> rick_h__: this install may be suspect since i had to do so much stuff behind the scenes.  juju may not be happy with me.
<rick_h__> bac: ok, well let me know if we need to retry to restore?
<rick_h__> on the one hand we need to get this up, but the goal is to get something up we can use going forward and not have to repeat this
<bac> rick_h__: agreed.  i guess i'd say let's just keep an eye on things.  it is up now so until we see something funky i'd leave it be.
<rick_h__> bac: ok, trying to shipit the branch from Makyo 
<rick_h__> Makyo: around? my next meeting will overlap the standup and need you to run it if possible. 
<kadams54> bac, rick_h__: my PR is also ready to land. Waiting to see how things go with Makyo'sâ¦
<rick_h__> kadams54: ok, it's running keep an eye on it
<rick_h__> I've got a call in a few so will not be able to track it down
<jrwren> what is the juju way of not repeating this?  custom charms?
<rick_h__> jrwren: fork a charm, push it up under your namespace
<jrwren> cool. got it.
<rick_h__> jrwren: so bzr branch the original, and bzr push to ~jrwren/charms/jenkins
<rick_h__> or hte like
<rick_h__> need to match the exacty syntax, should be in the docs
<jrwren> as for my "nothing working", i've figured it out. I guess I'll file a bug, although its a pretty niche issue.
<rick_h__> jrwren: ok, well still worth documenting for other's to search/find
<rick_h__> jrwren: but good to hear it's something that sounds like you can move forward around
<jrwren> yes. I should have thought of it sooner. I was frazzled from breaking your CI yesterday.
<rick_h__> jrwren: all good :)
<bac> jrwren: how are you going to fork the jenkins charm?
<bac> jrwren: if you're looking to make a change i have a suggestion!
<rick_h__> bac: sorry. that was just my example
<rick_h__> bac: current charm in my brain atm :)
<jrwren> oh, i'm not. I am more trying to understand some juju philosophies.
<bac> rick_h__: bug 1336273
<_mup_> Bug #1336273: Add ability to specify PPAs <jenkins (Juju Charms Collection):New> <https://launchpad.net/bugs/1336273>
<rick_h__> bac: oh cool
<bac> rick_h__: if we had that, we could go a long way to having a bundle that did most of our setup
<rick_h__> jrwren: the branch philosophy is on the chopping block though. There's a spec doc I can share if you're interested 
<bac> rick_h__: so if someone want experience in charm authoring...
<bac> s/want/wanted/
<rick_h__> rogpeppe1: for the standup, can we get a doc shared up for that work so we can start to look at things?
<rogpeppe1> rick_h__: ok, will do
<Makyo> Looks like the merge build failed, but it seems like one of the random selenium failures
<jrwren> it was: https://bugs.launchpad.net/juju-core/+bug/1336313
<_mup_> Bug #1336313: juju fails silently when .ssh/config has a ControlMaster set <juju-core:New> <https://launchpad.net/bugs/1336313>
<rbasak> jrwren: I've not hit that bug specifically, but I did appreciate that "juju ssh" seemed to use my own ControlMaster correctly.
<rbasak> jrwren: are you sure that you didn't have a cached connection to an existing machine with a matching %r/h/p that was hung or something?#
<Makyo> jujugui call in 10, kanban now
<jrwren> rbasak: i don't see how, since those hostnames are basically random from teh cloud provider each time.
<jrwren> rbasak: do you use control persist yes? or a timeout? maybe you have a small enough timeout?
<rbasak> jrwren: I'd be interested to know what the real problem is rather than disable control master use completely. I find it really useful - it speeds things up massively.
<jrwren> rbasak: ok, I'll experiment more. 
<rbasak> I use ControlPresist 3600
<jrwren> i'll be that is the difference.
<bac> hazmat: you approved my tls branch for juju-client.  will you be merging it soon?  i've got a card in kanban that i'd like to kill.
<rbasak> That's an hour, though. Surely the juju timeout isn't that long?
<jrwren> *i'll bet*
<rbasak> jrwren: I wonder if this is Azure-specific? I wasn't aware of any need to be able to ssh the bootstrap host during bootstrap. I thought Juju entirely used cloud-init?
 * rbasak has commented on the bug
<rbasak> I hope that's useful and constructive.
<jrwren> already useful to me. I need to try with timed ControlPersist instead of just "yes"
<Makyo> jujugui call now
<Makyo> antdillon, urulama call now
<rick_h__> urulama: is on call with me
<rick_h__> ant as well
<jcsackett> nothing quite like being hangouts with almost no bandwidth. :p
<hatch> heh that's why I wasn't in today :)
<hazmat> bac, yeah.. sorry catching up on backlog.. i'll merge shortly
<bac> thanks hazmat
<bac> jcsackett: when you 'juju ssh' to azure instance do you find the ssh connection goes away frequently?
<jcsackett> bac: i haven't done any juju stuff on azure; i only ssh directly into the jenkins units.
<bac> jcsackett: yeah, should be the same, though. they don't drop?
<jcsackett> bac: i haven't noticed it, no.
<jcsackett> jujugui: can someone confirm a bug for me?
<hatch> sure
<jrwren> so... when I broke CI yesterday, why didn't I get a "environment is already bootstrapped" message? were there state storage changes? 
<bac> maybe
<rogpeppe1> jcsackett: yup, there's a bug
<rogpeppe1> jcsackett: oh, you mean a *particular* bug? :-)
 * jcsackett laughs
<jcsackett> if someone can open comingsoon.jujucharms.com (or any other develop branch instance they have) and deploy a service, i'm seeing a gray bar instead of the charmbrowser or the service inspector, but i'm having lots of oddities today.
<hatch> looking
<jcsackett> this is w/o flags, so i believe the service inspector should open.
<bac> jrwren: i think you should have.  try to bootstrap the same env twice on ec2 and see what happens
<hatch> jcsackett correct, something is broken
<jcsackett> hatch: cool, i'll file and set up a card.
<hatch> it doesn't changeState to the new url any longer
<hatch> jcsackett urgent imho
<bac> hatch: quick, steal that for your QA day bug!
<jcsackett> agreed.
<jcsackett> nope!
<jrwren> bac: exactly what I was thinking, and exactly what I just got on azure, but I didn't yesterday with the CI environment
<jcsackett> it's mine, b/c i forgot to do QA the other day. :p
<hatch> bac lol I think i've filed enough bugs this past week to get some wiggle room on qa day :)
 * bac admits he sat on a bug for 12 hours last week
<hatch> jcsackett I think this was because one of the branches that recently landed didn't get qa'd without the mv flag
 * jcsackett nods
<jcsackett> hatch: looks like.
<jcsackett> card made in urgent lane, for whoever is looking for work.
<jcsackett> hatch: is there any reason we can't rename the "UIState" thing back to State?
<hatch> jcsackett none I can think of
<hatch> jcsackett oh I left it like that because we have a 'state' attribute in app.js
<hatch> which has NOTHING to do with state
<hatch> lol
<hatch> it's the environment or somethin
<hatch> g
<jcsackett> ok then.
<jcsackett> we'll leave it be, but i'll remove the XXX saying we can rename it.
<hatch> jcsackett well we CAN rename it, but we should probably also rename the other state thing in app to something that makes sense
<hatch> else it'll just be even more confusing heh
<hatch> there will likely be a ton of renaming required though
<jcsackett> hatch: i have a growing feeling that to dispatch charm details and unit details on the inspector we need to get rid of slots.
<hatch> why's that? 
<jcsackett> hatch: well, details are all rendered via the "showViewlet" stuff, which is slots based, isn't it?
<jcsackett> hatch: i guess we don't have to get rid of it.
<jcsackett> we're just dealing with more stuff to cleanup.
<jcsackett> and inspectors now need to conditionally render viewlets in slots both on event and on init.
<hatch> hmm lemme take a look
<jcsackett> hatch: ok.
<hatch> jcsackett https://github.com/juju/juju-gui/blob/develop/app%2Fviews%2Finspectors%2Fservice-inspector.js#L89
<hatch> here is where you would conditionally show the unit details
<hatch> jcsackett here is where it shows the unit details https://github.com/juju/juju-gui/blob/develop/app%2Fviews%2Fviewlets%2Fservice-overview.js#L724
<hatch> currently
<jcsackett> Don't forget charm details. That's also needing update. 
<jcsackett> So then the click fires change state, and I guess renderui gets called again...
<jcsackett> Yeah, ok. I hadn't gotten back into state land; this isn't the problem I thought it was. 
<hatch> hmm
<hatch> this might actually be a little more work
<hatch> we can't re-render the inspector
<hatch> so it has to know it's already rendered
<hatch> maybe it already does that
<hatch> heh
 * hatch looks
<hatch> jcsackett yeah you'll have to implement something for the inspector like there is for the charmbrowser
<hatch> so that it doesn't 'aways' re-render the inspector, but insteads just sets new data in
<hatch> instead
<jcsackett> hatch: dig. 
<jcsackett> I *thought* that might be a wrinkle. 
<hatch> the proper inspector method is _inspector
<hatch> I'm not sure where `inspector` method is used heh
<hatch> it might need to be removed....the `inspector` method
<jcsackett> I think it's leftover from the old system. 
<hatch> yeah
<rick_h__> hey guys, how goes?
<rick_h__> Makyo: working on landing your branch, looks to be running tests now at least
<rick_h__> kadams54: yay for yours landing
<kadams54> Yup
<rick_h__> jcsackett: you're set then? 
<Makyo> rick_h__, ah, thanks, was trying to figure that out
<rick_h__> Makyo: yea, no idea why it's doing that and didn't for kadams but oh well. 
<rogpeppe> rick_h__: i'm done for the day now. here's a link to the on-going API proposal doc: https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc/edit
<rogpeppe> rick_h__: formatting is a bit scrappy i'm afraid :-)
<rick_h__> rogpeppe: awesome thanks. Will take a look. Can you move ot to the 14.04 specs folder if it's not in there currently?
<rick_h__> and make sure the team's got edit
<rogpeppe> rick_h__: everyone's got edit, i think
<rogpeppe> rick_h__: not quite sure how to do the folder thing in google docs
<rogpeppe> rick_h__: i didn't even know there *were* folders for google docs :-)
<rick_h__> https://drive.google.com/a/canonical.com/?usp=docs_web#folders/0B95cjYKYHu9oMm50aVlLS0pYZWc
<rick_h__> is the specs folder
<rick_h__> somehow want to get it in there but yea not sure about it myself
<rick_h__> jujugui heads up the two calls with Mark S today went well. He's excited we've got urulama and jrwren starting and loved hearing the osx stuff got out and is interesting in checkout out the usage of that
<bac> cool
<rogpeppe> rick_h__: i'll work out how to put something in a folder tomorrow...
<rick_h__> rogpeppe: ok, will try to figure it out. Even if we have to create a new doc in that folder and copy/paste
<urulama> \o/
<rick_h__> rogpeppe: have a good evening
 * rick_h__ goes to find some food now that calls are done for now
<bac> he's usually pretty good about seeing stuff go by on G+ so i was surprised that went unnoticed
<rogpeppe> urulama: see ya tomorrow morning
<rogpeppe> rick_h__: have a good rest-of-day
<rogpeppe> g'night all
<urulama> rogpeppe: bye
<bac> rick_h__: after looking at the other jenkins installation i think we may be better to manage charmstore on our own.  their jenkins is 1.4, the plugins we need aren't installed properly, etc.
<rick_h__> bac: ok, then let's do it
<bac> rick_h__: i'm trying to install a slave now.  if it works i'll run with it.  otherwise i'll talk to sinzui about their upgrade plans
<rick_h__> bac: feel free to create cards and let me know if you need help
<rick_h__> bac: rgr
<rick_h__> ok, now really going to head out for lunch and move to the coffee shop for the afternoon. 
<jcsackett> rick_h__: i am set.
<jcastro> http://askubuntu.com/questions/457635/what-is-a-configuration-to-allow-access-to-juju-gui-in-local-provider
<jcastro> do we support the gui like this?
<jcastro> and if so, how?
<rick_h__> jcastro: looking
<rick_h__> jcastro: not yet, juju has to support the networks in containers and be able to expose the internal port80 stuff out. 
<rick_h__> jcastro: I'm not 100% sure on the status of that in juju-land. 
<jcastro> ok want me to answer it or you got it?
<rick_h__> jcastro: but the gui is hanging because it probably can't talk to juju from that container 
<jcastro> I am going through our question queue
<rick_h__> jcastro: I'll put something together. 
<rick_h__> jcastro: side note, do you know if brew has download/install stats?
<rick_h__> jcastro: we're curious on measing quickstart install on osx
<jcastro> no clue, will investigate
<rick_h__> jcastro: ok, wasn't sure since you guys have some brew stuff/juju itself. We can look into it
<Makyo> Alright, got a legit failure.  At least it's something to go by.
<jcastro> rick_h__, doesn't appear that way
<jcastro> rick_h__, from looking at the formula
<rick_h__> Makyo: :/ ok
<rick_h__> jcastro: ok thanks
<jcastro> https://pypi.python.org/packages/source/j/juju-quickstart/juju-quickstart-1.4.0.tar.gz
<jcastro> it snags from there
<jcastro> since no one links to that except for brew, I would think that's where the stats go
<rick_h__> jcastro: right, but wondered if brew had a popcorn or the like to track installs from itself
<rick_h__> oh, does brew pull that down every install? 
<jcastro> yeah
<jcastro> it's a homebrew, that's the point
<rick_h__> heh, ok cool
<jcastro> I would do your next release at a URL you have GA on, and then update the formula to get the tarball from there
<rick_h__> Makyo: hmm, that's one I've not seen much. Is that legit then?
<Makyo> Bah, can't reproduce locally.  Not sure it is, rick_h__ 
<rick_h__> Makyo: ok, feel free to retry 
<rick_h__> Makyo: and let's keep an eye. Now that we know the CI stuff is running again. Sorry for the pain in landing
<Makyo> No worries! I'm watching.
<rick_h__> lol
<rick_h__> wow 534 downloads in the last week
<rick_h__> jcastro: ^ 
<hatch> nice
<hatch> jcsackett so I'm going to take off for the day, any q's about that inspector stuff before I go?
<Makyo> hatch, http://www.buzzfeed.com/tanyachen/americans-fail-canada-again
<hatch> Makyo haha I was going to paste that tomorrow :P
<hatch> I accept not knowing all of the provinces but damn some were just horrible!
<hatch> lol
<rick_h__> that is awesome Makyo 
<rick_h__> Makyo: what are you up to? Can you look at the card in urgent nexte?
<rick_h__> next that is
<Makyo> rick_h__, sure thing
<rick_h__> Makyo: ty, I'm hoping to stick hatch with a release this week and that one seems a blocker
<Makyo> Alright, sounds good.
<rick_h__> jrwren: can you make sure to file holiday time for the 4th please?
<rick_h__> jrwren: and just how goes overall?
<jrwren> i'll figure out how to file it.
<rick_h__> jrwren: sure thing, it's in the hr.canonical.com system
<jrwren> it goes... i have so many questions at this point, and mostly they are somehow influenced by yesterdays disruption.
<rick_h__> jrwren: once you login there's a list of your "all other absenses" and you can create a "New"
<rick_h__> jrwren: cool, want to chat? 
<jrwren> sure.
<rick_h__> jrwren: k, let's meet in the standup hangout from today
<bac> marcoceppi: you have any experience using the jenkins-slave charm?
<marcoceppi> bac: not for a long time, no
<bac> marcoceppi: do you know if after adding the relation the slave should be launched and marked as online?  i've formed a relation but the master sees it as offline and i can't get it online.
<marcoceppi> bac: are you using the charm store charm?
<Makyo> Well, that was easy.
<Makyo> Lemme test it.
<bac> marcoceppi: i took the cs charm and pushed it to LP for trusty
<marcoceppi> bac: I used more updated branches that were in the canonical-qa or some other users branches
<bac> marcoceppi: ok, cool
<marcoceppi> bac: these charms are on our list for the audit
<marcoceppi> so I'll be pushing to update them
<Makyo> jujugui quick PR for ghost inspector https://github.com/juju/juju-gui/pull/414
<rick_h__> Makyo: looking, can you rekick your other pr for land please while I do?
<rick_h__> Makyo: looks like it got hung up in sauce land this time :(
<Makyo> Yeah, boo.  Will kick.
<rick_h__> Makyo: sorry, can't QA. I need to setup an env on this new laptop and am heading out shortly
<rick_h__> jujugui going afk for a bit and will be back later. Have some later calls tonight. 
<bac> jujugui: what am i doing wrong here when trying to checkout a specific revision: http://paste.ubuntu.com/7732968/
<Makyo> Fiiinally landed.  Yeesh.
<rick_h__> bac: git fetch first?
<rick_h__> bac: where is that revision located?
<rick_h__> bac: if it's in a pull request, you need to be watching the pr branches in the branch spec
<bac> rick_h__: this is in the jenkins slave
<bac> rick_h__: so do i need to do some manual config before jenkins can checkout the specific branch for the PR?
<rick_h__> bac: ok, so if you look at the .gitconfig on the gui CI server there's some stuff to make git look at the special places github puts pr branches
<rick_h__> bac: once that is in place, a git fetch should update and load the pr locations and then you can git checkout the hash
<bac> rick_h__: ok, i just copied the .gitconfig to the slave
<bac> and the checkout worked
<bac> hurrah
<rick_h__> bac: cool
<bac> rick_h__: can you look at http://ci.jujugui.org:8080/job/charmstore/9/console
<rick_h__> bac:  looking
<rick_h__> heh, java and git don't mix
<rick_h__> bac: looking into it, can you give me access to the slave machine as well please?
<bac> rick_h__: alreadydid
<rick_h__> bac: ok, everything looked ok, but with the gitconfig change I wiped the workspace and restarted a build using current master rev
<rick_h__> bac: and it looks like it's running
<bac> i'm beginning to think the jenkins charms are dangerous.  just give a false sense that they are doing something worthwhile when you still need to do so much by hand.  this is not idle carping.
<rick_h__> bac: yea, the charms need so much work and jenkins, being so UI driven (vs a darn text file to config) makes it hard to setup and restore
<bac> rick_h__: well it certainly is getting much further
<bac> but then died
<rick_h__> bac: ok that failed
<rick_h__> needs hg installed?
<bac> uuid not installed.  my bad.  hg too
<rick_h__>  imports code.google.com/p/go.crypto/pbkdf2: exec: "hg": executable file not found in $PATH
<rick_h__> ok cool, that looks like progress though
<rick_h__> thanks
<bac> installing via the charm config so it'll be present if i download a bundle
<bac> rick_h__: i'm having a lot of trouble with the juju gooey being non-responsive.  'save changes' button goes dark but never returns, for instance.
<bac> same with 'deploy'.  haven't seen this on real(tm) providers
<rick_h__> :/
<bac> geez, mercurial is a pig, in terms of dependencies
<jrwren> the move to github didn't include history?
<Makyo> jujugui anyone have a moment to qa https://github.com/juju/juju-gui/pull/414 ?
<rick_h__> jrwren: it did for the gui, what are you looking at?
<bac> rick_h__: i'm stuck and unsure how to proceed
<bac> rick_h__: you still around or we can talk about it tomorrow
<rick_h__> bac: yea, just got off call #1 
<rick_h__> what's up?
<bac> rick_h__: here's the deal: jenkins checks out juju/charmstore into a workspace.  but to be usable, it has to be in a properly set up go directory structure.
<bac> rick_h__: so i copy the workspace checkout to a freshly minted, GOPATH
<rick_h__> ruh roh
<bac> but then 'go get' in that directory doesn't work due to git being unhappy
<rick_h__> can we make the workspace a GOPATH?
<bac> dunno
<rick_h__> bac: yea, so most things around jenkins means turning the workspace into the root of the world for that code/work
<rick_h__> bac: so I'd assume we'd need to do something so that the workspace is the root/GOPATH source for all things that go on in there
<rick_h__> bac: and that it's setup in the jenkins config via env vars or the like
<bac> rick_h__: well not the root but somewhere down the tree
<rick_h__> bac: there's stuff in the job to define env vars and the like for the job/process
<rick_h__> bac: ok, yea I'm not up on how GOPATH expects to work out
<rick_h__> but in python world I'd treat it like a virtualenv root 
<bac> if GOPATH is /tmp/foo then this branch needs to be checked out to /tmp/foo/src/github.com/juju/charmstore
<bac> and then it needs to fetch all of the supporting stuff
<bac> that's why i hoped just copying the freshly checked out directory to a well constructed GO directory tree would work.  but it doesn't
<bac> rick_h__: anyway, that's where i'm at.  need to run. talk tomorrow.
<rick_h__> bac: ok let's chat tomorrow. Thanks for the great work on it
<jrwren> rick_h__: i was looking at juju/juju :(
<rick_h__> jrwren: oh, it should have history?
<jrwren> maybe it does, but not branches?
<rick_h__> they talked enough about how to do it
<jrwren> which, now that I think about it, makes sense given how bzr branches
<rick_h__> right, they're all collapsed into a root history 
<jrwren> i was hoping to git diff 1.18 with trunk
<rick_h__> oh hmm, no tags
<rick_h__> yea, probably have to go check out the 1.18 release in LP and check last comment or something and fine the rev in the git history to diff
<rick_h__> pita 
<jrwren> if that rev ever made it to git
<jrwren> since it was in branch, it may not have
<rick_h__> it should have, I think all were kept. 
<rick_h__> I think the branch commits were inlined into the main one
<rick_h__> at least that's how our juju-gui move went
<rick_h__> but the 1.18 should have been a mainline commit/tag 
<jrwren> in that case, I can find it in the reflog
<rick_h__> jrwren: any luck on the reproducing?
<rick_h__> jrwren: and if you're still around go away, day's over :P
<jrwren> imma keep working on it, at least until the family gets home.
<jrwren> and, yes, I think I did repro.
<jrwren> its as simple as we made it sound
<jrwren> but... azure: *sigh*
<jrwren> Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/libe/liberror-perl/liberror-perl_0.17-1_all.deb  503  Service Temporarily Unavailable
<jrwren> i should try to repro on AWS too.
<huwshimi> Morning
<rick_h__>  morning huwshimi 
<huwshimi> rick_h__: Hey
#juju-gui 2014-07-02
<huwshimi> Is anyone about?
<rick_h__> huwshimi: what's up?
<huwshimi> rick_h__: I'm just a bit stuck with this branch...
<huwshimi> rick_h__: I probably just need to talk it over with someone
<rick_h__> huwshimi: sure, let me look at what you're up to
<rick_h__> huwshimi: setup a call and I'll jump in
<huwshimi> ok
<huwshimi> rick_h__: https://plus.google.com/hangouts/_/gw3fj4cjdgws5hjs5dngj7og6ma
<rogpeppe> huwshimi, urulama: morning!
<huwshimi> rogpeppe: Morning
<urulama> rogpeppe: hi (got lost in the document land) :D
<rick_h__> morning
<luca> Morning rick_h__ we are planning to do some MV testing next Tuesday, what state do you think comingsoon will be in?
<rick_h__> luca: I'll see, I'm out tomorrow through tues so will leave instructions awnd try to keep an eye on it while away
<rick_h__> luca: but I'll have a sever lack of interwebs while away in the woods. This place has no cell coverage, but a clubhouse with slow wifi I can try to visit
<rick_h__> rogpeppe: got a sec to chat?
<rogpeppe> rick_h__: sure
<rick_h__> rogpeppe: https://plus.google.com/hangouts/_/g27ldilysl2kzyynhvqc3ahbiea?authuser=1&hl=en
<rick_h__> rogpeppe: google search ftw, found the resources draft spec, might be a bit out of date but something to look at. 
<rick_h__> rogpeppe: shared it with you so you should get an email/see it now
<rogpeppe> rick_h__: thanks
<rick_h__> rogpeppe: also forwarding you another email
<bac> hi rogpeppe, i'm having some issues with godeps.  do you have a moment?
<rogpeppe> bac: sure
<bac> rogpeppe: this is on jenkins, trying to build and test juju/charmstore.  i have this script: http://paste.ubuntu.com/7736543/
<bac> the godeps step is producing odd output: http://paste.ubuntu.com/7736539/
<rogpeppe> bac: sorry, didn't see your second line there. looking.
<bac> rogpeppe: in this output http://paste.ubuntu.com/7736609/ i see two problems: 1) some specified bzr version revisions don't appear to exist.  is it then trying again too quickly and hitting locking issues?
<bac> rogpeppe: ignore that second paste and look at the most recent
<luca> rick_h__: thatâs no problem, we are just testing users reaction to how its designed and to see how they would use the drag and drop feature
<rick_h__> luca: sounds good
<rogpeppe> bac: interesting. i'll try to repro
<bac> rogpeppe: thanks
<bac> rogpeppe: the script changed a bit to produce that output.  it was: http://paste.ubuntu.com/7736632/
<rogpeppe> bac: hmm, i tried (almost) exactly those steps and it works for me
<bac> rogpeppe: with a fresh GO directory?
<rogpeppe> bac: yes
<rogpeppe> bac: hold on, i'll paste a slightly simpler script which should be equivalent
<bac> rogpeppe: cool, can you do our ci then?  i'll just have it email you.  :)
<bac>  s/trusty-slave/roger-slave/
<rogpeppe> bac: one thing that might be affecting it is that you really want to put $GOPATH/bin at the start of $PATH, in case there's a godeps elsewhere (unlikely i guess)
<bac> that's a good change but highly unlikely
<bac> rogpeppe: if you'll paste your simplification i'll try it on jenkins
<rogpeppe> bac: just making sure it works
<rogpeppe> bac: http://paste.ubuntu.com/7736692/
<rogpeppe> bac: it's possible that bzr doesn't like running concurrently
<rogpeppe> bac: hence the -P flag
<rogpeppe> bac: but i don't understand the `unrecognized import path "labix.org/v2/mgo/..."` error
<bac> rogpeppe: yeah, i'll bet that helps.  also the trap is nice.
<rogpeppe> bac: just like Go defer :-)
<bac> rogpeppe: line 11 won't cause my revision of charmstore to get updated will it?
<rogpeppe> bac: there is no revision of charmstore at that point
<rogpeppe> bac: so it'll get the latest
<bac> yes there is.  the one i copied
<bac> i don't want the latest
<rogpeppe> ah twats
<rogpeppe> bac: i just realised what you were doing :-)
<bac> sorry, i didn't explain well
<bac> i think the -P might be enough to test
<rogpeppe> bac: can it make a difference which way the merge happens?
<bac> rogpeppe: i don't understand your question
<bac> which merge?
<rogpeppe> bac: the merge that's being done with git pull
<bac> rogpeppe: in http://paste.ubuntu.com/7736539/ everything before line 20 is done by jenkins.  my script starts at 20.
<rogpeppe> bac: jenkins knows about GOPATH?
<rogpeppe> ah, i see
<rogpeppe> you mean the actual script that will be given to jenkins starts at line 20
<rogpeppe> bac: is it possible that the bot doesn't have permissions to access some third party hosts?
<bac> rogpeppe: yes.  prior to that is jenkins checking out the revision that it saw had changes.
<bac> rogpeppe: i don't think this machine has any outbound restrictions
<rogpeppe> bac: so jenkins sets up GOPATH for your script?
<bac> rogpeppe: with -P 1 godeps succeeded.
<bac> it is very odd it can't find the specified revisions
<rogpeppe> bac: ok, that's interesting. i wonder why it would fail when run concurrently.
<bac> rogpeppe: no, that GOPATH biz is done in my script
<rogpeppe> bac: so... some stuff before line 20 isn't done by jenkins?
<bac> rogpeppe: are you looking at http://paste.ubuntu.com/7736539/
<rogpeppe> i wonder how two bzr processes running in two entirely separate repositories can interact
<rogpeppe> bac: ah no, i was looking at your shell script
<rogpeppe> bac: i understand now
<bac> gotcha
<bac> rogpeppe: yay, it worked: http://paste.ubuntu.com/7736744/
<bac> rogpeppe: i'm a bit concerned that godeps isn't finding the exact revisions specified in dependencies.tsv
<rogpeppe> bac: in that latest output?
<bac> rogpeppe: yes, like line 36
<bac> rogpeppe: all where it says "trying to fetch new version" seem wrong to me
<rogpeppe> bac: so, the default behaviour of godeps is to update whatever repository is already in place
<bac> why didn't it find the specified version
<rogpeppe> bac: but in this case, the repositories are not downloaded yet
<bac> rogpeppe: i thought the idea was you wanted to peg it to a specific version
<rogpeppe> bac: so it tries to update; that fails (because it doesn't exist), then it downloads and tries again
<rogpeppe> bac: it does that
<bac> rogpeppe: but why doesn't it get the version i asked for?
<bac> so when it says "trying to fetch newer version" it is really getting the one is specified in dependencies.tsv?
<rogpeppe> bac: it's fetching the newest version it can find
<rogpeppe> bac: then it updates that to the version it needs (see line 46)
<bac> oh
<rogpeppe> bac: the error message is perhaps misleading
<bac> oh
<bac> i understand now
<rogpeppe> given that -P 1 fixed it, i think i'll have to make that the default
<rogpeppe> a pity really, because it speeds things up a lot
<bac> yeah, it is quite slow.  is it just bzr that has issues?
<rogpeppe> hmm, maybe there's a bug in my code; some of those errors look highly suspicious
<bac> rogpeppe: hey the 'trap' worked great.  i've learned something new and useful today.
<rogpeppe> bac: cool
<jcsackett> does anyone know what a url patter of /inspector/service/charm/true corresponds to? i see url generation for it and tests for it but can't actually seem nagivate to anything even *kinda* like that.
<jcsackett> jujugui ^
<jrwren> who runs azure.archive.ubuntu.com?
<rick_h__> jrwren: not sure, on some clouds we run servers on their network to provide those close archvies
<rick_h__> jrwren: I'd ask in #cloud-dev perhaps
<rick_h__> jrwren: in that link you posted a MS eng says it was corrected?
<rick_h__> jcsackett: so in theory we're supposed to have /inspector/servicename/charm to open the inspector for a service in the environment and /charm would open the charm details for that popout
<jcsackett> rick_h__: ah, so it *is* meant for this card.
<jcsackett> rick_h__: that was my assumption.
<jcsackett> dispatching details, much like /unit seems to be for unit details.
<rick_h__> jcsackett: right
<jcsackett> huzzah. i'm not actually colliding with anything.
<rick_h__> jcsackett: so the idea is that I should be able to share a link from my environment to you that has the inspector in the sidebar opened to what I'm looking at
<jcsackett> rick_h__: right, that i know--inasmuch as that's dispatching details. i was just curious why the /charm pattern was already part of the url stuff when we weren't doing that yet.
<rick_h__> jcsackett: ah, yea because it was ToBeImplemented
<rick_h__> :)
 * jcsackett laughs
<hatch> get back home from vacation...power is out....no biggy.....open fridge....it's warm.... :/
<rick_h__> oops :(
<hatch> guys drilling in fiber drilled through the cable bundle in many peoples backyards on Monday
<hatch> so I'm hotspotting yay
<hatch> heh
<hatch> oh and I have a big above ground cable running to the box in the yard for power
<rick_h__> hah
<rick_h__> jrwren: how goes the bug reproduction steps?
<jrwren> not great.
<jrwren> I think I picked 2, effectively not functional, providers.
<jrwren> imo azure and joyent don't work, or at least don't work with 1.19, I didn't go back to 1.18 to see if that matters.
<rick_h__> jrwren: ok azure we're aware of and there's work going on around that in 1.19 but not in the release 
<rick_h__> joyent we need to check for bugs on then and if we can't find them file them
<jrwren> different issue though, AFAIK.
<jrwren> i'm not hitting the azure ssh issue, which I see fixed in master.
<rick_h__> jrwren: but you had talked about doing an ec2 test on the bootstrap takeover issue
<jrwren> i am hitting the azure.archive issue 
<rick_h__> jrwren: right, there's a thread right now about not running apt-get upgrade on bootstrap and such
<jrwren> yup, i've not yet tried ec2. i'll do that
<jrwren> do you mean http://bugs.launchpad.net/juju-core/+bug/1316185 ?
<_mup_> Bug #1316185: juju bootstrap hangs in slow environments <juju-core:Fix Committed by axwalk> <juju-core 1.20:Fix Committed by axwalk> <https://launchpad.net/bugs/1316185>
<rick_h__> jrwren: yes
<jrwren> yeah, that is a different azure issue.
<rick_h__> jrwren: that's the one that bac hit on azure around slow/timeout related bootstrap 
<rick_h__> jrwren: ok, want t join the standup hangout early and let's chat out what's up and what we need to file bug-wise?
<jrwren> sure.
<Makyo> jujugui call in 10
<bac> rogpeppe: this is pro forma, but would you look at this trivial PR so i can exercise the landing? https://github.com/juju/charmstore/pull/8
<bac> rogpeppe: add a +1 if you would
<rogpeppe> bac: LGTM
<rick_h__> jujugui call in 2 
<antdillon> kadams54, where you looking for assets for gui?
<antdillon> kadams54, I have Spencor on the design team to provide any assets you need
<rick_h__> jrwren: so we're set from our call and have good stuff to move forward on from here correct?
<jrwren> yup
<rick_h__> jrwren: ok cool, so once we get these bugs filed let's go to ec2 and try to have juju work a few times before you give up on us :) 
<jrwren> ok.
<jrwren> i don't mind finding these bugs. it just makes juju better
<bac> rick_h__: if a jenkins -merge job fails, can you re-trigger another from github?  i added a second :shipit: but it is ignored.
<rick_h__> jrwren: definitely
<rick_h__> bac: youhave to remove the comment from the lander that says " merge job accepted"
<bac> rick_h__: ty
<rick_h__> bac: that's the trigger it uses to make sure it doesn't try to rerun a merge over and over
<bac> rick_h__: is a second marker required?
<bac> doubtful
<rick_h__> bac: no, just remove the marker and it'll retry
<rick_h__> assuming by marker you mean that comment
<bac> no i meant :shipit:
<rick_h__> bac: oh no
<rick_h__> it'll just retry
<bac> cool
<bac> rick_h__: we still have a call in five minutes, right?
<rick_h__> antdillon: so we're looking for something for the uncommitted indicator for service blocks
<rick_h__> bac: yes
<rick_h__> antdillon: in the visuals/etc we've got things for the MV UX, but trying to find one for the service view and the blue circle indicator that I recall having there
<rick_h__> luca: what is the final decision on uncommitted and service blocks? 
<rick_h__> luca: we talked about a lot of designs but can't find a final one that matches the grey line for relation. 
<rick_h__> luca: and what we need to indicator on the service block. Did we ditch the blue circle? 
<luca> rick_h__: no
<luca> rick_h__: sec iâll find image
<rick_h__> luca: ty, kadams54 is working on it and needs the resrouces 
<rick_h__> rogpeppe: are you free for a call in 1min?
<rogpeppe> rick_h__: sure
<rick_h__> rogpeppe: k, will link you in a sec
<rick_h__> https://plus.google.com/hangouts/_/canonical.com/jaas-store?authuser=1 rogpeppe 
<antdillon> rick_h__, Sure I just wanted to put kadams54 and Spencer in direct contact to speed up asset creation
<rick_h__> antdillon: rgr thanks
<hatch> Makyo did you have a reviewer for your branch? I just updated on develop forgetting about that bug and now I'm blocked lol
<Makyo> hatch, need a QA
<hatch> ok on it
<hatch> Makyo qa ok - but I don't understand the fix....why did destroying the inspector early cause it to not dispatch?
<Makyo> hatch, It left the state pointing at the temporary id.
<Makyo> hatch, and we wanted it pointing at the deployed ID.
<hatch> ahhh it didn't fire the serviceDeployed event
<hatch> got it, thanks, shipit!!!
<hatch> Makyo looks like your avatar is no more on github
<Makyo> What happened?
<Makyo> Shows up for me..
<hatch> Makyo https://github.com/juju/juju-gui/pull/414 you see it here?
<hatch> I had to remove/add mine again when it did this a couple weeks ago to me
<Makyo> Yep.
<hatch> hmm intersting
<hatch> Makyo build failed
<hatch> looks like gh error
 * Makyo froths
<Makyo> Mocha timeout.
<Makyo> Trying again.
<jrwren> something tells me series: precise machine mixed with cs:trusty/juju-gui-3  won't work. am I right?
<hatch> jrwren the gui charm is identical for precise and trusty
<hatch> but juju may complain about the tools missing
<hatch> :)
<jrwren> excellent.
<hatch> I want to write a android wear app......but Java......
<hatch> Makyo looks like another fail....
<hatch> CI borked?
<Makyo> Yeah, can't reproduce locally.  Not sure what's up.
<hatch> rick_h__ any insight into the failures of Makyo's branch?
<hatch> mocha is failing to start
<hatch> well Makyo I'm just going to pull your branch into mine so I am not blocked and hope for the best with this landing :)
<Makyo> Alright, sounds good.
<hatch> hmm apparently pulling it in creates a merge entry
<hatch> not a FF
<hatch> Makyo is your branch up to date with develop?
<Makyo> hatch, looks like there's one branch ahead of it.
<Makyo> Let me see if updating helps.
<hatch> jcsackett so this branch I'm working on requires me to modify the state object to select a tab in the inspector so we are likely going to conflict 
<hatch> jcsackett so I can put this branch on hold, any ETA on yours? (although it doesn't look like we can actually land anything anyways)
<rick_h__> hatch: looking
<hatch> rick_h__ thanks, I'm also going to move onto another card as mine and jcsackett's will conflict pretty badly in a few files
<rick_h__> hatch: wtf, mocha init timeouts? 
<hatch> right? I have noooo idea
<rick_h__> no idea honestly. Quick google seems to have some version unhappiness 
<hatch> rick_h__ is mocha instlled?
<hatch> installed
<rick_h__> but we've had good branches land
<rick_h__> yea, if it wasn't installed that would be a diff error I'd think
<rick_h__> hatch: quick call please?
<hatch> sure
<rick_h__> standup?
<hatch> yup there
 * rick_h__ goes to get food for today biab
<hatch> bac could you ssh into the ci box and see if mocha is already running?
<hatch> bac the process is mocha-phantomjs
<hatch> some of the reports seem like there is a mocha plugin missmatch which is causing our issues
<jrwren> juju-gui doesn't load in safari eh? :)
<hatch> jrwren there is an https issue with safari
<hatch> you need to pull some strings to make safari show it
<hatch> safari may be fast and good on battery usage but just like everything apple if you don't do it their way....
<jrwren> it loaded for me, but sits there spinning at Connecting to the Juju environment.  must be XHR https issues or something?
<hatch> wss
<jrwren> ah. i see.
<hatch> yeah - we have a card/bug to investigate/fix
<jrwren> that is windows sharepoint services, right? :p
<hatch> haha - yeah that'll be the day
<rick_h__> jrwren: you have to give it explicit permission
<rick_h__> jrwren: see the bug in the maint lane with a link to the bug report to make it work
<rick_h__> jrwren: if you're interesting in helping fix that as the bug report for the final mission let me know. It'd be a good one to fix up our charm around that
<rick_h__> https://launchpad.net/bugs/1322596 is the bug report with the instructions for clicking on 'show certificate' first and then it will work/load
<_mup_> Bug #1322596: deploying to 1.0.2 to live environment fails in safari <juju-gui:Triaged> <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1322596>
<hatch> juju quickstart is so awesome
<hatch> even if amazon is taking forever to give me new instances
<hatch> rick_h__ whenever you return I'll need some extra insight into this because it works just fine when I create a new instance myself....I'd need ssh access into the ci machine to investigate further
<rick_h__> hatch: rgr, getting ready for our call. We can jump in early
<hatch> just grabbing some headphones
<hatch> Makyo hey can you do me a favour to see if your CI can land?
<hatch> in test/index.html can you increase the timeout to 200,000 from 100,000
<hatch> rick_h__ lol we were so lagged, you left the room and then started talking again
<rick_h__> lol
<rick_h__> yea, gotta love tech until the bandwidth drops down 
<hatch> yep, using the latency of lte and video conferencing just doesn't quite pan out
<hatch> jrwren those are some funky steps for safari :)
<jrwren> it took me a while to even read them.
<jrwren> I looked, and said "huh" and looked again, and said "huh" again, and finally read again and understood.
<hatch> I don't think showing a dialogue to the user in safari to follow those steps is a very good UX haha
<jrwren> ha! no.
<hatch> rick_h__ do you have a preference for the cards I work on for the next...5 days? I can start on the scale up journey 
<rick_h__> hatch: sounds good to me :)
<rick_h__> redir: ? who let him in :P
 * redir hides in the shadows
<rick_h__> kadams54: jcsackett I cancelled out 1-1s because I'm out tomorrow. If you want to chat I've got 1 hr before I EOD and crawl to the couch for a nap 
<hatch> haha, hey redir
<rick_h__> bac: sorry, same for you as well if you want to chat this week
<redir> hi hatch 
<hatch> how goes things?
<bac> rick_h__: i think i'm good.
<hatch> but just wait until next week....amirite bac? amirite??
<bac> uh, sure.
<rick_h__> bac: cool, I see successfull charmstore runs woot!
<redir> hatch: busy:) finally home after 3 weeks of travel
<bac> hey rick_h__, i'm keeping my eyes on the hurricane, though.  there is a chance we may have to change our travel plans.  if we do i'll work friday and swap to next week.
<rick_h__> bac: oh right, I heard about that heading up the east coast
<rick_h__> bac: ok, well stay safe
<hatch> redir oh right, all of that vacationing 
<rick_h__> and don't tell mramm about that
<rick_h__> :P
<redir> hatch: 2 wseeks vaca one for work
<bac> it is supposed to get to around norfolk friday 8am.  we land there friday 2pm
<bac> hi redir.
<rick_h__> bac: /me crosses fingers for you
<redir> hola
<rick_h__> bac: are you set to work on other charmstore cards then tomorrow/monday?
<bac> rick_h__: haven't looked really.  but yeah, i'll pick up something
<rick_h__> bac: especially keep an eye with roger on the api v4 stuff
<bac> rt
<rick_h__> bac: ok cool then. Sounds like a plan. 
<hatch> rick_h__ so the scale up journey card has a bug associated with it for unit scaling....is this just for reference or...
<rick_h__> hatch: yea, it was filed as a bug from luca if I recall
 * rick_h__ looks at the bug
<rick_h__> hatch: oh, well I guess let's make sure while we're doing scale up journey that's fixed :)
<rick_h__> it might be drive-by-able or fixed as part of updating the scale up journey
<hatch> sounds good, and do you have reference to the latest scale up journey ui stuff?
<hatch> was it just what was in those new inspector mockups?
<hatch> wherever those are....
<rick_h__> looking
<hatch> I don't think a lot of these files were put into the drive, just shared...
<rick_h__> https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1NEtGaHJYZGM4enM
<rick_h__> yea, the shared stuff is in drive
<rick_h__> it's shared from there
<hatch> oh, I need to pin the proper directories or someting heh
<rick_h__> yea, search for the juju gui directory
<rick_h__> and in there is a design folder
<rick_h__> and in there are assets/wireframes for the things
<rick_h__> hatch: all else fails bug ant
<rick_h__> and spencer
<rick_h__> Makyo: looks like your branch landed yay
<bac> rick_h__: http://ci.jujugui.org:8080/job/charmstore-merge/
<bac> big blue dot
<bac> rick_h__: i have had to install jenkins-github-lander on the slave but i have not made it self-updating yet.  does it really need to be?  what about just a daily cron that does a pull?
<rick_h__> bac: to update the jenkins-github-lander tool itself?
<bac> rick_h__: yeah
<rick_h__> bac: to date I've just manually updated those whenever we landed an update to the lander tool
<rick_h__> so I'm fine either way
<bac> rick_h__: ok.  just need to be aware it lives on the slave too
<rick_h__> fortunately it's a quick manual step we could automate with juju run 
<rick_h__> bac: rgr, thanks for the heads up
<bac> you and 'juju run'
<rick_h__> well I got thinking a lot of the stuff we're doing could be scripted
<rick_h__> especially like this, since we can target the same command at many services/units
<bac> rick_h__: enabling future go projects should be much easier now...
<rick_h__> did a bit of face-palm that I didn't think of doing that earlier
<rick_h__> bac: awesome, thanks for fighting that down into shape so we've got some good problems solved for us going forward
<bac> rick_h__: i've created a bundle, and a branch with all of the required bits including the current .jenv file.  i'll push to a private location at ~yellow shortly.
<rick_h__> bac: awesome
<Makyo> hatch, https://github.com/juju/juju-gui/pull/416
<hatch> Makyo thanks :)
<hatch> rick_h__ was the "please test this" something added int he latest iteration of ci?
<hatch> Makyo hopefully this works heh, although I can't believe a 100s timeout is not enough lol
<rick_h__> hatch: hmm, yea it should just be auto running
<hatch> ahh ok then yeah something broken :)
<hatch> it doesn't auto-run any longer it doesn't look like
<rick_h__> hatch: hmm, did you trigger the current running test run?
<hatch> nope, Makyo is landing his latest branch
<rick_h__> oh hmm, maybe that triggered it
<hatch> but that should be the merge 
<rick_h__> hatch: right
<jcsackett> rick_h__: naw, i'm good.
<rick_h__> jcsackett: ok cool
<rick_h__> hatch: flipped a couple of switches. Will see if it runs test runs
<hatch> sounds good thanks
<bac> rogpeppe: juju/charmstore now has jenkins landing.  like our other projects, after approval use :shipit: to trigger a final test and landing.
<rick_h__> bac: he's EOD, can you send an email to peeps maybe?
<rick_h__> wow, didn't realize how popular a name uros was until looking in lp for uros
<rick_h__> jujugui I'm out. Time to get the camper loaded up and ready for the trip. I'll be around via email or hangout if you need anything. 
<hatch> have a good holiday rick_h__ 
<hatch> I'll try to not break anything.....
<hatch> try
<rick_h__> woot woot
<rick_h__> :P
<hatch> :D
<rick_h__> keep an eye on that shifty jrwren character  :P 
<rick_h__> and make sure to help out with any juju fun 
<hatch> you bet
<jrwren> imma see what I can break.
<hatch> plz don't let it be ci again......plz not ci :P
<jrwren> !np
<jrwren> i'm really NOT going to see about breaking anything. With my luck lately, things will just happen.
<hatch> hah
<hatch> oh blarg this viewlet manager
<bac> good evening gui-peeps
<hatch> cya bac
<hatch> jcsackett ok I'm totally with you on this viewlet manager thing
<hatch> er rick_h__  ^
<hatch> it's gota go
<hatch> gotta 
<jcsackett> hatch: \o/
<jcsackett> not that we have time to rearchitect the whole thing right now, but i'd say bye-bye viewlet manager is right up there with bye-bye slots.
<hatch> yeah, the problem that it solves still exists but it needs some work so that there can be nested views
<rick_h__> hatch: yea, it was an interesting idea to managing chunks of UI but bit off a bit more than it can chew at this point. Frameworks and patterns that last are darn hard. 
<hatch> yeah I'm not sure how this is going to work properly without fixing viewlet manager....
<hatch> working on it
<hatch> databinding will just not work for a while :)
<rick_h__> :/ we just can't rip the thing out at this point though. That's a bigger chunk of work and should have more input from devs gone. 
<hatch> oh yeah no definitely can't go
<hatch> it'll be a ton of work to get rid of it
<hatch> I'm hoping we can fix it
<rick_h__> hatch: if it's going to be that bad then put the card back and work on the other ones until Makyo and I get back and we can get together and put more brains at it
<rick_h__> hatch: I think it'll take all our vision on it to be honest. There's got to be a path in there somewhere
<rick_h__> hatch: but we can work on other bits. The destroy stuff, the config changed stuff that should be unblocked at this point right?
<hatch> yeah right now I'm just manually instantiating the new view so that it can keep moving forward
<rick_h__> hatch: ok, trust your judgement of moving forward without getting bogged down for 3 days of work. 
<hatch> the config changed stuff requires the new UI doesn't it?
<hatch> maybe I'm miss remembering
<rick_h__> I don't recall 100%. I thought some of it was moving to the tab in ghost and such
<rick_h__> which the ghost is unblocked a bit now I thought
<hatch> yeah I'll have to take another look
<hatch> atm I'm going to get this new view structure done so that huw can do the styling and markup
<rick_h__> well, all we needed for that was the destroy stuff
<rick_h__> with that he could move forward
<rick_h__> so don't reorg code/structure for Huhw 
<rick_h__> huw
<hatch> I mean the scale-up UI 
<hatch> lots of styling/markup for that
<rick_h__> hatch: right, but the only thing he needs to be unblocked is the destory of non-slot viewlets 
<rick_h__> and then he can go back to cleaning up that markup some more
<hatch> oh I wasn't working on that stuff at all, I'm not really sure the story behind the slot destroy business
<hatch> oh right the change version stuff
<rick_h__> when we moved viewlets to be real views, they could have a destructor and thus .destroy()'d then they're swapped out
<rick_h__> oh sorry, yea bleeding things together
<rick_h__> anyway, back to packing
<kadams54> Makyo: how do I change the border on the blocks? I tried setting the stroke color in stylesheet.less but that doesn't seem to be doing it. Very little experience with SVG in HTMLâ¦
<Makyo> kadams54, is this for the indicator on the block, has a square border around it?
<kadams54> It's the border on the block itself. Mocks show them with a light blue border instead of grey.
<kadams54> Makyo: see http://cl.ly/image/2n3f3S312819
<Makyo> kadams54, oh, we'll need new assets for those, then.  Those are included using img tags.
<kadams54> Ah, OK, thans
<kadams54> thanks even
<Makyo> Well, image, for svg.  So they're not modifiable wihin the doc.
<Makyo> We do something similar with subordinate vs. regular blocks.
<hatch> jujugui can I get a quick review on https://github.com/juju/juju-gui/pull/417 no qa necessary
<huwshimi> Morning
<hatch> morning huwshimi 
<huwshimi> hatch: Hey
<hatch> I have assigned a task for you I was hoping you could get started on today
<hatch> if you have the time that is
<huwshimi> hatch: Let me take a look
<hatch> I assigned you the card in Project 1 which requires https://github.com/juju/juju-gui/pull/417 to land first (test failure is the intermittent one)
<huwshimi_> hatch: So do you just want me to create the HTML/CSS for the four states the view can be in?
<hatch> huwshimi_ yeah so if you could review and land my pr 417 then modify the template/css to match the design 
<huwshimi_> hatch: Well, the template is empty at the moment :)
<hatch> yeah.....heavily modify
<hatch> lol
<hatch> You've got some other stuff in the works I see but I'd like to see if we could 'pair' on this 
<hatch> so at your EOD, leave it in a landable state and create a PR
<hatch> I'll land it in the morning and continue....etc etc
<huwshimi_> hatch: Yeah, I'll take this card now
<hatch> I'm thinking we can probably get this done by my EOD Friday pending any big blockers
<huwshimi_> sure
<hatch> awesome
<hatch> I'm working off of a hotspot today so I'm going to hop offline for a while (used up 2GB today heh) I'll likely be back later
<hatch> have a good one
<rick_h__> huwshimi: I'm out thurs/fri/monday. Cancelled the call tonight, but let me know if you want to chat and we can setup something later
<huwshimi> rick_h__: Yep, no problems. I think I'm all good! Thanks for asking :)
<rick_h__> huwshimi: k
#juju-gui 2014-07-03
<hatch> huwshimi thanks for keeping the landing requests going on that branch to get it landed :)
<huwshimi> hatch: np :)
<hatch> so you're all set for the rest of the day? 
<huwshimi> hatch: Yep!
<hatch> huwshimi https://www.kickstarter.com/projects/1620669801/synek-any-beer-ever-made-fresh-on-your-counter
<huwshimi> Looks great
<rick_h__> hatch: looks like CI's been happy since mayko's change?
<hatch> rick_h__ negative, http://ci.jujugui.org:8080/job/juju-gui-merge/462/ this one failed
<hatch> we
<hatch> er
<hatch> sorry that failed with the noritfications test
<hatch> notifications
<hatch> so yes
<hatch> :)
<rick_h__> hatch: yea, more nervous about the failure to run tests :)
<rick_h__> notifications diaf
<rick_h__> and all that
<huwshimi> rick_h__: Mine have been failing all day :)
<hatch> are you ok with me adding a .skip to that test?
<rick_h__> hatch: actually that's a damn good point
<rick_h__> hatch: I am, we've got a card to fix those tests and ack that we won't get to it until post machine view
<rick_h__> hatch: we all know the damn thing is erronous so +1 on .skip 
<rick_h__> hatch: but please find the bug/card and XXX it in code
<hatch> cool, I'll do that right now once I confirm the failures
<rick_h__> hatch: rgr
<hatch> https://github.com/juju/juju-gui/pull/418 and now we wait to see if the tests pass :)
<hatch> my adapter to hook my xbox controller up to my laptop arrived, works like a charm....
<rick_h__> hah, very cool
<hatch> now the gaming master race can use a controller :)
<hatch> (he says from an underpowered laptop)
<rick_h__> hah
<hatch> oh rick_h__  have you used your document camera yet?
<rick_h__> hatch: yea a few times
<hatch> I'm thinking of getting one myself and there are so many options
<rick_h__> I only used it on a call once
<hatch> any insight?
<rick_h__> oh wtf, this is cool. I have this one but wired http://www.amazon.com/Ipevo-iZiggi-HD-Wireless-Document-CDVW-01IP/dp/B00GUELRK2/ref=sr_1_10?ie=UTF8&qid=1404357237&sr=8-10&keywords=document+camera+ipevo
<rick_h__> didn't know they had a wireless one
<rick_h__> comes with some osx software that works out nice
<rick_h__> linux is a bit more hit/miss
<hatch> bahahaha https://plus.google.com/118445028821328031751/posts/HrqeHHBNkRp
<hatch> are there any tips you have about like quality, functionality, etc
<rick_h__> so the quality is pretty good
<rick_h__> it's not as nice as a scanner or as easy to use as a scanner 
<rick_h__> but scanners only work for full document sheets well
<rick_h__> I've used it to lay out receipts for work next to each other, and send in one jpg of them all 
<rick_h__> and you can't use a scanner as a video camera
<rick_h__> so to record/etc
<rick_h__> I've not used it a ton, but the few times I've used it, seems to work out. It's a bit hard to get it setup to snapshot a full page doc
<rick_h__> but had to do that once with something that had to be signed 
<rick_h__> and saved me a trip to a fax machine
<hatch> and the resolution is ok?
<hatch> http://blog.trello.com/trello-on-your-wrist/
<rick_h__> yea, seems to be. It's a webcam basically
<rick_h__> hatch: yea, saw that. Will have to try that out when it ships
<rick_h__> I use trello for my GSoC stuff on bookie
<hatch> cool thanks
<hatch> ahh yeah
<rick_h__> hatch: I mean I'm not sure if I didn't get as a gift if I'd spend my $$ on it though
<hatch> reviews for the watches are all over the place, some say the samsung has better screen, others say the LG does heh
<rick_h__> hatch: it's not connected sitting on a desk behind me and only connected as needed
<hatch> ahh
<rick_h__> hatch: yea, but everyone agrees the lg has better battery life
<hatch> this is true
<hatch> definitely important
<rick_h__> hatch: and I'll take that, plus the screen issue is that the LG screen isn't as rich, but it works better outdoors
<rick_h__> so samsung has prettier, but sometimes useless screen
<rick_h__> lg isn't as pretty, but more usuable at all times
<hatch> I'm pretty much against samsung anyways 
<rick_h__> then there's that :)
<hatch> so it's really a non-contest haha
<rick_h__> +1 to anti samsung
<hatch> I forgot how crazy java was
<rick_h__> lol
<hatch> com.google.android.clockwork.watchfaces.WatchFaceStyle.Builder
<hatch> like what the h e double hockeystick 
<rick_h__> yea, I really want to do mobile dev work sometimes, but then I see java or obj C and run back away
<hatch> yeah I wanted to dabble with this watch but wow...
<rick_h__> lol
<hatch> Swift is pretty nice though
<hatch> not that that's going to help 
<rick_h__> tell luca we want to do a gui watch app :P
<hatch> haha - I don't think it allows any styling
<hatch> it COULD receive notifications though
<hatch> scale up/down etc
<rick_h__> lol
<hatch> could be pretty cool actually
<rick_h__> ask ant if his mobile charm details is watch mobile
<hatch> "Ok Google, scale up my wordpress service to 5 units"
<hatch> lol
<hatch> I wonder if some of our really smart people on the phone team could flash ubuntu touch onto the watch
<hatch> itty bitty icons
<huwshimi> hatch: OK, now I'm confused. Are you planning to completely replace the UI that exists for the current scaleup or are you just adding some bits and modifying what we have?
<hatch> huwshimi I was going to replace the whole thing - because it now needs to be sharable between the ghost and service inspectors
<hatch> some of the back end code can be sharable I think but the front end stuff is all new
<huwshimi> hatch: Ah great, makes thing easier for me then :)
<hatch> egggggcellent 
<hatch> huwshimi_ ok I'm heading off - so even if you don't get as much done as you'd like by your EOD put it into a landable state so I can land it in the morning and keep going :)
<huwshimi_> hatch: Yep, no problems. Thanks
<hatch> np, thanks, and have a good night
<rogpeppe> urulama, huwshimi: mornin'
<huwshimi> rogpeppe: Morning
<urulama> morning
<urulama> huwshimi: wow, australia ... and i thought i was alone :)
<huwshimi> urulama: Hey! Welcome!
<urulama> huwshimi: tnx
<urulama> huwshimi: good to be here ;)
<huwshimi> urulama: Is this your first week?
<urulama> huwshimi: yes, started on Monday. experienced information overload the first three days, now i plan to play with juju for few days 
<huwshimi> urulama: Yeah, it's all a bit crazy to begin with. It's great that you have a chance to play with it all to start off.
<huwshimi> brb, changing locations
<urulama> huwshimi: rick prepared set of "missions" to get to know the dev cycle and also how juju works, which also made you create different public cloud accounts which will be used anyway ... it's meant for newcomers ... looks nice
<rogpeppe> urulama: cool. i'd like to see the "missions".
<frankban> hi rogpeppe, how is it going?
<rogpeppe> frankban: yo
<rogpeppe> ~
<rogpeppe> !
<rogpeppe> frankban: not bad, thanks
<frankban> :-)
<rogpeppe> frankban: how was your greek island?
<frankban> rogpeppe: it was beautiful, the sea, nice small towns, good food
<rogpeppe> frankban: nice
<frankban> urulama: morning, and welcome!
<rogpeppe> frankban: you up for pairing on finishing up the apiv4 spec?
<frankban> rogpeppe: sounds good, I'll be ready right after a coffee. 
<urulama> frankban: morning
<urulama> frankban: and tnx :)
<rogpeppe> frankban: cool. i'll grab breakfast
<frankban> rogpeppe: I am in https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 no rush
<rick_h__> welcome back frankban 
<frankban> rick_h__: thanks!
<frankban> rick_h__: are you out today?
<rick_h__> greek island? Sounds awesome. 
<frankban> rick_h__: yeah, crete
<rick_h__> frankban: yea, heading up north for family camping over the holiday weekend
<rick_h__> frankban: rogpeppe and hatch can help fill you in on things for the couple of days. I'll be back on tues
<frankban> rick_h__: cool, so no call in 5, right? I am pairing with Roger on the v4 specs, have a great long weekend
<rick_h__> frankban: lots of docs/specs to catch up on and I'm sure your emails are backed up a bit
<rick_h__> frankban: yep, no call. 
<rogpeppe> rick_h__: have a good one
<rick_h__> thanks rogpeppe 
<rick_h__> urulama-away: meet frankban, frankban meet urulama-away, and jrwren is the other new hire. rogpeppe make sure to do the intro on the standup please. 
<urulama> rick_h__: we met in the morning :D
<rick_h__> oh, coolio then
<urulama> rick_h__: italy is close :D
<rick_h__> you morning people :P
<frankban> :-)
<urulama> rick_h__: what about the call tomorrow at 5pm? 
<rick_h__> urulama: I don't see a call on my calendar for 5pm tomorrow?
 * frankban lunches
<rick_h__> urulama: unless tha'ts the friday standup?
<rick_h__> urulama: in that case hatch will run the stand ups while I'm out
<rick_h__> urulama: hopefully with better bandwidth
<urulama> rick_h__: yes, the standups :D
<rick_h__> yea, hatch knows the drill. Just try to keep them short/sweet :)
 * urulama back to the process of killing dying charms
<bac> morning
<bac> hi frankban.  welcome back.  hope you had a good break.
<rogpeppe> frankban: hangout?
<frankban> rogpeppe: sure
<frankban> bac: thanks, I had a great time, how is it going?
<bac> frankban: good.
<hatch> morning all
<hatch> wb frankban 
<bac> urulama: with LXC 0 is actually the host machine.  it cannot be host to other services.  frankban may be able to provide a more coherent answer.
<jrwren> urulama: i just did the same thing :)
<urulama> jrwren: ;) let's see where the limit's are 
<frankban> urulama: quickstart co-locates the GUI on machine 0 only if 1) it's not a local env and 2) machine 0 is trusty or precise. I see a card to avoid co-location also on azure
<urulama> frankban: what happens with local env? isn't it only with "machine 0" on local env?  so how does 1) hold?
<jrwren> is juju-local really an empty package which installs dependencies?
<bac> urulama: i don't understand your question.  if it is a local env then it does not colocate the gui.
<bac> jrwren: yes.  not uncommon.
<jrwren> cool.
<urulama> bac: right, my bad.
<urulama> jrwren: based on questions about Safari ... did you try the "brew install juju --dev"? 
<jrwren> urulama: yes, that is exactly what I was running.
<jrwren> urulama: unfortunately its only 1.19.3, and building trunk is apparently non-trivial
<jrwren> urulama: so I stopped using juju osx for a bit, while I get more familiar
<jrwren> This may be a good time to ask, https://launchpad.net/juju-core/trunk/1.19.3/+download/juju-core_1.19.3.tar.gz  is a tarball which includes dependencies.  Is there such a tarball for 1.19.4 ?
<hatch> jrwren building juju is trivial on Ubuntu :)
<hatch> jrwren https://launchpad.net/juju-core/trunk/1.19.4
<hatch> on there
<jrwren> lets make it trivial other places too :p
<urulama> ^^^
<urulama> well, brew was a nice start tbh
<jrwren> indeed. brew is great.
<hatch> great....well....
<jrwren> not as great as ubuntu.
<hatch> jrwren urulama I'm guessing both of you guys are running on osx?
<urulama> hatch: no, just one of the machines at home
<hatch> ahh - I have to run it as the host os atm - the drivers just aren't quite there yet for this mbp
<urulama> hatch: parallels?
<jrwren> just a bit of OSX, yes.
<urulama> hatch: do you use parallels for running ubuntu?
<hatch> I HAVE Parallels but it's garbage for anything other than Windows, I'm using virtual box/vagrant, but others have had good luck with fusion 
<urulama> hatch: why? you just need to change xorg config file and it works as a charm with 14.04 (pun intended :D)
<hatch> urulama if I'm paying $100 for software I don't want to have to spend more hours making it work :)
<hatch> lol
<urulama> hatch: naaaa, it's only $100 the first year, it's $50 every next year for every upgrade :D :D :D
<hatch> haha ok good point
<hatch> tbh the thing which really irritated me with them was their lack of support
<jrwren> i thought it was $80/$40 :p
<hatch> it amounted to "have you tried turning it off and on again" :P
<hatch> urulama what version of parallels are you running? 
<urulama> hatch: 9
<hatch> I think I'm on 8, which might be the problem....
<hatch> nothing above 12.04 will run on it without display issues 
<urulama> hatch: oh, yes, if you want to run 14.04
<urulama> hatch: even 9 has display issues with 14.04, so if you don't want to change that xorg conf file, don't bother ugrading
<jrwren> 8 on 10.9 is terrible. They really don't support the old version on the newer OSX. They shouldn't claim to. They are wrong to claim ot.
<hatch> I have Ubuntu running on metal on this thing....it just needs a few driver/kernel updates so hopefully those will come soon
<arosales> stokachu: hello
<arosales> rick_h__: re bug 1317109
<_mup_> Bug #1317109: unable to override login password <add-user-story> <cloud-installer> <juju-core:Triaged> <juju-gui:Won't Fix> <https://launchpad.net/bugs/1317109>
<arosales> what is the recommended way to pass the admin password to the web login for juju-gui. I thought it was a charm config, but thought I would ping here.
<jrwren> i'll put ubuntu on this mac... eventually :)
<hatch> arosales hey he is gone until Tuesday
<hatch> arosales is this so you can log in automatically like quickstart does?
<jrwren> urulama: if you like, here is patch for brew juju formula for --devel to be 1.19.4 http://pastebin.ubuntu.com/7742234/
<urulama> jrwren: tnx
<arosales> hatch: correct
<hatch> arosales ok it does it by generating a single use login token 
<hatch> might I ask what the end goal is and I can hopefully provide a solution? 
<stokachu> hatch, with our openstack installer we have the abilty to set a common password for several services
<stokachu> most openstack credentials including horizon dashboard
<stokachu> we offer juju-gui for a visual on th eopenstack installaion but we are unable to set that password to the one defined in our installer
<hatch> right, hmm ok
<arosales> to have the cloud-installer lauch the gui in a similar fashion as quickstart. stokachu may have some addtional input.
<stokachu> does quickstart update the jenv file to a new password after deployment?
<stokachu> i think it reads admin-password
<hatch> so each subsequent loading of the GUI requires the password, the token is single use only....is that ok with you guys or do you want to default the password all the time?
<hatch> stokachu no the login token is entirely separate
<stokachu> preferably a default password that wouldnt change
<stokachu> ah ok
<hatch> but one that's not the admin-secret?
<stokachu> hatch, as long as i could deploy juju-gui with a 'ui-pass' or something so that someone could login that way
<hatch> like, you want to say 'GUI here is your password, log in with this one all the time' 
<stokachu> yea
<hatch> ok atm that's not possible 
<hatch> your best bet is to create a bug report in the gui project so that rick can get it into the queue 
<stokachu> yea it was set to wont fix :(
<hatch> oh really.....interesting
<hatch> have a link?
<hatch> jujugui call in 10 kanban now
<stokachu> https://launchpad.net/bugs/1317109
<_mup_> Bug #1317109: unable to override login password <add-user-story> <cloud-installer> <juju-core:Triaged> <juju-gui:Won't Fix> <https://launchpad.net/bugs/1317109>
<stokachu> im not sure what juju-core will do to help this
<frankban> hatch: so, the password charm option does not work?
<stokachu> frankban, i tried that and it doesn't seem to
<hatch> stokachu well the GUI needs the 'real' admin-secret to send to core to log in
<stokachu> gotcha
<frankban> stokachu: so, that seems to be a charm bug, separated to the one you linked. If the charm exposes an option like that, and warns about the risks, that should definitely work
<frankban> stokachu: trying the charm locally
<arosales> hatch: if stokachu is setting up their environments.yaml he should know or set the admin password and pass that value via the 'password' config option, correct?
<stokachu> frankban, that password could be for the credentials to the websocket on juju?
<hatch> arosales correct
<hatch> arosales but it seems that that option isn't working
<frankban> stokachu: the GUI uses the same password
<hatch> we'll know shortly
<hatch> now that frankban is on it :)
 * arosales agrees with frankban, if that doesn't work its a valid bug
<stokachu> frankban, i set the 'password' config option in my test, is that the one youre using?
<frankban> stokachu: yes, I am trying it now and check if it works with "juju set"
<stokachu> ok
<hatch> thanks frankban 
<hatch> jujugui call in 2
<arosales> stokachu: and frankban and to confirm the value for the password string is the admin password found for the given environment in ~/.juju/environment.yaml, correct?
<hatch> jrwren call 
<jrwren> i must be hitting wrong url
<jrwren> http://tinyurl.com/jujugui ?
<jrwren> yup, wrong url
<hatch> in your calendar there should be a link
<kadams54> Sneaky, isn't it?
<hatch> haha
<hatch> kadams54 I'll pull down your branch but I'm assuming we can 'just deal' with the blue dot for now :)
<hatch> frankban how goes the password field test?
<kadams54> hatch: I also have an e-mail out to Spencer to see if I can get the service block with a blue border asset.
<bac> hey rogpeppe, what's the difference between 'map[string] []Id' and 'map[string] Meta' ?
<hatch> arosales yes the password is the admin-secret in the environments.yaml
<frankban> stokachu: using "juju set juju-gui password=..." worked here: the GUI automatically logs me in
<hatch> ^ arosales 
<bac> rogpeppe: and don't say Id vs Meta :)
<kadams54> hatch: Even though it's not *technically* in scope for this ticket, it seems like having both the blue border and the indicator dot should go together.
<hatch> kadams54 cool, isn't it an svg, so you can just edit the file? Or is it too complex? I've never actually looked into it
<stokachu> frankban, so you set the password, went to the web ui, typed admin/password and it worked?
<rogpeppe> bac: in JSON, one looks like {"foo": ["id1", "id2"]}; the other looks like {"foo": {"name": "a name", etc}}
<kadams54> I talked with Makyo about it last night and he said we'd need a new asset. But I didn't think about modifying the existing SVG directlyâ¦ I'll take a look.
<hatch> stokachu no setting the password to the admin-secret will auto log it in
<rogpeppe> bac: oops, not quite
<hatch> that won't let you set a 'custom' password
<bac> rogpeppe: so the second is a not a list?
<frankban> stokachu: no, I set the password to the real juju one, and then the GUI does not even show the log in form, it just shows you the canvas
<rogpeppe> bac: the second holds a single item for each entry in the map
<rogpeppe> bac: the first holds a list of items for each entry
<stokachu> i see
<bac> rogpeppe: so for expand ids, you want to return a list of expanded ids per requested id or just a one-to-one mapping?
<rogpeppe> bac: the first one will actually look like: {"foo": [{"id": "precise/wordpress-23", "revision": 23, "series": "precise"}, ...}
<rogpeppe> bac: given the name of the path, what do you think? :-)
<rogpeppe> bac: (the former)
<bac> rogpeppe: that's why i'm asking
<rogpeppe> bac: perhaps you could suggest a better way of wording the explanation. i *thought* it was unambiguous, but evidently not
<bac> rogpeppe: can we do a hangout?
<rogpeppe> bac: join us in the standup
<frankban> stokachu: basically the charm generates a config file for the GUI (you can see it going directly to https://<GUI URL>/juju-ui/assets/config.js . By default, the password is null there, with juju set you can re-generate the config to include the password (and that means setting the password like that is very insecure)
<stokachu> juju set juju-gui password=.. the preferred way?
<frankban> stokachu: but that's an option if you really really want to do that. The other (better) possibility is to generate a timed one-shot password as done by quickstart
<stokachu> frankban, the one time password is generated each time the webui is accessed?
<frankban> stokachu: or just use quickstart to open the GUI
<stokachu> does it prompt people to use the login form?
<frankban> stokachu: the one time password can be generated by making an ws API call to the GUI server, the response of which includes a uuid that can in turn be used as a quiry string when accessing the GUI
<stokachu> ok
<frankban> stokachu: if you refresh the GUI, you should be still logged in. If you log out or use another browser, you must generate another one time password
<frankban> stokachu: quickstart does that and works well with already bootstrapped environments
<stokachu> ok thanks
<frankban> stokachu: here is an example of how to create the auth token: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/juju.py#L60
<frankban> stokachu: and it can be used like this: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/manage.py#L556
<stokachu> frankban, ok cool 
<kadams54> hatch: was able to modify the existing SVG. Pushed the updated code to my branch. Now that I see the border + indicator in action, it's pretty noticeable and IMO should be behind the flag.
<hatch> kadams54 ok I'll wait for review then
<frankban> bac: could you join the hangout again?
<kadams54> hatch: all changes pushed; review away.
<arosales> stokachu: also if you are setting up the environment. Suggest you set the ~/.juju/environments.yaml admin password to something like 4testingPlzchange, and then when you deploy the juju-gui deploy the charm with your customer config. Thus you don't have to do a config-set post deploy.
<bac> frankban: sure
<stokachu> arosales, yea for simplicity sake we'll probably do that
<arosales> stokachu: cool
<hatch> w00t I think CI is fixed.....we'll see....we'll see
<hatch> kadams54 ermahgerd that's blue
<hatch> lol
<hatch> is there a mockup I can compare to?
<kadams54> Yeah
<kadams54> hatch: http://cl.ly/image/2n3f3S312819
<hatch> kadams54 ahh ok so we will need new assets then
<kadams54> hatch: eh?
<hatch> the border is much thinner and gradiented 
<hatch> gradient'd 
<hatch> has a gradient
<hatch> yeah that one
<hatch> :)
<hatch> and the little handles are grey still
<kadams54> hatch: I don't think we need any more assets for this card.
<hatch> not this card, send an email and create a follow-up pending the new asset
<hatch> see PR
<hatch> btw - taking a screenshot on a retina then downscaling it makes images HUGE!!!!!!
<hatch> lol
<kadams54> Yes, wellâ¦ talk to our designers. I don't have a retina!
<kadams54> The service blocks have looked slightly different (thinner border, gradient, slightly different shape) on the mocks for some time now.
<kadams54> It also seems like I've seen several variations in different mocks. I just assumed that that was because they were still playing around with different designs.
<hatch> oh that's possible
<jrwren> whoa, i just noticed that jujugui charm uses pip to install things from pypi, have you noticed many cases where pypi fails?
<hatch> jrwren the charm has everything self contained
<hatch> it must work without an internet connection
<jrwren> ah, so its pip installing from the charm?  cool.
<frankban> jrwren: yes, it does not use PyPI. however, it needs to apt install some packages from the ubuntu repositories
<jrwren> saw that. python-pip being one of them
<jcsackett> hatch__: what part of my work is blocking you? state code, or something else?
<hatch__> jcsackett the inspector dispatcher and internal inspector dispatching 
<hatch__> when the user clicks the relation link I need to open the inspector and switch to the relation tab
<hatch> jcsackett but it's ok I have more than enough other stuff to do
<hatch> it's not blocking me, just the card :)
<jcsackett> hatch: ok.
<jrwren> why does the mongodb for localdb use so much space?
<hatch> jrwren hmm I haven't noticed
<hatch> how much are you seeing?
<jrwren> 1G on one host, 6G on another.
<hatch> yikes!
<hatch> definitely worth asking in #juju I've never seen that before
<jrwren> ok
<hatch> since the internet has been down I've found that I burn about 1GB/day of data during work
<hatch> would likely be 2GB but I've cut out my youtube/streaming habit  :)
<hatch> add netflix into there, probably burn through 4GB/day easily
<hatch> ouch
<jcsackett> jujugui: 1st of several reviews, please https://github.com/juju/juju-gui/pull/422
<hatch> heh on it
<jcsackett> hatch: just noticed i didn't lint it.
<jcsackett> i'll ping you in a moment when lint changes go up.
<jrwren> hatch: only 120GB/month, well under comcast's 250GB faux-limit ;]
<hatch> jrwren I'm using our crown corp telco, we don't have no BS "limits"
<hatch> unlimited cell and internet data
<hatch> jcsackett sure np
<jcsackett> hatch: ok, it's updated.
<jcsackett> and i'm grabbing some lunch.
<hatch> yeah I'm also going to do just that
<hatch> I'll review when I get back
<hatch> jcsackett test failure
<hatch> looks like a dependency issue
<jrwren> cs: is charmstore, right?  
<jrwren> i'm trying to repro https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1333159
<_mup_> Bug #1333159: Unable to upgrade juju-gui <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1333159>
<hatch> jrwren it is
<hatch> looking
<jrwren> i deploy cs:trusty/juju-gui-2 no problem, but an upgrade does not seem to use git.
<bac> jrwren: cs: does stand for charmstore but it is protocol for our charm urls
<jrwren> uniter.charm git_deployer says no current staging repo
<jrwren> do I need to do something special to make the unit use a staging repo?
<jrwren> or... i wonder if this is actually a bug in juju which is already fixed.
<bac> jrwren: juju previously used git but now it does not.  if the original filer had mentioned which juju version we'd know.
<jrwren> i'll ask for that info in the bug
<hatch> sorry got distracted, thanks for helping bac
<jcsackett> hatch: well dammit.
<hatch> jcsackett heh yeah you got to run make test-debug test-prod :)
<jcsackett> ...huh. i'm not sure how to debug it if it only occurs on test-prod...because there's no test-prod-server is there?
<hatch> jcsackett you bet there is :)
<hatch> jcsackett there was no service inspector tests?
<hatch> I was sure there was
<jcsackett> hatch "ack service-inspector test" revealed nada.
<jcsackett> so if there are, they're not requiring the module.
<jcsackett> and nothing was named such.
<jcsackett> browser_app does some implicit testing.
<hatch> cra'cra'yo
<hatch> I'll leave you to debugging your dependency issue...they are a pita!
<hatch> but when you do find it, be sure to add it to the module that requires it, not just the test suite :)
<hatch> eventually we'll be able to switch to es6 modules and no longer have these issues
<bac> jujugui: someone *just* told Delta about the hurricane.  i'm going to defer my flight to saturday, meaning i'll work tomorrow and take monday as a swap.
<hatch> bac sure np, better safe
<hatch> where are you going?
<bac> obx
<hatch> ahh 
<jcsackett> bac: i'll hope where you staying isn't hit too bad. :)
<bac> jcsackett: me too!  hope to not spend next week cleaning up.
<kadams54> guihelp: are there docs for the RPC API being used in app/store/env/go.js?
<hatch> kadams54 you mean beyond RTFS?
<hatch> ;)
<kadams54> Hah!
<hatch> kadams54 what kind of questions did you have?
<hatch> frankban knows all the answers but I can do my best :)
<kadams54> Well the remove service/container/machine methods are going to need to invoke API calls
<jcsackett> hatch: i think i've sorted it; bad dependencies in the test, nothing in the modules.
<jcsackett> frankly baffled that test-debug worked, actually.
<hatch> jcsackett well...really we should only need to include a single module in the tests and the rest should be resolved
<jcsackett> hatch: yeah...that's so not true of *so* many tests. :p
<hatch> jcsackett lol I know!
<hatch> which one was missing?
<hatch> kadams54 those aren't already implemented in the backend?
<hatch> kadams54 destroyMachines is there destroy_service
<hatch> is there
<hatch> so everything is implemented already from the environment side of things
<kadams54> I'm working on services right nowâ¦ I didn't see anything in go.js or environment_change_set.jsâ¦
<hatch> both destroyMachines and destroy_service are in go.js
<kadams54> Bahâ¦ I was looking for remove_service
<kadams54> OK, carry on, ignore me
<jcsackett> hatch: when i cribbed from ghost-inspector for inspector module i did a bad copy paste, and pasted ghost-service over regular service.
<hatch> the guy is here fixing the internet....hopefully heh
<hatch> so when he is done we can have a call and I can show you all the stuff
<jcsackett> again: baffled test-debug passed.
<hatch> if you like
<hatch> ohh - I think test-debug passes because there is some leakage on the modules
<hatch> whereas prod doesn't include anything that's not explicitly defined
<jcsackett> that makes sense.
<hatch> we still really need to refactor the damn system
<hatch> heh
<hatch> jcsackett so is it all updated now?
<hatch> the PR i mean
<jcsackett> hatch: i'm rebasing to clean up before you start your review and to kick off another test run.
<jcsackett> b/c i want to see what just failed fail again, b/c i can't make it happen locally.
<hatch> ahh ok cool np
<jcsackett> ...and this is just the service details bit. still not getting to the unit bit.
 * jcsackett does not feel like he's had good luck with cards lately.
<jcsackett> :p
<hatch> jcsackett this is the intermittent test failure
<hatch> the two attempts I made at fixing it apparently were for naught 
 * hatch has sadface
<jcsackett> hatch: i'm very sorry it didn't work.
<jcsackett> i am however thrilled that this ain't my branch. :)
<hatch> haha
<hatch> oh great I get another temporary line running across my backyard
<hatch> those drillers sure made a mess
<jcsackett> hatch: fun times.
<jcsackett> i like, btw, that "above ground power" is an exception for you.
<jcsackett> also, the PR is all up to date.
<hatch> jcsackett lol - well this is like a wired in extension cord, not like coming from a pole :)
<hatch> so it's even one step further down from "from a pole" power :D
<jcsackett> hatch: oooh.
<jcsackett> hatch: that does sound super dodgy. :p
<hatch> yeah apparently they now need to directional drill to my house to run the new lines....
<hatch> someone is gona get one big "oops" bill
<jcsackett> hatch: what are you having done?
<hatch> they are installing fiber into the neighbourhood 
<hatch> so yay for faster internet, sadface for the mess they are making
<hatch> back on land line
<hatch> download-all-the-things!!!
<hatch> kadams54 you had some issues using event simulate and view handlers right?
<jrwren> Alright ya'll, I'm gone until Monday for American holiday. Have a great weekend.
<hatch> jrwren cya, enjoy the holiday
<hatch> kadams54_ you've had issues in the past with simulating events in views right?
<hatch> for some reason I can't simulate an event on a view
<hatch> the callback is never called
<hatch> was hoping you ended up running into this
<kadams54_> hatch: not ringing a bellâ¦
<kadams54_> Well, OK, I remember having problems with a simulate callâ¦ but I can't remember the details.
<kadams54_> Let me ponder it for a moment and it should come back.
<jcsackett> hatch: have you gotten to look at the PR yet?
<hatch> just about to start, I'm at a loss about this problem so a break is needed
<jcsackett> hatch: lemme actually put up a different PR. i've solved the event issue for units, so that's done now too.
<jcsackett> (unless you got into it in the last five minutes, in which case carry on)
<hatch> a new PR or just updating this one?
<jcsackett> hatch: nevermind. go ahead and finish that review and i'll push up the other one after.
<jcsackett> it'll make the second one super easy to read through.
<hatch> ok sounds good
<hatch> jcsackett ok why did you do this to previousInspector
<hatch> so confused
<hatch> heh
<jcsackett> hatch: do what now?
<jcsackett> i left some comments in the PR explaining some of it.
<hatch> you removed var previousInspector = this._activeInspector; 
<hatch> oh, so unsetting the variable for the single case didn't work?
<jcsackett> hatch: nope.
<jcsackett> so we only set previousInspector when we know we want to destroy it.
<hatch> seems flimsy, ok still looking
<jcsackett> hatch: how is it flimsy? whenever we create a new inspector, we store the old one?
<hatch> jcsackett it's just not clear why it's done the way it's done
<jcsackett> the only reason we did it globally before was b/c we *always* deleted the previous inspector.
<hatch> so future us will have to re-investigate
<jcsackett> i mean, i can throw in a comment.
<hatch> yeah I'm still looking to see if there is any alternative
<stokachu> so does the charmstore have an api exposed to pull a revision of a charm?
<hatch> stokachu add -### to the end
<hatch> for the charm version
<hatch> where ### is the versin
<stokachu> what if i just want to find the latest?
<hatch> don't have a -##
<hatch> :)
<stokachu> if i call ServiceDeploy within juju api, it requires a charmUrl
<hatch> https://jujucharms.com/precise/mysql-46/ vs https://jujucharms.com/precise/mysql-43/
<stokachu> which requires cs:series/charm-rev
<hatch> see the `Location:` in the heading of the details pane that opens
<stokachu> so i need to scrape the page and grab that url?
<stokachu> no json data is exposed via the charmstore?
<hatch> stokachu sure, see the net tab in the browser console for the response from the charmstore
<hatch> stokachu here for example https://manage.jujucharms.com/api/3/charm/precise/mysql-43
<stokachu> hatch, perfect just what i was looking for
<stokachu> even has a url field
<stokachu> even better!
<hatch> excellent
<stokachu> thanks :D
<hatch> anytime
<kadams54_> hatch: Sorry, I'm drawing a blank. The callback not firing just doesn't seem right. It seems like my problem was more with the event object and the data being passed to it. That said, I can't remember for sure, so all bets are off.
<hatch> ok I'm going to have to create a repro to see if it's something else
<hatch> thanks
<hatch> jcsackett ok review done, I think there is an existing approach that will fit a little nicer
<hatch> take a look and let me know what you think
<hatch> kadams54_ did you want to chat about the environment stuff? and how it interacts with the ecs?
<hatch> or do you got it
<huwshimi> Morning
<jcsackett> hatch: thanks for the comments. i'll have to attend to these on monday.
<hatch> jcsackett ok np
<hatch> have a good break
<hatch> huwshimi morning
<huwshimi> hatch: Hey
<hatch> huwshimi I unfortunately have run into an issue when writing the tests for my latest changes
<huwshimi> hatch: Oh
<hatch> simulating a click event is not being caught in the view's container
<hatch> and i have no idea why
<huwshimi> hatch: Want me to take a look?
<hatch> sure just a sec I'll push this up
<hatch> huwshimi https://github.com/hatched/juju-gui/tree/hook-up-scaleup
<hatch> do you know how to pull this down?
<hatch> and continue working on it?
<huwshimi> hatch: Yep, all good
<hatch> awesome - ok so the issue is that I simulate a click on the + but the `_toggleScaleUp` method is never triggered
<hatch> it's not even a race, it just never happens
<hatch> if I attach an event listener the event is simulated, but for some reason it's not being caught
<hatch> I'm hoping you have better luck heh
<huwshimi> Let's see :)
<hatch> there are a number of possible ui interactions with the view so doing it via simulate i think is the only way to really get it
<jcsackett> hatch: have a good weekend. :)
<huwshimi> hatch: http://paste.ubuntu.com/7744570/
<huwshimi> hatch: You need to render the view to a container in the DOM for the simulate events to work.
<hatch> ohhhh son of a
<hatch> thanks!
<hatch> lol
<hatch> that kind of makes sense
<hatch> sheesh
<huwshimi> :)
<hatch> thanks so much
<huwshimi> hatch: Just a fresh set of eyes :)
<hatch> ugh man I spent so much time on that
<hatch> yep I guess so
<hatch> or u r just super smart
<hatch> :)
<huwshimi> hatch: Well, I didn't want to brag
<hatch> haha
#juju-gui 2014-07-04
<hatch> huwshimi so do you have enough work for today without any of the scale up stuff?
<huwshimi> hatch: Yep, I think so.
<hatch> awesome
<urulama> huwshimi: morning
<rogpeppe> urulama, huwshimi: hiya
<urulama> rogpeppe: hehe, early bird
<rogpeppe> urulama: :-) happens sometimes
<rogpeppe> urulama: :-) happens sometimes
<huwshimi> rogpeppe, urulama: Morning :)
<urulama> wow, hp helion registration process is, well, could be easier :D
<urulama> morning frankban
<frankban> hi urulama 
<urulama> is it possible to get more info then: "ERROR couldn't read the environment"?
<urulama> been editing env.yaml for hpcloud and now whatever i do, even remove all entries in hpcloud: section still gives me this error
<urulama> found error
<urulama> so, parsing of env.yaml fails if there is an empty line with a tab (\t) at the beginning. this is probably known, right
<rogpeppe> urulama: was there no more descriptive error than "couldn't read the environment". That seems like a bug - it should at least say that it found an illegal character.
<rogpeppe> urulama: ah yes, that does look wrong
<rogpeppe> 	environments, err := environs.ReadEnvirons("")
<rogpeppe> 	if err != nil {
<rogpeppe> 		return errors.New("couldn't read the environment")
<rogpeppe> 	}
<rogpeppe> it should be: return fmt.Errorf("couldn't read the environment: %v", err)
<urulama> rogpeppe: i'll file a bug, it should state that tabs are not allowed and where the error happened (as you've written)
<rogpeppe> urulama: i suggest proposing a fix that does what i suggested
<rogpeppe> urulama: with that change, the error becomes:
<rogpeppe> ERROR couldn't read the environment: cannot parse "/home/rog/.juju/environments.yaml": YAML error: found character that cannot start any token
<rogpeppe> which i think you'll agree is a little better, even if it doesn't mention the line number or actual character that triggered the problem
<urulama> rogpeppe: that's a bit better, agree
<rogpeppe> frankban: you up for continuing on the API spec?
<frankban> rogpeppe: yes, I'll be ready in a few minutes
<frankban> rogpeppe: I am in the hangout
<bac> morning frankban and rogpeppe. i am unexpectedly here today.
<rogpeppe> bac: unexpected welcome, then!
<frankban> bac: morning
<bac> thank you
<bac> frankban: azure change to qs looks good.  i'll do qa now.
<frankban> bac: thanks, if you updated to juju-core 1.20 you will likely find that the new juju breaks quickstart
<bac> frankban: i have not yet, i don't think.  how does it break? is there a card for that?
<bac> frankban: i have 1.18.1.  i can qa with that
<frankban> bac: cool, please QA with 1.18, I'll create a card and look at it later
<bac> frankban: i can look at the card if you like
<frankban> bac: there is a backward incompatible change in the mega-watcher for machines
<frankban> bac: I am going to grab some food now. After your QA, could you please try to dupe the bug using 1.20? You should be able to do that by just trying "juju quickstart" in a local env. You should see a KeyError: u'NetworkScope' while juju is provisioning a machine for the GUI. If you are able to confirm the problem, AFAICT we should involve rbasak because this regression affects the distro quickstart.
<bac> frankban: my first QA attempt with your azure branch has failed.  will try again.  does not look to be related.
<frankban> bac: ok thanks
<urulama> frankban: 1.19.4 has the same NetworkScope error?
<urulama> frankban: with juju-quickstart on local env
<rogpeppe> bac: the API proposal has changed quite a bit since yesterday, if you want to take another look
<bac> rogpeppe: thanks, i will in a bit
<frankban> urulama: did not try juju dev, if you have 1.19 installed you can easily dupe
<frankban> bac: what error are you encountering?
<bac> frankban: second QA worked
<frankban> bac: cool
<bac> frankban: first time there was a timeout trying to ssh to machine 0
<bac> frankban: more likely azure weirdness or my local connection
<frankban> bac: ok, this seems unrelated to quickstart
<frankban> bac: yeah
<bac> yes
<bac> frankban: i marked it qa-ok
<urulama> frankban: i mean, i do get the same error on 1.19.4
<bac> well, i mean to.  i've actually pressed the button now
<frankban> urulama: cool thanks for confirming
<frankban> bac: thanks for the review, merging it. Working on the new card. I am starting to think we should really prioritize quickstart CI with current stable and development versions of juju. This would also help preventing other accidental public API changes like this
<bac> frankban: prob a good idea
<bac> frankban: prevented the change or just given us early warning?
<bac> frankban: i mean was their api change really accidental and we just spotted or was it intentional and we didn't know it was coming?
<frankban> bac: IIRC we consider API v0 to be the one in 1.18. I assume a change to the public API to be accidental. A quickstart test in these cases would not prevent the change to land, but would surely prevent it to be released
<frankban> bac: filed 1337831
<bac> frankban: right
<frankban> bug 1337831
<_mup_> Bug #1337831: Quickstart crashes when used with juju 1.20 <juju-quickstart:In Progress by frankban> <https://launchpad.net/bugs/1337831>
<frankban> rbasak: for when you are available: ^^^
<bac> frankban: are we the only consumers of that API?  i mean, should we fix QS to adapt or will there be larger fallout meaning juju-core should revert?
<frankban> bac: I am quite sure the GUI does not get unit addresses from MachineInfo yet, so it should not be affected. Not sure about other consumers. The problem is that we now have this released. Maybe we should raise the problem with juju devs
<bac> frankban: yeah, i'll bet william would be interested.  curtis too, but he's prob not here today.
<frankban> bac: pinged him in #juju-dev
<rbasak> frankban: thanks. After it happened the first time I'm making sure to test both juju-core and juju-quickstart together before uploading, and this is an MRE requirement for Trusty now, too.
<rbasak> frankban: so I'll make sure that juju-core doesn't hit the archive without juju-quickstart also working with it.
<rbasak> frankban: I guess I need a fix for juju-quickstart first, then, though I don't know that I'll get to doing it today anyway, so no panic for you guys.
<frankban> rbasak: cool thanks, I am working on the quickstart fix right now
<bac> frankban: i can reproduce the bug with 1.20, fwiw
<frankban> bac: thank you
<bac> frankban: should we plan on a qs release today?
<frankban> bac: it would be great, 1.4.1
<bac> frankban: i'll make a card
<frankban> thanks
<rbasak> frankban: I'm interested to know whether the fix will be backwards compatible with older Juju. I'm not sure it matters to be either way, but will probably be useful for me to know.
<frankban> rbasak: it will be backward compatible
<rbasak> Cool!
<frankban> bac: could you please take a look at https://codereview.appspot.com/111860043 ?
<bac> frankban: sure
<frankban> thanks
<frankban> rogpeppe: ready when you are back
<bac> frankban: done
<frankban> bac: thanks
<bac> frankban: if you merge your 1.20 fix i'll do the release
<frankban> bac: merged
<bac> ty
<frankban> rbasak: I merged the fix for bug 1337831. Now we are working to make a new 1.4.1 release
<_mup_> Bug #1337831: Quickstart crashes when used with juju 1.20 <juju-quickstart:Fix Committed by frankban> <https://launchpad.net/bugs/1337831>
<rbasak> frankban: great, thanks!
<hatch> man testing UI interactions is such a pita
<hatch> jujugui call in 10
<hatch> urulama jrwren friday's use a different room than the rest of the week so you'll want to click the link in the calendar for the call today
<hatch> jujugui call in 2
<urulama> hatch: this one? https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<bac> urulama: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<hatch> rogpeppe you coming?
<rogpeppe> frankban: i'm back in the hangout, BTW
<hatch> jujugui https://gist.github.com/087d9e30e3eb92a46657 runWhenCalled
<frankban> rogpeppe: joining
<frankban> hatch: looks good
<hatch> frankban so simple yet solves so many problems!! heh
<frankban> cool
<hatch> frankban I updated the gist with usage
<hatch> hmm I think I have a better update
<frankban> bac: would you like to take another look at the final apiv4 spec before we send it out for discussion?
<bac> hi frankban, just back from lunch.  will look now.
<frankban> bac: thanks
<bac> frankban: i cannot edit nor make comments on that doc
<bac> rogpeppe: ^^
<frankban> bac: it's set to "People at Canonical who have the link can edit"
<frankban> need to go now, have a good weekend all!
<bac> sorry frankban, the card is linked to https://docs.google.com/a/canonical.com/document/d/1wkgLrSZRcpz7zv5Sfc-lh21OZaYui-PhPolpedpWlCI/edit
<bac> but that's the wrong doc
<bac> rogpeppe: is this the correct document for your API proposal? https://docs.google.com/a/canonical.com/document/d/1wkgLrSZRcpz7zv5Sfc-lh21OZaYui-PhPolpedpWlCI/edit
<rogpeppe> bac: here: https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc/edit
<bac> rogpeppe: please fix the link in the kanban card
<rogpeppe> ah
<bac> rogpeppe: is this a typo: GET meta/color?id=djang
<bac> rogpeppe: or are you doing partial match on charm names?
<rogpeppe> bac: typo
<bac> yay
<bac> rogpeppe: fixed
<bac> rogpeppe: is meta/color new?
<rogpeppe> bac: yes
<hatch> oh man this new addition to the test suite is so nice
<hatch> updated the gist https://gist.github.com/hatched/087d9e30e3eb92a46657
<bac> rogpeppe: the doc looks good.  the examples you added are nice and help clarify things.
<rogpeppe> bac: cool, thanks
<hatch> so I need to load the css into the test suite to make these tests work, but that breaks many other tests..hmmm
<hatch> hmm new addition does not scale well
<hatch> need to rethink this
<bac> hey hatch
<hatch> ahoy
<bac> hatch: you have a precise machine available?
<hatch> umm....
<hatch> one sec
<hatch> bac I do
<bac> hatch: could you upgrade juju to 1.20 and see if you can bootstrap a local env?
<hatch> ok firing it up
<hatch> it'll be a bit
<hatch> I'll report back
<hatch> bac 1.17.7 is the highest I can get for some reason
<hatch> you sure they released 1.2 for precise?
<bac> hatch: it may be in ppa:juju/stable
<bac> hatch: but i discovered i'm hitting this bug: https://bugs.launchpad.net/juju-core/+bug/1316174
<_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
<hatch> ahh
<hatch> yeah I see it in the package list
<hatch> but it's not installing it
<hatch> yeah who knows....
<hatch> shall I spend more time on it? We could also spin up an ec2 instance
<hatch> I think that still has precise
<hatch> bac so you ok, or would you like me to keep on it?
<bac> hatch: nm
<hatch> ok sounds good
<hatch> btw I ended up getting the nvidia drivers working on my MBP - now to figure out if I can use them to turn off the discrete card and just use the iris gpu
<bac> hatch: unless you can translate comment #2 from that bug report into something actionable.  i cannot.
<hatch> bac, add more package repositories? :)
<bac> shouldn't the metapackage juju-local do that?  if not wtf does it do?
<hatch> that's what I thought
<hatch> tbh I have no idea how their packaging is set up
<hatch__> The power just went out here and it's going to be a while before it comes back, so have a good weekend everyone
<hatch> yay power
#juju-gui 2014-07-06
<huwshimi> Morning
#juju-gui 2015-06-30
<mhilton> rogpeppe, morning
<rogpeppe> mhilton: hiya
<mhilton> morning uiream
#juju-gui 2016-07-06
<fabrice> 550743
<fabrice> ccccccdlntltehtdlrrntdfgnncthjujkhetlbuvtvtb
#juju-gui 2017-07-03
<dakj> hello everyone! I need support with last release of Juju Gui, I'm deploying Openstack Base and I have to make a configuration on Keystone charm but I don't see the button to save that. Is it maybe changed something?thanks 
<dakj> anyone can help me?
<frankban> dakj: I think this is an instance of https://github.com/juju/juju-gui/issues/3035 ?
<dakj> frankban: thanks a lot I'll try that.
<dakj> frankban: on JAAS it's present, instead on JUJU gui it's not present, I've already done the upgrade with juju upgrade-gui... 
<frankban> dakj: yes, 2.7.4 will be released to juju tomorrow
<frankban> dakj: and it will include a fix
<dakj> frankban: ok, I'll wait tomorrow to upgrade that.....
<dakj> frankban: but via JAAS can I make the modify and deploy it on JUJU?
<frankban> dakj: do you mean on your own controller?
<dakj> frankban: yes
<frankban> dakj: no, JAAS cannot handle your own controllers, you can use the command line until tomorrow
<dakj> frankban: ok, perfect I'll deploy openstack tomorrow!!! thanks a lot for your support and have a nice day
<frankban> dakj: np ty
#juju-gui 2018-07-06
<teste_> teste
