[13:01] <frankban> hi benji: could you please review https://codereview.appspot.com/7299057 ? quick one
[13:01] <benji> frankban: sure
[13:01] <frankban> benji: thanks
[13:01]  * frankban lunches
[13:04] <benji> frankban: looks good
[13:10] <gary_poster> benji, once you get 1110823 landed please get me the jenkins username I emailed everyone about yesterday
[13:11] <gary_poster> bcsaller same for you
[13:11] <gary_poster> and hi btw :-D
[13:11] <benji> gary_poster: sure
[13:11] <gary_poster> thanks
[13:17] <benji> yow, I decrypeded the GPG message and I got a MIME document with a base64 encoded tgz; this is like some sort of geek obsticle course :)
[13:17] <gary_poster> heh
[13:17] <gary_poster> thunderbird handled that part transparently fwiw
[13:18] <gary_poster> thunderbird + enigmail that is
[13:23] <benji> "VERIFY ERROR: depth=1, error=self signed certificate in certificate chain"
[13:27] <bac> funny mine wasn't double tarred like gary's
[13:27] <gary_poster> good
[13:30] <gary_poster> So far I've waited 15 minutes for juju status to return after a canonistack bootstrap :-/
[13:34] <benji> gary_poster: user name: "benji"
[13:35] <gary_poster> thank you benji
[13:35] <benji> heh, I like the weather metaphore
[13:35] <benji> np
[13:41] <gary_poster> hey hazmat, I'm trying to get canonistack working with juju, both for general good practice and to be able to dupe what the CI is going to do.  I followed the wiki instructions for juju+canonistack AFAIK, and I can bootstrap, but juju status still doesn't return , 25+ minutes ago.  output from juju --verbose status isas follows: http://pastebin.ubuntu.com/1616631/ .  Does that suggest any problem/remediation to you?
[13:42] <gary_poster> that ssh to 10.55.60.231 seems to not be working out so well...
[13:42] <hazmat> gary_poster, can you log into the machine with ssh
[13:42] <hazmat> gary_poster, which region and which provider?
[13:42] <hazmat> one of the regions requires 'openstack' and one 'openstack_s3' 
[13:43] <hazmat> gary_poster, i think 02 is swift, and 01 is s3
[13:44] <gary_poster> hazmat, openstack provider, per https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack/QuickStart .  Using default region, which I think is 01
[13:44] <hazmat> hmmm.. maybe that's a red herring
[13:47] <gary_poster> ssh timed out
[13:48] <gary_poster> ah-ha, matsubara improved my .ssh/config.  looks like it might work now...
[13:50] <gary_poster> yes, all's good.  Will include follow-up in email
[13:59] <hazmat> gary_poster, cool
[13:59] <hazmat> i just updated the quick start doc to remove some extraneous config bits
[14:07] <gary_poster> hazmat, should I add the snippet I gave in the email for step 4 to that quick start?  Maybe recent ssh instructions elsewhere include that, but iwbni the quick start were self-sufficient, I think
[14:07] <gary_poster> Specifically, I also needed this:
[14:07] <gary_poster> Host 10.55.58.* 10.55.60.* 10.55.62.* 10.55.63.* *.canonistack *.canonistack2
[14:07] <gary_poster>     ProxyCommand ssh chinstrap.canonical.com nc -q0 %h %p
[14:08] <gary_poster> I only had that for 10.55.60.* before
[14:09] <hazmat> gary_poster, sounds good to me
[14:09] <gary_poster> k will do hazmat
[14:47] <bcsaller> gary_poster: do you have some time for a call soon?
[14:47] <gary_poster> sure bcsaller.  9:55 or 10:00 ok?
[14:47] <bcsaller> gary_poster: yeah, ping me when ready
[14:47] <gary_poster> will do
[14:59] <gary_poster> bcsaller, jujugui is open
[15:29] <gary_poster> bac benji frankban goodspud hazmat Makyo teknico call in 1
[15:29] <gary_poster> hatch hi :-)\
[15:30] <hatch> Ahoy!
[16:02] <benji> guihelp: has anyone seen this error when running "make test-prod"? Error: extend failed, verify dependencies (http://localhost:8084/juju-ui/assets/all-yui.js:1
[16:03] <benji> the tests pass when run in the browser
[16:10] <Makyo> teknico, Anything I can do to help?
[16:11] <teknico> Makyo, yes, thanks, call?
[16:12] <Makyo> teknico, Sure.  The old juju-ui hangout is free.
[16:13] <Makyo> https://plus.google.com/hangouts/_/409819056ea1551523432ac63f4df4a6feaa5922?hl=en-US
[16:47] <benji> darn, my test failures are due to some change made during review; traking it down now
[18:32] <dweaver> Question: How do you use juju-gui with local charms repository.  I can see in assets/config.js: charm_store_url: 'https://jujucharms.com/', Can this be set to a local file location like the juju option --repository or is there another way to support local charm repos?
[18:33] <dweaver> Any help will be appreciated :)
[18:38] <Makyo> guihelp, ^^^
[18:38] <Makyo> dweaver, I don't believe there's current support for a local repository, but I've not tried the method you've suggested.
[18:38] <hazmat> dweaver, at the moment its not supported
[18:38] <hazmat> dweaver, the gui will work with local charms once their deployed
[18:38] <bcsaller> (via the cli)
[18:39] <hazmat> but we don't have a local program that you can run that will give the endpoint interface that the gui needs at the moment
[18:39] <hazmat> its an interesting discussion point.. at the moment if the gui is deployed over ssl most browsers will ignore sub resources..
[18:39] <hazmat> that aren't ssl.. the exception seems to be websockets..
[18:40] <hazmat> but its unclear if thats just a transient quirk.. if its not we can do local charms over websocket.. else.. i'm not sure what options there are
[18:41] <hazmat> since/because the local program can't present a valid cert for itself running on localhost..
[18:42] <dweaver> OK, thanks, that answers my query, it is a query coming from HP, so it is likely to be a future requirement, so probably worth thinking about how we're going to achieve it.
[18:42] <dweaver> eventually, anyway :)
[18:43] <dweaver> hazmat++
[18:43] <dweaver> thanks
[18:43] <hazmat> np... so nutshell local charm search no.. manipulation/introspection of services deployed with local charms are fully supported
[18:46] <gary_poster> hazmat, for one story, charm might be hook point for something we could do.  You tell the charm about your local server, and it proxies it for you.  We could have it served from /local/* .  Similar proxying could be done in other stories.
[18:46] <hazmat> gary_poster, local host differs between the proxy and the client..
[18:47] <hazmat> and nat/firewall prevent remote_ip usage
[18:47] <gary_poster> hazmat, yes, for this to work, charm would have to be able reach your machine
[18:47] <gary_poster> so limited value, but perhaps some
[18:48] <hazmat> too many cases where it won't work to be a solution.
[18:48] <gary_poster> fair enough
[18:48] <hazmat> i think just pushing forward with the websocket gives us a possible universal answer.
[18:48] <hazmat> but it would be good to verify/research why this browser behavior exists.
[18:48] <hazmat> ie oversight or reasoned
[18:51] <hazmat> sounds like recent firefox may not allow it.. from some quick googling..
[18:51] <hazmat> gary_poster, alternatively we have the user separately accept the websocket cert from localhost
[18:51] <hazmat> in their browser as a crappy but nesc requirement
[18:51] <gary_poster> yeah
[18:51] <hazmat> and documented
[18:52] <hazmat> and then we can avoid the websocket and just make it  a  parallel impl 
[18:52] <hazmat> of the existing search rest backend
[18:53] <gary_poster> hazmat, ack, may be best we can do.  Although, for big companies as mentioned above, it may not even be a big deal to put it behind a real cert.
[18:54] <gary_poster> sounds a bit like other plans too though
[18:54] <hazmat> bcsaller, would you be up for sanity checking a mind twisted txzk branch ?
[18:55] <hazmat> dweaver, gary_poster, for them (big) i have other plans.
[18:55] <bcsaller> hazmat: sure
[18:55] <gary_poster> hazmat, understood
[18:56] <dweaver> hazmat, sounds exciting!
[19:02] <hazmat> hatch, welcome on board!
[19:02] <hatch> thanks :)
[19:02] <hatch> Hi everyone
[19:03] <hatch> My name is Jeff and I hate long walks on the beach
[19:04] <hatch> :D
[19:07] <hazmat> :-)
[19:14] <gary_poster> jujugui, ^^^ :-)
[19:14] <Makyo> hatch, o/
[19:16] <bac> hi hatch
[19:20] <bcsaller> hazmat: send me a link to what you want reviewed when you're ready
[19:25] <benji> hi hatch
[19:26] <hatch> Hey, looking forward to getting started
[19:28] <hazmat> bcsaller, its got some debug junk in it.. which i'm cleaning up.. but ignoring those the rest is ready https://codereview.appspot.com/7307051/
[19:29] <hazmat> hmm.. that diff is wierd..
[19:38] <hazmat> bcsaller, not sure why reitveld is getting the diff wrong
[19:38] <bcsaller> hazmat: too much?
[19:38] <hazmat> bcsaller, yeah.. way too much
[19:39] <bcsaller> hazmat: good, it was looking like quite the branch
[19:40] <hazmat> odd. even lp gets it wrong.. 
[19:40] <hazmat> trunk shows the managed.py but both are treating it as a new file
[19:40] <hazmat> in the diffs (reitveld and lp)
[19:42] <bcsaller> hazmat: if you don't get it working in the next few minutes I can try to generate it locally at the cost of some of the inline review comments
[19:43] <hazmat> bcsaller, i'm just going to go back and work on yanking the debug bits for now.. maybe just hold till tomorrow till i can get this clean
[19:44] <bcsaller> hazmat: thanks
[19:44] <hazmat> i was hoping to get it in for some of the drill work that people are doing.. but they seem to have other concerns atm
[19:58] <benji> gary_poster: do we want to put some kind of user or branch details in the sauce labs jobs?  Like say user name and branch nick?
[19:59] <gary_poster> benji sounds nice
[19:59] <benji> k, it'll be easy to do
[20:12] <bac> gary_poster: the approach i thought looked promising didn't actually work.  i'm talking with curtis now to see if he has any brilliant thoughts
[20:12] <gary_poster> good idea bac
[20:29] <benji> darn, grabbing the branch nick doesn't make any sense because the tests don't know that they are actually running against that branch
[20:36] <benji> gary_poster (and all other reviewers): https://codereview.appspot.com/7300054
[20:37] <gary_poster> on call
[20:58] <gary_poster> benji land with changes
[20:58] <benji> thanks
[20:59] <benji> "converting browser tests into runes" -- lol
[20:59] <gary_poster> :-)
[21:03] <gary_poster> bcsaller, am I right that there's no juju facility to somehow automatically associate elastic IPs, a la https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack#Obtaining_a_Public_IP_Address?  If not will simply suggest we script with the euca-* commands
[21:03] <gary_poster> (this is for automating CI using Juju, Jenkins, and Canonistack)
[21:09] <hazmat> gary_poster, can i grab you for some gui charm debugging?
[21:16] <bcsaller> gary_poster: I don't think the providers do anything special for elastic IPs. You get the public one provided but things like Amazon's elastic ips are provider specific and I don't think we had a general facility for that. I think associating an elastic IP changes the public address though  
[21:16] <gary_poster> hazmat, sure.
[21:16] <gary_poster> bcsaller, cool, thank you
[21:17] <hazmat> gary_poster, for openstack there is a facility for using an elastic ip
[21:17] <hazmat> use-floating-ips
[21:17] <hazmat> but it enables it everywhere
[21:17] <hazmat> and there are not that many
[21:17] <hazmat> on an account
[21:17] <gary_poster> hazmat enabled even for the bootstrap?
[21:18] <Makyo> I remember running into this when I was setting up canonistack.  Was keeping the websocket address from being set properly, correct?
[21:18] <hazmat> gary_poster, yes
[21:19] <gary_poster> hazmat, ok thanks.  I'm in jujugui if you want to meet there, or can move to juju-ui
[21:19] <hazmat> gary_poster, i'm trying to setup something remote with the drill team.. i'll ping again when its happening
[21:19] <gary_poster> Makyo, ah, I bet you are right, but I was simply trying to make it so that sauce labs can even see the charm at all
[21:20] <gary_poster> in an automated way
[21:20] <Makyo> gary_poster, ah, yeah, definitely.  I found that even with a public IP, though, the 'public  address' as reported to juju was still the canonistack address.
[21:21] <gary_poster> hazmat ok
[21:21] <gary_poster> Makyo, :-( .  Did you use use-floating-ips or the euca approach?
[21:21] <Makyo> gary_poster, euca.
[21:21] <gary_poster> ok
[21:21] <Makyo> gary_poster, so maybe floating IPs might help there.
[21:22] <gary_poster> Maybe the other approach will work better.  Will try both.  Yeah, thanks for warning
[21:25] <hazmat> we could slim down charm deb installs considerably
[21:26] <hazmat> by considering what the active config options are
[21:26] <hazmat> ie. if stable don't most of the pkgs, if not staging don't need zk, etc
[21:28] <hazmat> we should also move the download off launchpad and onto a cdn
[21:28] <hazmat> its quite slow to download from lp