#juju-gui 2013-05-13
<rick_h_> bah humbug for non-idlers
<rick_h_> blog post it is then, probably better that way anyway
<rick_h_> jcsackett: got linky for the reviews you need?
<jcsackett> rick_h_: https://codereview.appspot.com/9337043/
<rick_h_> jcsackett: cool, will look over in a min
<jcsackett> rick_h_: thanks.
 * gary_poster restarts after installing updates...
<gary_poster> hatch, you here today?
<gary_poster> rick_h_, you want to talk today?  May just be us around these parts today. :-)  If you'd like to chat that would be great, but if you want to skip the meeting in 9 that's fine by me too
<rick_h_> gary_poster: stand up in 9? or are you asking about killing it for today due to lack of attendance?
<gary_poster> rick_h_, yes
<gary_poster> the latter
<gary_poster> wdyt?
<hatch> gary_poster: going to use today as swap but I could pick another day if needed
<rick_h_> gary_poster: yea, skipping is cool with me. I don't know if jcsackett had anything he wanted to bring up
<gary_poster> hatch, swap away :-)
<hatch> great - I should be around home most of the day doing yard/house work so I'll check back to see if I'm needed :)
<gary_poster> cool thanks hatch.  have a good one
<hatch> you too
<gary_poster> rick_h_, cool.  happy to meet if jcsackett would like to, but so far we are -0 on the meeting :-)
<rick_h_> gary_poster: rgr, sounds like a plan to me
<gary_poster> cool thanks rick_h_ .  ttyl, & feel free to ping if you'd like.
<rick_h_> gary_poster: actually, do you have time for a quick guichat? 
<gary_poster> sure rick_h_ , joining
<gary_poster> th new google hangout "dropout" animation is...interesting
<gary_poster> m_3, you around today?  I have two questions you might be able to help with.  First, if we wanted to make a fluentd charm, we would need to change some values that require a machine reboot (max # of file descriptors).  Is that possible/supported in a hook?  Second, I'd like to have a charm be able to easily say that it provides an interface in both the global and container scopes (so both regular charms and subordin
<gary_poster> ates can use it).  Do you have to declare the interface twice, one for each scope, or is there a way to combine them?
<rick_h_> gary_poster: so I'm looking and notice that the routing tests use a module juju-routing, but I can't find any code that creates a module in that namespace?
<gary_poster> rick_h_, heh, confirmed
<gary_poster> rick_h_, looks like cruft
<rick_h_> gary_poster: ok cool then
 * rick_h_ digs more. 
<m_3> gary_poster: hey
<m_3> gary_poster: so not sure what to do about a reboot.. some providers can survive it... some can't
<m_3> gary_poster: well... _couldn't_ perhaps lxc is fixed wrt reboots not
<m_3> s/not/now/
<rick_h_> m_3: I heard about that. I think it's fixed or about to be? 
<m_3> rick_h_: the lxc reboot fix that made headlines was containers surviving host reboot
<rick_h_> m_3: ah
<m_3> rick_h_: there was also some probs with container reboots at one point
<m_3> I'd have to test to see which providers that really worked with... rebooting for config is a tough one though... be nice to avoid if at all possible
<m_3> have to test
<m_3> anyways... for relations
<rick_h_> jujugui is there a standard answer to lbox + raring? jcsackett is running in lxc with precise and avoided the issue of lack of lbox.
<m_3> gary_poster: right now you'd need two... one for container scope, one for external
<hazmat> m_3, reboot in lxc won't survive
<m_3> gary_poster: not too bad to stub them and call out to common library code
<m_3> hazmat: ack, thanks
<hazmat> m_3, perhaps fixed in the juju-core version hopefully
<hazmat> rick_h_, what's the issue with lbox + raring?
<m_3> yup
<rick_h_> hazmat: no package in raring. https://launchpad.net/~gophers/+archive/go?field.series_filter=raring
<rick_h_> hazmat: stopped in quantal
<hazmat> rick_h_, go install launchpad.net/lbox
<rick_h_> hazmat: yea, there's a package branch untouched since last year and trunk. Wondered what everyone else was doing/using
<rick_h_> branch is named 'package' 
<hazmat> rick_h_, that's pretty typical for debian packaging.. ie separate packaging from source, and use deb tool/build recipe to merge it in
<hazmat> hm.. although in this case its actually the src.. odd
<hazmat> rick_h_, i've just been using the src compile from go install lbox
<rick_h_> hazmat: k, will look at building go stuff. Not done anything other than local hello world/etc. 
<rick_h_> assume I need some deps and such
<hazmat> rick_h_, just the golang install
<rick_h_> main.go:8:2: import "launchpad.net/goetveld/rietveld": cannot find package
<rick_h_> kind of thing?
<hazmat> rick_h_, hmm.. maybe $ go get launchpad.net/lbox/...
<hazmat> that should fetch deps
<hazmat> rick_h_, its basically got virtualenv/pip built in.. the virtualenv part via GOPATH
<hazmat> env var
<rick_h_> as root? :(
<rick_h_> bah, will look up the docs/etc. It wants to put stuff in /usr/lib/go and such and doesn't feel very venv'y
<hazmat> rick_h_, set GOPATH to a dir you own
<rick_h_> hazmat: yea, seeing that. Thanks
<gary_poster> m_3, cool thank you!
<gary_poster> rick_h_, what is the problem?  works ok for me
<rick_h_> gary_poster: so there's no package any longer in the ppa for raring. I've got it built per hazmat's help. I just saw branches, no ppa, wondered what everyone else was doing
<rick_h_> gary_poster: so all good, custom build off of trunk for now. Will have to keep an eye out for updates down the road. 
<gary_poster> rick_h_, huh.  had not noticed
<rick_h_> jcsackett: review if you get some time please. Apologize in advance. Adding ns.CharmResults required a newline and then re-indenting the whole file afterwards
<rick_h_> jcsackett: https://codereview.appspot.com/9036049
<rick_h_> gary_poster: added a card for friday discussion but I'm away from Wed on. I'm roping JC into representing the cause, but if he's not available can you check if the card makes sense on its own when you get a minute?
<gary_poster> makes sense rick, thanks.  looking at your branch too
<rick_h_> gary_poster: cool, thanks
<jcsackett> rick_h_, gary_poster: i am not available on friday, alas.
<gary_poster> rick_h_, jcsackett maybe we ought to move retrosepctive to following monday anyway
<gary_poster> some other people will be out
<gary_poster> too
<jcsackett> gary_poster: i'm gone on the monday as well. :-/
<gary_poster> heh
<gary_poster> this crazy weekend vacation stuff!
<gary_poster> :-)
#juju-gui 2013-05-14
<rick_h_> bah, reitveld doesn't want to load for me today. 
<rick_h_> there it goes, just needed to warm up today I guess
<gary_poster> jujugui, we have a GUI UDS session that we need to lead/attend on Thursday, 18:05-19:00 UTC.  We ought to also attend, at least partially, the "Juju Charm Testing" session (Thursday 15:05-16:00 UTC), the "Charm Development Tooling" session (Wednesday 18:05-19:00 UTC), the "Charm Policy Review" session (Wednesday 15:05-16:00), and the "Juju Core Development" session (today 19:05-20:00 UTC).  I'll put those in an emai
<gary_poster> l now...
<benji> gary_poster: I wonder if we should promulgate the "Elmo's Pain" blog post to one of the lists.  Maybe at least him. :)
<bac> morning
<benji> morning, bac; I trust your return trip was OK
<bac> it was a-ok.  best as could possibly be for having to catch a cab at 4:45
<gary_poster> benji, yeah, the thought crossed my mind as well. :-) I was also considering advertising the blog more generally.  I'll do it soon, though I have higher priorities atm so if someone wants to do some of those that would be cool too.  oh, that reminds me.
<gary_poster> I think we have two very high priority bugs atm
<gary_poster> one is the memory leak
<gary_poster> the other is the problem when we update the demo site and we can't see it  anymore until we clear out our appcache
<bac> gary_poster: i got feed back from some of our spikey haired colleagues that the blog is interesting but they won't read it since it seems to be an internal gripe/work-around collection.  food for thought.
<gary_poster> bac, which spikey haired ones?
<gary_poster> for example, perhaps :-)
<bac> ok, it was just one.
<bac> his initials are curtis hovey
<gary_poster> heh
<gary_poster> ok cool
<rick_h_> lol
<rick_h_> gary_poster: bac I could see though getting a tag or category into one of the planets perhaps? Maybe a "this is share-worthy state of GUI" for those that don't care how the sausage is made.
<gary_poster> rick_h_, yeah good idea.  do any of the planets still have decent readership? I was under the impression that they were losing steam
<rick_h_> gary_poster: hmm, I'm an rss junkie so not a good person to ask
<gary_poster> heh
<rick_h_> jcastro might have a good suggestion
<gary_poster> good idea thanks
<rogpeppe1> gary_poster: hiya
<gary_poster> hey rogpeppe1 :-)
<rogpeppe1> gary_poster: i've just done a pretty major refactoring of the rpc package. it all seems to be working ok, but i wonder if you could check that the branch works with your stuff.
<rogpeppe1> gary_poster: the branch is here: lp:~rogpeppe/juju-core/300-rpc-refactor
<gary_poster> cool, rogpeppe1, sounds good.  I'll get someone to give it a whirl.  bac, you up for that?
<rogpeppe1> gary_poster: i'm quite happy with it - i think it's got rid of a few lurking bugs and added some cool new possibilities
<rogpeppe1> gary_poster: in particular, rpc can now be bi-directional
<bac> gary_poster: sure
<bac> rogpeppe1: thanks!
<gary_poster> thanks bac
<gary_poster> rogpeppe1, so you mean Juju can now initiate a conversation?
<gary_poster> as opposed to only responding?
<rogpeppe1> gary_poster: yes
<gary_poster> ah cool rogpeppe1, that is potentially a big deal
<rogpeppe1> gary_poster: yeah, i think so
<gary_poster> great
<gary_poster> I will keep that in mind in my thoughts going forward
<gary_poster> di you have any immediate ideas on how to apply that?
<rogpeppe1> gary_poster: i was thinking in particular of cross-environment relations, but i'm sure there are other places where it could be useful
<gary_poster> ah, of course
<rogpeppe1> gary_poster: there's no requirement that both sides speak the same API of course
<gary_poster> sure
<benji> log streaming
<rogpeppe1> benji: i'm not sure about that actually
<gary_poster> benji, watchers would work with that, but...yeah
<rogpeppe1> benji: i think for genuine streams, it might be better to just use a normal non-websocket URL
<gary_poster> rogpeppe1, benji, actually I was thinking that we might be able to use the statsd pattern for logs too.  I want to talk to mew about standards
<benji> rogpeppe1: yep, you're probably right
<gary_poster> I mean, it would be a relation interface, as rogpeppe1 suggested at the relevant meeting
<rogpeppe1> gary_poster: interface or not, the GUI still has to get access somehow
<gary_poster> rogpeppe1, yes, but there are lots of log aggregator tools out there now
<gary_poster> if we speak the right language, we can play the game
<rogpeppe1> gary_poster: ah, that sounds good
<rogpeppe1> gary_poster: BTW did you see that go 1.1 is out now?
<gary_poster> rsyslog is maybe the most basic.
<gary_poster> I did, rogpeppe1!  I intend to look at the new features.  Does that affect the project immediately, or will we havet owait for 13.10?
<rogpeppe1> gary_poster: i think we'll move over immediately
<gary_poster> cool
<rogpeppe1> gary_poster: there's not much that impacts us directly.
<rogpeppe1> gary_poster: i can lose a few hacky bits
<gary_poster> rogpeppe1, actually I had a thought for the statsd story that I was going to talk to you about.  we want a "statsd" interface that can operate in both a container scope and a global scope.  Specifically, the container scope is good for Landscape and for "adapter" subordinates (statsd -> XXXNEW_PROTOCOL); the global scope is good for gui and statsd servers and graphs (graphite).  We can simply require that users spec
<gary_poster> ify the interface twice, once for each scope, but I thought it would be good to record this use case so we can contemplate addressing it at some point.  Would you suggest simply filing a bug?  Or do you think I'm missing something in my evaluation of the situation?
<gary_poster> "addressing it at some point": making it possible to declare an interface once, applying to both scopes
<rogpeppe1> gary_poster: won't adapter subs have only the global interface?
<rogpeppe1> gary_poster: i.e. aren't adapters just about adapting from something local to the global stats relation?
<hazmat> gary_poster, the uistage.jujucharms.com is getting yanked...
<hazmat> gary_poster, hp is charging for instances
<gary_poster> rogpeppe1, well, that's a question.  so if the scenario is that we have charm A that provides a statsd interface and charmB that requires a NEWSTATS interface, and it is possible to translate statsd to NEWSTATS relatively trivially and automatically, what do you do?  I envisioned that you would want subordinate charmC on charmA that would translate statsd to NEWSTATS, and then you would relate charmB to charmC.  The
<gary_poster>  advantages AFAICT are that you add incremental load to the adapter charm that scales out naturally
<gary_poster> hazmat, hm.  the biggest problem here is juju.ubuntu.com, I think.
<rogpeppe1> gary_poster: could you explain that a bit?
<gary_poster> rogpeppe1, sorry, yes, wanted to reply to hazmat, 1 sec
<rogpeppe1> gary_poster: np
<gary_poster> hazmat, this is probably a discussion for sinzui and maybe alejandraobregon 
<hazmat> gary_poster, why are stats relayed through juju?
<hazmat> gary_poster, i thought heka + new websocket for stats
<hazmat> as statds
<gary_poster> hazmat, one thing at a time :-P I'll return to that conv. in a sec .  For now, can we prolong uistage until sinzui and alejandraobregon unveil the new jujucharms.com?
<sinzui> gary_poster, hazmat, noted. I think we will plan a new instance
<gary_poster> sinzui, hazmat, I suggest that you coordinate timing so there is not a link to nowhere from juju.ubuntu.com, but will step aside otherwise.
<hazmat> gary_poster, sinzui based on converations the deploy/reveal of that may get delayed even after tech is done.
<hazmat> so best to fix up current links
<gary_poster> hazmat, I heard the same, yes
<sinzui> that's right. I understand they want to rethink the site's initial exerpience
<hazmat> gary_poster do you have a staging site for the gui around?
<hazmat> er. trunk testing
<gary_poster> hazmat no, will arrange soon, and does not need to block you
<gary_poster> public facing bit is the only thing I think we need to coordinate
<gary_poster> Back to virst conv., rogpeppe1 and hazmat.  stats not relayed through juju, that's not what I'm talking about hazmat.  statsd talks directly to consumer, whoever they are.  The question is about future-proofing generally, since this is a topic that GUI, Landscape, and Core (at least themue had a related session) care about.  when statsd becomes old news and XXXNEWTHING is new approach, what do we do?  two approaches
<gary_poster> .  one is that everyone learns how to talk the new format and the old format.  that's fine.  but I was raising an interesting use case (that is practically important for Landscape only atm) of adapter charms.
<gary_poster> well, I was saying that adapter charms might be a way to approach the problem
<gary_poster> and I was thinking that they might work best as subordinates
<rogpeppe1> gary_poster: are you thinking that stats are shown in the GUI?
<gary_poster> and landscape is a subordinate now, and how they want to consume the metrics is from the perspective of a subordinate
<sinzui> Someone is making staging.jujucharms.com (manage) very angry. I an getting volleys of hate mail
<rick_h_> sinzui: that's me
<rick_h_> sinzui: looks like the interesting api call is blowing up on something new. 
<rick_h_> sinzui: was just trying to do a final QA on my branch which hits it
<sinzui> Shall I forward you all the hate, or are you content just knowing it cannot talk
<rogpeppe1> gary_poster: a subordinate can still have global relations
<rick_h_> sinzui: well, depends on the hate. If it's something I can help fix today before EOD sure. Else someone else might want to grab it. 
<gary_poster> rogpeppe1, metrics only for a single unit.  our use case is diagnosis.  metrics for aggregates are for dedicated solutions, like statsd + graphite connecting to one or more services
<gary_poster> eh, lines are being crossed, I'm afraid
<gary_poster> rogpeppe1, yeah, I know.
<gary_poster> rogpeppe1, quick call in the hopes that it straightens things out faster than otherwise?
<rogpeppe1> gary_poster: good idea
<gary_poster> rogpeppe1, https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a
<sinzui> rick_h_, this is the bug: https://bugs.launchpad.net/charmworld/+bug/1179942
<_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 <api> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1179942>
<hatch> morning all
<gary_poster> rogpeppe1, just lost you :-/
<gary_poster> morning hatch
<hatch> can I watch a youtube stream of the vUDS talks?
<gary_poster> hatch I don't think it is a stream. I think you have to go to each talk.  maybe wrong
<rogpeppe1> gary_poster: network difficulties, sorry
<gary_poster> np rogpeppe1 still in hangout if you would like to rejoin
<rogpeppe1> gary_poster: trying  but it doesn't seem to like me currently
<gary_poster> :-)
<jcsackett> rick_h_: do you know if we have bugs filed for all of our remaining UX commitments? or is that still in progress while the designs are completed?
<rick_h_> jcsackett: right, we asked luca to file bugs with the assets/etc attached in chunks that made sense.
<rick_h_> jcsackett: describing to him how we thought of things as 'widgets' or components that fit together
<abentley> rick_h_: which staging is broken?
<rogpeppe2> gary_poster: connection coming and going but hangouts still not there
<rick_h_> abentley: bug sinzui just posted: https://bugs.launchpad.net/charmworld/+bug/1179942
<_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 <api> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1179942>
<rick_h_> abentley: breaks anything hitting ES I think atm
<abentley> rick_h_: Gotcha.
<abentley> sinzui: It sounds like you've been looking at staging.  This looks like the same ES fail I've seen a couple of times.
<gary_poster> rogpeppe2, ok thanks for trying.  the main point we were discussing was whether setunit can coexist peacefully with addunit and removeunit.  I think they can, and they ought to.  I'd say that the underlying change is that juju needs to maintain a "goal number" of desired units, and have agents moving the actual number of units to meet that desire.  setunit directly changes that goal value.  addunit and removeunit tr
<gary_poster> ansactionally (that is, within a single transaction) get the current goal value, modify it, and set it.  setunit is a better concurrent approach generally, but removeunit and addunit will still work fine technically in the new world.  existing tests relying on addunit and removeunit should be fine.  what do you think?
<abentley> sinzui: You can see in the charm.log that ES failed to start when restarted. (/var/lib/juju/units/elasticsearch-0/charm.log at 2013-05-14 07:06:19,759)
<hatch> hey there is a new version of go released
<gary_poster> yeah go devs switching soon according to Roger
<gary_poster> I mean juju devs
<rick_h_> yea, says it's backwards compat 
<rick_h_> go Go :)
<rick_h_> when ever I see Go releases I realize how spoiled I am by the Python stdlib
<abentley> sinzui: I'm restoring staging.
<hatch> I was just surprised to see a go release
<hatch> over a year since their last one
<hatch> :)
<gary_poster> hey Makyo you around?
<hatch> well...with the exception of bug fix ones
<Makyo> gary_poster, Yep, though net's a little flaky.
<hatch> darn, so it wasn't the router?
<Makyo> hatch, apparently not.  Which is good in a way, I guess :)
<Makyo> I'll swap later.
<gary_poster> Makyo, ack.  I'm worried about that appcache problem we see on tinyurl.com/jujucharms (https://ec2-23-20-230-72.compute-1.amazonaws.com/).  I'm afraid it is going to affect jujucharms.com and we are going to be very unhappy.  Could you investigate, or maybe hand off some of your knowledge about this to someone else (hatch?)
<hatch> is this the no css issue?
<Makyo> gary_poster, Sure, either or.  I think the end result will be appcache just going away.
<Makyo> It's no resources, hatch , not just css.
<gary_poster> Makyo, no appcache will make us sad, yeah?
<abentley> rick_h_: staging is back.
<Makyo> gary_poster, the only things in there are the service blocks, which are going away, correct?
<rick_h_> abentley: cool thanks
<Makyo> And index.html
<benji> grrrr, chrome crashed while attempting a heap capture
<hatch> :/ tests passed when they should have failed
<gary_poster> Makyo, hmm, good point.  how big are the service blocks right now?
<Makyo> gary_poster, 25K
<Makyo> For all assets.
<gary_poster> Makyo, wow, yeah, let's dump it, unless you disagree.  If you agree, do you have time for that (it involves a bit of Makrfile jiggery) or would you prefer I find someone else so you can focus on the Go branches
<Makyo> gary_poster, I'll do it, should be quick.  I think it's just too clumsy for our needs.  All or nothing, too hard to clear, no way to not include index.html, etc.
<gary_poster> ok thanks much Makyo 
<Makyo> gary_poster, np.  Landing service placement, then that, then proposing branch 2/3 of the go stuff.
<gary_poster> cool, sounds good
<rick_h_> hatch: did you fix/find the issue with that CI issue of 'cannot find image'?
<gary_poster> if it's from two weeks ago, yes.  /me hopes ther's not a new one
<rick_h_> hatch: sorry "Can not find requested image" failure to be more exact
<rick_h_> gary_poster: my branch landing just tossed it out with that failure :/
<gary_poster> :-( :-(
<hatch> rick_h_: I don't follow...was it someone else maybe?
<rick_h_> hatch: I thought you were looking at the CI failure with the image ids/names not looking right?
<gary_poster> hatch, no, he's talking about the fix where you set the new openstack image
<rick_h_> hatch: my bad if I'm remembering incorrectly
<hatch> ohh yeah no I have no idea about that - it wasn't me - I am trying to find where the login username is being changed to 'admin'
<rick_h_> I didn't catch what the final fix was for that
<gary_poster> hatch, /me worries you were taken over by aliens...or /me was!
<rick_h_> lol
<rick_h_> ubuflu turns into ubuabduction
<gary_poster> heh
<hatch> lol
<hatch> there was a massive storm last night so maybe they came in under the cover of thunder
<arosales> fyi lower third info for G+ hangouts for vUDS or in general http://paste.ubuntu.com/5598305/
<arosales> gary_poster, were you just going to review the s-cloud-* BPs @ https://blueprints.launchpad.net/juju-gui
<gary_poster> cool thanks arosales 
<arosales> for vUDS guid development sessions tomorrow
<arosales> s/guid/gui/
<gary_poster> arosales, I was going to extract public facing bits from https://docs.google.com/a/canonical.com/document/d/12NlmaoSJswYe2H1u9Z0pjAhrBtqdtN_h76n5rfj05JA/edit# and discuss
<gary_poster> Thursday, not tomorrow, thanks to you :-)
<arosales> gary_poster, ah yes :-) 
 * arosales needs more coffee :-)
<gary_poster> :-)
<arosales> gary_poster, sounds good, thanks.
<gary_poster> cool, thanks
<arosales> gary_poster, let me know if you have any questions
<gary_poster> thanks arosales, will do
<sinzui> rick_h_, abentley, jcsackett, I think someone tested search with asdf and got an error, this is it: https://bugs.launchpad.net/charmworld/+bug/1179970
<_mup_> Bug #1179970: KeyError: 'Docs' <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1179970>
<rick_h_> sinzui: ack
<abentley> sinzui: Yes, I did.  Not sure what happened there, because that was after I'd run 'juju resolved --retry elasticsearch/0'.  It should have succeeded, and later attemtps did succeed.
<bac> rogpeppe2: i've exercised the GUI using your RPC branch and don't see any issues.
<rogpeppe2> bac: thanks a lot
<rogpeppe2> bac: that's good :-)
<hatch> somehow I wrote that whole login/logout route rewrite and didn't get a single indentation lint error....either I'm getting better at this stuff or something is seriously wrong :)
<hatch> jujugui Looking for a review and a qa on https://codereview.appspot.com/9415043/ a QA needs to be done using all three back ends please :)
<teknico> hatch, conflict in lp diff: https://code.launchpad.net/~hatch/juju-gui/auth-routes/+merge/163732
<hatch> ahh crap
<hatch> ok ignore that email
<hatch> thanks for pointing that out teknico :)
<teknico> hatch: quick hangout once you're done reproposing?
<hatch> yeah I just want to make sure everything works after fixing that
<hatch> annnd it doesnt
<teknico> :-)
<hatch> *expletive*
<gary_poster> hatch, after talking with teknico, ping me to talk about CI plz.  I'm pretty sure you know more than you are letting on about how to fix that CI failure.  Or one or both of us are aliens.
<hatch> ok we can chat now
<gary_poster> teknico,  gets to go first
<hatch> sec while I grab my headset
<teknico> hatch: https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7
<hatch> ok there
<abentley> rick_h_: Technically, you won't need has_icon, because icon.svg would be listed in "files", but I'm happy to include it as a convenience.
<hatch> gary_poster: ok guichat?
<gary_poster> ok hatch 
<gary_poster> hey bac, you have a sec?
<bac> gary_poster: sure
<gary_poster> thanks bac, guichat?
<bac> yep
<gary_poster> jujugui kanban now, call in 7
<rick_h_> abentley: ah true. cool
<teknico> Makyo: is your "Refactor RepoSuite to juju/testing" card reviewable? it links neither to Rietveld nor to LP
<Makyo> teknico, yes, sorry. Card confusion with splitting branches.
<Makyo> teknico, https://codereview.appspot.com/9074045/
<teknico> Makyo: gotcha
<hatch> rick_h_: are you around today?
<rick_h_> hatch: yea, what's up?
<hatch> in fixing my tests I have somehow broken a charm browser test suite and I am at a total loss as to wtf is going on - any chance you could take a look?
<rick_h_> hatch: sure, linky the branch in progress
<hatch> https://code.launchpad.net/~hatch/juju-gui/auth-routes
<hatch> thanks
<rick_h_> hatch: k, pulling down. Give me a few 
<hatch> rick_h_: you should see aftereach failing in browser_charm_view right after "qa content is loaded when tab is clicked on"
<hatch> and commenting that test out causes a number of tests to fail much later in the full suite....so I'm totally lost haha
<rick_h_> hatch: in app.js so both routes login/logout should be there? solving merge conflict...
<hatch> ohh I haven't merged with trunk yet
<hatch> I didn't want to introduce more issues yet :)
<hatch> only login route should be there
<rick_h_> hatch: so no logout route
<hatch> nope
<rick_h_> k
<rick_h_> hey, who's leaving the slider assets around the test suite :P
<hatch> yeah I noticed that too - I was going to look into fixing that after I got this branch landed
<rick_h_> hatch: guichat?
<hatch> yup
 * rick_h_ yells "not me!" and runs away from failing test
<hatch> lol
<hatch> thanks for looking :)
<bac> hi hatch, quick chat?
<bac> hatch: you got a sec?
<hatch> sure whats up?
<rick_h_> hatch: this Go login thing isn't intermittent. I've gotten it 10 straight times. 
<hatch> rick_h_, it depends on the speed it runs it with
<hatch> it's ok I know what that issue is ;)
<rick_h_> hatch: ok, just trying to poke at this some more. Depending on what I comment out I get all kinds of diff errors
<hatch> yeah something is right messed up with these tests
<bcsaller> updated card on "export UI" with a review branch when people have time
<hatch> rick_h_, I think I solved it
<rick_h_> hatch: orly?
<rick_h_> hatch: legit issue or just the test suite hating us?
<hatch> I think it was an issue with how the tests were written combined with the long instantiation procedure for app
<hatch> might have to put some thought into restructuring app
<rick_h_> hatch: well I'm all for restructing the test suite :P If app passes the tests then so be it imo. 
<hatch> well I was thinking about breaking the app instantiation into a number of extensions which we can turn on/off for testing
<hatch> that's my 5s worth of thought on the matter
<hatch> :)
<rick_h_> hatch: but you still need tests with it all turned on. 
<rick_h_> hatch: so if that'll fail then at least let's make sure we know that's what failed vs something 100 tests later
<hatch> thats kind of my thoughts - I am also working with a migraine so I'm sure there are also some other issues associated with it that I'm missing :)
<rick_h_> hatch: I guess at some point I just wonder if we're fixing the symptoms vs the real problem. If the code's not broken the tests need fixing not the code. 
<rick_h_> hatch: ah, well go take some meds for that. hate those evil things
<hatch> true but there is something to be said about 'testable code' 
<hatch> so it could be that the app is becoming to large to instantiate 
<hatch> for tests
<rick_h_> hatch: k, well if you found something all good and I'm all for making app easier to maintain/etc. I just don't want to add complexity by flagging app features purely because the test suite hates us. 
<rick_h_> not that it's my decision or anything, but my input since I heard someone ask me on the wind over here in my coffee shop :P
<hatch> haha so true so true - well once I finish modifying the tests if it works then we can look at it in more detail
<hatch> it's windy IN the coffee shop?
<hatch> ;)
<rick_h_> hatch: or maybe it was just the voices in my head. I can never tell
<hatch> haha
<gary_poster> I wonder when the service page got too big and required scrolling :-/
<gary_poster> sometimes
<gary_poster> mm all the time
<gary_poster> but sometimes it works for the first few seconds
<hatch> gary_poster, I thought we were ignoring that because of the new UX?
<gary_poster> not my intent
<hatch> oh ok sorry :)
<hatch> we got a new radio station, all 80's and 90's hits
<hatch> w000t
<gary_poster> hey bcsaller I'm trying out your export branch.  shift d works great.  I can't get what I believe be the help key to work (shift /, or simply "?" AFAICT).  From your branch it looks like I should be able to drag the environment name at the top of the page but that is not working for me.  Finally and most trivially, the "esc" callback throws errors when #shortcut-help is not around.  Can you correct me to the proper 
<gary_poster> help key and the proper drag mechanism?
<gary_poster> that was some strange English
<gary_poster> ...what I believe to be...
<gary_poster> ...Can you correct my understanding of the help key and the drag mechanism?
<bcsaller> gary_poster: Shift-/ or '?' works for me on that branch, odd. I also don't see an error pressing escape as shortcut help is always there (just not visible)
<gary_poster> huh
<gary_poster> I'll reload page after clearing appcache
<bcsaller> the word 'Environment' is the drag target (but I didn't change the cursor on hover as I don't think we should promote this feature yet)
<bcsaller> gary_poster: when you start the drag however it does change
<gary_poster> bcsaller, duh, looks like I just needed to clear appcache.  sorry for false alarm
 * bcsaller shakes his fist at appcache one final time
