[00:05] <davecheney> niemeyer: did you get a new one ?
[00:05] <davecheney> with the new keyboard ?
[00:05] <niemeyer> No, still the old one.. but the keys fail every once in a while
[00:05] <davecheney> niemeyer: this may be of use, http://www.sadtrombone.com/
[00:06] <niemeyer> After spanking them hard enough, they seem to get back in shape
[00:06] <davecheney> +1, good advice
[00:07] <davecheney> thumper: i have a problem
[00:07] <davecheney> thumper: https://bugs.launchpad.net/juju-core/+bug/1298115
[00:07] <_mup_> Bug #1298115: utils/ssh: test failures <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1298115>
[00:07] <davecheney> uses a map to collect up the options when forming the command
[00:07] <davecheney> so the results are
[00:07] <davecheney> 1. always correct
[00:08] <davecheney> 2. random
[00:08] <davecheney> this is, IMO a bug in the test
[00:08] <davecheney> I can do
[00:08] <davecheney> 1. change to test to look for the specific arguments, rather than assert the string is exactly the same
[00:08] <davecheney> 2. change the code to not use a map and enforce ordering
[00:09] <davecheney> 2. is more work, and feels wrong as thre is no requirement for the order of arguments to be stable
[00:09] <davecheney> 1. will probable make the test a bit messier
[00:16] <wwitzel3> thumper: I am now (re 3 hours ago)
[00:21] <wwitzel3> thumper: you still want me to take a look at bug 1297899 , I will add it to my task list for first thing in the morning.
[00:21] <_mup_> Bug #1297899: Libvirt machines deployed with MAAS and Precise is only able to successfully boot once <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1297899>
[00:23] <thumper> wwitzel3: that would be really helpful
[00:23] <thumper> as I don't have vmaas set up
[00:23] <thumper> it could be any one of the moving parts
[00:24] <thumper> davecheney: I'd suggest check with axw when he starts shortly
[00:24] <thumper> davecheney: as he was the author of said test
[00:24] <bodie_> sent an email to juju-dev@ -- if anyone can spare some cpu shares it would be most welcome :)
[00:24] <wwitzel3> thumper: yep, np
[00:24] <bodie_> whenever convenient
[00:24] <davecheney> thumper: right
[00:24]  * davecheney goes to do something else
[00:25] <thumper> bodie_: yeah, just saw it
[00:25] <thumper> bodie_: we have a team meeting tonight, I'll whack it on the agenda there too :-)
[00:27] <bodie_> thanks! hope it's not too verbose, I did my best to chop out the fat
[00:27] <bodie_> I'm used to an environment where nothing longer than 5 bullet points gets read
[00:27] <bodie_> (where no bullet points have line wrap)
[00:28] <thumper> heh
[00:50] <davecheney> bodie_: what is an Action ?
[00:56] <davecheney> sinzui: how many cpu's does the landing bot have ?
[01:01] <bodie_> davecheney, an Action is a charm-defined um, action, such as snapshot for a MySQL service
[01:10] <axw> wallyworld: re SupportedArchitectures
[01:10] <axw> If you can never upload the tools for a different arch, then FindInstanceTools will never be able to find them, right?
[01:10] <wallyworld> axw: sec, otp
[01:10] <axw> add-machine ssh:... still relies on FindInstanceTools
[01:10] <axw> ok
[02:02]  * thumper is back again
[02:09] <bodie_> I'm not sure, I was thinking of it as an API endpoint to run the Command on the client
[02:11] <bodie_> I don't understand how hooks are put together yet, I was focused on breaking down the command line syntax just to hopefully add a command we could test out
[02:33] <axw> wallyworld: raised #1298159, let me know if you've got too much on and I can take it
[02:33] <_mup_> Bug #1298159: manual: SupportedArchitecture restricts add-machine to same arch as bootstrap-host <manual-provider> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1298159>
[03:04] <axw> wallyworld: I'm just gonna do it, it's more important than the azure stuff
[03:04] <axw> (unless you're already doing it)
[03:04] <wallyworld> axw: ah sorry, i replied and didn't hit enter cause i'm on another call, that woud be great
[03:04] <wallyworld> sorry about that
[03:05] <axw> wallyworld: no worries
[03:26] <davecheney> axw: thanks for taking a look at the ssh failures
[03:26] <axw> davecheney: nps
[07:30] <dimitern> morning all
[08:00] <wallyworld> arosales: hiya, I sent an email about the joyent provider. we're having our weekly meeting in a few hours where we can discuss. let me know if you want input (or you could even tag along on the meeting if you needed to)
[08:01] <arosales> wallyworld: hello
[08:01] <wallyworld> hi
[08:02] <arosales> I would love to attend the meeting but probably won't be awake enough to attend.
[08:02] <arosales> I'll take a look at your mail.
[08:02] <wallyworld> ok. meeting starts in 2 hours
[08:02] <wallyworld> raise any concerns and i'l pass them on
[08:05] <arosales> wallyworld: you work on picking up the joyent provider work is very appreciated
[08:05] <arosales> odd you ran into a quota issue
[08:05] <wallyworld> np, sorry i haven't had a lot of time this week to start earlier, i've been swamped
[08:06] <arosales> good to hear bootstrap worked though
[08:06] <wallyworld> arosales: i didn't look closely - it may have been a rate limit exceeded issue
[08:06] <arosales> wallyworld: no worries, I appreciate you picking up this extra task with your already full workload
[08:06] <arosales> wallyworld: you using my account or curtis?
[08:06] <wallyworld> yours
[08:07] <arosales> ok, I'll see if there are any account settings, but I didn't see any  . . .
[08:07] <wallyworld> np. i've been called to dinner, bbiab
[08:08] <arosales> wallyworld: do you have 2 instances currently running in joyent?
[08:15] <arosales> wallyworld: I'll leave those two running (they do look like juju instances), but if you could destroy so they are not racking up $$$ before you leave that would be great.
[08:17] <dimitern> vladk, hey
[08:17] <vladk> dimitern: good morning
[08:17] <dimitern> vladk, morning
[08:18] <dimitern> vladk, how is that card ("Update ec2/openstack/etc provisioners to fail requests with StartInstanceParams.Network set.") going ?
[08:18] <dimitern> vladk, would you like to do some pairing on it?
[08:19] <vladk> dimitern: I didn't have much time for it
[08:19] <vladk> Mostly I worked on installing MAAS over VirtualBox
[08:19] <dimitern> vladk, did you manage ok?
[08:20] <vladk> I stuck with 'juju bootstrap' for maas, can't understand what ssh key I shoud configure on cluster controller
[08:20] <dimitern> vladk, I installed maas on precise with libvirt/kvm
[08:20] <wallyworld> arosales: i'll destroy
[08:20] <arosales> wallyworld: thanks I didn't want to disrupt any debugging
[08:20] <vladk> I am working on daemon, that converts Wake-On-Lan packets to virtualbox start command
[08:20] <dimitern> vladk, so inside the maas web ui there's a preferences page where you can generate an api key and import your ssh keys
[08:21] <dimitern> vladk, doesn't vbox support WoL already?
[08:21] <dimitern> vladk, that's why I decided to use libvirt - maas has support for controlling kvm vms with virsh directly
[08:22] <dimitern> and works quite well
[08:22] <dimitern> now i'm installing a new maas on trusty, in order to get vlan support (v1.5 r1961 or later)
[08:22] <vladk> vbox doesn't support WoL, but I write a daemon on Go, that listen vboxnet0 interface and starts VirtualBox images. This daemon is running on VirtualBox host
[08:22] <dimitern> vladk, nice! :)
[08:23] <vladk> I know about virsh, but it works only on Linux host, but I am still on MacOS
[08:23] <dimitern> vladk, you should get ubuntu ;)
[08:25] <vladk> I have installed ubuntu on macbook, and it surprisingly installed without problems, but I need time to be accustomed to new shortcuts and software.
[08:25] <dimitern> yeah, ubuntu works very well on mac books
[08:28] <vladk> About trusty, I failed to install maas on it, I got a lot of error on celeryd, that it could not connect to rabbitmq, so I switched to saucy.
[08:29] <dimitern> yeah, but we need maas on trusty which supports vlans
[08:29] <dimitern> other versions are too old
[08:32] <vladk> dimitern: we may use saucy for cluster controller and trusty for nodes
[08:33] <dimitern> vladk, we need a trusty region controller, the nodes do not matter - the RC is where the web ui and the maas api is (hence vlans support)
[08:34] <jam> dimitern, vladk: there is a PPA here: https://launchpad.net/~maas-maintainers/+archive/dailybuilds/+packages which has the updated versions of maas (I believe), but I do believe it only has a new-enough MaaS for the vlan work if you use trusty.
[08:34] <bigjools> if you don't want quite the bleeding edge there is daily-qa-ok as well
[08:34] <vladk> dimitern: if I select 'Create a new MAAS on this server' during installation, what do I get on that host? region-controller or cluster-controller or both?
[08:35] <jam> dimitern: actually, https://launchpad.net/~maas-maintainers/+archive/daily-qa-ok
[08:35] <dimitern> jam, yeah i talked with bigjools and rvba about that
[08:35] <jam> bigjools: thanks, I just saw that while poking around
[08:35] <bigjools> jam: yeah it would be better for you at the moment
[08:36] <dimitern> vladk, you get both
[08:36] <dimitern> vladk, to install only one or the other you'll need to install manually maas-region-controller or maas-cluster-controller (maas package includes both)
[08:37] <dimitern> jam, well, i'm half-way there with the installation anyway
[08:38] <jam> vladk, dimitern: you always need both, I would install both of them on the main machine.
[08:38] <jam> The cluster-controller is about scale-out
[08:38] <jam> so region is the overarching one, and clusters are groups of machines
[08:38] <jam> but you'd only have 2 cluster-controllers if you had, say, >1000 machines.
[08:42] <vladk> dimitern, jam: do I need a separate machine for juju? or I can install juju on maas host?
[08:42] <jam> you need a separate VM for the Juju state server (machine-0)
[08:43] <jam> MaaS doesn't let you put workloads on the MaaS host.
[08:45] <vladk> jam: Should 'juju state server' be inside or outside of MAAS cluster?
[09:04] <dimitern> vladk, when you run juju bootstrap in a maas environment, juju asks maas for a new node (one of the Ready ones), where juju will install the state server
[09:05] <dimitern> vladk, so strictly speaking the juju state server is inside the maas cluster (as in on the same network), but not on the cluster machine itself (on one of the enlisted nodes)
[09:23] <voidspace> morning all
[09:23] <dimitern> voidspace, hiya
[09:25] <voidspace> dimitern: o/
[09:36] <wwitzel3> hello
[09:38] <voidspace> wwitzel3: morning
[10:00] <rogpeppe> roll up, roll up, meeting limit approaching fast!
[10:00] <rogpeppe> fwereade, dimitern: ^
[10:01] <dimitern> rogpeppe, cheers
[10:01] <rogpeppe> voidspace: meeting?
[10:02] <thumper> jam, voidspace: meeting time
[10:02] <thumper> waigani: meeting
[10:02] <waigani> thumper: grrr, it keeps trying to log me in with my OTHER google account
[10:04] <wwitzel3> thumper: I looked at bug 1297899 this morning, I can replicate it with 1.17.2, but not with trunk. So I was going to try it with latest stable release to see if the fix can just be recommend the user upgrade.
[10:04] <_mup_> Bug #1297899: Libvirt machines deployed with MAAS and Precise is only able to successfully boot once <maas-provider> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1297899>
[10:12] <vladk>  can't connect juju-core-team call: This video call is full
[10:13] <jam1> vladk: yeah, we hit 15 today
[10:13] <jam1> have to get in early :)
[10:20] <jam1> vladk: https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit# is the doc we use each week to bring up stuff to talk as the whole team
[10:22] <vladk> I tried to install MAAS from the latest Trusty daily build and stuck again with MAAS web-UI:
[10:22] <vladk> I have a lot of messages in /var/log/maas/celery-region.log:
[10:22] <vladk> ERROR/MainProcess] consumer: Cannot connect to amqp://maas_workers@10.0.1.198:5672//maas_workers: [Errno 104] Connection reset by peer.
[10:22] <vladk> Does anyone know how to overcome it?
[10:23] <jam1> vladk: you can go to #maas and speak with rvba or allenap there
[10:23] <jam1> they are usually quite helpful
[10:23] <jam1> they lurk here too, but topic wise it makes more sense to ask there.
[10:25] <rvba> vladk: Looks like the rabbitmq server is down/not working.  Can you have a look at the logs?
[10:29] <vladk> rvba: rabbitmq is running, but probably not properly initialized, I don't see any vhosts and users on it
[10:29] <rvba> vladk: That's not right, you should see a maas user at least.  That's all created when the package gets installed.
[10:30] <vladk> rvba: I see maas user in Linux (although without /home/maas directory), but I don't see maas user in rabbitmqctl
[10:33] <vladk> rvba: the first mention of maas in rabbit@core.log is: "AMQPLAIN login refused: user 'maas_longpoll' - invalid credentials"
[10:33] <rvba> hum…
[10:34] <rvba> Same problem, the 'maas_longpoll' hasn't been created.
[10:35] <vladk> found in /var/log/installer/syslog: in-target: Creating user "maas_longpoll" ...
[10:35] <vladk> in-target: Error: unable to connect to node rabbit@core: nodedown
[10:36] <rvba> Interesting, looks like rabbitmq was down when the MAAS package was being installed.
[10:36] <rvba> alexisb: ^
[10:36] <rvba> alexisb: err, sorry
[10:36] <rvba> allenap: ^
[10:37] <allenap> Ah, that would explain it.
[10:37] <allenap> Could it be a race during installation? Rabbit’s not started by the time MAAS tries to create the user?
[10:39] <vladk> rvba, alexisb, allenap: part of /var/log/installation/syslog: http://pastebin.ubuntu.com/7162005/
[10:47] <allenap> vladk: Is policy-rc.d something you’ve installed?
[10:50] <vladk> allenap: I do the installation of MAAS on VirtualBox. Nothing special. I have a description here: https://docs.google.com/a/canonical.com/document/d/1oK80_jjPAD2BCwhNcFv9v_szkG1CE2AHy05BMjQfIeY/edit?usp=sharing
[10:51] <vladk> allenap: I don't have any problems with Saucy, but with Trusty this is persistent issue
[10:57] <rogpeppe> axw: perhaps we could have a chat after this meeting about HA stuff, if you have a little time?
[10:57] <rvba> vladk: Doing an install on canonistack now… you've installed 1.5+bzr2153+2177+253~ppa0~ubuntu14.04.1 correct?
[10:57] <axw> rogpeppe: bad time, sorry - need to get dinner on and so on
[10:57] <axw> rogpeppe: maybe later on
[10:57] <allenap> vladk: Essentially policy-rc.d seems to be blocking the correct operation of maas-region-controller’s postinst.
[10:58] <rogpeppe> axw: sure
[10:58] <rogpeppe> axw: let us know when might be a good time
[10:58] <axw> I will come back a bit later if I can
[10:58] <allenap> vladk: Unfortunately, the postinst explicitly ignores failure when trying to restart rabbitmq-server.
[10:58] <voidspace> rogpeppe: coffee and stuff - but my branch is nearly ready for review
[10:59] <rogpeppe> voidspace: lovely stuff
[10:59] <vladk> rvba: I take the latest trusty-server iso image from ubuntu site, my full installation/syslog: http://pastebin.ubuntu.com/7162080/
[10:59] <voidspace> rogpeppe: one more test (for the auto creating of the document - which as you suspected did fix the issue)
[10:59] <rogpeppe> voidspace: grand
[10:59] <vladk> allenap: ^
[10:59] <voidspace> rogpeppe: so I'll write the test and then wang the branch up for review
[10:59] <jam1> natefinch: I'm about half way through the review of your EnsureMongoServer patch
[10:59] <rogpeppe> voidspace: i'll grab some breakfast, then join the standup hangout
[10:59] <voidspace> rogpeppe: cool, see you there in a few minutes
[11:00] <rvba> vladk: okay, you're installing the trusty package from the main archive.
[11:00] <natefinch> jam1: good, we're still cleamimg it up a bit, but generally should be reviewable.  there's still a few failing tests.
[11:05] <rvba> vladk: this part doesn't look good. We're not 100% sure but we think it's what's causing the failure http://paste.ubuntu.com/7162104/
[11:08] <mgz> so... do I reboot for a proper shell, or keep working audio... I should really work out what the sound issue under ubuntu is
[11:09] <vladk> rvba, allenap: so the question should be redirected to ubuntu installer team?
[11:10] <rvba> vladk: the server team can probably help you with that indeed.  Let me just finish my test first (I'm installing the same package on a canonistack instance).
[11:11] <perrito666> bbl
[11:16] <rvba> vladk: it's taking forever… canonistack is so slow these days.
[11:18] <mgz> wallyworld: have you pushed your joyent branch up to launchpad?
[11:18] <wallyworld> mgz: not yet, give me a minute
[11:19] <mgz> ta
[11:19] <natefinch> wwitzel3: do you have instructions for local maas?
[11:19] <wwitzel3> natefinch: ish .. yes
[11:20] <wwitzel3> natefinch: I can walk you through and shore up the docunentation for it while we do it, that will help
[11:20] <wwitzel3> natefinch: I've done it so many times now it doesn't take very long
[11:20] <allenap> vladk: Possibly. The policy-rc.d stuff seems to be preventing maas-region-controller from installing properly, but because it’s explicit ignoring failures when restarting rabbit, and because it’s shell which invites poor error handling, it proceeds regardless, and it’s only discovered later. We could say that maas-region-controller conflicts with
[11:20] <allenap> whatever’s providing policy-rc.d, or we could work with policy-rc.d to enable whatever maas has to do.
[11:21] <allenap> vladk: I’m not familiar with policy-rc.d so I can’t say which is the best option.
[11:21] <natefinch> wwitzel3: yeah, cool.  can you put them in a google doc?  easiest way to share and edit stuff.
[11:21] <allenap> vladk: I’ll talk to roaksoax when he’s available; he knows a lot more about how maas is packaged than I do.
[11:22] <wallyworld> mgz: lp:~wallyworld/juju-core/joyent-provider-instance     wip, tests don't pass, won't compile without changes pushed also to github/joyent/gocommon and github/joyent/gosign
[11:22] <wwitzel3> natefinch: yep, what I most have documented is specific to VirtualBox but I switch recently to libvirt so I could take advantage of the virsh power stuff
[11:22] <wwitzel3> natefinch: which is what I don't have documented
[11:23] <natefinch> wwitzel3: is libvert better?  I've never used it
[11:23] <mgz> wallyworld: thanks, the gojoyent library split was one of the things I was concerned about with the landing
[11:24] <wallyworld> mgz: so i'll have to write tests for the libs and do git hub pull requests. even though tests don't pass, the code did bootstrap a real instance
[11:24] <wwitzel3> natefinch: well MAAS has native support for it as a power type, so that makes it better, less hand waving to get a VM to boot at the right time.
[11:26] <dimitern> natefinch, vladk, wwitzel3, here's my step by step notes for installing maas on libvirt locally: http://paste.ubuntu.com/7162174/
[11:28] <natefinch> dimitern: step 0 needs some work ;)
[11:29] <dimitern> natefinch, yeah :) so you need https://help.ubuntu.com/community/KVM/Installation
[11:32] <wwitzel3> dimitern, natefinch: yeah, those instructions for libvirt are exactly what I did
[11:33] <natefinch> wwitzel3, dimitern: nice
[11:33] <wwitzel3> dimitern, natefinch: only step I did you don't mention is I added an internal domain "my.maas" and added the maas controller to my list of nameservers in resolvconf
[11:34] <vladk> dimitern: you trick is to not install MAAS directly from installer
[11:34] <natefinch> gotta go help w/ kids, I'll be back in an hour or so
[11:34] <wwitzel3> dimitern: oh and I added an upstream dns server
[11:35] <wwitzel3> dimitern: oh, I can just downloaded a trusty ISO and installed maas, I didn't do the install/apt-get/upgrade steps
[11:36] <wwitzel3> dimitern: so slightly different starting steps, but it all works the same :)
[11:38] <mgz> wallyworld: short-term workaround for your github pull issue
[11:39] <mgz> wallyworld: you can always just update dependencies.tsv to point to github branches in your own namespace
[11:39] <wallyworld> mgz: that's not a bad idea
[11:39] <mgz> that lets you land the branch, now, without blocking
[11:39] <wallyworld> mgz: i need to get a bunch of tests passing though and write new onces
[11:40] <mgz> I suggest this, as the alternative is I land the older branch... which depends on lp:gojoyent, which then gets pulled out again when you land the further changes
[11:40] <mgz> which would be somewhat annoying for everyone
[11:40] <wallyworld> mgz: since i'm now storing the joyent private key in env config
[11:40] <dimitern> wwitzel3, yeah, I couldn't find trusty iso offhand
[11:40] <wallyworld> mgz: if we re going ti github, may as well link to those versions of the libs
[11:41] <mgz> (and generates conflicts, most likely)
[11:43] <voidspace> rogpeppe: you don't appear to be in either hangout (neither juju-core nor juju-core-team)
[11:44] <rogpeppe> voidspace: weird, i'm sitting in *a* hangout :-)
[11:44] <voidspace> hah
[11:44] <voidspace> good old google+
[11:44] <voidspace> what's the name (from the url)?
[11:44] <voidspace> I can try again
[11:44] <rogpeppe> voidspace: https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV9pYTY3ZTFhN2hqbTFlNnMzcjJsaWQ5bmhzNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[11:51] <voidspace> rogpeppe: the orb, banco de gaia
[11:52] <voidspace> rogpeppe: look for "little fluffy clouds"
[11:53] <voidspace> rogpeppe: Adventures Beyond the Ultraworld
[11:54] <voidspace> rogpeppe: Flaming Lips, Yoshimi Battles the Pink Robots
[11:54] <wwitzel3> are we saying real things?
[11:54] <voidspace> rogpeppe: Jonathan Coulton
[11:54] <voidspace> rogpeppe: look for the mandelbrot song
[11:54] <voidspace> rogpeppe: garfunkel and oates - pregnant women are smug
[11:56] <voidspace> rogpeppe: The Streets "Original Pirate Material"
[12:17] <rogpeppe> voidspace: TestOpenCreatesStateServersDoc
[12:34] <voidspace> https://codereview.appspot.com/81440043
[12:34] <voidspace> simple review for someone
[12:34] <voidspace> rogpeppe: ^
[12:38] <rogpeppe> voidspace: LGTM, but perhaps dimitern or fwereade or jam1 might want to take a look
[12:39] <voidspace> rogpeppe: I've pushed the additional comment you suggested
[12:39] <rogpeppe> voidspace: ta
[12:40] <axw> rogpeppe: don't think I can do a hangout tonight, but I will be around IRC for a while
[12:40] <jam1> voidspace: what is Key in this context (other than the contents of Keyfile) ?
[12:40] <axw> (if that's useful...)
[12:40] <rogpeppe> axw: that's fine
[12:40] <jam1> Private Key for the Certificate?
[12:40] <dimitern> voidspace, why not use environ global key to set the stateserverinfo ?
[12:40] <jam1> Maybe PrivateKey is a clearer spelling?
[12:40] <voidspace> jam1: it is the same Key as stateServerKey from configInternal
[12:40] <rogpeppe> jam1: sgtm
[12:40] <dimitern> voidspace, once we have multiple environments it will become a problem
[12:41] <rogpeppe> dimitern: there are other docs in the same collection
[12:41] <dimitern> rogpeppe, what other docs?
[12:41] <voidspace> jam1: do we have more than one key in the context of state serving?
[12:41] <rogpeppe> dimitern: stateserverinfo and apihostports
[12:41] <jam1> voidspace: rogpeppe: Since this *is* exposed in the API, and we don't want to change APIs when they are public, can we just expose KeyFile, or possible call in MongoKey ?
[12:41] <jam1> Rather than a comment about wanting it in the future?
[12:42] <dimitern> rogpeppe, so shouldn't the state server info be linked to the environment?
[12:42] <rogpeppe> jam1: sure, that's reasonable
[12:42] <jam1> I guess it isn't in API just yet
[12:42] <voidspace> rogpeppe: jam1: do we have that information easily available at the point we want to use it/
[12:42] <rogpeppe> dimitern: every single other collection has a problem if we're going to store multiple environments
[12:42] <voidspace> rogpeppe: jam1: it wasn't accessible on the config structs passed round when bootstrapping happens
[12:42] <rogpeppe> dimitern: using environGlobalKey doesn't help
[12:42] <bodie_> morning all
[12:42] <jam1> Given lines like this: +	err := st.stateServers.Find(bson.D{{"_id", stateServingInfoKey}}).One(&info)
[12:42] <rogpeppe> bodie_: hiya
[12:43] <jam1> we probably want to be careful what we call a "Key"d
[12:43] <rogpeppe> jam1: the API will come very soon
[12:43] <jam1> since stateServingInfoKey is a index entry?
[12:43] <jam1> aka, nothing like the public/private key strings
[12:43] <voidspace> jam1: rogpeppe: I'm happy to change Key to PrivateKey
[12:43] <rogpeppe> yeah, PrivateKey sgtm
[12:44] <rogpeppe> dimitern: we *could* potentially have a separate collection for every singleton document, but that seems like it's unnecessary work
[12:44] <dimitern> rogpeppe, just sayin'..
[12:45] <rogpeppe> dimitern: currently every document in every collection is implicitly linked to the environment
[12:46] <dimitern> rogpeppe, except for these which are linked to an environment
[12:46] <jam1> rogpeppe: given that it is just the value "e"
[12:46] <dimitern> rogpeppe, annotations, constraints, settings
[12:46] <jam1> dimitern: ^^
[12:46] <jam1> ./state/environ.go:16:const environGlobalKey = "e"
[12:46] <dimitern> jam1, I know, but it can be different in the future
[12:46] <dimitern> jam1, e#uuid
[12:47] <jam1> dimitern: well, we'd certainly have to restructure things and make it attributes of a State object, rather than global consts/vars
[12:48] <dimitern> jam1, +1 on that
[12:48] <jam1> rogpeppe: voidspace: So I happen to not like our current pattern of creating yet-another-collection whenever we have 1 doc worth of stuff to write, but it is the pattern so far.
[12:49] <voidspace> jam1: bikeshedding on name for "KeyFile" - rogpeppe is suggesting "SharedSecret"
[12:49] <axw> fwereade: re proxy-ssh, what do you mean by "can we instead just refuse it and error out" in the local provider code?
[12:49] <jam1> voidspace: I'd probably still want to put Mongo in there
[12:49] <jam1> to distinguish what we're sharing the secret about
[12:49] <jam1> or at least, DBSharedSecret
[12:50] <rogpeppe> jam1: well, all this info is for running mongo
[12:50] <rogpeppe> jam1: i guess we could put Mongo in front of every field
[12:50] <jam1> rogpeppe: technically APIPort isn't
[12:50] <rogpeppe> jam1: good point.
[12:50] <voidspace> DBSharedSecret sounds good
[12:50] <voidspace> mongo should be an implementation detail
[12:50] <jam1> voidspace: I think rog has a point that most of it is about the DB already
[12:51] <voidspace> ok, so back to SharedSecret
[12:51] <jam1> Cert happens to be used both ways, right?
[12:51] <rogpeppe> jam1: i think just SharedSecret should be ok
[12:51] <jam1> it is the Mongo TLS Cert and the API TLS Cert
[12:51] <rogpeppe> jam1: it doesn't actually matter that much how it's used
[12:51] <rogpeppe> jam1: yes
[12:51] <natefinch> jam1: the Mongo KeyFile is just a shared password, really
[12:52] <rogpeppe> natefinch: yeah, hence my SharedSecret suggestion
[12:52] <voidspace> naming things is the *perfect* topic for bike shedding :-)
[12:52] <jam1> voidspace: https://codereview.appspot.com/81440043/
[12:52] <jam1> reviewd
[12:52] <natefinch> rogpeppe: yeah that seems fine if we want to avoid referencing mongo
[12:52] <jam1> voidspace: naming is one of the 3 unsolved problems, right?
[12:52] <voidspace> cool, I'm just running tests before pushing the name change
[12:52] <voidspace> jam1: hah right
[12:52] <voidspace> the 2 hard problems in computer science
[12:52] <rogpeppe> cache invalidation?
[12:52] <voidspace> cache invalidation, off by one errors and naming things
[12:53] <natefinch> 4 things\: naming, cache invalidation and off by one errors
[12:53] <voidspace> There are 10 types of people in the world
[12:53] <sinzui> cmars, are bug 1290824 and bug 1290828 fix committed?
[12:53] <voidspace> Those who understand binary, those who don't and those who were expecting a joke about trinary
[12:53] <_mup_> Bug #1290824: juju should ask the charm store to decide the default series for a charm <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1290824>
[12:53] <_mup_> Bug #1290828: charm-store should be able to map "foo" into "cs:precise/foo" <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1290828>
[12:53] <natefinch> I love nerd jokes
[12:54] <bodie_> btw, appreciate seeing good responses to my email.  thanks all
[12:54] <voidspace> My favourite nerd joke, not computer related
[12:54] <voidspace> Heisenberg is driving along the freeway and happens to be speeding
[12:54] <bodie_> heheh
[12:54] <voidspace> A traffic cop spots him and flags him down
[12:54] <voidspace> The cop walks up to the car and gets Heisenberg to wind down the windo
[12:54] <voidspace> *window
[12:54] <voidspace> "Do you know how fast you were going?" the cop asks
[12:55] <voidspace> "No" replies Heisenberg, "but I know exactly where I am"
[12:56] <bodie_> I like the one about one Newton per square meter
[12:56] <voidspace> that's funny
[12:56] <bodie_> and my delivery is terrible, but I suspected the audience would already know the content...
[12:56] <voidspace> possibly not, it was new to me a few days ago
[12:56] <bodie_> why use a copy when a reference will do?
[12:57] <bodie_> :)
[12:57] <voidspace> I like the "infitinte mathmeticians walk into a bar. The first one asks for half a pint, the second for a quarter, the third for an eighth and so on"
[12:57] <voidspace> The barman pours a pint and tells them to sort it out amongst themselves...
[12:58] <voidspace> And on that note, coffee...
[12:59] <bodie_> lol
[13:02] <bodie_> a pint of coffee
[13:03] <sinzui> davecheney, I don't know about the landing bot. CI's unit tests are run with 2cpu machines except for arm64 which has 4
[13:04] <fwereade> axw, that's in Prepare, right? I'd just like to check that nobody sets a bad value without being warned -- I'd be fine with overwriting it if we output that we;re doing so
[13:05] <axw> fwereade: ok
[13:05] <axw> fwereade: I would normally, I just didn't in this case because there's no reason for a user setting it in the first place
[13:05] <axw> but I can do that
[13:06] <axw> fwereade: is there a better way to do this? feels slightly awkward putting it in the config
[13:06] <axw> fwereade: especially if it means going to the API for config ...
[13:06] <fwereade> axw, I felt awkward about that too
[13:06] <axw> just didn't want to do the dreaded env.Type() == "local"
[13:06] <fwereade> axw, but it *is* I think config, it can reasonably vary for different environments even against the same provider at times
[13:07] <fwereade> axw, +100 to avoiding that, yeah
[13:07] <perrito666> what is the difference between _test.go and _whitebox_test.go ?
[13:08] <fwereade> perrito666, the _whitebox_ ones are in-package
[13:08] <fwereade> perrito666, ie `package foo` not `package foo_test`
[13:09] <fwereade> perrito666, they don't get compiled into proper builds because their names end in _test.go
[13:09] <fwereade> perrito666, but they get all sorts ofinadvisable access to packageinternals
[13:09] <natefinch> perrito666: _whitebox isn't a Go thing, it's just a visual indicator for us.   _test.go is the magic that makes them only compiled during go test
[13:10] <fwereade> natefinch, perrito666: I suspect there may be a couple named _internal_test.go
[13:10] <natefinch> fwereade, perrito666 : I've only seen _whitebox in a few places... it's something I'd rather avoid, since it seems to just add visual noise.  I don't think it really matters that much if tests are internal or not
[13:11] <natefinch> fwereade: I much prefer internal tests anyway, because you can make the tests a lot more focused, so when something breaks, it's more obvious where the breaks are, rather than having to trace through reams and reams of code
[13:12] <fwereade> natefinch, well, it's inevitably testing the implementation not the interface, to some degree at least, and is therefore a bit nasty and makes things harder to change
[13:12] <fwereade> natefinch, so I'd prefer tests in general to be in a different package to the code
[13:13] <fwereade> natefinch, but if they have to be, I also rather agree it's not *that* big a deal if a few internal tests really help
[13:14] <fwereade> natefinch, I'm not sure the _whitebox_ bit is that justifiable but it's quite nice to have them flagged a bit more obviously
[13:14] <fwereade> the eye tends to slide right over foo vs foo_test
[13:15] <wwitzel3> whitebox tests just lead you down a path of pain and heartache, that said, in a pinch, it sure is nice having access to all those internals ;)
[13:15] <natefinch> fwereade: I'm the opposite.  testing the implementation is the only thing you're ever testing.  and tests with smaller scope are easier to fix when implementations change.  rather than monstrous system tests that blow up with weird errors.
[13:16] <fwereade> natefinch, the answer there is smaller packages imo
[13:16] <wwitzel3> natefinch: well you don't need system level tests to properly exercise a specific unit with a blackbox test, if you do, then the code is too tighly coupled
[13:17] <fwereade> natefinch, and you *are* indeed always testing the implementation, butneglecting to test it via its interface discards one of the real benefits of testing -- that your code, through having to satisfy two clients, ends up better factored
[13:17] <natefinch> packages inevitably depend on one another in annoying ways.  Go is great at unit tests because of interfaces... ub-
[13:18] <fwereade> natefinch, it's definitely hard to take a pre-existing monster package and break it into two... often you actually need to break it into 6 or 7
[13:18] <fwereade> natefinch, in order to actually untangle the dependencies
[13:20] <wwitzel3> natefinch, fwereade, with respect to refactoring, I find whitebox tests are almost counter productive to those efforts
[13:20] <natefinch> fwereade: but if your monster package breaks things down into small sub-functions that work over interfaces, it's very easy to write tests for the sub-functions to make sure they're doing the right thing.  You also want an overall test.... but when something changes, you'll get two failures - the huge blackbox test, and a tiny whitebox test that says "expected empty id, got nil id"
[13:20] <fwereade> natefinch, but that way you have a whole bunch of little implementations, which by necessity are exported and thus have the potential for some semblance of useful encapsulation
[13:20] <fwereade> wwitzel3, strongly agree
[13:21] <mgz> dimitern: is there anything you need review for atm? I also have some of the vlan setup info if you're interested
[13:22] <bodie_> hmmm
[13:22] <bodie_> testazureprovider failed
[13:23] <bodie_> http://paste.ubuntu.com/7162678/
[13:23] <fwereade> natefinch, and if you're doing nice interfaces in-package, you may as well expose them
[13:23] <bodie_> is this a known issue?
[13:23] <wwitzel3> natefinch: also, hangout? :)
[13:23] <natefinch> wwitzel3: sure
[13:24] <fwereade> bodie_, https://bugs.launchpad.net/juju-core/+bug/1223901
[13:24] <_mup_> Bug #1223901: provider/azure: tests are racy <race-condition> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1223901>
[13:24] <bodie_> ah
[13:26] <bodie_> looks like maybe more gwacl stuff
[13:26] <dimitern> mgz, I've just managed to create a maas node with a vlan and another network
[13:27] <dimitern> mgz, now I know how we need to set them up I think
[13:27] <fwereade> bodie_, most likely, that stuff was developed under some degree of time pressure
[13:27] <mgz> dimitern: ace. putting the details from maas in /etc/network/interfaces, or via the commandline calls?
[13:28] <dimitern> mgz, tried both
[13:28] <mgz> dimitern: the one fun part will be how we integrate this with containers
[13:28] <dimitern> mgz, so we need the "vlan" package for the vconfig command and also to modprobe 8021q before doing it
[13:28] <dimitern> mgz, yeah.. well I'll try some containers + bridging
[13:30] <axw> bodie_ fwereade : that's nothing new, it's an intermittent failure
[13:30] <mgz> the tricky bit being, currently we just let the container come up on the maas dhcp and ask for an address itself
[13:30] <axw> ther'es a bug for it somewhere
[13:30] <mgz> axw: yeah, fwereade linked the bug
[13:30] <axw> oops
[13:30] <axw> so he did
[13:31] <axw> this will be fixed when I land my changes
[13:31] <mgz> axw: you are a secret star
[13:31] <axw> mgz: not really, I just made the code that pretends to be parallel serial :)
[13:32] <axw> there's this concurrency control in there that doesn't work in practice because the azure API doesn't like it
[13:32] <voidspace> FAIL: replicaset_test.go:150: MongoSuite.TestAddRemoveSet
[13:32] <voidspace> known flakey test?
[13:32] <bodie_> axw, yay
[13:32] <voidspace> I'll look to see if there's a bug for it already
[13:33] <axw> voidspace: is it failing to find a server?
[13:33] <axw> if so, yeah
[13:33] <voidspace> axw: yeah "no reachable servers"
[13:41] <axw> fwereade: I can't check if the user has explicitly set proxy-ssh=true without changing the default
[13:41] <axw> currently defaults to true for all providers
[14:12] <perrito666> hey, could anyone try to bootstrap amazon with trunk?
[14:15] <natefinch> perrito666: trying now... what problem are you seeing?
[14:16] <mgz> perrito666: can you pastebin your bootstrap log with --debug passed?
[14:20] <perrito666> mgz: re-running
[14:21] <perrito666> natefinch: I was getting an error: error: flag provided but not defined: --instance-id
[14:21] <voidspace> rogpeppe: I just used string(existingByteArray) and []bytes(existingString)
[14:22] <rogpeppe> voidspace: sgtm
[14:22] <voidspace> rogpeppe: I'm concerned that this will use runes rather than encoded bytes
[14:22] <rogpeppe> voidspace: nope
[14:22] <voidspace> rogpeppe: but assuming ascii only they're the same anyway, right?
[14:22] <rogpeppe> voidspace: it doesn't do any rune-related convesions
[14:22] <rogpeppe> voidspace: but they're ascii only anyway, yeah
[14:22] <natefinch> perrito666: that was happening to rogpeppe the other day.  Make sure you clean out your $GOPATH/pkg directory, and make sure trunk is up to daye
[14:22] <voidspace> []byte(string) will return an array of runes (code points) won't it?
[14:22] <rogpeppe> voidspace: no
[14:22] <rogpeppe> voidspace: []rune(string) will
[14:23] <voidspace> ok, so utf-8 encoded bytes then?
[14:23] <rogpeppe> voidspace: []byte(string(x)) is a noop if x is []byte
[14:23] <natefinch> perrito666: also run godep dependencies.tsv from launchpad.net/juju-core and make sure it doesn't say anything is out of date
[14:23] <rogpeppe> voidspace: yeah, by convention
[14:23] <natefinch> perrito666: it just bootstrapped fine for me
[14:23] <voidspace> rogpeppe: right. If you get bytes out of a string there has to be *some* encoding used
[14:24] <rogpeppe> perrito666: i've seen that recently. i think it probably means you're not using the --upload-tools argument to juju bootstrap
[14:24] <natefinch> perrito666: sorry, that should be godeps not godep
[14:24] <perrito666> natefinch: thank you, something must be dirty on my env
[14:24] <rogpeppe> voidspace: "\xff\xfe\xfd\x00" is a perfectly valid string (even though it's not valid utf8)
[14:24] <perrito666> rogpeppe: thank you too :)
[14:24] <mramm> who from core can be at the cross team and represent our status on HA?
[14:25] <rogpeppe> mramm: i can do that
[14:25] <voidspace> rogpeppe: is it a valid Unicode string
[14:25] <rogpeppe> voidspace: nope
[14:25] <voidspace> rogpeppe: the word "valid" means something
[14:25] <mramm> likewise who from core can be at the cross team meeting and represent our status on VLAN support?
[14:25] <voidspace> rogpeppe: so the type string in Go must mean something then
[14:25] <rogpeppe> voidspace: well, a go string is just a bundle of bytes
[14:25] <voidspace> rogpeppe: is a Go string just a sequence of code points?
[14:25] <voidspace> right, but what do the bytes mean (i.e. what encoding)
[14:25] <rogpeppe> voidspace: not code points, bytes
[14:25] <mramm> dimitern: can you be there to talk about vlan?
[14:25] <voidspace> rogpeppe: ok, but what do the bytes represent
[14:26] <natefinch> perrito666: oh yeah, don't forget --upload-tools when you bootstrap using development code
[14:26] <voidspace> rogpeppe: that's what an encoding is
[14:26] <rogpeppe> voidspace: whatever you want them to :-)
[14:26] <voidspace> rogpeppe: a mapping of bytes to meaning
[14:26] <natefinch> voidspace: UTF8
[14:26] <voidspace> natefinch: thank you
[14:26] <rogpeppe> voidspace: you can impose an encoding if you want to
[14:26] <rogpeppe> voidspace: (and by convention, that encoding is utf8)
[14:26] <voidspace> ok
[14:27] <rogpeppe> voidspace: and some primitives in the language assume that
[14:27] <voidspace> so the string type is really just an immutable bytes type
[14:27] <rogpeppe> voidspace: yup
[14:27] <voidspace> yuck
[14:27] <dimitern> dimitern, xteam meeting?
[14:27] <dimitern> :)
[14:27] <rogpeppe> voidspace: it's actually quite clean
[14:27] <dimitern> mramm, that is ^^
[14:27] <voidspace> that's the Python 2 string type
[14:27] <rogpeppe> mramm: when is it?
[14:27] <dimitern> mramm, i can do it
[14:27] <mramm> in 3 min
[14:27] <rogpeppe> mramm: link?
[14:27] <mramm> just added you to the invite
[14:27] <natefinch> voidspace: you can get codepoints using the unicode package
[14:27] <voidspace> and as soon as you do anything non-trivial with text it puts the bugs in obscure places
[14:27] <mramm> on the phones
[14:28] <voidspace> natefinch: yep, that's pretty much the Python 2 way as well
[14:28] <mramm> too many people for a hangout now days
[14:28] <voidspace> Unicode as bolted on optional extra
[14:28] <voidspace> *sigh* :-)
[14:28] <rogpeppe> voidspace: if you go the other way, then your core language is as enormous as unicode itself
[14:28] <natefinch> voidspace: the only time it's a problem is if you expect the length of a string to be the number of characters
[14:28] <natefinch> voidspace: which is a case of "don't do that"
[14:28] <voidspace> or you need to care about the encoding of the bytes
[14:28] <voidspace> and the bytes came into the app at a different point
[14:29] <voidspace> or you need to combine strings from different sources
[14:29] <natefinch> voidspace: also, don't do that.  Just use UTF8 everywhere
[14:29] <rogpeppe> voidspace: conventions work pretty well. you convert at the boundaries of the system
[14:29] <natefinch> ^^
[14:29] <natefinch> exactly
[14:29] <voidspace> rogpeppe: I've worked with Unicode a reasonable amount
[14:29] <voidspace> even written articles on it :-)
[14:30] <voidspace> remembering to convert at the boundaries works, right up until it doesn't
[14:30] <voidspace> same with "assume everything is UTF8"
[14:30] <rogpeppe> voidspace: there are some pretty good packages for working with unicode in go
[14:30] <dimitern> mramm, sorry, I don't know how to join
[14:30] <voidspace> sure, I believe you
[14:30] <dimitern> mramm, there's no g+ link
[14:30] <mramm> dimitern: right it is a conference call
[14:30] <rogpeppe> mramm: i haven't seen an invite yet
[14:30] <voidspace> rogpeppe: I've worked with languages that are Unicode by default for text (and *force* you to do the conversion at the boundaries) and those that don't
[14:31] <voidspace> rogpeppe: and you have to think a bit more with the former, but it avoids a lot of pain
[14:31] <dimitern> mramm, I've never heard of these - how to join?
[14:31] <voidspace> right, lunch
[14:31] <rogpeppe> mramm: which normalisation form do you decide on?
[14:31] <mgz> dimitern: you can ring an actual phone number
[14:31] <rogpeppe> ooh, retro
[14:31] <mgz> there are details on the wiki
[14:31] <natefinch> lol
[14:31] <mramm> just pasted them over to dimitern
[14:35] <voidspace> rogpeppe: NFC or NFD of course
[14:35] <voidspace> unicode isn't perfect, but it's better than the alternative
[14:35] <mgz> NFC is such a great answer
[14:36] <mgz> you can't tell if they don't know, or have made the best choice
[14:38] <voidspace> apparently the correct answer is "neither or both"
[14:38] <voidspace> http://scripts.sil.org/cms/scripts/page.php?item_id=NFC_vs_NFD
[14:40] <voidspace> "The problem is that the question is not reasonable, and points to a misunderstanding of Unicode."
[14:41] <rogpeppe> voidspace: http://godoc.org/code.google.com/p/go.text/unicode/norm
[14:43] <voidspace> rogpeppe: mojibake
[14:44] <rogpeppe> voidspace: usually better than random crashes
[14:53] <mgz> sinzui: are you aware of anyone reportinga bug that lxc containers on maas don't work with trusty?
[14:54] <sinzui> mgz, is this what you are thinking about https://bugs.launchpad.net/juju-core/+bug/1271923
[14:54] <_mup_> Bug #1271923: using lxc containers with maas provider always default to series of host service unit <lxc> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1271923>
[14:55] <mgz> sinzui: aha! no, but that *would* mask the bug
[14:55] <mgz> ...maybe
[14:56] <sinzui> mgz, that is the only lxc/maas bug
[14:56] <mgz> I'll poke a little further, thanks!
[14:59] <ev> I didn't get a chance to ask before I had to drop off the cross-team call, but on the point of retrying provisioning in the face of transient errors
[14:59] <ev> (https://bugs.launchpad.net/juju-core/+bug/1227450)
[14:59] <_mup_> Bug #1227450: juju does not retry provisioning against transient provider errors <charmers> <landscape> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1227450>
[15:00] <ev> could you not query the provider for the api limit and only hit it below that rate?
[15:00] <ev> openstack seems to have this option: http://docs.openstack.org/api/openstack-compute/2/content/Rate_Limits-d1e862.html
[15:00] <mgz> ev: the goose code does... sort of do that already
[15:01] <ev> ooh, magic rune
[15:01] <ev> grepping through tip and reading up
[15:01] <ev> thanks mgz
[15:01] <ev> also, any chance on getting movement on cleaning up security groups and floating ips in a coming release?
[15:01] <mgz> the issue is we only retry 3 times, and without much backoff,
[15:01] <ev> we have to tidy up after each deployment as we quickly run out of them on HP Cloud
[15:02] <ev> ah right
[15:02] <mgz> and juju-core, when startinga bunch of things in parallel isn't polite about it,
[15:02] <ev> yeah
[15:02] <mgz> so, it's likely that goose gets hammered with more things than even its retry code can help with
[15:02] <mgz> what's landed in trunk should unblock you guys on borked environments, because you can just run the deployer script,
[15:03] <mgz> then do `juju retry-provisioning` if things have gone wrong, rather than tearing the lot down and going from the start
[15:03] <mgz> and we'll gradually improve on not getting into that state in the first place
[15:05] <ev> is there any way of knowing that it failed because of API limits specifically, short of grepping the output of juju status for "API limit" ?
[15:05] <ev> just trying to think of what we put in our juju-deployer wrapper for this
[15:05] <natefinch> nothing like a load of 5.9.... #thanksgoogletalkplugin
[15:06] <mgz> yes, and making juju-core understand the 503 would also mean the provisioner could automatically try again a bit later
[15:06] <rogpeppe> wwitzel3: i'm looking at your problem now, BTW
[15:07] <mgz> ev: as a workaround for you guys, it would be reasonable to just look for status: error in the yaml and call the retry command
[15:08] <bodie_> pinged Actions thread back
[15:08] <bodie_> thanks for all the talky talky :)
[15:15] <ev> so that call was quite specific to juju development. Do we have any kind of call set up for people developing solutions on top of juju? Just a place for sharing best practices, that sort of thing.
[15:19] <mgz> ev: no, but that would probably make sense. the current call is far too large really, for just a people-giving-feedback-to-juju-core, and covers a bunch more sutff
[15:19] <mgz> mramm may have opinions. it's still good for us to hear about what you guys are struggling with on juju day to day though :)
[15:20] <ev> opinions on how to structure a separate call?
[15:20] <mgz> yeah.
[15:20] <ev> I think it'd make sense to have a juju-core representative on the call
[15:20] <ev> so you guys can gauge whats plaguing your consumers
[15:21] <dimitern> mgz, this is what we need to enable a vlan in a maas node: http://paste.ubuntu.com/7163250/
[15:22] <ev> but I was thinking people from ~canonical-ci-engineering, ~canonical-ci, ~canonical-losas, ~oem-solutions-releng, etc
[15:22] <mgz> dimitern: so, that's doing a bunch of things twice. the do-it-now commands could be omitted, as we're probably doing ifdown/ifup anyway
[15:23] <dimitern> mgz, we want them to appear after reboot as well, right?
[15:23] <dimitern> mgz, and we want them immediately as well
[15:23] <ev> mramm: what do you think?
[15:24] <mgz> right, so we just do the adding to /etc/network/interfaces (.d ideally), and not the vconfig, for instance
[15:24] <mgz> and just take that interface down and put it back up again to pick up the new config
[15:24] <mgz> as we currently do for the bridge config
[15:25] <mgz> ...one fun part: we do bridge config in cloud-init - which is earlier than we can make an api call to maas to get the vlan details
[15:26] <mgz> so, we either do the network setup in two steps, or fiddle with when the existing bridge setup happens
[15:26] <dimitern> mgz, vconfig is needed to create the vlan
[15:27] <mgz> dimitern: right at that moment, yeah, but setting it up in /etc/network is equivalent
[15:27] <dimitern> mgz, well, I suppose we can generate the right commands in cloud-init, incl. the data we get from maas (the provisioner can prepare that)
[15:28] <mgz> right, that's one option, if the provisioner can get the right networks out of maas early enough to pass the details it
[15:28] <mgz> *in
[15:28] <mgz> I'm not sure we can
[15:29] <mgz> because we ask maas to do the provisioning for us, which is picking the machine *and* giving it the boot details
[15:29] <dimitern> mgz, why not? we can ask "give me the networks for this machine" after we do acquireNode
[15:29] <mgz> we don't know what machine we got before we need to give it the cloud-config stuff
[15:29] <mgz> iirc
[15:29] <dimitern> i'll have to look into that some more
[15:30] <mgz> dimitern: actually, maybe it works, we might have an interval where we have the machine identified, before we finish off StartInstance
[15:32] <dimitern> mgz, it my experiments with maas-cli you do know what instance you'll be starting after you acquire it with a set of networks
[15:32] <mgz> dimitern: maybe that's the best option then, doing bridge and vlan seperately scares me a bit
[15:33] <dimitern> mgz, lxc+bridging+vlans, now that's scary :)
[15:46] <mramm> ev: mgz: I am supportive of a second call, or a restructuring of the cross-team call
[15:47] <mramm> I think we should setup a one-off-call to go over the current ideas
[15:47] <mramm> and then from there we can figure out what makes sense as a standing thing
[15:48] <mramm> jcastro: do you think you can help get that setup?
[15:53] <jcastro> yeah
[15:54] <jcastro> ev, we have a charmers call weekly where we talk about juju consumption rather than core stuff, you're more than welcome, we have a bunch of new people so we're always swapping tips
[16:03] <jcastro> ev, I can also have our dudes spin up your team if you'd like
[16:03] <jcastro> give you a condensed best practice dump
[16:16] <wwitzel3> natefinch: just merged some changes from rogpeppe and pushed them up
[16:31] <natefinch> wwitzel3: sweet
[16:49] <voidspace> rogpeppe: state/api/machiner.go ? (place for the StateServingInfo api)
[16:49] <voidspace> ah, that's the client side
[16:49] <rogpeppe> voidspace: state/api/agent i think
[16:49] <voidspace> rogpeppe: cool, thanks
[16:51] <sinzui> perrito666, We don't use --upload-tools in testing, there is alos talk of removing the feature.
[16:52] <perrito666> sinzui: well to be honest I did not have to use it a couple of revisions back
[16:52] <sinzui> perrito666, If --upload-tools is required, then should this be documented with backup and restore...you cannot backup and restore unless you use upload-tool (a developer hack)
[16:53] <perrito666> sinzui: regardles, using an older rev the thing runs well even without upload-tools
[16:53] <sinzui> perrito666, then maybe that is part of the bug. We expect enterprise users to use streams, and if not a a public cloud, their own stream defined in the tools-metadata-url
[16:54] <sinzui> perrito666, okay, I think we do have a regression then, Streams are not being honoured it seems
[16:55] <jam1> alexisb: looks like I just missed you and natefinch, sorry I didn't make it in time
[16:56] <alexisb> no worries
[16:57] <alexisb> natefinch can follow up with you
[16:57] <natefinch> jam1: you only missed us by seconds :)  I'm back in the hangout if you want to talk that way.
[16:57] <sinzui> perrito666, I suspect that if you called juju sync-tools ENV, then ran the test, it might pass also
[17:01] <perrito666> sinzui: queued to the test run marathon I am having
[17:03] <perrito666> it is very unfortunate that I got to fix the two bugs that where impeding my test to run and none of those was the one breaking your side :(
[17:04] <ev> jcastro: yes please. Does it have people from the teams I mentioned?
[17:04] <ev> does it have juju-core people for "this is burning us badly"?
[17:05] <jcastro> it could, can you jet me a mail? I can set this up but I am currently putting out 2 fires
[17:17] <perrito666> sinzui: -r2488 works out of the box here (with the tools-metadata-url: you suggested)
[17:28] <voidspace> rogpeppe: AuthEnvironManager did you say?
[17:29] <rogpeppe> voidspace: yeah
[17:29] <voidspace> rogpeppe: cool
[17:29] <voidspace> thanks
[17:36] <sinzui> perrito666, I am releasing r2498 as 1.17.7. Since CI is setup largely as end users might use it. I cannot say the feature works.
[17:37] <perrito666> sinzui: off course, I was not trying to imply that, I was just thinking out loud
[17:39] <sinzui> perrito666, Maybe I can get abentley to try the script. He knows the test infrastructure and he might see a problem with the test
[17:40] <perrito666> sinzui: please do, I am pretty sure now that there is something I need to set up in my env to replicate your failure, yet I cant get  exactly what it is
[17:40] <sinzui> perrito666, you didn't need to call sync-tools?
[17:40] <perrito666> sinzui: nope
[17:41] <perrito666> I just bzr revert -r2488; go install ./...; juju destroy-environment amazon; ./backup_restore_juju.py $GOPATH/bin/ amazon
[17:42] <perrito666> sinzui: previously I had deleted all binaries and pkgs
[17:42] <perrito666> and that (ok, there was a cd to your test repo in the middle of that) but you get the point
[17:43] <sinzui> perrito666, and $GOPATH/bin is in the from of the $PATH?
[17:43] <perrito666> sinzui: yes, I exported PATH explicitly before running
[17:44] <sinzui> That all sounds correct.
[17:44]  * sinzui ponders tainted control-buckets
[17:47] <perrito666> I have what looks pretty much as a fresh starting user, that is why I am a bit puzzled on why is it not failing just like jenkins
[18:01] <natefinch> wwitzel3: sorry, long call with John & Alexis, and now I need to drop my car off at the garage.  Back in not too long I hope.
[18:10] <rogpeppe> wwitzel3: i bet you're getting test failures in testOpenAPIState
[18:14] <rogpeppe> voidspace: am enjoying the lips
[18:22] <voidspace> rogpeppe: yeah, they're good
[18:25] <rogpeppe> yay, cmd/jujud test pass
[18:25] <rogpeppe> tests
[18:25] <voidspace> rogpeppe: you there?
[18:26] <rogpeppe> voidspace: yup
[18:26] <voidspace> rogpeppe: can you hear me?
[18:26] <rogpeppe> voidspace: i'm in the hangout and there are two instances of you, but they're unresponsive
[18:26] <rogpeppe> voidspace: nope
[18:27] <voidspace> ah, maybe the hangout has crashed
[18:27] <rogpeppe> voidspace: i was chucked out briefly a while ago. might be something to do with that
[18:27] <voidspace> I'll leave and reenter
[18:33] <voidspace> g'bye all
[18:33] <voidspace> EOD
[18:34] <voidspace> g'night
[18:52] <natefinch> wwitzel3, rogpeppe back now
[18:58] <perrito666> ok EOD for me, shout me via mail if you need me
[18:58] <wwitzel3> natefinch: ok
[19:03] <rogpeppe> natefinch, wwitzel3: i'm ducking out of the call for a little bit. ping me if you need me.
[19:04] <natefinch> rogpeppe: ok, no prob
[19:04] <wwitzel3> rogpeppe: oh right, sorry :)
[19:25] <perrito666> sinzui: hey, CI actually "worked"I just saw a merge proposal fixing that ssh issue, you always see the same public address error bc the error is very poorly handled
[19:26] <rogpeppe> fwereade: you're not around atm by any chance?
[19:28] <sinzui> perrito666, damn it. you are right. I has worked once: http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/functional-backup-restore-devel/
[19:28] <perrito666> sinzui: https://codereview.appspot.com/81180043/patch/1/10002
[19:29] <perrito666> sinzui: the link you just send me is not the one you wanted to sen me?
[19:30] <sinzui> perrito666, From the history of jobs r2497 passed on its 3rd try r2798 never passed
[19:30] <perrito666> ah yes
[19:30] <sinzui> r2499 is testing now
[19:30] <perrito666> sinzui: the thing is
[19:31] <perrito666> there is a portion of the code that does a lot of things yet when it fails it is always hidden by the same error
[19:31] <perrito666> which is the one we are seeing since the beginning of thi bug
[19:32] <sinzui> I suspected as much. Obviously we have a public address, but juju uses that general error to say it could not connect
[19:32] <sinzui> I wonder if the test is more reliable with hp?
[19:33] <perrito666> sinzui: the current error is with ssh, there was an ad hoc implementation of ssh and I switched to use the default one, but apparently the default one was broken short after
[19:34] <sinzui> 2497 is the rev that fixes it too
[19:36] <sinzui> perrito666, I changed the test to use Hp next time. If the current run fails, the next 3 tries will be in another cloud
[19:37] <sinzui> damn, and try 2 did fail
[19:44] <rogpeppe> a review of this branch would be appreciated. https://codereview.appspot.com/81570043/
[19:45] <perrito666> sinzui: makes no sense, 2497, which introduced changes worked, then it doesn't but the code is not even near that
[19:47] <perrito666> bbl
[19:55] <rogpeppe> does anyone else see a test failure in trunk, in agent/mongo
[19:55] <rogpeppe> ?
[19:56] <sinzui> natefinch, do you have a few minutes to review an inc to trunk's version? https://codereview.appspot.com/81580043
[19:56] <wwitzel3> rogpeppe: nope, not for me here
[19:56] <rogpeppe> wwitzel3: looks like a test isolation issue
[19:57] <natefinch> sinzui: I hope I'm never too busy to review a 2 character change :)  LGTM
[19:57] <wwitzel3> rogpeppe: it passes for me running the whole suite as well as just in agent/mongo
[19:58] <wwitzel3> rogpeppe: is there a specific test you want me to try?
[19:58] <rogpeppe> wwitzel3: if it passes for you, that's fine. i'm just proposing a fix
[20:02] <rogpeppe> wwitzel3, natefinch: i'd appreciate a review of this trivial fix: https://codereview.appspot.com/81290045
[20:03] <wwitzel3> rogpeppe: looking
[20:04] <wwitzel3> rogpeppe: we already do this in our branch actually
[20:05] <rogpeppe> wwitzel3: right, but this breaks trunk, so should go in soon
[20:06] <wwitzel3> rogpeppe: http://bazaar.launchpad.net/~wwitzel3/juju-core/030-MA-HA/view/head:/agent/mongo/mongo_test.go#L34
[20:06] <wwitzel3> rogpeppe: ok, sure
[20:06] <rogpeppe> wwitzel3: i prefer your version
[20:06] <rogpeppe> wwitzel3: i'll go with that
[20:07] <wwitzel3> rogpeppe: k
[20:10] <rogpeppe> wwitzel3: PTAL https://codereview.appspot.com/81290045
[20:12] <wwitzel3> rogpeppe: LGTM
[20:13] <fwereade> rogpeppe, I sort of am, but am not at my highest functioning
[20:14] <rogpeppe> fwereade: i've refactored the agent config in the least invasive way i can think of that still gives us some reasonable behaviour in jujud
[20:14] <rogpeppe> fwereade: i'd very much appreciate your opinion when you think you can muster a look
[20:14] <rogpeppe> fwereade: https://codereview.appspot.com/81570043/
[20:14] <rogpeppe> fwereade: it's on the critical path for HA
[20:21] <rogpeppe> natefinch, wwitzel3: i'd appreciate a review of this branch at some point - it's what i've done today: https://codereview.appspot.com/81570043
[20:23] <wwitzel3> rogpeppe: yeah, I've added it to my list, I will give it a thorough look
[20:24] <rogpeppe> wwitzel3: thanks a lot
[20:25] <natefinch> rogpeppe: me too
[20:35] <wwitzel3> EOD for me
[20:43] <rogpeppe> me too
[20:43] <rogpeppe> long past it
[20:43] <rogpeppe> g'night all
[20:44] <natefinch> night rog
[21:21] <fwereade> rogpeppe, that's very nice, nearly an LGTM straight off
[21:21] <fwereade> this is not to say others should not also look at it
[21:43] <hatch> is there a way to ping the env to see if a charm url has been loaded programatically
[21:43] <hatch> basically the deployer needs to check to see if a local charm has been uploaded already
[21:47] <davecheney> hatch: hmm
[21:47] <hatch> I'm at a total loss after banging on it for a couple hours so open to anything at this point :)
[21:47] <davecheney> charms only get up loaded if they are deployed
[21:48] <davecheney> those two actions are not seperate
[21:48] <hatch> ahh but they are now with the ability to upload local charms via the GUI
[21:48] <davecheney> maybe upgrade-charm has somethign useful
[21:48] <davecheney> hatch: ok, i'm probably out of date
[21:48] <davecheney> and I bet you can keep uploading the sme charm rev over and over
[21:48] <hatch> it auto increments the revno
[21:49] <davecheney> but that isn't what you want
[21:49] <davecheney> the depliyed has to create charms in the storage at exact renos
[21:49] <hatch> well not really - the user is dragging and dropping charms into the env in the gui, then deploying a bundle
[21:49] <hatch> so the deployer needs to deploy those 'local' charms
[21:50] <davecheney> hatch: i dunno if I can help
[21:50] <hatch> maybe I just skip the check and deploy
[21:50] <davecheney> i'm just guessing at this point
[21:50] <hatch> it's entirely possible what I'm looking for doesn't exist
[21:52] <hatch> thanks for the help davecheney I'll skip the check for now and just attempt deployment
[21:57] <davecheney> hatch: sounds like a good first step
[21:59] <davecheney> sinzui: congrats on 1.17.7
[22:00] <davecheney> will that be the point at which 1.18.0 is branched ?
[22:00] <davecheney> i saw there was a 1.17.8 milestone
[22:00] <sinzui> Thanks. Maybe. If interesting and stable fixes land over the next few days, I will use it
[22:01] <sinzui> There is a store compatibility and maas lxc issue that were raise a few hours ago
[22:01] <sinzui> davecheney, I think 1.18.0 will trunk + a few more revs
[22:01] <davecheney> sinzui: ok
[22:03] <fwereade> hatch, there's a CharmInfo method on Client?
[22:05] <fwereade> hatch, it looks a bit odd, though, it returns something from api not params -- not a big deal from your perspective though, right?
[22:15] <perrito666> sinzui: hey, still here?
[22:16] <sinzui> perrito666, I am
[22:17] <perrito666> does jenkins just merge rev after rev and run the same test? (I am trying to find out what was broken when)
[22:17] <sinzui> no
[22:19] <sinzui> perrito666, it tests the entire release. tarball, package, publication of tools, installation, then tests they work in each cloud then tests arch/series/function nuances
[22:19] <sinzui> https://docs.google.com/a/canonical.com/document/d/1ZQIJL2YNAYpDHDO4g3kwcq8tHTR8ax6L15xhAXELngc/edit
[22:19] <perrito666> sinzui: thanks, ill read
[22:48] <perrito666> hey guys, how do I make juju not required --upload-tools ?
[22:48] <davecheney> perrito666: if you are building juju from source, this is required
[22:48] <davecheney> as the versino of your local build will not match that of any published tools
[22:57] <sinzui> perrito666, 1. make your own stream data, 2, push it to a public site
[22:57]  * sinzui looks for fragment
[22:58] <sinzui> perrito666, look at the generate_streams() function in http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/assemble-public-tools.bash
[22:59] <sinzui> The summary is create the dir structure, copy your test tools into releases, then run metadata
[23:00] <sinzui> perrito666, oh, but you need to make your tool by taring the jujud with the right name.
[23:00] <sinzui> perrito666, That step is in the archive_tools function...in the most complicated way It could be written
[23:01] <sinzui> perrito666, just cd the the bin dir and tar it with the series and arch of your test machine
[23:01] <perrito666> sinzui: thank you
[23:01] <perrito666> :) I am so taking a beer from whoever broke that fix :p
[23:02] <sinzui> perrito666, You can put the whole tree from tools/ in a bucket in a cloud, or on a website. I push a tree here a few weeks ago for an example: http://people.canonical.com/~curtis/juju-dist/tools/
[23:03] <sinzui> perrito666, BTW, these steps are not common knowledge. I need to find time to make a script for a developer or devops to publish a few select tools for testing or private cloud use
[23:05] <perrito666> sinzui: well if all that will give me a copy of what i being tested, then here I go
[23:22] <hazmat> hatch there is no useful charm api, and local charms can't be checked to see if they are already uploaded
[23:22] <hazmat> since the env arbitrarily rewrites the revision
[23:24] <davecheney> slow ppc is slow
[23:24] <davecheney> trying to get a cleaner test run so I know where to focus today
[23:24] <davecheney> hatch: oh poop
[23:25] <davecheney> hazmat: even
[23:25] <hatch> lol
[23:25] <hatch> :)
[23:25] <hazmat> :-)
[23:25] <davecheney> hazmat: hatch that does sound like something that should be addressed
[23:25] <hazmat> hatch, sent email re that issue
[23:25] <davecheney> hazmat: good man
[23:25] <hazmat> davecheney, yes.. list charms, delete charm
[23:25] <hazmat> where delete only works if unused
[23:25] <hatch> davecheney is this re the question I asked before?
[23:25] <davecheney> hazmat: i was going to ask, but i'll ask a differnt way
[23:25] <davecheney> hazmat: charms are put into 'storage'
[23:25] <davecheney> right
[23:25] <hazmat> davecheney, please do.. i sent email privately
[23:25] <hatch> sorry my client dc'd for whatever reason
[23:25] <davecheney> like tools
[23:26] <hatch> may I be cc'd on said email?
[23:26] <hazmat> hatch, check your inbox
[23:26] <davecheney> hazmat: doesn't storage provide apis to list charms
[23:26] <hazmat> davecheney, don't really need to clean storage :-).. its polite.. but simply  wipe the ref in db
[23:26] <davecheney> albeit not very conventienlyt
[23:26] <hazmat> davecheney, doesn't matter
[23:26] <hazmat> davecheney, its in state
[23:26]  * hatch hits refresh a lot
[23:26] <hazmat> davecheney, we have storage link in state..
[23:26] <hatch> nothing
[23:26] <hatch> :)
[23:26] <davecheney> hazmat: ah yes, we store that metadata in state
[23:27] <hazmat> davecheney, yeah.. else we'd never find  a charm
[23:27] <davecheney> hazmat: in that case, there needs to be something added to the API server
[23:27]  * hazmat nods
[23:27] <davecheney> hatch: whelp, there is you answer
[23:27] <hazmat> davecheney, yes.. list charms, delete charm
[23:27] <hatch> davecheney lol *sadface*
[23:28] <hatch> ohh hazmat  u sent to personal email :)
[23:28] <hazmat> doh..
[23:28] <hatch> sorry missed that
[23:28] <hazmat> unintended.. was first completion i saw
[23:28] <hatch> no problem, thanks for commenting - I have hacked on the deployer to 'skip' all checks but it appears that there is no way via the CLI to deploy a charm that's already uploaded as well
[23:29] <hatch> I was going to confirm this tomorrow but this may be a blocker regardless
[23:29] <hazmat> hatch, no.. juju cli does not support deploying local charms that don't exist
[23:29] <hatch> yeah darn, the api does because we deploy via path in the gui through the rpc call
[23:29] <hazmat> hatch, and those checks are important to deployer, it wants to verify config/relations before arbitrarily modifying an env
[23:29] <hatch> right
[23:30] <hatch> this was supposed to be a quick fix - turns out it's quite an architectural change to how the deployer and possibly the cli's deploy command operates
[23:30] <hazmat> hatch, correct.. deployer still has pyjuju support
[23:31] <hatch> not in my fork...tehe
[23:31] <hatch> :P
[23:31] <hatch> but yeah ok thanks for clearing this up
[23:31] <hazmat> and supports old version of juju-core
[23:31] <hazmat> hatch, ^ which don't support charms via api
[23:31] <hazmat> hatch, there is no stable version of juju with  local charms via api afaik
[23:31] <sarnold> any suggestions for a go-capable cscope replacement? :) I'd like something that can find call sites, not just definitions; ctags is only providing definitions...
[23:32] <hatch> yeah - I hacked all of that stuff apart to make it get to the cli in the guiserver but then I think it totally falls apart
[23:33] <hazmat> hatch, once 1.18 / 1.20  whatever its called gets into trusty.. i'll drop pyjuju support in deployer and move to api only usage there as well
[23:33] <hatch> hazmat sounds good - so should I file this bug on the deployer project for that time?
[23:45] <davecheney> SHIT
[23:45] <davecheney> -juju.log WARNING
[23:45] <davecheney> isn't know to all packages
[23:45] <davecheney> damnit