[00:00] <huwshimi> jcsackett: Yay!
[00:01] <huwshimi> jcsackett: What's a service units?
[00:02] <huwshimi> *unit
[00:03] <huwshimi> jcsackett: Oh, I see what you're saying.
[00:38] <huwshimi> rick_h_: If you return I have some questions...
[01:03] <kadams54> Yay!
[01:05] <jcsackett> evening kadams54.
[01:06] <kadams54> So does this accomplishment include a PR that needs review/QA?
[01:08] <jcsackett> kadams54: hopefully, momentarily.
[01:08] <jcsackett> i'm figuring out how to test something.
[01:08] <jcsackett> then, yes.
[01:09] <jcsackett> kadams54: you going to be around for a bit?
[01:10] <kadams54> As long as it takes to wrap up work on my card
[01:12]  * jcsackett get zooming on tests
[01:15] <rick_h_> huwshimi: howdy
[01:15] <rick_h_> huwshimi: sorry, had a thing with the wife tonight. I meant to mention it when we talked earlier
[01:15] <huwshimi> rick_h_: It's all good, you've been working a lot :)
[01:16] <rick_h_> huwshimi: shoot me a hangout url if you want and I'll join in for questions
[01:16] <huwshimi> rick_h_: I just wanted to ask with the uncommitted stuff if there's actually anything that can be in an uncommitted state currently?
[01:16] <huwshimi> rick_h_: It doesn't look like we can add machines or containers yet...
[01:17] <rick_h_> huwshimi: no, but it's next. So I wanted to have the asset and css class ready to add to the tokens
[01:17] <rick_h_> huwshimi: so I figured we could look at styling the token and testing with it hard coded or something for the moment, so it's one less step one we can create them
[01:18] <huwshimi> rick_h_: Ah sure, I'll add some uncommitted states then.
[01:18] <huwshimi> rick_h_: Should I add another card just for the states then?
[01:18] <rick_h_> huwshimi: yea, and it's kind of shared between the uncommited machine and container
[01:18] <rick_h_> huwshimi: ? I thought I put your head on a card for the uncommitted state?
[01:19] <rick_h_> huwshimi: or you mean add a card for making the new machine work?
[01:19] <huwshimi> rick_h_: Oh, you did, but I thought I couldn't do it. I mean add a card just for the html/css work
[01:19] <rick_h_> huwshimi: ah gotcha
[01:20] <rick_h_> ok, that's fine
[01:20] <rick_h_> huwshimi: do you follow the d3 stuff to look at the card you've got now?
[01:21] <huwshimi> rick_h_: It looks quite a simple fix, unless I'm missing something: https://github.com/juju/juju-gui/pull/287
[01:22] <rick_h_> huwshimi: ooh, super awesome then
[01:22] <rick_h_> huwshimi: I'll check it out shortly then and QA it
[01:24] <huwshimi> rick_h_: Thanks.
[01:28] <huwshimi> rick_h_: In the mockups there are two uncommitted states. One with a blue background and one with blue circles next to the properties. Do you know the difference?
[01:35] <rick_h_> huwshimi: so they is supposed to be both that I'm aware of. /me goes to look at hte mockups
[01:36] <rick_h_> ah, these are out of date. So The blue is the background for new machines and new containers
[01:36] <rick_h_> the circle is used for a machine that exists, but contains an uncommitted service
[01:37] <rick_h_> so for the demo purposes we can get away with just the blue backgroud since both the machine and container will be new/uncomitted
[01:37] <huwshimi> rick_h_: OK
[01:40] <huwshimi> rick_h_: This isn't going to take long, anything in particular you'd like me to take a look at for this afternoon?
[01:48] <rick_h_> huwshimi: well I'm going to look through your branches and ant's and then try to wrap up mine. if you get time to check out ant's branch and QA and see how that looks that'd be good
[01:48] <rick_h_> there's some failing tests I'll help him get through
[01:48] <rick_h_> after this level of stuff we need to get the drag/drop of unplaced unit tokens to create the machine/container for the demo
[01:48] <rick_h_> but I think those have to wait until existing branches land
[01:49] <rick_h_> huwshimi: check outu https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1MmNDVXNoZDh3VFU/edit and see if we've got any missing UX bits you can see or point out
[01:49] <rick_h_> it's starting to blur a bit for me
[01:53] <huwshimi> rick_h_: I could create the 'new machine' and 'new container' forms ready to be hooked up?
[01:53] <huwshimi> (create the base widget/view and html/css etc.)
[01:56] <rick_h_> huwshimi: well so the demo is to drag over the header and the header will create the new uncommitted machine
[01:56] <rick_h_> so I think we'll just have to spin up a token, I'm not sure if the constraint stuff is there atm
[01:56] <huwshimi> rick_h_: Ah, so we'll by-pass those forms for now?
[01:57] <rick_h_> It's hard to see in his doc there
[01:58] <rick_h_> I think we'll drop, bring up a form to select constraints on the new machine and then go there
[01:58] <rick_h_> so there might be a 'part' of the machine token that needs doing there along the lines you're seeing
[01:58] <huwshimi> ok
[01:58] <huwshimi> rick_h_: I guess I can create the header states for dropping too.
[01:58] <rick_h_> huwshimi: cool
[02:05] <rick_h_> huwshimi: can you put some notes in the other pull request for me to know what's up in that review? The final machine view rendering/etc.
[02:05] <rick_h_> qa notes or anything I need for background
[02:07] <huwshimi> sure
[02:12] <huwshimi> rick_h_: Updated. Is that enough info?
[02:12] <rick_h_> cool thanks huwshimi
[02:15] <rick_h_> huwshimi: note added
[02:16]  * huwshimi looks
[02:18] <huwshimi> rick_h_: Card added.
[02:18] <rick_h_> huwshimi: thanks, there may be an existing test but want to make sure we go back on it if not
[02:19] <huwshimi> rick_h_: Yep, np. I don't remember there being any tests
[02:54] <huwshimi> bbs lunch
[03:00] <jcsackett> kadams54: don't know if you're still up, but you won't see a PR from me tonight. rebase just did something awful and i'm too tired to sort it.
[03:01] <kadams54> Gah! Alright man, get a good night's sleep.
[03:31] <kadams54> huwshimi: if you're interested, just put up https://github.com/juju/juju-gui/pull/289 which is the animation cleanup stuff that was started in the sprint.
[03:34] <rick_h_> thanks kadams54
[03:34] <rick_h_> kadams54: can you rebase that down please?
[03:34] <kadams54> Yeah, planning on it.
[03:35] <rick_h_> kadams54: cool thanks
[03:37] <huwshimi> kadams54: Great, I'll take a look
[03:53] <huwshimi> kadams54: QA looks good.
[03:53] <kadams54> woot
[04:29] <huwshimi> Ugh, looks like selenium is killing our ci again.
[04:30] <rick_h_> huwshimi: it's my fault
[04:31] <rick_h_> huwshimi: there's a flaky test in ant's branch I'm trying to work around
[04:31] <huwshimi> rick_h_: Oh, that's ok then :)
[04:31] <rick_h_> yea, it's all my doing and I'm watching it closely
[04:32] <huwshimi> Ah good
[04:32] <huwshimi> I only noticed it in that branch anyway
[05:35] <rick_h_> finally!
[05:35] <rick_h_> ok, off to bed for me. Thanks for the great work huwshimi. We're actually going to be closer than I thought we'd be. Might be able to make it with some weekend work
[05:36] <huwshimi> rick_h_: Great!
[05:36] <huwshimi> rick_h_: Goodnight :)
[06:54] <huwshimi> rick_h_: I tried to figure out this bug, but not sure what's going on: https://bugs.launchpad.net/juju-gui/+bug/1317766
[06:54] <_mup_> Bug #1317766: Hardware info not available when a machine is first added <machine-view> <juju-gui:New> <https://launchpad.net/bugs/1317766>
[11:58]  * frankban lunches
[12:03] <rick_h_> morning
[12:28] <antdillon> rick_h_, morning
[12:28] <rick_h_> howdy antdillon
[12:30] <antdillon> rick_h_, It seems like the summary panel should be its own view?
[12:31] <rick_h_> antdillon: well, my first thought was that the deployer bar would launch it and watch it for the deploy button or cancel button and update itself based on that interaction
[12:32] <rick_h_> antdillon: so I'm ok with it being a view on its own, but I think the deployer bar needs to create, watch it, and then handle it
[12:33] <rick_h_> antdillon: but to start out with you could wire it into the deployer bar view, create a new template, a 'onDeployClick' handler that creates a new div floating with the template info rendered
[12:33] <rick_h_> there's not a ton in that popup for this demo. Just a list of the two services and such
[12:33] <antdillon> rick_h_, Yeah  sure
[12:33] <rick_h_> so rather start small and iterate
[12:34] <antdillon> Cool
[12:34] <rick_h_> so I'd rather start small/simple and iterate if that makes sense
[12:34] <rick_h_> but tell me if I sound crazy, still waking up
[12:34] <antdillon> yeah, i'll get it working from the deployer bar. shouldnt be hard to split out later if we need
[12:49] <rick_h_> frankban: starting qa, we'll try to round up one or two others to make sure we hit it all
[12:50] <frankban> rick_h_: thanks
[12:50] <rick_h_> morning luca
[12:50] <rick_h_> luca: is this meeting something we need to do today or can we bumb it post-demo on tues?
[12:51] <luca> rick_h_: I was literally just about to cancel
[12:51] <rick_h_> luca: <3
[12:51] <luca> rick_h_: hehe
[12:57] <jcsackett> morning all.
[12:57] <rick_h_> morning jcsackett
[13:00] <rick_h_> frankban: qa ok and thanks for making me find a couple of other issues :)
[13:00] <redir> morning
[13:01] <frankban> rick_h_: thanks for QAing I also filed two new bugs related to the left inspector
[13:01] <jcsackett> rick_h_: so, i seem to now only have "view" access to the juju ui calendar--it won't let me make or move an appointment. though it did let me delete it. very strange.
[13:01] <rick_h_> frankban: yep, putting them on the board as well
[13:01] <rick_h_> jcsackett: :/ ok will look
[13:01] <frankban> rick_h_: mine are already on the board
[13:02] <frankban> rick_h_: in backlock/deck
[13:02] <rick_h_> frankban: oh ok cool then
[13:07] <kadams54> guihelp Got a PR that needs review (and more QA wouldn't hurt either): https://github.com/juju/juju-gui/pull/289
[13:08] <rick_h_> kadams54: yea, all branches need one review and one qa to start
[13:09] <rick_h_> kadams54: I'll peek in a bit thanks for the ping.
[13:09] <kadams54> rick_h_: Looking for another card. Got any suggestions?
[13:09] <rick_h_> antdillon: how are you doing? Need a hand with anything? kadams54 might be able to?
[13:10] <antdillon> rick_h_, All good, styling up the panel now
[13:10] <rick_h_> kadams54: some more qa on frankban's branch would be good, helping out antdillon on the summary view, or looking at the "do not load the real inspector after the deploy" card
[13:10] <rick_h_> kadams54: are the top of the list atm
[13:11] <kadams54> kk
[13:11] <kadams54> frankban: https://github.com/juju/juju-gui/pull/282 right?
[13:11] <frankban> kadams54: yes thanks
[13:14] <rick_h_> kadams54: added another bug card that should be a nice one to look at around the missing hardware info.
[13:16] <jcsackett> ...nothing like figuring out conflicts when all the code you were working on gets smashed by other code...
[13:16] <rick_h_> jcsackett: that smashed/
[13:16] <rick_h_> ?
[13:30] <frankban> guihelp: I have three QA ok for my branch. Can I assume I also have a +1 to land the code?
[13:30] <rick_h_> frankban: just did it
[13:31] <rick_h_> frankban: so got you in line after huw's two
[13:31] <frankban> rick_h_: :-) cool thanks
[13:31] <redir> bac: yt?
[13:33] <bac> redir: hib
[13:36] <redir> bac: I had no problem getting the local demo going. heartbeat shows 3 fails: API* interesting and bundles collection. It is still ingesting though.
[13:36] <rick_h_> redir: yea, bundles ingest last and part of insteresting is having featured which you don't get oootb
[13:36] <redir> so it works
[13:36] <bac> redir: that is good
[13:37] <bac> redir: thanks for proofing that doc.  i thought things may have changed since it was written.
[13:37] <redir> np
[13:38] <redir> I did kill my net and verify that I could find charms too.
[13:38] <redir> FWIW
[13:38] <rick_h_> woot
[13:39] <jcsackett> rick_h_: it's moderately awful. virtually every function i touched has been modified in landed branches. every step has non trivial conflicts.
[13:39] <rick_h_> jcsackett: ok, let me know if you want to run through it in a pair for an extra set of eyes
[13:39] <rick_h_> jcsackett: and :( that we managed to overlap that much
[13:40] <jcsackett> rick_h_: looks like it's fallout from the "don't re-render the entire machine view" and the bit that gets units on machine tokens.
[13:40] <jcsackett> so maybe once i'm done touching those bits the rebase will calm down.
[13:44] <rick_h_> jcsackett: cool
[13:57] <hatch> luca was our call to be rescheduled?
[13:58] <luca> hatch: I cancelled it because I didn’t want to take up your time when your all so busy
[13:58] <luca> hatch: it’s low priority for the time being so we can do it some other time
[13:58] <hatch> alright no problem
[14:01] <rick_h_> kadams54: heads up, that bad machine data shows up in a live lxc deploy as well. So we need to hit it from both a new server note deployed yet, and an existing lxc one without that data
[14:02] <kadams54> ok
[14:02] <kadams54> rick_h_: Would be good to have a pre-impl chat
[14:03] <rick_h_> ugh, we need cleaner ghost names for services now. 6349192$:db → 63449111$:slave lol
[14:03] <rick_h_> kadams54: k, shoot me a link
[14:04] <kadams54> rick_h_: https://plus.google.com/hangouts/_/72cpikalb7ek14gkppcfots2so
[14:11] <kadams54> I am hungry for lunch.
[14:11] <kadams54> At 10 AM.
[14:11] <kadams54> Clearly I am missing the Vegas brunch buffets.
[14:11] <kadams54> ;-)
[14:12] <rick_h_> frankban: do you have time to look at esc-enabling the add-unit call in the env ?
[14:13] <hatch> kadams54 haha
[14:13] <frankban> rick_h_, kadams54: FYI lxc containers only provide arch
[14:13] <frankban> rick_h_: add_unit in ecs?
[14:13] <rick_h_> frankban: yea, so we're just going to go with "Hardware characteristics unavailble"
[14:13] <rick_h_> frankban: add_unit in the env needs to go through the ecs and then be added to your unit list as a ghost?
[14:13] <frankban> rick_h_: is there a UX reason why we don't show machines' architetcure?
[14:14] <rick_h_> frankban: just wasn't on the list from UX
[14:14] <rick_h_> frankban: I think it's rare for them to vary a lot in an env so it's repeat info
[14:15] <frankban> rick_h_: ok, so in mass scale when we add units we need 1) to create unplaced units in the db and 2) to register corresponding calls on ecs right?
[14:16] <rick_h_> frankban: well, I'm thinking all around. When we drag/drop a service we'll create a new service (ghost) but it won't show up in machine view as an unplaced unit unless there's also a ghost-unit on that service
[14:16] <rick_h_> frankban: so it would work for both the mass scale up, but also just for the demo path of drag/drop a service
[14:16] <rick_h_> is what I'm thinking
[14:17] <rick_h_> frankban: and then the machine view panel, watching that new unit list, would update the list of unplaced units in the UI
[14:18] <frankban> rick_h_: sounds good, I'll tackle that once the units branch is landed. is there a card for that?
[14:19] <rick_h_> frankban: there is now
[14:19] <frankban> cool thanjks
[14:19] <frankban> thanks even
[14:19] <rick_h_> frankban: cool, your branch should land in about 15min
[14:19] <rick_h_> it's running through now
[14:19] <frankban> yeah
[14:24] <hatch> luca maybe we should also add to this naming thing other 'required' settings too
[14:28] <luca> hatch: ok will do
[14:29] <hatch> luca, so if I drag a service to the canvas and then click the 'deploy' should it auto put the unplaced unit on a machine?
[14:29] <hatch> I'm working on this interaction right now
[14:29] <rick_h_> hatch: for the demo what we're doing is to create a ghost service with a single unit that frankban is going to make a ghost-unit
[14:30] <rick_h_> hatch: using the add_unit call, like the mass scale up
[14:30] <hatch> ok, and for the not-demo?
[14:31] <rick_h_> hatch: we'll implement the scale up journey in the inspector for existing services and we're in talks with luca on the path for non-existing services
[14:31] <rick_h_> hatch: probaly on the deployment confirmation page asking you to go and place those units or something
[14:31] <rick_h_> hatch: but there's some workflow TBD there
[14:31] <hatch> oh...ok
[14:32] <rick_h_> the 'no inspector' was new in vegas and we've not had time to chase the path all the way through yet
[14:33] <hatch> ok, I've just removed the inspector opening from the charmbrowser right now and I've been finding all of these use cases which seem broken now
[14:33] <hatch> so that's why Im' asking heh
[14:33] <rick_h_> hatch: definitely
[14:33] <rick_h_> hatch: and we'll be asking luca a lot...wed :)
[14:34]  * hatch shakes fist like an 80s cartoon baddie....."and he better have answers"
[14:34] <luca> rick_h_: hatch haha We’ll see how the no inspector thing works out
[14:34] <luca> rick_h_: hatch I would like to test it and see how it feels
[14:35] <rick_h_> luca: yep
[14:35] <hatch> atm, not very good :P
[14:35] <luca> hatch: f u :P
[14:35] <hatch> lol!
[14:37] <rick_h_> frankban: landed woot
[14:37] <rick_h_> jcsackett: Makyo frankban's branch has hit for a nice rebase from develop
[14:37] <frankban> rick_h_, hatch: thinking about add_unit: I guess we'll need an important change when under mv flag: currently when we deploy from the inspector we pass the provided units to env.deploy. this means right now with a single call we deploy the service, add machines and place units to those machines. we need to instead deploy with numUnits=0, then have the ecs calls reflect this dependency chain: deploy -> addMachines -
[14:37] <frankban> > place units
[14:38] <rick_h_> frankban: hmm, can we update the ecs deploy to add the ghost service we need using the existing path?
[14:39] <rick_h_> frankban: I mean the add_unit needs to be ecs-able, but that's mainly for scaling exisint units which we can come back to if it's not in the line of sight we need for the demo
[14:39] <rick_h_> existing
[14:39] <hatch> from what I understand, the deploy will now do nothing but create an unplaced unit
[14:40] <hatch> so the user will have to take 3 extra steps in this new UI
[14:40] <rick_h_> hatch: right, but hte service needs to be there as well so that you see it in the service view and when you hit deploy you get the service info
[14:40] <rick_h_> hatch: right, from the UI perspective right now yes
[14:41] <jcsackett> rick_h_: whoo!
[14:41] <frankban> rick_h_: if we need a ghost service that's doable, but when we click deploy we still need things to happen in a specific order
[14:41] <hatch> yeah we still need the ghost
[14:41] <rick_h_> frankban: right, which is why I'm wondering if we can work with the current chain
[14:41] <rick_h_> frankban: hatch hop on the standup call early?
[14:41] <hatch> sure
[14:41] <hatch> ecs supports this type of requirement
[14:41] <frankban> sure
[14:42] <hatch> so we can modify the ecs deploy to add a machine if it doesn't have one
[14:42] <hatch> I think anyways....
[14:42] <hatch> oh hmm
[14:42] <hatch> maybe not...
[14:42] <rick_h_> forget the machine part for now, it'll be manually done and its own ecs line item before services go onto it
[14:43] <hatch> ok ecs doesn't support adding machines right now
[14:44] <rick_h_> right, but the env has the call and it's next on the list
[14:44] <rick_h_> hatch: coming on the call?
[14:44] <hatch> oh, I wasn't sure HOW early
[14:44] <hatch> haha omw
[14:58] <jcsackett> jujugui: call in 2.
[15:01] <rick_h_> jujugui call now
[15:01] <rick_h_> antdillon: you're welcome to join https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
[15:02] <antdillon> rick_h_, Sure
[15:18] <hatch> rick_h_ I was joking about it being Makyo's fault :) but you will probably want to start with the code in ghost-service-inspector.js line 185
[15:18] <Makyo> Whew!
[15:18] <hatch> that's where it determines if it should open an inspector or not after clicking deploy
[15:18] <rick_h_> hatch: yep, will do. I was going to start hunint down anything that creates an inspector
[15:18] <hatch> the odd part is that it also opens the machine view
[15:18] <hatch> so there are some crossed wires there somewhere
[15:18] <rick_h_> yea, will look
[15:22]  * rick_h_ goes for a little walk for a breather. biab
[15:34] <hatch> jujugui lf a really quick review/qa https://github.com/juju/juju-gui/pull/292
[15:36] <hatch> kadams54 when you get a chance can you rebase your animation branch into logical commits plz
[15:37] <kadams54> hatch: Well now, that's pretty subjective :-) Yeah, I'll rebase it down.
[15:37] <hatch> haha - I consider a logical commit one that, when landing on in a bisect, doesn't break :)
[15:41] <kadams54> Done
[15:42] <kadams54> hatch: --^
[15:53] <hatch> kadams54 thx, review done with trivial
[15:53] <hatch> s
[15:54] <hatch> jujugui so do we have unplaced units now on develop?
[15:55] <frankban> hatch: we have a db.units model list. so if you use db.addUnits passing a unit with no machine field it is unplaced
[15:56] <hatch> ok but the UI isn't hooked up to that yet
[15:56] <hatch> correct?
[15:56] <hatch> antdillon I just saw the work you did, gw thx
[15:57] <frankban> hatch: in the machine view panel I see this.get('db').serviceUnits. it should be this.get('db').units;
[15:57] <antdillon> antdillon, Thanks, little quick
[15:58] <antdillon> antdillon, Should have the deply summary with you shortly
[15:58] <frankban> hatch: we also have db.units.filterByMachine(null) which returns all unplaced units
[15:58] <hatch> frankban yeah ok, I'll take that card to hook the UI up
[15:58] <hatch> antdillon talking to yourself? ;)
[15:58] <antdillon> hatch, long week
[15:58] <hatch> lol
[16:03] <rick_h_> hatch: you rerunning your tests? That's a spurious IE10 one that hit you
[16:03] <rick_h_> hatch: do you have a reviewer for yours yet or still need one?
[16:04] <frankban> rick_h_, hatch: maybe we have a conceptual problem here: to create a new container in the juju-core API we must call addMachines([{parentId: '1', containerType: 'lxc'}]). As you can see, we must know the parentId. Assume (like in the demo) we create a new machine and then a container in that machine. For the second call we must know the id of the machine in the first call. And we only know that when the first call
[16:04] <frankban> returns data.
[16:04] <hatch> rick_h_ I don't think anyone stepped up yet
[16:04] <hatch> I can re-run it
[16:04] <rick_h_> hatch: k, will look
[16:04] <hatch> thx
[16:05] <rick_h_> frankban: :/ so we have this with services and relations right? We use the temp service name and update it?
[16:05] <hatch> what he said
[16:05] <hatch> :)
[16:05] <jcsackett> rick_h_: ok, i've fixed up the merge of doom, but we have a problem that may or not be minor.
[16:05] <frankban> rick_h_: for services we already know the service name at the time of the deploy call (we provide the service name)
[16:05] <rick_h_> frankban: can the ghost machine (representing the container) have a ghost id that's 9999 or z1 or something?
[16:06] <rick_h_> frankban: and have that updated when we get the parent call back with the new model data?
[16:06] <rick_h_> jcsackett: heh, hit me.
[16:07] <rick_h_> frankban: if not, can we mold the demo so that he first creates the machine and then goes back to create hte container as as second step and be ok?
[16:07] <jcsackett> rick_h_: so, the logic that now updates the machine tokens only fires when a machine is added--not when a container is.
[16:07] <jcsackett> so we don't get new service icons on the machine tokens as they're added.
[16:07] <jcsackett> you can  see them just fine if you click the machine and get the containers, but you'll only see the first service unit icon on the machine token.
[16:07] <rick_h_> "Hey, let's go deploy mysql, create a new machine yay" hit deploy, go watch it come up in service view, "now let's deploy phpmyadmin, but in a container on that machine" frankban
[16:07] <rick_h_> jcsackett: a container is a machine
[16:08] <rick_h_> jcsackett: so it should fire if I understand things correctly
[16:08] <hatch> frankban There is a callback which is called after each task executes so we should be able to parse out the new machine names there.... Makyo  this is supported with your executioner right?
[16:08] <jcsackett> rick_h_: nope. machine tokens are only updated when what the machine view sees as a machine is added.
[16:08] <jcsackett> (or removed)
[16:08] <rick_h_> jcsackett: right, but a container is just a machine with a parent id
[16:09] <rick_h_> jcsackett: so can we not either listen more closely on machine update?
[16:09] <jcsackett> shorter answer: containers being added to not update machine tokens.
[16:09] <rick_h_> jcsackett: or something
[16:09] <jcsackett> rick_h_: we can, i'm just updating you on the branch.
[16:09] <rick_h_> jcsackett: ok thnking
[16:09] <jcsackett> as it expands into endless changes. :p
[16:09] <frankban> rick_h_, hatch looking at the ecs code
[16:09] <rick_h_> jcsackett: ok, that's fine. It's a step forward and we can hit it up as follow up
[16:09] <jcsackett> rick_h_: so put it up for review?
[16:09] <rick_h_> jcsackett: yes
[16:09] <rick_h_> let's keep the chunks moving
[16:09] <jcsackett> rick_h_: got it.
[16:10] <rick_h_> jcsackett: just add a card at the end of the line, but leave it in the ready to code in case we can get to it
[16:10] <rick_h_> jcsackett: a quick test if a flash back to service view and back to machine view helps the situation?
[16:10] <hatch> frankban thanks, Makyo did the execution stuff but I remember he built on the callback wrapper which I added already to progress each item in the graph
[16:11] <rick_h_> jcsackett: e.g. "in the demo, go look at the new block here and back to machine view to get the updated UI"
[16:11] <rick_h_> jcsackett: the old trick them by never keeping your hands still enough for them to track :)
[16:14] <jcsackett> rick_h_: i'll check that.
[16:14] <jcsackett> ...i think that should work, actually.
[16:18] <rick_h_> hatch: qa issue with your branch, I can't add the relation
[16:18] <rick_h_> hatch: it needs to also trigger the deploy button function in the inspector
[16:19] <hatch> ohh ok
[16:19] <hatch> my bad
[16:19] <rick_h_> hatch: so the qa steps I'm trying is "drag/drop mysql, drag/drop mediawiki, relate them, go to machine view, hit deploy button, go back to service view"
[16:19] <hatch> ahhh this UX is so messing with my head
[16:19] <rick_h_> hatch: yea, undersstand
[16:20]  * hatch whispers to himself, it's just a demo, it's just a demo
[16:20] <hatch> :D
[16:20] <rick_h_> yea, just a demo behind feature flags
[16:20] <hatch> ok sorry I'll add that in
[16:20] <rick_h_> thanks
[16:22] <rick_h_> jcsackett: for the follow up tests add a card please and mark it high priority
[16:22] <rick_h_> jcsackett: in the on deck lane in backlog
[16:22]  * jcsackett nods
[16:23] <jcsackett> rick_h_: for the next thing shall i go ahead and jump on the service units updating on machine token?
[16:23] <rick_h_> jcsackett: no, hatch did you add the card for showing the unplaced units?
[16:23] <Makyo> rick_h_, Man, ec2 is slow today.  Confirmed that services are now placed with annotations.
[16:23] <hatch> rick_h_ I put my head on it, but I wont be able to start on it for a bit
[16:24] <rick_h_> jcsackett: that card can wait if we've got the "flip views" workaround. We need to get unplaced units showing asap and then start the drag/drop work
[16:24] <rick_h_> hatch: k, jcsackett can you start with ^
[16:24] <rick_h_> jcsackett: notes that frankban noted how to update it in irc above ^
[16:25] <hatch> oooo boy this is quite a bit more work than I had thought......
[16:26] <jcsackett> hatch: everything on this is more work than we thought. :p
[16:26]  * rick_h_ ponders evil evil ness
[16:26] <hatch> haha
[16:26] <rick_h_> hatch: so let's just say....
[16:26] <jcsackett> rick_h_: i'm fixing some lint and goofiness on my PR, then i'll check the flip views workaround.
[16:26] <rick_h_> hatch: that we render the inspector off screen, simulate click deploy button, simulate click close button, carry on
[16:27] <rick_h_> bah, can't do that
[16:27] <rick_h_> when he clicks on the service to make the relation it'll blow up
[16:27] <hatch> it should be ok, just more work than I thought
[16:27] <hatch> because we parse the UI for the config options now
[16:27] <rick_h_> hatch: ok
[16:28] <frankban> rick_h_, hatch: assume you add two machines and then a container to the first one: from the environment perspective (go.js) we only see something like: addMachines([{}]); addMachines([{}]); addMachines([{containerType: 'lxc', parentId: ?????}]). I can surely add a change focused on the demo (assume the machine added will be the "1") but in general the current design should be improved in some way AFAICT
[16:28] <rick_h_> hatch: yea, was worried about that. Can we jsut not pass for defaults
[16:28] <hatch> I've got to compare the formatting but I think we can just pass in the defaults if everything maps correctly
[16:28] <rick_h_> frankban: agreed, I think we could look at adding a new method like addContainer that can keep some metadata to help track things
[16:29] <rick_h_> frankban: or update the ecs to start to tag items with a unique id and parentid turns into a ecs parent id?
[16:29] <hatch> frankban yes the add machine ecs call should generate a uuid for the machine id when it's a 'ghost' machine which others can reference for it's parents
[16:29] <hatch> uid? uuid? id?
[16:29] <rick_h_> so ecs adds machine one and gives it and id $@!# and then the second one gets *(U&& and when you add the container the parent is $@!#
[16:29] <hatch> d?
[16:29] <hatch> ?
[16:29] <hatch>
[16:30] <kadams54> guihelp https://github.com/juju/juju-gui/pull/294 is a short QA/review
[16:30] <rick_h_> kadams54: will look in a sec
[16:30] <hatch> rick_h_ were you just swearing a lot there? :P
[16:30] <rick_h_> hatch: :P
[16:30] <Makyo> kadams54, rick_h_  on it - throw reviews my way.
[16:31] <rick_h_> Makyo: k
[16:31] <rick_h_> Makyo: so is your wip card jc's as well?
[16:31] <rick_h_> they can both go to reviwe?
[16:31] <rick_h_> review
[16:32] <Makyo> rick_h_,  I believe the icons-in-tokens work is one branch, so the two have merged.
[16:32] <rick_h_> Makyo: k
[16:32] <jcsackett> rick_h_: that's correct--i was doing the exact same thing for both tokens so threw my head on it too.
[16:35] <jcsackett> rick_h_: checking the "flip" now.
[16:37] <Makyo> kadams54, +1
[16:37] <kadams54> Sweet, thanks
[16:38] <kadams54> Ah hah… poor Jenkins: http://cl.ly/image/2H0I2N3z1e19
[16:39] <rick_h_> heh, scale scale!
[16:39] <kadams54> Well then, I'm going to go get lunch. Hopefully I'll have two successfully built branches ready to ship when I get done.
[16:40] <rick_h_> jcsackett: :1:'d
[16:40] <jcsackett> rick_h_: is that thumbs up?
[16:40] <rick_h_> jcsackett: yes
[16:40] <jcsackett> rick_h_: flipping works.
[16:41] <rick_h_> jcsackett: ok awesome, good to know
[16:41] <rick_h_> we'll have to remember that when we get the script going
[16:41]  * jcsackett nods
[16:41] <kadams54> rick_h_: any prefs on what card to tackle next? Looking at the two drag-n-drop ones right now…
[16:42] <rick_h_> kadams54: well those need jc's to have tokens to drag/drop
[16:42] <rick_h_> kadams54: go grab lunch and we'll organize around seeing tokens and drag/drop when you get back
[16:42] <kadams54> OK
[16:42] <jcsackett> hm. lunch. there's a good idea.
[16:44] <jcsackett> rick_h_: so, last test run failed, make check passes, shall i just :shipit: so kadams54 and others can start work?
[16:44] <rick_h_> jcsackett: why did it fail?
[16:44] <rick_h_> jcsackett: I see lint issues
[16:45] <jcsackett> rick_h_: right, which i fixed in a subsequent push, thus make check is working now. i'm happy to wait for CI to catch the new changes and update.
[16:45] <rick_h_> jcsackett: oh, gotcha. Sure
[16:45] <jcsackett> ...we just seem to be in a sort of panicy hurry. :p
[16:45] <rick_h_> well let's not panic.
[16:45] <rick_h_> but not waste any time :)
[16:47]  * jcsackett laughs
[16:47] <jcsackett> a *non-wasteful* hurry, then. :p
[16:54] <Makyo> jujugui What's a good next card, or does anyone need a second set of eyes?
[16:55] <frankban> Makyo: I am near my EOD, so if you want to continue my work we can have a quick call
[16:55] <rick_h_> Makyo: frankban +1
[16:55] <hatch> Makyo in your ghost relations did you ever run into an error "Charm not loaded" ?
[16:55] <Makyo> frankban, sounds good.
[16:55] <frankban> Makyo: cool
[16:55] <Makyo> hatch, not really, no.
[16:55] <hatch> ok np
[17:00] <frankban> Makyo: the branch is in https://github.com/frankban/juju-gui/tree/more-ecs-calls .  I am in https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
[17:07] <jcsackett> guihelp: ci is complaining about my branch in a way i cannot reproduce locally. http://ci.jujugui.org:8080/job/juju-gui/933/console
[17:07] <hatch> oh that error
[17:08] <hatch> jcsackett it's a sauce labs issue
[17:09] <hatch> there is actually some poorly written code somewhere in python land
[17:09] <rick_h_> jcsackett: yea, spurious sauce labs issue
[17:09] <rick_h_> jcsackett: just kill the "merge request accepted" and let it pick it up again
[17:09] <hatch> I traced it down at some point but wasn't sure the proper way to fix it
[17:10] <rick_h_> we're hammering on CI and sauce hard today so spurious seems a bit not so spurious today
[17:10] <hatch> I wonder if we paid for sauce if we would get better service
[17:10] <hatch> or if it's the same for open source vs not
[17:10] <rick_h_> possibly for sure
[17:12] <rick_h_> jujugui I'm going to go pick up my camper from the dealer and bring it back. I'll be back in a bit. I've given up my card to take one to write out the demo.
[17:13] <rick_h_> jujugui the next things are getting the unplaced tokens and then drag/drop to call the add_machine calls in the env.
[17:13] <antdillon> rick_h_, I'm going to sumbit my branch now
[17:13] <rick_h_> antdillon: awesome, kadams54 when you get back from lunch can you look that over, look at possible tests, and qa that ^  please?
[17:14] <rick_h_> jujugui if anyone has a question or issue while I'm afk call me<PHONE_NUMBER>
[17:14] <hatch> so trusting....so so trusting
[17:14] <hatch> "for a good time call...."
[17:14] <rick_h_> :P
[17:14] <hatch> haha
[17:14] <rick_h_> I <3 everyone here :P
[17:17] <hatch> Makyo I can't seem to get add_relation to work on comingsoon via the ecs
[17:17] <hatch> this did work at one point right?
[17:17] <hatch> I can probably bisect to find the issue
[17:18] <rick_h_> hatch: it does work now. I tested it this morning
[17:18] <hatch> on comingsoon?
[17:18] <hatch> I drag mysql and wordpress, long click, relate, then click Deploy
[17:18] <hatch> then I get Uncaught TypeError: Cannot read property 'command' of undefined
[17:19] <rick_h_> bah, yea something broken just today
[17:19] <hatch> poop
[17:19] <hatch> ok I'll track this down
[17:19] <rick_h_> oh, reloaded and it worked
[17:20] <rick_h_> cache/js issue?
[17:20] <rick_h_> so just worked for me on comingsoon
[17:20] <rick_h_> http://comingsoon.jujucharms.com/:flags:/il/mv/ deploy and all
[17:20] <hatch> yeah ok works now
[17:20] <hatch> what the heck hah
[17:20] <jcastro> rick_h_, rails bundles still missing for me on jujucharms.com
[17:20] <hatch> ok I'll update my branch
[17:21] <rick_h_> jcastro: ok
[17:21] <jcastro> rick_h_, ok weird
[17:21] <rick_h_> jcastro: if you get time try it as a differnet branch vs in the same. something is odd, but we keep working on it and then it shows up
[17:22] <rick_h_> jcastro: but we're in pure demo mode through the weekend until Tues so no bandwidth to look until after Tues
[17:22] <jcastro> ack, I am also in demo mode to make a bundle, lol
[17:22] <rick_h_> :)
[17:22] <rick_h_> we think there's something with the multiple bundles in a file but can't prove it
[17:23]  * rick_h_ goes afk now for a few
[17:23] <antdillon> rick_h_, kadams54 deploy summary branch https://github.com/juju/juju-gui/pull/295
[17:31] <jcastro> does anyone know how I can deploy a personal branch from the gui to the canvas?
[17:31] <jcastro> http://manage.jujucharms.com/~michael.nelson/precise/elasticsearch
[17:32] <jcastro> I can't find that branch in the gui
[17:35] <hatch> jcastro download the charm as a zip?
[17:35] <jcastro> nm, I had "elastic search" in my terms instead of "elasticsearch"
[17:36] <hatch> oh :)
[17:36] <jcastro> - _ -
[17:38] <kadams54> Back from lunch. Looking at antdillon PR.
[17:43] <kadams54> guihelp Anyone else been experiencing flakiness with their icons? I've been seeing stuff like this since mid-sprint: http://cl.ly/image/452g3m461j2M
[17:44] <hatch> can't say I've seen that
[17:45] <jcsackett> kadams54: yeah, i don't have that happen.
[17:45] <jcsackett> kadams54: local, on jujucharms.com, both?
[17:45] <kadams54> local… haven't checked upcoming…
[17:45] <jcsackett> kadams54: i would guess than that it's something on your vagrant/host issue.
[17:46] <kadams54> Probably
[17:50] <hatch> sweet got the bug
[17:50] <hatch> kadams54 time to install 14.04 on metal - on your machine there are lots of drivers for it
[17:51] <hatch> so you won't run into the same issues I'm having
[17:53] <kadams54> I wish JS had string substitution…
[17:54] <hatch> it....does?
[17:54] <hatch> kadams54 what are you trying to do?
[17:55] <kadams54> https://github.com/juju/juju-gui/pull/295/files#diff-e6baa739d19ae967f00d894884a065acR265
[17:55] <hatch> so you want to do something like a printf instead?
[17:56] <kadams54> In python, I'd handle that like so:
[17:56] <kadams54> url = 'https://manage.jujucharms.com/api/3/charm/precise/%s/file/icon.svg'
[17:56] <kadams54> single = dict(icon=url % ecs.changeSet[key].command.args[1],
[17:56] <kadams54>               name: ecs.changeSet[key].command.args[1])
[17:56] <kadams54> Yes
[17:57] <kadams54> Much nicer way of inserting vars into long strings
[17:57] <hatch> http://yuilibrary.com/yui/docs/api/classes/Lang.html#method_sub
[17:58] <hatch> it's not quite the same, but close
[17:58] <hatch> enough
[17:58] <kadams54> Oh sure, there are plenty of libraries that add the capability
[17:58] <kadams54> I just wish it was baked in
[17:59] <hatch> yeah....js is missing....everything
[17:59] <hatch> lol
[17:59] <kadams54> I wish python had JS' more flexible lambda function
[18:00] <hatch> but at least the prototypal system is very flexible
[18:00] <kadams54> And I wish JS had python's list comprehensions, string substitutions, and syntactical succinctness
[18:01] <kadams54> But they're just never going to hook up and make babies, so all I can do is hang my hopes on ECMAScript 6/7/8 :-)
[18:01] <hatch> haha
[18:01] <hatch> maybe by 2020 it'll be caught up
[18:02] <hatch> but by then Dart will be in all the browsers and people will use it instead.....*snort*
[18:02] <kadams54> I'm pretty sure that by 2020 we'll be mired in WW3
[18:02] <kadams54> After which JS will be everywhere and dead at the same time
[18:03] <hatch> yeah you're probably right on that
[18:03] <kadams54> No, no… Bernhardt's right.
[18:04] <hatch> I don't get the reference
[18:05] <kadams54> https://us.pycon.org/2014/schedule/presentation/186/
[18:05] <kadams54> Pretty sure you saw the video of this talk?
[18:05] <hatch> oh yeah
[18:14] <hatch> apparently deploying a service with 0 units is a nono
[18:16] <kadams54> Were explosions involved?
[18:18] <hatch> not sure, I walked away, cool guys don't look at explosions
[18:20] <hatch> Makyo you kickin around?
[18:21] <hatch> Makyo when you get a chance do you remember what lines 39-45 are for? https://gist.github.com/hatched/cdc73083450dc0eaa02b I've rewritten this callback handler and it doesn't seem like they have any effect...
[18:23] <Makyo> 1 sec.
[18:24] <hatch> yeah no rush
[18:26] <Makyo> The topo retains a list of wrapped services in service_boxes.  The ids of those are the <randomNumber>$ style, so on success, this replaces that object in topo.service_boxes with something the more closely matches what will be received in the delta.  Without it, in a real env, the box would disappear, then reappear on the delta, anything from a flicker to a disappearance.
[18:30] <hatch> ahh ok cool I'll add a comment to that effect
[18:30] <hatch> thx
[18:30] <Makyo> np, sorry it wasn't well commented
[18:32] <rick_h_> how goes?
[18:34] <rick_h_> kadams54: so with ant's branch can you take that over, clean up the items you had questions on and work towards a landing
[18:34] <rick_h_> kadams54: file a new card in the on deck land marked high priority for missing tests
[18:35] <rick_h_> kadams54: and no not seen the icon issue
[18:37]  * jcsackett hates CI.
[18:37] <jcsackett> but is in a better mood, having finally had lunch.
[18:38] <rick_h_> jcsackett: I kicked it for you
[18:41] <jcsackett> rick_h_: it looks like there might be another damn merge conflict.
[18:41]  * jcsackett is *never* getting this done.
[18:41] <rick_h_> jcsackett: :(
[18:41] <rick_h_> almsot there?
[18:41] <rick_h_> happy happy
[18:41] <jcsackett> yeah, i'm almost there.
[18:42] <jcsackett> hating on tools, but almost there.
[18:42] <jcsackett> does git have other merge patterns? b/c it's dying on *stupid* shit. :p
[18:44] <kadams54> rick_h_: Yup, no problem. I'd already started on the tests.
[18:44] <rick_h_> crap, I think I left my nice notebook at the grocery store doh
[18:44]  * rick_h_ bangs head on wall
[18:51] <kadams54> Notebook on aisle 5, notebook on aisle 5.
[18:54] <jcsackett> that's a fine notebook, dude. my condolences.
[18:54] <jcsackett> also: conflict fixed. let's try this *again*.
[18:54] <rick_h_>  yay
[18:54] <jcsackett> rick_h_: do i need to :shipit: again?
[18:54] <rick_h_> hatch: how goes your branch?
[18:54] <rick_h_> jcsackett: no, just remove the "merge accepted" message
[18:54] <rick_h_> jcsackett: if that's not there it'll repick it up
[18:54] <hatch> rick_h_ done, just need tests for this new setup now
[18:54] <rick_h_> hatch: woot
[18:55] <hatch> eating lunch now
[18:55] <rick_h_> hatch: gotcha, cool thanks.
[18:55] <hatch> the only downside is that you must deploy a service with a single unit
[18:55] <hatch> so I'm doing that part in a follow-up
[18:55] <rick_h_> hatch: ok
[18:55] <jcsackett> ok, i've completely lost mental state.
[18:55] <hatch> to make a 'non attached' unit
[18:55] <hatch> jcsackett spend too much time in Colorado?
[18:55] <hatch> kehehe
[18:56] <jcsackett> i live in the south dude. we kill our brain cells with moonshine, not plants. :p
[18:56] <hatch> haha
[18:57] <rick_h_> ok, going to dare to run to the store and hope my notebook is there while I wait for a call :/
[18:57] <rick_h_> wish me luck
[18:57] <jcsackett> rick_h_: i know you said something about this earlier, but i've lost track. what should i throw myself at, kamikaze like, next?
[18:57] <jcsackett> also: good luck.
[18:57]  * jcsackett waits to see if the question was sent in time...
[18:59] <jcsackett> guess not. jujugui, anyone need reviews or something?
[18:59] <hatch> nothing here yet
[19:04] <jcsackett> blast.
[19:09] <rick_h_> jcsackett: ok so next is the unplaced unit tokens
[19:09] <rick_h_> frankban had notes in irc easlier on the fix
[19:09] <rick_h_> don't look at serviceUnits but just .units and something else
[19:10] <rick_h_> and got my notebook back yay!
[19:11] <jcsackett> rick_h_: ...while i recognize those as words that relate to machine view, they aren't coming up in a cogent form for me. chat?
[19:11] <rick_h_> jcsackett: sure thing
[19:12] <jcsackett> rick_h_: https://plus.google.com/hangouts/_/gzrh7sh4g3zbscs42oajucofsia?authuser=2&hl=en
[19:14] <antdillon> kadams54, thanks for the review
[19:33] <Makyo> jujugui Does anyone besides frankban know how the AddMachines API call works?
[19:35] <Makyo> (specifically whether or not you can refer to a machine later on in the list of MachineParams, i.e.: [{create machine 1}, {create lxc on machine 1}] in the same API call.)
[19:40] <rick_h_> Makyo: I'm not sure on that. Honestly, I'd just try it and see if it blew up or errored. Maybe ping someone in core?
[19:41] <Makyo> rick_h_, doing that now.
[19:41] <Makyo> Have a path forward for the moment, at least.
[19:41] <rick_h_> Makyo: cool, looking for the code atm
[20:11] <antdillon> kadams54, Added your QA things to the branch
[20:12] <kadams54> OK, thanks
[20:12] <antdillon> kadams54, Thanks
[20:13] <antdillon> rick_h_, the deploy summary only supports deploys and add relations at the moment as it seems to be all the ecs records
[20:13] <kadams54> What about the expand icons? Is that in scope, or to be implemented in a different card?
[20:13] <antdillon> Oh sorry yea, they are placeholder at the moment
[20:13] <kadams54> OK, thanks
[20:13] <antdillon> kadams54, They jump to much different views
[20:14] <kadams54> cool
[20:14] <antdillon> Also click the number of changes in the bottom left doesnt open the small summary
[20:14] <bac> ping rick_h_
[20:14] <kadams54> Yeah, I noticed :-)
[20:15] <antdillon> kadams54, Another branch for that stuff, I reckon
[20:15] <Makyo> rick_h_, got an answer, adding it to our yuidocs
[20:24] <rick_h_> bac: pong
[20:24] <rick_h_> Makyo: cool
[20:24] <rick_h_> antdillon: ok, we're working on getting add machine/container going right now
[20:24] <rick_h_> antdillon: so we'll look if we get that working adding or whatever
[20:27] <bac> rick_h_: do you have time for a quick update call?
[20:27] <rick_h_> bac:  sure thing
[20:27] <bac> ok, standup
[20:28] <rick_h_> bac: can you invite me there please?
[20:28] <rick_h_> jcsackett: landed yay
[20:31] <bac> rick_h_: let me just call your cell
[20:33] <jcsackett> rick_h_: oh hallelujah.
[20:44] <jcsackett> rick_h_: so, we're getting unplaced units and generating tokens, but they're not rendering right. this is slightly more involved, but i'll keep digging.
[20:44] <jcsackett> whereever i am by EoD i'll push up so someone else can grab and run if they're working over the weekend.
[20:44] <jcsackett> s/rendering right/rendering at all/
[20:47] <hatch> rick_h_ https://github.com/juju/juju-gui/pull/292 ok all ready not
[20:47] <hatch> now
[20:47] <hatch> you can now, deploy mysql/wordpress/relate them, click deploy
[20:47] <hatch> all without the inspector
[20:49] <hatch> rick_h_ are you no longer working on the inspector opening after deploy?
[20:50] <hatch> rick_h_ well it appears that my branch has fixed that bug by bypassing that codepath entirely
[20:51] <hatch> jcsackett how goes the battle? When is your EOD?
[20:51] <huwshimi> rick_h_: Just wanted to check in and see how things are going?
[20:52] <hatch> huwshimi well, some of us are going to be picking up some hours this weekend to try and get the board cleared
[20:52] <hatch> for the demo
[20:53] <jcsackett> hatch: EoD is at six. battle's is indeterminate. not yet sure why the service icons don't go poof.
[20:53] <jcsackett> er, go poof.
[20:53] <hatch> jcsackett what's that in UTC?
[20:53] <hatch> timezones are for suckers
[20:54] <jcsackett> uh...22UTC, maybe?
[20:54] <jcsackett> shit i dunno. i'm on EST.
[20:54] <rick_h_> jcsackett: yea push and I can look
[20:54] <hatch> ok in an hour then
[20:54] <hatch> :)
[20:54] <rick_h_> hatch: will check it out
[20:54] <rick_h_> hatch: jcsackett yea, please push your stuff, with good notes in the pull requests
[20:55] <rick_h_> it's time for me to take the camper to the campground (actuall 3hrs late)
[20:55] <rick_h_> once we get setup I'll go through stuff tonight
[20:55] <rick_h_> so will be afk for a few hours driving and setting up the trailer
[20:55] <rick_h_> thanks!
[20:55]  * rick_h_ runs away
[20:55] <hatch> cya
[20:57] <bac> redir: you around?
[20:58] <redir> bac: yep
[20:59] <bac> redir: i was having a mapping format exception issue with ES.  but now it looks like it may be working!
[20:59] <redir> bac: not for much longer. we have out of town guests coming for a dinner party this eve
[20:59] <bac> ohh, a dinner party!  will you be serving negronis?
[20:59]  * redir blinks
[20:59] <redir> heh
[20:59] <jcsackett> oh ho, someone didn't put `this` into a loops scope.
[20:59] <jcsackett> huzzah, this may be easy.
[20:59] <redir> they don't drink
[21:00] <bac> more negronis for you then
[21:00]  * bac cannot stand camparai
[21:00]  * bac cannot spell campari
[21:00] <bac> sweet, i just ingested a directory full of local charms.
[21:06] <huwshimi> hatch: That card you just picked up, how do you get a unit in the unplaced column?
[21:06] <hatch> atm, you don't
[21:06] <hatch> jcsackett is working on that right now
[21:07] <huwshimi> Ah
[21:07] <hatch> you can create unplaced units not but I'm pretty sure they don't show up in the UI yet
[21:07] <hatch> I'm just going to make the headers drop targets
[21:08] <huwshimi> hatch: In the header widget I've added the drop state to the headers (just the styling at this point)
[21:09] <huwshimi> hatch: So you can do .setDroppable and it will switch to the correct state.
[21:09] <jcsackett> hatch, huwshimi: to be clear, i'm just making sure they render in the UI.
[21:09] <jcsackett> i'm doing nothing about placement etc into that unplaced thing.
[21:09] <jcsackett> i'm about to push it up for PR, just doing some CSS tweaks now.
[21:09] <hatch> jcsackett when you're done, unplaced units will be listed in the first column through right?
[21:09] <redir> bac: you have local demo all tidy?
[21:10] <bac> it looks pretty tidy
[21:10] <bac> redir: you can play with it if you're intersted
[21:10] <hatch> in your PR can you include the commands/process to get the units to show up there plz
[21:10] <hatch> ^ jcsackett
[21:10] <hatch> huwshimi I see, thanks
[21:10] <huwshimi> hatch: Also, on the scale up UI, it seems that the form should close when you click "add units"
[21:11] <hatch> PR's accepted
[21:11] <jcsackett> hatch: planning on it.
[21:11] <hatch> .....lol
[21:11] <hatch> jcsackett thanks
[21:11] <bac> redir: it is at ~bac/charmworld/ingest-local-charms
[21:11] <bac> er, lp:~bac/charmworld/ingest-local-charms
[21:11] <kadams54> Taking a break for family stuff. Will be back on after the kids are in bed tonight. Planning on landing ant's deployed changes summary panel work at that time.
[21:12] <bac> redir: i simply introduced a new cmd-line option to ingest-queued:  --local-repo=<path>
[21:14]  * Makyo -> dogwalk
[21:14] <redir> bac I'll try it monday
[21:15] <redir> I'll need to get a directory of charms from somewhere though
[21:20] <bac> redir: 'charm-tools get'.  that may be more than you want...
[21:20]  * bac walks dog
[21:20] <jcsackett> hatch: take a look at https://github.com/juju/juju-gui/pull/296 ?
[21:21] <hatch> jcsackett on it
[21:22] <redir> bac: I have charm-tools which gives me charm-get, is that what you mean?
[21:23] <redir> and download them one at a time/
[21:23]  * redir goes to start making dinner RSN
[21:26] <hatch> jcsackett it doesn't work
[21:26] <jcsackett> zuh?
[21:26] <hatch> when I run the cli command the inspector shows that there are more units
[21:26] <hatch> but there are none in the unplaced units column
[21:27] <hatch> I have to close/open it
[21:27] <jcsackett> right, _renderServiceUnit only executes when the machineviewpanel is first rendered.
[21:27] <hatch> or is that what branch was supposed to accomplish?
[21:27] <jcsackett> that's all this does.
[21:27] <hatch> ohh ok
[21:27] <jcsackett> just gets the _render thing to work as it is now.
[21:27] <jcsackett> there are still bugs.
[21:27] <hatch> can you create a card for the databdinging units list
[21:27] <hatch> plz
[21:27] <jcsackett> sure.
[21:27] <hatch> thanks
[21:28] <hatch> looks like we'll need some styling on it too
[21:28] <hatch> it being the unit tokens
[21:28] <huwshimi> jcsackett: Feel free to give me a card to style them.
[21:29] <jcsackett> huwshimi: okay.
[21:29] <hatch> huwshimi it will be a bit, I need to do the review and then it needs to land, just fyi
[21:29] <hatch> jcsackett how come there are no tests?
[21:30] <hatch> are they coming?
[21:30] <jcsackett> hatch: b/c all i did was update existing code.
[21:30] <jcsackett> and yeah, i'm adding high priority on deck cards.
[21:30] <huwshimi> jcsackett: No problems. I'll have my Monday while you guys are sleeping too.
[21:31] <hatch> that's a little creepy
[21:31] <hatch> lol
[21:32] <hatch> jcsackett so are there no tests for this functionality then?
[21:33] <jcsackett> hatch: only what tests were there before, and i can't imagine they were very good.
[21:34] <jcsackett> hatch: i can try to get tests in the next 30 min, but we don't have much setup in the way of isolation for these bits right now.
[21:34] <jcsackett> not sure i'll get anywhere.
[21:34] <hatch> jcsackett see test_machine_view_panel.js
[21:35] <hatch> lots of tests there
[21:35] <jcsackett> hatch: yeah, i just realized i was running make test-debug on develop, which is why everything passed. :p
[21:36] <hatch> haha
[21:36] <hatch> I have it a +1 so once tests pass and there are new ones it can be landed
[21:36] <hatch> if you don't get all the way finished I can take over
[21:44] <jcsackett> hatch: do our tests not use our css in the less files?
[21:44] <hatch> nop
[21:44] <hatch> well
[21:45] <hatch> that's a lie
[21:45] <hatch> unless the module loads it in itself
[21:45] <hatch> it's not there
[21:45] <jcsackett> ah. how does the module load it?
[21:45] <hatch> I don't think any do
[21:45] <jcsackett> hm.
[21:45] <hatch> not anymore anyways
[21:46] <hatch> what did you need the css for?
[21:46] <hatch> should be functional without?
[21:46] <jcsackett> there's some stuff in the serviceunit token that had style="display: none" in the html, which i moved into the css.
[21:46] <jcsackett> but there are tests making sure those bits don't start out visible.
[21:46] <jcsackett> ...should that whole block just start with the hidden class, come to think of it?
[21:47] <jcsackett> or is that only display: none by default for actual YUI widgets?
[21:47] <huwshimi> jcsackett: It might be fine to just check the css class is applied
[21:47] <huwshimi> (without knowing if that css applies the display: none)
[21:48] <jcsackett> huwshimi: eh, i guess. but just checking "class=details" seems like an unnecessary test.
[21:48] <hatch> all we got, until we start doing real renderings in the tests
[21:49] <jcsackett> hatch: can you call "show" and "hide" on arbitrary nodes?
[21:49] <hatch> if they are Y.Node instances yes  - http://yuilibrary.com/yui/docs/api/classes/Node.html#method_show
[21:50] <jcsackett> hatch: and that just applies ".hidden" right, or does that actually set the style?
[21:51] <hatch> both I think - sec
[21:51] <hatch> http://yuilibrary.com/yui/docs/api/files/node_js_node-view.js.html#l34
[21:51] <hatch> adds a hidden attribute
[21:51] <hatch> and sets the style on the element
[21:51] <jcsackett> yeah, i just found it too.
[21:52] <jcsackett> ok, so i'll update the "style=None" to start with .hidden class and check for that in tests.
[21:53] <hatch> so confused
[21:53] <hatch> I'll take your word on it
[22:12] <jcsackett> hatch: it'll make sense when you see the updated PR.
[22:12] <hatch> oh kay!
[22:13] <jcsackett> hatch: i've pushed to the PR--the test isn't actually passing yet, but i'm going to have to let you run with it.
[22:13] <jcsackett> i've got to EoD and get to a dinner.
[22:14] <hatch> sure np
[22:14] <hatch> enjoy
[22:14] <jcsackett> thanks.
[22:14] <jcsackett> have a good weekend, all.
[23:56] <rick_h_> howdy
[23:56] <rick_h_> from the campground
[23:56] <rick_h_> 4g in the wood yay
[23:56] <rick_h_> woodsd
[23:56] <rick_h_> woods
[23:58] <rick_h_> hatch: so you're running with jc's branch on the test side?
[23:59] <hatch> yeah, just doing some house stuff now
[23:59] <hatch> will try and get it in and landed tonight
[23:59] <rick_h_> hatch: ok cool, going back to your branch now