<gary_poster> :-)
<gary_poster> bcsaller, shift d works great, but if I export a larger environment (like http://ubuntuone.com/3dl0I8k9YsG52dvmzFdiOH) with drag-drop I get an error ("Error opening file '/home/gary/Desktop/{"meta":{"exportFormat":1},"services":[{"displayName":"cassandra","name":"cassandra","charm":"cs:precise/cassandra-3","config".txt': No such file or directory")
<gary_poster> it looks like the name is the content when you drag-drop?
<bcsaller> gary_poster: it shouldn't be, maybe I botched the merge, my quick testing seemed to work before, checking now
<gary_poster> bcsaller, fwiw I merged your branch into trunk for review.  Maybe that's the problem
<gary_poster> no conflicts though
<bcsaller> I did that this morning as well before the CR push
<bcsaller> gary_poster: there are two import paths, the file reader one which is the drag from file manager to browser case, the other is from the clipboard. The clipboard case will put the JSON (if it fits) in the clipboard
<bcsaller> AFAIK it can't set a filename associated with that clip though
<bcsaller> so nautilus sees the drag and tries to name the file its contents
<gary_poster> ack, on call back soon
<bcsaller> however dragging to another gui instance is fine as it tries to import that data directly
<bcsaller> ok
<Makyo> my cobzr setup got corrupted :|
<bac> Makyo: kill cobzr
 * Makyo gets out the knife :/
<bac> Makyo: seriously, did you read tim's suggestions in juju-core/docs/bazaar* ?
<hatch> rick_h_, yeah looks like I found a good workaround 
<hatch> it was because of multiple app instantiations with such a long init cycle
<Makyo> bac, re: switching to pipelines?
<bac> Makyo: you don't have to go all the way to pipelines but just use a sane set up for lightweight checkouts that allows you to get rid of cobzr
<Makyo> Something just fell off the roof.  Back in a sec.
<Makyo> Oh well.
<sinzui> I see m.jc.com just through a wobbly when someone was looking at the juju-gui charm
<Makyo> I'll read up on it, bac.
 * sinzui reports bug
<rick_h_> hatch: cool
<hatch> of course I am trying to solve some edge cases now
<rick_h_> bcsaller: you guys have a running GUI charm on prodstack right? It's just a raw IP port right now?
<bcsaller> rick_h_: I'm not sure the status of that 
<rick_h_> bcsaller: asking because abentley noticed that the charm installs apache, but prodstack rules say you must go through the apache charm from them and curious if there's a branch/etc to look at for the latest/greatest
<bcsaller> hmm, afaik they accepted what we delivered 
<bcsaller> there was no additional work to support a remote apache. Currently the server is static files though so they might have let it in because of that 
<rick_h_> bcsaller: ok cool. 
<hatch> rick_h_, still around?
<rick_h_> hatch: what's up?
<hatch> wondering if you could pull down the latest version of my auth branch and see if that Go error pops up
<rick_h_> hatch: k, sec
<hatch> thanks
<rick_h_> hatch: all tests pass
<hatch> righteous 
<rick_h_> hatch: just testing something else out quick, sec
<rick_h_> hatch: so if I comment out the test_app (which I was doing to help debug the test issue) it happens every time
<hatch> ok let me try that
<hatch> darn I still can't repro
<hatch> are you on your desktop?
<rick_h_> hatch: laptop
<rick_h_> desktop arrives tomorrow
<rick_h_> hatch: sec, let me breakpoint there and peek
<gary_poster> I attended Juju vUDS session.  Took some notes from GUI perspective, fwiw: http://pad.ubuntu.com/uds-1305-juju-core-development
<gary_poster> big take away: we need even more of a machine perspective than I thought
<hatch> rick_h_, ok I was able to reproduce it once - I was asking about the desktop because maybe it was a speed issue - looking into the test now
<rick_h_> hatch: yea, understand. 
<gary_poster> rick_h_, bcsaller yes they accepted the apache because GUI needs to be behind haproxy to merge websocket (juju) and normal web resources (apache).  If we were a subordinate, we would still need our own apache, or something like that.
<gary_poster> not sure if we could have our own apache within another apache. don't see how that would work
<hatch> gary_poster, mongo works better in HA with odd numbers? lol 
<hatch> have to admit that's pretty funny :)
<bcsaller> hatch: https://speakerdeck.com/mitsuhiko/a-year-of-mongodb ;)
<gary_poster> hatch, :-P :-)
<rick_h_> hatch: hmm, so they 'look' the same to me 
<rick_h_> hatch: just the order is diff from what I can tell
<rick_h_> hatch: maybe the test can just compare multiple properties expected to match instead of the deepequal?
<hatch> rick_h_, no the deep eql is necessary - the issue is a race condition...now I need to figure out how to fix that
<hatch> that guys slides are wrong.....mongo doesn't use JSON records :P
<hatch> I will read more after I fix this test
<rick_h_> hatch: http://paste.mitechie.com/show/959/
<rick_h_> mongodb needs 3 so you can always vote for a new master. Also you usually want sharding, and 3 of each shard...so enjoy the number of machines 
<hatch> ohh that's why it needs 3...I guess that makes sense
<rick_h_> yea, you want to have a vote to promote else some out of date second can just become master and oh well to any data that didn't get there yet
<rick_h_> hatch: so yea, I don't know. When I debugger into that test and check each property I'm golden. Then again if it's a race the delay in getting at the object must be cool and fix it
<hatch> yeah - I know how to fix it....just trying to figure out how without rewriting all of the tests
<hatch> :)
<rick_h_> hatch: ok, then I can quit poking at this and EOD
<rick_h_> have fun :)
<hatch> thanks for your help
<rick_h_> hatch: heh, happy to just yell "it's broke" :)
<hatch> oo new radio station is playing Oasis
<hatch> fixed....but yuck
<rick_h_> hatch: what was that? I stopped reading at 'fixed' :P
<hatch> https://gist.github.com/hatched/3ec63ac042ad698c6ea6
<hatch> ln 2 to 11
<hatch> feel free to try that in your branch :)
<rick_h_> hatch: now turn that into a method resetGoEnv() and it's pretty again
<hatch> sure I still think it's a hack :)
<rick_h_> hatch: yay tests pass
<hatch> and I thought that the login/logout routes would be a simple fix :)
<rick_h_> hatch: ok, color me confused. What you added is just a pass through beforeEach/afterEach?
<hatch> the before/after each still run as normal, so that's why I am destroying the env that the before created
<hatch> clobbered the method causing issues
<hatch> then reset it back after
<abentley> gary_poster: I don't understand why you would need your own apache if it was a subordinate.  The subordinate relation could make the charmed apache serve your static files.
<gary_poster> abentley, the GUI's haproxy would need to proxy the apache, so the haproxy needs to have control over the external port that serves the GUI--80 and 443 in our case.  I could imagine a setup that had the GUI served from apache in one charm, and then fronted by an haproxy service that was specially configured to serve the Juju API properly.  That haproxy would probably require custom development and unusual configurat
<gary_poster> ion, and would be antithetical to my desire to make deploying the GUI very easy (a single deploy statement and a single expose statement).  If we could make the GUI charm support both the easy deploy and the subordinate deploy story then that would be fine in theory.  However, 
<gary_poster> that is only interesting with the jujucharms.com/sandbox story.  Until convinced otherwise, I prefer to have a single charm that is configured to handle the different cases.
<gary_poster> That was a bit convoluted, sorry. :-/
<hatch> I noticed that the featured flags route is at the end of the route list - shouldn't that be at the start?
<hatch> so that the other routes can rely on that code?
<abentley> gary_poster: I'm not familiar with the haproxy+websockets issues.  Do I understand correctly that juju-gui's charm installs both juju-gui and haproxy?
<abentley> gary_poster: And apache?
<gary_poster> abentley, yes.  want to have a chat?
<abentley> gary_poster: sure.
<gary_poster> abentley, guichat is open (https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a)
<hatch> jujugui - anyone available for a QA and review? https://codereview.appspot.com/9415043/
<bcsaller> hatch: I can review that
<hatch> thanks - any chance I could get a QA too? sorry QA'ing this kind of sucks :/
<bcsaller> yes
<hatch> u da man
<gary_poster> hey bcsaller.  so, I can drag and drop into another GUI, or...what else?
<gary_poster> I guess a text editor.
<gary_poster> trying
<abentley> sinzui: Have you seen my explanation of the deeper cause in https://bugs.launchpad.net/charmworld/+bug/1179942 ?
<_mup_> Bug #1179942: Max retries exceeded with url: /charms/_search?size=10 <api> <elasticsearch> <oops> <charmworld:Triaged> <https://launchpad.net/bugs/1179942>
<bcsaller> another gui is really the target, the export hotkey is the download story as its not size limited
<sinzui> ES was not up
<gary_poster> text editor does not work.  ah ok
<gary_poster> hm
<sinzui> ^ abentley ES was not up, so the app tried until it hit the max
<abentley> sinzui: Right.  I'll copy the explanation to 1176901, but please don't mark *that* as a dupe :-P
<hatch> bcsaller, so what's the best way to clear out the namespaces?
<sinzui> abentley, It is the older bug and I think it is the same issue. It is about the time we discovered that ES timesout on start
<bcsaller> hatch: look at showRootView
<hatch> ok I was thinking override myself thanks
<hatch> hmm not working
<hatch> to the investigator!
<abentley> sinzui: I'm sorry if I didn't communicate that clearly to you earlier.  I thought I had.
<bcsaller> gary_poster: do you need different behavior for export? Our choices are limited w/o the server generating a URL for the Download. If it does then we can be more sophisticated. 
<bcsaller> generating the blob for the S-d export works because it doesn't need to be referenced apart from the download, but passing a URL (the other mode of DnD) can't reference such a file. 
<bcsaller> there is a possibility to request local file access, generate the file there, but its was not clear it was worth the effort 
<gary_poster> bcsaller, ok.  had to think a bit about that.  I am concerned about the drag and drop UX because I think it gives the wrong idea of what you can do.  I realize that this must be demonstrated to someone for them to find it, but I want to make it super explicit that this is experimental.  Could you put the drag and drop behind a "gui.experimentaldndexport.enable" flag, or similar?  (you could delete the "experimental,
<gary_poster> " for instance :-).  Then when we demo, it will be clear that this is not released and should not necessarily be expected in the future.
<bcsaller> drag out being a strange story to being with. Store interaction for example would make more sense 
<gary_poster> sorry, reading what you are saying now
<gary_poster> yeah agree
<gary_poster> basically I think we ought to be able to show off what you have done, so people like Luca can get a feel for possibilities, while being clear that this is not actually released
<gary_poster> it sounds like you are on the same page
<gary_poster> again, I realize the feature flag simply adds to the hidden nature of what you already had
<gary_poster> bcsaller, you ok with featureflag?  if so will LGTM 
<gary_poster> btw, who updated the background for the gui blog?  I meant to say thank you!
<bcsaller> gary_poster: yes, fine with that, though I'd make it quite short if you're ok with it /:flags:/dnd or something
<gary_poster> bcsaller, prefer to make it explicit.  In approval to Matt's branch I pointed to Launchpad feature flag names.  As I quoted them I thought they might be too heavy, but "dnd" is IMO an example of what we don't want: a feature flag that does not clarify what it does, and that will encourage naming conflicts
<bcsaller> fair enough
<gary_poster> so, I'd be fine with a naming convention that was more trusting, and more trying to state the intent rather than the letter: "choose a name that clearly indicates what it does, both for docs and for name clashes"
<gary_poster> we need to share this though
<gary_poster> right now the rule is the LP rule
<bcsaller> gary_poster: right now its only enabled with sandbox (except for the hotkey, which I think is fine?) I will add the flag. I think always saying gui. and experimental can both be dropped and presence indicates enable implicitly, no?  So 'dndexport'?
<bcsaller> if you feel strongly I can go with the whole thing though
 * gary_poster hates xchat sometimes
<gary_poster> bcsaller, ok with dumping gui (was in contrast with charmbrowser. or inspector. or whatever) for now until we change our minds.  The other element is supposed to be a verb
<gary_poster> dndexport.enable
<bcsaller> ok
<gary_poster> the contrast is supposed to be "disable" or a particular flavor of approach
<gary_poster> bcsaller, you can argue against that too and say YAGNI until proven otherwise
<bcsaller> seems like presence is on, as you'd never have to turn off a feature flag given our current plans?
<bcsaller> they will all say .enable
<gary_poster> maybe so bcsaller .  go for it.  have to run. :-P
<bcsaller> ha, ok
<gary_poster> :-)
<hatch> bcsaller, the fix is being proposed
<hatch> bcsaller, ok the changes are up - should QA properly now
<hatch> you might need to appcache-force 
<bcsaller> hatch: I'll check it again in a few minutes, thanks
<hatch> yep no rush thanks again
<hatch> thanks for the qa and review bcsaller - I'll add that note into hacking
<hatch> anyone else still working? :)
 * hatch wants to land this
<hatch> bcsaller, I created a new unit-tests.rst file to document unit test gotchas and added it to the branch
<hatch> morning huwshimi 
<Makyo> hatch, looking at your branch because sick of bzr.
<hatch> switch to git?
<hatch> :P
 * hatch is just trolling 
<Makyo> HAh.
<hatch> lol I have only found a few things that git is actually better at
<hatch> but they are used so infrequently it's hardly worth it
<Makyo> Yeah.  There's a lot of stuff that bzr does or can be made to do that make the transition relatively easy.  I just screwed up my local stuff.  Was going to rebuild, but I need a break.
 * rick_h_ sneaks up behind hatch to snuff out that nonsense he's spewing
<hatch> haha sounds good
<hatch> rick_h_, lol I think you're more pro-git than I am :)
<rick_h_> hatch: it definitely sounds so
<hatch> Makyo, is there more recent documentation for juju charm development than https://juju.ubuntu.com/docs/getting-started.html this hasn't been updated since november
<rick_h_> hatch: check with marco in #juju and ask about juju create and such
<rick_h_> hatch: there's some stuff in the works but not sure where/what state it's at
<Makyo> hatch, Don't know, but yeah, check with marcoceppi.
<Makyo> Or m_3, I think?
<hatch> that name has a ring to it
<Makyo> You talked with both of them about the node charm.
<hatch> marcoceppi......marcoCeppi......maaaaarcoCEPPI
<rick_h_> heh
<Makyo> hatch, lost track of time.  Will do a code review now and try to do QA after dinner.
<hatch> sure np - bcsaller did a QA so you probably don't have to if you don't want to
<hatch> but 2x is always better :)
<Makyo> hatch, will leave it up to you, but yeah, more is better
<hatch> maybe because it's such an integral part you should probably do another
<hatch> I am not sure if he tested with the go back end
<hatch> do we have a fake go back end?
<hatch> :)
<hatch> Makyo, thanks for the review  - I was also curious about the story for requiring the login
<hatch> I'll create a friday ticket
<Makyo> hatch, cool, thanks.
<Makyo> hatch, I know a lot of sites that lose your current goal when you log in, so it's not unusual by any stretch, but still.
<Makyo> Some keep it in a ?next=<url>
<hatch> yeah I am just thinking that if that happens and then they paste the url again they will need to log in again
<hatch> *might need to*
<hatch> I'd like to see a ?redirect I think...
<hatch> or yeah... a ?next or something along those lines
<hatch> should be pretty easy to implement
<rick_h_> stick it in localstorage and clear it out post-login
<rick_h_> avoid url/router bits
<hatch> that might be more work
<Makyo> hatch, yeah.  I mean, pasting the URL again, they have the creds in local storage.
<hatch> yeah if they have allowed the local storage
<Makyo> True.
<Makyo> or session storage or whatever we use.
<rick_h_> who doesn't allow localstorage? it's pretty darn built in
<hatch> rick_h_, it asks for permission - people click no out of habit haha
<rick_h_> hatch: it doesn't for localstorage
<rick_h_> hatch: you're thinking offline cache access, I just mean sticking the url to redirect to in the key/value store
<rick_h_> http://caniuse.com/namevalue-storage
<rick_h_> hatch: they don't ask until after 5MB I think
<rick_h_> http://dev.w3.org/html5/webstorage/#disk-space
<hatch> oh right
<hatch> that would probably be the cleanest but using the query params would be the easiest to implement
<hatch> although probably not by mjuch
<rick_h_> hatch: yea, just an idea as it's more invisible. I'm with Makyo that it'd be nice to implement url saving on login for sure
<hatch> ok well there is a ticket for Friday to discuss
<hatch> I'm sure that it will pass pretty easily 
#juju-gui 2013-05-15
<bac> hi gary_poster, i updated the machine image, as well as automating it though that isn't done yet, but CI is still failing.  i can't tell what is wrong from the console logs of the two runs i tried.  thoughts?
<gary_poster> bac, hi, I am out today.
<gary_poster> jujugui ^^^
<bac> gary_poster: right, sorry
<gary_poster> bac if I had to guess from output I would say image is wrong somehow, but yeah, output is not useful at all, and diff than before
<bac> gary_poster: yep.  go away.  :)
<gary_poster> :-)
<hatch> morning
<benji> hatch: I bet you're not quite in the office yet.
<benji> rick_h_: I have a YUI event/subscriber question.  Do you have a minute to talk in the hangout?
<hatch> benji, correct, should be in about 10 though
<benji> hatch: cool; you and rick_h_ can race to see who gets to talk to me
<hatch> lol ok I'm back
<hatch> still need the hangout?
<hatch> ^ benji 
<benji> hatch: I'll meet you in the regular place.
<hatch> cool be there in a sec just gota grab my headset
<Makyo> hatch, sorry I didn't get to QA last night, doing it now.
<hatch> benji, we have a bad connection
<hatch> trying to rejoin
<hatch> benji, is it all of the attr change facades are sticking around?
<hatch> or just one?
<hatch>  /some
<benji> hatch: I don't know about all, but many, many are
<hatch> alright thats fine
<hatch> thx
<hatch> benji, are there any other attribute facades sticking around?
<hatch> others besides change?
<hatch> Makyo, thanks :) 
<abentley> sinzui: btw, the app-exception.log is tremendously useful.  Thanks for getting that working.
<sinzui> yes it is isn't it. I ponder switching to oops tools instead of sending volleys of errors emails to me now
<hatch> benji, sorry, did you see the previous message?
<sinzui> abentley, do you want me to request a release of m.jc? I think this will be the first release of using the ES collection migration feature
<abentley> sinzui: Please do.
<bac> hi hatch
<bac> hatch: jenkins is running again but still unhappy.  can we chat a bit to go over the failures?
<hatch> I think that failure you want to talk to frankban about
<hatch> he was having some issues with the deploy test failing
<benji> hatch: there aren't enough to show promenently in the heap snapshots, but there may be
<bac> hatch: previously there was a failure sending results to saucelabs.  perhaps that one was transient.  have you seen it before?
<bac> hatch: thanks.  i think frankban is gone today.
<frankban> hatch, bac: the failures I was seeing last week are caused by firefox not being able to reconnect the websocket after switching from sandbox to staging.  I think that's unrelated to the current errors. However, I am changing my branch so that the selenium driver is started for each testcase (not once for all tests). This should make our suite more reliable, and slightly slower...
<frankban> bac: I am here
<bac> but i was wrong!
<bac> frankban: is that landing soon?
<frankban> bac: I'd like to propose it today. Coding is done, testing takes time
<bac> ok
<Makyo> For future reference: lightweight checkouts suck for QAing.
<frankban> one cool thing about having a separate driver for each testcase is that we have many separate saucelabs videos
<Makyo> hatch, LGTM on QA.
<hatch> thanks Makyo - landing
<hatch> bac, still want to chat? 
<bac> hatch: sure, briefly
<bac> hatch: ready when you are
<hatch> can you hear me?
<hatch> benji, eric said that it's likely our app which is causing the issue 
<benji> hatch: that's easy for him to say ;)
<benji> meanwhile I have a workaround that stops the leak (and might break the app, but you can't have everything)
<abentley> sinzui: One thing I can't help noticing is that even minutes after restarting elasticsearch, it's still eating a lot of CPU although no one's hitting it AFAIK.
<abentley> It's bouncing around between 10%-70% CPU use and load average is .96
<hatch> benji, lol any luck with the repro?
<benji> hatch: I haven't tried yet, I had the idea for the workaround and wanted to try it first, repro is next
<hatch> gotcha - I can help with the repro if you want to pass me your testing code
<sinzui> abentley, wow. what is in play? it starts the Java vm, the lucene proc, and a web proc
<frankban> bac: I duped the 'service not deployed' error locally, investigating
<bac> frankban: ok, thanks
<abentley> sinzui: It appears to be the elasticsearch binary.  http://pastebin.ubuntu.com/5667901/
<hatch> oh awesome you can watch the uds videos live
<abentley> sinzui: CPU is now reasonable and load average is dropping.
<hatch> running the tests and streaming a uds video have put my laptop to a new high temperature!
<hatch> 72.5C lol
<sinzui> abentley, The current ES release has a number of fixes for hangs. It is probably worth us updating. Lp's imports failed though. I will kick, and if that fails, I will pull the source directly from github
<abentley> sinzui: Great.
<hatch> jujugui - new login/logout branch has been merged with trunk
<hatch> let me know if you run into any issues
<sinzui> abentley, m.jc is not r225. I an sadder note, I think I deleted your very important email that I was not to read until my head was clear. Please resend it...I will immediately move it a safe place so that it is not among the blueprint spam
<abentley> sinzui: done.
<sinzui> abentley, adeuring: I ponder the relationship between the short_url KeyError and promulgated charms. Every example I see is juju-gui, the only promulgated charm that is not owned by charmers.
<adeuring> sinzui: thanks 
<abentley> sinzui: Yes, that could be it.  The short-form URL I'm using is one of those places where we're forced to assume ~charmers.
<frankban> may the ancient gods kill firefox because he's sick and suffering
<hatch> frankban, lol
<hatch> some things it does so well....others....not so much
<frankban> bac, hatch: so it seems that in firefox the appflower deployment fails because the service block is not visible in the canvas at the default zoom level, and so, the corresponding element's text is just empty. :-O
<Makyo> jujugui call in 10
<hatch> frankban, possible issue from the layout changes Makyo did?
<frankban> bac, hatch: fixing this in my branch and the fix will be... zooming out before checking for service names in the canvas.
<hatch> lol 
<bac> frankban: thx
<hatch> I suppose that's the best fix as any
<Makyo> What :|
<Makyo> Zoom levels just act as a viewport.  Things that are outside the viewport are still on the canvas.
<frankban> hatch: yes, Makyo's changes are great, firefox is cursed, firefox is the new ie. ok I said that...
<hatch> Makyo, ahh ok - I wasn't sure exactly how your layout code handled that
<hatch> frankban, lol! at least it auto updates so it CAN be fixed :)
<Makyo> hatch, exactly like scrolling.  Elements at the bottom of the page are still within the dom.
<Makyo> SVG being just a part of the DOM.
<hatch> I don't think the test knows that it's in the dom, just that it's visible
<hatch> so I was wondering if your new layout stuff put the new service off the page
<hatch> (in the soucelabs tests)
<frankban> hatch, Makyo: it's just a firefox issue AFAICT. The service block is found in the DOM, and the tests knows both that it's in the DOM and that it's not visible by the user. The problem is that selenium/firefox is not able to retrieve the .name element text if the service block is not made visible. that's really odd
<hatch> oh boy...lol sounds like a firefox selenium driver issue
<hatch> so maybe it's seleniums fault not firefox
<hatch> ;)
<Makyo> frankban, ah.  Yeah, browsers treat SVG a little strangely (HTMLElements vs SVGElement), and some of the attributes/methods are different.  Hopefully it's not that...
<hatch> firefox does have issues with svg attributes
<frankban> zooming out fixes that, and let's say it's also not horrible, b/c it lets you see the deployed service in the videos
<Makyo> If so, though, just means involving D3 in tests, since they've already solved the cross-browser compatibility problem there.
<Makyo> Huh
<Makyo> That's weird.
<Makyo> jujugui call in 2
<hatch> I'm ok with zooming out as a solution
<hatch> :)
<frankban> seeing things from a wider perspective is always a good idea
<Makyo> https://ec2-54-243-27-37.compute-1.amazonaws.com/
<benji> by the way, my laptop's wi-fi has been crazy flakey for the last week or so, so if I'm not on IRC, I'll probably be back soon.  You can always text or call me if need be.
<Makyo> Doing a few quick config change on the ec2 site I just mentioned, just to see if that messes with things at all.
<Makyo> Seems fine.
<jcsackett> hatch: looks like your login/logout stuff might be eating urls.
<jcsackett> if i go to /bws/sidebar, that gets removed as the page loads. i can make the behavior stop by reverting your revision. :-/
<bac> umm, tasty urls
<jcsackett> bac: :-P
<hatch> jcsackett, so when you type that url in manually it is just removed?
<jcsackett> hatch: right; if i put in $guiurl/bws/sidebar, rather than getting the sidebar loaded, i get just the canvas and the "/bws/sidebar" bit is gone.
<hatch> ok let me look into that thanks
<jcsackett> hatch: not sure you should be thanking me, but thank you for looking into it. :-)
<hatch> jcsackett, ok I can reproduce - the sidebar shows up still but the url is gone
<jcsackett> ccccccbljtrvbcvtkeunclicukrirgefcjfkjcbtkcll
<jcsackett> dammit.
<hatch> lol
<jcsackett> hatch: i don't reliably get the sidebar. sometimes it shows, sometimes it doesn't. the url is always eaten though.
<hatch> ok it strips urls no matter what
<hatch> I'll have to investigate this
<hatch> it's not just on browser
<jcsackett> dig.
<hatch> jcsackett, just wanted to let you know I have found the issue and working on a proper workaround
<hatch> Makyo, are you around?
<Makyo> hatch, just got back.  What's up?
<hatch> In order to fix the bug that jc found, to do a proper fix I should implement the redirect 
<hatch> after logging in
<hatch> so.... localstorage or hash?
<hatch> I am thinking local
<hatch> or another 'clean' experience I'm happy with too
<hatch> storing with some other type of local var
<Makyo> I say a var, or maybe local storage.  I think the full story has logging in as a step in a process, so we shouldn't need anything as complex as a storage mechanism.
<hatch> sounds like a plan
<hatch> alright I'll implement it with this fix
<Makyo> hatch, cool.  Sounds good.  Want to just convert the discussion card to a task?
<hatch> sure thing
<hatch> doesn't look like I can
<hatch> I can re-make one though
<Makyo> Sure.
<benji> why is the gui using jquery?  I didn't know we had that in there.
<Makyo> Out for the afternoon, stuff fromn earlier turned into migraine.  Back 100% tomorrow
<hatch> get better Makyo|out ! C U tommorow
<bac> hatch: my ci branch is up for review if you'd like a diversion for your afternoon
<hatch> certainly
<bac> âââ
<bac> i'm going to try to walk the dog between storms
<hatch> bac, review has been completed, sorry I forgot to click 'submit' :)
#juju-gui 2013-05-16
<gary_poster> hi everyone
 * gary_poster does not look forward to inbox
<bac> hi gary_poster
<gary_poster> hi :-)
<benji> we really do need to make a concerted effort to reduce the number of noise emails we get, it is not just annoying, it increases the chance that we'll miss something important
<gary_poster> benji, friday card?
<benji> gary_poster: say again?
<benji> oh, the email thing
<benji> sure
<gary_poster> yeah
<gary_poster> thanks
<gary_poster> hey bac, should I review the "find an appropriate machine image" branch or wait for changes from Jeff's review?
<bac> gary_poster: i'm almost done answering.  give me a few minutes.  thanks for asking.
<gary_poster> cool
<bac> gary_poster: done
<bac> gary_poster: our 1:1 conflicts with the uds session.  i can do it most any other time today or tomorrow
<gary_poster> ok bac, thanks.  I will drag it somewhere or other, or you are welcome to if you look at my schedule also
<bac> i'll let you do it since you have more scheduled stuf
<bac> f
<frankban> gary_poster: hi, thanks for the review! weekly call?
<gary_poster> frankban, urgh, sorry :-)
<gary_poster> joining
<frankban> :-)
<abentley> adeuring:  So Launcpad's getBranchTips API works is that if the branch is promulgated, the series it is linked to are the last element of the tuple.  So in "["~charmers/charms/precise/apache2-passenger/trunk", "jorge@ubuntu.com-20130422194721-qz44aua2wpkri90p", ["precise"]]" the final "precise" indicates that this is a promulgated branch.
<adeuring> abentley: ok, thanks
<hatch> bac thanks for those changes - just wondering if you are going to add the section on how to change the server image stuff in your new script to the docs
<bac> hatch: when approved, before landing, i'll update that section to deprecate it.
<hatch> alrighty - I just didn't see a comment about it
<hatch> lgtm'd
<bac> hatch: did you mention it and i didn't reply?  if so, sorry.
<hatch> sok, it happens :)
<bac> \o/, jenkins is happy again
<gary_poster> yay!
<gary_poster> thank you bac
<bac> thanks to frankban's branch i suspect
<gary_poster> thank you frankban :-)
<frankban> :-)
<hatch> being that prod doesn't support 404's it makes it impossible to test the after-login-redirect on prod 
<hatch> ack decoratedRelation
<hatch> oops
<hatch> :)
<gary_poster> bac, thank you for attending charm dev tooling.  that may prove to be essential for us this cycle
<gary_poster> I wanted to be there but not enough to come back to work :-)
<gary_poster> did you learn anything of interest?
<bac> gary_poster: yes, but it is still a bit of a mess.  it is not clear to me what the path is for reconciling the libraries
<gary_poster> ok
<gary_poster> We may want to lead some of this
<gary_poster> That way we have what we want, at least in part
<bac> the two overlapping ones are charm-support and our stuff
<gary_poster> right
<gary_poster> If we port charm-support to use our stuff, assuming our tests are as good or better, we might get a good resolution
<bac> i think we need to work with matthew to decide how to merge them.  i fear that existing code bases will make neither party interested in moving to the other
<bac> gary_poster: you mean make existing charm-support a wrapper?
<gary_poster> I wonder if their charms are actually using host.py directly
<gary_poster> well, the overlap is in host.py AIUI
<gary_poster> if we make one package that is low-level utils (our stuff)
<hatch> Makyo, are you around?
<gary_poster> and convert the charm-support to use them
<gary_poster> charm-support bits
<gary_poster> then it may be easiest all around
<Makyo> hatch, Yes, what's up?
<bac> is anyone going to UDS Charm Testing in 30 minutes?
<gary_poster> I want to propose that
<gary_poster> I was supposed to bac, but I think I need to prepare for other things.  jujugui, do we have any volunteers for Juju Charm Testing in 30 minutes?
<frankban> gary_poster: yes
<gary_poster> thanks frankban 
<teknico> gary_poster: I'll be there
<gary_poster> thanks teknico 
<hatch> Makyo, in my new login branch (the one that fixes the url issue) there is an error being thrown in views.DecoratedRelation (Cannot read property 'modelId' of undefined )
<hatch> this only happens on prod build
<bac> frankban, teknico: tips: be sure to set up "lower third" banner in G+ with the color, logo, and your title.  if you don't they'll ask you to
<teknico> gary_poster: is the web page enough, or do we use hangout to attend?
<hatch> so I see that modelId is trying to be accessed on a service which is undefined
<teknico> bac: unfortunately the toolbox is not working for me :-/
<hatch> and that is called on 'update' 
<bac> frankban, teknico: also you've got to go to the hangout not just the session page if you want to participate
<hatch> but what causes it to update?
<gary_poster> bac, they need to ask Antonio for that url, right?
<hatch> I am thinking that it's updating before the deltas are in?
<teknico> bac: right, where's the hangout url?
<gary_poster> the hangout url I mean
<Makyo> hatch, no clue.  I can't really switch right now.  Maybe check with bcsaller ?
<bac> gary_poster, teknico: ask someone to paste it to IRC or the etherpad
<hatch> Makyo, ok np, just figured bcuz d3 :)
<gary_poster> teknico, frankban I suggest asking arosales out of band beforehand
<Makyo> hatch, that's not d3, that's topology.  Probably fired by db update, but yeah, can't quite check right now.
<teknico> bcsaller: good morning :-)
<gary_poster> Makyo, hatch bcsaller is out for rest of week at Google I/O.  Doesn't mean Makyo should drop everything, but just to be aware
<Makyo> gary_poster, ah, thanks
<hatch> oh right I forgot that he was there
<bcsaller> I'm here for a few minutes now
<gary_poster> hi bcsaller.  Did you get google glasses? :-)
<hatch> ok real quick :) what causes update to fire on the relation topology code
 * arosales reading back scroll . .  .
<hatch> he got a Pixel....lucky!!
<bcsaller> gary_poster: pixel chromebook
<gary_poster> ah, cool@!
<gary_poster> sorry arosales.  could you give frankban and teknico hangout url for charm testing please?
<bcsaller> trying to get Ubuntu on it before I head back 
<hatch> I'll take it off your hands if you don't like it
<hatch> no problem....I'll take the burden
<bcsaller> heh
<arosales> gary_poster, will do.
<arosales> I'll post it into #ubuntu-uds-servercloud-2 irc room too
<hatch> :)
<arosales> gary_poster, frankban teknico hatch ^
<hatch> so bcsaller do you know - off the top of your head - what causes the relation update code?
<gary_poster> cool thanks a lot arosales 
<teknico> arosales: thanks, I'm there already
<arosales> I create a new hangout URL about 5-10 minutes before each one starts.
<bcsaller> hatch: db update triggers topo.update which will call it for the relation module
<arosales> Google + On air requires a new hangout for each session.
<hatch> ok so if service is undefined during the update that would mean that the deltas haven't fully come in yet?
<bcsaller> hatch: its possible it could be trying to resolve the charm still
<hatch> bcsaller, alright - thanks just wanted some insight as to what the sequence was here before debugging because it only happens on prod so it's a little difficult to debug
<hatch> well...only on prod and only on initial login
<teknico> jujugui, I'm trying to land a branch (bcsaller's one) and the lbox check fails horribly, has anyone seen this? http://pastebin.ubuntu.com/5670997/
<gary_poster> not I
<bcsaller> I couldn't have even proposed it with that 
<bac> nope
<teknico> bcsaller: how do you mean?
<bcsaller> I mean to propose make check had to run here, so I didn't get that 
<hatch> bcsaller, thanks - I was able to resolve right away with that little bit of insight :)
<hatch> so because prod doesn't support extra paths does orange not test on prod?
<teknico> bcsaller: yeah, that's the output of "make check"
<hatch> ^ sinzui (just curious because I want to make sure this all works before proposing)
<hatch> bcsaller, so how is IO? I was able to catch a couple talks in the background but I am sure there are a lot more on the ground
<bcsaller> hatch: its been alright, some useful tips from the chome side of the house relatated to avoiding repaints and tracking leaks
<hatch> I think I heard that one....the redbox one with the slide out left panel?
<bcsaller> hatch: yes
<hatch> yeah some pretty cool stuff there that can probably help us out
<hatch> going to be an android/java dev by the time you come back?
<bcsaller> yeah, I was watching the redraws on the gui, we can do better
<bcsaller> hatch: android studio is a big improvement 
<hatch> I was reading about that last night - really going to help adoption I think using a 'real' ide
<hatch> not that eclipse isn't a real ide.... ;)
<hatch> gary_poster, were you able to find a workaround to pipe diffs to sublime?
 * hatch has been working in Ubuntu
