[00:25] <perrito666> I hate something in my network but I am not sure what
[00:25] <thumper> your computer?
[00:25] <thumper> I had mine
[00:26] <perrito666> It might be my isp, or perhaps my wlan card, but I am not sure which of those is the one I hate today
[00:38] <sinzui> Hi wwitzel3 ericsnow: Can we get this reviewed and merged by tommorrow so that we can propose 1.25-beta1 for wily https://github.com/juju/charm/pull/157
[00:38]  * sinzui not know the policy for reviews and merges in the charm project
[01:56] <mup> Bug #1500676 opened: use-default-secgroup in environments.yaml not respected <cpec> <juju-core:New> <https://launchpad.net/bugs/1500676>
[05:11] <axw> wallyworld: FYI - https://bugs.launchpad.net/juju-core/+bug/1500703
[05:11] <mup> Bug #1500703: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[05:12] <wallyworld> ok
[05:12] <axw> wallyworld: gce volumes don't work properly
[05:12] <axw> wallyworld: working on a fix now
[05:12] <wallyworld> sounds good, ty
[05:12] <wallyworld> hopefully you'll get access to that maas setup soon too
[05:14] <mup> Bug #1500703 opened: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[05:17] <mup> Bug #1500703 changed: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[05:26] <mup> Bug #1500703 opened: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[05:29] <mup> Bug #1500703 changed: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[05:32] <mup> Bug #1500703 opened: provider/gce: DeviceNames populated in volume attachment info are invalid <gce-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500703>
[07:06] <mup> Bug #1500721 opened: provider/ec2: volumes should be attached with name "xvdf" instead of "xvdf1" by default <ec2-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500721>
[07:43] <rogpeppe> dimitern: oh great OCR of the day! :-) would you be able to do a review for me, by any chance please? http://reviews.vapour.ws/r/2774/
[07:50] <dimitern> rogpeppe, sure thing :) looking
[07:50] <rogpeppe> dimitern: ta muchly! :)
[08:02] <voidspace> dimitern: if you get a chance... http://reviews.vapour.ws/r/2775/
[08:02] <dimitern> frobware, sorry, omw ~2m
[08:04] <frobware> dimitern, ok
[08:07] <voidspace> dimitern: actually, extended the test and found a bug... fixing
[08:15] <voidspace> dimitern: and done...
[08:27] <axw> wallyworld: do you have a moment to review http://reviews.vapour.ws/r/2776/?
[08:27] <wallyworld> axw: sure, about to eat,so will pick it up after if i don't get it done
[08:27] <axw> wallyworld: thanks
[08:30] <wallyworld> axw: where does "scsi-0Google_PersistentDisk" come from?
[08:30] <wallyworld> is that something we made up?
[08:50] <dimitern> voidspace, sweet! :)
[09:00] <mup> Bug #1500760 opened: juju space/subnet subcommands need to respect -e env-name flag <network> <usability> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500760>
[09:02] <dimitern> voidspace, TheMue, standup?
[09:02] <dimitern> jam, fwereade ^^
[09:02] <rogpeppe> dimitern: any chance of that review? :)
[09:04] <dimitern> rogpeppe, in standup now, will reply in ~20m
[09:04] <rogpeppe> dimitern: ta
[09:04] <voidspace> dimitern: omw
[09:15] <dimitern> rogpeppe, LGTM
[09:15] <rogpeppe> dimitern: tvm
[09:25] <dimitern> voidspace, reviewed as well
[09:29] <dimitern> frobware, how's going so far with the bootstrapping etc?
[09:29] <frobware> dimitern, tis bootstrapped
[09:29] <frobware> dimitern, want to go through the motions over HO?
[09:31] <dimitern> frobware, ok - joining the standup one
[09:31] <frobware> dimitern, 10 mins - ok?
[09:31] <dimitern> frobware, np
[09:33] <mup> Bug #1500769 opened: provder/gce: default block source not set <gce-provider> <juju-core:In Progress by axwalk> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500769>
[09:33] <dimitern> dooferlad, just a reminder to add cards for the -e flag issue
[09:33] <dimitern> :)
[09:34] <dooferlad> sure
[09:44] <frobware> dimitern, I'm back...
[09:50] <dimitern> frobware, omw
[10:06] <axw> wallyworld: good news, I got Ceph working on GCE with storage.
[10:06] <wallyworld> farking awesome
[10:06] <wallyworld> what sort of disks?
[10:07] <axw> wallyworld: SSDs
[10:07] <wallyworld> much to change in the charm?
[10:07] <axw> wallyworld: the non-local kind
[10:07] <wallyworld> btw, did you see my question above?
[10:07] <axw> wallyworld: not a lot
[10:07] <axw> wallyworld: no sorry, reading
[10:08] <wallyworld> yeah, adding storage should not be a big deal
[10:08] <axw> wallyworld: it's not made up, that's how what the /dev/disk/by-id path looks like. it's not *documented* though, so it's a bit sketchy. hence the TODO, which involves changing mongo and apiserver, etc.
[10:09] <wallyworld> np, thanks, i didn't quite fully grok it
[10:09] <axw> wallyworld: there's two paths in /dev/disk/by-id: that one, and google-<device name>
[10:09] <wallyworld> ah ok
[10:09] <axw> wallyworld: the diskmanager publishes the undocumented one :)
[10:09] <wallyworld> :-)
[10:10] <axw> I better log a bug for that I think
[10:10] <wallyworld> axw: should we fix that now lest we have mmigration issue later
[10:10] <wallyworld> before 1.25 ships
[10:10] <axw> wallyworld: I'll try to do that next
[10:11] <axw> wallyworld: there's another bug I was about to fix, which is that the gce provider doesn't set a default volume source
[10:11] <axw> wallyworld: I can leave that for now and fix this
[10:11] <wallyworld> i think that would be wise, just imo
[10:11] <axw> wallyworld: I'd prefer to get the quick fix in first though, if you don't mind
[10:12] <wallyworld> sure, +1
[10:12] <axw> in case I run out of time
[10:12] <wallyworld> done
[10:12] <axw> wallyworld: thanks
[10:12] <TheMue> frobware: so, back from the doc, brain is - at least as much as possible ;) - ok, now continuing on the "online" docs (part of the cmd). want to propose it today
[10:29] <frobware> TheMue, sounds good on all fronts... :)
[10:32] <TheMue> frobware: yeah, absolutely. and then I can start with the user docs, already got needed infos by nick
[10:39] <mup> Bug #1500803 opened: provider/gce: HardwareId should use the documented "google-" format <gce-provider> <juju-core:In Progress by axwalk> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1500803>
[11:04] <frobware> dooferlad, do you run spaces tests on CI right now?
[11:04] <dooferlad> frobware: we don't have any yet, so no
[11:05] <dooferlad> frobware: that is what I am fixing :-)
[11:05] <dooferlad> frobware: there are unit tests
[11:05] <dooferlad> frobware: and those do run
[11:05] <frobware> dooferlad, ok, that's good -- if you had said "yes" then dimitern and I might have been bemused
[11:06] <frobware> dooferlad, because it's not clear at the moment which access-key/secret-key combo allows spaces to work
[11:10] <dooferlad> frobware, dimitern: http://pastebin.ubuntu.com/12610778/
[11:10] <dooferlad> frobware, dimitern: http://pastebin.ubuntu.com/12610786/
[11:10] <frobware> dooferlad, interesting. that's what I was trying to do.
[11:11] <frobware> dooferlad, as in my test charm for spaces was to use ubuntu
[11:11] <dooferlad> frobware: well, I have it automated now. Will check in and you can use it.
[11:12] <frobware> dooferlad, if you could bung me some instructions that would be appreciated
[11:12] <dimitern> dooferlad, you need to use a different service name if you're deploying the same charm twice
[11:12] <dimitern> dooferlad, i.e. juju deploy cs:trusty/ubuntu ubuntu1 --constraints spaces=dmz ; # or maybe even just: juju deploy ubuntu ubuntu2 --constraints...
[11:12] <dooferlad> dimitern: so http://reviews.vapour.ws/r/2700/ isn't quite the perfect instructions then :p
[11:13] <dooferlad> dimitern: will try that...
[11:13] <dimitern> dooferlad, in the steps there I'm using 1 deploy followed by 1 add-unit
[11:13] <dooferlad> dimitern: ok, ok, problem between keyboard and chair
[11:14] <dimitern> :)
[11:19] <wallyworld> rogpeppe: urulama: whenever you get time, here's a new charmrepo.v2 PR which adds a repo which sits on top of a given charm dir https://github.com/juju/charmrepo/pull/32
[11:19] <urulama> wallyworld: kk, sometime during the day, will be ready before your morning
[11:20] <rogpeppe> wallyworld: thanks, will look
[11:20] <wallyworld> tyvm
[11:20] <urulama> wallyworld: hah, not a small one :P
[11:20] <wallyworld> nah sorry
[11:21] <wallyworld> rogpeppe: urulama: it's set up to allow core to juju deploy with a dir path rather than a cs:foo or local:bar url
[11:24] <rogpeppe> wallyworld: i wonder if it's right that the caller should have no control as to which kind of repository is used
[11:25] <rogpeppe> wallyworld: for example if you're a server, you almost certainly don't want to be statting local paths
[11:25] <rogpeppe> wallyworld: when resolving URLs
[11:27] <wallyworld> rogpeppe: i don't quite follow, if you use the Infer method, the first checks are for cs: or local:. Only if neither of those does it assume a path
[11:27] <wallyworld> this is used on the client when deploy or upgrade
[11:29] <rogpeppe> wallyworld: hmm, doesn't ParseReference always return a schema of "cs" if none is specified
[11:29] <rogpeppe> ?
[11:30] <rogpeppe> wallyworld: so if you do "juju deploy wordpress" and there's a local wordpress directory that you want to deploy, i think it'll try to deploy cs:wordpress anyway, won't it?
[11:30] <rogpeppe> wallyworld: is that the behaviour you want?
[11:30] <wallyworld> rogpeppe: ah right so with paths with only single words (not foo/bar) it will assume cs:
[11:30] <wallyworld> i'll have to change that
[11:30] <wallyworld> try for path first
[11:30] <wallyworld> i had it that way and then changed it
[11:30] <dooferlad> dimitern: can you view the spaces and subnets in juju status?
[11:32] <dimitern> dooferlad, no
[11:32] <dooferlad> dimitern: bother
[11:41] <dimitern> dooferlad, use space list for the time being - we'll add it to status at some point
[11:47] <rogpeppe> wallyworld: have you got a few moments for a chat?
[11:48] <wallyworld> rogpeppe: sure, can i ping you in say 10 minutes?
[11:48] <rogpeppe> wallyworld: sure
[11:48] <wallyworld> ty
[11:49] <urulama> wallyworld, rogpeppe: do talk about the "supported-series" vs "series" as well, otherwise, we can do it tomorrow
[11:49] <wallyworld> oh? i changed it to supported-series
[11:52] <rogpeppe> wallyworld: eco guys don't like supported-series unfortunately
[11:52] <wallyworld> oh damn
[11:53] <wallyworld> i'll have to add back that parsing stuff
[11:54] <rogpeppe> wallyworld: i've suggested an alternative
[11:54] <wallyworld> in te doc?
[11:56] <rick_h_> wallyworld: in the bug on juju/charm that was opened
[11:56] <rick_h_> wallyworld: see https://github.com/juju/charm/issues/156
[11:56] <wallyworld> oh, ok, i don't normally follow gh bugs
[11:56] <rick_h_> wallyworld: :P
[11:58] <wallyworld> lp forever
[11:59] <wallyworld> rogpeppe: free now? https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
[12:09]  * fwereade had very little sleep last night and is going to have a nap before his meeting in 2h
[12:17] <dimitern> frobware, I found the problem
[12:19] <mup> Bug #1500843 opened: Windows ftb due to unused import is diskmanager <blocker> <ci> <regression> <windows> <juju-core:In Progress by gz> <https://launchpad.net/bugs/1500843>
[12:19] <dimitern> frobware, while I *still* don't quite get why it's working fine when using the root keys, the reason we're getting this rate limit error
[12:20] <dimitern> frobware, as we saw in the logs is "InvalidGroup.NotFound" for the SG juju created for the machine
[12:21] <dimitern> frobware, which is a "classic" SG - not attached to the VPC explicitly but
[12:22] <mup> Bug #1500843 changed: Windows ftb due to unused import is diskmanager <blocker> <ci> <regression> <windows> <juju-core:In Progress by gz> <https://launchpad.net/bugs/1500843>
[12:22] <dimitern> frobware, it might be easier if we get on a HO actually :)
[12:24] <mgz> ocr: ^ want to review my branch?
[12:25] <mup> Bug #1500843 opened: Windows ftb due to unused import is diskmanager <blocker> <ci> <regression> <windows> <juju-core:In Progress by gz> <https://launchpad.net/bugs/1500843>
[12:31] <voidspace> dimitern: so I added the missing test and extracted the functions as you suggested
[12:32] <voidspace> dimitern: switching one of the machines to have JobManageEnviron in the MachineTemplate caused AddMachines to return an empty slice of machines
[12:32] <voidspace> dimitern: do you think it's worth me digging into that to work out why?
[12:33] <frobware> dimitern, yep, HO's easier... :)
[12:37] <voidspace> dimitern: ah, found it - "state server jobs specified but not allowed"
[12:38] <voidspace> hmmm...
[12:40] <dimitern> frobware, joining standup HO?
[12:40] <frobware> dimitern, ok
[12:49] <wallyworld> rogpeppe: here's that charm change https://github.com/juju/charm/pull/158
[12:50] <urulama> wallyworld: i think he's out on lunch
[12:50] <wallyworld> urulama: np, i'm about to go to sleep, so if it's +1, could you shipit for me
[12:53] <urulama> wallyworld: will do
[12:53] <wallyworld> ty
[13:43] <frobware> dimitern, coming back... (wrong tab)
[14:40] <mup> Bug #1246156 changed: plugins should receive environment to operate in unambigiously <juju-core:Triaged> <https://launchpad.net/bugs/1246156>
[14:43] <mup> Bug #1246156 opened: plugins should receive environment to operate in unambigiously <juju-core:Triaged> <https://launchpad.net/bugs/1246156>
[14:46] <mup> Bug #1246156 changed: plugins should receive environment to operate in unambigiously <juju-core:Triaged> <https://launchpad.net/bugs/1246156>
[14:51] <voidspace> dimitern: ping
[14:55] <dimitern> voidspace, pong
[14:56] <voidspace> dimitern: upgrade step added to 1.25
[14:56] <voidspace> dimitern: does it need adding to 1.26 (master) as well (i.e. to steps126)
[14:57] <voidspace> dimitern: that would only be needed if someone upgraded from a 1.25 beta, which doesn't have the preferred field, to 1.26
[14:57] <voidspace> without going to 1.25 final first (which would do the upgrade for them)
[14:57] <voidspace> dimitern: I don't think that's supported, so I don't think it needs to be in steps126
[14:57] <voidspace> dimitern: but would like confirmation
[14:58] <voidspace> to be clear, it is (or will) be in steps124 and steps125 on master - I don't think it needs to be in steps126 as well
[14:59] <dimitern> voidspace, hmm.. let me think for a moment
[15:00] <dimitern> voidspace, I think since 1.25 is not release yet, we *shouldn't* need to add it to 1.26 steps
[15:01] <voidspace> dimitern: that's my understanding
[15:01] <voidspace> dimitern: they should upgrade to 1.25 "some released version" first
[15:01] <voidspace> which would do the upgrade
[15:01] <voidspace> then go to 1.26
[15:04] <dimitern> voidspace, yeah - as far as users are concerned - it might screw us up a bit when testing upgrades etc. with upload-tools
[15:07] <voidspace> dimitern: heh, if it does it's a few lines copy & paste to fix
[15:08] <voidspace> dimitern: it's merged on 1.24, in the queue for 1.25 and master
[15:10] <dimitern> voidspace, awesome!
[15:22] <natefinch> modular
[15:22] <natefinch> lol wrong window
[15:23] <voidspace> how to kill a colleague without being found out
[15:23] <voidspace> oops, wrong window...
[15:23] <natefinch> rofl
[15:23] <voidspace> ;-)
[15:28] <voidspace> dimitern: heh, landed on 1.25 - master is blocked
[15:28] <dimitern> voidspace, 1.25 is the important one anyway for us now :)
[15:29] <voidspace> dimitern: yep, I've marked the bug as fix committed
[15:29] <voidspace> dimitern: the blocker on master is trivial, so should be fixed soon anyway
[15:30] <dimitern> voidspace, sweet!
[15:44] <voidspace> dimitern: hah, so the ec2 provider implementation of NetworkInterfaces already fetches all associated subnets
[15:44] <voidspace> dimitern: the only thing needed for SubnetInfo that it doesn't keep is the availability zone information
[15:45] <voidspace> dimitern: so easy enough to add (somehow....)
[15:45] <voidspace> dimitern: looking at whether extending network.InterfaceInfo to keep this info is sensible
[15:48] <dimitern> frobware, *facepalm* .. and I was wondering why it's not working!
[15:48] <dimitern> voidspace, I'm not sure adding AZ to InterfaceInfo is worth the effort
[15:48] <dimitern> frobware, us-east-1 does not have a default VPC
[15:49] <voidspace> dimitern: but I *need* it for the Subnets call
[15:49] <voidspace> dimitern: if I add it to InterfaceInfo, then when Subnets(instId) is called I can just call NetworkInterfaces(instid) and build the SubnetInfo from that
[15:50] <voidspace> dimitern: otherwise I call NetworkInterface(instId) (which internally calls the ec2 describe subnets for each subnet) - and then I have to call describe subnet *again* for each nic to get the full SubnetInfo
[15:50] <voidspace> or I can add []AZ to InterfaceInfo
[15:51] <dimitern> frobware, what a way to waste 2h..
[15:51] <dimitern> voidspace, I see
[15:51] <voidspace> dimitern: or I can find another way, which might be better than extending InterfaceInfo
[15:51] <voidspace> a new method which is used by both NetworkInterfaces and Subnets
[15:51] <dimitern> voidspace, ok then - I see no harm in adding AvailabilityZone to InterfaceInfo
[15:52] <voidspace> it had better be a slice to support other providers where a subnet can span availability zones
[15:55] <dimitern> voidspace, fair point about using a slice - I'll leave it to your judgment then
[15:59] <frobware> dimitern, so what's the redux here?
[16:06] <dimitern> frobware, look carefully before spending hours debugging :)
[16:06] <dimitern> frobware, eu-central-1 one of the few (if not the only one) regions on the shared aws account with a default VPC
[16:07] <dimitern> frobware, I've added a few subnets to it, backed out my changes and I'm trying to recreate the demo there, will paste you some steps shortly
[16:07] <frobware> dimitern, ok. but I guess a better error message is in order for the places/cases where this currently happens.
[16:08] <dimitern> frobware, re the redux - default VPC is required for all this MVP functionality to work
[16:09] <dimitern> frobware, yes, definitely - e.g. error out if spaces cannot be supported (due to a missing default VPC for example at least for now)
[16:09] <voidspace> dimitern: which region do we have default vpc in?
[16:09] <dimitern> voidspace, eu-central-1
[16:09] <voidspace> cool, thanks
[16:09] <voidspace> dimitern: doing some manual testing
[16:09] <voidspace> about to do addressable containers (1.25)
[16:11] <lazypower> ooo addressable containers \o/
[16:11] <voidspace> heh
[16:12] <voidspace> "ERROR environment destruction failed: destroying storage: destroying volumes: destroying "vol-fa3c3117": The volume 'vol-fa3c3117' does not exist. (InvalidVolume.NotFound)"
[16:12] <voidspace> that's a new one on me. I didn't create any volumes.
[16:15] <dimitern> voidspace, go in the EC2 web console and check the Volumes page
[16:15] <voidspace> dimitern: presumably someone else's volume...
[16:15] <voidspace> which is worrying that my call to destroy-environment would touch it...
[16:16] <dimitern> and IT WORKS!
[16:16] <voidspace> yay
[16:16] <voidspace> whatever IT is...
[16:16] <voidspace> spaces hopefully...
[16:18] <dimitern> voidspace, frobware: it's still deploying some instances, but they all end up where they should and AZ distribution also works: http://paste.ubuntu.com/12613764/
[16:19] <voidspace> dimitern: awesome, nice work
[16:19] <mup> Bug #1464679 changed: juju status oneline format missing info <landscape> <status> <ui> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1464679>
[16:19] <dimitern> voidspace, frobware, here are the steps: http://paste.ubuntu.com/12613782/
[16:20] <frobware> dimitern, presumably I should be able to replicate this with my local aws account as it would have been created with a default VPC
[16:20] <dimitern> frobware, indeed - that's why it worked with my personal account but not with the shared on us-east-1
[16:22] <dimitern> frobware, and the mystery around root/non-root creds about the shared account - no mystery at all :) I actually tested with my account it turned out (I did set the shared acc keys but *then* overrode them in env. yaml)
[16:24] <frobware> dimitern, if you don't have a default VPC (e..g, us-east-1) is there a way to specify one as part of the setup/demo?
[16:24] <dimitern> frobware, not yet
[16:25] <dimitern> frobware, because the issues we were facing during the HO
[16:26] <dimitern> (with a non-default VPC the behavior is "as prescribed" in the AWS API docs, no "EC2-Classic"-sorta compatible quirks - e.g. groupName vs groupId)
[16:26] <frobware> dimitern, what happens if you don't do this step: for i in subnet-0fb97566 subnet-d27d91a9; do juju subnet add $i default; done
[16:29] <dimitern> frobware, nothing - I just wanted to test the 3 cases: using default VPC subnets, non-default subnets with and without auto-public-IP set,
[16:29] <dimitern> just for completeness sake
[16:29] <frobware> dimitern, OK. Just wanted to check (and understand) that you could do it with just public/dmz.
[16:30] <dimitern> frobware, yeah - surprisingly for me it works even in the last case (no public IPs) .. somewhat
[16:31] <frobware> dimitern, so next steps are to try some charms... :)
[16:31] <dimitern> frobware, the machine is up and can talk to the api server, you can even ssh into it (as we're jump-hosting via the bootstrap node), but it can't access the archive (dns works, but not connecting)
[16:31] <dimitern> frobware, yep! :)
[16:35] <dimitern> frobware, I'll leave the env running for tonight, checking the connectivity periodically with a watch script, just to make sure it works longer than 5m :)
[16:35] <dimitern> and then it's time to get a drink \o/
[16:35] <frobware> dimitern, yep, nice one!
[17:26] <katco> natefinch: wwitzel3: ericsnow_afk: are all of you available for a chat
[17:26] <katco> ?
[17:46] <mup> Bug #1500981 opened: juju-db segfault while syncing with replicas <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1500981>
[17:49] <ericsnow> katco: sure
[17:51] <katco> natefinch: wwitzel3: ericsnow: need the whole team for this one
[17:52] <katco> ericsnow: i'm in moonstone now if you have a sec though
[18:16] <mup> Bug #1500996 opened: Juju says "bad JSON product data" for valid simplestreams <ci> <simplestreams> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1500996>
[19:01] <perrito666> is there any charm for vivid?
[19:40] <rick_h_> perrito666: https://jujucharms.com/q/vivid
[19:53] <katco> natefinch: ping
[20:16] <perrito666> rick_h_: thanks a lot
[20:17] <rick_h_> perrito666: any time
[20:17] <perrito666> what is the middle column supposed to be, series?
[20:17] <rick_h_> perrito666: yes
[20:18] <rick_h_> more interesting in a search for not a specific series: https://jujucharms.com/q/apache2
[20:19] <perrito666> rick_h_: I tried the dropdown filter but only got the ubuntu charm
[20:19] <rick_h_> perrito666: yea, we try not to promote the non-LTS too much
[20:19] <katco> natefinch: ping
[20:20] <rick_h_> perrito666: so if you ask for it it'll give it to you, but deploying workloads is best done on LTS
[20:20] <perrito666> rick_h_: I used the filter to get the url parameter and then changed for vivid
[20:20] <rick_h_> perrito666: ah, yea it probably had some other params there by default vs a normal search.
[20:21] <rick_h_> perrito666: since by default in the /store it shows only promulgated (reviewed charms) and that is the only one
[20:21] <perrito666> heh, yup, the strange thing is that it returned only one charm, but it was useful for what I was trying
[20:21] <rick_h_> perrito666: anyway, a handful from there
[20:50] <katco> natefinch: ping
[21:11] <wallyworld> wwitzel3: bug 1491688 - where did you get up to? this issue seems familair - did we fix it one other time?
[21:11] <mup> Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority <landscape> <logging> <rsyslog> <sts> <juju-core:Triaged> <juju-core 1.24:Confirmed> <https://launchpad.net/bugs/1491688>
[21:18] <wwitzel3> wallyworld: yeah, we fixed it a previous time, axw did, but it looks like it might have not made it in to other versions, I got to replication point, but didn't ever start really digging on it
[21:19]  * thumper looks around carefully
[21:19] <thumper> anything blowing up?
[21:19] <wallyworld> wwitzel3: ty, i'll follow up with him
[21:19] <alexisb> thumper, yes
[21:19] <alexisb> we have two criticals:
[21:19] <thumper> :-(
[21:19]  * thumper sighs
[21:20] <alexisb> thumper, you know you love bug squad duties
[21:20] <thumper> except I was poking lxd with a stick
[21:20] <thumper> among other things
[21:21] <mwhudson> thumper: you can debug my ppc64le if you'd rather
[21:21] <thumper> alexisb: where are these criticals?
[21:22] <alexisb> thumper, lxd is a happening in moonstone hangout if you are interested
[21:22] <thumper> yeah
[21:22] <alexisb> I am sure wwitzel3 wouldnt mind if you joined the party
[21:22] <thumper> I have some info re:lxd
[21:22] <alexisb> criticals:
[21:23] <alexisb> bug 1491688
[21:23] <mup> Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority <landscape> <logging> <rsyslog> <sts> <juju-core:Triaged> <juju-core 1.24:Confirmed> <https://launchpad.net/bugs/1491688>
[21:23] <wallyworld> thumper: fwiw ^^^^^ i thought that one was fixed
[21:23] <thumper> which ironically is only high
[21:23] <alexisb> https://bugs.launchpad.net/juju-core/+bug/1335885
[21:23] <mup> Bug #1335885: destroy-environment reports WARNING cannot delete security group <amulet> <cloud-installer> <destroy-environment> <landscape> <openstack-provider> <security> <uosci> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1335885>
[21:24] <alexisb> thumper, it is happening on cisco site
[21:24] <thumper> wallyworld: I thought it was fixed too
[21:24] <wallyworld> thumper: andrew fixed it apparently, i'll check with him in an hour or so
[21:25] <thumper> I wonder if it is client version vs. fixed version
[21:25] <thumper> perhaps the fixed version hasn't made its way to the client site
[21:25] <wallyworld> could be
[21:25] <alexisb> thumper, that second one is now causing issues for openstack and sts
[21:25] <thumper> m'kay
[21:28] <thumper> wwitzel3: are you talking lxd now?
[21:33] <wallyworld> thumper: wwitzel3: bug 1417875
[21:33] <mup> Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority <canonical-bootstack> <logging> <regression> <juju-core:Fix
[21:33] <mup> Released by wwitzel3> <juju-core 1.21:Fix Released by wwitzel3> <juju-core 1.22:Fix Released by wwitzel3> <https://launchpad.net/bugs/1417875>
[21:34] <wallyworld> haven't read description yet, seems related
[21:34] <wallyworld> fixed in 1.22
[21:36] <wallyworld> thumper: wwitzel3: and then this one which seems more likely, fixed in 1.24 bug 1474614
[21:36] <mup> Bug #1474614: rsyslog connections fail with certificate verification errors after upgrade to 1.24.2 <regression> <juju-core:Fix Released by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1474614>
[21:36] <wallyworld> so maybe above fix needs to be checked
[21:45] <thumper> wallyworld: arse
[21:46] <wallyworld> balls?
[21:47] <wallyworld> thumper: ?
[21:47] <thumper> wallyworld: the fixed but not fixed
[21:48] <wallyworld> yeah, but could be different root cause
[21:48] <wallyworld> not sure, haven't dug
[22:08] <anastasiamac> menn0: tyvm for review!!!
[22:10] <menn0> anastasiamac: no problemo
[22:11] <mup> Bug #1501084 opened: hitting nova RAM quota results in over-general error <juju-core:New> <https://launchpad.net/bugs/1501084>
[22:32] <mup> Bug #1500676 changed: use-default-secgroup in environments.yaml not respected <cpec> <juju-core:Invalid> <https://launchpad.net/bugs/1500676>
[22:56] <mup> Bug #1500996 changed: Juju says "bad JSON product data" for valid simplestreams <ci> <simplestreams> <juju-core:Invalid> <juju-core 1.24:Invalid> <https://launchpad.net/bugs/1500996>
[22:56] <mup> Bug #1501093 opened: unclear simplestreams error <ci> <simplestreams> <juju-core:Triaged> <https://launchpad.net/bugs/1501093>
[23:30] <wwitzel3> thumper: you have some lxd info?
[23:34] <beisner> hi wallyworld, thumper - thoughts on https://launchpad.net/bugs/1335885 ?   i'm hitting it with high frequency, bootstraps are failing in test automation.
[23:34] <mup> Bug #1335885: destroy-environment reports WARNING cannot delete security group <amulet> <cloud-installer> <destroy-environment> <landscape> <openstack-provider> <security> <uosci> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1335885>
[23:35] <beisner> ps, added summary comment
[23:37] <beisner> 1.24.5 --> 1.24.6 seems to have exacerbated it