[08:23] <ara> good morning all!
[08:24] <ara> morning Riddell
[09:25] <jibel> marjo, hello, I tried to reproduce your firefox issue again with the kubuntu netbook livecd in persistent mode without success but I've found a strange behavior of casper.
[09:27] <jibel> marjo, what was the device you used as persistent device and was it completely clean, I mean freshly formatted and fully empty ?
[09:29] <marjo> jibel: i think my problem had to do with virtualbox not recognizing the USB stick
[09:30] <marjo> jibel: yes, the device was freshly formatted and only folder was lost+found
[09:30] <fader_> marjo: You could test it with a virtual hard disk
[09:31] <fader_> If you're using vbox that's probably much easier than trying to get a USB device recognized
[09:31] <marjo> jibel: single partition labeled 'casper-rw'
[09:31] <marjo> jibel: but i wanted to test with the USB stick instead of hard disk to see if that works
[09:32] <marjo> since you had already confirmed w/ hard disk
[09:32] <jibel> marjo, okay. I cannot reproduce then, the test passes each time with a clean device (usb or partition)
[09:32] <marjo> jibel: ok thx!
[09:32] <marjo> fader_ my point is USB stick should also work
[09:32] <jibel> marjo, did you tried qemu, it supports usb without having to pay for it I guess.
[09:32] <marjo> and jibel just confirmed it
[09:33] <fader_> marjo: Agreed, but dealing with USB in virtual box is an 'interesting' activity
[09:33] <marjo> fader_ i can confirm the interesting activity
[12:39] <njin> Hello to all: steps 3 and 7 of testcase uoi-002 need to be updated http://testcases.qa.ubuntu.com/Install/DesktopOem
[12:43] <ara> njin, if you have a launchpad account, you can do it yourself
[12:43] <ara> njin, I am subscribed to all the changes, so I will review the changes
[12:44] <njin> ara: ok, i will do .
[12:56] <njin> ara: done
[12:56] <ara> njin, great, thanks
[13:47] <KE1HA> Good after noon ara, question for you.  I'm looking at the diffrences between UB / EDUB and XUB (primarily menu headings / pull downs) and was wondering if there's a Blueprint for setting up the Menu structure on Ubuntu?
[13:48] <ara> KE1HA, each project is different on what applications to add and how to structure their menus
[13:49] <KE1HA> Yes, understand about the individual apps, maybe I wasn't too clear, I thinking about the Menu structure itself not so much the contests (apps) for each, for example:
[13:50] <KE1HA> On UB/EDUB, Sound & Video = Multimedia in Xubuntu.
[13:51] <KE1HA> on UB/EDUB Internet = Network on Xubuntu.


