[07:12] <rogpeppe1> mornin' all
[07:12] <urulama> morning
[07:16] <huwshimi> morning
[07:20] <rogpeppe1> urulama, huwshimi: hiya
[08:57] <rogpeppe> frankban: yo!
[08:58] <frankban> morning rogpeppe 
[08:58] <rogpeppe> frankban: you up for continuing forward with the store stuff?
[09:00] <frankban> rogpeppe: sure, coffee and I am ready
[09:00] <rogpeppe> frankban: cool
[09:10] <frankban> rogpeppe: I am in daily standup
[09:10] <rogpeppe> frankban: joining
[09:40] <frankban> urulama: could you please take a look at https://github.com/juju/charmstore/pull/12 ?
[09:40] <frankban> urulama: (and morning ;-)
[09:42] <urulama> frankban: morning
[09:47] <urulama> frankban: looks fine, only small detail ... you use CharmArchive sometimes instead of Archive (all the rest cases) ... any particular reason for this?
[09:49] <urulama> frankban: (ie, branch_test.go, line 83)
[09:50] <frankban> urulama: we (will) also have BundleArchives
[09:50] <urulama> frankban: all clear
[12:36] <jrwren> mornin
[12:40] <urulama> morning
[13:04] <urulama> jujugui: anyone else having problems with the login window after getting 1.20.0 core in the update? can't enter password for user-admin on any browser (firefox, chrome, safari)
[13:05] <frankban> urulama: trying to reproduce
[13:05] <urulama> jujugui: whatever is typed is lost within a few sec (self erased)
[13:10] <frankban> urulama: I am able to log in into the GUI in a local env
[13:11] <urulama> frankban: ok, tnx. using manual here, switching to amazon now
[13:14] <bac> hi frankban
[13:15] <frankban> bac: morning, how are you doing?
[13:16] <bac> frankban: good, thanks.  on friday, doing QA for quickstart i ran into bug 1316174 and suspended the release.  can't recall if i mentioned it or not.
[13:16] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
[13:16] <bac> frankban: it isn't a QS issue but i didn't want to do a friday release with an issue
[13:17] <frankban> bac: isn't it something also affecting current release?
[13:17] <bac> frankban: yes it does
[13:17] <frankban> bac: so, a new release would keep failing on precise but at least would fix trusty IIUC
[13:18] <bac> frankban: yes, it would be an improvement
[13:18] <frankban> bac: in this case I'd be +1 on releasing anyway.
[13:18] <bac> frankban: qa on trusty was fine
[13:19] <bac> frankban: ok, unfortunately i am not here today.
[13:19] <frankban> bac: oh, I can do that then, so missing bits are 1) QA on saucy 2) move the packages to juju stable PPA and 3) push the release to PyPI, correct?
[13:20] <bac> frankban: and the homebrew bits
[13:23] <frankban> bac: ok, I see the hacking file includes brew documentation. I'll take care of the release, thanks a lot for the heads up while on holiday. 
[13:23] <bac> frankban: np
[13:37] <rogpeppe> frankban: ready to continue whenever you are
[13:39] <frankban> rogpeppe: joining
[13:54] <urulama> frankban: seems like local, amazon & openstack env work properly, while manual has the issue with the login in juju-gui
[13:54] <urulama> frankban: will test on some other machine, to see if i get the same error in manual env
[13:56] <frankban> urulama: ok, let me know if you see the same
[14:28] <hatch> morning all
[14:41] <frankban> morning hatch 
[14:41] <hatch> frankban I've gone through about 4 more versions of the 'runWhenCalled' testing implementation heh
[14:41] <hatch> and still need to do one more :)
[14:42] <frankban> hatch: after that, 3 more and I'd expect it to be just perfect
[14:44] <hatch> haha - well I need it to finish these tests so those iterations better come quick :)
[14:45] <hatch> the last iteration didn't work because it was hard to follow for many steps through the UI https://gist.github.com/hatched/087d9e30e3eb92a46657 see I added // #'s to illustrate that
[14:45] <hatch> the current one does away with all that so you can write them synchronously 
[14:46] <hatch> except for the initial async call has to be called last....which I don't like
[14:47] <hatch> frankban maybe you have a better idea https://gist.github.com/hatched/42e60957927b7caddd8b#file-test-js-L14
[14:48] <hatch> that's the current functionality
[14:49] <hatch> I like how it's written synchronously but it's the initial 'trigger' that has to be put at the end which is a little funky - I was considering adding a `runner.step()` method which would parse the steps first then run a `runner.start()` but that's adding even more code to the test runner which I was really trying not to do
[14:55] <hatch> jujugui call in 5
[14:59] <hatch> jujugui call in 1
[15:01] <hatch> jujugui call now
[15:08] <hatch> kadams54 https://plus.google.com/hangouts/_/gwrfc6s6hbqazst3ovh3uaypeua?authuser=1&hl=en
[15:09] <hatch> hurrroowwww
[15:19] <jcsackett> jujugui: sorry i missed call time. have been knocked offline for last 30min and lost my phone.
[15:19] <hatch> jcsackett np
[15:24] <kadams54> hatch: sooooo…
[15:24] <kadams54> hatch: it looks like we check for that 'new' prefix in other parts of the code
[15:24] <kadams54> And use it to make decisions about whether the machine is committed yet or not.
[15:24] <hatch> ok that's not going to work for the future
[15:25] <kadams54> What should we be doing?
[15:25] <hatch> we should inspect the model to see if it's a real-boy
[15:25] <hatch> later on we will add the ability to name machines
[15:25] <hatch> so we can't rely on a user input to know if something is new or not
[15:26] <kadams54> Well, it's not really user input, since it's a standard string we prefix to all machine IDs.
[15:26] <kadams54> (for uncommitted machines)
[15:26] <kadams54> The one advantage I see is that it means we don't have to do a DB lookup
[15:26] <hatch> right but that's not going to work
[15:27] <hatch> unless we have newthisismymachinename
[15:27] <hatch> or what if they name their machine 'newsuperbox'
[15:27] <kadams54> Name doesn't matter
[15:27] <kadams54> It's combining "new" + ID
[15:27] <kadams54> And I think ID is an auto-generated sequence?
[15:28] <hatch> can you link me to where this is happening
[15:29] <kadams54> Just grep through machine-view-panel.js for 'new' (with single quotes included in the search) - it happens all over the place in there.
[15:30] <kadams54> Also: I'm not seeing a connection between the IDs of committed machines and the IDs assigned to ghosted machines, which would mean more overlap.
[15:31] <kadams54> The ghosted IDs are assigned via the _ghostCounter, which is just set to 0 when a MachineList is instantiated.
[15:34] <hatch> but the name being displayed to the user is the id right?
[15:36] <kadams54> Not really
[15:36] <kadams54> It's just a temporary ID
[15:36] <kadams54> Which is created from 'new' + _ghostCounter
[15:37] <kadams54> And _ghostCounter has no connection to the actual IDs stored in the DB.
[15:37] <kadams54> So a machine could be new0 when created
[15:37] <kadams54> But 1 once actually deployed
[15:37] <jcsackett> hatch: i'm looking through your review, and i'm wondering, how would you feel about the various "createInspector" methods dealing with destroying the old one after they make a new one?
[15:37] <jcsackett> hatch: rather than the _inspector method tracking active and previous the whole way through?
[15:38] <jcsackett> at the point where we're, say, making createServiceInspector responsible for sorting out quite a bit about the state of the service inspector, it seems tidier to me.
[15:38] <hatch> kadams54 right, but what's being shown to the user? something is generating that
[15:38] <hatch> jcsackett hmm lemme take a look
[15:39] <kadams54> hatch: what's being shown to the user is exactly what I just said. 'new' + _ghostCounter
[15:39] <hatch> kadams54 so your card is simply deleting that 'new' ?
[15:40] <kadams54> Yes, and I'm saying it's not "simply" and we might want to re-think it.
[15:41] <hatch> you think that we should leave the 'new' prefix?
[15:41] <kadams54> 1) we have logic based on the 'new' prefix and 2) we'll end up with a confusing UX because the user will see two machines labeled "0" and the only diff between them is that one is blue.
[15:41] <kadams54> hatch: yes.
[15:42] <kadams54> hatch: keep the new prefix, unless there's a strong case for removing it. In which case we'll need to get creative with solutions.
[15:42] <hatch> 1) this is not going to work in the future, we can't rely on something saying 'new' if the user can enter their own names
[15:43] <hatch> 2) I propose that we dont' show id's at all for undeployed machines if we can't show a reliable id
[15:43] <hatch> new0 is just as confusing as 0
[15:43] <kadams54> hatch: is naming machines on the road map?
[15:43] <hatch> yes, it's even in the bug report...
[15:43] <kadams54> new0 isn't great…
[15:43] <kadams54> But it's better than 0
[15:43] <kadams54> It communicates something important about the machine's state
[15:44] <kadams54> Something that distinguishes new0 from 0
[15:44] <urulama> frankban: so, i've set up completely new set of machines for manual env and the "disappearing" password is no longer there. however, connecting to the juju environment fails now :(
[15:44] <hatch> kadams54 right, but new0 seems like it's a new version of 0, when in fact it's an entirely different machine
[15:45] <kadams54> hatch: I'll concede that point, but it's still better than having two machines labeled as "0"
[15:45] <kadams54> hatch: I don't like the way things currently work, but I don't think "simply" removing the "new" prefix is a step in the right direction.
[15:45] <hatch> jcsackett so instead of doing the previous inspector assignment in _inspector and then the previous.destroy in the _inspector you want to move that into the create methods?
[15:46] <jcsackett> hatch, i think so. can you chat for a moment?
[15:46] <hatch> kadams54 ok that's fine - so you need to send an email to design and peeps expressing your concerns and offering an alternative approach so that everyone can weigh in
[15:46] <hatch> jcsackett sure just one minute I need to relocate
[15:46] <kadams54> 1) We need to change the logic to look at a model attribute to determine uncommitted state and 2) we need to figure out how to differentiate (beyond blue color) ghosted machines from committed machines.
[15:46] <jcsackett> hatch: cool.
[15:46] <hatch> construction crews are making a ton of noise 
[15:47] <kadams54> hatch: will do.
[15:47] <jcsackett> always fun, the construction.
[15:47] <frankban> rbasak: quickstart 1.4.1 is on PyPI
[15:50] <hatch> jcsackett https://plus.google.com/hangouts/_/gs4t7bkjwkdpdylcfqa4a2nuwaa?authuser=1&hl=en
[16:14] <hatch> jcsackett ok creating a new hangout
[16:15] <hatch> jcsackett https://plus.google.com/hangouts/_/gvbizv4vjesvksrba5nljzslq4a?authuser=1&hl=en
[16:48] <hatch> kadams54 thanks for the email
[16:48] <kadams54> yup
[16:50] <hatch> kadams54 I usually add luca directly to these emails as I'm not sure  he's on peeps, maybe keep that in mind and ping him next time you see to make sure he got it
[16:50] <kadams54> Yeah, I CC'd him on this.
[16:50] <kadams54> Rick had mentioned the same.
[16:52] <hatch> oh I didn't see it in the list
[16:52] <hatch> maybe you bcc'd?
[16:53] <kadams54> From: Kyle Adams <kyle.adams@canonical.com>
[16:53] <kadams54> To: "juju-gui-peeps@lists.launchpad.net" <juju-gui-peeps@lists.launchpad.net>
[16:53] <kadams54> Cc: Luca Paulina <luca.paulina@canonical.com>
[16:53] <kadams54> I suspect the list stripped off the CC.
[16:54] <hatch> interesting I didn't know it did that
[16:54] <hatch> in fact I didn't think that it did heh
[17:33] <kadams54> Taking a lunch break…
[17:46]  * rogpeppe is done for the day
[17:46] <rogpeppe> g'night all
[18:01] <hatch> cya rogpeppe 
[18:01] <hatch> jujugui anyone around to take a look at a complicated test using my new 'resume' method? https://gist.github.com/hatched/a115fb081279c8856b9d
[18:01] <hatch> this technique now allows you to test async UI interactions by writing synchronous code
[18:08] <hatch> here is the changes to the utils methods and it in use https://gist.github.com/hatched/087d9e30e3eb92a46657
[19:54] <jcsackett> hatch: FYI, won't have branch up before my usual EoD. Doc appt has been 2.5 hours and ain't over yet. 
[19:54] <hatch> yikes, ok np
[19:55] <hatch> lots of waiting room?
[20:00] <hatch> jujugui looking for a review and qa https://github.com/juju/juju-gui/pull/425 plz and thanks
[20:01] <hatch> I'm blocked on my next task until that branch lands
[20:02] <hatch> well I can just continue from it, np
[20:50] <hatch> jujugui does anyone know how the user will 'scale-down' with the new scale-up UI?
[21:19] <rick_h__> bac: around? 
[21:25] <hatch> hmm, does anyone know why a simulate() call wouldn't work in IE in a callback?
[21:25] <hatch> rick_h__ no he is off today
[21:25] <hatch> ended up working Friday instead
[21:25] <rick_h__> hatch: ok cool
[21:25] <hatch> and wb to the real world
[21:25] <hatch> :)
[21:25] <rick_h__> hah, no kidding
[21:25] <rick_h__> wheeee
[21:25] <rick_h__> start driving home and all the emails start to arrive
[21:26] <hatch> haha, ding ding ding ding.......
[21:26] <rick_h__> there's still places out there with no cell connectino
[21:26] <hatch> yeah our cabin used to be one....unfortunately (fortunately?) it now has reception
[22:08] <hatch> well I'm totally baffled by this test failure
[22:08] <hatch> of course it has to be in IE10 too hah
[22:27] <hatch> hmm it happens in all versions of IE
[22:27] <hatch> even 11
[22:27] <hatch> kadams54 wb
[22:32] <hatch> well I'm at a total loss here maybe a night off will give me some fresh perspective 
[23:07] <huwshimi> Morning
[23:07] <rick_h__> morning huwshimi 
[23:07] <rick_h__> how goes?
[23:07] <huwshimi> rick_h__: Hey, good thanks. Have a nice break?
[23:12] <rick_h__> huwshimi: yea, have 996 pictures to go through :)
[23:12] <rick_h__> good times, a little crazy having no cell reception for days at a time
[23:12] <rick_h__> but was good and exhausting times in the woods
[23:13] <huwshimi> rick_h__: Great! It's cool to hear how you actually get away during your breaks :)
[23:14] <huwshimi> I guess that usually doesn't stop you from working though :)