[00:19] <hatch> hey huwshimi
[00:20] <huwshimi> Hey
[00:21] <huwshimi> hatch: How's things?
[00:21] <hatch> going good - just trying to get everything done before next week
[00:22] <hatch> seems these things always happen a week too early haha
[00:22] <huwshimi> :)
[11:01] <rick_h_> morning party people
[11:05] <rick_h_> frankban: how goes this morning?
[11:06] <frankban> rick_h_: I was going to send you an email
[11:06] <frankban> rick_h_: I was able to give internet access to nodes, by doing the following:
[11:06] <frankban> - add a default 10.0.0.1 gateway to the MAAS network;
[11:06] <frankban> - fix the POSTROUTING netfilter rule in the host, i.e.
[11:06] <frankban>   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
[11:07] <rick_h_> cool, yea that's what I was just looking at in some google searches
[11:07] <frankban> rick_h_: Next error was related to juju tools: "cannot execute binary file: Exec format error”.
[11:07] <frankban> See https://bugs.launchpad.net/juju-core/+bug/1325968
[11:07] <frankban> so the fix seems t be --constraints arch=i386
[11:08] <rick_h_> ugh
[11:08] <frankban> rick_h_: with that constraint, juju finally bootstrapped!
[11:08] <rick_h_> yay!
[11:08] <frankban> rick_h_: so now I am testing quickstart with and without the constraints flag
[11:09] <rick_h_> frankban: <3 ok very cool. Glad you're unblocked enough. Thanks for helping throgh all this fun stuff
[11:09] <rick_h_> frankban: let's make sure we add notes to that maas doc so that we can make sure this works out as the hope is we'll have a maas lab going forward
[11:09] <frankban> rick_h_: yeah it was ages since my last iptables command ;-)
[11:10] <rick_h_> no kidding, I got that far last night and took that as a sign I was done :)
[11:10] <rick_h_> iptables and multiple glasses of wine never mix lol
[11:10] <frankban> :-)
[11:11] <frankban> rick_h_:  now running ".venv/bin/python juju-quickstart --constraints arch=i386" fingers crossed
[11:12] <rick_h_> frankban: cool, maybe did I install i386 ubuntu on the maas controller?
[11:12] <frankban> rick_h_: unrelated, but ssh always disconnects me after a few minutes with a broken pipe
[11:12] <frankban> rick_h_: the kernel is 64 bit
[11:12] <rick_h_> frankban: yea, I wonder if I've got a network thing going on. It kept doing that to me ssh'ing out on my laptop last night
[11:12] <rick_h_> frankban: but my desktop stayed connected the whole time, so it's strange
[11:13] <frankban> rick_h_: the nodes are i386, and that's where tools are used
[11:13] <rick_h_> frankban: ic, but the nodes can be anything right? We can set them as amd64 in maas and it should install the right images from it's list of images?
[11:13] <frankban> rick_h_: in theory yes, in theory...
[11:13] <rick_h_> lol
[11:14] <rick_h_> frankban: ok, so you ssh'd in and verified they were running i386 images?
[11:14]  * rick_h_ is trying to phrase a reply to the bug and if we can dupe it we should work with juju core on it
[11:14] <frankban> rick_h_: no I have not but in the edit node page i see "i386/generic" arch
[11:15] <rick_h_> frankban: oh? oooh, ok. 
[11:15] <rick_h_> I was looking at nuc2 which is amd64
[11:16] <rick_h_> so maybe it's my failing to setup maas correctly
[11:16] <rick_h_> frankban: when you're test is done let me know and we'll edit the node and try to recomission it
[11:16] <frankban> rick_h_: ok
[11:16] <rick_h_> and see if we can get updated software on it
[11:16] <rick_h_> and then make it work sans constraint :)
[11:17] <frankban> rick_h_: woot, all's good for now: http://pastebin.ubuntu.com/8472118/
[11:17] <rick_h_> yay!
[11:18] <rick_h_> so now the other thing to document is sshuttle into the 10.0 network on there so you can get at the gui
[11:18] <frankban> rick_h_: quickstart has not finished yet
[11:18]  * rick_h_ really doesn't want to redo this setup but wonders if trying to put all the nodes on the public network would be best
[11:19] <frankban> rick_h_: so, GUI deployed, but then quickstart exited with an error: juju-quickstart: error: unable to connect to the Juju API server on wss://nuc1.maas:443/ws: [Errno -2] Name or service not known
[11:20] <frankban> so, dns is not working
[11:20] <rick_h_> hmm, yea
[11:21] <rick_h_> so maas is setup and supposed to manage dns, but I bet it's because I set the dns on the hosts to google or something vs itself
[11:22]  * rick_h_ looks up format of dig commands
[11:23] <rick_h_> dig nuc1.maas @10.0.0.1
[11:23] <rick_h_> works so cool
[11:24] <rick_h_> frankban: ok, updated resolv.conf and the nameserver for the 10.x interface and just a normal cli "dig nuc1.maas" returns now
[11:26] <frankban> rick_h_: cool, so, I'll re-run quickstart on the bootstrapped environment and this time it should be able to connect to the gui server
[11:27] <rick_h_> frankban: rgr
[11:27] <frankban> rick_h_: done, quickstart completed successfully: http://pastebin.ubuntu.com/8472146/
[11:27] <frankban> \o/
[11:27] <rick_h_> woooooooo!
[11:27] <rick_h_> it's early...but a happy dance it is
[11:28] <frankban> rick_h_: destroying the environment
[11:28] <rick_h_> hold on if you can
[11:28] <frankban> ops
[11:28] <rick_h_> ok, np
[11:28] <frankban> rick_h_: another thing I noted, when destroying an environment the node is left to Releasing failed status, and you need a manual "release" fot it to be back in ready state
[11:29] <rick_h_> frankban: yea
[11:29] <frankban> rick_h_: but I guess it's not our problem
[11:29] <rick_h_> frankban: ok so sshuttle -v -D -r ubuntu@maas.jujugui.org 10.0.0.0/24
[11:29] <rick_h_> let's me load up maas on http://10.0.0.1/MAAS
[11:29] <frankban> rick_h_: cool, should wer try to switch nuc1 to amd64?
[11:30] <rick_h_> frankban: so the hope is that line will let us load up the gui and environment stuff once it's brought up
[11:30] <rick_h_> frankban: yea, let's do that
[11:30] <rick_h_> frankban: ok switched and comissioning
[11:30] <frankban> rick_h_: cool thanks
[11:31]  * rick_h_ wishes he had all the kvm stuff setup to watch it and make sure it's going...doesn't trust maas enough yet
[11:31] <rick_h_> frankban: yea, on the release node stuff, it's new and we've got some issues from the experimental branch
[11:31] <rick_h_> frankban: you'll be happy to know our big problem before was lack of the amt control tools package installed
[11:31] <rick_h_> frankban: the new software shows the error while before I assumed maas handled that bit
[11:32] <frankban> rick_h_: yay for experimental maas
[11:32] <rick_h_> definitely, so maas was never powering on/off our machines as hoped
[11:32] <frankban> ic
[11:33] <frankban> rick_h_: one confusing bit is that nuc1 pretends to have 10.0.0.151 addr, but when it starts it's on 10.0.0.100
[11:34] <rick_h_> frankban: yea, I'm not sure what's up with that to be honest. 
[11:35] <frankban> rick_h_: ok the node is ready
[11:35] <frankban> rick_h_: running quickstart without constraints
[11:35] <rick_h_> frankban: rgr
[11:36] <frankban> rick_h_: at least we now my branch with maas support works and generates a reasonable configuration
[11:38] <rick_h_> frankban: :)
[11:39] <rick_h_> frankban: yea, I had hoped it would be very little different other than generating the proper environments.yaml
[11:39] <frankban> rick_h_: yeah, it's basically just it
[11:39] <rick_h_> and then 3 days of getting maas and juju happy lol
[11:39] <rick_h_> across timezones 
[11:39] <frankban> lol
[11:40] <rick_h_> hmm, it's green and says deployed?
[11:40] <frankban> rick_h_: yeah, qucikstart still bootstrapping
[11:40] <rick_h_> cool
[11:41] <frankban> rick_h_: and now it's deploying
[11:41] <frankban> rick_h_: so bootstrap succeeded without constraints
[11:41] <rick_h_> woot
[11:41] <rick_h_> lol, every change one step closer...and closer...and closer
[11:41] <frankban> waiting for the new shiny cs:trusty/juju-gui-9 unit to be deployed
[11:42] <frankban> rick_h_: done! quickstart is ready
[11:42] <rick_h_> sweet, so with the shuttle command can you load the gui in your local browser now?
[11:42] <frankban> trying
[11:45] <rick_h_> it works here https://10.0.0.100/login/
[11:45] <frankban> rick_h_: it works!
[11:45] <rick_h_> woot!
[11:45] <rick_h_> jujugui we have a maas ! rock on frankban 
[11:45] <frankban> rick_h_: password is 109b105fe8b699f4b0a2555563502331
[11:46] <rick_h_> hah, /me wants to deploy something!
[11:46] <frankban> rick_h_: machine view shows 0-state service 4xGHz, 8.0GB,
[11:46] <frankban> \o/
[11:46] <rick_h_> nice!
[11:46] <frankban> we might want to strip the final comma there ;-)
[11:46] <rick_h_> and with machine view we can container on that thing and deploy crazy stuff
[11:46] <rick_h_> lol
[11:47] <urulama> rick_h_, frankban: did anyone tried juju-gui on manual? i can play with that tonight before going to bed as I wanted to test using mongo shards and multi CS units
[11:47] <frankban> rick_h_: ghost charm on the bootstrap node?
[11:47] <rick_h_> frankban: yea, should work
[11:48] <rick_h_> urulama: 'juju-gui on manual'?
[11:48] <frankban> rick_h_: in a container?
[11:48] <urulama> rick_h_: manual environment
[11:48] <rick_h_> urulama: oh hmm, not sure. 
[11:48] <rick_h_> frankban: yea, lxc it up
[11:48] <urulama> rick_h_: ok, i'll let you know
[11:48] <rick_h_> frankban: my understanding is that the lxc container will get a root 10.0.0.xx ip from dhcp
[11:48] <rick_h_> frankban: and be able to be exposed at the root network level
[11:49] <rick_h_> urulama: I think with machine view now you could bring up the machines, add them, and they'd show up in machine view
[11:49] <rick_h_> urulama: and then you could deploy to them directly
[11:49] <rick_h_> urulama: but you'd have to add them and such via cli/manual stuff first? 
[11:50] <rick_h_> ok, bringing up elasticsearch on nuc2 hopefully
[11:52] <frankban> rick_h_: nuc2 is pending, 0/lxc/0 is pending. man, this GUI thing seems to work just fine
[11:52] <rick_h_> frankban: <3
[11:52] <rick_h_> frankban: sometimes, we do damn good work :)
[11:52] <urulama> rick_h_: yes, adding will have to be done by add-machine unless there is code in GUI that makes this "add-machine" call. 
[11:53] <rick_h_> urulama: right, it makes an add-machine call but I think in manual you have to provide extra info to that call as to where the machine to add is located
[11:53] <rick_h_> urulama: and the gui doesn't do that
[11:53] <frankban> rick_h_: http://10.0.0.155:2368/ \o/
[11:53] <urulama> rick_h_: ok.
[11:53] <rick_h_> frankban: woot, ghost looks green and exposed
[11:53] <rick_h_> haha! 
[11:54]  * rick_h_ does another round of happy dance and notices son is up...time to prepare for day bare biab
[11:54] <rick_h_> frankban: you rock thanks again for the pita work on this!
[11:54]  * rick_h_ goes afk for a little bit
[11:54] <frankban> and it's not "Just a blogging platform.". it's more "just a blogging platform deployed via a GUI which manages juju on top of a maas controller"
[11:54] <urulama> rick_h_, frankban: did you try deploying openstack? :P
[11:56] <frankban> urulama: I don't even know where to start to do that. but for our scope, ghost is as good as openstack ;-)
[11:59]  * frankban lunches
[12:00] <urulama> frankban: https://jujucharms.com/bundle/~james-page/openstack-on-openstack/25/openstack/?text=openstack
[12:06] <rick_h_> frankban: urulama http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/ :P
[12:06] <urulama> rick_h_: even better :)
[12:06] <rick_h_> frankban: urulama so I think I'll end up getting a 3rd nuc so we can easily test out bundles on two empty nodes and maybe then we can get openstack on them :P
[12:07] <rick_h_> oh boo, elasticsearch failed
[12:08] <rick_h_> oh, it can't reach out to the internet
[12:09] <rick_h_> no, it did reach out ok. It just got a forbidden for some reason ok
[13:49] <frankban> guihelp: is anyone available for taking a look at https://codereview.appspot.com/151200043 (quickstart/python)? thanks!
[13:50] <frankban> rick_h_: thanks for the nice email
[13:51] <rick_h_> frankban: <3
[13:53] <bac> frankban: i can look
[13:53] <frankban> bac: thanks
[13:54] <bac> ah, i've missed rietveld.
[13:54] <hatch> like honestly?
[14:00] <bac> compared to reviews on github, yeah.
[14:00] <frankban> +1
[14:00] <hatch> the only difference I can see is that you can queue up review comments
[14:01] <hatch> but you can also do that on github wtihout clicking 'submit'
[14:01] <bac> hatch: so you keep each comment in limbo and then submit them all at once?
[14:02] <hatch> no because queuing up the comments doesn't really bother me :) 
[14:02] <hatch> but it is possible
[14:02] <bac> hatch: i also don't like how it collapses and hides your comments when a new revision is pushed.  i find it very hard to follow the review and determine if everything has been addressed.
[14:02] <frankban> hatch: there are other little things that I miss. For instance, better handling of long lines (when reviewing go code it is useful), ability to comment unchanged code and above all, a way to review patches and follow the review discussion that doesn't drive me crazy
[14:03] <hatch> reitveld frequently 'forgets' comments when saving so it's really a catch 22
[14:03] <bac> no, it is a toss up.  it is definitely not a catch 22.  :)
[14:03] <hatch> lol right
[14:04] <hatch> maybe if reitveld wasn't so ugly I'd like it more
[14:04] <hatch> gota get some designers up in that house
[14:05]  * rick_h_ changes location back to the house. afk
[14:08] <bac> see, when doing the review i made a comment about some user-facing text but when i did the QA i saw my comment was bogus.  deleted it.  approved the review. no noise from premature comment sent out.
[14:08] <bac> frankban: +1
[14:08] <hatch> lol
[14:08] <hatch> hey luca__
[14:09] <luca__> hi hatch 
[14:09] <frankban> bac: thanks
[14:09] <bac> frankban: amazing that it was so simple!
[14:12] <bac> rick_h_: you need to add a photo of your MAAS to that document
[14:16] <hatch> luca__: sent an email to ya regarding the commit summary
[14:16] <bac> rick_h_: i tried to ssh to the maas but cannot connect.  did you do an ssh-import-id for all of us?
[14:18] <luca__> hatch: I haven’t seen any email...
[14:18] <luca__> hatch: I just got an email
[14:19] <hatch> :)
[14:24] <luca__> hatch: I didn’t know this feature was coming!
[14:24] <hatch> yeah we like to keep you on your toes :P
[14:25] <luca__> hatch: haha
[14:25] <hatch> I'm going to land this as is but would be nice to tweak it a bit for the next release
[14:25] <luca__> hatch: maybe we should schedule a call so you can talk me through it, it seems pretty straight forward.
[14:25] <luca__> hatch: do we have to land it?
[14:26] <hatch> well if I don't the code could go stale 
[14:26] <luca__> ok
[14:26] <hatch> I'm pretty much free whenever
[14:26] <luca__> ok
[14:26] <hatch> with the exception of the standup in 45
[14:26] <hatch> er 30
[14:27] <kadams54> guihelp: am I correct in thinking that a revived model (from a LazyModelList) should fire change events automatically?
[14:27] <hatch> kadams54: yes
[14:27] <kadams54> hatch: *sigh*
[14:27] <hatch> lol why?
[14:27] <hatch> that sounds like a good thing
[14:27] <hatch> and pretty much the only reason to revive :P
[14:28] <kadams54> hatch: it would be a good thing… if that's what I actually saw happening.
[14:28] <kadams54> hatch: http://pastie.org/private/kndmzbqg3syfm9zgeh21pg
[14:28] <hatch> looking
[14:28] <kadams54> That's the change I made. But now my onChange handler function isn't being called at all.
[14:29] <hatch> and you're sure the revive is being called?
[14:29] <kadams54> Yeah, got a breakpoint on it
[14:29] <hatch> and what's the event handler?
[14:30] <hatch> just the registration part
[14:30] <kadams54> I'll double-check though. I'm also wondering if something is breaking in event propagation.
[14:30] <hatch> I'm guessing that there is something wrong with your event registration
[14:30] <frankban> bac: I can add your keys, what pait are you using? I see four in your lp page
[14:31] <frankban> pair even
[14:31] <kadams54> this.addEvent(db.machines.after('*:change', this._onMachineChange, this));
[14:31] <kadams54> hatch: ^
[14:31] <bac> frankban: just run 'ssh-import-id bac', if it hasn't been done
[14:31] <frankban> bac: cool
[14:31] <hatch> kadams54: yeah that won't work
[14:31] <bac> frankban: i should probably prune what i've got on LP
[14:32] <frankban> bac: done
[14:32] <bac> frankban: and i'm in.  thanks.
[14:32] <hatch> kadams54: lazy model list doesn't have a change event for attribute changes
[14:33] <hatch> kadams54: and unfortunately reviving doesn't add the lml as a bubble target
[14:34] <kadams54> The previous approach, of manually firing the change event, was buggy because the event object wasn't populated with the same info that a change would have in a ModelList.
[14:34] <hatch> ahh
[14:34] <hatch> well you can fire a custom event facade 
[14:34] <hatch> the second param of fire() 
[14:35] <hatch> nbd just another YUI bug that'll never get fixed now ;)
[14:36] <rick_h_> bac: woot welcome to maas :)
[14:36] <kadams54> hatch: yeah, I know I can fire a custom event facade, but that means trying to populate it with the same info that YUI does for changes in a ModelList… and I'd like to avoid that.
[14:36] <hatch> well you only have to populate it with the information that your handlers expect
[14:36] <hatch> which shouldn't be too much
[14:37] <bac> rick_h_: so you have some poor man's maas?  no orange box?
[14:37] <rick_h_> bac: yea, I've got a 'rick bought 3 nucs, a switch, and a internet plan with static ips' maas
[14:37] <bac> rick_h_: nuc-nuc-nuc
[14:37] <rick_h_> bac: so it took months to come up vs an orange box taking 10min
[14:37] <kadams54> hatch: the whole point of an event architecture is to decouple so that the code firing the event doesn't have to know about the code subscribed to the event.
[14:38] <kadams54> hatch: I mean, if that's what I have to do, I'll do it. I'm just hoping there's a better way.
[14:38] <bac> you should name them larry, moe, and curly
[14:38] <rick_h_> bac: hah!
[14:38] <hatch> not without patching lazymodellist
[14:38] <rick_h_> bac: .95 manual focus lens just arrived wheeee!
[14:39] <hatch> rick_h_: can't you just turn off auto focus to get a manual focus? ;)
[14:39] <bac> rick_h_: which one?
[14:40] <rick_h_> bac: voightlander 17.5mm for m4/3
[14:40] <bac> that'll be a real challenge to focus i would think
[14:40] <rick_h_> bac: so m4/3 focus peaking ftw
[14:40] <rick_h_> it'll take some practice for sure
[14:40] <rick_h_> but focus peaking should hopefully help
[14:41] <rick_h_> the hard part is I'm used to setting aperture priority and hitting go
[14:41] <bac> being that wide, you've got some leeway
[14:41] <rick_h_> so now it's more set aperture on the lens, focus with peaking, adjust shutter speed to get desired exposure manually
[14:41] <rick_h_> but .95 is wiiiide open
[14:42] <bac> wait, can't you leave it in AP and let the camera set shutter speed?
[14:42] <rick_h_> it doesn't know the aperture since it's done on lens
[14:42] <rick_h_> it has no contacts to talk to the camera
[14:42] <rick_h_> the camera thinks there's no lense there
[14:42] <bac> rick_h_: no, but it has a meter.
[14:42] <bac> rick_h_: no different from my rangefinder
[14:43]  * rick_h_ will have to check it out and try
[14:43] <bac> a step in the right luddite direction for sure
[14:43] <rick_h_> bac: ah cool. So the aperture shows 0.0, but it does adjust SS for me when I hit go
[14:44] <bac> rick_h_: but your exif data will be hosed!
[14:44] <rick_h_> yes, no exif data :/
[14:45] <bac> mine guesses based on having two out of three data points
[14:45] <rick_h_> gotcha
[14:45] <bac> it writes to a different exif field showing that it is not sure
[14:48] <hatch> I just use my cell phone
[14:48] <frankban> rick_h_: are you available for a quick second review of https://codereview.appspot.com/151200043 ?
[14:48] <hatch> < --- professional
[14:49] <rick_h_> frankban: already looking
[14:49] <frankban> thanks
[14:52] <rick_h_> frankban: done, thanks for the changes. The goal will be to work on the release and completing the FFE bugs in the package for utopic after this please.
[14:53] <rick_h_> bac: now that's shallow https://www.flickr.com/photos/7508761@N03/15411328085/ :)
[14:54] <bac> rick_h_: 404
[14:54] <rick_h_> doh, perms
[14:54] <rick_h_> reload
[14:55] <frankban> rick_h_: cool thanks, I'll work on a 1.4.4 release after landing this
[14:55] <rick_h_> frankban: awesome. 
[14:55] <hatch> rick_h_: that's some seriously shallow dof
[14:56] <hatch> what;s that, 1"?
[14:56] <rick_h_> hatch: 5 or 6
[14:57] <Makyo> Oooh.  Jealous.
[14:58] <rick_h_> jujugui call in 4
[14:58] <rick_h_> kanban it up please
[15:12] <bac> so is my mic not working?
[15:18] <rick_h_> bac: yea, mic fail
[15:18] <rick_h_> camera fail
[15:18] <bac> rogpeppe: under "Mailing List" do you have an Unsubscribe button?
[15:18] <rogpeppe> bac: yup
[15:18] <rick_h_> rogpeppe: filter or spam catch it?
[15:18] <bac> rogpeppe: nm, https://launchpad.net/~juju-gui-peeps/+mailing-list-subscribers
[15:18] <rogpeppe> rick_h_: i'm looking in Spam
[15:18] <bac> you are on it.
[15:19] <rick_h_> "gui maas now available...pretty much" is the exact title
[15:19] <rogpeppe> rick_h_: i don't think so. when did you send the mail?
[15:19] <bac> rick_h_: does everyone really have access?  frankban had to manually add me
[15:19] <rick_h_> bac: no, I need to go through and import ssh keys
[15:19] <rick_h_> bac: but you me and frankban can now add that in
[15:19] <rogpeppe> rick_h_: i'm guessing it might just be delayed
[15:19] <bac> rick_h_: okey doke
[15:20] <rick_h_> bac: I'll try to run through everyone's LP ids at lunch
[15:21] <rick_h_> rogpeppe: shared the doc with you and included the email contents in the share notice
[15:21] <rogpeppe> rick_h_: thanks
[15:21] <rogpeppe> rick_h_: when did you send the email? was it today?
[15:23] <rogpeppe> rick_h_: i've got that. i wonder what happened to the mailing list message.
[15:23]  * rogpeppe is concerned that he may have missed lots more
[15:26] <hatch> Makyo: did you forget to mark this one as committed? https://bugs.launchpad.net/juju-gui/+bug/1365260
[15:29] <rick_h_> rogpeppe: whoa, you're not on yellow in LP strange
[15:30] <rogpeppe> rick_h_: hmm. i am in ~juju-gui-peeps though.
[15:30] <rick_h_> rogpeppe: added you, should hopefully be all set, not sure on the peeps list but at least on the team wise
[15:30] <rick_h_> rogpeppe: yea
[15:30] <rogpeppe> rick_h_: no archives, i'm guessing
[15:30] <rick_h_> rogpeppe: no, nothing much that you'd be interested yet I don't think
[15:31] <rogpeppe> rick_h_: cool
[15:31] <rick_h_> rogpeppe: it's been very gui/machine view focused so far though it's starting to warm up with storefront stuff
[15:31] <rick_h_> it's handy as the UX team is also on that list, and a few core folks like ramm, kapil, etc
[15:32] <rick_h_> I'll try to remember to check next time I see something go across
[15:32] <rick_h_> jujugui ok added ssh keys for the LP users  fabricematrat evarlast jcsackett hatch kadams54 makyo uros-jovanovic martin-hilton rogpeppe to the maas server
[15:33] <rick_h_> jujugui so if you're not on the list or can't get in let me know
[15:33] <rick_h_> bac: thanks for the prod
[15:33] <kadams54> rick_h_: sweet… will check it out in a bit.
[15:37] <hatch> rick_h_: so what "can't" we deploy here? Does MAAS create vm's ? So it'll look to us like a bunch of machines? Or does it still only look like 2 machines?
[15:37] <rick_h_> hatch: it's two machines and you can lxc at will
[15:37] <rick_h_> so can install most anything you want but bundles of 5 machines can't work
[15:37] <hatch> ahh so is that where openstack comes in? to create vm's?
[15:39] <rick_h_> hatch: yes, thought without juju can you bring up a node with bare ubuntu image
[15:39] <hatch> so MAAS is really the hardware layer then openstack is the vm layer then juju is the orchestration layer
[15:39] <hatch> we got this stack!
[15:48] <Makyo> hatch, sorry, bio break.  I'll mark it as committed.
[15:48] <Makyo> Actually, should be released
[15:49] <hatch> ahh yes
[16:15] <jcsackett> jujugui: i need two reviews and a pretty serious (requires real env) QA of https://github.com/juju/juju-gui/pull/600
[16:16] <hatch> jcsackett: I can get on it once I'm finished mine but I'm running into some testing oddities that are being less than awesome
[16:16] <hatch> want to get this finished first
[16:18] <rick_h_> jujugui ok break time for lunch afk
[16:40] <kadams54> Also lunching.
[16:44] <hatch> rick_h_: luca brings up a good point in his email re the conflict blocking - should I bench this branch until we can come to an agreement on a real plan?
[16:53] <rick_h_> hatch: well, I think we should leave the notification for now. 
[16:53] <rick_h_> hatch: at least it's visible and non-blocking
[16:53] <rick_h_> hatch: and it's more info that we have today (no hidden config issues) 
[16:53] <rick_h_> hatch: and we can work out the blocking path
[16:56] <hatch> rick_h_: ok so remove the blocking of the commit?
[16:56] <rick_h_> hatch: that's my idea atm, how does that sound?
[16:58] <hatch> works for me
[16:58] <hatch> I'll respond to the email with luca
[16:58] <rick_h_> hatch: k
[17:05] <hatch> jcsackett: lol nice typod bug
[17:05] <hatch> containser all the things!!!
[17:07] <hatch> our minimum wage just went up to $10.20/hr 
[17:07] <hatch> and there goes the cost of living by the same increase 
[17:07] <hatch> lol
[17:15] <hatch> jujugui does anyone know why the inspector breaks when the gui loses connection to its server? Anyone looked into this in their spare time? 
[17:45] <hatch> jujugui I need reviews and qa https://github.com/juju/juju-gui/pull/599
[17:45] <hatch> jcsackett: still need reviews and all that?
[17:51] <jcsackett> hatch: i do. looking to trade?
[17:52] <hatch> shitty trade but ok
[17:52] <hatch> :P 
[17:52] <rick_h_> bwuahahahha
[17:53] <rick_h_> jujugui I've put the two big bugs into the urgent lane for next steps. They're big enough I'd like to do another release once we get those in. 
[17:55] <hatch> cool
[17:57] <hatch> rick_h_: well there goes Ember from the list https://twitter.com/jdalton/status/517370990532497409
[17:57] <hatch> :)
[17:59] <rick_h_> hello
[17:59] <rick_h_> bah
[17:59]  * rick_h_ test
[17:59]  * rick_h_ never thought ember was on the list
[17:59] <rick_h_> hmm, why did that not go out 3 times in a row :/
[17:59] <hatch> everything is on the list :) I'm being open minded!!!
[18:10] <kadams54> hatch: is there any way to set e.target when firing an event? I tried: list.fire('change', {foo: 'bar', target: model}) and the target that came through on the other side was still list (and not model).
[18:15] <kadams54> hatch: Right now I'm considering, as a hack, something like this: http://pastie.org/private/cp1wjtfuigw4bsdxfhhynw
[18:15] <kadams54> (with comments, of course)
[18:32] <jcsackett> rick_h_: just letting you know i was able to successfully get onto the maas stuff.
[18:33] <hatch> kadams54: looking
[18:34] <hatch> kadams54: so it won't let you set the target?
[18:34] <kadams54> hatch: doesn't seem to.
[18:35] <hatch> kadams54: http://yuilibrary.com/yui/docs/api/classes/EventTarget.html#method_fire
[18:35] <hatch> yeah looks like it will
[18:35] <hatch> see the arguments definition
[18:36] <kadams54> Yeah, I know, which is why I though my first approach would work. But that's not the story told in the debugger.
[18:37] <hatch> well no, the change event has a facade set
[18:37] <hatch> so it'll overwrite what you're trying to pass
[18:38] <hatch> kadams54: I think your approach in that pastie is acceptable with comments as per why it's there and where it's coming from
[18:44] <hatch> kadams54: there are other psudo appropriate ways to do it - setting a custom facade for the event...but no, that's even harder to reason about :)
[18:44] <hatch> just fyi :)
[18:47] <hatch> jcsackett: your branch qa's well on sandbox - I'm going to take lunch then will qa the real env
[19:10] <bic2k> which is the preferred place to file bugs/feature requests: launchpad or github?
[19:14] <rick_h_> bic2k: launchpad
[19:14] <rick_h_> I think issues is disabled in github
[19:17] <rick_h_> jujugui running away for the day. jcsackett if you don't get a second review I'll try to look at it tonight after 
[19:17] <urulama> rick_h_: have fun
[19:18] <rick_h_> urulama: get out of here :P I can't EOD before you TZ law
[19:18] <urulama> :D
[19:18]  * urulama goes *puf*
[20:37] <hatch> jcsackett: +1
[20:37] <jcsackett> hatch: whoo! thanks.
[20:37] <jcsackett> so glad to be closing in on landing that mofo.
[20:38] <jcsackett> that db.reset call and 'var db =' thing in the tests were total PITAs to track down.
[20:38] <hatch> yeah I bet
[20:42] <hatch> jcsackett: I can't reproduce #1376353 nor does the var in question exist
[20:42] <hatch> are you sure you didn't have some local branch with a typo?
[20:43] <jcsackett> hatch: you mean the one about not switching back to services that i filed?
[20:43] <hatch> yeah
[20:43] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1376353
[20:43] <hatch> lazyPower: ping
[20:43] <lazyPower> pong
[20:44] <hatch> I'm looking at your bug here https://bugs.launchpad.net/juju-gui/+bug/1375251
[20:44] <hatch> what do you mean by 'environment clone' ?
[20:44] <lazyPower> i copied the same entry in environments.yaml (its a manual clone provider, read: DO)
[20:44] <lazyPower> and deployed a "fresh environment" - with fresh vms and saw the same behavior
[20:45] <hatch> oh ok so you upgraded from 7 to 8 in the new env and it was the same issue?
[20:46] <hatch> and you say switching to machine view at any time clears the xy coords? This is very odd - I've never seen that before
[20:46] <hatch> I wonder if this is a DO specific issue
[20:46] <jcsackett> hatch: what do you mean the var in question doesn't exist?
[20:46] <jrwren> jcsackett: was it you that fixed the mysterious jenkins crashing spawned process bug?
[20:47] <hatch> jcsackett: this._containserHeader is undefined
[20:47] <jcsackett> jrwren: i think so? you mean the fact that the dev server wouldn't stay up?
[20:47] <jcsackett> hatch: right, that it's undefined is the problem.
[20:48] <jrwren> jcsackett: yes. Was there anything other than BUILD_ID=dontkillme environment variable?
[20:48] <jcsackett> jrwren: nope, that's all it took.
[20:48] <lazyPower> hatch: actually on the new env it was a straight deployment of 8
[20:48] <jrwren> jcsackett: thanks.
[20:48] <jcsackett> jrwren: yw.
[20:49] <lazyPower> hatch: and yes, switching to machine view at any time clears x/y coords. :(
[20:49] <lazyPower> hatch: i can run a sample deployment and hand over creds if you want to inspect
[20:49] <hatch> jcsackett: right but do you see the var name? It doesn't exist in the app
[20:49] <hatch> lazyPower: ok this must be a DO only issue because I know of a few others using the mv on ec2 without issue in a prod env
[20:49] <hatch> did you use the DO plugin?
[20:50] <hatch> or just manually assign the machines?
[20:50] <lazyPower> i use the DO plugin
[20:50] <jcsackett> hatch: i don't know what you mean. the line exists in the code, and is coming up undefined. 
[20:50] <jcsackett> hatch: i do indeed see this._containersHeader
[20:51] <hatch> jcsackett: oh so the bug has a typo?
[20:51] <hatch> lazyPower: ok I'll install the plugin and such and give it a try
[20:52] <hatch> although I'm guessing the issue is DO specific 
[20:52] <jcsackett> hatch: yup, bug has a typo, i've updated.
[20:52] <hatch> ok so just tried on develop and alls well
[20:52] <hatch> in fact I qa'd your branch with it and no issues
[20:58] <jcsackett> hatch: there is indeed no containers header in my personal env.
[20:58] <hatch> so possible that yours is broken?
[20:58] <jcsackett> hatch: how?
[20:59] <hatch> well I just had a fresh env on ec2 running on develop and it worked as expected
[20:59] <hatch> I can try again 
[20:59] <jcsackett> hatch: where do we do the whole "provider has these sorts of containers" thing?
[20:59] <jcsackett> hatch: it may also be a charm upgrade issue.
[21:00] <hatch>  environments.providerFeatures = {
[21:00] <hatch> go.js 2185
[21:01] <rick_h_> jcsackett: to force headers/etc add :flags:/containers
[21:01] <rick_h_> jcsackett: it overrides the normal provider settings
[21:02] <jcsackett> rick_h_, hatch: right, my env is manual, we have nothing for that.
[21:02] <jcsackett> which i think means anyone trying to use our stuff with the digital ocean plugin is going to have issues too, since iirc that's just a wrapper around manual.
[21:02] <rick_h_> jcsackett: ok, seems like manual provider is something we might have to check out. Sounds like both your bug and lazyPower's here is causing us issues?
[21:03] <hatch> yeah this sounds like a manual provider issue
[21:03] <hatch> I'm in the process of setting up the DO plugin to give this all a try
[21:03] <rick_h_> ok, so in our list of providers/featuers we offer is manual in that list?
[21:03] <jcsackett> rick_h_: no.
[21:03] <rick_h_> I bet that's the issue. We've got the list of features per provider and we're missing one now
[21:03] <hatch> negative
[21:03] <jcsackett> i suspect adding it to that with no allowed containers we'll work.
[21:03] <jcsackett> s/we'll/will
[21:03] <hatch> oh waitasecond
[21:03] <jcsackett> we should probably have a sane fallback.
[21:04] <rick_h_> jcsackett: rgr
[21:04] <jcsackett> hatch: ??
[21:04] <hatch> these are all named off the env name?
[21:04] <rick_h_> hatch: off the provider juju tells us we're using
[21:04] <hatch> ohh ok *phew*
[21:04] <rick_h_> hatch: but we didn't include 'manual' I bet and that's blowing up
[21:05] <hatch> yeah - and what does manual support? nothing?
[21:05] <rick_h_> :/ no idea
[21:05] <rick_h_> I'd say to fix the bug we start with nothing
[21:05] <hatch> haha sounds good
[21:05] <rick_h_> and land that for the updated release EOW
[21:05] <hatch> hazmat: any idea if manual provider supports containers?
[21:05] <rick_h_> and then we can explore making it nicer going forward.
[21:05] <jcsackett> rick_h_: manual supports nothing, b/c it'll have the same no bridging issue as ec2.
[21:05] <hatch> ahh ok
[21:05] <hatch> that makes sense
[21:05] <rick_h_> hatch: jcsackett right, with manual it could be any platform, we can't tell if lxc or kvm will work/etc
[21:06] <rick_h_> it could just be my old laptops in a row in a closet
[21:06] <lazyPower> hatch: manual supports --to lxc:#
[21:06] <hatch> hmmm
[21:06] <jcsackett> lazyPower, hatch: technically, so does ec2.
[21:06] <hatch> heh true
[21:06] <jcsackett> we say "nope" to containers b/c while you can deploy, you can't then properly use those services without going into the server and mucking with the lxc bridge.
[21:07] <rick_h_> lazyPower: if you deploy wordpess in an lxc on ec2 and expose it...no worky
[21:07] <lazyPower> well none of the networking works in terms of --to containers
[21:07] <rick_h_> lazyPower: so we've cut back that in the GUI to help prevent a lot of bug reports around that until juju supports routing those network connections
[21:07] <lazyPower> but you can still do it. you're just expected to handle the routing yourself.
[21:07] <rick_h_> lazyPower: it does in maas :) and juju will support ec2 around end of cycle
[21:07] <lazyPower> ooo
[21:07] <lazyPower> fantastic
[21:08] <rick_h_> lazyPower: rgr, so we have :flags:/containers to enable it anyway
[21:08] <jcsackett> rick_h_: confirmed, :flags:/containers makes everything work. i'm updating the bug in case someone else encounters this before EoW.
[21:08] <rick_h_> jcsackett: rgr
[21:08] <rick_h_> jcsackett: ty much
[21:09] <jcsackett> rick_h_: hey, happy to help with my own bug. :p
[21:09] <jcsackett> i love being an actual user of the thing i work on.
[21:10] <hatch> :D
[21:11] <hatch> lazyPower: what are you saying in your video? "ssh (tack) keygen" ?
[21:11] <hatch> your DO video
[21:12] <lazyPower> yep
[21:13] <lazyPower> tack = -
[21:13] <hatch> isn't that a dash? 
[21:13] <lazyPower> its a 'tack' when i say it
[21:13] <hatch> lol ok
[21:13] <lazyPower> but i can see why you'd think its a dash
[21:13] <hatch> - = en dash — = em dash
[21:13] <hatch> could that be why? :P
[21:14] <lazyPower> you've forgotten a very distinct dialect
[21:14] <lazyPower> - = sysadmin 'tack'
[21:14] <hatch> ohh - tbh I've never heard it called a tack before
[21:15] <lazyPower> hack at -
[21:15] <lazyPower> see what i did there?
[21:15] <hatch> haha
[21:16] <hazmat> hatch, definitely does
[21:16] <hazmat> re containers
[21:16] <hazmat> hatch, and with the rudder/flannel charm they can talk across hosts
[21:16] <hazmat> though that makes things work across hosts in any provider
[21:18] <lazyPower> wait
[21:18] <hatch> hazmat: right but juju doesn't support the routing so If I created two lxc containers using manual provider and installed wordpress in one and mysql in the other - I couldn't relate them
[21:18] <lazyPower> we have phaux networking charms that solve this?
[21:18] <hazmat> hatch, on the same host it would just work
[21:18] <lazyPower> hazmat: why are we not talking about this more prominently?
[21:18] <hatch> rick_h_: ^
[21:18] <hazmat> hatch, across hosts you need one of my container sdn charms
[21:19] <hazmat> hatch, currently its published as rudder
[21:19] <hazmat> but upstreamed changed names 
[21:19] <hatch> ohh so if I had two machines the units couldn't communicate
[21:19] <hazmat> hatch, let me dig you up the readme
[21:19] <hatch> I think I'll still set it as disabled in the GUI for now :)
[21:19] <hazmat> no
[21:19] <hazmat> hatch, so this charm does the magic sdn across hosts http://bazaar.launchpad.net/~hazmat/charms/trusty/rudder/trunk/view/head:/readme.txt
[21:20] <lazyPower> and suddenly hazmat just gave birth to the most amazing thing I've heard all day
[21:20] <hazmat> hatch, it should be a configuration option on gui
[21:20] <hatch> right but joe user won't know that relations won't "just work" which = GUI bugs which aren't our fault
[21:20] <hazmat> lazyPower, your right it deserves talking about it
[21:20] <hazmat> hatch, make it an option
[21:20] <hatch> you can enable container support using the 'container' flag in the gui
[21:21] <hazmat> lazyPower, i'm hoping to bring it up at brussels as we should do this or weave as our default sdn, 
[21:21] <hazmat> as opposed to the broken by default on providers, let's do a works on all providers by default
[21:21] <lazyPower> I'll give ita go - when you sent the rudder email to the list, it was only 10k feet over my head
[21:21] <lazyPower> now that you've just put it out there in plain english, i want to blog about this as well
[21:22] <hazmat> ie. we do the opposite for security groups/firewalls.. we should have universal iptables and then provider specific customization around implementation
[21:22] <hazmat> as an optimization
[21:22] <lazyPower> man, we've had this for what, over a month now?
[21:22]  * hazmat hides
[21:22] <hazmat> gotta run EOD family time
[21:22] <lazyPower> o/ tc hazmat
[21:22] <hatch> cya thanks hazmat
[21:56] <rick_h_> Makyo: hatch do you guys think we could crank out https://bugs.launchpad.net/juju-gui/+bug/1376464 in one day during sprints?
[21:57] <hatch> oo fancy
[21:57] <hatch> where would it go? :)
[21:57] <rick_h_> no, simple, in the drop down menu in the upper right
[21:57] <rick_h_> under help and feedback
[21:58] <rick_h_> or maybe even on the keyboard shortcut menu would be good
[21:58] <hatch> so that might cause some issues because the flags ususally need to be set pre-init
[21:58] <rick_h_> hatch: yea, maybe we even go so far as to do a page reload on save
[21:58] <hatch> so maybe the dropdown could modify the config file
[21:58] <hatch> then reload
[21:58] <hatch> yeah
[21:58] <rick_h_> hatch: meh, I'm thinking straight localstorage
[21:58] <hatch> ahh that would also work nicely
[21:58] <rick_h_> and then on load read the key or don't at all the config points
[21:59] <hatch> yeha that would be a cool project
[21:59] <Makyo> Yeah
[21:59] <Makyo> That sounds good.
[21:59] <rick_h_> hatch: Makyo ok, goal is to do that monday and show it in a lightning talk. 
[21:59] <rick_h_> hatch: Makyo feel free to hack during flights :P
[22:00] <Makyo> Hahah
[22:00] <Makyo> Sounds good.
[22:00] <rick_h_> I like the idea of putting the checkboxes/etc in the keyboard help
[22:00] <rick_h_> because people don't know that's there either and it's out of the way regardless of what happens to the header later in life
[22:01] <hatch> yeah the flag code would need a minor addition to check localstorage
[22:01] <rick_h_> hatch: right
[22:01] <hatch> but should be straight forward
[22:01] <Makyo> Yeah, exactly.
[22:01] <rick_h_> ok, noted to the bug
[22:01] <rick_h_> thanks guys
[22:04] <hatch> rick_h_: maybe in the dropdown a link to open the 'developer tools' for the gui
[22:04] <hatch> would give us a place to put random dev type things
[22:04] <rick_h_> hatch: yea, I'm worried about that moving around 
[22:04] <rick_h_> hatch: longer term
[22:04] <rick_h_> hatch: but yea, we can find a home
[22:38] <bic2k> this one is a feature request: https://bugs.launchpad.net/juju-gui/+bug/1376487
[22:40] <hatch> oh nice one :)
[22:40] <hatch> bic2k: question - would you want that zoom level saved only on your machine? Or cross the environment?
[22:40] <hatch> cross env might make for some....interesting...results for differing screen sizes :)
[22:41] <bic2k> thats why I suggest localStore for it
[22:42] <bic2k> chances are if you are accessing juju-gui from different machines they will have different browser sizes. That being said, you could store the top x,y offset for all viewers and the zoom locally for maximum effect
[22:42] <bic2k> but really, per device probably makes the most sense
[22:42] <bic2k> its easiest to do, dumb in the right ways
[22:44] <hatch> best kind of enhancements :P
[22:57] <rick_h_> hatch: is your blog post up?
[22:57] <bic2k> blog post for?
[22:57] <rick_h_> hatch: or is tumblr hating still?
[22:58] <bic2k> ACK, never mind me
[22:58] <rick_h_> bic2k: machine view post he had prepped but never made it public
[23:01] <bic2k> rick_h_ thanks ;-) I thought I was in a different window when I read that
[23:01] <rick_h_> :)
[23:01] <hatch>  rick_h_ still having issues I'll get it up tonight no matter what
[23:01] <rick_h_> hatch: gotcha
[23:01] <rick_h_> huwshimi: morning
[23:01] <huwshimi> Morning
[23:01]  * rick_h_ heads off to coffee shop, biab