[00:53] <jose> geom: yes, there will be sessions. I manually add the ones for the month every first day of the month :)


[00:55] <feoh> Hi all. I filed a crappy 20.04 bug and I'm looking for advice on how to improve it: https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1872870
[00:55] <feoh> I'm seeing little square outlined outline trails left behind when my mouse cursor moves with the latest update. Just started yesterday.
[00:55] <feoh> I filed the bug under gnome but I wonder if I should target some other more specific target
[00:56] <feoh> and I tried to provide evidence but the trails don't show up in a screen grab
[02:23] <feoh> FWIW added a screencast. That's the only thing I can think of
[02:54] <lotuspsychje> good morning
[08:41] <benjam2000> With ubuntu 20.04 the preseed automation style (debian installer) for automated installs wont be supported anymore?
[09:17] <benjam2000> There are already netinstall or mini images available for 20.04?
[09:29] <benjam2000> Ok, netinstall and mini.iso images seem to be available: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
[11:32] <ubuking> hiiiiiii
[13:16] <iconoclasthero> is there an eta for 20.04 RC1?
[13:19] <lotuspsychje> as always, its out when its out iconoclasthero
[13:50] <sdeziel> I've already described my problem in #ubuntu-server (no response) so apologies for those in both channels.
[13:50] <sdeziel> I was about to apply updates on a Focal server when I noticed the unusually long list that apt wants to pull in. This all seems to be coming from the kernel upgrade that suddenly wants to bring DKMS and all that
[13:51] <sdeziel> here's what it looks like: https://paste.ubuntu.com/p/hfmV6BwTd9/
[13:51] <sdeziel> to be precise, I don't want DKMS nor kernel headers and didn't need them in the previous weeks
[13:59] <sdeziel> there seems to be a link with wireguard and its -dkms package. I've now moved to only installing wireguard-tools to stop trying to go the DKMS route
[14:00] <lotuspsychje> sdeziel: you might wanna bring that up in #ubuntu-quality too, maybe someone noticed aswell
[14:00] <sdeziel> so only wireguard-tools is installed now but it still wants to pull wireguard-dkms
[14:01] <sdeziel> lotuspsychje: yeah, but I'm now suspecting a behavior change in apt that would explain why it wants to pull in Recommends during upgrades
[14:02] <sdeziel> s/upgrades/dist-upgrades/
[14:02] <lotuspsychje> i just did the upgrades, but i dont have wireguard installed, so didnt notice
[14:03] <sdeziel> apt upgrade behaves normally, it's just apt dist-upgrades now wants to bring those Recommends
[14:05] <sdeziel> I'm lost now. I ran apt upgrade and it pulled just the kernel which is good. Then I ran apt dist-upgrade and it said nothing needed to be updated
[14:08] <sdeziel> maybe that was all triggered by the fact that I initially had the wireguard package installed without having wireguard-dkms (weird though as it's listed as Depends)
[14:08] <sdeziel> thanks lotuspsychje
[14:12] <lotuspsychje> sdeziel: when i try to install wireguard here, it pulls all dependencies so it seems
[14:13] <sdeziel> lotuspsychje: yeah, I don't understand how it worked for me here without the wireguard-dkms package
[14:13] <sdeziel> I know the .ko is shipped by the kernel but the wireguard metapackage is really supposed to insist on wireguard-dkms
[14:14] <sdeziel> so it was a mistake to install wireguard to begin with as I really only want wireguard-tools
[14:19] <mcphail> I think the wireguard thing is just a messy transition from 19.10, where the kernel didn't have the module built in
[14:21] <sdeziel> mcphail: I thing the wireguard metapackage is less relevant now and potentially confusing
[14:21] <sdeziel> s/thing/think/
[14:21] <sdeziel> I would guess that the vast majority of users will want what wireguard-tools + the built-in module provides
[14:22] <lotuspsychje> sdeziel: maybe you installed it, during a stage dependencies were still being worked on?
[14:22] <mcphail> Yes. Now sure how these things are supposed to be handled. I mean, having the wireguard-dkms package doesn't seem to break anything but itis annoying
[14:27] <sdeziel> lotuspsychje: indeed, at some point, wireguard-dkms was installed without me realizing
[14:39] <lotuspsychje> sdeziel: yeah suspected something like that
[14:43] <lotuspsychje> sdeziel: affected your bug
[14:45] <sdeziel> lotuspsychje: thx
[16:13] <howarth> What's the deal with the kernel update? Part of it shows <IP_ADDRESS>.29 but most of it still shows <IP_ADDRESS>.28. Yet according to https://launchpad.net/ubuntu/focal/+package/linux-generic it has the former (<IP_ADDRESS>.29) as in Release.
[16:14] <lotuspsychje> !info linux-image-generic
[16:16] <lotuspsychje> howarth: sudo apt autoremove
[16:19] <howarth> But linux-image-5.4.0-24-generic, linux-modules-5.4.0-24-generic and linux-modules-extra-5.4.0-24-generic, etc are all still at <IP_ADDRESS>.28. Yet https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/19145415 shows new <IP_ADDRESS>.29 copies should have been pushed, no?
[16:20] <howarth> Looks like an incomplete update to the <IP_ADDRESS>.29 kernel build in the repo.
[16:20] <howarth> Same issue still exists (for several days now) in proposed-updates.
[16:21] <lotuspsychje> do you have -proposed enabled?
[16:21] <howarth> On a second test drive.
[16:21] <howarth> This one, my main drive, has proposed-updates off.
[16:22] <howarth> I never filed a bug report because I figured it would get fixed before the next kernel push into the release repo.
[16:22] <lotuspsychje> howarth: pastebin please: dpkg --list | grep linux-image
[16:22] <howarth> ii  linux-image-5.4.0-24-generic               5.4.0-24.28                                amd64        Signed kernel image generic
[16:22] <howarth> ii  linux-image-generic                        <IP_ADDRESS>.29
[16:25] <lotuspsychje> from my dpkg logs: 2020-04-16 14:42:38 status installed linux-image-generic:amd64 <IP_ADDRESS>.29
[16:26] <howarth> But where is the matching linux-image-5.4.0-24-generic               5.4.0-24.29
[16:26] <howarth> I don't see any evidence on https://packages.ubuntu.com/focal/main/newpkg that it ever got pushed into the repo like it should have
[16:26] <howarth> They built it but for some reason never pushed it
[16:27] <lotuspsychje> howarth: did you full-upgrade?
[16:28] <howarth> One was a dist-upgrade from 19.10 and the other a clean install from the beta
[16:28] <lotuspsychje> !uptodate
[16:29] <howarth> Unless I am missing something, no one has shown evidence that they got linux-image-5.4.0-24-generic               5.4.0-24.29 installed automatically
[16:29] <howarth> I'm not talking about   linux-image-generic
[16:29] <lotuspsychje> howarth: when you uname -a it hides the last number
[16:30] <lotuspsychje> so current should be .29
[16:30] <lotuspsychje> if you fully upated system
[16:30] <lotuspsychje> *updated
[16:30] <howarth> This is checking with 'dpkg --list | grep linux-image'... does it show that you have a 'linux-image-5.4.0-24-generic               5.4.0-24.29'?
[16:31] <howarth> Show me your output for 'dpkg --list | grep linux-image | grep 29'
[16:31] <howarth> ii  linux-image-generic                        <IP_ADDRESS>.29                                amd64        Generic Linux kernel image
[16:31] <lotuspsychje> http://dpaste.com/1GPBHHM
[16:32] <howarth> Exactly what I am saying
[16:32] <howarth> You also don't have a linux-image-5.4.0-24-generic               5.4.0-24.29 installed for a signed kernel
[16:32] <howarth> The issue is that ubuntu built it but never pushed into the repo
[16:33] <howarth> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/19145415
[16:33] <lotuspsychje> lets reboot first holdon
[16:36] <howarth> My guess is that ubuntu does some manual steps for the kernel signing and dropped the  5.4.0-24.29 copy by accident
[16:56] <howarth> Looking at https://lists.ubuntu.com/archives/focal-changes/2020-April/date.html I see https://lists.ubuntu.com/archives/focal-changes/2020-April/017325.html and https://lists.ubuntu.com/archives/focal-changes/2020-April/017327.html
[16:57] <howarth> For [ubuntu/focal-proposed] linux-signed 5.4.0-24.28 (Accepted) and [ubuntu/focal-proposed] linux-meta <IP_ADDRESS>.29 (Accepted)
[16:57] <howarth> It certainly looks like ubuntu dropped the ball on doing the required  [ubuntu/focal-proposed] linux-signed 5.4.0-24.29 (Accepted)
[16:57] <howarth> which is MIA
[16:59] <howarth> https://launchpad.net/ubuntu/+source/linux-signed/5.4.0-24.28 exists but https://launchpad.net/ubuntu/+source/linux-signed/5.4.0-24.29 doesn't
[17:10] <lotuspsychje> bug #1873315
[17:10] <luna_> Moving from 20.04 Betas to RC now
[17:14] <luna_> howarth: lotuspsychje: i got .24 today
[17:15] <lotuspsychje> yeah we all did
[17:16] <howarth> https://launchpad.net/ubuntu/+source/linux-meta/<IP_ADDRESS>.29
[17:16] <howarth> linux-meta (<IP_ADDRESS>.29) focal; urgency=medium
[17:16] <howarth>   * Bump ABI 5.4.0-24
[17:16] <howarth>   * Miscellaneous Ubuntu changes
[17:16] <howarth>     - [Packaging] Remove support for riscv64
[17:16] <howarth> linux-meta (<IP_ADDRESS>.28) focal; urgency=medium
[17:16] <howarth>   * Bump ABI 5.4.0-23
[17:17] <hggdh> yes, this is a packaging change
[17:19] <howarth> But it is opaque if those linux kernel builds for <IP_ADDRESS>.29 that didn't land in the repo would have actual changes
[17:21] <luna_> Running RC now
[18:28] <wlan2> So I just upgraded a machine to 20.04 and got openmpi-bin as a broken package because something is wrong with /var/lib/dpkg/alternatives/mpi
[18:29] <wlan2> It says update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc
[18:30] <wlan2> I've never encountered this before, and was wondering how to proceed.
[18:47] <wlan2> I think I fixed it, but I don't like the way I did it. I removed /var/lib/dpkg/alternatives/mpi , purged and installed.
[18:47] <wlan2> Just saying in case somebody else gets this issue.
[18:47] <wlan2> Have a nice day.