[00:35] <huwshimi> rick_h_: So if we don't yet have the hardward info we should say something like "Hardware info unavailable"?
[00:38] <rick_h_> huwshimi: yes, that's a card I think
[00:38] <rick_h_> huwshimi: I think "Hardware details not available" if that'll fit
[00:38] <huwshimi> rick_h_: OK, I'll do that as part of the token styling branch.
[00:39] <rick_h_> huwshimi: thanks
[01:55] <rick_h_> kadams54: did you put up your branch?
[02:38] <rick_h_> ok, night all see you tomorrow
[02:50] <huwshimi> Night
[05:01] <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.
[05:01] <kadams54> Er
[05:01] <kadams54> It's not landed
[05:01] <kadams54> Ready for QA :-)
[05:02] <huwshimi> kadams54: Ah, I'll take a look
[05:04] <kadams54> Bah, stupid lint
[05:05] <huwshimi> :)
[10:29] <rick_h_> morning party people
[10:32] <huwshimi> rick_h_: Good morning :)
[10:32] <rick_h_> huwshimi: still around? morning man
[10:32] <huwshimi> rick_h_: Just been out and got home
[10:32] <rick_h_> huwshimi: very cool, thanks for the work last night. Will start going over the branches and qa'ing soon
[10:32] <rick_h_> after the coffee brews
[10:33] <huwshimi> :)
[10:50] <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.
[10:51] <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
[10:52] <huwshimi> rick_h_: Yep, np
[10:52] <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
[10:52] <huwshimi> sure
[10:55] <frankban> rick_h_, huwshimi: morning, I need two reviews for https://github.com/juju/juju-gui/pull/309
[10:55] <rick_h_> frankban: sure thing
[10:55] <frankban> rick_h_: thanks, this is a required change before placeUnit
[10:55] <huwshimi> I'll do a QA and then I need to sleep :)
[10:56] <frankban> huwshimi: heh, thanks
[10:56] <rick_h_> huwshimi: thanks and get some rest
[10:56] <huwshimi> It's not late, I'm just jet-lagged still :)
[10:58] <rick_h_> frankban: the hideChangeDescription is done in the bar itself next to the counter. Originally the branch worked: 
[10:58] <rick_h_> "Drop a service, the bar would show "1    Added service XX      Deploy"
[10:58] <rick_h_> and then after 2s it would hide the "Added service XX" part
[11:02] <frankban> rick_h_: uhm, it does not work in trunk
[11:02] <rick_h_> yea, something has been broken along the wya
[11:03] <rick_h_> the count isn't there
[11:03] <rick_h_> ant's branch added this work and I qa'd it originally
[11:03] <frankban> rick_h_: and the change description hides
[11:03] <rick_h_> I wonder if someone's rebase/merge conflict caused issues and it got lost
[11:03] <frankban> :-/
[11:04] <huwshimi> rick_h_: I'm not sure if you saw my email about the summary "No uncommited changes" state being related to something there
[11:04] <rick_h_> https://github.com/juju/juju-gui/pull/288
[11:04] <rick_h_> huwshimi: it is 
[11:04] <rick_h_> huwshimi: well it's all related
[11:04] <huwshimi> rick_h_: I think the timeout is applying to the wrong element
[11:05] <rick_h_> huwshimi: right, and it looks like we're missing some code/elements
[11:05] <huwshimi> yeah
[11:05] <rick_h_> huwshimi: from that pull request ^
[11:05] <rick_h_> so will have to diff and pull that back together
[11:06] <huwshimi> rick_h_: I saw it working at some stage though
[11:07] <rick_h_> huwshimi: yea, same here
[11:07] <rick_h_> frankban: :+1: on your branch
[11:08] <frankban> rick_h_, huwshimi: thank you!
[11:10] <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?
[11:11] <rick_h_> frankban: I thought add_unit had to add that unit so that we could search for unplaced units using the filterByMachine(null)?
[11:11] <rick_h_> frankban: I see though, you mean to not actually add it to the ecs at that point though
[11:12] <rick_h_> but it's in the db
[11:13] <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. 
[11:13] <frankban> rick_h_: we can add the unit to the ECS and then placeUnit modifies the record
[11:13] <rick_h_> frankban: but your way sounds ok as well
[11:18] <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
[11:18] <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.
[11:18] <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
[11:19] <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
[11:19] <rick_h_> frankban: it could just be ignored, as you suggest, or an error in the summary directing you to go back and place. 
[11:19] <frankban> rick_h_: sounds good, new machines for unplaced units is a simpler story for us
[11:19] <rick_h_> frankban: in which case we'll also need some way to 'destroy' an unplaced unit
[11:20] <frankban> rick_h_: so yeah, place unit should just change the unit record in ECS
[11:20] <rick_h_> frankban: but I definitely understand your concerns. hatch and I have mentioned them to luca/design. 
[11:20] <rick_h_> frankban: ok cool. Thanks
[11:21] <rick_h_> jcsackett: around this morning? 
[11:25] <rick_h_> poor poor CI is getting a workout this week
[11:26] <rick_h_> ok, think I've reviewed and caught up with things atm. Going to go about that coffee and breakfast now
[11:29]  * frankban lunches
[11:32] <huwshimi> rick_h_: I figured out what was going on with the deployer bar, just pushing a branch
[11:33] <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
[11:34] <huwshimi> rick_h_: Np, just running tests.
[11:43] <huwshimi> rick_h_: It's ready for review/qa. I'm heading to bed :)
[11:46] <huwshimi> Night all
[11:53] <rick_h_> huwshimi: night!
[12:20] <rick_h_> frankban: looks like conflicts hitting between you and huw there. Sorry about that. 
[12:21] <rick_h_> bac: morning
[12:21] <bac> hi rick_h_
[12:23] <rick_h_> frankban: looks like a small one in the handlebars template 
[12:23] <rick_h_> -         <h2 class="title">These changes will be deployed to: {{ machineName }}</h2>
[12:23] <rick_h_> +         <h2 class="title">The following changes will be deployed</h2>
[12:38] <frankban> rick_h_: looking
[12:42] <frankban> rick_h_: shipit again?
[12:43] <rick_h_> frankban: just delete the comment "merge request accepted" and it'll repick it up
[12:44] <frankban> rick_h_: ok thanks, maybe we should add instructions to the Build failed message
[12:45] <frankban> rick_h_: landing again
[12:46] <rick_h_> frankban: definitely. I honestly thought we did have some notes in there. 
[12:47] <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
[13:10] <jcsackett> morning all.
[13:10] <rick_h_> morning
[13:11] <bac> hi jcastro
[13:11] <bac> hi jcsackett
[13:11] <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
[13:11] <bac> all nicks in a channel should be unique to the first two characters
[13:12] <kadams54> Morning all.
[13:12] <jcsackett> morning, kadams54.
[13:13] <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.
[13:13] <jcsackett> kadams54: one sec.
[13:14] <jcsackett> kadams54: app/assets/javascripts/event-tracker.js
[13:15] <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.
[13:21] <hazmat`> rick_h_, local charms in bundles with drag and drop onto the gui.. workable?
[13:21] <hazmat`> rick_h_, basically going to pre-load the local charms into the environment.. that should work?
[13:21] <rick_h_> hazmat`: I thought that didn't work because of the revision stuff
[13:23] <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
[13:24] <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?
[13:26] <hazmat`> jcastro, i'm busy in the demo room, missing keynotes.. should be linked from main ostack site
[13:26] <hazmat`> jcastro, http://www.openstack.org/home/Video/
[13:28] <rick_h_> hazmat`: sorry, phone call
[13:28] <hazmat`> rick_h_, no worries
[13:29] <rick_h_> hazmat`: honest answer is I'm not sure off the top of my head. 
[13:29] <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 
[13:29] <rick_h_> hazmat`: there's something there. we tried it and ended up failing due to an assumption somewhere in the pipeline
[13:30] <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
[13:30] <bac> rick_h_: ack
[13:32] <rick_h_> kadams54: morning, I think huw and frankban have found the deployer bar issues you were looking into on your card?
[13:34] <jcsackett> y'all did a ton of work over the weekend.
[13:34] <rick_h_> yes, almost there
[13:37] <kadams54> rick_h_: interesting. Did they commit a fix or just find where the bug was at?
[13:37] <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?
[13:38] <rick_h_> kadams54: I think the fix is in, swimming atm with working on huw's update to fix the deployer bar notifications
[13:38] <rick_h_> jcsackett: I think that's fine now
[13:38] <rick_h_> jcsackett: frankban's branch that just landed I think fixes that
[13:38] <jcsackett> rick_h_: dig.
[13:38] <rick_h_> jcsackett: a verify/qa would be cool
[13:38] <jcsackett> rick_h_: verifying now.
[13:39] <kadams54> rick_h_: OK, cool. I like cards that get fixed in other people's branches while I sleep.
[13:39] <rick_h_> kadams54: yea, give it a go and see if you can break it again
[13:39] <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
[13:40] <jcsackett> rick_h_: it appears to work on sandbox--was this observable there, or does it need a real env?
[13:40] <rick_h_> jcsackett: yea, it was there
[13:40] <jcsackett> rick_h_: also, how was camping?
[13:40] <jcsackett> cool, i'm marking it with frank and throwing it into daily call.
[13:40] <rick_h_> the campground was awful, the boy had fun, the wife and my verizaon bill didn't appreciate all the branches :)
[13:41]  * jcsackett laughs
[13:41] <rick_h_> but it was nice to get out of the house and sleep under the sky a bit
[13:41] <jcsackett> well, at least your son enjoyed it.
[13:41] <jcsackett> :)
[13:41] <rick_h_> he loves camping, and they had lots of stuff for kids
[13:41] <jcsackett> that's cool.
[13:50] <rick_h_> morning hatch 
[13:51] <hatch> morning
[13:51] <hatch> how goes it?
[13:51] <rick_h_> hatch: crazy wheeeee
[13:54] <redir> what time is the demo:
[13:54] <redir> ?
[13:54] <rick_h_> redir: tues AM
[13:54] <frankban> Makyo: ping
[13:54] <Makyo> frankban, hi
[13:55] <redir> ahh so one more day to polish it
[13:55] <rick_h_> redir: yea, well make it work today
[13:55] <rick_h_> and collapse :)
[13:55] <bac> rick_h_: time for a quick chat?
[13:55] <rick_h_> bac: definitely
[13:55] <rick_h_> kadams54: looking at qa'ing your branch. It's all up to date per huw's feedback?
[13:55] <bac> rick_h_: in standup
[13:56] <kadams54> rick_h_: Yes, should be. Event bindings are now destroyed properly.
[13:56] <rick_h_> kadams54: coolio will look after this call thanks
[13:56] <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
[13:58] <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
[13:59] <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
[14:00] <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
[14:01] <Makyo> frankban, hmm, correct... Unless we just use something like '(pending machine)' if the machine hasn't yet been created.
[14:01] <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
[14:01] <frankban> Makyo: and then making the parent check using options.modelId
[14:01] <Makyo> frankban, That makes sense, yeah
[14:02] <frankban> Makyo: cool, I'll take a look
[14:02] <frankban> hatch: what code are you referring to?
[14:03] <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
[14:03] <hatch> in hindsight ghostserviceid makes sense :)
[14:09] <frankban> hatch: IC :-) unfortunate overlapping (but I guess it's unsurprising given the demo panic)
[14:24] <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?
[14:25] <hatch> rick_h_ I think now with frankban's latest branch it should be good to go, I'm just running through kadams54 PR 
[14:25] <hatch> then I can get on it
[14:25] <rick_h_> hatch: rgr
[14:30] <hatch> ohh you already shipped it
[14:30] <hatch> lol
[14:31] <rick_h_> hatch: heh, I added a card in the backlog to follow up on your comments
[14:32] <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
[14:34] <hatch> comingsoon is broken
[14:35] <hatch> http://comingsoon.jujucharms.com/:flags:/il/mv/
[14:35] <hatch> changeset count is in the header
[14:35] <rick_h_> bah
[14:35] <rick_h_> lol
[14:35] <bac> frankban: the demo needs to use quickstart.  where is the best place to get it? trusty repo or some PPA?
[14:36] <rick_h_> bac: the ppa, I don't know that trusty has been updated for the bug fixes yet
[14:36] <frankban> bac: juju/stable ppa
[14:36] <bac> ty
[14:37] <frankban> bac: what do they use quickstart for?
[14:37] <bac> frankban: deploy charmworld
[14:37] <rick_h_> hatch: can you try a local copy? I wonder if this is coming soon css issues
[14:37] <hatch> no it's in develop
[14:37] <Makyo> rick_h_, it's in trunk.
[14:37] <rick_h_> hatch: I don't see what in the CSS is making that happen
[14:38] <rick_h_> ok thanks :)
[14:38] <hatch> it's not css, it's markup
[14:38] <hatch> the changes button needs preventDefault on it as well
[14:38] <hatch> because it's an A it breaks the url
[14:38] <rick_h_> gotcha
[14:38] <hatch> I'm just going to sit back and pretend I've never said anything about using anchors
[14:38] <hatch> ...
[14:38] <hatch> lol!
[14:39] <rick_h_> well it's incomplete features anyway. So not fair 
[14:39] <hatch> there is actually a full deployer bar up there
[14:39] <hatch> it's really broken now
[14:39] <hatch> a bisect is probably necessary here
[14:39] <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
[14:40] <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.
[14:40] <hatch> oh darn!
[14:40] <rick_h_> https://github.com/juju/juju-gui/pull/288 is the original working branch
[14:41] <hatch> ohh that's a lot of changed files heh
[14:41] <rick_h_> icons mostly
[14:41] <hatch> ok I'm going to get my branch landed first
[14:42] <hatch> oh yay my keyboard backlight just stopped working
[14:42] <hatch> F^&*^&* Apple
[14:43] <jcsackett> rick_h_: can you chat for a moment?
[14:43] <rick_h_> jcsackett: sure thing
[14:43] <jcsackett> rick_h_: https://plus.google.com/hangouts/_/g3hgvsy4smtzi2x6dptuesyplya?authuser=2&hl=en
[14:45] <rick_h_> jcsackett: https://github.com/juju/juju-gui/pull/307
[14:47] <rick_h_> hatch: jcsackett is going to look at that
[14:48] <jcsackett> ...the horror, the horror. :p
[14:48] <rick_h_> hatch: some cross between ant/huw/me made something wonky
[14:48] <Makyo> jujugui I'm on the deployer bar thing.
[14:48] <jcsackett> rick_h_: ^
[14:48] <rick_h_> Makyo: ok cool then
[14:48] <jcsackett> right, back to figuring out what to look at. :p
[14:48] <rick_h_> Makyo: so you're two birds one-stone there Makyo ?
[14:49] <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.
[14:49] <rick_h_> Makyo: yea, that text was replaced in a drive by
[14:50] <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
[14:50] <Makyo> rick_h_, okay.  I'll add that to this card and go through the rest of the list.
[14:50] <rick_h_> Makyo: the icons show now, that was hatch's attempt to avoid collisions
[14:50] <rick_h_> Makyo: so updating the card for the two items remaining
[14:51] <hatch> yeah I borked that
[14:51] <hatch> but I think that's all fixed now
[14:51] <rick_h_> yea, all good
[14:51] <rick_h_> as long as we all ack you can only have one unit of any service in ghost lol
[14:51] <hatch> Makyo when following your QAsteps.js are we supposed to get ghost machines?
[14:51] <hatch> rick_h_ haha, this demo better be very scripted :)
[14:52] <rick_h_> hatch: trying to work on that for sure
[14:52] <Makyo> hatch, all my branch did was ensure ECS called addMachines properly; no UI
[14:52] <jcsackett> Makyo: so to be clear, you're handling the deployer bar rendering goofily up top?
[14:52] <hatch> Makyo ahh ok cool, I've just been using those steps to qa other stuff and was curious
[14:53] <Makyo> jcsackett, Yes, if that's alright.
[14:53] <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
[14:53] <jcsackett> rick_h_: dig.
[14:53] <jcsackett> jujugui: who needs PR/QA? i appear to be super free.
[14:53] <rick_h_> I've got to start work on the demo script and notes. 
[14:54] <rick_h_> jcsackett: so I think we're all set atm, but hopefullyu will have some coming down the pipe 
[14:54] <rick_h_> kadams54: did you dupe the issue in your card?
[14:54] <rick_h_> kadams54: or is that all set?
[14:54] <hatch> jcsackett you can go through the codebase with rubber gloves and some solvent to clean up all the new tech debt
[14:54] <hatch> haha jk it's actually not that bad
[14:54] <rick_h_> hatch: heh, save that for tomorrow
[14:54] <rick_h_> there will be a "great post-demo audit!"
[14:55] <rick_h_> but not today
[14:55] <rick_h_> enough moving parts atm
[14:55] <jcsackett> i'm looking at the two polish cards, and will be on interrupt for PRs and QA.
[14:55] <kadams54> rick_h_: well, yes, it seems to be fixed. However I'm seeing some other odd behavior.
[14:55] <rick_h_> kadams54: ok
[14:55] <rick_h_> jujugui call in 5
[14:56] <kadams54> Hmm, strike that… I'm seeing "no uncommitted changes" again. Different route to reproduce it though.
[14:56] <bac> rick_h_: you know, it is a little redonkulous that we don't deploy charmworld with a bundle in real life.
[14:56] <rick_h_> bac: +1
[14:57] <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
[14:57] <rick_h_> bac: but for our QA env we want to setup I was looking at trying to create/use a bundle for that
[14:57] <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
[14:58] <rick_h_> hatch: we are dropping on a pre-existing machine to create a new container
[14:58] <hatch> crap that is not what my code does
[14:58] <rick_h_> so we have to addMachine with a real parent and make a new lxc container
[14:58] <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
[14:58] <Makyo> Got the deployer bar thing; copy-paste problem.
[14:58] <rick_h_> doh
[14:59] <rick_h_> thanks Makyo 
[14:59] <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
[14:59] <hatch> yeah I must have misunderstood - I thought that it was being dragged to an existing container
[15:00] <hatch> it's ok I just need to add drop support to the machine tokens
[15:00] <rick_h_> hatch: it's the header that you drop on
[15:00] <rick_h_> https://www.dropbox.com/sh/lvdydgiu7jeuuso/7MlRX5-IPu#lh:null-06-machine.png
[15:00] <hatch> no that creates a new machine/container, we need to create a new container in a machine
[15:00] <hatch> so you drop on the machine
[15:00] <rick_h_> you've selected the first machine, and drop on the header "Create new container" which we can hardcode to a new lxc 
[15:01] <rick_h_> right, the grey means that the machine is selected
[15:01] <hatch> oh boy
[15:01] <rick_h_> and a big "Create new container" drop target
[15:01] <rick_h_> jujugui hangout
[15:01] <hatch> man where did I get the idea to drop on a container
[15:04] <bac> jujugui: is this fatal state from 'juju status'?  agent-state-info: '(error: no instance types in us-west-2 matching constrain
[15:04] <bac> ts
[15:04] <bac>       "cpu-cores=1 cpu-power=100 mem=2048M root-disk=20480M")'
[15:05] <bac> or will it continue with best attemp?
[15:05] <bac> s/attemp/attempt/
[15:12] <hatch> rick_h_ can you hop back in?
[15:13] <hatch> just want to confirm the interaction for the drag and drop
[15:13] <bac> frankban: do you know the answer to my question ^^^?
[15:13] <rick_h_> hatch: joining
[15:13] <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.
[15:14] <frankban> bac: what machine is returning that error?
[15:15] <bac> frankban: the one for elasticsearch and mongo.  is that your question?
[15:16] <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?
[15:17] <rick_h_> jcsackett: rgr 
[15:17] <bac> frankban: ok.  i wonder which of those constraints is causing the problem...
[15:18] <rick_h_> bac: I think the cpu-power or the root-disk
[15:18] <rick_h_> bac: I'd drop those two and see what happens
[15:18] <rick_h_> having both core and power I don't know makes sense, I think it's either/or but not 100% sure
[15:19] <bac> huh, i didn't specify the cpu-power one.  juju must've helpfully added it for me.
[15:19] <rick_h_> heh, you co cool juju
[15:21] <bac> that helps me narrow it down, though
[15:28] <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?
[15:30] <hatch> heh yes
[15:30] <rick_h_> kadams54: yep
[15:30] <rick_h_> last minute mandate that's falling apart in real life
[15:30] <kadams54> Now things make sense.
[15:31] <kadams54> Well, more than 30 minutes ago.
[15:31] <hatch> :D
[15:32] <kadams54> OK, so on my card… should I update it to be specific to when undeployed (ghost) stuff is deleted?
[15:32] <rick_h_> kadams54: definitely
[15:38] <kadams54> Hmm, found another variation that may be more problematic for the demo.
[15:38] <rick_h_> kadams54: k, good to know
[15:38] <kadams54> If you drop a second charm, it triggers the message again
[15:39] <rick_h_> 'triggers the message'?
[15:39] <kadams54> Yeah, "no uncommitted changes".
[15:39] <rick_h_> kadams54: call?
[15:39] <kadams54> Sure
[15:40] <rick_h_> kadams54: let's just hit the standup hangout
[15:40] <kadams54> k
[15:47] <rick_h_> wahoo! we have replication
[15:47] <kadams54> rick_h_: Nice to know I'm less crazy-ish.
[15:48] <rick_h_> yea, know that feeling
[15:57]  * rick_h_ goes to take a lunch break
[16:02] <hatch> hmm this interaction feels very clunky
[16:02] <hatch> definitely need to get it infront of luca
[16:03] <rick_h_> hatch: + 1, I think the manual clicky method will be the better placement story to be honest
[16:03] <rick_h_> hatch: but Mark S wants the drag/drop GUI experience so we're doing that first
[16:03] <hatch> yeah I just find I'm switching back and forth a lot, just doesn't quite feel right
[16:03] <rick_h_> ok, now really to lunch
[16:03] <hatch> lol
[16:04] <Makyo> jujugui https://github.com/juju/juju-gui/pull/312 for some intermediary work on the UI polish
[16:04] <jcsackett> Makyo: looking now.
[16:07] <Makyo> Man, what happened to my pre-push hook? :(
[16:18] <jcsackett> Makyo: i have had lots of trouble with pre-push hooks, of late.
[16:31] <jcsackett> Makyo: thanks for updates, QAing now.
[16:33] <Makyo> jcsackett, thanks!  We're in a hurry, but you're right about the test, I'm getting one in real quick.
[16:34] <jcsackett> Makyo: thanks!
[16:37] <frankban> it works! it fracking works!
[16:37] <jcsackett> Makyo: you said note the machine key in your QA instructions...do you mean the "addMachines-$number", or what?
[16:37] <jcsackett> frankban: \o/
[16:37] <kadams54> rick_h_: I fixed the issue, but I also found this: http://pastie.org/private/hayd1bhhcmy81k4ycabfg
[16:37] <hatch> ugh so many conflicts
[16:38] <kadams54> rick_h_: With which I agree. Why are notifications hidden after 2 sec? Can we remove that?
[16:38] <Makyo> jcsackett, yes
[16:38] <rick_h_> kadams54: there's two moving parts here
[16:38] <jcsackett> Makyo: ok, thanks.
[16:38] <rick_h_> the notification is in the bar while it's closed state and disappears after 2s
[16:38] <rick_h_> kadams54: that we want
[16:39] <rick_h_> kadams54: it's got a side effect of doing something that clears the data in the summary
[16:39] <Makyo> jcsackett, the parentId, until frankban's changes land, is 'addMachines-123' or whatever.
[16:39] <rick_h_> kadams54: that's the bug 
[16:39] <kadams54> Yeah, I fixed the side effect
[16:39] <kadams54> But why do we clear after 2 sec?
[16:39] <jcsackett> Makyo: oh, the whole string? not just the number?
[16:39] <kadams54> Why not just leave the notify there until something else comes along?
[16:39] <rick_h_> kadams54: ok, then yea. We do want that notification to fade away. It's a notification, it's temporal by design?
[16:39] <Makyo> jcsackett, yeah, sorry
[16:39] <frankban> jujugui: please take a look at http://pastebin.ubuntu.com/7453150/
[16:39] <kadams54> It's too quick
[16:40] <jcsackett> Makyo: no worries.
[16:40] <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
[16:40] <frankban> jujugui: note that new1 is arbitrary
[16:40] <kadams54> frankban: just discussing your comment here: http://pastie.org/private/hayd1bhhcmy81k4ycabfg :-)
[16:41] <kadams54> rick_h_: The notification is often gone before I get a chance to read it
[16:41] <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
[16:41] <jcsackett> Makyo: to view change summary i click the "changes" thing in the left of the deployer bar, right?
[16:41] <rick_h_> it's the old 'highlight in yellow the new item' trick
[16:42] <rick_h_> jcsackett: no, click deploy
[16:42] <rick_h_> jcsackett: that changes doesn't work yet
[16:42] <Makyo> jcsackett, click deploy, it'll ask for a confi--yeah
[16:42] <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.
[16:43] <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
[16:43] <kadams54> Yup
[16:43] <rick_h_> kadams54: cool, not sure on 10, but double it maybe? 
[16:43] <kadams54> I'll leave frankban's comment in there for the moment
[16:43] <rick_h_> k
[16:44] <frankban> Makyo: time for a hand off call?
[16:44] <Makyo> frankban, sure
[16:44] <rick_h_> frankban: Makyo can I get a listening invite please? 
[16:44] <frankban> rick_h_: sure
[16:44] <rick_h_> kadams54: ok, so how about we double it and mark it as a UX item to chat bout
[16:45] <rick_h_> lots of interactions we're not really thrilled about in this
[16:45] <frankban> Makyo, rick_h_: see http://pastebin.ubuntu.com/7453193/
[16:45] <kadams54> kk
[16:45] <hatch> ugh merge conflicts are gona kill me
[16:46] <jcsackett> Makyo: qa ok, thanks for the test, though i note we're skipping it?
[16:46] <frankban> rick_h_, Makyo https://plus.google.com/hangouts/_/canonical.com/daily-standup
[16:46] <rick_h_> hatch: :( was worried about that with the long running branch there this weekend
[16:46] <kadams54> rick_h_: how do you want me to mark it as a UX item? Card? Just a grep-able comment?
[16:46] <hatch> it's so bad....I've had to rebase it 4 times to develop already
[16:46] <rick_h_> kadams54: make a card for now, put it in the needs specification section on the board
[16:46] <hatch> 5 failing tests so I hope those aren't bad
[16:46] <jcsackett> hatch: ugh, dude that sucks. i have felt your pain (and recently. :p)
[16:46] <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.
[16:46] <jcsackett> Makyo: awesome. LGTM and all that jazz.
[16:47] <jcsackett> you can :shipit: when you like.
[16:47] <Makyo> jcsackett, thanks!
[16:47] <jcsackett> ...i like that *as i typed that* i saw the shipit command come over the PR. :P
[16:54] <kadams54> guihelp: https://github.com/juju/juju-gui/pull/313 ready for review and QA
[17:02] <rick_h_> kadams54: looking
[17:02] <rick_h_> redir: let me know when you're free
[17:03] <frankban> Makyo: https://github.com/frankban/juju-gui/tree/unit-placement
[17:03] <Makyo> frankban, thanks
[17:03] <redir> rick_h_: at your leisure
[17:04] <rick_h_> redir: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[17:07] <frankban> jujugui see you next Monday, have a great week!
[17:08] <hatch> jujugui lf a review/qa on https://github.com/juju/juju-gui/pull/303 hurry before I have to rebase again! :P
[17:08] <hatch> frankban cya! enjoy your holidays
[17:08] <kadams54> frankban: have a good time!
[17:08] <kadams54> hatch: looking
[17:16] <Makyo> Restart for updates before I get rolling.
[17:17] <kadams54> hatch: QA looks good to me
[17:20] <hatch> nice
[17:20] <hatch> thx
[17:21] <kadams54> Review also looks good
[17:22] <bac> hazmat`: ping
[17:23] <bac> rick_h_: i've produced the doc and walked through it.
[17:23] <rick_h_> bac: awesome! Can you email to hazmat`, james page, and copy myself on it please?
[17:25] <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.
[17:25] <rick_h_> bac: thanks
[17:25] <hatch> rick_h_ who's taking over frankbans branch?
[17:25] <hatch> is that not something we need for the demo?
[17:26] <rick_h_> hatch: Makyo has it now
[17:26] <hatch> ok cool
[17:26] <rick_h_> hatch: yes, it is. It's the last part after yours, to integrate them together
[17:26] <rick_h_> hatch: so you and Makyo should sync up and help him find the points of connection once your branch hits
[17:27] <hatch> will do
[17:27] <hatch> it's being shipped now
[17:27] <rick_h_> hatch: ty much sir
[17:29] <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
[17:29] <rick_h_> bac: crap
[17:30] <rick_h_> bac: odd, it looks like it should work http://bazaar.launchpad.net/~abentley/charms/precise/charmworld/trunk/view/head:/hooks/config-changed
[17:30] <rick_h_> bac: can you check what juju get gives you?
[17:30] <rick_h_> and see if the config change made it to juju-land?
[17:31] <bac> rick_h_: it did not
[17:31] <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
[17:31] <bac> i'll have to destroy the env and start over, which i will after lunch
[17:31] <rick_h_> bac: well from the current env, can you change the source and see if it does it now?
[17:31] <rick_h_> bac: or is it torn down already?
[17:32] <bac> ah, i bet i need to include the revno in the bundle
[17:33] <marcoceppi> rick_h_: why can't you remove a subordinate relation?
[17:33] <rick_h_> marcoceppi: no idea. 
[17:33] <marcoceppi> rick_h_: I'll file a bug!
[17:33] <rick_h_> marcoceppi: juju says you can't or the gui says you can't?
[17:33] <marcoceppi> gui, but we did it from cli and it worked
[17:33] <rick_h_> marcoceppi: yea, file a bug please
[17:34] <Makyo> hatch, running out to grab some food; don't have anything in the house.  Will be just a sec.
[17:35] <Makyo> rick_h_, marcoceppi pyjuju wouldn't allow that because it meant modifying another service's unit.
[17:35] <hatch> Makyo ok np, I'm judt going through code now
[17:35] <rick_h_> Makyo: ah, good to konw
[17:35] <marcoceppi> Makyo: figured it was something the the days of old
[17:36] <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
[17:39] <kadams54> I think Jenkins needs some swap days…
[17:39] <rick_h_> hah
[17:52] <rick_h_> Makyo: ignore that landing failed email from ci. Looks like we raced to get it to rerun and it ran it twice
[18:10] <kadams54> rick_h_: Looking for more work here… maybe the card about adding icons to the container's parent?
[18:10] <rick_h_> kadams54: sure thing
[18:10] <rick_h_> kadams54: take a look and let me know if you've got any questions or need a pre-imp
[18:12] <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?
[18:12] <rick_h_> kadams54: right, so when the db is updated, the machine token needs updating
[18:12] <rick_h_> and it needs an uncommitted flag
[18:12] <kadams54> k
[18:13] <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
[18:13] <rick_h_> though that's not the important part for now
[18:16] <hatch> yay branch landed
[18:16] <hatch> no more rebasing
[18:16]  * hatch jumps for joy
[18:16] <rick_h_> lol
[18:16] <kadams54> rick_h_: so this is for both the machine token and the container token?
[18:16] <kadams54> \o/
[18:16] <rick_h_> kadams54: so the container token should be updated as part of the interaction, but the machine token needs to be async updated
[18:16] <kadams54> Ah
[18:17] <kadams54> So add the unit to the container and then add the icon to both the container and the machine
[18:18] <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
[18:18] <rick_h_> kadams54: and then, after you click some confirm, the container, and unit get updated in the db.
[18:18] <kadams54> And the machine needs to update as well
[18:18] <rick_h_> kadams54: and the machine token that container is in, needs to be updated to show the new service it holds
[18:18] <rick_h_> or will hold technically
[18:18] <kadams54> k
[18:27] <hatch> wow there have been a lot of chances to the ecs stuff
[18:28] <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
[18:29] <hatch> well the original plan had it use a persistent data store 
[18:29] <hatch> but that was a lot of front loaded work
[18:29] <hatch> so now we are paying for it
[18:30] <hatch> should have just done the front loaded work
[18:30] <hatch> I blame the demo
[18:30] <hatch> :P
[18:30] <rick_h_> which persistant data store?
[18:31] <hatch> the one I was working on
[18:31] <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?
[18:31] <hatch> no but it would make going back and updating fields easier
[18:32] <hatch> the execution stuff would still be complicated no matter what
[18:32] <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. 
[18:32] <rick_h_> things like placeUnit and addUnits and such help things stay up to date
[18:33] <hatch> it's a pretty complicated problem
[18:34] <rick_h_> definitely
[18:34] <hatch> we are dealing with it on a case/case basisc
[18:34] <hatch> which is fine
[18:34] <rick_h_> I'll admit I was tricked by the fact that service/relation was simple and moved quickly
[18:34] <rick_h_> and when we got to machine/unit things got a level more complicated
[18:34] <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. 
[18:34] <hatch> and it'll all be thrown out when core gets this....
[18:34] <hatch> lol
[18:35] <rick_h_> I don't know, we'll have to go back and add some stuff on creating names for multiple services, units, machines
[18:35] <rick_h_> and keeping all that from conflicting, updating from deltas, etc
[18:35] <rick_h_> all that work will remain regardless of if core does some of this or not
[18:37] <hatch> we'll have to handle seamless interactions between deltas and env calls 
[18:37] <rick_h_> yes
[18:37] <hatch> for things like placing units on machines via the cli and gui
[18:37] <rick_h_> but it's starting to get cool. 
[18:38] <rick_h_> I so badly want my new container when I drop. :) this is going to be slick when it's released
[18:38] <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
[18:38] <rick_h_> right, and we've got 4s lag 
[18:38] <rick_h_> or sorry, deltas is a 10s thing
[18:38] <rick_h_> the main watcher they use is a 10s cycle watcher
[18:38] <hatch> yeah
[18:39] <rick_h_> so I'm not sure how much we'll ditch. That's an awfully poor UX to have multi second lags
[18:40] <hatch> yeah the ecs might have to move into the fakebackend
[18:40] <rick_h_> we'll see. one step at a time
[18:40] <rick_h_> we know they're not adding any of this in the current cycle
[18:40] <rick_h_> and who knows next cycle
[18:40] <hatch> hah probably not then either
[18:41] <rick_h_> and we've still got bundle supports/etc we'll beat on this code a bit over the rest of the year
[18:42] <hatch> yeah that one will be fun
[18:42] <hatch> Makyo did you have a pre-imp with frankban about his prototype?
[18:42] <Makyo> hatch, yeah
[18:42] <hatch> it looks pretty good to me 
[18:42] <Makyo> hatch, yep, going to get it cleaned up and such
[18:42] <Makyo> Working on tests now
[18:43] <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. 
[18:45] <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
[18:45] <hatch> it looks like it's pretty close to the original 
[18:45] <hatch> with lots of forks coming out of it
[18:46] <bac> compiz is eating my vm.  boo.
[18:46] <hatch> rick_h_ so what else would you like me on for now?
[18:47] <bac> rick_h_: thanks for the additional explanation to my email.  i assumed kapil and james knew what was going on demo-wise
[18:48] <rick_h_> bac: yea, there's several forces going on there and not sure who knows what to be honest
[18:48] <bac> well i hope they will hop right on it else we might have a stressful tomorrow
[18:48] <rick_h_> hatch: it's all about this drop/deploy working. I'm not sure how far Makyo's branch goes
[18:49] <hatch> ok - it should be adding the placeUnit functionality
[18:49] <hatch> which needs to be added to the drop function once landed
[18:49] <rick_h_> hatch: right, so there's probably some UI wiring to get the container token that needs to be in there
[18:49] <hatch> one line change as I understand it
[18:49] <rick_h_> hatch: and the clean up on deploy maybe?
[18:50] <rick_h_> hatch: the uncommited css notifications perhaps?
[18:50] <rick_h_> hatch: huw added methods for that, then those would need to be cleared on deploy
[18:51] <hatch> these are the ones that show up in the deployer bar?
[18:51] <rick_h_> hatch: no, the blue background on the container token
[18:51] <rick_h_> and the new machine token, which we're not using atm for the demo
[18:53] <hatch> oh ok, I was pretty sure the ghost machines/containers didn't show if they were ghosted
[18:53] <hatch> confirmed
[18:53] <hatch> so we should be showing those first
[18:54] <rick_h_> sorry, you skipped a step on me, what now?
[18:55] <hatch> if you go into the console and type 
[18:55] <hatch> ecs = app.env.get('ecs');
[18:55] <hatch> cb = function() { console.log(arguments); };
[18:55] <hatch> app.env.addMachines([{}], cb);
[18:55] <hatch> you don't get a machine listed in the machine column
[18:55] <hatch> until you commit()
[18:55] <hatch> uncommitted machines don't show up in the list
[18:55] <rick_h_> hatch: ah, yea you should get a machine token that's in uncommitted state
[18:55] <rick_h_> hatch: right, and they should
[18:56] <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
[18:56] <hatch> did that ever work? Should I be looking for a bug or implementing new
[18:56] <Makyo> Man, Francesco's smart.  I feel like I do something clever, then he just wafts through and clever turns into right.
[18:56] <rick_h_> hatch: honestly, not sure. it's partially related to kadam's work of showing uncommitted units on a machine
[18:57] <rick_h_> all that update the UI to match the db stuff
[18:57] <rick_h_> Makyo: :)
[18:58] <hatch> rick_h_ ok looking at the ecs stuff it looks like it's never worked
[18:58] <Makyo> Tests pass, working on lint.
[18:58] <hatch> it needs to do something similar to units being assigned
[18:58] <rick_h_> hatch: ok cool
[18:58] <rick_h_> Makyo: woot
[18:58] <hatch> we need to create a machine in the db then delete it  when it becomes a real boy
[18:58] <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
[18:59] <hatch> I need to wait for  Makyo's branch to land because it touches the same code haha
[18:59] <hatch> Makyo we can pair on this ^
[18:59] <rick_h_> hatch: heh yea, well if he's at lint you're on deck for review and helping to complete the demo 
[18:59] <rick_h_> :)
[19:01] <Makyo> Yeah, 2 minutes or so
[19:02] <Makyo> Then you can help me QA/.
[19:02] <hatch> sounds good
[19:04] <hatch> this machine view stuff is coming together really well
[19:05] <hatch> it would be done if it wasn't for the ecs lol
[19:05] <rick_h_> it's almost like we had a plan :P
[19:05] <Makyo> Haha
[19:07] <rick_h_> lol, changed my watch from C to F so it changed it from 24C to 24F
[19:07] <rick_h_> so helpful watch face
[19:08] <hatch> hahaha
[19:09] <hatch> you should just live with C
[19:09] <hatch> then you'll start using a base 10 measurement system
[19:09] <hatch> you'll then wonder what have you been doing your whole life!
[19:09] <hatch> and move to Canada 
[19:10] <hatch> Celsius is a Canadian gateway drug 
[19:10] <hatch> :P
[19:14] <Makyo> hatch, https://github.com/juju/juju-gui/pull/314
[19:14] <hatch> on it
[19:18] <hatch> Makyo I feel like there were a lot of things added to the code and not a lot of tests
[19:19] <hatch> these changes to the tests end up testing all the changes that were made?
[19:19] <Makyo> hatch, a lot changed, vs. added.  That's fair, though, first pass was to get tests working.
[19:19] <Makyo> hatch, PR was the best way for me to get it to you for QA, though.
[19:19] <Makyo> (well, easiest, and I'm lazy)
[19:20] <hatch> yeah ok that's fine - I just wanted to see if additional tests were still required
[19:20] <Makyo> I'll see what I can do.
[19:20] <hatch> code looks good, qa'ing
[19:26] <hatch> Makyo I think your qa step docs are borked on line 7
[19:26] <hatch> function() .... ?
[19:28] <Makyo> hatch, those were copied from francesco, give me a sec.
[19:28] <hatch> ohh ok I think it might be a bad line break then
[19:28] <hatch> that should have said
[19:28] <hatch> "ohh, I think it is a bad line break"
[19:29] <Makyo> Yeah, copied plain text from a pastebin, sorry
[19:30] <hatch> no problem, it worked but generated an error, trying again
[19:33] <hatch> Makyo I get Error: attempted to place a unit which has not been added: mysql/0
[19:33] <hatch> when running the placeUnit call
[19:34] <hatch> unless the first step where it says 'deploy' doesn't mean 'commit' ?
[19:34] <hatch> no it probably wouldn't
[19:34] <Makyo> I'll take a look, see if you can do additional QA
[19:35] <rick_h_> worked hedre
[19:35] <rick_h_> here
[19:35] <rick_h_> got the new unit in the changelog with machine and container
[19:36] <hatch> there we go got it
[19:36] <hatch> I was interpreting 'deploy' as 'commit'
[19:36] <rick_h_> ah, yea no deploy is the service call that the ecs captures
[19:37] <hatch> Makyo so are you adding the extra tests now or doing to do so in a follow-up?
[19:38] <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
[19:38] <hatch> sounds good
[19:38] <hatch> shipping
[19:38] <rick_h_> added a note to add a card for updating with moar tests!
[19:38] <hatch> moar tests!
[19:38] <rick_h_> hatch: so are you going to look at then wiring this into your drop and removing the original unit token?
[19:39] <Makyo> I was sitting down because I haven't yet today :P  I'll do further QA on real env.
[19:39] <hatch> I would really love it if we had tests along side each file in the folder oh man that would be nice
[19:39] <Makyo> But yeah, QA works for me in sandbox.
[19:39] <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
[19:40] <hatch> rick_h_ first ghost machines need to show up in the UI
[19:40] <rick_h_> hatch: they show up, just not as ghost
[19:40] <rick_h_> hatch: and for the demo they'll exist
[19:41] <rick_h_> make it deploy a bundle first, then drop on a container on a machine in the bundle
[19:41] <hatch> oh ok then yes I'll hook up the drag and drop to deploy the unit to the newly created container
[19:41] <rick_h_> hatch: thanks
[19:41] <hatch> rick_h_ is someone doing a few dry runs on this first? :)
[19:42] <rick_h_> hatch: that's why I want to get this working asap so we can start to
[19:42] <rick_h_> hatch: yes, we'll be working on dry runs as soon as the drop of the unit works
[19:42] <rick_h_> on lxc and ec2 and they'll have access to the hardware
[19:43] <hatch> cool, ok I'll get on the drag and drop
[19:58] <hatch> I've clicked that damn magnifying glass 100x today
[19:58] <rick_h_> hatch: lol
[19:58] <hatch> lol
[19:58] <rick_h_> so I just downloaded the pdf
[19:58] <rick_h_> and have it open in a pdf reader zoomed 
[19:58] <rick_h_> much nicer
[19:58] <rick_h_> hatch: or you mean the search button in the header?
[19:59] <hatch> yeah in the header.....it reloads the page
[19:59] <hatch> no prevent on it
[19:59] <rick_h_> heh yea. land mines wheeee
[20:02] <hatch> Makyo got a few for a hangout?
[20:02] <Makyo> Sure
[20:02] <hatch> ok sec creating
[20:03] <hatch> https://plus.google.com/hangouts/_/7ecpj6sl0bvcknh7up5ivfta7s?hl=en
[20:30] <hatch> Makyo thanks that was the trick, it appears to be working as expected now
[20:30] <rick_h_> woot!
[20:30] <hatch> ^ rick_h_  just need to remove the unplaced unit now
[20:30] <rick_h_> yay, my tablet has shipped from delta. I'm very curious if it's the right thing I get back
[20:30] <hatch> lol!!!
[20:30] <hatch> it might be someone elses haha
[20:31] <rick_h_> hah, I was getting worried that vegas was turning into a very expensive trip
[20:31] <hatch> lol
[20:31] <hatch> and you didn't even gamble!
[20:31] <hatch> ok so we need a card to have containers auto-update
[20:32] <rick_h_> hatch: rgr
[20:32] <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
[20:32] <rick_h_> hatch: to force a redraw of all the things and tie the stuff going on to what people are used to
[20:33] <hatch> good call -  makes it look like it's not broken
[20:33] <hatch> kehehehe
[20:33] <rick_h_> :)
[20:34] <hatch> ok unplaced units is not databound 
[20:35] <rick_h_> hmm, should be. I thought it was added today
[20:35] <rick_h_> kadams ^ bah how dare he not be here
[20:35] <hatch> lol I just tried tab complete and was like NOOOOOO
[20:35] <hatch> haha
[20:35] <hatch> looking into it
[20:35] <rick_h_> https://github.com/juju/juju-gui/pull/305
[20:35] <rick_h_> heh, you reviewed it
[20:36] <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
[20:36] <hatch> will investigate
[20:37] <rick_h_> hatch: I think that unit you're placing isn't in the db, it's a copy?
[20:37] <rick_h_> hatch: or does setting an attr not trigger the change event watched for?
[20:37] <hatch> nope it's in there....working as it should
[20:37] <hatch> that's my guess
[20:37] <rick_h_> this.get('db').units.after(['add', 'remove', '*:change'],
[20:38] <rick_h_> add works, maybe change isn't right
[20:41] <hatch> ahh that's it
[20:41] <hatch> change won't fire because they aren't models
[20:42] <rick_h_> right
[20:42] <hatch> they need to be revived, changed, then torn down
[20:42] <hatch> ON IT!
[20:47] <hatch> yeah fixed it
[20:47] <Makyo> Just wanted to let you know, we're all counting on you.
[20:47] <hatch> *that
[20:47] <hatch> like a boss
[20:47] <hatch> lol
[20:47] <hatch> now to figure out why I don't have any icons
[20:48] <rick_h_> lol
[20:48] <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
[20:48]  * rick_h_ is biab
[20:48] <hatch> cya
[20:55] <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
[20:55] <hatch> and the filterByMachine doesn't match the machine ids 
[20:55] <Makyo> hatch, that's when the callback is called; can the callback share part of the burden there?
[20:57] <hatch> I think so, trying
[21:09]  * bac walks the jojo
[21:09] <Makyo> I need to go get the dogs as muddy as possi-er, walk the dogs, back in a bit.
[21:24] <hatch> awesome - it now refreshes the container column when you drop the unit
[21:24] <hatch> this is READY TO GO
[21:24] <hatch> and full of ugly hacks
[21:25] <rick_h_> hatch: lol
[21:26] <rick_h_> hatch: documented hacks?
[21:26] <rick_h_> and I'm back in case anyone needs anything
[21:26] <hatch> that method is one big porn block
[21:26] <hatch> (XXX's)
[21:26] <rick_h_> lol
[21:26] <hatch> :D
[21:31] <lazyPower> \o/
[21:40] <jcsackett> rick_h_: are the next cards still prioritized? deployer test isolation higher priority than containers updating?
[21:42] <rick_h_> jcsackett: no, I've got to go through them tomorrow. 
[21:42] <rick_h_> jcsackett: the tech debt will be priority missing tests, etc.
[21:42] <rick_h_> jcsackett: and finishing the inspector left, which means finishing up my branch I put aside for now
[21:42] <Makyo> Back, +mud
[21:43] <rick_h_> jcsackett: I can toss a couple your way if you're looking
[21:43] <Makyo> And bills.  Why I ever pick up the mail is beyond me
[21:43] <rick_h_> Makyo: heh, yea. It's either spam or bills
[21:44] <rick_h_> jcsackett: have an interesting one for you
[21:44] <jcsackett> rick_h_: ok.
[21:44] <rick_h_> if I can find the UX wireframes
[21:49] <rick_h_> jcsackett: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1aHFtUE8zZTMzM0k
[21:49] <rick_h_> jcsackett: card is assigned, listing out the changes when clicking on the number in the deployer bar corner
[21:49] <rick_h_> jcsackett: let me know if you have any questions or want to pre-imp
[21:50] <jcsackett> rick_h_: it's almost EoD. i'll explore the relevant code today and ping you first thing tomorrow?
[21:50] <jcsackett> rick_h_: we've got everything that's needed for demo, yeah? or is this a demo thing?
[21:51] <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
[21:51] <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
[21:51] <jcsackett> rick_h_: ok. do you need any other eyeballs for that? 
[21:52] <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
[21:52] <hatch> jujugui https://github.com/juju/juju-gui/pull/316 BOOM
[21:52] <rick_h_> hatch: looking
[21:52] <hatch> don't judge me
[21:52] <hatch> :P
[21:52] <rick_h_> hatch: Makyo I'll do LXC QA 
[21:52] <Makyo> I'll QA in a real env
[21:52] <Makyo> Oh, hah
[21:52] <Makyo> Sure!
[21:52] <rick_h_> oh...I'll judge...really judge
[21:52] <hatch> aha
[21:52] <kadams54> Too late - you're a Canadian.
[21:52] <Makyo> I'll review etc.
[21:52] <kadams54> That makes you polite
[21:52] <Makyo> kadams54++
[21:52] <rick_h_> Makyo: jcsackett it'd be cool if someone tested out ec2 or HP or something
[21:52] <kadams54> A beer-drinking hockey fan
[21:53] <kadams54> With a closet full of flannel
[21:53] <Makyo> rick_h_, I have ec2
[21:53]  * hatch doesn't like hockey
[21:53] <rick_h_> Makyo: cool thanks
[21:53] <hatch> at least not watching it
[21:53] <jcsackett> forgot to ping earlier, jujugui: tiny PR https://github.com/juju/juju-gui/pull/315
[21:54] <rick_h_> kadams54: got time to review ^ ?
[21:54] <kadams54> yeah
[21:54] <rick_h_> thanks
[21:54] <rick_h_> oh the judging! :P
[21:55] <rick_h_> hatch: it's not that bad, at least the parts 'fit' together and make sense I think
[21:55] <rick_h_> but maybe I've been looking at too many branches of this stuff lately :P
[21:55] <hatch> haha - yeah it works and all that - there is just so many better ways to do this :)
[21:55] <rick_h_> hatch: well, but iteractions on the current idea I think. 
[21:56] <rick_h_> more automation/etc
[21:56] <hatch> yeah true true
[21:56] <rick_h_> unless you have a plan that's a completely different path?
[21:56] <hatch> no, originally I had a different plan but this path works just fine
[21:57] <rick_h_> lol, we'll get your plan next time
[21:57] <hatch> haha no biggy
[21:58]  * hatch is being punished for the inspector debacle 
[21:58] <rick_h_> lmao
[21:58] <rick_h_> hey, I've worked hard to not have anything come across as punishment :P
[21:58] <rick_h_> after all, still fighting state myself :/
[21:58] <hatch> haha
[21:59] <jcsackett> ...if you had to work hard to have nothing come across as punishment, that implies something *could* be thought of as punishment. :p
[21:59] <hatch> haha
[22:01] <kadams54> hatch: did you test this in Vagrant?
[22:01] <hatch> I work in vagrant, so yes?
[22:02] <kadams54> OK… seeing some funkiness and trying to rule out potential causes.
[22:02] <hatch> I have to run test-server though
[22:02] <hatch> it won't run through on debug in vagrant
[22:03] <kadams54> Funkiness was resolved with make clean
[22:03] <kadams54> You're off the hook ;-)
[22:03] <jcsackett> `make clean` is magic.
[22:04] <rick_h_> it's showing, you have to take a shower once in a while :P
[22:04] <rick_h_> even spartans 
[22:04] <hatch> haha
[22:04] <kadams54> :-b
[22:04] <bac> rick_h_: hey have you heard anything from our intrepid friends in ATL?
[22:05] <rick_h_> bac: not a peep
[22:05] <rick_h_> bac: not seem them active on irc
[22:05] <bac> rick_h_: well, i've done about all i can without any participation/feedback
[22:05] <rick_h_> bac: agreed
[22:05] <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
[22:06] <bac> rick_h_: rt.  the process is a little clunkier than i'd like due to juju / quickstart / charmworld charm issues
[22:07] <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. 
[22:07] <rick_h_> bac: thanks a ton for getting that working. I think it'll be cool even beyond this demo to have that handy
[22:08] <bac> rick_h_: sure, but the things i encountered are usability for the tool chain
[22:08] <bac> rick_h_: what time is the demo?
[22:08] <rick_h_> bac: which parts? I thought it was just the charm and the branch suport?
[22:08] <rick_h_> bac: so the big one for Mark is 10:20 central I think
[22:08] <bac> 'juju scp -r' doesn't work
[22:09] <rick_h_> oh, yea I saw that conversation go by. 
[22:09] <bac> config settings in a bundle are not being set by the charm when deployed with quickstart
[22:09] <rick_h_> bac: right, we've got a bug to add that
[22:09] <bac> that may be the charm's fault
[22:09] <rick_h_> I think it's inthe maint. backlog
[22:09] <bac> which? the config setting?
[22:09] <rick_h_> well to provide a config.yaml override
[22:10] <rick_h_> it should "just work" if it's in the bundle.yaml
[22:10] <bac> oh, am i just stupid?  can the bundle only contain juju-level settings?
[22:10] <bac> num_units, etc?
[22:10] <rick_h_> bac: yep
[22:10] <rick_h_> oh no, it can contain config
[22:10] <bac> gah.  my bad.
[22:10] <rick_h_> sorry, multi tasking, the bundle can contain config overrides I think
[22:11] <bac> rick_h_: ok, well those aren't being respected, at least by this charm
[22:11] <rick_h_> http://comingsoon.jujucharms.com/bundle/~charmers/mediawiki/6/single/#code
[22:11] <bac> i'll sort it out tomorrow when i can talk to frankban
[22:11] <rick_h_> bac: right, that might be a charm bug that it's not accepting the config change on install
[22:11] <rick_h_> bac: well I think he's afk for the rest of the week. 
[22:12] <rick_h_> bac: ^ shows the options: xxxx block passed from the bundle
[22:12] <bac> ah, i didn't use the 'options' heading!
[22:12] <hatch> rick_h_ how goes the lxc qa?
[22:13] <rick_h_> hatch: working on it
[22:13] <rick_h_> sorry, talking to others :)
[22:13] <hatch> hah no problem
[22:16] <hatch> jcsackett reviewed your branch
[22:21] <rick_h_> hatch: the container didn't update for me on drop?
[22:22] <hatch> it didn't render a new one?
[22:22] <rick_h_> hatch: no
[22:22] <hatch> ^ kadams54  did you have the same issue in qa?
[22:22] <rick_h_> sec, will try another service
[22:23] <kadams54> rick_h_ hatch I did have that issue, but that's what the clean fixed
[22:23] <kadams54> http://cl.ly/image/0n1W1Z443K2c
[22:23] <rick_h_> kadams54: well this is on a deployed service
[22:23] <hatch> ohh - rick_h_  maybe make clean will work for you?
[22:23] <kadams54> The container didn't update on drop and the list of unplaced units didn't update either
[22:23] <hatch> ohh
[22:23] <kadams54> Ah yeah
[22:23] <kadams54> I was vagrant
[22:24] <rick_h_> swapping to service and back worked
[22:24] <rick_h_> and I didn't get a nagios unit. 
[22:25] <hatch> so it doesn't actually work then?
[22:26] <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
[22:26] <rick_h_> just unit-less in a real env
[22:26] <hatch> :/
[22:26] <hatch> can you put a debugger in go.js add_unit()
[22:26] <hatch> see if it gets called?
[22:26] <hatch> debugger/breakpoint
[22:27] <rick_h_> Uncaught Error: attempted to place a unit which has not been added: 61439359$/0 
[22:27] <hatch> what the....
[22:27] <hatch> so there is clearly some difference on a real environment
[22:27] <rick_h_> ok, so reload the browser window, nagios is there without any units. 
[22:28] <rick_h_> trying to deploy wordpress
[22:28] <rick_h_> oh, that worked now
[22:28] <rick_h_> well the container updated
[22:28] <hatch> lol
[22:28] <hatch> the attempted to place error is from the placeUnit() call
[22:28] <rick_h_> no errors this time
[22:28] <hatch> ohh 
[22:29] <hatch> nagios is a subordinate
[22:29] <rick_h_> ran it with the debug toolbar open? 
[22:29] <rick_h_> hatch: no, nrpe is, nagios is a server
[22:29] <rick_h_> we picked nagios just because of that, it's a server with a web interface
[22:29] <hatch> ohh ok
[22:29] <hatch> hmm
[22:29] <rick_h_> when I click on the wordpress in service view the inspector shows me "one undefined unit: 31706881$/0"
[22:30] <rick_h_> and again, no units.
[22:30] <rick_h_> ok, will try to debugger in placeUnit()
[22:31] <hatch> the env needs to make the add_unit call for it to actually create the unit
[22:31] <hatch> I'm wondering if any of this stuff was tested on a real env
[22:31] <rick_h_> bah, compressed JS files fail
[22:31] <hatch> it might just simply not work
[22:31] <rick_h_> wheeee
[22:31] <hatch> heh, switch the gui to debugger mode :)
[22:31] <rick_h_> ok, will reload and watch the wss traffic
[22:33] <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)
[22:34] <rick_h_> hatch: yea, not seeing a unit call in wss
[22:35] <rick_h_> {"Type":"Client","Request":"ServiceDeploy","Params":{"ServiceName":"mysql","Config":{},"Constraints":{},"CharmUrl":"cs:precise/mysql-44","NumUnits":0},"RequestId":19}
[22:35] <rick_h_> {"Type":"Client","Request":"AddMachines","Params":{"MachineParams":[{"Jobs":["JobHostUnits"],"ParentId":"6","ContainerType":"lxc"}]},"RequestId":20}
[22:35] <hatch> ok so basically that means that the lazyaddunit doesn't work
[22:35] <rick_h_> yea
[22:35] <rick_h_> something isn't right there
[22:36] <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
[22:37] <hatch> breakpoint*
[22:37] <rick_h_> sec, just resetting env, have to get the boy some sort of food for dinner and brb. 
[22:38] <hatch> yeah np
[22:47] <hatch> rick_h_ in sandbox I put a breakpoint in _add_unit() in go.js and it was never hit
[22:47] <rick_h_> hatch: k, makes sense then
[22:47] <hatch> ^ Makyo  any idea what's broken here?
[22:48] <hatch> I can step through the changeset execution
[22:48] <Makyo> 1sec.
[22:48] <hatch> just wondering if you might have any other insight :)
[22:48] <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?
[22:49] <hatch> the command looks good
[22:49] <rick_h_> hatch: does the lxc parent complete/hit the callback?
[22:50] <hatch> just going to step through the commits
[22:50] <hatch> watch the flow of it
[22:52] <hatch> ok the addUnit call is never executed by the ecs
[22:52] <rick_h_> the ghost deployer extension is supposed to addUnit when you drop the service
[22:52] <rick_h_> ?
[22:53] <rick_h_> so you have the call in the changeset, but it's not executed?
[22:53] <hatch> correct
[22:53] <rick_h_> ok, so that means something in the parent/etc setup is failing to hit the child
[22:53] <hatch> service deploy and add machine commands are executed
[22:53] <rick_h_> they're not parent/child
[22:53] <hatch> _commitNext() is never called with the unit command
[22:54] <hatch> the heirachy is properly built
[22:54] <rick_h_> yea, something in the callbacks
[22:54] <hatch> hierarchy 
[22:55] <rick_h_> so this might be due to frankban changing the id from being the changeset id to the actual model id
[22:56] <hatch> it's waiting for the level to be completed
[22:56] <hatch> but it never is
[22:57] <hatch> the addMachine callback is not returning
[22:57] <hatch> so it's not triggering the level complete
[22:57] <hatch> now....how to fix that
[22:57] <hatch> heh
[22:58] <Makyo> GUI can't load any charmworld assets: net::ERR_BLOCKED_BY_CLIENT - did something change on charmworld's side?
[22:58] <Makyo> ditto assets.ubuntu.com
[22:59] <rick_h_> Makyo: not that I'm aware of, was just doing it
[22:59] <hatch> hmm it's working in the GUI for me
[22:59] <rick_h_> Makyo: maybe you're falling into some ip addr black hole?
[22:59] <Makyo> This is ec2
[22:59] <hatch> did you open the ports?
[22:59] <hatch> :)
[22:59] <hatch> oh wait nm juju does that
[22:59] <hatch> heh
[22:59] <rick_h_> well it should be able to go out 
[23:00] <rick_h_> and the client is doing it not the ec2 stuff
[23:00] <Makyo> Wellp.
[23:00] <rick_h_> http://stackoverflow.com/questions/22318119/i-am-getting-failed-to-load-resource-neterr-blocked-by-client-with-google-chr ?
[23:00] <rick_h_> ad blockers enabled?
[23:01] <Makyo> Damnit.
[23:01] <Makyo> EFF's Privacy Badger was running./
[23:02] <hatch> lol
[23:02] <hatch> oh I think I found the bug
[23:03] <rick_h_> good because my brain isn't up to following the callback levels atm :P
[23:03] <redir> love it:) I have had to debug ghostery for the same reasons before Makyo 
[23:04] <hatch> yep fixed it
[23:04] <hatch> cleaning up then pushing
[23:05] <rick_h_> woot
[23:06] <hatch> rick_h_ Makyo  fix pushed plz try qa on a real env again https://github.com/juju/juju-gui/pull/316
[23:07] <Makyo> Alright, on it.
[23:07] <hatch> *phew* was REALLY worried there was an architectural bug introduced by something frankban did lol 
[23:07] <hatch> I did not want to have to fix that tonight haha
[23:07] <hatch> instead it was a bug I introduced....which is much more acceptable lol
[23:08] <hatch> introduced? should have been protected against?....yeah the latter
[23:08] <hatch> ;)
[23:10] <hatch> doh, lint
[23:10] <hatch> fixing...
[23:10] <huwshimi> Morning
[23:11] <rick_h_> just got a phone call from ramm
[23:12] <rick_h_> promising a dist tarball in an hour :) 
[23:12] <rick_h_> hopefully :/
[23:12] <huwshimi> rick_h_: Did you just see that email from James>
[23:12] <huwshimi> *?
[23:12] <redir> coop shift, later
[23:12] <rick_h_> huwshimi: not yet
[23:12] <huwshimi> rick_h_: He needs help
[23:13] <rick_h_> huwshimi: got a phone call from ramm
[23:13] <rick_h_> promised them a tarball in an hour or less
[23:13] <huwshimi> ah ok
[23:13] <rick_h_> hatch: reloading here
[23:16] <hatch> ok, new linted and test passing version has been pushed up
[23:17] <hatch> heh
[23:17] <hatch> I just read the email, was going to say we needed to get them a tarbal
[23:17] <hatch> :D
[23:17] <rick_h_> :)
[23:18] <rick_h_> ok, so the unplaced unit token stuck around 
[23:18] <rick_h_> until I swapped back/forth but not the worst that can happen
[23:18] <hatch> ok that's not horrible......but did we get a unit in the env....
[23:18] <rick_h_> woot! "1 pending units nagios/0"
[23:18] <hatch> YES!!!!!
[23:19] <rick_h_> lol, but in lxc it creates a new machine anyway 
[23:19] <rick_h_> Makyo: here's hoping you've got better luck?
[23:19]  * rick_h_ remembers this is why quickstart puts the gui on a new machine on local
[23:19] <hatch> rick_h_ haha, well you can't create an lxc in an lxc :)
[23:20] <Makyo> rick_h_, let me tell you about stupid hooks.
[23:20] <hatch> you need to do lxc > kvm > lxc or something
[23:20] <rick_h_> bah, and an empty machine hanging there, but probably due to this mess
[23:20]  * rick_h_ destroys local and goes to ec2
[23:20] <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.
[23:21] <rick_h_> Makyo: :(
[23:21] <Makyo> rick_h_, also, if you set a config value to the same thing, config-changed doesn't appear to fire.
[23:21] <Makyo> so I've destroyed and re-deployed this thing four times.
[23:21] <rick_h_> Makyo: yea, you have to set it to develop and then back again
[23:21] <rick_h_> heh
[23:21] <Makyo> Anyway, I'm almost there promise
[23:21] <rick_h_> well, running quickstart on ec2 right no
[23:21] <rick_h_> now
[23:21] <hatch> brb letting dogs out
[23:21] <Makyo> More tests, the betteer
[23:25] <rick_h_> grrr no love on ec2 stupid thing
[23:25] <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
[23:28] <rick_h_> hmm, seems to be doing better this time...maybe
[23:30] <rick_h_> yay bootstrapped
[23:30] <rick_h_> juju deploy juju-gui --to=0 
[23:30] <rick_h_> go go go
[23:33] <rick_h_> ok, running on ec2
[23:33] <rick_h_> updating branch
[23:38] <rick_h_> hatch: Makyo we might need to prepare to not use lxc sub container but just colocate two on bare metal. 
[23:39] <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?
[23:40] <jcsackett> rick_h_ did you see James pages comment on the Ods doc?
[23:40] <rick_h_> jcsackett: yes
[23:40] <jcsackett> Good stuff. 
[23:41] <hatch> rick_h_ so it still doesn't create a unit/ 
[23:41] <hatch> ?
[23:41] <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
[23:41] <rick_h_> hatch: I'm trying to figure out if kvm is allowed
[23:41] <rick_h_> or if we just need to colocate on bare metal
[23:42] <rick_h_> hatch: while I wait to hear something (by irc, phone or email I've tried all three) 
[23:42] <rick_h_> I'm still trying to QA on ec2
[23:42] <hatch> oh boy lol
[23:42] <rick_h_> and damn these ec2 machines are so slow for building hte distfile
[23:42] <Makyo> Do the series have to match?
[23:44] <jcsackett> rick_h_ The comment in referring to is he can't do npm stuff, so setting up develop is failing. 
[23:44] <jcsackett> s/in/I'm/
[23:44] <rick_h_> hatch: ok, colocated bare metal
[23:44] <rick_h_> hatch: we need to rip out the lxc bits
[23:44] <rick_h_> jcsackett: looking
[23:45] <rick_h_> jcsackett: he'll not be using devleop
[23:45] <rick_h_> jcsackett: we'll get him a tarball
[23:45] <hatch> colo bare metal? I thought that wasn't recommended lol
[23:45] <rick_h_> hatch: oh well!
[23:45] <rick_h_> hatch: it's openstack on openstack so no kvm and no lxc
[23:45] <hatch> so.....anyone know the id syntax for creating a colo on bare metal? :)
[23:45]  * hatch goes digging
[23:45] <Makyo> hatch, just don't specify the destination as a container.
[23:46] <hatch> it's based on the path
[23:46] <rick_h_> hatch: right, I think we can just addUnit with the existing machine id
[23:46] <hatch> oh....so no machine?
[23:46] <rick_h_> jcsackett: I don't see these comments where is this?
[23:46] <hatch> hmm
[23:47] <hatch> can you verify this on your ec2 env?
[23:47] <rick_h_> hatch: right, the machine will already exist, we'll drop onto the header, and just deploy on it
[23:47] <rick_h_> hatch: how can I test it? 
[23:47] <hatch> well I mean via the command line
[23:47] <hatch> add unit to the machine
[23:47] <rick_h_> hatch: help me with instructions and I'll try it out
[23:47] <hatch> ok one sec
[23:48] <hatch> well you'd need to deploy a service with 0 units
[23:48] <hatch> then `juju add-unit <that service> --to <machine num>`
[23:49] <rick_h_> from the cli? 
[23:49] <hatch> yeah
[23:49] <hatch> I just want to make sure that those sequence of events actually work
[23:49] <rick_h_> looking
[23:50] <rick_h_> cli won't let me error: --num-units must be a positive integer
[23:50] <jcsackett> rick_h_ want me to reply that there's a tarball coming with the dependencies?
[23:50] <rick_h_> but we know you can via the api
[23:50] <rick_h_> jcsackett: where is this?
[23:50] <jcsackett> Email reply to the sharing of the ODS doc. 
[23:51] <jcsackett> To you, cc'ed to the rest of us. 
[23:51] <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. 
[23:51] <rick_h_> jcsackett: ok, I think that's old info. I've already handled that one
[23:51] <rick_h_> we're onto the next issues of lxc containers on the demo hardware won't work
[23:52] <hatch> rick_h_ ok I'm writing the handler to deploy to bare metal
[23:52] <jcsackett> rick_h_ ah, ok. Saw the question w/ no reply. Hadn't realized lxc was the next issue. 
[23:52] <rick_h_> hatch: rgr, thanks
[23:52] <hatch> will post back when it's tested
[23:52] <rick_h_> jcsackett: my bad, didn't notice I needed to reply to all
[23:52] <rick_h_> hatch: rgr, will leave up my ec2 to test it on
[23:52] <rick_h_> and will bring up an lxc to test it on as well
[23:54] <rick_h_> hatch: one drive by please, rename the drop target heading "Colocate on this machine"
[23:56] <rick_h_>  /Create new container/Colocate to machine
[23:58] <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
[23:58] <hatch> placing a unit on a bare metal creates a new machine....
[23:59] <rick_h_> hatch: that's in sandbox?
[23:59] <hatch> yeah....
[23:59] <rick_h_> hatch: I'm not sure the sandbox supports colocated services like that. I bet it adds a new machine
[23:59] <hatch> ok, checking the commands it executes
[23:59] <hatch> then will push it up
[23:59]  * rick_h_ is thinking.