<gary_poster> hatch, no, not on linux.  I write to file :-/ .  frankban and teknico also use it; maybe they have a better answer?
<frankban> hatch: I write to file too
<hatch> this is unacceptable!! one of you pythonites should write a patch ;) 
<Makyo> hatch, tried qdiff?
<bcsaller> or meld
<Makyo> Meld's good too.
<hatch> I haven't even heard of them :) I'll take a look, on OSX I could just pipe to sublime so it was never an issue
<hatch> thanks I'll look into those
<bcsaller> bzr qdiff (or you might not find it)
<Makyo> sudo apt-get install qbzr
<hatch> qdiff is in apt
<bcsaller> meld is standalone and for when you want to do something with the files relative to the diff, qdiff is more for review 
<hatch> doesn't qbzr make it like git? shared folders and the like?
<Makyo> hatch, that's cobzr
<hatch> oh ok
<Makyo> hatch, qbzr is just a Qt wrapper around a bunch of bzr commands.
<hatch> gotcha - installing
<hatch> I'll give meld a go too
<hatch> bcsaller, so are there more talks than the 5 in each block that are listed online?
<bcsaller> yeah
<hatch> I thought so
<hatch> else those would be some full rooms :)
<bcsaller> either way, they are
<hatch> can I pipe a diff to meld? or do I have to use the GUI?
<hatch> help file only shows via the gui
<luca> gary_poster: Hi Gary, are you available for a quick catch up with Ale and me?
<bcsaller> hatch: not sure what you want to pipe, what would you normally use?
<sinzui> hatch, Orange does run "make test-prod" though individuals may may mistakes from time to time.
<hatch> on osx I `bzr diff | sub`
<gary_poster> sure luca.  http://tinyurl.com/guichat (it is free and I am there now) or somewhere else?
<luca> gary_poster: sure
<gary_poster> cool
<hatch> sinzui, ok that's what I meant - they don't go into the browser and test it on prod....I was wondering it there was a way to make it appear without changing the url
<sinzui> hatch, when I review, I pull the branch and run the tests myself to be sure tests run in several scenarios.
<sinzui> hatch, I hope that tarmac will provide some assurances that I forgetful developers are reminded before anything can merge
<hatch> :) I just wanted to make sure that there wasn't some secret way to test the browser on prod in the browser before I propose :)
<sinzui> hatch, I don't know of a better way than exploring the site during development and review at this time. :(
<hatch> yeah that's fine - just thought I'd check before assuming 
<sinzui> hatch, this is also why I am slow when doing gui reviews
<hatch> because assuming makes an ass out of u ming 
<hatch> wait that's not right...
<hatch> haha
<hatch> :P
<hatch> I think there is a card to get prod working to redirect 404's to root but until then.... :-)
<arosales> gary_poster, I am also checking with the orange team but would any folks here be interested in joining the Charm Store feeback loops session at the top of the hour?
<arosales> http://summit.ubuntu.com/uds-1305/meeting/21694/servercloud-s-juju-charmstore-feedback-loops/
<hatch> jujugui when you have a chance could I get a QA and review on https://codereview.appspot.com/9445043/  thanks
<bac> hatch: will do
<hatch> thanks sir
<gary_poster> arosales, sorry was on call.  jujugui can anyone join the session arosales mentioned in 20 minutes?  I would suggest that whoever joins think about bundles and whether they fit into the discussion in an interesting way.
<gary_poster> this would be in lieu of our daily call for whoever joins
<gary_poster> so only one volunteer would be good. :-)
<arosales> gary_poster, thanks. I haven't gotten any volunteers from orange atm, but I think a few of them are out this week.
<gary_poster> arosales, yeah I know rock and jc are, who would be the most obvious choices afaik
<gary_poster> rick
<Makyo> bac, your post on bzr went missing.  Is that still written down somewhere?
<bac> Makyo: the alias for pulltrunk?
<Makyo> Yeah
<bac> shoot
<bac> Makyo: bzr alias pulltrunk="pull -d :parent"
<gary_poster> benji, can you find the link for statsd emitter implementations in different languages?  I see different servers but not emitters
<benji> sure
<gary_poster> I know I'd seen it before though
<gary_poster> thank you
<benji> gary_poster: https://github.com/etsy/statsd/wiki#client-implementations
<gary_poster> cool thanks benji!
<benji> np
<Makyo> bac, thanks
<Makyo> bac, oh, looks like it was a draft post that was only showing up when I was logged in. 
<gary_poster> hatch when you are wondering what to do next, lemme know please :-)
<bac> Makyo: it should be published now
<bac> Makyo: i thought i had
<Makyo> bac, cool, thanks!
<bac> the wp interface is a holy mess.
<Makyo> Yes.  Yes.
<hatch> gary_poster, shoot - I'm just reviewing my last branch
<Makyo> bac, It's a little clearer if you're running your own copy, but only a little.
<gary_poster> hatch, :-) k
<bac> Makyo: well the multiple editor views kills me
<gary_poster> hatch, let's do it after call
<hatch> sounds good
<teknico> bac: there's a "the" and an "interface" too many ;-)
<Makyo> bac, yeah, true.
<gary_poster> jujugui call in 8.  please update kanban
<gary_poster> benji are you fairly confident that the "last value" of each statsd metric will be sufficient for the metadata display we want?  or is there some interaction between values over time that we need to worry about?   I read about it this weekend but was not clear and have not taken the time to improve my understanding
<benji> gary_poster: I belive that for some of the stats types (guage for sure, maybe others, my memory needs to be refreshed) the last value is all we will need to display a good value; I am pretty sure there is at least one other type that we will have to track over time in order to display something meaningful 
<benji> perhaps a card for someone to research and cogitate on the topic would be good (I'll volunteer if I can get out from under this memory leak)
<gary_poster> jujugui call in 2
<gary_poster> sinzui, are you able to go to vUDS charmstore thing or should I delegate someone so we have at least someone there?
<sinzui> Oh, bugger. I forgot.
<sinzui> Yes I want to attend
<sinzui> thank you gary_poster
<gary_poster> ok thanks sinzui.  arosales I didn't have any volunteers, and sinzui will be there.  I'll see if anyone else can join late.
<arosales> sinzui, thanks
<gary_poster> bac ping to join guichat
<arosales> as long as there is one rep that is good
<gary_poster> cool thanks arosales 
<arosales> sinzui, https://plus.google.com/hangouts/_/0668cba98347aa731901ad12783d4ba70dd1bebe?authuser=0&hl=en
<bac> hatch: doing QA for you.  when using devel/rapi what is the login password?
<bac> after landing my jenkins-fixing branch, jenkins died.  a retry and it is back to normal.  hope i didn't introduce fragility.
<teknico> weird stuff installed in /usr/local, bah. cleaned it all up
<hatch> bac, admin
<bac> hatch: admin no worky
<hatch> it says the pw is incorrect?
<teknico> gary_poster: still good to land bcsaller's branch?
<gary_poster> teknico, yes
<bac> hatch: if i hit localhost:8888 and then logout, enter 'admin' as password it says it is incorrect *and* the canvas background goes dark
<hatch> let me try it locally
<bac> hatch: and when that happens the password entry box is no longer selectable
<bac> hatch: and the url goes from localhost:8888/login/ to localhost:8888/logout/
<bac> hatch: given that bit of bad QA i think i'll excuse myself for lunch if that's ok.  i'll look at it again as soon as i return.  ok with you?  (it is fried chicken day at fattie's and she runs out fast!)
<hatch> bac, hmm I think you have a bad merge
<hatch> there is no more /logout/ paths
<bac> hmm
<hatch> I'm just trying now
<hatch> yeah I am unable to reproduce
<hatch> did you merge into trunk or just check out the branch?
<bac> hatch: i have a fresh trunk then merged your branch
<bac> hatch: i've tried against sandbox and rapi.  against rapi i get the same behavior except for the redirect to /logout
<bac> hatch: the merge shows 180 changed lines, just like your MP
<hatch> hmm try just checking out the branch
<hatch> I'll try merging trunk here
<hatch> see if i can repro
<hatch> oh bac index.html has been edited
<hatch> you might need appcache-force
<hatch> the logout button is now a div not a link
<hatch> so I wonder if that might be the issue
<hatch> ahhh
<bac> hatch: appcache-force did not help.  neither did clearing browser data.
<bac> hatch: if i shelve your changes all works
<hatch> ok something is broken with trunk here
<bac> trunk wfm
<hatch> my trunk index.html has the logout link as an <a> but on launchpad its a div
<bac> i see an <a>
<hatch> yeah that's wrong
<hatch> see http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/index.html#L102
<hatch> so something is broken there
<hatch> and here for that matter
 * hatch deletes his trunk dir
<hatch> there we go
<hatch> bac, delete your trunk dir and then re-checkout trunk
<bac> hatch: nothing was wrong with my trunk
<bac> i cleared my browser, make clean; make appcache-force; make devel and then it worked
<hatch> you said it had an <a> for a logout link
<hatch> ohh ok
<bac> hatch: nope, my browser element did
<hatch> sorry sorry
<bac> anyway it seems to work now
<hatch> glad we wont' have to deal with appcache anymore after Makyo s branch lands
<hatch> :)
<benji> indeed
<hatch> appcache has so much potential but it's implementation is just wako
<bac> hatch: QA is fine.  LGTM with some changes
 * benji runs a sandbox (with simulateEvents on) to check for memory leaks over lunch.
 * bac lunches
<hatch> thanks bac!
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/related-charms/+merge/164223?
 * sinzui does
<hatch> anyone else available for a QA and review on https://codereview.appspot.com/9445043/ ?
<arosales> gary_poster, fyi jcastro will have the hangout link for the Juju Gui session coming up.
<gary_poster> ack thanks arosales 
<gary_poster> jujugui join #ubuntu-uds-servercloud-2 and https://plus.google.com/hangouts/_/041beb28b529693593663161927dfd82747426c9?authuser=0&hl=en pls :-)
<gary_poster> jujugui also suggest opening http://pad.ubuntu.com/uds-1305-juju-gui-development rather than summit page
<benji> if you need the ubuntu logo, look here: http://design.ubuntu.com/wp-content/uploads/logo-ubuntu_cof-orange-hex.png
<gary_poster> if anyone has a graph of my use of the word "um" per minute they can keep it to themselves ;-)
<benji> we should start a vUDS award for best background; that could get interesting
<gary_poster> :-)
<bac> -----/\--______----^--
<gary_poster> heh
<benji> actually I was just thinking about how well you do at impromptu public speaking
<gary_poster> heh, thanks.  I do better when I'm not rushing from one thing to the next, I think :-)
<gary_poster> bac, actually, do you have a few minutes for guichat?
<bac> gary_poster: yep
<gary_poster> thanks
<hatch> anyone available for a review/qa on https://codereview.appspot.com/9445043/ ?
<sinzui> hi abentley. I have a question about the behaviour of related charms
<sinzui> abentley, It seems possible (because a test does not show it is not) that a charm could be listed among it's related charms. Eg apache requires and provides http, and I think its popularity would guarantee it to be listed among the other related charms. Except that is is not an "other" charm. Are we concerned about this?
<Makyo> hatch, sure
<hatch> thanks Makyo 
<abentley> sinzui: Yes, I would expect Apache to be "related" to itself.
<abentley> sinzui: I think it's an imperfect user experience, but I decided not to worry about it.
<abentley> sinzui: One issue is that there are a bunch of Apache charms, so blacklisting just the current charm doesn't reduce the problem significantly.
<abentley> sinzui: Maybe we should blacklist all charms with the same charm name (i.e. "apache2").  What do you think?
<sinzui> I think Identical name would make sense.
<abentley> sinzui: Okay.  Do you want that in this branch or a followup?
<sinzui> abentley, We could treat this as a follow up issuse.
<sinzui> okay, we agree, r=me
<abentley> sinzui: Do you think we should reduce the weight of charms with differing distroseries?  Technically, such charms can be used together, but I think people prefer to use the same series where possible.
<sinzui> Good point.
<hatch> thanks Makyo !
<Makyo> hatch, reply was missing an 'a', so here you go: aaaaaaaaaaaaaaaaaaaaaaaa
 * hatch takes those a's to keep for later
<Makyo> Just in case.
<sinzui> abentley, is it possible for a oneiric charm to match? I think I would like m_3 or jcastro to say the GUI/browser should not be showing charms for obsolete series...meaning stop indexing them too.
<m_3> sinzui: +1 on disabling indexing for unsupported series... maybe with a round of pings to maintainers if no more recent versions of charms exist
<sinzui> m_3, yes, that is one of my concerns. maybe manage.jujucharms.com should continue to show them so that maintainer can see the last know reports about them
<abentley> sinzui: Yes, it's possible for oneiric charms to match, just as they would for another search.  We'd have to delete them from the index for them to stop showing up.  Or maybe we should mark them as obsolete and penalize the scores of obsolete series charms.
<sinzui> My thoughts about preserving reports are flawed. Juju and charm proof are changing. A great charm for oneiric might be a bad charm for precise.
<abentley> sinzui: Don't we auto-clone the branches when we create a new Ubuntu series?  Should we do that here?
<sinzui> abentley,  I'd like to stop ingesting them. I think preventing them appearing in the GUI is good, but I think I still want m.jc to let me see the obsolete series charms. Ubuntu on Lp lets me do that.
<abentley> sinzui: The motivation for stopping ingestion is because they are unmaintained and won't stand up to newer versions of proof, etc?
<sinzui> abentley, I think we stopped. after the first try. m_3 might know the reason? Maybe it was because cloning branches when creating a new series confuses user. Precise is still the series we want users developing for.
<sinzui> abentley, right. Why fix/update charms for series we don't want people to deploy?
<abentley> sinzui: My reason to keep ingesting them is the behaviour of ingest changes periodically.  For example, I'm working on a branch to stick icon.svg in gridfs.  If we don't ingest the charms, they won't get updated, and we
<abentley> will have worse compatibility problems than we do now.
<bac> benji, did you see i found a known issue with python-requests and https proxy? bummer.
<abentley> sinzui: We could handle some of those cases with migrations.
<benji> bac: no I handn't seen that; bummer indeed
<abentley> sinzui: But in other cases, we'll start ingesting new data, so re-ingesting the charm seems like the only viable way to update the mongodb/es representation.
<abentley> bac: The one I filed?
<sinzui> abentley, possibly. Since the tools are changing, but oneiric is not, the situation is a conundrum. I don't think we will be backporting charm-tools to oneiric for authors to run. The charms were held to a difference standard.
<bac> abentley: no, this one
<bac> https://github.com/kennethreitz/requests/issues/905
<abentley> sinzui: The related charms for Apache are kind of absurd anyway.  "Oh you
<abentley> 're interested in apache?  Have you considered deploying WordPress, openerp or juju-gui?"
<hatch> gary_poster, would you like me to create tickets for this parent/child view stuff?
<gary_poster> hatch just made it in story 1
<hatch> oh ok thanks
<abentley> sinzui: When you get a chance, could you please review https://code.launchpad.net/~abentley/charmworld/reindex-failure/+merge/164254 ? It's remarkably short.
<Makyo> They're replacing our power meter, will drop in a few.
<hatch> Makyo, using too much power?
<hatch> turn off the bitcoin mining machines! ;)
<Makyo> Nah, upgrading to the smart meters.  Which is good, the one we have currently is awful.
<hatch> mine is a spinning aluminum disk
<hatch> pretty sure it's not 'smart' :)
<Makyo> Hah, yeah, ours is too.  We had one of the 110v legs go out, though, which damaged our stoves and one of my RAID disks, so it's desperately needed.
<hatch> ahhh that's no good
<Makyo> It was a little funny, because power would only run in the house if we turned on a burner on the stove.
<Makyo> And by funny, I mean dangerous.
<hatch> lol
<hatch> "what you doing?" "oh just boiling water to watch tv" "???"
<Makyo> Haha
<sinzui> abentley, looking now
<sinzui> abentley, and I just approved it. Thank you.
<abentley> sinzui: Thanks.
<BradCrittenden> gary_poster: are you getting canonicaladmin alerts now?
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/icon-as-file/+merge/164262 ?
<bac> where did FileSaver.js come from?  it needs to be added to our 'do not lint or fix list'.
 * bac does same
<bac> bzr st
 * sinzui does
<sinzui> abentley, r=me. I'll let you approve the merge itself
<abentley> sinzui: Thanks.
<Makyo> Dogwlk
<Makyo> hatch, can I borrow one of those 'a's? I seem to be having problems.
<hatch> oh hey yeah sure np
 * hatch hands an a
<Makyo> \o/
<bac> anyone up for a code review? https://codereview.appspot.com/9449044  it is my unbouncing of the textarea inputs branch.  will need QA to appreciate the fix.
 * bac -> dog2fort
<gary_poster> bac, yes? though if you just sent me one I didn't get it
<gary_poster> hey sinzui, you around?
<sinzui> I am
<gary_poster> hey sinzui.  I'd like to mark bug 1178462 as high for GUI while not marking it high for you all.  Basically, we have committed to delivering it for 13.10
<_mup_> Bug #1178462: Can't drag a charm from the charm browser sidebar to the main canvas <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1178462>
<gary_poster> but I don't want you to have a record that you need to implement it
<gary_poster> any ideas?
<gary_poster> move it to high and remove your tag seems like the right thing to me
<sinzui> gary_poster, I'm not against it. I think I originally set it medium because I understood it to be a new requirement.
<gary_poster> cool sinzui.  would it help you if I removed the tag, or don't bother?
<sinzui> I move a number of bugs to medium a couple of weeks ago to distinguish between what we want to do this month verses next month
<sinzui> yeah, remove the tag since we can have it hgh
<gary_poster> sone.  thanks sinzui.
<gary_poster> done I mean
<sinzui> fab, Thank you for raise this to my attention
<gary_poster> np
<gary_poster> oh sinzui, not being able to turn the left hand charm browser on will become a blocker for us next week.  I think we are only waiting on speed and reliability of manage.jujucharms.com.  Do you know yet when that will be ready?
<sinzui> I think it will.
<sinzui> We just need to complete the svg change
<bac> jujugui: i cannot use google hangouts (via the new icon) with my canonical account.  it hasn't been enabled.  has anyone else seen this regression?
#juju-gui 2013-05-17
<bac> jujugui: anyone have time for a review: https://codereview.appspot.com/9449044
<gary_poster> bac I'll look at code
<bac> thanks gary_poster
<gary_poster> huh, that's interesting
<gary_poster> so when you focus on it you can see you have more room
<gary_poster> but normally it is compressed
<gary_poster> that seems nice on the face of it :-)
<gary_poster> bac do you want qa, or is code check ok?
<bac> gary_poster: luca has looked at it and liked it
<bac> gary_poster: qa would be swell if you have time to spin it up
<gary_poster> ok will check
<bac> gary_poster: it's pretty fun!  :)
<gary_poster> :-)
<gary_poster> bac. LGTM, qa good
<bac> thanks gary_poster.  just need one more jujugui review now... :)
<gary_poster> :-)
<benji> bac: I can.  Do you need QA too?
<bac> benji: nah.  i'll put up a branch for luca to look at
<bac> benji: *finally* got that lp2kanban branch landed.
<gary_poster> bac don't forget that he knows how to start up a branch himself now
<benji> k, I'll look at it now
<gary_poster> he == Luca
<benji> oh really, what pushed it over the edge
<bac> gary_poster: oh, nice
<gary_poster> he got it set up at sprint
<bac> luca, can you have a look at the branch in review at https://codereview.appspot.com/9449044
<gary_poster> the fact that we have the sandbox as default now means it is easier
<bac> it is the auto-resizing-textarea-on-focus work i showed you in oakland.
<bac> i guess london is lunching
<bac> benji: i didn't put FileSaver in there.  i just made the Makefile aware
<bac> benji: so you're preaching to the wrong choir.  :)
<benji> heh
<bac> i'm not sure how it ever landed, tbh
<benji> even if you did, I wouldn't blame you, it's the /system/ man!
<bac> it was a mess and beautify threw up on it.  isn't 'make prep' run as part of lbox?
 * bac tunes .procmailrc...again
<gary_poster> bac, benji, app/assets/javascripts/ is where we are supposed to put our vendor imports that don't have npm sources, as established from before we joined the project.  It also has our code that we want to open source.  Are you advocating separating them, or something else?  FWIW, .lbox.check runs make check, which runs  "lint test-prod test-debug test-misc" so if lint is ok then it will land.  beautify is only suppos
<gary_poster> ed to fix what the closure linter would complain about...ah, and the linter honors LINT_IGNORE
<gary_poster> where the beautifier ignores it
<gary_poster> so that's the diff
<gary_poster> not sure why we have that diff
<gary_poster> but anyway...please make a card for something you think we should improve :-)
<benji> right, my contention is that putting dependencies somewhere other than under app/ would be an improvment
<benji> I
<benji> will make a card now
<frankban> quite impressive: http://thomasstreet.net/blog/spreadsheet.html
<benji> so many cards in the "Discuss" slot
<gary_poster> that's because we haven't discussed for three weeks :-/
<gary_poster> and we are missing two people today, both of whom should be a part of some of these discussions
<gary_poster> frankban, yeah, angular looks pretty cool to me on the face of it
 * benji adds a "Discuss why we haven't discussed things in the Discuss lane" card.
<gary_poster> :-P
<gary_poster> we had a sprint!
<frankban> benji: I see you have two very similar discussion cards: either my board is broken or you really really want to reduce noise emails
<gary_poster> heh
<benji> heh
<benji> that might be from a board hiccup; I'll fix it
<luca> bac: just back from lunch, I'll check it now
<bac> thanks
<gary_poster> eek
 * gary_poster realizes we have no licensing whatsoever
<bac> who has no licensing?
<gary_poster> juju gui
<bac> you mean in the code?  we've got GPL3 listed on LP
<gary_poster> yeah, the code :-)
<gary_poster> I think we are should be using AGPL
<gary_poster> hatch, Makyo are event-tracker.js and unscaled-pack-layout.js in the assets/javascripts folder ours, or taken from somewhere?
 * gary_poster wonders about putting licensing in handlebars templates, and really doesn't want to.
<luca> successfully branched my first branch. I'm gonna bzr the pentagon now. Eat it!
<frankban> bac: thanks for the review!
<frankban> guihelp: anyone want to take another look at a quick Python branch? https://codereview.appspot.com/9464043
<gary_poster> luca, lol
<luca> gary_poster: :)
<bac> luca: \o/
<benji> luca: the guy who "owns" the nick "luca" has been away for 7 weeks, when he is gone for 10-15 weeks the ops will give it to you if you ask nicely (then you won't have to be luca__________________ any more)
<luca> benji: interesting, it's annoying to have the password thing pop up hehe
<bac> frankban: looking
<gary_poster> sadly, the guy who owns "gary" logs on frequently :-P
<bac> frankban: doh, that's your same branch.  nm.
<frankban> hatch: hi, do you have a minute for a quick call?
<hatch> sure one minute
<bac> benji: i was able to get twitter to give me 'bac' since some dude in japan hadn't used it in a few years.  i doubt they do that anymore.
<bac> it's a bit of a curse, though
<gary_poster> frankban, after that, please ping me for possibly a slightly longer call :-)
<benji> heh
<hatch> frankban: guichat?
<frankban> hatch: sure
<frankban> gary_poster: ack
<gary_poster> thx
<bac> huh, teknico landed branch rev 666 yesterday and no one noticed
<Makyo> gary_poster, unscaled-pack-layout is D3 modified for our purposes.
<gary_poster> ok thanks Makyo 
<Makyo> gary_poster, Also, I tried to land the remove annotations branch last night, but every time I merge with trunk, it wipes out all of my changes, like it's resolving every merge with --take-other
<gary_poster> weird!
<Makyo> Wondering if that's because the MP has already been marked as merged?
<gary_poster> maybe but I doubt it.  You can change the MP status manually yourself to check though, Makyo 
<Makyo> gary_poster, alright, that's what I was going to try this morning.  If not, I'll try a new branch.
<gary_poster> Makyo, yeah, cool, that was my next suggestion as well.  You could try a new branch and manually merging in the old one to see if it works
<hatch> yay no more appcache!
<gary_poster> :-)
<hatch> I'm surprised that google didn't release any new hardware at io
<frankban> gary_poster: ready in the usual place
<hatch> the new hangouts shows me that gary_poster and frankban are currently in a hangout and that I can join :)
<bac> gary_poster: just curious why you didn't do a single line like (C) 2012-2013 for the headers
<gary_poster> bac, because of https://sites.google.com/a/canonical.com/legal-services/software-ip : see the end of the "Source Code" section of "Notices for software and documentation"
<gary_poster> IOW, I have no idea, just trying to follow their instructions
<bac> gary_poster: their instructions don't give a multi-year example.  on LP we used a range, which i think is acceptable.
<gary_poster> bac, oh, I was misreading "When modifying an existing file, if your changes are substantial enough, add a copyright line at the top of the file, after any existing copyright notice:"
<gary_poster> they were talking about files from other sources
<gary_poster> ok, I will switch to 2012-2013
<Makyo> Gah, finally. Had to recreate changes by hand, since trying to merge old branch into a clean branch of trunk gave me "Nothing to do."
<hatch> looks like CI had a canonistack error, anyone logged in to refire?
 * hatch fired off another
<gary_poster> jujugui call in 2.  please update kanban asap
<hatch> CI timed out.....firing again :/
<hatch> they are runnin gnow
<hatch> installing ubuntu on google glass is so cool
 * hatch wonders if it also runs steam
<hatch> ;)
<hatch> gary_poster: doing this work I have noticed that we have a :gui:/charms view - is this supposed to be here? I haven't even heard of this section until now :)
<gary_poster> hatch, not sure on call will ping
<hatch> alrighty
<gary_poster> hatch I think the service charm tab links to that, yeah?
<gary_poster> we want it for now, but not for long
<hatch> negative - it looks like it's a place to search for charms
<gary_poster> I think the inspector will have a :gui:[service name]/charm tab.  oh, really?!  hah.
<gary_poster> um, hatch...yeah, let's rip it out.
<gary_poster> :-)
<hatch> consider it ripped!
<gary_poster> :-) thanks
<hatch> I'll do that in a separate branch
 * gary_poster runs to go get lunch before our call
<gary_poster> good idea
 * bac has head-ache.  lies down.  bbiab.
<Makyo> gary_poster, got the N10 today, do I need to let anyone know?
<gary_poster> Maybe reply to the person who sent and confirm?
<bcsaller_> benji: sent some notes about the mem leak you're fighting, I think we have a test case already that can help show the issue 
<benji> at first I though I sent notes, then I though I was being asked to send notes, and then I relized: I have been sent notes
<bcsaller_> suddenly I feel less helpful
<bcsaller_> and more confusing
<benji> communication is hard
<bac> gary_poster: do you have any additional info on the temporarily missing endpoints card?
<gary_poster> bac on call will be with you soonish and can talk then
<bac> ok
<gary_poster> bac guichat?
<bac> sure
<bac> gary_poster: i see your frozen head
<gary_poster> bac, could you give me your appspot review of https://codereview.appspot.com/9499043 (you already gave me the MP +1, thank you; the appspot change has the 2012-2013 change)
<gary_poster> jujugui, could I please have one other review of https://codereview.appspot.com/9499043 ?  It adds AGPL to everything, so it is gigantic and mechanical
<hatch> lol wow
<hatch> yeah I can do it
<gary_poster> thank you :-)
<hatch> done!
<hazmat> gary_poster, AGPL?
<hazmat> gary_poster, its distributed by usage.. so why not GPL?
<benji> as I understand it the reason prime reason is because juju-core is AGPL
<benji> plus, we may have non-web-app bits soon, so those aren't distributed in order to use them
<gary_poster> thanks hatch
<benji> bcsaller: question: I am seeing a model in more than one model list (as returned by the model's .lists() method), all of the lists are "serviceList"s but as far as I can tell only one serviceList is created and it lives in the Database object (app/models/models.js:626).  Can you confirm or deny my reading of the code?
<bcsaller> benji: is this with fakebackend or no?
<benji> bcsaller: improv
<bcsaller> benji: fakebackend would have its own database, but sharing there would be an issue, ok reading
<benji> well, I just half-answered my own question; I added an intitialzer method to ServiceList with a console.log() call and I am seeing many being created.
<benji> any idea why?
<hatch> bcsaller: io over?
<bcsaller> hatch: there are some coding labs now
<gary_poster> hazmat, my thinking was what benji said, plus we effectively serve these from a server to actually be useful.  that's maybe the weakest argument.  I also didn't feel that GPL was any advantage of choosing GPL over AGPL.  WDYT?
<bcsaller> benji: console.trace() :)
<benji> oh, bcsaller: you're not really here; don't feel compelled to listen to me ;)
<hatch> bcsaller: ahh, not partaking in any?
<bcsaller> hatch: I did some but taking a break now, days of presentations is draining for me 
<hatch> yeah you can really only absorb so much
<hatch> brain work is exhausting :)
<hazmat> benji, gary_poster, i guess given the tie in to juju-core its reasonable.. just that its always been unclear to me where the boundary of AGPL breaksdown.. its code run by the browser, so does the browser now need to be opensource AGPL compatibile to be accessed legally.  ie where does the chain end.
<bcsaller> thats like saying an open source kernel makes all code it runs open source 
<hatch> I like that idea
<hatch> to the courts!
<gary_poster> hazmat I'm with you in spirit that I don't find the AGPL's distinctions clear with JS apps in particular, though I don't think people would bother to try to argue that AGPL went as far as your example.  From the perspective of the company, though, I thought going for the more restrictive license was a good starting point.  I'm asking our lawyers about whether I need to worry about collecting user data, so I can ment
<gary_poster> ion that on the way
<hatch> bcsaller: did you happen to catch any talks on Dart? It's always interested me...
<bcsaller> hatch: I didn't but I did see some good web dev talks in general
<hatch> cool - a lot of the talks are online already so this weekend might be a remote io weekend :)
<hatch> Makyo: is there a reason why you are hanging the flags off of the window object without any namespacing?
<hatch> seems like it should be (at least) jujuFlags
<hatch> or are we not concerned about clashing?
<hatch> in this instance
<hatch> is this an issue? /:gui:/service/memcached/:flags:/foo becomes /:flags:/foo/:gui:/service/memcached/ when using the built in url parser
<hatch> should we put a special case in there to keep the flags namespace at the end instead of alphabetical?
<hatch> also when navigating to / the flags namespace is removed - the properties are still saved so it should still work but it may not be clear to users
<Makyo> hatch, sorry, was dogwalking, should have said.
<Makyo> hatch, flags is on window for some reason I don't really remember that we glossed over at the sprint.  I'll try to think back to it and ask around, and we can change it if we need down the road.
<Makyo> hatch, as for namespace order, so long as :flags: only gets /foo, I don't see a problem, personally.
<Makyo> hatch, the last might be an issue, but should be relatively easy to change if so.
<hatch> alrighty - I'm just implementing stuff with flags right now and those are the things I came across so far
<hatch> da na nu na nu inspector widget da na nu na nu u uh unnnnn
#juju-gui 2013-05-18
<fwereade_> BradCrittenden, do you know offhand whether the GUI makes use of the magical NumUnits conversion in ServiceDeploy?
<fwereade_> BradCrittenden, ie, if you request 0 units, you get 1
<fwereade_> BradCrittenden, because I'm pretty sure this is crack, and I'm about to kill it
<BradCrittenden> fwereade_: and a happy saturday morning to you!  :)
<bac> fwereade_: no, the GUI will always make a reasonable request
<fwereade_> bac, awesome, tyvm
<bac> fwereade_: so you will return an error if 0 requested?
<fwereade_> bac, I *think* it's legitimate, if odd -- there's nothing inconsistent about state if we honour that requst
<fwereade_> bac, apart from anything else, you always get 0 units if you deploy a subordinate service
<fwereade_> bac, I could maybe be convinced to error on 0, but it feels like extra code for little benefit
<fwereade_> bac, medium-term I don't think that ServiceDeploy is sane anyway
<fwereade_> bac, "deploy" is a ui nicety only
<fwereade_> bac, it's at last 3 conceptually distinct operations
<fwereade_> bac, add-charm, add-service, add-units
<fwereade_> bac, (and add-units is questionable anyway as you know)
<bac> fwereade_: the case for subordinates was not considered for requesting 0 units.
<fwereade_> bac, I can't remember offhand if we error or if we ignore that in Conn
<bac> the requirement we were working with was that a deployed service had to have >= 1 unit.
<fwereade_> bac, I'm pretty sure we barf in cmd/juju if -n > 0
<bac> so setting the number of units for a running service had that restriction too as that would effectively remove the service.
<fwereade_> bac, my mental model is that a service can legitimately exist without units; I accept that's not a user-centric perspective but I think it's the job of the CLI/GUI layers to enforce that
<fwereade_> bac, does that sound reasonable?
<fwereade_> bac, (whereas the api and state layers should be concerned with internal consistency, and make every attempt to satisfy client requests that don't break that)
<fwereade_> bac, (there's some tedium in that the outer layers may also want some sort of consistency checks if only to save on pointless roundtrips, but that's just a performance optimization)
<fwereade_> bac, if you're around, how about magical inference of service name from charm name in ServiceDeploy? I'll be making a missing service name an error, I think
#juju-gui 2014-05-12
<huwshimi> rick_h_: So if we don't yet have the hardward info we should say something like "Hardware info unavailable"?
<rick_h_> huwshimi: yes, that's a card I think
<rick_h_> huwshimi: I think "Hardware details not available" if that'll fit
<huwshimi> rick_h_: OK, I'll do that as part of the token styling branch.
<rick_h_> huwshimi: thanks
<rick_h_> kadams54: did you put up your branch?
<rick_h_> ok, night all see you tomorrow
<huwshimi> Night
<kadams54> huwshimi: Just landed https://github.com/juju/juju-gui/pull/305 after working through some merge issues. Turns out we had quite a bit of overlap in the code we were working on.
<kadams54> Er
<kadams54> It's not landed
<kadams54> Ready for QA :-)
<huwshimi> kadams54: Ah, I'll take a look
<kadams54> Bah, stupid lint
<huwshimi> :)
<rick_h_> morning party people
<huwshimi> rick_h_: Good morning :)
<rick_h_> huwshimi: still around? morning man
<huwshimi> rick_h_: Just been out and got home
<rick_h_> huwshimi: very cool, thanks for the work last night. Will start going over the branches and qa'ing soon
<rick_h_> after the coffee brews
<huwshimi> :)
<huwshimi> rick_h_: I saw you closed that branch. My only concern is that we will be showing something that doesn't exist, and may not ever exist (the search for example looks to have moved in more recent wireframes). No harm in leaving it there I guess though.
<rick_h_> huwshimi: right, it'll only be for Mark S's demo portion. We won't release it as is for now. It's behind the feature flags as well
<huwshimi> rick_h_: Yep, np
<rick_h_> huwshimi: I think it's safe to leave for now and we'll work on that as we finish MV and release it from the feature flag
<huwshimi> sure
<frankban> rick_h_, huwshimi: morning, I need two reviews for https://github.com/juju/juju-gui/pull/309
<rick_h_> frankban: sure thing
<frankban> rick_h_: thanks, this is a required change before placeUnit
<huwshimi> I'll do a QA and then I need to sleep :)
<frankban> huwshimi: heh, thanks
<rick_h_> huwshimi: thanks and get some rest
<huwshimi> It's not late, I'm just jet-lagged still :)
<rick_h_> frankban: the hideChangeDescription is done in the bar itself next to the counter. Originally the branch worked: 
<rick_h_> "Drop a service, the bar would show "1    Added service XX      Deploy"
<rick_h_> and then after 2s it would hide the "Added service XX" part
<frankban> rick_h_: uhm, it does not work in trunk
<rick_h_> yea, something has been broken along the wya
<rick_h_> the count isn't there
<rick_h_> ant's branch added this work and I qa'd it originally
<frankban> rick_h_: and the change description hides
<rick_h_> I wonder if someone's rebase/merge conflict caused issues and it got lost
<frankban> :-/
<huwshimi> rick_h_: I'm not sure if you saw my email about the summary "No uncommited changes" state being related to something there
<rick_h_> https://github.com/juju/juju-gui/pull/288
<rick_h_> huwshimi: it is 
<rick_h_> huwshimi: well it's all related
<huwshimi> rick_h_: I think the timeout is applying to the wrong element
<rick_h_> huwshimi: right, and it looks like we're missing some code/elements
<huwshimi> yeah
<rick_h_> huwshimi: from that pull request ^
<rick_h_> so will have to diff and pull that back together
<huwshimi> rick_h_: I saw it working at some stage though
<rick_h_> huwshimi: yea, same here
<rick_h_> frankban: :+1: on your branch
<frankban> rick_h_, huwshimi: thank you!
<frankban> rick_h_: so the current plan is: now we call add_unit when a service is deployed: we should prevent the ECS to really add that unit if it's not placed. When we drag the unit we call env.placeUnit(ghostUnit, toMachine), and at that point in some way the add_unit ECS call is activated, with the hooks to add the unit to the right machine. Correct?
<rick_h_> frankban: I thought add_unit had to add that unit so that we could search for unplaced units using the filterByMachine(null)?
<rick_h_> frankban: I see though, you mean to not actually add it to the ecs at that point though
<rick_h_> but it's in the db
<rick_h_> frankban: so in my head it was added to the ecs and db on add_unit, but with no machine assigned. When placed, it would update the model to have the right machine info and make sure the ecs for it was updated. 
<frankban> rick_h_: we can add the unit to the ECS and then placeUnit modifies the record
<rick_h_> frankban: but your way sounds ok as well
<frankban> rick_h_: both work well for the demo, the issue is the following: with my branch, we call add_unit after deploy, and that reflects our intent. Then we have an unplaced unit. The user switches to machine view, and she can 1) place that unit or 2) leave that unit in the unplaced column. Then she hits deploy. If she placed the unit, the intention is clear: she wants the unit on that machine. If the unit is still unpla
<frankban> ced, then I guess the intention is to avoid adding the unit i.e. "I want to just keep this unit, commit my current changes, and then I will place this unit later". The current behavior is instead: this unit is unplaced, but is registered to be deployed, I'll create a new machine to host the unplaced unit.
<rick_h_> frankban: yes, that's why I'm ok with that. It's a running question we need to go through with design on how to handle unplaced information at deploy time
<rick_h_> frankban: luca has provided feedback that they want to 'try it out and see' in order to help define how that interaction works
<rick_h_> frankban: it could just be ignored, as you suggest, or an error in the summary directing you to go back and place. 
<frankban> rick_h_: sounds good, new machines for unplaced units is a simpler story for us
<rick_h_> frankban: in which case we'll also need some way to 'destroy' an unplaced unit
<frankban> rick_h_: so yeah, place unit should just change the unit record in ECS
<rick_h_> frankban: but I definitely understand your concerns. hatch and I have mentioned them to luca/design. 
<rick_h_> frankban: ok cool. Thanks
<rick_h_> jcsackett: around this morning? 
<rick_h_> poor poor CI is getting a workout this week
<rick_h_> ok, think I've reviewed and caught up with things atm. Going to go about that coffee and breakfast now
 * frankban lunches
<huwshimi> rick_h_: I figured out what was going on with the deployer bar, just pushing a branch
<rick_h_> huwshimi: ok cool, if you've got it working then put your head on the card I assigned JC please and I'll take a look in a few and work to get that landed as well
<huwshimi> rick_h_: Np, just running tests.
<huwshimi> rick_h_: It's ready for review/qa. I'm heading to bed :)
<huwshimi> Night all
<rick_h_> huwshimi: night!
<rick_h_> frankban: looks like conflicts hitting between you and huw there. Sorry about that. 
<rick_h_> bac: morning
<bac> hi rick_h_
<rick_h_> frankban: looks like a small one in the handlebars template 
<rick_h_> -         <h2 class="title">These changes will be deployed to: {{ machineName }}</h2>
<rick_h_> +         <h2 class="title">The following changes will be deployed</h2>
<frankban> rick_h_: looking
<frankban> rick_h_: shipit again?
<rick_h_> frankban: just delete the comment "merge request accepted" and it'll repick it up
<frankban> rick_h_: ok thanks, maybe we should add instructions to the Build failed message
<frankban> rick_h_: landing again
<rick_h_> frankban: definitely. I honestly thought we did have some notes in there. 
<rick_h_> frankban: heh yep missing that step around everything else in https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst will add it
<jcsackett> morning all.
<rick_h_> morning
<bac> hi jcastro
<bac> hi jcsackett
<jcsackett> i'm used to getting pinged when people wanted castro; haven't seen him get pinged when people meant to ping me that often. :p
<bac> all nicks in a channel should be unique to the first two characters
<kadams54> Morning all.
<jcsackett> morning, kadams54.
<kadams54> I've got a YUI question. I see Y.Event.EventTracker being used all over in our code, but I can't find docs for it. I don't even find it in the yui3 codebase.
<jcsackett> kadams54: one sec.
<jcsackett> kadams54: app/assets/javascripts/event-tracker.js
<bac> rick_h_: i've tested local charm ingestion with the git ghost charm.  it works as expected.  i'm going to write a doc to go along with it for the handoff.
<hazmat`> rick_h_, local charms in bundles with drag and drop onto the gui.. workable?
<hazmat`> rick_h_, basically going to pre-load the local charms into the environment.. that should work?
<rick_h_> hazmat`: I thought that didn't work because of the revision stuff
<hazmat`> rick_h_,  tbd.. its deterministic if you have an env reset.. its always revision file in the charm +1.. i was hoping to get away with no revision.. but that's probabably hosed.. i had a branch for p8 demo where i had deployer probe for the high rev on the local charm known to th eenv
<jcastro> hazmat`, if there's a livestream from the demo can you ask someone onsite to send the link to us so we can watch it?
<hazmat`> jcastro, i'm busy in the demo room, missing keynotes.. should be linked from main ostack site
<hazmat`> jcastro, http://www.openstack.org/home/Video/
<rick_h_> hazmat`: sorry, phone call
<hazmat`> rick_h_, no worries
<rick_h_> hazmat`: honest answer is I'm not sure off the top of my head. 
<rick_h_> hazmat`: it's something we thought would work but ran into issues due to revisions. I don't recall if juju-core would/wouldn't deploy a local charm without a rev 
<rick_h_> hazmat`: there's something there. we tried it and ended up failing due to an assumption somewhere in the pipeline
<rick_h_> bac: can you make sure to send that doc/notes to hazmat` and james page please? They can make sure everyone is aware/has access to it if needed for demos
<bac> rick_h_: ack
<rick_h_> kadams54: morning, I think huw and frankban have found the deployer bar issues you were looking into on your card?
<jcsackett> y'all did a ton of work over the weekend.
<rick_h_> yes, almost there
<kadams54> rick_h_: interesting. Did they commit a fix or just find where the bug was at?
<jcsackett> rick_h_: that unit deploy error without MV flag seems approachable this morning. shall i grab it or is there something else i should go after?
<rick_h_> kadams54: I think the fix is in, swimming atm with working on huw's update to fix the deployer bar notifications
<rick_h_> jcsackett: I think that's fine now
<rick_h_> jcsackett: frankban's branch that just landed I think fixes that
<jcsackett> rick_h_: dig.
<rick_h_> jcsackett: a verify/qa would be cool
<jcsackett> rick_h_: verifying now.
<kadams54> rick_h_: OK, cool. I like cards that get fixed in other people's branches while I sleep.
<rick_h_> kadams54: yea, give it a go and see if you can break it again
<rick_h_> kadams54: I know huw sent an email out on it and I think one of these had a fix in it, been 4 or 5 branches since I got up so getting a bit lost
<jcsackett> rick_h_: it appears to work on sandbox--was this observable there, or does it need a real env?
<rick_h_> jcsackett: yea, it was there
<jcsackett> rick_h_: also, how was camping?
<jcsackett> cool, i'm marking it with frank and throwing it into daily call.
<rick_h_> the campground was awful, the boy had fun, the wife and my verizaon bill didn't appreciate all the branches :)
 * jcsackett laughs
<rick_h_> but it was nice to get out of the house and sleep under the sky a bit
<jcsackett> well, at least your son enjoyed it.
<jcsackett> :)
<rick_h_> he loves camping, and they had lots of stuff for kids
<jcsackett> that's cool.
<rick_h_> morning hatch 
<hatch> morning
<hatch> how goes it?
<rick_h_> hatch: crazy wheeeee
<redir> what time is the demo:
<redir> ?
<rick_h_> redir: tues AM
<frankban> Makyo: ping
<Makyo> frankban, hi
<redir> ahh so one more day to polish it
<rick_h_> redir: yea, well make it work today
<rick_h_> and collapse :)
<bac> rick_h_: time for a quick chat?
<rick_h_> bac: definitely
<rick_h_> kadams54: looking at qa'ing your branch. It's all up to date per huw's feedback?
<bac> rick_h_: in standup
<kadams54> rick_h_: Yes, should be. Event bindings are now destroyed properly.
<rick_h_> kadams54: coolio will look after this call thanks
<frankban> Makyo: I noticed that the parentId when creating machines in ECS refers to the change key. for placeUnit, the caller must be able to retrieve the machine id. Also, AFAIK the same machine id should be used when creating the ghost machine in the db
<hatch> well this is interesting, I had almost exactly what frankban had in his place-unit branch, I just had one property switched around....lol damn
<Makyo> frankban, yes, I believe so.  ecs._translateKeysToIds will do that for any ECS record that has a keyToId method.  It's my understanding that the ID will have to be the key for the ghost machine, so long as validation allows that.  We do have other examples  of changing that such as https://github.com/juju/juju-gui/blob/develop/app/views/ghost-deployer-extension.js#L164
<frankban> Makyo: so IIUC we do something like machineId = env.addMachine(..) and then app.db.machines.add({id: machineId}) but at that point the machine token should end up with a very ugly name
<Makyo> frankban, hmm, correct... Unless we just use something like '(pending machine)' if the machine hasn't yet been created.
<frankban> Makyo: the alternative is to use a modelId in the options, so we create a new machine in the db with a customized name (e.g. new1), then call addMachines passing that id to the options
<frankban> Makyo: and then making the parent check using options.modelId
<Makyo> frankban, That makes sense, yeah
<frankban> Makyo: cool, I'll take a look
<frankban> hatch: what code are you referring to?
<hatch> the env.add_unit call and callback stuff in ghost deployer extension.js  I was using the service name not the ghost service id so I couldn't get it to work properly
<hatch> in hindsight ghostserviceid makes sense :)
<frankban> hatch: IC :-) unfortunate overlapping (but I guess it's unsurprising given the demo panic)
<rick_h_> hatch: are you in a good place to rebase and be able to look at the drag/drop? Or still need the placeUnit first?
<hatch> rick_h_ I think now with frankban's latest branch it should be good to go, I'm just running through kadams54 PR 
<hatch> then I can get on it
<rick_h_> hatch: rgr
<hatch> ohh you already shipped it
<hatch> lol
<rick_h_> hatch: heh, I added a card in the backlog to follow up on your comments
<rick_h_> I went with huw's review and qa plus I did a qa to make sure it merged cleanly still and did shipit, but your feedback is valid and will be followed up on
<hatch> comingsoon is broken
<hatch> http://comingsoon.jujucharms.com/:flags:/il/mv/
<hatch> changeset count is in the header
<rick_h_> bah
<rick_h_> lol
<bac> frankban: the demo needs to use quickstart.  where is the best place to get it? trusty repo or some PPA?
<rick_h_> bac: the ppa, I don't know that trusty has been updated for the bug fixes yet
<frankban> bac: juju/stable ppa
<bac> ty
<frankban> bac: what do they use quickstart for?
<bac> frankban: deploy charmworld
<rick_h_> hatch: can you try a local copy? I wonder if this is coming soon css issues
<hatch> no it's in develop
<Makyo> rick_h_, it's in trunk.
<rick_h_> hatch: I don't see what in the CSS is making that happen
<rick_h_> ok thanks :)
<hatch> it's not css, it's markup
<hatch> the changes button needs preventDefault on it as well
<hatch> because it's an A it breaks the url
<rick_h_> gotcha
<hatch> I'm just going to sit back and pretend I've never said anything about using anchors
<hatch> ...
<hatch> lol!
<rick_h_> well it's incomplete features anyway. So not fair 
<hatch> there is actually a full deployer bar up there
<hatch> it's really broken now
<hatch> a bisect is probably necessary here
<rick_h_> yea, looking. It's been a mess. It worked, then got broken, then huw fixed it, and I in qa tweaked it, and not it's very broken
<rick_h_> so bisect won't help a ton as you'll find it's been broken for a while in a bunch of branches.
<hatch> oh darn!
<rick_h_> https://github.com/juju/juju-gui/pull/288 is the original working branch
<hatch> ohh that's a lot of changed files heh
<rick_h_> icons mostly
<hatch> ok I'm going to get my branch landed first
<hatch> oh yay my keyboard backlight just stopped working
<hatch> F^&*^&* Apple
<jcsackett> rick_h_: can you chat for a moment?
<rick_h_> jcsackett: sure thing
<jcsackett> rick_h_: https://plus.google.com/hangouts/_/g3hgvsy4smtzi2x6dptuesyplya?authuser=2&hl=en
<rick_h_> jcsackett: https://github.com/juju/juju-gui/pull/307
<rick_h_> hatch: jcsackett is going to look at that
<jcsackett> ...the horror, the horror. :p
<rick_h_> hatch: some cross between ant/huw/me made something wonky
<Makyo> jujugui I'm on the deployer bar thing.
<jcsackett> rick_h_: ^
<rick_h_> Makyo: ok cool then
<jcsackett> right, back to figuring out what to look at. :p
<rick_h_> Makyo: so you're two birds one-stone there Makyo ?
<Makyo> rick_h_, Looking at the card, I'm not sure how much still applies.  I can't find that text in my QA so far, but a lot has changed.
<rick_h_> Makyo: yea, that text was replaced in a drive by
<rick_h_> Makyo: there's the current issue of two bars (top/bottom) and there's no support for add machines to the list of messages/summary
<Makyo> rick_h_, okay.  I'll add that to this card and go through the rest of the list.
<rick_h_> Makyo: the icons show now, that was hatch's attempt to avoid collisions
<rick_h_> Makyo: so updating the card for the two items remaining
<hatch> yeah I borked that
<hatch> but I think that's all fixed now
<rick_h_> yea, all good
<rick_h_> as long as we all ack you can only have one unit of any service in ghost lol
<hatch> Makyo when following your QAsteps.js are we supposed to get ghost machines?
<hatch> rick_h_ haha, this demo better be very scripted :)
<rick_h_> hatch: trying to work on that for sure
<Makyo> hatch, all my branch did was ensure ECS called addMachines properly; no UI
<jcsackett> Makyo: so to be clear, you're handling the deployer bar rendering goofily up top?
<hatch> Makyo ahh ok cool, I've just been using those steps to qa other stuff and was curious
<Makyo> jcsackett, Yes, if that's alright.
<rick_h_> jcsackett: so there's some qa work or looking at the polish cards, or helping pair with anyone and helping to do reviews/landings as they come up
<jcsackett> rick_h_: dig.
<jcsackett> jujugui: who needs PR/QA? i appear to be super free.
<rick_h_> I've got to start work on the demo script and notes. 
<rick_h_> jcsackett: so I think we're all set atm, but hopefullyu will have some coming down the pipe 
<rick_h_> kadams54: did you dupe the issue in your card?
<rick_h_> kadams54: or is that all set?
<hatch> jcsackett you can go through the codebase with rubber gloves and some solvent to clean up all the new tech debt
<hatch> haha jk it's actually not that bad
<rick_h_> hatch: heh, save that for tomorrow
<rick_h_> there will be a "great post-demo audit!"
<rick_h_> but not today
<rick_h_> enough moving parts atm
<jcsackett> i'm looking at the two polish cards, and will be on interrupt for PRs and QA.
<kadams54> rick_h_: well, yes, it seems to be fixed. However I'm seeing some other odd behavior.
<rick_h_> kadams54: ok
<rick_h_> jujugui call in 5
<kadams54> Hmm, strike thatâ¦ I'm seeing "no uncommitted changes" again. Different route to reproduce it though.
<bac> rick_h_: you know, it is a little redonkulous that we don't deploy charmworld with a bundle in real life.
<rick_h_> bac: +1
<rick_h_> bac: I've wanted to bring up with IS about managing a bundle file except they do the custom local charm stuff which bundles don't support
<rick_h_> bac: but for our QA env we want to setup I was looking at trying to create/use a bundle for that
<hatch> rick_h_ https://github.com/juju/juju-gui/pull/303#discussion_r12510773 are we not dropping on a readily created container for the demo? Can I instead just console.log the information - I'm scared to introduce a bug pre-demo by adding addMachine here
<rick_h_> hatch: we are dropping on a pre-existing machine to create a new container
<hatch> crap that is not what my code does
<rick_h_> so we have to addMachine with a real parent and make a new lxc container
<bac> rick_h_: the qa env is live.  i launched it.  next time i'll use a bundle rather than the deploy script orange wrote
<Makyo> Got the deployer bar thing; copy-paste problem.
<rick_h_> doh
<rick_h_> thanks Makyo 
<rick_h_> hatch: ok, well that's the demo. Existing openstack bundle, deploy nagios and co-locate it on an existing openstack service machine in a new lxc container
<hatch> yeah I must have misunderstood - I thought that it was being dragged to an existing container
<hatch> it's ok I just need to add drop support to the machine tokens
<rick_h_> hatch: it's the header that you drop on
<rick_h_> https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu#lh:null-06-machine.png
<hatch> no that creates a new machine/container, we need to create a new container in a machine
<hatch> so you drop on the machine
<rick_h_> you've selected the first machine, and drop on the header "Create new container" which we can hardcode to a new lxc 
<rick_h_> right, the grey means that the machine is selected
<hatch> oh boy
<rick_h_> and a big "Create new container" drop target
<rick_h_> jujugui hangout
<hatch> man where did I get the idea to drop on a container
<bac> jujugui: is this fatal state from 'juju status'?  agent-state-info: '(error: no instance types in us-west-2 matching constrain
<bac> ts
<bac>       "cpu-cores=1 cpu-power=100 mem=2048M root-disk=20480M")'
<bac> or will it continue with best attemp?
<bac> s/attemp/attempt/
<hatch> rick_h_ can you hop back in?
<hatch> just want to confirm the interaction for the drag and drop
<bac> frankban: do you know the answer to my question ^^^?
<rick_h_> hatch: joining
<jcsackett> jujugui: quick note, i have a doctor's appt in 2 hours--historically the appt is short, the time in the waiting room is long. i'll have wifi so still ping me and i can do PRs QA, but i'll be unable to do to hangouts for a bit then.
<frankban> bac: what machine is returning that error?
<bac> frankban: the one for elasticsearch and mongo.  is that your question?
<frankban> bac: yes, I am not sure you can recover that. IIRC resolved only works with units. So maybe destroy-machine and add another one?
<rick_h_> jcsackett: rgr 
<bac> frankban: ok.  i wonder which of those constraints is causing the problem...
<rick_h_> bac: I think the cpu-power or the root-disk
<rick_h_> bac: I'd drop those two and see what happens
<rick_h_> having both core and power I don't know makes sense, I think it's either/or but not 100% sure
<bac> huh, i didn't specify the cpu-power one.  juju must've helpfully added it for me.
<rick_h_> heh, you co cool juju
<bac> that helps me narrow it down, though
<kadams54> During standup today I realized that I may just be slow on the uptakeâ¦ is the "no inspector" thing the reason why the inspector no longer shows up when you deploy a charm?
<hatch> heh yes
<rick_h_> kadams54: yep
<rick_h_> last minute mandate that's falling apart in real life
<kadams54> Now things make sense.
<kadams54> Well, more than 30 minutes ago.
<hatch> :D
<kadams54> OK, so on my cardâ¦ should I update it to be specific to when undeployed (ghost) stuff is deleted?
<rick_h_> kadams54: definitely
<kadams54> Hmm, found another variation that may be more problematic for the demo.
<rick_h_> kadams54: k, good to know
<kadams54> If you drop a second charm, it triggers the message again
<rick_h_> 'triggers the message'?
<kadams54> Yeah, "no uncommitted changes".
<rick_h_> kadams54: call?
<kadams54> Sure
<rick_h_> kadams54: let's just hit the standup hangout
<kadams54> k
<rick_h_> wahoo! we have replication
<kadams54> rick_h_: Nice to know I'm less crazy-ish.
<rick_h_> yea, know that feeling
 * rick_h_ goes to take a lunch break
<hatch> hmm this interaction feels very clunky
<hatch> definitely need to get it infront of luca
<rick_h_> hatch: + 1, I think the manual clicky method will be the better placement story to be honest
<rick_h_> hatch: but Mark S wants the drag/drop GUI experience so we're doing that first
<hatch> yeah I just find I'm switching back and forth a lot, just doesn't quite feel right
<rick_h_> ok, now really to lunch
<hatch> lol
<Makyo> jujugui https://github.com/juju/juju-gui/pull/312 for some intermediary work on the UI polish
<jcsackett> Makyo: looking now.
<Makyo> Man, what happened to my pre-push hook? :(
<jcsackett> Makyo: i have had lots of trouble with pre-push hooks, of late.
<jcsackett> Makyo: thanks for updates, QAing now.
<Makyo> jcsackett, thanks!  We're in a hurry, but you're right about the test, I'm getting one in real quick.
<jcsackett> Makyo: thanks!
<frankban> it works! it fracking works!
<jcsackett> Makyo: you said note the machine key in your QA instructions...do you mean the "addMachines-$number", or what?
<jcsackett> frankban: \o/
<kadams54> rick_h_: I fixed the issue, but I also found this: http://pastie.org/private/hayd1bhhcmy81k4ycabfg
<hatch> ugh so many conflicts
<kadams54> rick_h_: With which I agree. Why are notifications hidden after 2 sec? Can we remove that?
<Makyo> jcsackett, yes
<rick_h_> kadams54: there's two moving parts here
<jcsackett> Makyo: ok, thanks.
<rick_h_> the notification is in the bar while it's closed state and disappears after 2s
<rick_h_> kadams54: that we want
<rick_h_> kadams54: it's got a side effect of doing something that clears the data in the summary
<Makyo> jcsackett, the parentId, until frankban's changes land, is 'addMachines-123' or whatever.
<rick_h_> kadams54: that's the bug 
<kadams54> Yeah, I fixed the side effect
<kadams54> But why do we clear after 2 sec?
<jcsackett> Makyo: oh, the whole string? not just the number?
<kadams54> Why not just leave the notify there until something else comes along?
<rick_h_> kadams54: ok, then yea. We do want that notification to fade away. It's a notification, it's temporal by design?
<Makyo> jcsackett, yeah, sorry
<frankban> jujugui: please take a look at http://pastebin.ubuntu.com/7453150/
<kadams54> It's too quick
<jcsackett> Makyo: no worries.
<frankban> jujugui: that shows the steps I am following with my current branch, and the API to use to place units and add ghost machines/containers
<frankban> jujugui: note that new1 is arbitrary
<kadams54> frankban: just discussing your comment here: http://pastie.org/private/hayd1bhhcmy81k4ycabfg :-)
<kadams54> rick_h_: The notification is often gone before I get a chance to read it
<rick_h_> kadams54: right, but it's ack'ing that you did something. I don't know that hanging around until you do something else is attractive either
<jcsackett> Makyo: to view change summary i click the "changes" thing in the left of the deployer bar, right?
<rick_h_> it's the old 'highlight in yellow the new item' trick
<rick_h_> jcsackett: no, click deploy
<rick_h_> jcsackett: that changes doesn't work yet
<Makyo> jcsackett, click deploy, it'll ask for a confi--yeah
<kadams54> Yeah, highlighting is fine if it's the same area on the screen that you're currently focused. The notifications are not. I'm OK with clearing them, but after 10 or 15 seconds at least.
<rick_h_> kadams54: we can add that as a discussion for follow up but with luca out and ant at a sprint I don't know we can get good UX feedback on the issue
<kadams54> Yup
<rick_h_> kadams54: cool, not sure on 10, but double it maybe? 
<kadams54> I'll leave frankban's comment in there for the moment
<rick_h_> k
<frankban> Makyo: time for a hand off call?
<Makyo> frankban, sure
<rick_h_> frankban: Makyo can I get a listening invite please? 
<frankban> rick_h_: sure
<rick_h_> kadams54: ok, so how about we double it and mark it as a UX item to chat bout
<rick_h_> lots of interactions we're not really thrilled about in this
<frankban> Makyo, rick_h_: see http://pastebin.ubuntu.com/7453193/
<kadams54> kk
<hatch> ugh merge conflicts are gona kill me
<jcsackett> Makyo: qa ok, thanks for the test, though i note we're skipping it?
<frankban> rick_h_, Makyo https://plus.google.com/hangouts/_/canonical.com/daily-standup
<rick_h_> hatch: :( was worried about that with the long running branch there this weekend
<kadams54> rick_h_: how do you want me to mark it as a UX item? Card? Just a grep-able comment?
<hatch> it's so bad....I've had to rebase it 4 times to develop already
<rick_h_> kadams54: make a card for now, put it in the needs specification section on the board
<hatch> 5 failing tests so I hope those aren't bad
<jcsackett> hatch: ugh, dude that sucks. i have felt your pain (and recently. :p)
<Makyo> jcsackett, there's a note hidden by the diff; the test passes in isolation, but the suite is poorly isolated; there's a card.
<jcsackett> Makyo: awesome. LGTM and all that jazz.
<jcsackett> you can :shipit: when you like.
<Makyo> jcsackett, thanks!
<jcsackett> ...i like that *as i typed that* i saw the shipit command come over the PR. :P
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/313 ready for review and QA
<rick_h_> kadams54: looking
<rick_h_> redir: let me know when you're free
<frankban> Makyo: https://github.com/frankban/juju-gui/tree/unit-placement
<Makyo> frankban, thanks
<redir> rick_h_: at your leisure
<rick_h_> redir: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<frankban> jujugui see you next Monday, have a great week!
<hatch> jujugui lf a review/qa on https://github.com/juju/juju-gui/pull/303 hurry before I have to rebase again! :P
<hatch> frankban cya! enjoy your holidays
<kadams54> frankban: have a good time!
<kadams54> hatch: looking
<Makyo> Restart for updates before I get rolling.
<kadams54> hatch: QA looks good to me
<hatch> nice
<hatch> thx
<kadams54> Review also looks good
<bac> hazmat`: ping
<bac> rick_h_: i've produced the doc and walked through it.
<rick_h_> bac: awesome! Can you email to hazmat`, james page, and copy myself on it please?
<bac> rick_h_: i want to do another run through to make sure it is clean.  there are some broken bits that have to be worked around.  will email this version out now.
<rick_h_> bac: thanks
<hatch> rick_h_ who's taking over frankbans branch?
<hatch> is that not something we need for the demo?
<rick_h_> hatch: Makyo has it now
<hatch> ok cool
<rick_h_> hatch: yes, it is. It's the last part after yours, to integrate them together
<rick_h_> hatch: so you and Makyo should sync up and help him find the points of connection once your branch hits
<hatch> will do
<hatch> it's being shipped now
<rick_h_> hatch: ty much sir
<bac> rick_h_: one oddity: setting the source for the charmworld branch in the bundle was not honored.  it deployed with trunk at lp:charmworld.  that complicates things
<rick_h_> bac: crap
<rick_h_> bac: odd, it looks like it should work http://bazaar.launchpad.net/~abentley/charms/precise/charmworld/trunk/view/head:/hooks/config-changed
<rick_h_> bac: can you check what juju get gives you?
<rick_h_> and see if the config change made it to juju-land?
<bac> rick_h_: it did not
<rick_h_> bac: if so, maybe try setting it to lp:charmworld and back. Perhaps it doesn't like the different source during install, but expects it to be a follow p change
<bac> i'll have to destroy the env and start over, which i will after lunch
<rick_h_> bac: well from the current env, can you change the source and see if it does it now?
<rick_h_> bac: or is it torn down already?
<bac> ah, i bet i need to include the revno in the bundle
<marcoceppi> rick_h_: why can't you remove a subordinate relation?
<rick_h_> marcoceppi: no idea. 
<marcoceppi> rick_h_: I'll file a bug!
<rick_h_> marcoceppi: juju says you can't or the gui says you can't?
<marcoceppi> gui, but we did it from cli and it worked
<rick_h_> marcoceppi: yea, file a bug please
<Makyo> hatch, running out to grab some food; don't have anything in the house.  Will be just a sec.
<Makyo> rick_h_, marcoceppi pyjuju wouldn't allow that because it meant modifying another service's unit.
<hatch> Makyo ok np, I'm judt going through code now
<rick_h_> Makyo: ah, good to konw
<marcoceppi> Makyo: figured it was something the the days of old
<rick_h_> bac: sorry, linked to an old version of the charm. http://bazaar.launchpad.net/~juju-jitsu/charms/precise/charmworld/trunk/view/head:/hooks/config-changed looks like it might even support a tarball source if the branch one fails
<kadams54> I think Jenkins needs some swap daysâ¦
<rick_h_> hah
<rick_h_> Makyo: ignore that landing failed email from ci. Looks like we raced to get it to rerun and it ran it twice
<kadams54> rick_h_: Looking for more work hereâ¦ maybe the card about adding icons to the container's parent?
<rick_h_> kadams54: sure thing
<rick_h_> kadams54: take a look and let me know if you've got any questions or need a pre-imp
<kadams54> rick_h_: Will do. I suspect I'll need a pre-imp. IIRC, the container's supposed to have a list of icons for all the services deployed on it. This card about updating that list when a new unit is added?
<rick_h_> kadams54: right, so when the db is updated, the machine token needs updating
<rick_h_> and it needs an uncommitted flag
<kadams54> k
<rick_h_> kind of like https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu#lh:null-22-new-container-unit.png but with the blue circle from https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu#lh:null-08-machine.png I think
<rick_h_> though that's not the important part for now
<hatch> yay branch landed
<hatch> no more rebasing
 * hatch jumps for joy
<rick_h_> lol
<kadams54> rick_h_: so this is for both the machine token and the container token?
<kadams54> \o/
<rick_h_> kadams54: so the container token should be updated as part of the interaction, but the machine token needs to be async updated
<kadams54> Ah
<kadams54> So add the unit to the container and then add the icon to both the container and the machine
<rick_h_> kadams54: well what'll happen in the future is that you drop on the new container, and you get a container token expanded asking you for a type and details
<rick_h_> kadams54: and then, after you click some confirm, the container, and unit get updated in the db.
<kadams54> And the machine needs to update as well
<rick_h_> kadams54: and the machine token that container is in, needs to be updated to show the new service it holds
<rick_h_> or will hold technically
<kadams54> k
<hatch> wow there have been a lot of chances to the ecs stuff
<rick_h_> hatch: yes, it's needed some extra support for the whole unit thing. It's really not written to be ghost-able nicely lol
<hatch> well the original plan had it use a persistent data store 
<hatch> but that was a lot of front loaded work
<hatch> so now we are paying for it
<hatch> should have just done the front loaded work
<hatch> I blame the demo
<hatch> :P
<rick_h_> which persistant data store?
<hatch> the one I was working on
<rick_h_> I mean just having persistent data doesn't get around needing to be able to tie units to services/machines and update them post-deploy in order?
<hatch> no but it would make going back and updating fields easier
<hatch> the execution stuff would still be complicated no matter what
<rick_h_> I don't know that it's 'hard'. We need some helpers to smooth it out, but the work that's there I think needed to be there. 
<rick_h_> things like placeUnit and addUnits and such help things stay up to date
<hatch> it's a pretty complicated problem
<rick_h_> definitely
<hatch> we are dealing with it on a case/case basisc
<hatch> which is fine
<rick_h_> I'll admit I was tricked by the fact that service/relation was simple and moved quickly
<rick_h_> and when we got to machine/unit things got a level more complicated
<rick_h_> but it was going to happen regardless. In fact, it's working around the data store (app.db) that's making this fun. 
<hatch> and it'll all be thrown out when core gets this....
<hatch> lol
<rick_h_> I don't know, we'll have to go back and add some stuff on creating names for multiple services, units, machines
<rick_h_> and keeping all that from conflicting, updating from deltas, etc
<rick_h_> all that work will remain regardless of if core does some of this or not
<hatch> we'll have to handle seamless interactions between deltas and env calls 
<rick_h_> yes
<hatch> for things like placing units on machines via the cli and gui
<rick_h_> but it's starting to get cool. 
<rick_h_> I so badly want my new container when I drop. :) this is going to be slick when it's released
<hatch> it'll probably be simpler to just drop all the functionality from the GUI and rely on core at that point.....but then we don't get it in the sandbox
<rick_h_> right, and we've got 4s lag 
<rick_h_> or sorry, deltas is a 10s thing
<rick_h_> the main watcher they use is a 10s cycle watcher
<hatch> yeah
<rick_h_> so I'm not sure how much we'll ditch. That's an awfully poor UX to have multi second lags
<hatch> yeah the ecs might have to move into the fakebackend
<rick_h_> we'll see. one step at a time
<rick_h_> we know they're not adding any of this in the current cycle
<rick_h_> and who knows next cycle
<hatch> hah probably not then either
<rick_h_> and we've still got bundle supports/etc we'll beat on this code a bit over the rest of the year
<hatch> yeah that one will be fun
<hatch> Makyo did you have a pre-imp with frankban about his prototype?
<Makyo> hatch, yeah
<hatch> it looks pretty good to me 
<Makyo> hatch, yep, going to get it cleaned up and such
<Makyo> Working on tests now
<rick_h_> Makyo: hatch jump on a hangout and pair up on the tests if it might help. It'd be good to have more eyes on it and such. 
<hatch> yeah I've been going through the code, I think after it's done Makyo  can give me a tour of how it operates
<hatch> it looks like it's pretty close to the original 
<hatch> with lots of forks coming out of it
<bac> compiz is eating my vm.  boo.
<hatch> rick_h_ so what else would you like me on for now?
<bac> rick_h_: thanks for the additional explanation to my email.  i assumed kapil and james knew what was going on demo-wise
<rick_h_> bac: yea, there's several forces going on there and not sure who knows what to be honest
<bac> well i hope they will hop right on it else we might have a stressful tomorrow
<rick_h_> hatch: it's all about this drop/deploy working. I'm not sure how far Makyo's branch goes
<hatch> ok - it should be adding the placeUnit functionality
<hatch> which needs to be added to the drop function once landed
<rick_h_> hatch: right, so there's probably some UI wiring to get the container token that needs to be in there
<hatch> one line change as I understand it
<rick_h_> hatch: and the clean up on deploy maybe?
<rick_h_> hatch: the uncommited css notifications perhaps?
<rick_h_> hatch: huw added methods for that, then those would need to be cleared on deploy
<hatch> these are the ones that show up in the deployer bar?
<rick_h_> hatch: no, the blue background on the container token
<rick_h_> and the new machine token, which we're not using atm for the demo
<hatch> oh ok, I was pretty sure the ghost machines/containers didn't show if they were ghosted
<hatch> confirmed
<hatch> so we should be showing those first
<rick_h_> sorry, you skipped a step on me, what now?
<hatch> if you go into the console and type 
<hatch> ecs = app.env.get('ecs');
<hatch> cb = function() { console.log(arguments); };
<hatch> app.env.addMachines([{}], cb);
<hatch> you don't get a machine listed in the machine column
<hatch> until you commit()
<hatch> uncommitted machines don't show up in the list
<rick_h_> hatch: ah, yea you should get a machine token that's in uncommitted state
<rick_h_> hatch: right, and they should
<rick_h_> hatch: because you might manually create a machine, make it a large one with 16gb of ram, and then place units on it
<hatch> did that ever work? Should I be looking for a bug or implementing new
<Makyo> Man, Francesco's smart.  I feel like I do something clever, then he just wafts through and clever turns into right.
<rick_h_> hatch: honestly, not sure. it's partially related to kadam's work of showing uncommitted units on a machine
<rick_h_> all that update the UI to match the db stuff
<rick_h_> Makyo: :)
<hatch> rick_h_ ok looking at the ecs stuff it looks like it's never worked
<Makyo> Tests pass, working on lint.
<hatch> it needs to do something similar to units being assigned
<rick_h_> hatch: ok cool
<rick_h_> Makyo: woot
<hatch> we need to create a machine in the db then delete it  when it becomes a real boy
<rick_h_> hatch: lol, pretty much. Or at least update the token with new data that will update the id and clear the uncomitted info
<hatch> I need to wait for  Makyo's branch to land because it touches the same code haha
<hatch> Makyo we can pair on this ^
<rick_h_> hatch: heh yea, well if he's at lint you're on deck for review and helping to complete the demo 
<rick_h_> :)
<Makyo> Yeah, 2 minutes or so
<Makyo> Then you can help me QA/.
<hatch> sounds good
<hatch> this machine view stuff is coming together really well
<hatch> it would be done if it wasn't for the ecs lol
<rick_h_> it's almost like we had a plan :P
<Makyo> Haha
<rick_h_> lol, changed my watch from C to F so it changed it from 24C to 24F
<rick_h_> so helpful watch face
<hatch> hahaha
<hatch> you should just live with C
<hatch> then you'll start using a base 10 measurement system
<hatch> you'll then wonder what have you been doing your whole life!
<hatch> and move to Canada 
<hatch> Celsius is a Canadian gateway drug 
<hatch> :P
<Makyo> hatch, https://github.com/juju/juju-gui/pull/314
<hatch> on it
<hatch> Makyo I feel like there were a lot of things added to the code and not a lot of tests
<hatch> these changes to the tests end up testing all the changes that were made?
<Makyo> hatch, a lot changed, vs. added.  That's fair, though, first pass was to get tests working.
<Makyo> hatch, PR was the best way for me to get it to you for QA, though.
<Makyo> (well, easiest, and I'm lazy)
<hatch> yeah ok that's fine - I just wanted to see if additional tests were still required
<Makyo> I'll see what I can do.
<hatch> code looks good, qa'ing
<hatch> Makyo I think your qa step docs are borked on line 7
<hatch> function() .... ?
<Makyo> hatch, those were copied from francesco, give me a sec.
<hatch> ohh ok I think it might be a bad line break then
<hatch> that should have said
<hatch> "ohh, I think it is a bad line break"
<Makyo> Yeah, copied plain text from a pastebin, sorry
<hatch> no problem, it worked but generated an error, trying again
<hatch> Makyo I get Error: attempted to place a unit which has not been added: mysql/0
<hatch> when running the placeUnit call
<hatch> unless the first step where it says 'deploy' doesn't mean 'commit' ?
<hatch> no it probably wouldn't
<Makyo> I'll take a look, see if you can do additional QA
<rick_h_> worked hedre
<rick_h_> here
<rick_h_> got the new unit in the changelog with machine and container
<hatch> there we go got it
<hatch> I was interpreting 'deploy' as 'commit'
<rick_h_> ah, yea no deploy is the service call that the ecs captures
<hatch> Makyo so are you adding the extra tests now or doing to do so in a follow-up?
<rick_h_> hatch: Makyo let's do follow up. We need to get this wired up and it needs to go through ci and land
<hatch> sounds good
<hatch> shipping
<rick_h_> added a note to add a card for updating with moar tests!
<hatch> moar tests!
<rick_h_> hatch: so are you going to look at then wiring this into your drop and removing the original unit token?
<Makyo> I was sitting down because I haven't yet today :P  I'll do further QA on real env.
<hatch> I would really love it if we had tests along side each file in the folder oh man that would be nice
<Makyo> But yeah, QA works for me in sandbox.
<rick_h_> Makyo: cool, definitely qa live env please. hatch can run with it for now to start the last card. I'm working on the docs and can help live qa
<hatch> rick_h_ first ghost machines need to show up in the UI
<rick_h_> hatch: they show up, just not as ghost
<rick_h_> hatch: and for the demo they'll exist
<rick_h_> make it deploy a bundle first, then drop on a container on a machine in the bundle
<hatch> oh ok then yes I'll hook up the drag and drop to deploy the unit to the newly created container
<rick_h_> hatch: thanks
<hatch> rick_h_ is someone doing a few dry runs on this first? :)
<rick_h_> hatch: that's why I want to get this working asap so we can start to
<rick_h_> hatch: yes, we'll be working on dry runs as soon as the drop of the unit works
<rick_h_> on lxc and ec2 and they'll have access to the hardware
<hatch> cool, ok I'll get on the drag and drop
<hatch> I've clicked that damn magnifying glass 100x today
<rick_h_> hatch: lol
<hatch> lol
<rick_h_> so I just downloaded the pdf
<rick_h_> and have it open in a pdf reader zoomed 
<rick_h_> much nicer
<rick_h_> hatch: or you mean the search button in the header?
<hatch> yeah in the header.....it reloads the page
<hatch> no prevent on it
<rick_h_> heh yea. land mines wheeee
<hatch> Makyo got a few for a hangout?
<Makyo> Sure
<hatch> ok sec creating
<hatch> https://plus.google.com/hangouts/_/7ecpj6sl0bvcknh7up5ivfta7s?hl=en
<hatch> Makyo thanks that was the trick, it appears to be working as expected now
<rick_h_> woot!
<hatch> ^ rick_h_  just need to remove the unplaced unit now
<rick_h_> yay, my tablet has shipped from delta. I'm very curious if it's the right thing I get back
<hatch> lol!!!
<hatch> it might be someone elses haha
<rick_h_> hah, I was getting worried that vegas was turning into a very expensive trip
<hatch> lol
<hatch> and you didn't even gamble!
<hatch> ok so we need a card to have containers auto-update
<rick_h_> hatch: rgr
<rick_h_> hatch: in the demo notes I have him go to service view to see the health bar and service and then click back
<rick_h_> hatch: to force a redraw of all the things and tie the stuff going on to what people are used to
<hatch> good call -  makes it look like it's not broken
<hatch> kehehehe
<rick_h_> :)
<hatch> ok unplaced units is not databound 
<rick_h_> hmm, should be. I thought it was added today
<rick_h_> kadams ^ bah how dare he not be here
<hatch> lol I just tried tab complete and was like NOOOOOO
<hatch> haha
<hatch> looking into it
<rick_h_> https://github.com/juju/juju-gui/pull/305
<rick_h_> heh, you reviewed it
<hatch> haha yeah - odd, if I deploy bundle, deploy postgres, place unit, view canvas, click back, unit is gone, but it's not gone after I place
<hatch> will investigate
<rick_h_> hatch: I think that unit you're placing isn't in the db, it's a copy?
<rick_h_> hatch: or does setting an attr not trigger the change event watched for?
<hatch> nope it's in there....working as it should
<hatch> that's my guess
<rick_h_> this.get('db').units.after(['add', 'remove', '*:change'],
<rick_h_> add works, maybe change isn't right
<hatch> ahh that's it
<hatch> change won't fire because they aren't models
<rick_h_> right
<hatch> they need to be revived, changed, then torn down
<hatch> ON IT!
<hatch> yeah fixed it
<Makyo> Just wanted to let you know, we're all counting on you.
<hatch> *that
<hatch> like a boss
<hatch> lol
<hatch> now to figure out why I don't have any icons
<rick_h_> lol
<rick_h_> jujugui I've got to go get my son from day care. I'll be back. I emailed the start of the walk through with notes. Let me know if anything doens't match up
 * rick_h_ is biab
<hatch> cya
<hatch> Makyo so the reason the icon doesn't show up is because the machine id on the unit doesn't get updated on commit
<hatch> and the filterByMachine doesn't match the machine ids 
<Makyo> hatch, that's when the callback is called; can the callback share part of the burden there?
<hatch> I think so, trying
 * bac walks the jojo
<Makyo> I need to go get the dogs as muddy as possi-er, walk the dogs, back in a bit.
<hatch> awesome - it now refreshes the container column when you drop the unit
<hatch> this is READY TO GO
<hatch> and full of ugly hacks
<rick_h_> hatch: lol
<rick_h_> hatch: documented hacks?
<rick_h_> and I'm back in case anyone needs anything
<hatch> that method is one big porn block
<hatch> (XXX's)
<rick_h_> lol
<hatch> :D
<lazyPower> \o/
<jcsackett> rick_h_: are the next cards still prioritized? deployer test isolation higher priority than containers updating?
<rick_h_> jcsackett: no, I've got to go through them tomorrow. 
<rick_h_> jcsackett: the tech debt will be priority missing tests, etc.
<rick_h_> jcsackett: and finishing the inspector left, which means finishing up my branch I put aside for now
<Makyo> Back, +mud
<rick_h_> jcsackett: I can toss a couple your way if you're looking
<Makyo> And bills.  Why I ever pick up the mail is beyond me
<rick_h_> Makyo: heh, yea. It's either spam or bills
<rick_h_> jcsackett: have an interesting one for you
<jcsackett> rick_h_: ok.
<rick_h_> if I can find the UX wireframes
<rick_h_> jcsackett: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1aHFtUE8zZTMzM0k
<rick_h_> jcsackett: card is assigned, listing out the changes when clicking on the number in the deployer bar corner
<rick_h_> jcsackett: let me know if you have any questions or want to pre-imp
<jcsackett> rick_h_: it's almost EoD. i'll explore the relevant code today and ping you first thing tomorrow?
<jcsackett> rick_h_: we've got everything that's needed for demo, yeah? or is this a demo thing?
<rick_h_> jcsackett: this is not a demo thing. hatch I think is finishing up demo and then we'll be qa'ing and I'll be updating the docs
<rick_h_> jcsackett: and I'll try to take time tomorrow to make heads/tails of the backlog of cards to make it through the week and we'll start our next 2 week iteration friday with planning poker
<jcsackett> rick_h_: ok. do you need any other eyeballs for that? 
<rick_h_> jcsackett: if you've got time/eyeballs happy to have them. Especially if you've got a working ec2 or other cloud environment to try it for real
<hatch> jujugui https://github.com/juju/juju-gui/pull/316 BOOM
<rick_h_> hatch: looking
<hatch> don't judge me
<hatch> :P
<rick_h_> hatch: Makyo I'll do LXC QA 
<Makyo> I'll QA in a real env
<Makyo> Oh, hah
<Makyo> Sure!
<rick_h_> oh...I'll judge...really judge
<hatch> aha
<kadams54> Too late - you're a Canadian.
<Makyo> I'll review etc.
<kadams54> That makes you polite
<Makyo> kadams54++
<rick_h_> Makyo: jcsackett it'd be cool if someone tested out ec2 or HP or something
<kadams54> A beer-drinking hockey fan
<kadams54> With a closet full of flannel
<Makyo> rick_h_, I have ec2
 * hatch doesn't like hockey
<rick_h_> Makyo: cool thanks
<hatch> at least not watching it
<jcsackett> forgot to ping earlier, jujugui: tiny PR https://github.com/juju/juju-gui/pull/315
<rick_h_> kadams54: got time to review ^ ?
<kadams54> yeah
<rick_h_> thanks
<rick_h_> oh the judging! :P
<rick_h_> hatch: it's not that bad, at least the parts 'fit' together and make sense I think
<rick_h_> but maybe I've been looking at too many branches of this stuff lately :P
<hatch> haha - yeah it works and all that - there is just so many better ways to do this :)
<rick_h_> hatch: well, but iteractions on the current idea I think. 
<rick_h_> more automation/etc
<hatch> yeah true true
<rick_h_> unless you have a plan that's a completely different path?
<hatch> no, originally I had a different plan but this path works just fine
<rick_h_> lol, we'll get your plan next time
<hatch> haha no biggy
 * hatch is being punished for the inspector debacle 
<rick_h_> lmao
<rick_h_> hey, I've worked hard to not have anything come across as punishment :P
<rick_h_> after all, still fighting state myself :/
<hatch> haha
<jcsackett> ...if you had to work hard to have nothing come across as punishment, that implies something *could* be thought of as punishment. :p
<hatch> haha
<kadams54> hatch: did you test this in Vagrant?
<hatch> I work in vagrant, so yes?
<kadams54> OKâ¦ seeing some funkiness and trying to rule out potential causes.
<hatch> I have to run test-server though
<hatch> it won't run through on debug in vagrant
<kadams54> Funkiness was resolved with make clean
<kadams54> You're off the hook ;-)
<jcsackett> `make clean` is magic.
<rick_h_> it's showing, you have to take a shower once in a while :P
<rick_h_> even spartans 
<hatch> haha
<kadams54> :-b
<bac> rick_h_: hey have you heard anything from our intrepid friends in ATL?
<rick_h_> bac: not a peep
<rick_h_> bac: not seem them active on irc
<bac> rick_h_: well, i've done about all i can without any participation/feedback
<rick_h_> bac: agreed
<rick_h_> bac: I think we call this mission accomplished, work on getting it in trunk from here. We've done what we can do to help them out
<bac> rick_h_: rt.  the process is a little clunkier than i'd like due to juju / quickstart / charmworld charm issues
<rick_h_> bac: true, but it's also a demo/technical thing. So not truly user facing/etc. I think we can afford a few rough edges. 
<rick_h_> bac: thanks a ton for getting that working. I think it'll be cool even beyond this demo to have that handy
<bac> rick_h_: sure, but the things i encountered are usability for the tool chain
<bac> rick_h_: what time is the demo?
<rick_h_> bac: which parts? I thought it was just the charm and the branch suport?
<rick_h_> bac: so the big one for Mark is 10:20 central I think
<bac> 'juju scp -r' doesn't work
<rick_h_> oh, yea I saw that conversation go by. 
<bac> config settings in a bundle are not being set by the charm when deployed with quickstart
<rick_h_> bac: right, we've got a bug to add that
<bac> that may be the charm's fault
<rick_h_> I think it's inthe maint. backlog
<bac> which? the config setting?
<rick_h_> well to provide a config.yaml override
<rick_h_> it should "just work" if it's in the bundle.yaml
<bac> oh, am i just stupid?  can the bundle only contain juju-level settings?
<bac> num_units, etc?
<rick_h_> bac: yep
<rick_h_> oh no, it can contain config
<bac> gah.  my bad.
<rick_h_> sorry, multi tasking, the bundle can contain config overrides I think
<bac> rick_h_: ok, well those aren't being respected, at least by this charm
<rick_h_> http://comingsoon.jujucharms.com/bundle/~charmers/mediawiki/6/single/#code
<bac> i'll sort it out tomorrow when i can talk to frankban
<rick_h_> bac: right, that might be a charm bug that it's not accepting the config change on install
<rick_h_> bac: well I think he's afk for the rest of the week. 
<rick_h_> bac: ^ shows the options: xxxx block passed from the bundle
<bac> ah, i didn't use the 'options' heading!
<hatch> rick_h_ how goes the lxc qa?
<rick_h_> hatch: working on it
<rick_h_> sorry, talking to others :)
<hatch> hah no problem
<hatch> jcsackett reviewed your branch
<rick_h_> hatch: the container didn't update for me on drop?
<hatch> it didn't render a new one?
<rick_h_> hatch: no
<hatch> ^ kadams54  did you have the same issue in qa?
<rick_h_> sec, will try another service
<kadams54> rick_h_ hatch I did have that issue, but that's what the clean fixed
<kadams54> http://cl.ly/image/0n1W1Z443K2c
<rick_h_> kadams54: well this is on a deployed service
<hatch> ohh - rick_h_  maybe make clean will work for you?
<kadams54> The container didn't update on drop and the list of unplaced units didn't update either
<hatch> ohh
<kadams54> Ah yeah
<kadams54> I was vagrant
<rick_h_> swapping to service and back worked
<rick_h_> and I didn't get a nagios unit. 
<hatch> so it doesn't actually work then?
<rick_h_> hatch: no, I hit deploy and it showed me the right stuff, but didn't create the unit. I do get the esrvice and the lxc container
<rick_h_> just unit-less in a real env
<hatch> :/
<hatch> can you put a debugger in go.js add_unit()
<hatch> see if it gets called?
<hatch> debugger/breakpoint
<rick_h_> Uncaught Error: attempted to place a unit which has not been added: 61439359$/0 
<hatch> what the....
<hatch> so there is clearly some difference on a real environment
<rick_h_> ok, so reload the browser window, nagios is there without any units. 
<rick_h_> trying to deploy wordpress
<rick_h_> oh, that worked now
<rick_h_> well the container updated
<hatch> lol
<hatch> the attempted to place error is from the placeUnit() call
<rick_h_> no errors this time
<hatch> ohh 
<hatch> nagios is a subordinate
<rick_h_> ran it with the debug toolbar open? 
<rick_h_> hatch: no, nrpe is, nagios is a server
<rick_h_> we picked nagios just because of that, it's a server with a web interface
<hatch> ohh ok
<hatch> hmm
<rick_h_> when I click on the wordpress in service view the inspector shows me "one undefined unit: 31706881$/0"
<rick_h_> and again, no units.
<rick_h_> ok, will try to debugger in placeUnit()
<hatch> the env needs to make the add_unit call for it to actually create the unit
<hatch> I'm wondering if any of this stuff was tested on a real env
<rick_h_> bah, compressed JS files fail
<hatch> it might just simply not work
<rick_h_> wheeee
<hatch> heh, switch the gui to debugger mode :)
<rick_h_> ok, will reload and watch the wss traffic
<hatch> I'm just updating/setting up my testing machine and then I'll be able to test it as well (assuming it all goes ok)
<rick_h_> hatch: yea, not seeing a unit call in wss
<rick_h_> {"Type":"Client","Request":"ServiceDeploy","Params":{"ServiceName":"mysql","Config":{},"Constraints":{},"CharmUrl":"cs:precise/mysql-44","NumUnits":0},"RequestId":19}
<rick_h_> {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"ParentId":"6","ContainerType":"lxc"}]},"RequestId":20}
<hatch> ok so basically that means that the lazyaddunit doesn't work
<rick_h_> yea
<rick_h_> something isn't right there
<hatch> while my machine updates....you can switch the GUI into debug mode in the charm and then put a debugger in _add_unit in go.js
<hatch> breakpoint*
<rick_h_> sec, just resetting env, have to get the boy some sort of food for dinner and brb. 
<hatch> yeah np
<hatch> rick_h_ in sandbox I put a breakpoint in _add_unit() in go.js and it was never hit
<rick_h_> hatch: k, makes sense then
<hatch> ^ Makyo  any idea what's broken here?
<hatch> I can step through the changeset execution
<Makyo> 1sec.
<hatch> just wondering if you might have any other insight :)
<rick_h_> hatch: I wonder if changing the model to assign the unit to a machine did something to get it not to be added?
<hatch> the command looks good
<rick_h_> hatch: does the lxc parent complete/hit the callback?
<hatch> just going to step through the commits
<hatch> watch the flow of it
<hatch> ok the addUnit call is never executed by the ecs
<rick_h_> the ghost deployer extension is supposed to addUnit when you drop the service
<rick_h_> ?
<rick_h_> so you have the call in the changeset, but it's not executed?
<hatch> correct
<rick_h_> ok, so that means something in the parent/etc setup is failing to hit the child
<hatch> service deploy and add machine commands are executed
<rick_h_> they're not parent/child
<hatch> _commitNext() is never called with the unit command
<hatch> the heirachy is properly built
<rick_h_> yea, something in the callbacks
<hatch> hierarchy 
<rick_h_> so this might be due to frankban changing the id from being the changeset id to the actual model id
<hatch> it's waiting for the level to be completed
<hatch> but it never is
<hatch> the addMachine callback is not returning
<hatch> so it's not triggering the level complete
<hatch> now....how to fix that
<hatch> heh
<Makyo> GUI can't load any charmworld assets: net::ERR_BLOCKED_BY_CLIENT - did something change on charmworld's side?
<Makyo> ditto assets.ubuntu.com
<rick_h_> Makyo: not that I'm aware of, was just doing it
<hatch> hmm it's working in the GUI for me
<rick_h_> Makyo: maybe you're falling into some ip addr black hole?
<Makyo> This is ec2
<hatch> did you open the ports?
<hatch> :)
<hatch> oh wait nm juju does that
<hatch> heh
<rick_h_> well it should be able to go out 
<rick_h_> and the client is doing it not the ec2 stuff
<Makyo> Wellp.
<rick_h_> http://stackoverflow.com/questions/22318119/i-am-getting-failed-to-load-resource-neterr-blocked-by-client-with-google-chr ?
<rick_h_> ad blockers enabled?
<Makyo> Damnit.
<Makyo> EFF's Privacy Badger was running./
<hatch> lol
<hatch> oh I think I found the bug
<rick_h_> good because my brain isn't up to following the callback levels atm :P
<redir> love it:) I have had to debug ghostery for the same reasons before Makyo 
<hatch> yep fixed it
<hatch> cleaning up then pushing
<rick_h_> woot
<hatch> rick_h_ Makyo  fix pushed plz try qa on a real env again https://github.com/juju/juju-gui/pull/316
<Makyo> Alright, on it.
<hatch> *phew* was REALLY worried there was an architectural bug introduced by something frankban did lol 
<hatch> I did not want to have to fix that tonight haha
<hatch> instead it was a bug I introduced....which is much more acceptable lol
<hatch> introduced? should have been protected against?....yeah the latter
<hatch> ;)
<hatch> doh, lint
<hatch> fixing...
<huwshimi> Morning
<rick_h_> just got a phone call from ramm
<rick_h_> promising a dist tarball in an hour :) 
<rick_h_> hopefully :/
<huwshimi> rick_h_: Did you just see that email from James>
<huwshimi> *?
<redir> coop shift, later
<rick_h_> huwshimi: not yet
<huwshimi> rick_h_: He needs help
<rick_h_> huwshimi: got a phone call from ramm
<rick_h_> promised them a tarball in an hour or less
<huwshimi> ah ok
<rick_h_> hatch: reloading here
<hatch> ok, new linted and test passing version has been pushed up
<hatch> heh
<hatch> I just read the email, was going to say we needed to get them a tarbal
<hatch> :D
<rick_h_> :)
<rick_h_> ok, so the unplaced unit token stuck around 
<rick_h_> until I swapped back/forth but not the worst that can happen
<hatch> ok that's not horrible......but did we get a unit in the env....
<rick_h_> woot! "1 pending units nagios/0"
<hatch> YES!!!!!
<rick_h_> lol, but in lxc it creates a new machine anyway 
<rick_h_> Makyo: here's hoping you've got better luck?
 * rick_h_ remembers this is why quickstart puts the gui on a new machine on local
<hatch> rick_h_ haha, well you can't create an lxc in an lxc :)
<Makyo> rick_h_, let me tell you about stupid hooks.
<hatch> you need to do lxc > kvm > lxc or something
<rick_h_> bah, and an empty machine hanging there, but probably due to this mess
 * rick_h_ destroys local and goes to ec2
<Makyo> rick_h_, I'm on it, though.  Turns out, if you fuck up a hook, resolve --retry doesn't do quite what it's supposed to if it's the Install hook that failed.
<rick_h_> Makyo: :(
<Makyo> rick_h_, also, if you set a config value to the same thing, config-changed doesn't appear to fire.
<Makyo> so I've destroyed and re-deployed this thing four times.
<rick_h_> Makyo: yea, you have to set it to develop and then back again
<rick_h_> heh
<Makyo> Anyway, I'm almost there promise
<rick_h_> well, running quickstart on ec2 right no
<rick_h_> now
<hatch> brb letting dogs out
<Makyo> More tests, the betteer
<rick_h_> grrr no love on ec2 stupid thing
<rick_h_> ERROR state/api: websocket.Dial wss://ec2-54-227-207-97.compute-1.amazonaws.com:17070/: dial tcp 54.227.207.97:17070: connection refused
<rick_h_> hmm, seems to be doing better this time...maybe
<rick_h_> yay bootstrapped
<rick_h_> juju deploy juju-gui --to=0 
<rick_h_> go go go
<rick_h_> ok, running on ec2
<rick_h_> updating branch
<rick_h_> hatch: Makyo we might need to prepare to not use lxc sub container but just colocate two on bare metal. 
<rick_h_> hatch: Makyo what's the different in our api calls? Just deploy the unit with the machine id and skip the addMachine bits?
<jcsackett> rick_h_ did you see James pages comment on the Ods doc?
<rick_h_> jcsackett: yes
<jcsackett> Good stuff. 
<hatch> rick_h_ so it still doesn't create a unit/ 
<hatch> ?
<rick_h_> hatch: no, james page is saying that lxcs won't work well in an open stack deployment which this is going to be running on
<rick_h_> hatch: I'm trying to figure out if kvm is allowed
<rick_h_> or if we just need to colocate on bare metal
<rick_h_> hatch: while I wait to hear something (by irc, phone or email I've tried all three) 
<rick_h_> I'm still trying to QA on ec2
<hatch> oh boy lol
<rick_h_> and damn these ec2 machines are so slow for building hte distfile
<Makyo> Do the series have to match?
<jcsackett> rick_h_ The comment in referring to is he can't do npm stuff, so setting up develop is failing. 
<jcsackett> s/in/I'm/
<rick_h_> hatch: ok, colocated bare metal
<rick_h_> hatch: we need to rip out the lxc bits
<rick_h_> jcsackett: looking
<rick_h_> jcsackett: he'll not be using devleop
<rick_h_> jcsackett: we'll get him a tarball
<hatch> colo bare metal? I thought that wasn't recommended lol
<rick_h_> hatch: oh well!
<rick_h_> hatch: it's openstack on openstack so no kvm and no lxc
<hatch> so.....anyone know the id syntax for creating a colo on bare metal? :)
 * hatch goes digging
<Makyo> hatch, just don't specify the destination as a container.
<hatch> it's based on the path
<rick_h_> hatch: right, I think we can just addUnit with the existing machine id
<hatch> oh....so no machine?
<rick_h_> jcsackett: I don't see these comments where is this?
<hatch> hmm
<hatch> can you verify this on your ec2 env?
<rick_h_> hatch: right, the machine will already exist, we'll drop onto the header, and just deploy on it
<rick_h_> hatch: how can I test it? 
<hatch> well I mean via the command line
<hatch> add unit to the machine
<rick_h_> hatch: help me with instructions and I'll try it out
<hatch> ok one sec
<hatch> well you'd need to deploy a service with 0 units
<hatch> then `juju add-unit <that service> --to <machine num>`
<rick_h_> from the cli? 
<hatch> yeah
<hatch> I just want to make sure that those sequence of events actually work
<rick_h_> looking
<rick_h_> cli won't let me error: --num-units must be a positive integer
<jcsackett> rick_h_ want me to reply that there's a tarball coming with the dependencies?
<rick_h_> but we know you can via the api
<rick_h_> jcsackett: where is this?
<jcsackett> Email reply to the sharing of the ODS doc. 
<jcsackett> To you, cc'ed to the rest of us. 
<rick_h_> I've emailed him, commented in the doc, and said so to mark ramm. So if there's still a question I'd like to know where the conversation is happening. 
<rick_h_> jcsackett: ok, I think that's old info. I've already handled that one
<rick_h_> we're onto the next issues of lxc containers on the demo hardware won't work
<hatch> rick_h_ ok I'm writing the handler to deploy to bare metal
<jcsackett> rick_h_ ah, ok. Saw the question w/ no reply. Hadn't realized lxc was the next issue. 
<rick_h_> hatch: rgr, thanks
<hatch> will post back when it's tested
<rick_h_> jcsackett: my bad, didn't notice I needed to reply to all
<rick_h_> hatch: rgr, will leave up my ec2 to test it on
<rick_h_> and will bring up an lxc to test it on as well
<rick_h_> hatch: one drive by please, rename the drop target heading "Colocate on this machine"
<rick_h_>  /Create new container/Colocate to machine
<hatch> the UI is rendering it in the bare metal container when you drop, but after switching away and back again it's rendering as a new machine
<hatch> placing a unit on a bare metal creates a new machine....
<rick_h_> hatch: that's in sandbox?
<hatch> yeah....
<rick_h_> hatch: I'm not sure the sandbox supports colocated services like that. I bet it adds a new machine
<hatch> ok, checking the commands it executes
<hatch> then will push it up
 * rick_h_ is thinking. 
#juju-gui 2014-05-13
<rick_h_> so in the sandbox with the simulator I've got two mysqls in one lxc container mysql/0 and mysql/5 
<rick_h_> huwshimi: if you get a sec toss your card on the board please
<huwshimi> rick_h_: Oh yes, sure.
<rick_h_> huwshimi: thanks, will try to look after we settle this fire
<huwshimi> rick_h_: It's all good. Let me know if I can help with anything.
<hatch> running tests
<rick_h_> hatch: rgr
<Makyo> hatch, rick_h_ just curious, what's stopping us from using LXCs?  I've deployed to them on EC2 before; is this an openstack thing?
<rick_h_> Makyo: yes, the demo hardware is openstack running on openstack
<rick_h_> Makyo: not openstack on bare metal via maas like we thought
<Makyo> Boo, so no containers?
<Makyo> Ah, crap.
<rick_h_> Makyo: yep, none at all, lxc or kvm
<Makyo> That's where I was confused
<rick_h_> so worst worst case we swap the drop target to the create new machine and just deploy a new service on a new machine via machine view, but if we can colocate on bare metal we can at least demo that as closer to what we want to show
<hatch> ok rick_h_  it's up
<rick_h_> hatch: rgr, updating my two envs
<rick_h_> distfile building
<rick_h_> dave in #juju think this won't work as --to is a hack and the api won't support it like we're trying to use it
<hatch> lol 
<Makyo> Can we just be pretty?
<rick_h_> hatch: Makyo so probably be prepared to just try to create a new machine. I think we can move the drop target to the machine one, use the last commit, and just remove the machine parent? 
<rick_h_> to deploy a new unit on a new machine (no parent machine id) and then after that machine bring up the unit
 * rick_h_ is still holding out hope as these damn distfiles build
<rick_h_> or what do you guys think?
<hatch> so drop on the new machine header?
<hatch> I thought the colo was the big deal?
<Makyo> rick_h_, if that works, I'm all for it.  It sounds like a valid path, too.  "Let's deploy Nagios, just drag it onto a new machine..."
<rick_h_> hatch: I did too until the last 30min
<rick_h_> hatch: I'm cranky this isn't working out like we wanted, I'll be honest
<rick_h_> Makyo: yea, that's my thought. It's a small step code-wise from where we were with lxc
<hatch> good thing I saved that code 
<hatch> lol
 * hatch planned for this
<hatch> haha
<rick_h_> hatch: yea, thank you git
<hatch> ok I'll make the machine header the droppable one
<rick_h_> hatch: lol, plan for "the issue is going to be" 
<hatch> haha
<rick_h_> hatch: thanks, I'll still work on this qa here just to be sure
<rick_h_> damn this distfile stuff is slow when you're watching it
<rick_h_> oh npm wheee
<rick_h_> I'm going to nuke that damn site one of these days
<hatch> 'var container = db.machines.add({id: 'Hi Openstack!'});
<hatch> kehehehe
<rick_h_> lol
<rick_h_> just don't makeit "Fuuuuuuuuuuuuuuuuuuuuuuuuuu"
<hatch> do you know what the container type for bare metal is?
<rick_h_> null? Makyo any idea?
<hatch> I'll try undefined and see if it breaks
<Makyo> no container type
<Makyo> No parentId, no containerType
<rick_h_> hatch: rm the attr?
<hatch> coo
<hatch> yeah
<rick_h_> k
<hatch> hehe apparenlty it doesn't like my machine name :D
<rick_h_> lol
<Makyo> Problem I'm getting now (probably fixed by having MS log in beforehand) is that on login, it displays a broken GUI rather than the login screen
<Makyo> Until you refresh
<Makyo> Then it offers the login screen
<hatch> ok it's working but not showing the icon when it first creates the token
<Makyo> Oh, flags.
<Makyo> I had flags in the URL before loading login
<Makyo> So, fwiw, everything works on EC2 if I just create a new machine with the unplaced unit
<rick_h_> Makyo: ? 
<Makyo> rick_h_, if I drag the unplaced unit to a new machine (what I'd guessed was the path, correct me if I'm wrong)
<rick_h_> Makyo: ok, this is with hatch's latest?
<Makyo> rick_h_, I think so, within the last 15 minutes.
<hatch> that shouldn't work heh, maybe you're on the version HEAD~2 ?
<rick_h_> Makyo: yea, what's version.js say?
<rick_h_> hatch: Makyo let's hop in a hangout?
<hatch> fire me a link, will be in in a min
<hatch> just need to get the dogs in
<rick_h_> k
<Makyo> acb5d2a
<rick_h_> https://plus.google.com/hangouts/_/g4qxjkx7wpe5uiwrl7eahe6fb4a?hl=en
<rick_h_> Makyo: ok, so that's the latest "colocates on primary machine"
<huwshimi> jcsackett: Did you implement the units on machines/containers? It might be our simulator, but it never shows more than one unit on a container/bare metal, even if there are more units showing for the machine than there are containers: https://dl.dropboxusercontent.com/u/1826926/units.png
<huwshimi> If we're colocating, we might need to fix that if it's not a simulator issue
<huwshimi> Oh, maybe our unit mapping is wrong, the extra units have a different machine id
<rick_h_> huwshimi: yea, we'll have to look into it. Something's not right. I noticed it when doing the mongodb bundle
<huwshimi> oh, it's matching the first part of the id, so a unit.machine = 12 will render on machine.id=1 and unit.machine = 25 will render to machine.id=2
<rick_h_> huwshimi: heh, that seems ungood :)
<huwshimi> Yeah... :)
<rick_h_> good catch
<rick_h_> ok, bootstrapped new lxc and ec2 envs on my desktop so I can throw moar power at the problem!
<hatch> ok the machine token is being created before the unit is assigned
<hatch> that's why it's not rendering properly
<rick_h_> so when the machine is assigned we're unlazy-updating-relazying?
<rick_h_> can the machine token watch the unit for changes?
<rick_h_> and update accordingly?
<hatch> the unfortunately named '_smartUpdateList' isn't very smart
<rick_h_> lol
<hatch> and falls over when called manually
<hatch> I'm not sure why it fails
<hatch> maybe I can manually clear it out
<rick_h_> so updateMachines and smartUpdateList appear to only be for the unplaced unit list
<rick_h_> oh never mind
<rick_h_> misreading that
<rick_h_> hatch: so if you call updateMachines it won't work?
<rick_h_> _updateMachines that is
<hatch> nope, just trying to look into why
<rick_h_> hatch: what's _updateMachineWithUnitData for?
<hatch> the unit doesn't yet know what machine it's being assigned to
<hatch> so that doesn't help
<hatch> so it's passed an empty list
<rick_h_> hatch: when we place the unit we don't know the machine to updateMachineWithUnitData?
<rick_h_> hatch: I'm getting at it's broken for a split second then updates
<rick_h_> hatch: want to push up what you've got and I can pull down and help poke at it? 
<hatch> yeah one sec
<rick_h_> k thx
<hatch> I'm pretty much back to https://github.com/hatched/juju-gui/commit/2f7a580bb5c0b81e154438422378b95d3adb2d7a
<hatch> it's the closest I've gotten
<rick_h_> hatch: cool, update the pr and I'll pull down and stab at it some
<hatch> GOT IT
<hatch> fffffuuuuuuuuuuuu
<hatch> hah
<hatch> rick_h_
<hatch> I'll clean this mess up and push it up
<rick_h_> huh?
<hatch> I got it
<hatch> it renders the icon
<rick_h_> woot
<hatch> it doesn't render the container though until after deploying
<rick_h_> hatch: Makyo stand down, we've been bumped
<hatch> But....I.....Just.....
<hatch> I even just got the container to render
<rick_h_> hatch: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<hatch> rick_h_ we r in
<rick_h_> juju gui machine view demo killed, chat with me if you've got any questions. 
<huwshimi> rick_h_: :(
<rick_h_> huwshimi: acutally jump in ^ for a minute please
<hatch> rick_h_ https://github.com/hatched/juju-gui/tree/unit-drop-n-place-machine
<hatch> that one, when dropping the unplaced unit on the machine header creates a machine token and a container for the bare metal
<rick_h_> hatch: thanks
<rick_h_> hatch: make it a pr for me please
<rick_h_> hatch: just mark it WIP so I can see the diff/qa-pr it easier
<rick_h_> thanks man, see you all later in the week 
<huwshimi> rick_h_: Cheers man, have a good one.
<hatch> rick_h_ https://github.com/juju/juju-gui/pull/318
 * huwshimi has lunch
<rick_h_> morning
<lazyPower> o/
<redir> morning
 * rick_h_ takes the boy off to day care, biab
<redir> ooo, google chat has circle icons now
<rick_h_> ooh, fancy
 * rick_h_ is back
<jcsackett> morning all.
<rick_h_> jcsackett: can you check out huw's branches this morning please?
<jcsackett> rick_h_: already looking.
<rick_h_> jcsackett: and take over if necessary, he's out this week I believe
<jcsackett> rick_h_: got it.
<rick_h_> jcsackett: ty much, I'll take a peek at yours here. Jeff's will hold for a bit
<jcsackett> rick_h_: thanks.
<rick_h_> redir: let's setup a chat later today to go through your doc comments. Are you still going through the doc or set now?
<redir> rick_h_: i'll go back through it some more. and will draw some pictures from my notes.
<rick_h_> redir: ok cool
<rick_h_> redir: when you're set and ready then let's setup a call to walk through it 
<redir> reading the store code and setting up bzr branches under go -- which is new to me
<redir> rick_h_: cool will do
<rick_h_> redir: heh, yea welcome to the dual dvcs life :)
<BradCrittenden> jcsackett: i'd like to get your feedback on my local charm ingestion branch when you have some time.  lp:~bac/charmworld/ingest-local-charms
<jcsackett> bac: sure.
<jcsackett> jujugui: i've just discovered i'm not part of ~juju-gui-peeps on launchpad anymore. assuming that's still the group to be in, can someone add me?
<bac> jcsackett: ping me when you are free.  call it a mid-flight, pre-impy thing
<jcsackett> bac: i'll ping you when i finish looking over huw's branch.
<rick_h_> jcsackett: will do
<rick_h_> jcsackett: added
<jcsackett> rick_h_: thanks.
<bac> go ~yellow
<rick_h_> :)
<jcsackett> bac: looking at a diff of yours now. you want to hangout when i've read it?
<bac> yes, please
<jcsackett> bac: this is incorporating the work you've been doing for the demo into the charmworld base, yeah?
<bac> y
<jcsackett> awesome.
<jcsackett> one sec, lemme find a headset and i'll send you a hangout.
<jcsackett> bac: https://plus.google.com/hangouts/_/gwcncgfm72mxid5ajoocxnc2cua?authuser=2&hl=en
<bac> sorry jon, i'd gone to get a tea
<bac> joining
<bac> jcsackett: ^^
<redir> bac: can I bug you about locations.conf and setting up bzr later? after your call
<bac> redir: sure
<bac> hi redir
<redir> yo
<redir> wanna hangout bac?
<bac> redir: sure.  paste an url here
<bac> redir: we have seven minutes before the keynote
<redir> https://plus.google.com/hangouts/_/gshmjqp7flvrgad5bny2rybvwua?authuser=3&hl=en
<rick_h_> reminder marks' keynote is coming up next
<rick_h_> jujugui ^
<rick_h_> jujugui no machine view, but should be cool
<redir> where's the keynote?
<redir> link...
<rick_h_> https://www.openstack.org/home/Video/
<redir> jujugui^
<redir> tx
<bac> so we're running a little late...
<rick_h_> yea
<bac> go solidfire!
<kadams54> *fingers crossed*
<bac> yay, the layout worked.
<hatch> :-D
<hatch> wow
<redir> great work guys, you all rock
<kadams54> Yeesh
<bac> no spoilers.  i've got about a 20 second lag. :)
<rick_h_> hah
<kadams54> My "yeesh" was mostly the thought of using juju across centos, ubuntu, and windows. Craziness.
<hatch> rofl
<rick_h_> lol
<kadams54> Anyone know if Mark's going to be demoing anything at the November 3rd summit in Paris?
<bac> jujugui: standing up nowish?
<rick_h_> bac: rgr, on my way
<redir> what was that short lpad thing? lpad.in/something
<rick_h_> hmm, not sure. 
<rick_h_> I'd just stick the url in there, it's all good
<redir> already done
<bac> redir: for the lightweight co set up, this is all i need in my locations.conf: http://paste.ubuntu.com/7458051/
<hatch> jcastro when I click the up button on HN the button just goes away, does that mean i've voted?
<rick_h_> hatch: yep
<rick_h_> you're good
<jcastro> yes
<hatch> (shitty UX)
<hatch> :)
<hatch> thx
<jcastro> we were on the front page, now we're at the top of the 2nd page
<hatch> must have moar clicks!
<redir> hatch: that is hacker new not ui designer news
<redir> s/new/news
<jcastro> hatch, if it makes you feel better their search also sucks!
<hatch> lol
<redir> rick_h_: let me know if there is enough context in the merge request attached to that card
<rick_h_> redir: rgr will do
<rick_h_> my new amt ready intel nucs arrived so now trying to swap hardware so I can send back the first set :)
<hatch> marcoceppi any progress on the GH to LP stuff for charms? I'd like to get the Ghost charm in the store
<kadams54> jcsackett: Got some questions for you when have some timeâ¦
<marcoceppi> hatch: I should be getting a proof of concept for my sync stuff by end of week
<marcoceppi> got derailed getting more charms in to trusty
<redir> thansk for the pointers bac, I have a working lightweight checkout now...forgot I had installed cobzr some time ago and had to  remove i t...
<bac> redir: great.  stab cobzr.
<kadams54> hatch: I caught up on some of last night's backlog when I came in this morning but was wondering: what's the latest with https://github.com/juju/juju-gui/pull/316 ?
<kadams54> Awesome. I can consistently crash juju-gui:develop in Canary to the point of needing a kill -9.
<kadams54> Tab won't even close
<rick_h_> kadams54: hatch is out today. I'm going to work on mering the two branches and see if we can get them landable. 
<rick_h_> kadams54: what's up?
<kadams54> That branch has a lot of overlap with my stuff so I just want to make sure I coordinate
<rick_h_> kadams54: ok. I'll be a bit. So just take a peek and we'll try to get yours in and update to match.
<kadams54> Yeahâ¦ I'm actually working in Jeff's branch right now, so if you setup your own branch let me know so I can track the changes there.
<rick_h_> k
<rick_h_> redir: is qa still bin/enque followed by ingest?
<redir> rick_h_: make run and in a diff window
<redir> ./bin/es-ingest IIRC
<redir> let me double check
<rick_h_> bac: is bin/enque used any more? Looks like --debug got removed but the code using it didn't catch up
<rick_h_> redir: es-update?
<rick_h_> well that's just the fulltect update
<redir> rick_h_: http://pastebin.ubuntu.com/7458731/
<rick_h_> gotcha, yea I think bin/enqueue is gone and just hadn't been removed
<bac> rick_h_: it may be used by the charm.  ingest-queued now does the big enqueue does as stand-alone
<rick_h_> I've got too much old knowledge of how it used to work in my head
<redir> rick_h_: I've got too much ignorance. 
<rick_h_> bac: well bin/enque just fails because there's a if args.debug
<rick_h_> but no debug
<redir> It is bliss:)
<rick_h_> arg is left
<rick_h_> so guess the charm isn't using it either
<redir> big report:)
<redir> s/big/bug
<rick_h_> bug even 
<bac> rick_h_: no, charm isn't using it
<rick_h_> bac: rgr, thanks for peeking
<kadams54> rick_h_: when you get the chance, we should talk more about Jeff's branch and my card. I *think* my card may be resolved within the branch, but I can't verify in the current state.
<rick_h_> kadams54: ok
<rick_h_> shoot me a link
<kadams54> https://plus.google.com/hangouts/_/gw7gremxriufe4kurfpnffyo3ya
<redir> rick_h_: when are your comp/swap days
<rick_h_> redir: when are mine? someday
<rick_h_> not sure atm
<redir> k
<redir> how many charms are there?
<hatch> ~200
<rick_h_> 350 ish last I looked
<hatch> but that number is a little odd because there are charms for different series which are the same, and then a lot that aren't in the store
<hatch> oh wow that many? it's grown fast
<redir> k. importing them in core-store to try reproducing a bug and up to 378...
<redir> just wondering if it is near the end.
<rick_h_> probably near it, but with trusty and such maybe not :)
<rick_h_> redir bac: is there something to wipe the index? running es-update I get pyelasticsearch.exceptions.ElasticHttpError: (400, u'MapperParsingException[Analyzer [n3_20grams] not found for field [ngrams]]')
<BradCrittenden> rick_h_: yes, let me look, though redir may have it handy
<bac> rick_h: this should work: http DELETE 'http://localhost:9200/charms'
<rick_h_> bac thx, retrying
<jcsackett> bac: why do you keep becoming BradCrittenden?
<bac> jcsackett: connection drops for a tiny bit, irc reconnects but sees 'bac' is already taken
<bac> irc nick timeout is greater than my outage time
<jcsackett> huh; i don't actually see you disconnecting/reconnecting.
<rick_h_> bac has quit from #juju-gui ; Ping timeout: 252 seconds
<bac> jcsackett: i can get momentarily booted when a large, norovirus incubator goes by
<redir> 521 charms...
<rick_h_> woot
<jcsackett> bac: ... airplane?
<redir> cruiseship
<bac> jcsackett: i wouldn't want to be on that airplane
<jcsackett> ah.
<jcsackett> that makes more sense
<rick_h_> redir: bac man I'm having all kinds of issues trying to ingest and get stuff loaded. http://paste.ubuntu.com/7458986/
<rick_h_> I'm going to EOD soon, but just fyi, I'm trynig to get things down to QA and having a series of elasticsearch issues. 
<rick_h_> hmm, bet that's from the clearing of the db
<bac> rick_h_: that exception you pasted is in the 'save' method in the error handling section.  so saving threw an error and the corrective action is to delete the charm, which then errored b/c it did not exist.  i've never seen that before.
<rick_h_> another restart going without errors 
<rick_h_> bac: yea, I got impatient and tried to kill stuff and do qa without letting ingest finish
<rick_h_> probably left stuff in a bad place
<bac> oh
<rick_h_> starting over again
<bac> that error handling could be more robust
<rick_h_> anyway, will let it run tonight while I'm out and hopefully be good tomorrow
 * rick_h_ runs away a little bit early today. have a good night all
<redir> rick_h_: k
<redir> have a great eve
<redir> what's a QA day?
<redir> and what's an exploratory qa day
<redir> ?
<hatch> redir a day where it's your job to find a bug in the GUI
<hatch> find & file 
<hatch> we used to adhere to it pretty strictly, but lately it's been too much of a cram :)
<jcsackett> oh shit, i was supposed to do that today.
<redir> hmmm
 * jcsackett makes note to find a bug tomorrow.
<redir> like just take a day and use the gui looking for bugs?
<redir> what is the diff btwn qa and exploratory qa?
<hatch> redir exploratory qa means you have to go and try and break the app
<hatch> do things in different ways, pretend you're a user who doesn't know what's going on etc
<hatch> redir not really the day, just part of the day
<redir> tx, hatch 
<hatch> you'll be surprised what you find when you try and use the app in unintended ways :)
<hatch> and with all the work that's been landing lately we no doubt created some bugs :)
<rick_h_> oops, I had that on my stand up list to talk to jcsackett about and he wasn't there so missed it
<BradCrittenden> hatch: who were you schooling on red velvet?  http://www.nytimes.com/2014/05/14/dining/red-velvet-cake-from-gimmick-to-american-classic.html
<hatch> haha I don't remember
<hatch> huw I think
<hatch> oh man it needs to rain here
<hatch> so dusty
<bac> bah, take ours
<hatch> gladly take some :)
<bac> it comes with car-alarm-setting-off thunder too
<hatch> hah sounds like your shock sensor is a litttle too sensitive
<hatch> that landscape cloud builder thing is pretty darn cool
<hatch> I'm re-watching the keynote heh
<bac> hatch: not my car.  all of the other cars on the street...
 * bac walkies
<hatch> ahhh - is car crime bad there?
<bac> ha, all crime is bad here
<bac> not my little enclave, though
<hatch> haha ok
<bac> it also helps to not be a drug dealer or gang member.  for some reason they tend to be overrepresented in the statistics.
<kadams54> guihelp https://github.com/juju/juju-gui/pull/320 is ready for a look-see. It's a WIP so not yet ready to land.
<hatch> bac lol
<hatch> kadams54 does it work?
<kadams54> Yes
<hatch> no units should fire a change event by default
<hatch> because they are just objects
<hatch> or did my wip branches land?
<kadams54> No, your WIP branch did not land
<kadams54> But I've seen it so I know placeUnit will revive the unit :-)
<kadams54> env.placeUnit() that is
<hatch> ohh ok so the placeUnit has the changes in it to revive
<hatch> cool
<hatch> :)
<kadams54> QA instructions include console commands to grab a unit, revive it, and then set the machine ID.
<hatch> I'm not really set up atm to do any qa/reviews 
<hatch> just glanced through
<hatch> what do you think of your smart updater stuff being able to diff the old list and new list and updating the tokens which need updating
<hatch> that would be my preference....of course that's going to be more work to implement 
<hatch> :)
<kadams54> I agree that function needs to handle changes and not just the current additions/deletions
<kadams54> But I think there's still a need for a function that can just hit a single machine in the list
<hatch> you think so?
<kadams54> Yeah, I was talking with rick_h_ earlier and there are going to be a lot of events that update/change a single machine
<hatch> what I'm thinking is that at scale, we'll want to batch the changes in the UI
<kadams54> Seems like, even if changes were batched, you'd still need a way to update a single token
<hatch> I suppose this could actually be used by the smart renderer 
<hatch> yeah
#juju-gui 2014-05-14
<rick_h_> hatch: you around tomorrow? We can chat about this with kadadms
<hatch> yeah, I'm getting the yard un-wintered :)
<rick_h_> cool
<hatch> it sounds like it's on the right path though
<rick_h_> yea, I think we had a good conversation about a good path
<rick_h_> but I did want to make sure you were involved if you had feedback
<hatch> I'll have to take a deeper look at it
<hatch> but it seems good at face value
<hatch> rick_h_ what time tomorrow do you want to have a chat?
<rick_h_> hatch: not sure, kadams seems to start around 10, but I've got a delivery 9-11 (eastern)
<rick_h_> after standup maybe?
<hatch> sure that works for me
<rick_h_> hatch: coolio
<hatch> how goes the battle with the NUC?
<rick_h_> good, have maas installed but have to figure out the network stuff
<rick_h_> ATT isn't going to get to my new network stuff until later in the month
<rick_h_> so might just sit on it until then when I can put them on the network and not have ot change it around
<hatch> wth, how hard can it be for them to flick a switch? hah
<rick_h_> well, to get business class I've got to get on a different pipe that's not been run down my street
<rick_h_> so they've got to do that first, then schedule my install after that
<hatch> oh haha
<hatch> WELL THEN!
<rick_h_> redir: qa'd and commented. One small code change request
<bac> rick_h_: did your qa work after blowing away the ES index manually?
<kadams54> jujugui: heading to Michigan's equivalent of the DMV to change the title on a car. Not sure when I'll be back at the keyboard, but it will definitely be before standup.
<rick_h_> bac: I did a full emptydb and and cleared the index manaully and then I forgot to run the app so proof would pass
<rick_h_> after doing all of that I did finally get it to ingest correcty lol, been too long since I worked on charmworld
<rick_h_> kadrgr
<rick_h_> bah, how dare he leave so I can't tab complete his name
<bac> rick_h_: i'm looking for implications for deploy, things we may need to do in a migration.
<rick_h_> bac: well I can't say for sure what state my old lxc container was in and such
<rick_h_> I think it was a combo of bad things I did on my part
<bac> rick_h_: ok.  well, perhaps we'll just wait to see what happens when jenkins lands it on qa
<rick_h_> bac: rgr
<bac> my mom called b/c the internet didn't work.  took 20 minutes for her to admit she had a router and to find it.
<rick_h_> lol
<rick_h_> didn't know routers are secrets to be ashamed of
<redir> code change related to: http://bit.ly/1lsXCfv
<redir> rick_h_: ^^
<rick_h_> redir: cool, that's a link to a bug?
<rick_h_> I understand that's the background of the change, but wouldn't a skip of the test do the same as commenting it out?
<redir> I am going to a cafe for a an hour or two -- while someone works in our apt. Should be back for the stand up.
<rick_h_> redir: rgr, thanks for the heads up
<redir> rick_h_: I recommended a skip in that bug and abentley said he didn't think so
<rick_h_> ok, so he's arguing the test should stand as is
<redir> I haven't looked deeply at what test under test.ini does though.
<rick_h_> right now it's commented out
<rick_h_> I think a skip > commented out and a working test > skipped test
<redir> I don't really understand what he is saying
<rick_h_> so for this branch, I'm ok with a skip. And a card in maintance to look at this bug
<redir> I agree with you 
<rick_h_> but honestly, the goal if you working on the store is to remove this so I'm +1 skip and carry on for now
<rick_h_> there's a bug noting the issue, maybe put the bug number in the skip message
<rick_h_> and call it a day 
<redir> good idea
<redir> will do
<rick_h_> thanks
<jcsackett> morning, all.
<redir> morning jcsackett 
<redir> bbiab
<rick_h_> delivery man is here, biab
<rick_h_> back
<jcsackett> rick_h_: got a sec to chat imp details on change summary? have a question with changing configs pre deploy, specifically.
<rick_h_> jcsackett: sure thing
<jcsackett> rick_h_: https://plus.google.com/hangouts/_/gymhrqahxkwfy5tn6duz2v72yaa?authuser=2&hl=en
<rick_h_> morning hatch, when you get settled want to run an interview presentation question by you before emailing it
<hatch> sounds good, ha ve it in a doc somewhere?
<rick_h_> hatch: yep
<rick_h_> hatch: shared with you
<hatch> cool, looking
<hatch> just as I get over my cold, I get allergies lol
<rick_h_> hah! welcome to spring!
<redir> modified to run desctructive by default under the test make target or not under testdebug target. http://paste.ubuntu.com/7462988/ I could reverse the logic and make test nondestructive, then add a testci target that is. Then sinzui only needs to change that target on CI, IIUC.
<redir> guihelp thoughts?
<redir> I think I like the latter better. Then we only have to deal with thte booger once changing the ci config, rather than all developers needing to deal with it when running tests
<rick_h_> redir: looking and rereading the bug filed
<redir> cool heading back to apt for call. hopefully they re done in my office.
<redir> brb
<Makyo> jujugui call in 10
<redir> back
<rick_h_> redir: cool, let's chat after the hangout. I think I better understand abentley's point and the issue now. 
<redir> k
<abentley> redir: watch for stray pdbs :-)
<redir> it isn't committed. still needs doc'ed etc. but thanks for the reminder. I have been known to dangle a pdb in a commit or two
<rick_h_> jujugui call now
<bac> redir: but where did your Quickstart come from?  probably the PPA.  the card is for getting into main.
<redir> OIC, tx bac
<tvansteenburgh> hey guys, when doing and api search (e.g. http://manage.jujucharms.com/api/3/search?text=mongodb), is there a way to say "only give me charms" or "only give me bundles" ?
<tvansteenburgh> s/and/an/
<hatch> tvansteenburgh at the moment you can only get 'all' bundles 
<hatch> fixes are in the works for enhancing the search though
<tvansteenburgh> hatch: okay thanks
<rick_h_> tvansteenburgh: charm:mongodb
<rick_h_> tvansteenburgh: bundle:mongodb
<hatch> rick_h_ so I think I'll trash the card that's on the board and create a series of them to 'hook up drop targets for unplaced units' 
<rick_h_> hatch: jump in hangout to follow up?
<hatch> sure
<hatch> in the standup hangout
<rick_h_> hatch: rgr
<rick_h_> hatch: fyi ^ 
<hatch> oh that's interesting, is that new?
<rick_h_> hatch: we did that a few months ago, so newish?
<hatch> yikes where have I been
<tvansteenburgh> rick_h_: cool, thanks!
<rick_h_> hatch: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<rick_h_> tvansteenburgh: np, let me know if you hit any issues
<tvansteenburgh> rick_h_: any suggestions on how to handle this: http://manage.jujucharms.com/api/3/search?type=approved&text=charm:
<tvansteenburgh> i want "all approved charms" but this query returns bundles too
<rick_h_> tvansteenburgh: hmmm, thinking
<rick_h_> tvansteenburgh: http://manage.jujucharms.com/api/3/search?type=approved&text=&series=trusty and update for each series you want the data for. 
<rick_h_> tvansteenburgh: bundles don't have series so you should get those filtered out?
<tvansteenburgh> rich_h_: will bundles ever have series?
<rick_h_> tvansteenburgh: not that I'm aware of
<rick_h_> tvansteenburgh: what's this for? If it's something we need to support we can look into it perhaps
<tvansteenburgh> charmworldlib is a python library on top of this api. i'm working on adding bundle support to the lib
<hatch> annnnnd I'm working outside!
<rick_h_> what bundle feature of bundle support is this doing?
<rick_h_> hatch: :P
<hatch> ok I needed a blanket, but damnit I'm outside!
<tvansteenburgh> when i do Bundles.search() i want to make sure i only get bundle data back
<rick_h_> tvansteenburgh: ok, but doing bundle:term should work for that. 
<rick_h_> tvansteenburgh: what's the recommended charm search part for?
<rick_h_> tvansteenburgh: chat? 
<tvansteenburgh> rick_h_: yeah, chat
<rick_h_> tvansteenburgh: https://plus.google.com/hangouts/_/gzypx4siy6biijpzjj4hq2ey6ma?authuser=1&hl=en
<redir> that causes an error, so I skipped the test committed, will look at the test separately.
<redir> so now I change status to approved? rick_h_ bac?
<rick_h_> redir: ok, yea skip and land and add a follow up kanban card for the test
<rick_h_> redir: make sure to put that bug number into the new card as the "card id" field
<redir> having never landed before I am guessing I change the status to approved
<redir> then magic happens, rick_h_ 
<rick_h_> redir: yep
<rick_h_> then if all goes well CI will pick it up and try to land it. That CI tarmac stuff is still running the show right bac?
<redir> and where would you like the card added
<redir> maintenance?
<rick_h_> redir: might as well stick it in Maint. branch start 
<redir> tracking
<redir> k
<redir> tx
<rick_h_> redir: but time box it. Look at that test update for today, if there's no advancement let's move it back as a todo item and get you back onto the core store stuff please
<redir> k. approved revision == 515 but the skip is in 516, does that matter?
<rick_h_> hmm, it might complain about revisions not approved. sec
<rick_h_> redir: ah, yea you need to fill out the commit field
<rick_h_> see the landing bot being all helpful like that
 * redir likes robots.
 * rick_h_ goes to get lunchables
 * rick_h_ is back from lunchables
<hatch> mmmm lunchables
<tvansteenburgh> rick_h_: after looking at the charmworld code i realized the error of my ways. http://manage.jujucharms.com/api/3/search?type=approved&text=charm works just fine
<rick_h_> tvansteenburgh: ooh, good call. I didn't think to ditch the :
<rick_h_> the source always wins
<tvansteenburgh> +1, thanks for your help
<hatch> chickadees are out :-)
<kadams54> In the saddle for the afternoon
<kadams54> guihelp: looking for eyeballs on https://github.com/juju/juju-gui/pull/320
<rick_h_> kadams54: can help look shortly
<bac> oh no, leankit has hired all of those little bastards from vegas: http://leankit.com/blog/wp-content/uploads/2014/04/8-WIP-Personas1-570x1024.jpg
<kadams54> Minions. They're called minions. ;-)
<hatch> haha minions rock
<rick_h_> lol
<hatch> kadams54 I think it was you who said the container tokens get the data-id attribute set somewhere so it didn't need to be in the template
<hatch> do you remember where it is set?
<kadams54> If I had a time machine I'd go back and punch past-me in the mouth for saying that.
<kadams54> Oh, yeah, that's right
<rick_h_> kadams54: I've put some feedback in that I think drives this a bit deeper. Can you give it a read through and we can try to figure out if it makes sense and break the work. Maybe some this branch and some as a follow up?
<kadams54> hatch: here: https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-token.js#L129
<kadams54> Will look through
<kadams54> Thanks rick_h_ 
<rick_h_> kadams54: thank you, it's a good start on the work we need.
<hatch> kadams54 ohh it was the machine token, not the container token
<hatch> ok the container token maybe didn't ever have an id set
<kadams54> Yeah, container token doesn't right now, but machine and unplaced unit do
<hatch> got it
<kadams54> Both of those work the same way now
<kadams54> Used to be machine had it in the template and unplaced unit didn'tâ¦ or the other way around
<rick_h_> redir: what's the card in tracking you've got there?
<redir> in which?
<redir> in Proj A
<redir> one of the store bugs I started on
<redir> rick_h_: 
<rick_h_> redir: ok, I'm going to move it back, tracking is for stuff outside of our control we're monitoring
 * redir looks to see where it should be
<rick_h_> redir: like getting quickstart updated in trusty. We've handed off the work and are watching others who do the final landing bits. So we're tracking their progress towards our goal
<rick_h_> redir: I'm just moving it back into ready to code
<rick_h_> and tomorrow then just move it to 'branch start check list"
<redir> or later today!
<rick_h_> redir: or later today :)
<redir> can't reproduce anyhow
<redir> but more on that later
<rick_h_> ok
<redir> rick_h_: are you rharding on lp?
<rick_h_> redir: yes
<hatch> so....containers don't have unique id's?
<rick_h_> hatch: machine containers? They should. 
<hatch> the object passed into the container token doesn't have anything resembling an id
<hatch> containers = this.get('db').machines.filterByParent(parentId);
<rick_h_> ok, well a container is just a machine and machine's have ids
<hatch> ok I'll look into this filterByParent method then
<rick_h_> so the machine id of the containers should be their id
<rick_h_> it might not be passing back all the data you need
<rick_h_> right
<hatch> so my neighbour just asked me if I have the day off...I said no....this is work
<hatch> kehehe
<rick_h_> hah
<hatch> would like this screen to be a little brighter though
<hatch> this is pretty darn cool https://chrome.google.com/webstore/detail/octotree/bkhaagjahfmjljalopjnoealnfndnagc
<hatch> ^ shows the github repo in a tree format
<rick_h_> nice
<redir> guihelp easy review -> https://code.launchpad.net/~reedobrien/charmworld/reindex_test/+merge/219569
<bac> redir: on it
<hatch> zomg that's HUGE
<redir> merci
<hatch> ;)
<bac> redir: would you like your branch to the bug?
<bac> redir: recall the --fixes=lp: thing on commit will do it for you...
<redir> ?
<redir> link branch to bug
<redir> oh
<redir> I put it in the commit message
<redir> didn't realize it was cli time req't
<hatch> rick_h_ oh I think I found the issue - if the filter returns an empty array it renders the token as bare metal
<hatch> so no id
<hatch> hmmm
<rick_h_> hatch: ah, right well that's true
<hatch> well NOW you tell me!
<hatch> :P
<rick_h_> well you said a container, bare metal isn't a container :P
<hatch> okI'll let it slide......this time!
<bac> redir: sorry, if i confused you.  if you do 'bzr ci -m "my wonderful changes" --fixes=lp:123456' the branch will be linked to the bug on LP the next time you push.
<redir> bac how do I link them after the fact?
<redir> just stick it in a comment/
<bac> no
<redir> ?
<rick_h_> redir: in the UI in the upper right there's a link for it
<rick_h_> On the bug page there's a "Link branch" and in the branch there's a "Link to bug" or something like that
<hatch> You need to do it from the bug page
<bac> go to the branch page and click 'link to bug report'
<hatch> yeah what rick said
<bac> hatch: or the branch page
<hatch> or that
<hatch> :)
<hatch> LP is a little confusing sometimes
<bac> they are ambidextrous
<hatch> hah
<bac> hatch: how would you suggest rewording "Link to bug report" to be clearer?
<hatch> bac I don't think it could be clearer
<hatch> I mean, it's confusing because you can't do it from the merge proposal 
<bac> when did LP merge proposals get in-line comments???
<hatch> I don't see said comments
<bac> hatch: on https://code.launchpad.net/~reedobrien/charmworld/reindex_test/+merge/219569 do you not see several places that reference "inline comments"?
<bac> hatch: it could be that it is a feature only enabled for beta testers or LP devs or something
<redir> I see link in bug -> branch, but not in branch -> bug
<hatch> I see your comment which references the inline comments but there are no inline comments
<bac> redir: did you make the change i requested?
<bac> there should be an in-line comment below line 21
<redir> I didn't se a requested change
<redir> but yes I just saw that
<bac> redir: so maybe in-line comments don't work so well
<redir> comment
<hatch> haha
<redir> looks like it is there now
<redir> you prolly  need to reapprove for the new commit
<bac> redir: and you must put the commit message into the merge proposal before sending it on
<redir> yeah.
<redir> :(
<redir> I did but didn't save before clicking see inline comments
<bac> redir: done.  you can toggle the approve now and it should be happy
<kadams54> rick_h_: had a chance to read through your comments and digest. Let me know when you've got a few minutes to chat about it.
<rick_h_> kadams54: k, otp atm and will get back
<redir> guibot doesn't miss a beat
<redir> thanks bac
<rick_h_> kadams54: got time?
<kadams54> Yup
<rick_h_> kadams54: join me in the standup hangout?
<kadams54> k
<hatch> rick_h_ do you use google play music?
<rick_h_> hatch: yep
<hatch> it's suggesting me songs from you hah
<rick_h_> lol
<hatch> I just started using it and man I'm confused
<rick_h_> sorry about that, I listen to a lot of kids stuff and a lot of soundtracks on there
<rick_h_> yea, it can be confusing. 
<rick_h_> it's nice though, if you subscribe, to just get to anything. I almost always live in "listen now" area
<hatch> well apparently I can upload my music to it? But I have to pay to do so?
<hatch> maybe not?
<hatch> I can only download a song twice
<hatch> .....It's just confusing when it's not a streaming service
<rick_h_> hatch: yea, there's the music manager app you can get
<rick_h_> I used that to do my uploads
<rick_h_> I think you only have to pay over 20k songs
<rick_h_> and OMG yay my tablet is back from Delta!
<hatch> I think it needs some better onboarding
<bac> redir: hey, guess what i found.  bin/sync-index
<hatch> haha it was actually your tablet??
<bac> rick_h_: you left it in the seatback pocket/
<bac> s///?/
<rick_h_> bac: heh, no I pulled it out of that pocket and put it on my seat so I wouldn't forget it
<bac> wow
<rick_h_> then I pulled my bag down from the storage above and left it
<bac> rick_h_: i was thankful to get back my stainless water bottle
<rick_h_> so I was just stupid, while being thoughtful to make sure I didn't forget it
<rick_h_> but yay, because there's not a good tablet I'd buy and don't want to pay full price for another N10
<redir> bac does it do what you think?
<redir> or work?
<bac> redir: it seems to!  miracles.
<redir> I saw it and think it wasn't doing what I wanted
<redir> but that could have been me breaking shit
 * redir likes miracles nearly as much as robots
<bac> redir: it seems to just put the charms in mongo into ES.  perhaps it doesn't index bundles...i haven't looked
<redir> trumpets blare, angles sing:)
<redir> angels even
<redir> me runs car^H^H^Hbike to shop
<bac> redir: yes, it does not know about bundles
<redir> grrr flamingo double charged me
<hatch> hmm, I should take a look
<hatch> thx for mentioning that
<rick_h_> redir: :(
<hatch> looks like they charged me for  the internet
<hatch> jujugui ^ did they charge anyone else for their room internet?
<kadams54> hatch: No
<hatch> ugh that place is such a bess
<hatch> mess*
 * bac looks
<kadams54> hatch: Though I should re-check my credit card just to verify - is this a charge you just noticed show up?
<bac> hatch: did you check out at the desk?
<hatch> kadams54 it went through on saturday
<hatch> bac no.....you still have to do that? I didn't know it was 1990 still :P
<hatch> the saturday we left that is
<bac> hatch: i did it so that i'd know if there were outstanding charges
<hatch> Makyo how about you? Did they charge you for your internet in the room?
<kadams54> hatch: Verified. No charges for internet.
<kadams54> rick_h_: https://github.com/juju/juju-gui/pull/320 is ready for another round of review + QA.
<rick_h_> kadams54: rgr, thanks. 
<hatch> ok I'll check with sarah to make sure we aren't being double charged thx
<redir> They tried to bill me for the internet service, but I refused to pay it before I left. I had them remove that and a call to hotel tech support. So they agreed, then billed me. And then billed me again a week later for roomservice a second time.
<hatch> lol 
<hatch> I hope that place is stricken from the sprint list 
<hatch> stricken with prejudice 
<Makyo> hatch, checking.
<bac> hatch: by 'that place' i hope you mean 'nevada'
<hatch> bac lol, there are some really nice places in Nevada 
<bac> i can't see us sprinting at any of them
<bac> bandwidth at the bottom of the canyon is miserable
<hatch> haha....well that may be valid
<Makyo> hatch, no, because they used your card for incidentals/
<hatch> rofl
<kadams54> rick_h_: just submitted my expenses. Should I send you the receipts for when you approve, or should I just send them along to expenses@canonical.com? Is there any other info I need to include in that e-mail so that they can connect my receipts to my expense report?
<rick_h_> kadams54: you can just send them along. 
 * redir redoes math and they only overbilled me by a dollar. Amazingly, the receipt is pretty inscrutable.
<rick_h_> kadams54: please make sure to rebase down the 3 commits. 
<kadams54> rick_h_: I'd rather notâ¦ they're not related commits
<kadams54> Or rather, they're distinct units of work within themselves
<kadams54> "Logical commits" per hatch :-)
<rick_h_> kadams54: ah, I just saw the dupe tests and assumed it was gardening
<rick_h_> kadams54: all good then, nvm
<kadams54> That was drive by
<hatch> :D
<rick_h_> kadams54: reviewed
<kadams54> Thanks! I'll make the comments changes and then land it
<rick_h_> kadams54: ty much
<rick_h_> kadams54: and you're in a good place for the follow up then?
<kadams54> yeah
<rick_h_> cool
<kadams54> Follow up being to setup the array of machine token and improve rendering logic to only redo the changed bits
<kadams54> s/token/tokens/
<rick_h_> kadams54: rgr
<kadams54> I'll setup a card for that shortly.
<rick_h_> k
<redir> erm should expenses show up in canonical admin under my expenses after submitting, but before approving?
<kadams54> redir: yeah. Did you hit the Update link at the bottom before sumitting?
<redir> I thought I hit update
<redir> but I see nothging in the anywhere
<redir> I hope I am not submitting 20 copies of this:)
<kadams54> Hmmâ¦ I had that happen once when I tried to save a draft, but I think I forgot to hit update.
<kadams54> Fortunately it took when I re-entered everything, hit update, and then submitted
<redir> oic
<rick_h_> redir: have to check with mramm, I think your stuff goes to him atm
<redir> you update then save
<redir> rick_h_: it does according to this
<redir> just want to put some receipts away...
 * rick_h_ thinks that's a nice way of saying...not my problem! :P
<redir> rick_h_: noted
 * redir prepares to bother the ramm
<rick_h_> and with that, I think I'm going to run away for the day
<rick_h_> have a good night all
 * rick_h_ runs fast as fast can be...trips over the dog...doh
<hatch> woah....apparently the ecs can brick chrome
<hatch> lol
<redir> night
<kadams54> Ah yes, I did that a few times.
<hatch> I filed a bug on it
<hatch> that definitely shouldn't happen
<hatch> :)
<redir> what's the ecs?
<hatch> environment change system
<rick_h_> environment change sets
<bac> rick_h_: how did DL know it was yours?  just from the seat, label, constant phone calls?
<hatch> lol oh right I forgot it was renamed to sets from system
<rick_h_> bac: so I filled out the form, told them my seat, described the item, listed the movies and such on it, and they just replied "we think we found your item"
<rick_h_> so not sure which item made my case
 * Makyo dogwalks
<hatch> I'm surprised someone didn't steal it
<hatch> like the clean-up crew or something
<hatch> maybe there is still SOME good in the world lol
<bac> hatch: they thought about it, but stole the lost iPad instead.
<hatch> haha
<hatch> probably the truth
<hatch> Makyo does the 'ghost' machine need an id that is representative of it's end position..... ie) container vs machine style id's?
<Makyo> hatch, no, I don't think so. Just something that can be deleted later/
<hatch> ok - I'm just trying to track down a bug and trying to narrow down the issues
<hatch> how hard is it to run charmworld locally? 
<rick_h_> hatch: in an lxc not bad. Just make sure it's a sauce or precise lxc
<rick_h_> hatch: just takes a while, why, what's up?
<hatch> doing this machine view stuff requires a lot of refreshing
<hatch> so I'm hammering on CW and it's slowing me down
<hatch> heh
<rick_h_> how would charmworld help?
<rick_h_> oic
<rick_h_> try setting the url to http://qa.manage.jujucharms.com/ ? 
<rick_h_> it's non ssl at least
<hatch> ahh that's a good idea
<hatch> I have everything working but placing onto an already created container
<hatch> I'm very close to calling it a placeUnit bug
<hatch> yep placeUnit bug
<hatch> this ecs + mv stuff is a house of cards right now
<hatch> ok adding to an already existing container is broken
<hatch> I'm guessing in the add_unit stuff
<hatch> but I'm pushing that to another branch
<hatch> jujugui anyone able to take a peek at my branch before I write the tests? https://github.com/juju/juju-gui/pull/321
<kadams54> Sure
<hatch> thank yas
<kadams54> Nothing jumps out at first glance. Unfortunately I just got a phone call and gotta make an emergency jacket delivery, but I'll look at it more when I get back.
<Makyo> I'll take a quick look too.
<Makyo> hatch, yeah, that looks like a good path to move forward with.
<hatch> eggcelent thx for looking
#juju-gui 2014-05-15
<rick_h_> this is interesting reading. I think this somewhat fits a model I like of one smart bit of code doing the work and logic using a bunch of dump components http://r.bmark.us/u/c65d3981a861f0
<redir> rick_h_: interesting, does jujugiu map to that model?
<rick_h_> redir: in parts
<rick_h_> redir: so the State system helping to managing dispatch fits that a bit. Components request a change of state and the state system is a dispatcher from there
<redir> the store in the flux model == statesys
<rick_h_> redir: and there's the code that handles the deltas from juju-core. It's something we probably don't do well enough, reusing that dispatcher that we use to talk over the websocket in the direct user interactions
<redir> and components == view?
<rick_h_> redir: yea, somewhat
<rick_h_> the dispatcher is the sys which stores the current state 
<rick_h_> and then the views are triggered and told "Hey, this is the state, update your stuff man"
<redir> I can't quite put my finger on it but is seems to echo the ORM vs. anti-ORM model proponents converstations as well
<redir> "Hey view, you better get your state together!"
<redir> I like it
<rick_h_> heh, well I always wrap my orm around a layer of code 
<rick_h_> that's more app-specficic and provides a cleaner/simpler api
<redir> I should look at bookie and see how you did it there.
<rick_h_> redir: did your branches land?
<rick_h_> redir: or are they in limbo landing at all?
<redir> I think they both landed
<rick_h_> ok cool, will move them over to daily call
<redir> "bam!" to quote emeril
<redir> thanks for the nudges
<redir> WRT store stuff
<rick_h_> all good, it's my job :)
<redir> http://bit.ly/1qFzThG I can't reproduce that. 
<redir> the code appears to have changed significantly since then 
<redir> June 2012
<rick_h_> redir: cool, then mark the bug as invalid and note you can't reproduce it and ask them to reopen if they find a method of reproducing
<redir> should I go back and see if I can see it in the past and note where it may have been fixed? Ask someone? comment that I can't reproduce?
<redir> perfect
<jcsackett> huh, wasn't actually on IRC...
<jcsackett> morninng all. :)
<rick_h_> party
<jcsackett> i love "party" as a morning greeting. :p
<redir> especially at the end of the night
<jcsackett> ...fair. :p
<redir> the charm browser == CW?
<rick_h_> heh not really
<rick_h_> the charm browser is the UI components in the GUI that allow for browsing charms
<rick_h_> it loads it's api data from charmworld
<rick_h_> which loads it's metadata from the juju store and other parts of the world
<redir> looking through the other store bugs and they seem to need some clarity
<rick_h_> and it all gets called 'the store' at times confusing the $#@$#@ out of people
<rick_h_> redir: ok, feel free to add some notes/etc 
<rick_h_> redir: a little triage/etc. Mark bugs as incomplete if they really do need more info to move forward and the like
<rick_h_> redir: maybe even put a card up for "store bug triage" and move it to done when you've gone through
<redir> k
<rick_h_> hit me up if you've got any questions
<redir> lots
<redir> :)
<redir> can prolly run through them in 10 minutes though
<redir> gah. 
<BradCrittenden> jcsackett: could you review https://codereview.appspot.com/98280043 at your convenience?
<jcsackett> bac: sure.
<jcsackett> bac: i'll be reviewing it soon. soritng out a bit of branch goofiness at the moment.
<bac> jcsackett: ty
<jcastro> hey rick_h_
<jcastro> http://dash.juju.solutions/solutions
<jcastro> https://github.com/chuckbutler/juju-is-dashing
<rick_h_> jcastro: purdy
<redir> very metro or aol depending on how old you are
<bac> hi abentley.  we're having login issues with charmworld on canonistack and the new staging version on prodstack.  both are using new URLs.  is it required to register those URLs with SSO for things to work?
<bac> jcastro: i'll bet that is real pretty on your windows phone
<jcastro> hah
<abentley> bac: No, registering the URLs is only needed for SSO to "trust" the site.  Without it, you'll get a page asking you what you want to share.
<abentley> bac: But if you share everything, it should have the same effect.
<abentley> bac: Note that everything defaults to /not/ shared.
<bac> abentley: ah, ok.  there is some other problem then as when we return to charmworld we're not logged in
<bac> abentley: still i'll ask webops to register us
<abentley> bac: At login time, charmworld tells SSO where to send users once they've authenticated.
<rick_h_> hatch: http://r.bmark.us/u/c65d3981a861f0 from one of the tech mailing lists this morning. 
<rick_h_> hatch: seems to match some of the 'make one part smart, all the rest stupid components' stuff we've been talking about lately
<hatch> checking
<hatch> I got a sun burn yesterday
<hatch> lol
<rick_h_> lol
<jcsackett> bac: looking at your MP now.
<hatch> rick_h_ While I agree with the outcome of that article, they are doing MVC wrong, no wonder it wasn't scalable lol
<rick_h_> heh
<rick_h_> hatch: they're also on a different scale than most
<hatch> "A Flux TodoMVC Tutorial ..."
<hatch> haha so ironic 
<hatch> :P
<hatch> yeah, very scale, much codebase
<rick_h_> jujugui call in 10
<jcsackett> jujugui: can someone look at https://github.com/juju/juju-gui/pull/322, please?
<hatch> on it
<rick_h_> jujugui call in 1
<rick_h_> jcsackett: ^
<rick_h_> kadams54: ^
<jcsackett> rick_h_: yeah, fighting with G+ again.
<bac> redir: http://qa.manage.jujucharms.com
<bac> on canonistack
<hatch> good afternoon antdillon 
<antdillon> hatch, hi there
<redir> bac tx
<hatch> Makyo you asked if the simulate false should have been committed......after working with this machine view stuff - I'm thinking it should be off by default because we have no visual indication that it's on, thoughts?
<rick_h_> hatch: make it obvious by dumping to the console some info? 
<hatch> well the simulator is very broken for the machine view - so it needs to be disabled every load if you're going to be using the mv anyways
<hatch> very is probably an exaggeration 
<rick_h_> well I think that's what I like about this. It points out issues easy to sweep under the rug for now. 
<rick_h_> I don't think turning it off by default because it's annoying right now is the answer tbh
<rick_h_> you can flip it for your dev cycle and get the work done
<jcsackett> rick_h_: re: your comment about tests for the generateDescription stuff--i'm game for that, but will get to it in a follow up as that functionality already exists untested in the code.
<jcsackett> i've planned the whole rest of my day to be "add tests" cards, so it should be handled soon.
<rick_h_> jcsackett: right, but now you made a bunch of changes to it. While you're there, it makes sense that your changes turn into "here's what it should be now"
<rick_h_> I'm just saying one test that's got an array of "change object => html string" mapping to loop and verify
<hatch> ohhhhhh kay
<jcsackett> rick_h_: fair enough.
<hatch> jujugui are there no placeUnit() tests?
<hatch> rick_h_ I created a card for ^
<rick_h_> hatch: hmm, I thought there were some that frankban and Makyo did 
<rick_h_> hatch: but yea, ok, card is good
<hatch> I thought so too but a grep in the test folder turned up 0 results
<rick_h_> it might be indirect I guess. So yea, direct tests of it welcome
<hatch> ugh test suite
<jcsackett> ^ + 1000
<Makyo> jujugui quick review/qa https://github.com/juju/juju-gui/pull/323
<jcsackett> hatch: i've pushed up changes to my PR, not sure if you want to take a look again or not.
<hatch> should I trust you? :P
<jcsackett> hatch: i'm generally trustworthy.
<jcsackett> hatch: however, "trust, but verify" is a saying for a reason. :p
<hatch> haha
<hatch> I just looked, all looks good :)
<jcsackett> hatch: cool, thanks.
<hatch> jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/321 
<Makyo> On it
<hatch> thx sir
<hatch> ahh it's raining out.....awesome
<hatch> rick_h_ I think the kanban on deck for project 1 is out of date
<rick_h_> hatch: looking
<rick_h_> hatch: I gardened a bunch of it today but not done yet
<rick_h_> hatch: let's chat paticulars after my calls
<hatch> cool np - I'm looking for my next card - I was thinking I might try and tackle the 'ghost machine' in the ecs addMachine call bit....
<hatch> that might be something to pair up with Makyo  on
<rick_h_> hatch: for now let's grab one of the cards in the ready to code and do some cleanup?
<hatch> can do!
<rick_h_> hatch: or I could really give you the hell task of trying to get that search/state card going again which will probably have the rebase from hell now
<rick_h_> kadams54: 1-1?
<kadams54> Ah yes
<hatch> lol....hm
<rick_h_> hatch: I'm trying to be nice and find time to get back to that one myself :P
 * hatch picks something from ready to code really fast
<hatch> sorry busy, got another card
<hatch> ...lol
<redir_> anyone have any pointers to fixing dns slownes swith dns-masq
<redir_> ?
<redir_> under 14.04
<bac> redir, no, its built into my wap
<redir_> bac wap?
<bac> wireless access point
<rick_h_> hatch: did you have time to chat now?
<hatch> otp 5 mins?
<rick_h_> hatch: :P fine be that way
<redir_> bac me too. I'll just deal with it
<redir_> for another day
<hatch> rick_h_ ok rdy
<rick_h_> hatch: stand up hangout
<bac> redir: sorry, i may have been too cryptic.  my router runs dns_masq, so i don't have to on my machine.  works well.
<hatch> im there
<bac> redir: but consequently i don't know anything about setting it up
<redir_> oic
<redir_> found it here
<redir_> I think'
<rick_h_> bac: there was an email about this bug https://bugs.launchpad.net/juju-core/+bug/1318711 that mentioned  In the                                                                                    
<rick_h_> mean time, you can do "juju scp -- -r $source $target"
<_mup_> Bug #1318711: juju scp reports -r as an invalid option <ssh> <juju-core:Triaged> <https://launchpad.net/bugs/1318711>
<rick_h_> bac: not sure if you saw the email on that but seemed good to know
<bac> rick_h_: that is good to know
<bac> i shall add that to the bug report
<rick_h_> bac: yea, just looking noticed that his reply didn't get into there thanks
<rick_h_> jcsackett: call?
<hatch> Makyo hey how goes the review?
<Makyo> code's okay, just QAing
<jcsackett> rick_h_: oh shoot, didn't realize it was 2:30.
<lazyPower> Question, aside from doing charm create and making a bunch of dummy charms, is there a mode in the gui that i can use to mock a deployment with charms that dont exist yet? I'm trying to explain and diagram something out, and i'm looking for a better technique than clipping screenshots to build this in inkscape.
<rick_h_> lazyPower: so, funny you should ask that
<rick_h_> lazyPower: with the work that bac is just landing, you could run a charmworld instance, feed it local 'fake charms' and then point a gui at it
<lazyPower> oh thats awesome!
<rick_h_> lazyPower: but no, there's nothing that just let's you pretent eh GUI is a wireframe tool at the moment
<rick_h_> so you still have to create the fake charms, but you can feed them into a fake charmworld/GUI in sandbox demo mode to get the UI you're looking for to show off
<bac> lazyPower: grab lp:charmworld and look at docs/index.rst for --local-repo
<lazyPower> i think i can do that with local charms at jujugui.com for the time being can't i?
<rick_h_> lazyPower: ah, good point. yes
<rick_h_> we can do local charms in sandbox mode 
<lazyPower> hmm.. 
<lazyPower> i really want a juju gui wireframing tool. I'll pin this and come back to it. TA gentlemen
 * rick_h_ escapes from today. Have a good day all. 
<hatch> so hows everyones afternoon going?
<bac> hatch: mine is going well.  a bit warm but i'm fighting the urge to turn on a/c.
<hatch> bac yeah? What does the temp need to be to turn that on?
<hatch> I'm usually turning it on at around 18c
<redir> later rick_h_ 
<bac> hatch: well it is 28c now... so, 30c i'd say
<redir> 30c == ac to me if humid
<hatch> jeebus
<hatch> 30c is me curling up in the basement 
<hatch> lol
<redir> hatch: also depends if the windows are open, breeze etc...
<hatch> granted it does hit 30+ during the summer but those days are rare
<hatch> redir let the smog roll right through?
<hatch> :P
<redir> smog?
<redir> this ain't LA
<hatch> lol, with all those ppl there isn't smog?
<hatch> I figured just that many people exhaling would create smog lol
<redir> there's definitly some grime, but that is mostly just cars.
<redir> but no smoggier than DC
<redir> maybe less
 * Makyo takes dogs for a walk while fighting CI
<hatch> Chrome is 50% slower running our test suite than safari https://twitter.com/FromAnEgg/status/467039921501655040
<bac> redir: the ngram branch did not deploy cleanly to the qa machine.  i think it requires the ES index be blown away before the mapping will work.
<bac> redir: that means before we can deploy it to production we'll need to write a migration to remove the index.  i'll make a card.
<redir> i see
<redir> I think we (you) had mumbled something about that in vegas
<hatch> jujugui lf a quick review/qa https://github.com/juju/juju-gui/pull/324
<redir> bac how do migration scripts work?
<bac> redir: i was probably mumbling more than usual in vegas
<bac> redir: precariously
<bac> redir: we should probably chat tomorrow for a more thorough explanation
<redir> bac: works for me
<redir> if that other script you had worked...
<bac> redir: ngrams now seem happyish: http://qa.manage.jujucharms.com/search?search_text=erp&op=
<bac> redir: but only on that machine
<redir> bac and that search box doesnt' use ngrams I don't think
<bac> redir: ah, yes, you're correct.
<redir> cuz we only fixed up api search to use it
<bac> redir: so, an api test will be required before proclaiming victory
<redir> http://bit.ly/1jjJUNp
<redir> bac ^
<bac> redir: that looks like good news
<bac> redir: too bad there isn't a couscous project that we could've matched
<bac> or countchocula
 * redir gets hungry at mention of couscous
<redir> going to danrea tonight
<redir> da andrea
<bac> i hope that is better than it sounds
<redir> http://bit.ly/1jjKqet
<bac> redir: so, in summary, the qa machine is happy and the jenkins lander seems happy again.  though QA for your branch failed since it didn't install cleanly.
<redir> which is because the index fails to update without wiping it?
<redir> perhaps related to jcsackett's issue qa-ing, maybe.
<bac> redir: yes.  the webops will get unhappy if we tried to deploy like that on production
<redir> heheh
<bac> redir: you should offer to help that restaurant pick a new palette for their web site in exchange for a free dinner
<redir> rightly so
<redir> yeah hopefully they spend more time in the kitchen than building www sites
<redir> google maps now has a plane as a transportation option
<hatch> oh cool
<hatch> jujugui anyone available for a review? https://github.com/juju/juju-gui/pull/324
<Makyo> hatch,  on it
<hatch> thx
<hatch> it' a quick one
<Makyo> hatch, can you look at #323?  I'm not sure what's going on with CI.
<hatch> sure
 * rick_h_ looks at CI
<rick_h_> Makyo: saucelabs fail
<rick_h_> Makyo: just keep pushing it tbh
<Makyo> alright, will do
<rick_h_> Makyo: well that error usually is a Sauce issue. Might have hit it at a bad time. If it fails like that again, after someone else got a success I'd think maybe there's an issue in there in the tests
<hatch> Makyo looks like the first one was a real failure, the second was a sauce labs failure
<hatch> I also added one comment to it if you like
<Makyo> Alright, but I'll deal in a bit.  One thing at a time.
<Makyo> hatch, was there no test impact for your branch?
<hatch> Makyo there were test already - they just continue to pass :)
<Makyo> hatch, just making sure.
<Makyo> Another case of not-really-unit-tests
<hatch> yup
<hatch> I've talked with a few people who run other large scale js apps and how they do their tests
<hatch> maybe in 3 years when we get some downtime we can refactor our test suite
<hatch> :)
<rick_h_> hatch: :P or in the next 6mo we'll work on it. 
<hatch> that's a lie and you know it!!
<rick_h_> hatch: not fair considering you and I just talked about that work starting after the next 2wk cycle
<hatch> lol
<rick_h_> ok, well yea lies all the way down 
<hatch> rick_h_ did you see my G+/tweet about safari vs chrome?
<hatch> crÄ crÄ!
<rick_h_> hatch: yea, I want to try that out. I'm curious if that's a chrome dev version thing, a chrome on osx thing, etc
<hatch> I'm on the GA release 
<hatch> Makyo are you around still?
<Makyo> hatch, yeah
<hatch> so I'm looking into this issue with placeUnit not placing in containers
<hatch> *existing containers
<hatch> actually......hangout?
<hatch> https://plus.google.com/hangouts/_/gzx4obd5lqizoj2vofrv5zs4waa?hl=en
<hatch> I came across a cool song "Will Chaplin - Eye of the Pyramid" he was on The Voice last year
#juju-gui 2014-05-16
<rick_h_> morning party people
<rick_h_> TGIF
<kadams54> guihelp https://github.com/juju/juju-gui/pull/325 is ready for QA and review
<rick_h_> kadams54: got it, will look in a sec thanks
<rick_h_> kadams54: can you pull the WIP from the title? 
<kadams54> Sureâ¦ though my thoughts were that someone else would take over and land that branch.
<rick_h_> kadams54: I think we're down a few fokls today so not sure it'll move today
<kadams54> OK
<rick_h_> if you're back on monday we can review/qa today but I think half the team is out 
<rick_h_> but cool, I'll take a look and if it's cool/close will try to get it landed. If not, we can catch up monday
<rick_h_> and get outta here and enjoy the weekend man
<rick_h_> the chilly, cold, wet,  ugh weekend :/
<kadams54> hah
<kadams54> Alright, I'm out. (Though I already spotted a typo in the comments, likely due to some errant Vim commands, that will need fixing.)
<bac> hi tvansteenburgh, you pinged me last night after i was AFK.  what's up?
<tvansteenburgh> bac: nvm, it's already fixed :)
<bac> tvansteenburgh: my kind of problem
<redir> morning
<rick_h_> morning redir 
<jcsackett> morning, all.
<redir> very celebrate! wow
<rick_h_> heh, I'm falling over tired over here so you guys will have to prop me up for meetings kthx
 * redir props
<bac> redir: what are you celebrating?
<redir> morning party
<bac> oh
<redir> heh
<redir> still mainlining coffee
<bac> that's not quite as festive as i'd imagined
<rick_h_> that's what I missed this morning. Didn't make my coffee
<rick_h_> oh moka pot, here I come!
<redir> I do have that doge meme in my head since dinner last night.
<redir> :/
<rick_h_> hah
<rick_h_> jujugui ci is rebooting and such fyi
<bac> redir: how was your couscous dinner?
 * rick_h_ is testing out running landscape across our CI server ans such
<redir> I can't kill vim
<redir> bac it was really good
<redir> pretty inexpensive fresh pasta
<redir> wine <10 a glass
<redir> and wow. very quality
<bac> cool.
<redir> how do I unfreeze vim
<redir> ?
<rick_h_> you froze vim? wow
<rick_h_> open a terminal and `sudo killall (g?)vim` 
<rick_h_> (not sure if you're running vim or gvim
<bac> looks like he did 'killall weechat'
<rick_h_> lol, reboot when all else fails
<bac> hey, anyone have experience with SMART hard drive warnings?
<rick_h_> If I see one I buy a new hard drive
<rick_h_> about the end of my experience with them
<bac> yeah, but does BAD mean you have time to recover?
<rick_h_> not sure
<redir> I don't know if it was vim or tmux
<redir> no key resopnses
<redir> in that term
<rick_h_> dropped ssh connection?
<redir> kill vim was just responing under new pid
<redir> tried killing tmux and that killed it all
<redir> local vim
<rick_h_> lol
<redir> slowly trying vim. using for editing configs only first
<redir> can't imaging trying to write code modally
<rick_h_> :) it's super awesome
<redir> :)
<rick_h_> I had a bunch of intro videos but they seemed to have been pulled :(
<redir> so edit
<redir> much powerful. wow
<rick_h_> hmm, my blip account was removed it seems. 
 * redir refrains from googling blip
<redir> vague memory of blip is surfacing. Keeps taking longer to find things in my wetware
<rick_h_> https://www.youtube.com/watch?v=XXJO_Swmdnw is the one I put on youtube. I'll have to try to find my other orig videos and upload them or someting
<rick_h_> ooh, here we go. i did upload #3 and #4 as well https://www.youtube.com/watch?v=KVAeelM-0QI https://www.youtube.com/watch?v=SzrcMilnre8
<jcsackett> for some reason hearing your voice in a youtube video weirds me out.
<rick_h_> heh, not surprising
<rick_h_> wow, 2010? Time flies
<redir> bac I don't know that it can measure if you have time to recover
<redir> I think those smart tools just tell you that things are failing
<redir> OK importing stuff into the jcorestore to start adding search
<rick_h_> redir: huh?
<rick_h_> redir: not sure that's something you should bite off atm. There's a lot more there than meets the eye. 
<redir> http://bit.ly/1ox5YpO
<rick_h_> redir: if there's no smaller bugs to tackle, I'd suggest chatting about some intro task we need for the next step in our store process
<rick_h_> redir: yea, that's a loaded bug and a half there
<redir> http://bit.ly/1ox66Wv
<redir> only two left
<redir> really
<redir> importing charms anyhow
<rick_h_> redir: ok cool, then let's put those on ice and start to look at the upcoming tasks we plan on planning-poker'ing on monday and see if we can start something there
<redir> open to a chat if you are awake
<rick_h_> redir: cool yea, understood
 * redir looks at on deck
<rick_h_> yea, jump in the standup room? I might have to bail as I'm expecting a call but no idea when it'll arrive
<redir> jumping
 * rick_h_ goes to make coffee
<hatch> hey all, what do you think of my latest blog post? http://fromanegg.com/post/85890866087/unidirectional-data-flow-architecture
<bac> hatch: your page does not load in safari
<rick_h_> hatch: cool
<hatch> bac, it's just you :)
<hatch> rick_h_ thx
<bac> that is unlikely
<hatch> analytics shows people from Safari and I have safari
<hatch> s/from/on
<jcsackett> jujugui: call in ten.
<bac> drats, it seems to be an orangesquad holiday
<redir> hatch: do users "visit" urls?
<hatch> hah, sure, why not? :)
<hatch> do you have better wording:
<hatch> ?
<redir> hatch: I don't really know. I just understood gui to not be URL driven
<hatch> it's VERY url driven now
<hatch> :)
<redir> you mean with the new work going in?
<hatch> redir yeah - many interactions update the URL so that it's sharable 
<redir> it may have been before too. I just had this conception that it loaded and you did stuff and state changed but the url didn't
<hatch> yeah, well the url only changes when the state is potentially sharable
<hatch> so, viewing an inspector? sharable, dragging a machine around, not sharable
<redir> and it devises state from the URL
<hatch> on the first pass yes
<hatch> subsequent passes the url is updated from state changes
<hatch> because the state is more detailed than the url needs to be
<redir> right and app state isn't really a resource
<redir> AFIU
<hatch> well, it's the resource which determines what the app is doing
<rick_h_> jujugui call in 1
<jcsackett> react does look cool.
<rick_h_> yea, I generally hate the whole mixing of definitions/model stuff in the HTML, but it does the thing I like of "here's some data redraw" really really well
<bac> jcsackett: given that aaron and curtis are not here today, could i bug you about some charmworld archeology?
<jcsackett> bac: oh dear. i suppose so. :p
<bac> jcsackett: specifically bug 1096131 and its companion branch https://code.launchpad.net/~abentley/charmworld/login-config/+merge/142974
<jcsackett> bac: if you want to hangout, give me about 5 min.
 * jcsackett needs more coffee
<_mup_> Bug #1096131: login/logout buttons do not update correctly <charmworld:Fix Released> <https://launchpad.net/bugs/1096131>
<jcsackett> oh wow, i probably will have nothing to contribute on that, but give me a moment to make coffee and look at it and then i can try and answer questions.
<bac> jcsackett: back?
<jcsackett> bac: back.
<redir> I see what you did there
 * jcsackett lauchs
<bac> jcsackett: you make a hangout?
<jcsackett> bac: just tried to do video from the msg you sent me on g+
<jcsackett> shall i try again?
<bac> yes, or just paste the url
<bac> i can't figure out how to start a hangout on the phone
<redir> so both core store and cw want to use mongo.juju['charms'] for persistence
<redir> but differently
<rick_h_> redir: yea, well the two were indepenant
<rick_h_> independent
<redir> tried to cheat and index the charms imported by charmload
<rick_h_> lol
<redir> got the full family fued XXX
<redir> s/fued/feud
<rick_h_> woot! got my power cables for muy nucs
 * redir imagines rick_h_ doing victory dance with power cables
<rick_h_> damn, I ordered 3' cables on purpose!
 * rick_h_ grumbled
<redir> short victory dance?
<rick_h_> yea, not short enough I guess
<rick_h_> oh well, not going to send them back over it
<rick_h_> it's on a rack, I don't need 6' of cables. The plug is 12" from the box
<hatch> haha
<hatch> I needed a ethernet cable a while back, the only one I had was 100ft long
<hatch> it needed to go 2'
<hatch> :D
<redir> doesnt' look like a nything sets the version for migrations in the DB
<rick_h_> redir: ? the migation tool chain itself marks the versions
<redir> Datastore is not currently versioned
 * redir reads more code
<rick_h_> redir: oh, you have to init it
<rick_h_> make db_init? /me has to go look
<hatch> guys - there was a problem connecting to my NAS, I need to contact my system administrator
<redir> rick_h_: that is kind of what I mean
<hatch>  /msg hatch
<hatch> :D
<redir> I was figuring that make run would set the current version or something
<rick_h_> redir: yea, it should have
<rick_h_> I've not touched this in a long time so catching up
<rick_h_> hmm, wtf. The upgrade process makes sure it's initialized
<rick_h_> redir: check out 'ensure_initialized'
<rick_h_> so not sure what's up. 
<redir> k, will keep digging. thought I'd see if anyone knew off the top of their head
<rick_h_> guihelp anyone seen mass failures of tests that attempt to set focus? They cause script errors in FF and chrome
<hatch> rick_h_ is this in test-server?
<rick_h_> hatch: yes
<redir> got it
<hatch> the browser needs to be in focus
<hatch> else they will fail
<rick_h_> hatch: https://github.com/juju/juju-gui/pull/326
<rick_h_> yea, it's got focus, or thought it did
<rick_h_> even chrome?
<hatch> yeah even chrome
<hatch> TypeError: 'null' is not an object (evaluating 'chosenOne.simulate')
<rick_h_> ok, it had focus and dies in YUI in the event handling 
<rick_h_> no, not that
<rick_h_> Uncaught TypeError: Cannot read property 'className' of null 
<rick_h_> e.mix.removeClass dom-base-min.js:8
<rick_h_> e.mix.toggleClass
<hatch> ahh I see it
<hatch> I'll have to pull it down to see
<hatch> I'll check
<rick_h_> hatch: thanks, yea love another set of eyes to see if you can dupe it or what not
 * rick_h_ goes to get food stuffs annoyed
<hatch> rick_h_ when I run the tests separately they pass
<rick_h_> hatch: yea, if I run them individual they're fine
<hatch> the problem is in test_browser_search_widget.js
<rick_h_> k, I'm heading back there. 
<rick_h_> whatever error is in there is non-obvious it seems. I'll go back through what's changed in there
<hatch> yeah I looked at the diff....and wow, what a diff lol
<hatch> the issue may not be in the test file per-se, it might be in the code it's running too
<rick_h_> yea
<rick_h_> stepping away for food and will restab it with a giant knife
<hatch> sure
<hatch> rick_h_ the issue is with the test: 'should support setting search string'
<rick_h_> lol, two lines
<hatch> yeah - would you like me to continue on it or do you want to take it from here?
<rick_h_> hatch: cool thanks, will start to walk wha that does
<hatch> ok cool
<hatch> hopefully it doesn't something really bad and cascading test failures are actually a good thing lol
<rick_h_> hah, heh it does a focus
<rick_h_> hatch: so it's back to the focus issue
<hatch> :(
<rick_h_> hatch: yea, comment out the line 'input.focus()' and tests pass
<hatch> I'm curious as to what changed in that branch to cause it to fail
<rick_h_> yea, you and me both
<hatch> from the obscure test messages it seems like maybe input doesn't exist?
<hatch> or an event issue
<rick_h_> I'm wiring some debug/try/catch stuff aroud that line
<hatch> +1
<hatch> ooooo sexy http://www.autoblog.com/2014/05/16/2015-nissan-370-z-nismo-revealed-pics/
<hatch> Sometimes I wish I had somewhere to drive to
<hatch> https://github.com/rdio/jsfmt
<rick_h_> I was wondering how long it'd take you to find that
<hatch> haha
<hatch> I think we do a pretty good job at our layouts but maybe this will be better for the chaining bits than gjslint :)
<hatch> rick_h_ any luck?
<rick_h_> otp
<redir> what's otp?
<redir> I keep reading one-time-password and I know that is wrong
<hatch> on the phone
<hatch> or "on the potty"
<hatch> I read it as the second
<hatch> -always-
<hatch> lol
<redir> great
<redir> such porcelain 
<redir> helps though
<redir> much appreciate
<hatch> lol
<rick_h_> on the phone :P
<rick_h_> interviews are fun fun fun wheeee
<rick_h_> hatch: no, I'm angry and closed the PR and going to try to find a way to do that work better by starting over and trying to find some incremental steps
<rick_h_> hatch: running tests all along the way better to catch when I make the testing gods angry
<hatch> well...we have always had issues with focus()
<rick_h_> yea, but not like this
<hatch> no, this is an odd one
<rick_h_> every focus call in the suite, simulate or otherwise, is throwing a JS error down in YUI land and causess the suite to bomb out
<rick_h_> I started commenting out every failing test, everyone one was around focus stuff
<rick_h_> after I got to 7 I stopped and decided my branch is evil and must be exorcised
<hatch> hmm
<hatch> this is less than ideal
<rick_h_> you're telling me
<jcsackett> hatch or rick_h_, i am trying to replace a method on a view with a stub, but the stub isn't getting called when the event fires (trying to more directly test event listenting than just assuring 'on' gets called in bindEvents)
<jcsackett> the actual method is, instead, as though no stub were created.
<jcsackett> is replacing something bound via 'on' in initializer not possible?
<hatch> are you stubbing the prototype?
<rick_h_> jcsackett: show me the money! ... I mean code
<hatch> you'll need to stub the method before the event handler gets called
<hatch> er
<hatch> event binder
<rick_h_> jcsackett: you have to stub it on the live instance 
<jcsackett> hatch: and stub it on the prototype, not on the view itself?
<rick_h_> jcsackett: do it on the instance of the view
<hatch> well you should stub it on the live instance if you can
<rick_h_> not the View class
<hatch> but if you can't then you need to do it on the prototype
<hatch> before the instance is created
<jcsackett> rick_h_, hatch: i'm doing it on the live instance. i'll try prototype and create new instance.
<rick_h_> jcsackett: code, it should completely work if you're on the instance
<hatch> rick_h_ unless the event is bound before it can be stubbed
<rick_h_> well the event should be bound to a callback
<rick_h_> that is stubable at any time on the instance
<hatch> depends on how the event is created, it may be creating a bound instance of the callback, not calling the method you think it is
<rick_h_> then it sholdn't do that to be more testable and refactorable :P
<hatch> node.on('click', cb, this) 
<hatch> in this case, cb is a bound function, not the original one
<rick_h_> right, I understand, but I'd push that we update that to node.on('click', this._onClick, this)
<hatch> same problem
<hatch> the stubbing has to be done before that binding
<jcsackett> hatch, rick_h_ https://pastebin.canonical.com/110371/
<hatch> jcsackett yeah that's not going to work
<hatch> you're stubbing the method after it's been bound 
<rick_h_> man I swear we do this. 
<hatch> I thought I had a test which tests what you're doing though
<hatch> just checks that the on method is called properly
<hatch> you're testing if the yui event system works
<hatch> (which it does.....we hope)
<rick_h_> no, you're testing that the callback does the right thing based on event data passed into it
<rick_h_> hatch: yea, I mean true in this case, but we've got a lot of tests that catch events stuff
<hatch> https://github.com/juju/juju-gui/blob/develop/test/test_machine_view_panel.js#L186
<hatch> yeah - it's just that those tests are fraught with issues that we seem to always run into
<hatch> heh
<rick_h_> hatch: oh, but I don't use the stub code 
<hatch> I'm pretty sure that this test tests exactly what you're trying to do jcsackett but skips the yui event handling
<rick_h_> I just view._showDraggingUI = function(ev) { done(); }
<rick_h_> jcsackett: ^
<rick_h_> don't use the makeStub, but just change the function. It's on an instance, you don't have to reset it, and you can do whatever assertions you want in the function you create
<jcsackett> rick_h_: i tried that too and it didn't work.
<jcsackett> hatch: i'm doing this because just seeing if 'on' gets called doesn't seem like much either.
<hatch> jcsackett I'm not sure I understand?
<rick_h_> jcsackett: push a branch up please. 
<hatch> jcsackett I'm pretty sure to do what you want to do you will need to stub the method out on the prototype of a NEW view, not the one created in the beforeEach
<hatch> it'll have to be done before you actually call `new`
<hatch> if I'm understanding what you're doing correctly
<jcsackett> hatch: ok, i'm game for trying that.
<hatch> if THAT doesn't work, then you have other problems :-)
<hatch> jcsackett if you still have problems after that we can pair on it
<hatch> if you like
<jcsackett> nope, that fixed it.
<redir> bac all your tests pass?
<jcsackett> of course, now we return to the question, hatch, of whether this approach has any value--do you really think just asserting that 'on' was called for each event is sufficient?
<jcsackett> i feel uncomfortable seeing that, but if others think that's enough, i don't want to add more tests to a not super fast suite.
<hatch> well your test is definitely more thorough 
<jcsackett> hatch: dig.
<hatch> but since so much is 'faked', the other view, the callback ect
<hatch> you're testing a) the event was attached b) that the proper callback is called
<hatch> removing YUI from that equasion you're left with that the proper method was called with the proper args
<hatch> know what I mean?
<hatch> I'm not saying you SHOULDN'T write your test....I just question what it adds over what's already there (assuming YUI works) :)
<jcsackett> hatch: well, that's the question i'm asking. b/c truthfully, i would rather replace the test checking that 'on' was called with three tests checking each event after fire. but if that's not *actually* an improvement, it's slower test run time for nothing.
<jcsackett> well, not so much slower test run time, but more tests for nothing.
<redir> how do I checkout bzr branch to a different revno
<redir> ie: bzr switch -b test -r510
<redir> still checks out 511
<hatch> jcsackett well I suppose if you used the 'real' token view to emit the event via it's own mechanisms then it would be a good integration test
<hatch> know what I mean?
<jcsackett> hatch: yeah, but the last thing we need is more integration tests masquerading as unit tests. not saying integration tests would be bad.
<jcsackett> i think, basically, my testing experience says "test the right events are fired and test the right behavior happens when an event is received"; checking 'on' is called doesn't feel like the latter to me, but perhaps it is.
<hatch> but isn't that what you;re doing right now? creating an integration test? the current test calls the method in question, and makes sure that method does what it's supposed to do
<hatch> which is kind of the definition of a unit test
<hatch> so this test is saying "yes on() was called with the proper arguments" 
<jcsackett> sure; i suppose that's true.
<hatch> whereas yours is saying "yes the callback gets called when it receives this event"
<jcsackett> you make a very good point.
<redir> found it
 * jcsackett has no love of js events and tests
<jcsackett> :p
<hatch> hah, sometimes I make sense :D
<bac> redir: you see test failures in trunk?
<redir> i'll checkout trunk in a second
<redir> but I am on a fresh branch from trunk, so should be OK
<redir> bac now working my way back on rev at a time., but still seeing fails
<redir> so I have something broken
<hatch> jcsackett so what did you end up deciding on? :)
<jcsackett> hatch: i took your point--there's better work to do then shaving that yak.
<hatch> oh Kay!
<redir> bac wrong version of elasticsearch running
<redir> fixed most. I still see on though
<hatch> grabbing lunch
<hatch>  /making
<rick_h_> redir: sending frankban an email saying you were looking at the dep stuff. Please make sure to shoot an email when you EOD 
<rick_h_> redir: even if it's "I didn't get around to it" so that he knows the status
<redir> rick_h_: yeah trying to figure out why I have test failure now that I didn't have before
<rick_h_> redir: all good, just don't want to leave it hanging
 * rick_h_ heads out for the day. Have a good weekend all!
<redir> bac you gone/
<redir> ?
<redir> jcsackett: ?
<bac> redir: ?
<redir> trying to understand why this test is failing but am failing to understand what it is testing even
<bac> redir: what test?
<bac> paste?
<redir> test_search.py:TestUpdate.test_simple_change_dynamic_to_static_mapping
<bac> oh, that looks like a fun one
<redir> mmm
<bac> redir: all of the test in the two test_search.py files pass for me...
 * redir shakes computer
<redir> kaaaahhhhhnnnn
<bac> redir: so, in summary, it fails for you on trunk?
<redir> bac yes
<bac> wait, i was on revno 510.  trying again with 511.
<redir> bac I converted to a lightweight checkout
<bac> redir: you are on 511 with no mods?
<redir> so totally fresh build today
<redir> bac yea
<bac> Ran 102 tests in 30.792s
<bac> OK
<redir> me deletes checkout and starts fresh again
<bac> if it fails again, please paste the output.
<redir> files not in mapping is the gist of the failure
<jcsackett> what's the logic for when we should use the event tracker vs just using this.on($event)?
<bac> jcsackett: use the event tracker if your level of indirection is less than 5
 * jcsackett blinks
<jcsackett> bac: is that an actual answer, or am i missing a reference? and if it's the former, i don't follow. :p
<bac> it was a bad joke
<redir> I laughed
<hatch> jcsackett I suppose, whenever the event is being atttached to something that may not be removed when the instance is destroyed
<hatch> so if the event is on the instance...well then there isn't a ton of risk because when the instance goes, so does the event. If it's on a dom node however.....
<hatch> it's really a piece of mind thing though
<bac> as in "i'll give you a piece of my mind"?
<hatch> lol, just like that, yes
<redir> Eddie would be proud
<jcsackett> hatch: awesome, that makes perfect sense, thanks.
<hatch> coolio, np
<redir> is there a charm to install charmworld?
<redir> we have an email list?
<redir> jujugui@ or something?
<bac> there is a charmworld charm
<hatch> redir yes i'll pm it to u
<redir> bac is it useful for developing
<redir> ?
<redir> hatch: merci
<bac> not really
<redir> boo
<rick_h_> jcsackett: always use event tracker. Any time you do this.on() it leaves behind a handle that isn't cleaned up
<bac> redir: you use bundle:~bac/charmworld-local/5/charmworld-local  to stand-up a charmworld with es and mongo on their own machines using quickstart if you want
<bac> redir: probably not a useful exercise for friday afternoon, though
 * redir pulls a handful of hair out. the tests  pass this time.
<bac> yay, i think
<bac> ok, i'm getting threatening stares from the dog so i'm taking him out.  see y'all later.
<redir> later
<redir> wher does bzr shelve store shelves
<hatch> in the ether 
<hatch> hah
<redir> did I just delete my shelf by removing the lightweight checkout
<redir> ?
<hatch> tbh im not sure
<hatch> is there a parent .bzr dir?
<redir> sigh
<redir> looks like I lost my shelf
<hatch> :(
<redir> don't know why I would have though that would be in the repo not the lightweight chekcout
<redir> silly me
<redir> I did a lightweight checkout from trunk and switched to a feature branch
<redir> then shelved
<redir> then redid the lightweight checkout and it is gone. I thought it would be in the new feature branch created next to trunk but it appears it was in teh lightweight co 
<redir> c'est la vie
<hatch> redir yeah, sorry there aren't a lot of bzr pros around any more
<redir> luckily it was only a couple files
<redir> which were still open in my editory
<redir> so I ahve it. were is large i would have been more cautious
<redir> whatevs
<hatch> oh nice - sublime auto updates to the file on disk so I don't have that 'safety net' hehe
<hatch> I should probably look into changing that 
<redir> hatch: it does if the directory is the same. If you remove a dir from under it those files should still be around
<redir> in sublime
<hatch> oh that doesn't happen to me, the file goes blank
<hatch> rick_h_ hey how goes the GSOC?
<redir> hatch: hmm st2 or st3
<hatch> st2
<redir> st3 here
<redir> which just seems to have crashed
<hatch> heh, I'm sticking with st2 until some other brand makes it - it looks like Atom might be the next best
<hatch> eventually
<redir> eow later
<hatch> enjoy your weekend
#juju-gui 2014-05-18
<huwshimi> Morning
<rick_h_> howdy huwshimi 
<huwshimi> rick_h_: Hey :)
<rick_h_> huwshimi: good time away?
<huwshimi> rick_h_: Yeah, was nice to be gone for a few days.
<huwshimi> rick_h_: Did you get a break this weekend?
<rick_h_> huwshimi: yea, I did. Had some stuff around the house to catch up on
<rick_h_> but got a nap in one day :)
<huwshimi> Nice :)
<rick_h_> spent some time planning my SF trip in late Aug
<huwshimi> Oh great
<rick_h_> huwshimi: do you have something to get started on today? Or need some pointers at some likely cards?
<rick_h_> huwshimi: we'll be doing planning poker and loading up the board for the 2wk cycle Monday 
<rick_h_> so should look better for you tomorrow
<huwshimi> rick_h_: Ok. I was planning on tackling some of the test cards. At least one is fallout from work I was doing.
<huwshimi> rick_h_: If you have anything you'd like me to get done, let me know.
<rick_h_> huwshimi: ok, that's fine by me. 
<rick_h_> huwshimi: other things to peek at are that some of the guys were updating the deployer bar. So a UX run through and hooking up the cancel stuff there would be useful
<rick_h_> we should be close to polishing that off functionally
<huwshimi> rick_h_: OK sure
<rick_h_> so take your pick, but if you can't find anything let me know. I tried to clean things up a bit last week but won't be done until Monday our end
<huwshimi> Yep no problems.
<huwshimi> Three days away and my email has been flooded.
<rick_h_> hah
<rick_h_> yea, dig out with a big shovel
#juju-gui 2015-05-11
<mhilton> good morning everybody.
#juju-gui 2015-05-14
<marcoceppi> Hey GUI peeps
<marcoceppi> is there an example of what constraints look like in "ye olde" bundle format?
<rick_h_> marcoceppi: sure thing sec
<marcoceppi> ta, also, does the GUI export with constraints?
<rick_h_> marcoceppi: yes, if they're not the defaults
<marcoceppi> interesting. I guess this is an old version of the GUI then
<rick_h_> bah, I thought the openstack bundle had them
<rick_h_> I know hatch was just messing with that export format with constraints this week.
<rick_h_> marcoceppi: https://github.com/juju/juju-gui/blob/develop/test/data/mysql-deployer-mixed.yaml
<marcoceppi> rick_h_: booya, thanks
<rick_h_> marcoceppi: sorry, that was harder than I thought. I'll check with hatch on the export. I could have sworn it exported non-default constraints but maybe I'm wrong.
<marcoceppi> rick_h_: no worries, I'll lset the ISV know that it's "being looked at" and update their bundle they're using to use the constraints they expect
<marcoceppi> rick_h_: if you need me to file a bug I can get more information about the gui they're using, etc
<rick_h_> marcoceppi: rgr sounds good. This next release we'll make sure has them as we've fixed all the colocation export/import work
<rick_h_> marcoceppi: no, that's ok. I'll just amke sure we've got it covered in the upcoming release. 
<marcoceppi> rick_h_: ta, appreciate it dude
<hatch> marcoceppi: rick_h_ got it all set?
<rick_h_> hatch: just want to verify we've got constraint export in the upcoming release
<hatch> yup it's a query string like key value pair list
<hatch> "fooo=bar baz=baz"
<marcoceppi> how does "5.2Ghz" translate into a constraint?
<rick_h_> hatch: ok, we need to make sure it's exporting
<rick_h_> marcoceppi: that's cpu-freq or something? /me checks for constraints
<hatch> cpu-power=5.2Ghz
<hatch> ^ rick_h_ marcoceppi 
<rick_h_> hatch: ah right -power
<hatch> artch, cpu-cores, cpu-power, mem, root-disk
<hatch> arch*
<hatch> stayed up till 3am working on a new charm......*yawn*
<marcoceppi> but power is measured in a scale of flag integers
<marcoceppi> "0-100" where 100 is 1 ecu
<marcoceppi> w/e idgaf about amazon's stuff
<marcoceppi> I'll just set the ram and let aws figure it out
<hatch> marcoceppi: sorry I don't know what valid values are, I just know about the keys :) 
<marcoceppi> <3 haha it's all good. I'm unblocked - thanks!
<hatch> no prolem
<marcoceppi> How does to: work?
<marcoceppi> within a bundle
<rick_h_> marcoceppi: https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-34/archive/bundles.yaml.orig for an example
<rick_h_> marcoceppi: --to what? the format depends a bit
<hatch> marcoceppi: v3 or v4 format?
<rick_h_> marcoceppi: but this is stuff that's going to depend on what you want to do and the updates to the unreleased deployer for some of it
<hatch> marcoceppi: https://github.com/juju/charmstore/blob/v4/docs/bundles.md
<hatch> scroll to the bottom
<marcoceppi> well, I got an "envExport" bundle from an ISV, I assume that's v3
<hatch> yup
<rick_h_> marcoceppi: yes
<marcoceppi> cool
<frankban> uiteam, rogpeppe2: the forward port of latest changes to charmrepo.v0 is ready for review here: https://github.com/juju/charmrepo/pull/6
<frankban> ty
<rogpeppe2> frankban: LGTM
<frankban> rogpeppe2: ty
<frankban> rogpeppe2: it seems I cannot merge on charmrepo
<rogpeppe2> frankban: really?
<rogpeppe2> frankban: i'll add you
<frankban> rogpeppe2: ty
<rogpeppe2> frankban: here's another charmrepo PR: https://github.com/juju/charmrepo/pull/7
<frankban> rogpeppe2: ty merged
<rogpeppe2> frankban: np
<rogpeppe2> frankban: i will now deal with the conflicts... :)
<rogpeppe2> wot no conflicts?!
<rogpeppe2> frankban: it all just worked woo
<frankban> rogpeppe2: great
<rogpeppe2> frankban: what are we going to do about this num_units fiasco?
<rogpeppe2> frankban: i'm faced with changing the charmstore for it, and it's awkward and annoying to do
<frankban> rogpeppe2: what change?
<frankban> rogpeppe2: we are not changing the defaults if not specified
<rogpeppe2> frankban: the bundleUnitCount
#juju-gui 2015-05-15
<mhilton> morning all
#juju-gui 2016-05-19
<jcastro> how do I get to the gui in the latest beta? I see it's deployed a unit in the admin environment
<jcastro> but going to the ip in my browser doesn't work
<jrwren> jcastro: `juju gui` will launch browser with url or display url.
<jcastro> thanks
<jcastro> jrwren: can I destroy models from the gui?
<jrwren> jcastro: i don't know. I do not think that you can, yet.
<hatch> jcastro: you can using the latest develop (but it's broken right now, hopefully will be fixed today)
<jcastro> hatch: how do I use bleeding edge gui in 2.0 land?
<hatch> jcastro: `make dist && juju upgrade-gui /path/to/dist` :)
<hatch> but if you try that now it will break
<jcastro> hah
<jcastro> man dude, next time just kick me in the knee
<jcastro> it would be sweet to have a config option to always deploy trunk gui though
<hatch> I don't think so, we want people to use the latest stable release
 * jcastro nods
<hatch> jcastro: I think having the two steps makes it easy enough while providing enough of a roadblock to indicate that "maybe you should know what you're doing" to continue
<hatch> jcastro: but we will make the gui easier to build in the future to lower that barrier 
<jrwren> jcastro: but you can build a trunk tarball yourself and juju upgrade-gui like hatch said ;]
<jrwren> hatch: how could it be any easier?  make sysdeps deps tarball wait and hour for it to break, clean-all try again, pray? :]
<hatch> lol
<hatch> by simplifying the deps required to build 
#juju-gui 2016-05-22
<ejat> anyone can help me with this error : http://paste.ubuntu.com/16614114/
#juju-gui 2017-05-15
<dakj> Hi guys, I've an issue with the bundle of Openstack Base. Juju deploys on all nodes presented on MAAS all components of Openstack, I've open a post here(https://askubuntu.com/questions/913007/openstack-base-bundle-deployed-with-juju) someone can help me? thanks
<dakj> But the components Nova-Cloud-Controller and Ceph-mon are in pending and not complete their task
<dakj> Anyone can help me with Openstack Base bundle?
<rick_h> dakj: do you have the juju cli setup for this? Or is it just in the GUI?
<rick_h> dakj: we'll need to check the logs and the cli output of `juju show-machine X` where x are the machines that are showing pending
<rick_h> dakj: and see if there's any note on the delay/issue there
#juju-gui 2017-05-19
<dakj__> hello guys, Is there someone can help me to resolve an issue with landscape-dense MAAS bundle? 
#juju-gui 2019-05-16
<fabrice_> good morning everyone
