[00:00] <rogpeppe> ericsnow: i've pushed $$merge$$ - perhaps you could take it over if there are some silly errors from the bot?
[00:00] <rogpeppe> ericsnow: indeed
[00:00] <ericsnow> rogpeppe: sure
[00:00] <rogpeppe> ericsnow: but this should actually work reasonably for most use cases
[00:00] <rogpeppe> ericsnow: thanks
[00:00] <urulama> ty, ericsnow
[00:00]  * rogpeppe beds headward
[00:00] <ericsnow> rogpeppe: np
[00:00] <rogpeppe> g'night all
[00:32] <mup> Bug #1560262 opened: relation visibility rules different between service/service and service/subordinate relations <canonical-is> <juju-core:New> <PostgreSQL Charm:Triaged> <postgresql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1560262>
[01:02] <wallyworld> axw: with the restore issue - reading the code leads me to believe the issue is because we no longer store admin-secret in bootstrap config. we could add it back but wouldn't it be better to store it in the backup metadata?
[01:02] <axw> wallyworld: admin-secret is the password for admin@local, should just grab it out of accounts.yaml instead
[01:02] <wallyworld> ah, yes, good point
[01:03] <wallyworld> that does ite the restore to the user who did the backup
[01:03] <axw> wallyworld: (it would be better to pull something out of backup metadata tho)
[01:03] <wallyworld> agreed
[01:03] <wallyworld> i may fix the easy way for now
[01:03] <axw> wallyworld: +1
[01:03] <wallyworld> i'd rather the backup be stand alone
[01:03] <axw> wallyworld: needs an overhaul, so yeah
[01:22] <wallyworld> axw: joy, we also need ca-cert which is fine, but also ca-private-key which we don't currently store with the controller metadata
[01:23] <axw> wallyworld: what do we need that for?
[01:23] <axw> I thought we would generate new certs
[01:24] <wallyworld> i'll have to look deeper - the current code attempts to create an env config and it complains
[01:26] <davecheney> thumper: cherylj https://github.com/juju/juju/pull/4836
[01:26] <wallyworld> axw: atm we don't prepare or anything - the code just assumes we had a complete config available via bootstrap config, so it needs to be reworked
[01:27] <anastasiamac> wallyworld: axw: last change for openstack virt type http://reviews.vapour.ws/r/4276/
[01:27] <axw> anastasiamac: looking
[01:28] <anastasiamac> axw: tyvm \o/
[01:28] <axw> wallyworld: yeah, it does assume we have a bootstrap config already. it always did, so the only potential issue is to do with info we may have thrown away, like ca-private-key
[01:28] <axw> wallyworld: only immediate problem I mean
[01:29] <wallyworld> axw: yeah, not having the same ca-private-key seems problematic i think?
[01:29] <wallyworld> maybe not
[01:30] <axw> wallyworld: sorry, I don't know what's newly generated, and what needs to be the same
[01:30] <wallyworld> i guess if we are rebootstrapping, there's no existing machine sout there
[01:30] <wallyworld> so no need for existing agents to be able to reconnect
[01:31] <wallyworld> which i think would be the main issue
[01:31] <axw> wallyworld: part of the restore process involves SSHing to the agents and fixing them up, IIANM
[01:32] <axw> wallyworld: the controller's going to have a new IP, after all
[01:32] <wallyworld> right but doesn't the restore assume everything is gone if we use the -b option
[01:32] <wallyworld> maybe not
[01:33] <wallyworld> i'll have to read the code
[01:51] <axw> anastasiamac: just a couple of comment changes, otherwise LGTM
[01:51] <anastasiamac> axw: awesome \o/ thnx :D
[01:51] <axw> anastasiamac: BTW, "code is kinda weird" is not your fault, just how it is / has to be due to openstack limitation
[01:55] <axw> wallyworld: you said there was another bug about permission denied? I don't see it on LP against admin-controller-model. did you say you still had to add it?
[01:55] <wallyworld> axw: it's just not targetted to that branch, let me get it
[01:55] <wallyworld> https://launchpad.net/bugs/1461561
[01:56] <mup> Bug #1461561: juju run fails with "Permission denied (publickey)" on manual provider <intermittent-failure> <manual-provider> <run> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1461561>
[01:56] <axw> ta
[01:56] <mup> Bug #1441302 changed: Vivid unit tests are not reliable enough <test-failure> <vivid> <juju-core:Won't Fix> <https://launchpad.net/bugs/1441302>
[01:58] <axw> wallyworld: I suspect it's just a race with the worker to update authorized_keys
[01:58] <wallyworld> sounds likely yeah
[02:11] <mup> Bug #1496032 changed: backups restore won't create bootstrap on GCE <backup-restore> <docteam> <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1496032>
[02:36] <wallyworld> axw: reviewed
[02:36] <axw> wallyworld: thanks
[03:01] <axw> wallyworld: please see reply about type name
[03:01] <wallyworld> ok
[03:02] <wallyworld> axw: no reply yet, did you publish?
[03:03] <axw> wallyworld: derp. published now
[03:05] <wallyworld> axw: GenericResource I think is ok, but I'm not strong;y opinionated either way
[03:05] <axw> wallyworld: in that case I'll leave it. if it becomes a pattern, we should strongly consider changing the framework to allow injecting things directly
[03:06] <wallyworld> sgtm
[03:06] <axw> wallyworld: do you want me to wait before merging to admin-controller-model?
[03:06] <axw> wallyworld: wait for CI to be a bit happier?
[03:06] <wallyworld> may as well merge now, what could possibly go wrong :-)
[03:07] <wallyworld> we should have a run in say 5 hours
[03:07] <wallyworld> still time to fix stuff before tomorrow and better to find issues early at this stage
[03:07] <wallyworld> we could merge the other 2 fixes first i guess
[03:46] <cherylj> gah, I see the problem with the joyent provider
[03:46] <cherylj> they're ignoring the tags passed into startinstance
[03:46] <anastasiamac> cherylj: :D
[03:47] <davecheney>   thumper mwhudson https://github.com/golang/go/issues/14904
[03:48] <davecheney> i'm detouring into this bug this arvo
[03:48] <davecheney> cmd/juju/status trips it up 100% of the time
[03:56] <wallyworld> axw: this backup thing is messy - apart from old bootstrap config, the only place we store the admin-secret aka oldpassword is in the agent.conf file, and the same is true for the ca-private-key. So assuming we have that file, which the backup does include in the archive, we can parse it on restore, but i think it would be better to do that stuff server side and include in the json metadata for the backup. but that sucks because
[03:56] <wallyworld> nothing so far in apiserver needs to know about agentconfig and i'd rather keep it that way. so it's all a bit yuck
[03:58] <wallyworld> axw: maybe we should just include the private key and admin secret in bootstrap config
[03:59] <axw> wallyworld: it would be nice not to, but I guess we could as a stop gap at least
[04:00] <wallyworld> axw: yeah, i don't really want to. so what would we prefer - parsing the conf files on restore? or extracting the info srver side on backup
[04:00] <axw> wallyworld: we definitely can't generate new ones at restore time?
[04:00] <wallyworld> i'm not sure. the private key i think needs to be paired with the cacert
[04:01] <axw> wallyworld: yeah, we would need to update that too.
[04:01] <thumper> davecheney: interesting...
[04:02] <wallyworld> axw: and a new admin secret would not be the end of the world i guess. but we do have all the info in the backup archive
[04:02] <wallyworld> so we'd really need to look to use that info if availab;e
[04:06] <axw> wallyworld: for a quick solution, I'd go with parsing agent.conf on restore. then we can look at improving.
[04:07] <axw> wallyworld: we also need to think about how we're going to persist user auth details to log back into the controller after restore, in lieu of an accounts.yaml that's valid with the creds at time of backup
[04:08] <axw> wallyworld: options are to store in the backup metadata, or to require the user to login. but these are things we could look into at the same time as the rest
[04:09] <wallyworld> ok, was thinking the same thing, also we only need this if we are rebootstrapping
[04:10] <axw> wallyworld: I can't make heads or tails of the SSH thing. the system key is added to authorized-keys at bootstrap, and I've confirmed they're in the hosted model config; and that is present in cloud-config when machines are started
[04:10] <axw> so there's no race AFAICT
[04:10] <wallyworld> fark
[04:10]  * axw disappears to make lunch
[05:28] <wallyworld> axw: i think adding admin-secret to bootstrap config is ok. it's used for the gui login having it accessible like that makes sense to me
[05:29] <axw> wallyworld: I don't understand why we need it there. it's already in accounts.yaml.
[05:29] <axw> wallyworld: admin-secret == password for admin@local
[05:29] <wallyworld> ah true
[05:30] <wallyworld> there's not a nice way that avoids yuk to get it server side, so i'll read from there for now
[05:30] <wallyworld> parsing the agent conf files client side is also no go
[05:30] <wallyworld> so i'll get that ingo srrver side and include with backup metadata
[05:31] <axw> wallyworld: why is it no go?
[05:32] <wallyworld> all the code to open the archive and extract the files is all server side. there's a lot of it. and there's no guarantee what you'll get in terms of file names - it depends on machine id.
[05:32] <wallyworld> i'd have to refactor a lot of code
[05:32] <axw> wallyworld: ok
[05:33] <wallyworld> restore works by uploading the archive to state server and server side code does the work
[05:33] <wallyworld> so none of that code is client side
[05:34] <axw> wallyworld: ah, I think I figured out when the race could happen with authorized-keys. if you specify it explicitly in --config
[05:35] <axw> wallyworld: that'll go into hosted model config, whereas admin model's config will have the system's public key added
[05:35]  * axw works on a patch
[05:35] <wallyworld> ah i see
[05:35] <wallyworld> bbiab, school pickup
[06:10] <anastasiamac> axw: wallyworld: tag fixes for joyent http://reviews.vapour.ws/r/4282/
[06:23] <axw> anastasiamac: is there some significance to the "tag." prefix?
[06:23] <axw> anastasiamac: do we need to add that to the prepopulated tags?
[06:23] <anastasiamac> axw: I am fixing the broken code. what ever was there or whatever it was copied from, i've kept
[06:24] <anastasiamac> axw: but i would have to say that probably not..
[06:24] <axw> anastasiamac: I guess if you tested and it worked, there's no significance. alrighty
[06:26] <axw> anastasiamac: LGTM, thanks
[06:27] <anastasiamac> axw: thnx. I'll re-google tag names in joyent but m pretty it's an arbitrary prefix :D
[06:48] <mup> Bug #1560331 opened: juju-br0 fails to be up when no gateway is set on interface <juju-core:New> <https://launchpad.net/bugs/1560331>
[07:12] <jam> axw: are you around for a bit? I'd like to figure out what we need for storage and LXD containers
[07:13] <jam> especially for normal deployments (maas/ec2) but also for LXD provider.
[07:22] <axw> jam: sorry, didn't see notification - not on usual machine (desktop's on the fritz)
[07:22] <axw> jam: still around for a while
[07:23] <jam> axw: so the LXC code has something about passing through the loop device
[07:23] <jam> and I need to know what we actually use, and how we need to do that with LXD
[07:23] <jam> AIUI if we want a device, then we talk directly to LXD and ask it to pass a device through (might need to be in the lxd profile, I need to investigate that side)
[07:24] <jam> axw: but I'd like to know what we're using and how I can measure that I've done it correctly.
[07:25] <axw> jam: the existing LXC storage code wasn't great. it was simply allowing access to all loop devices to all containers
[07:25] <jam> axw: who was creating the loop device to then pass in?
[07:25] <axw> jam: the container does it internally. they have access to the /dev/loopX files
[07:26] <axw> jam: (it would be much better if the host passed it in)
[07:27] <jam> axw: but who on the outside would create the fil to then mount?
[07:27] <jam> you'd ask the container broker ?
[07:28] <axw> jam: there's several places where we can create storage: dynamically on the machine (e.g. loop); dynamically on the controller (e.g. ebs); at machine provisioning time (e.g. maas)
[07:28] <axw> jam: the last one might fit with creating in the container broker
[07:29] <axw> jam: but it would be nice if there's some way we could do it dynamically through the LXD API
[07:34] <jam> axw: LXD would let us pass the device through (supposedly), but it wouldn't do the mkfs, etc. stuff
[07:35] <jam> I don't believe
[07:40] <axw> jam: all we need is a device. juju will create filesystems as necessary
[07:40] <axw> jam: does LXD have an API for allocating block devices? I don't see it in the REST API doc, but that may just be outdated
[07:41] <axw> wallyworld: https://github.com/juju/juju/pull/4844
[07:41] <wallyworld> looking
[07:44] <wallyworld> axw: what if the user has explictly set their auth keys for the hosted model
[07:45] <axw> wallyworld: how?
[07:45] <wallyworld> ah, i was thinking we had a capability for host model config on cli
[07:45] <axw> wallyworld: you can only specify the config for both admin and hosted model
[07:46] <wallyworld> one day we should add that separate host model config perhaps
[07:46] <wallyworld> axw: lgtm
[08:05] <wallyworld> axw: off to soccer, restore tests are a bitch, need to refactor a bit, will finish when i get back and hopefully land tonight
[08:05] <axw> wallyworld: okey dokey
[08:06] <wallyworld> axw: i'm so not happy with the solution, but there's little other option right now
[08:06] <wallyworld> that we can do quickly
[08:09] <axw> jam: so thinking about it a bit more, if we were to pass disks through to the containers, I think we'd need to do that in two places: an environment-level storage provider for the lxd provider; and a machine-level storage provider for lxd-type containers
[08:10] <axw> jam: for hte latter, we'd need to update machine-level storage to manage disks for containers as well as disks for the machine itself
[08:11] <axw> jam: AFAICT there's no help from LXD for dynamically allocating volumes from ZFS or BTRS for use in containers (apart from root volume), which would be ideal
[08:11] <axw> at worst we could do what we were doing with LXC: open up loop devices to all containers and let them have at them. not ideal tho
[08:12] <axw> jam: I'd prefer if we could allocate any volumes the host supports to containers, though
[08:26] <TheMue> aaargh, building a shell script generating a shell script but then doing wrong escaping. wonderful, costed me some time.
[08:27] <TheMue> morning btw
[09:30] <mup> Bug #1560391 opened: apt-mirror is not used in containers with MAAS provider <juju-core:New> <https://launchpad.net/bugs/1560391>
[09:48] <fwereade> don't suppose anyone who did backup/restore work is online?
[09:51] <fwereade> because apparently I have perpetrated lp:1559712 and I need a bit of context about why this is an error
[09:52] <fwereade> perrito666, ericsnow perhaps? ^
[09:54] <perrito666> Well i am having breakfast and chatting from a phone
[09:54] <perrito666> But shoot
[09:54] <perrito666> Fwereade^
[10:00] <perrito666> In short, prepare restore puts juju in a pseudo ro mode for that iirc, it writes info in mongo so I presume that is what is failing hence the transaction aborted
[10:02] <voidspace> dooferlad: standup?
[10:09] <perrito666> Fwereade gtg need to take my wife to work + not feeling so well
[10:31] <mup> Bug #1560428 opened: cmd/juju/common depends on gopkg/check.v1 <juju-core:New> <https://launchpad.net/bugs/1560428>
[10:43] <mup> Bug #1560428 changed: cmd/juju/common depends on gopkg/check.v1 <juju-core:New> <https://launchpad.net/bugs/1560428>
[10:46] <fwereade> perrito666, np, let me know if/when you're available
[10:46] <fwereade> again :)
[10:49] <mup> Bug #1560428 opened: cmd/juju/common depends on gopkg/check.v1 <juju-core:New> <https://launchpad.net/bugs/1560428>
[11:41] <dimitern> fwereade, davecheney, FYI - updated the pprof wiki page with instructions how to access it from a browser
[11:41] <dimitern> awesome tool btw
[11:41] <dimitern> https://github.com/juju/juju/wiki/pprof-facility
[12:13] <mup> Bug #1560457 opened: help text for juju bootstrap needs improving <juju-core:New> <https://launchpad.net/bugs/1560457>
[12:25] <wallyworld> axw: not sure if you have a moment to look at http://reviews.vapour.ws/r/4287/
[12:26] <wallyworld> axw: you may need to hold your nose, but we need to re-write backup/restore somewhat for multi-model
[12:30] <rick_h_> wallyworld: hold on that though. I want to talk through that and what's in 2.0 vs 2.1 and how we go about that please
[12:30] <wallyworld> rick_h_: oh, no fear, we have no much for anything right now :-)
[12:31] <wallyworld> s/much/time
[12:31] <rick_h_> wallyworld: k
[12:32] <wallyworld> rick_h_: what we need to do to get 2.0 out the door given how the cloud credentials stuff now removes the need for storing an entire bootstrap config means that there's a few things we need to clean up for 2.1
[12:33] <rick_h_> wallyworld: rgr
[13:17] <marcoceppi> katco natefinch how does deploying a charm with resources local work?
[13:18] <marcoceppi> like, what's the command line work like?
[13:18] <marcoceppi> s/work/look/
[13:18] <natefinch> marcoceppi: yep
[13:18] <natefinch> marcoceppi: juju help deploy ;)
[13:19] <natefinch> marcoceppi: uju deploy foo --resource bar=/some/file.tgz --resource baz=./docs/cfg.xml
[13:19] <natefinch> marcoceppi: you just specify the resources you want to have uploaded when you deploy the charm.   You can do that for store resources too
[13:20] <marcoceppi> natefinch: I DON'T HAVE TIME FOR YOUR REASONABLE SUGGESTIONS
[13:20] <natefinch> marcoceppi: er, store charms that is
[13:20] <natefinch> marcoceppi: lol
[13:20] <marcoceppi> natefinch: yeah, but I'm waiting for charmstore update, etc
[13:20] <natefinch> marcoceppi: right, just wanted to clarify that it's not just for local charms
[13:20] <marcoceppi> natefinch: yeah, lookikng forward to that, but I've got a charm now with resources
[13:21] <marcoceppi> natefinch: I know there's a filename param, etc
[13:21] <marcoceppi> natefinch: and I remember that it's mostly ignored
[13:22] <natefinch> marcoceppi: the extension of the file you upload needs to match the extension of the filename in the charm metadata, it'll complain if you don't have them match
[13:22] <marcoceppi> natefinch: okay, one file is literally `python-jujusvg` with no ext
[13:22] <marcoceppi> what happens then?
[13:23] <marcoceppi> as in, it's just a binary
[13:23] <natefinch> marcoceppi: then we enforce that what you upload doesn't have an extension
[13:23] <marcoceppi> cool
[13:23] <marcoceppi> <3
[13:24] <natefinch> marcoceppi: yeah, the filename in the metadata is really just used for the extension for uploads, and its' what we store the file data as on the units... though since we return the full path from resource-get, it shouldn't matter too much to the charm itself
[13:24] <marcoceppi> natefinch: perfect, I remember that being shook out in capetown happy to see it implemented as such
[13:25] <natefinch> marcoceppi: yeah, I'm mostly really happy with how the feature turned out.  I think it'll be super useful.
[13:26] <marcoceppi> natefinch: a few days ago the instance containing svg.juju.solutions died, so I'm charming that up with resources. I'll let you know how it goes
[13:26] <natefinch> marcoceppi: cool cool.  Please let us know any pain points or other sharp edges
[13:43] <mup> Bug #1560487 opened: local provider fails to create lxc container from template <juju-core:New> <https://launchpad.net/bugs/1560487>
[13:45] <rogpeppe> does anyone know the difference between jujuclient.Controller.Servers and jujuclient.Controller.APIEndpoints ?
[13:46] <rogpeppe> it's a new type, so *presumably* they both have a role to play, but in my limited experimentation they both hold exactly the same thing.
[13:47] <rogpeppe> fwereade, dimitern, natefinch, axw, wallyworld: ^
[13:48] <natefinch> rogpeppe: no idea, I haven't used that package
[13:48] <rogpeppe> natefinch: np
[13:48] <wallyworld> rogpeppe: they mean the same as when used with the jenv stuff - servers are the host names, api endpoints the ip addresses
[13:48] <rogpeppe> wallyworld: what's the difference? both seem to contain host names and port numbers
[13:49] <rogpeppe> wallyworld: ah, you mean one has resolved IP addresss + port and the other has the equivalent hostnames ?
[13:49] <wallyworld> rogpeppe: as i understand it, if the hostnames are known they are used
[13:49] <wallyworld> yes
[13:49] <rogpeppe> wallyworld: that is *really* confusing!
[13:49] <rogpeppe> wallyworld: just the naming really
[13:49] <wallyworld> rogpeppe: that stuff goes back a looong time
[13:49] <natefinch> we're really bad at naming
[13:49] <rogpeppe> wallyworld: it's a new type!
[13:49] <wallyworld> which we ported
[13:49] <wallyworld> copied even
[13:49] <rogpeppe> wallyworld: hrmph
[13:50] <wallyworld> we didn't want to change the semantics
[13:50] <wallyworld> as people would have groked the meaning b now
[13:50] <rogpeppe> wallyworld: the semantics perhaps didn't need to change, but at least it could be documented that a) they both hold host:port pairs and b) one is resolved and the other isn't
[13:50] <natefinch> wallyworld: ...or not :)
[13:50] <wallyworld> rogpeppe: it was probaly around your time on juju when this was first done :-)
[13:51] <rogpeppe> wallyworld: i still can't work out which is resolved and which isn't
[13:51] <wallyworld> it's as documented now as it evr was
[13:51] <natefinch> wallyworld: you're just digging your hole deeper
[13:51] <wallyworld> why?
[13:51] <wallyworld> we can't change the world in a day
[13:51] <natefinch> wallyworld: if it's been the same for forever and it's been this well documented for forever, that just means it's bad and should be fixed.
[13:51] <rogpeppe> wallyworld: just about everything else has changed about that stuff
[13:52] <wallyworld> yes it should, let me get 25 hours in a day and i'll do it
[13:52] <rogpeppe> wallyworld: so i'd've thought that aspect could probably change too
[13:52] <wallyworld> not everything has changed, that bit hasn't :-)
[13:53] <rogpeppe> how is anyone meant to guess what the intended relationship between these two things?
[13:53] <rogpeppe> 	// Servers contains the addresses of hosts that form the Juju controller cluster.
[13:53] <rogpeppe> 	// APIEndpoints is the collection of API endpoints running in this controller.
[13:53] <rogpeppe> they sound very different from one another.
[13:53] <wallyworld> guess so, that doc was as we founf it
[13:53] <wallyworld> a lot of this stuff has been ported, not reimplemented
[13:54] <wallyworld> you don't need to understand everything to the nth degree if you are porting it
[13:54] <rogpeppe> wallyworld: it's actually got worse since the original, which was this: http://paste.ubuntu.com/15472129/
[13:55] <rogpeppe> wallyworld: that at least explained the situation
[13:55] <wallyworld> we should copy that doc back across
[13:55] <rogpeppe> wallyworld: +1
[13:57] <rogpeppe> wallyworld: BTW both the field names *and* the comments have changed from the original
[13:58] <wallyworld> yes, can't recall why now, may have been to comply with the spec we were given actually
[14:01] <katco> morning all
[14:01] <katco> wallyworld: evening o/
[14:01] <wallyworld> hi
[14:01] <katco> wallyworld: doing ok?
[14:01] <wallyworld> no, life sucks
[14:02] <cherylj> someone's not living the dream today :/
[14:02] <katco> wallyworld: understandable atm... but the sun will rise on a better day :)
[14:02]  * wallyworld is grumpy
[14:02] <katco> wallyworld: anything i can do to help?
[14:02] <wallyworld> wave a magic wand and solve all the merge conflicts and test failures
[14:02] <rogpeppe> wallyworld: sorry if i excacerbated the situation :)
[14:02] <wallyworld> rogpeppe: np, i have copied the text across already
[14:02] <katco> wallyworld: i can work on merges today if you'd like
[14:02] <rogpeppe> wallyworld: thanks
[14:03] <rogpeppe> wallyworld: changing the names would be good too. Something like: APIEndpoints and ResolvedAPIEndpoints ?
[14:03] <wallyworld> katco: thanks, bu there's a lot of ingrained knowledge needed to resolve the conlficts
[14:03] <dooferlad> frobware: is there no maas call today?
[14:03] <wallyworld> rogpeppe: i'll see what we can do
[14:03] <katco> wallyworld: ok. well, lmk
[14:04] <wallyworld> will do
[14:04] <wallyworld> katco: you could review http://reviews.vapour.ws/r/4287/ - it's a temporary fix to get restore working, still a long way to go to fix it all properly
[14:04] <katco> wallyworld: tal
[14:05] <rogpeppe> wallyworld: thanks, that's appreciated
[14:06] <cherylj> rogpeppe: is your 070-use-charmstore-v5-api branch something we need to get into the beta this week?
[14:07] <rogpeppe> cherylj: no, sorry, it was a temporary hack to get a PR in a mutually dependent repo landed. I can delete it now.
[14:07] <cherylj> rogpeppe: ah, ok, thanks!
[14:08] <rogpeppe> cherylj: deleted
[14:08] <cherylj> thanks!
[14:09] <rogpeppe> cherylj: and BTW if you ever need to land something in a repository which both depends on an is depended on by juju-core, that's the way to do it and still have godeps work.
[14:09] <rogpeppe> s/on an is/on and is/
[14:09] <cherylj> good to know.  Thanks :)
[14:09] <ericsnow> rogpeppe: FYI, that merge went through on the first try :)
[14:09] <rogpeppe> ericsnow: yeah, i saw in the morning and was happy
[14:09] <ericsnow> :)
[14:10] <rogpeppe> ericsnow: thanks for keeping an eye on it
[14:10] <ericsnow> rogpeppe: np
[14:11] <katco> rogpeppe: hey thanks for working so hard to land that patch :) work continues i guess?
[14:11] <fwereade> katco, if you know backup: ISTM that creating a RestoreInfoSetter should not create a document; or, if it should, that it ought to handle concurrent creations of the same type
[14:11] <fwereade> katco, is there some synchronisation mechanism somewhere in restore that I've missed?
[14:11] <katco> fwereade: eh? is this regarding wallyworld's patch?
[14:12] <rogpeppe> katco: i'm leaving as is for the time being, as i have to make progress in other areas.
[14:12] <fwereade> katco, not at all I'm afraid
[14:12] <rogpeppe> katco: it should be sufficient for most purposes. there may be some bugs :)
[14:12] <katco> fwereade: ah. i don't know hardly anything about backup/restore i'm afraid :( but ericsnow and natefinch should
[14:12] <fwereade> katco, np, thanks
[14:13] <katco> fwereade: i'm reviewing a patch now, so maybe i'll become an expert in the next bit of time ;)
[14:13] <wallyworld> i don't recall doing anything with RestoreInfSetter in my patch?
[14:13] <rogpeppe> katco: hope that's ok. did you have any other particularly pressing things?
[14:13] <fwereade> ericsnow, natefinch: ^ ? (RestoreInfoSetter)
[14:13] <ericsnow> rogpeppe, katco: there are a few things left (like sending the channel through the AddCharm API endpoint)
[14:13] <fwereade> wallyworld, nothing to do with you
[14:13] <natefinch> perrito666: is Mr. Restore
[14:13] <rogpeppe> ericsnow: file a bug
[14:13] <ericsnow> fwereade: perrito666 did all the work on restore, though I did review much of the work
[14:13] <fwereade> wallyworld, my problem entirely :)
[14:13] <katco> rogpeppe: the only horse i have in that race is natefinch being able to determine what channel a charm was deployed from
[14:13] <wallyworld> \o/
[14:13] <ericsnow> rogpeppe: k
[14:14]  * katco head explodes from the different threads of convo
[14:14] <fwereade> perrito666, last I heard, was not feeling well
[14:14] <natefinch> gah.. people talk about sending channels around in go and I get all confused
[14:14] <ericsnow> fwereade: :(
[14:14] <fwereade> ericsnow, I will do my best and ping you for a review
[14:14] <ericsnow> fwereade: sounds good; thanks!
[14:15] <ericsnow> natefinch: ha
[14:15] <katco> ericsnow: ty
[14:15] <rogpeppe> katco: yeah, currently it'll probably always use stable.
[14:16] <perrito666> fwereade: I am back fully restored
[14:16] <perrito666> fwereade: how can I help you?
[14:16] <ericsnow> rogpeppe, katco: we still need to sort out the long-lived macaroon situation, but I don't think it's as urgent
[14:18] <tvansteenburgh> where can i find a list of all the valid Request types for each api facade?
[14:19] <ericsnow> tvansteenburgh: I don't believe that is cataloged anywhere, meaning you have to read through the facades code and apiserver/params/*.go
[14:20] <natefinch> tvansteenburgh: yeah, unfortunately, what ericsnow said.  We really should document all that stuff.
[14:20] <ericsnow> tvansteenburgh: godoc might help make it more manageable though
[14:20] <bogdanteleaga> do we have something like this for stderr? https://github.com/juju/cmd/blob/master/output.go#L157
[14:21] <tvansteenburgh> ericsnow, natefinch: ok, well if i know the name of the facade, where in the source should i go to find the Request types for it?
[14:21] <ericsnow> tvansteenburgh: all the API data types are lumped together in several files in apiserver/params.go
[14:22] <ericsnow> tvansteenburgh: so you have to see what types are in the API methods and then find them in those params files
[14:22] <fwereade> perrito666, so the heart of it is that creating a RestoreInfoSetter will sometimes fail
[14:23] <perrito666> it being the bug you mentioned early today?
[14:23] <fwereade> perrito666, which is presumably happening now because of timing changes in my branch
[14:23] <fwereade> perrito666, yeah
[14:23] <fwereade> perrito666, and I am worried that just fixing the current symptom is going to leave us unstable all the same
[14:24] <perrito666> fwereade: see priv msg
[14:28] <dimitern> wallyworld, ping
[14:28] <wallyworld> yo
[14:28] <dimitern> hey, I've found a storage issue with bootstrapping on maas now
[14:28] <dimitern> http://paste.ubuntu.com/15472360/
[14:29] <dimitern> looks like related to removing provider storage ?
[14:29] <tvansteenburgh> ericsnow: i don't see a apiserver/params.go?
[14:30] <ericsnow> tvansteenburgh: apiserver/params/params.go
[14:30] <ericsnow> (in core)
[14:31] <wallyworld> dimitern: maas still has provider storage
[14:31] <wallyworld> it can't use tags the same way as the other providers, so we still need ito
[14:32] <wallyworld> are you referring to this line? DEBUG juju.provider.common state.go:36 putting "provider-state" to bootstrap storage *maas.maasStorage
[14:32] <dimitern> wallyworld, nope - it fails like joyent - see the paste above - just after it connected once client logins were unblocked
[14:33] <perrito666> dimitern: didnt remove storage in maas
[14:33] <perrito666> oh wallyworld said that already
[14:33] <wallyworld> dimitern: so why do you think it's a storage issue?
[14:33] <dimitern> oh :/ I was hoping it was something known.. I'll keep digging
[14:34] <wallyworld> dimitern: cherylj had a tgeory
[14:34] <wallyworld> theory
[14:34] <wallyworld> can't recall exactly what now
[14:34] <dimitern> wallyworld, joyent precise jobs failed very similarly and intermittently and it was due to missing tags
[14:34]  * cherylj reads backscroll
[14:34] <perrito666> dimitern: joyent iirc, was a porblem with tags not being populated as fast as they where requested
[14:35] <cherylj> perrito666 - the problem with joyent was that they were not setting tags passed in as StartInstance args
[14:35] <perrito666> ah, I got it wrong then :)
[14:36] <cherylj> perrito666: no worries, I didn't discover that until adding in the logic to retry the api connection in bootstrap if the error was "not bootstrapped"
[14:36] <cherylj> I saw that even after several minutes, we never got tagged instances
[14:36] <cherylj> so, I had to look elsewhere :)
[14:36] <dimitern> perrito666, cherylj, wallyworld, false alarm, I found out why it fails - not related to storage
[14:37] <cherylj> dimitern: ah, good :)
[14:40] <mup> Bug #1560511 opened: The AddCharmWithAuthorization API endpoint needs to respect channels. <juju-core:New> <https://launchpad.net/bugs/1560511>
[14:52] <mup> Bug #1560520 opened: Charm channels must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560520>
[15:01] <mup> Bug #1560520 changed: Charm channels must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560520>
[15:10] <mup> Bug # opened: 1560520, 1560525, 1560527, 1560531
[15:13] <mup> Bug #1560525 changed: Juju 2.0-beta3 stabilization  <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1560525>
[15:14] <mup> Bug #1560527 changed: juju get should be able to take a key argument <juju-core:New> <https://launchpad.net/bugs/1560527>
[15:14] <mup> Bug #1560531 changed: Charm store macaroons must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560531>
[15:23] <mup> Bug #1560525 opened: Juju 2.0-beta3 stabilization  <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1560525>
[15:23] <mup> Bug #1560527 opened: juju get should be able to take a key argument <juju-core:New> <https://launchpad.net/bugs/1560527>
[15:23] <mup> Bug #1560531 opened: Charm store macaroons must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560531>
[15:41] <redir> morning
[15:43] <perrito666> morning redir
[15:50] <redir> feeling better perrito666 ?
[15:50] <perrito666> redir: much, thank you
[15:51] <redir> good good
[15:51] <perrito666> redir: did you get your mail and other stuff?
[15:53] <dimitern> dooferlad, ping
[15:53] <dooferlad> dimitern: pong
[15:55] <dimitern> dooferlad, hey, I wasn't sure you're around today
[15:55] <dimitern> dooferlad, meet babbageclunk - Christian
[15:56] <dooferlad> dimitern: I am, but was at the hospital this morning for a scan (baby #2)
[15:56] <dooferlad> hello babbageclunk!
[15:56] <dimitern> I see, ok
[15:57]  * dimitern needs to go out, but will be back later
[16:01] <TheMue> dooferlad: baby #2?
[16:01] <dooferlad> TheMue: yep :-)
[16:02] <TheMue> dooferlad: great news, grats
[16:02] <dooferlad> TheMue: due early August.
[16:02] <dooferlad> TheMue: Thanks!
[16:04] <TheMue> dooferlad: so enough time left for the preparation. ours maybe both will have left home by end of year, depends on universities
[16:04] <dooferlad> TheMue: ah, happy and sad at the same time.
[16:05] <TheMue> dooferlad: exactly, but it makes proud to see how they grow up.
[16:05] <redir> perrito666: not yet
[16:05] <TheMue> dooferlad: hehe, and we already think about downsizing the house, when we don't need so much room anymore
[16:06] <TheMue> dooferlad: means selling the big one and buy a new, smaller, and more modern one
[16:07] <dooferlad> TheMue: heh, for me the only larger thing we may buy is a car!
[16:09] <TheMue> dooferlad: here wel already changed to a smaller one (but with a little more luxary). the large station wagon soon hasn't been needed anymore
[16:13] <cherylj> frankban: ping?
[16:13] <frankban> cherylj: on call, will ping you asap
[16:14] <cherylj> k, thanks!
[16:16] <ericsnow> redir: did you get onto ReviewBoard yet?
[16:18] <voidspace> alexisb: ping
[16:20] <redir> ericsnow: I don't beleive so.
[16:21] <redir> ianb said he'd work on it.
[16:21] <redir> going to listen to the people and culture orientation thing in a minute
[16:22] <redir> Then I'll ping alexisb about the paperwork stuff.
[16:22] <ericsnow> redir: go to http://reviews.vapour.ws/ and click on the github button
[16:22] <ericsnow> redir: see https://github.com/juju/juju/blob/master/CONTRIBUTING.md#code-review
[16:22] <redir> ericsnow: to be sure, would I receive and email re: reviewboard?
[16:22] <redir> ericsnow: will do
[16:23] <ericsnow> redir: also see https://github.com/juju/juju/blob/master/doc/contributions/reviewboard.md
[16:24] <redir> ericsnow: great thanks
[16:25] <ericsnow> redir: np
[16:31] <cherylj> ericsnow: for bug 1560531 and bug 1560520, are these blockers for the next beta?
[16:32] <mup> Bug #1560531: Charm store macaroons must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560531>
[16:32] <mup> Bug #1560520: Charm channels must be used on the controller. <juju-core:New> <https://launchpad.net/bugs/1560520>
[16:32] <ericsnow> cherylj: they prevent the correct behavior when folks use channels, so I'd say so
[16:33] <ericsnow> cherylj: rick_h_ could probably say more; and I know it's on urulama's radar
[16:34] <ericsnow> cherylj: oh, and regarding the macaroons one, I'm not sure but I'd be inclined to call it a blocker too
[16:34] <rick_h_> ericsnow: didn't we say for the beta we'd get the initial deploy in and come back with follow ups to fix the bugs in that behavior after deploy?
[16:34] <ericsnow> cherylj: it will keep private charms from doing the right thing or using resources
[16:35] <ericsnow> rick_h_: the initial deploy stuff isn't finished relative to channels
[16:35] <ericsnow> rick_h_: basically just the --channel flag is added
[16:36] <rick_h_> ericsnow: ok, and it won't deploy the right one when used?
[16:36] <ericsnow> rick_h_: right; it will always use stable
[16:36] <ericsnow> currently
[16:37] <rick_h_> ericsnow: oh...then boooo
[16:37] <ericsnow> cherylj: and by "next beta" you mean the one after the one we're wrapping up this week, right?
[16:37] <redir> :)
[16:37] <cherylj> ericsnow: we're still trying to wrap up the one for this week
[16:38] <ericsnow> cherylj: those bugs just need to be in the final release, however that works out
[16:38] <cherylj> okay, thanks
[16:38] <ericsnow> cherylj: I do not anticipate they will be resolved this week
[16:38] <cherylj> ericsnow: cool, thanks
[16:38] <ericsnow> cherylj: np
[16:46] <katco> cherylj: best to talk to urulama for status/eta
[16:47] <urulama> otp
[16:48] <voidspace> alexisb: meet babbageclunk :-)
[16:48] <alexisb> babbageclunk, heya man, welcome!
[16:49] <babbageclunk> alexisb: hi!
[16:49] <babbageclunk> Thanks!
[16:50] <frankban> cherylj: ping
[16:51] <urulama> katco, cherylj, ericsnow: yes, that's not a full implementation, but it's also not so problematic as you've described. once you have a fully qualified url from the channel pointer, the logic to resolve ACL should allow you to deploy it, not just stable one
[16:51] <urulama> so, i'd like to have a QA performed when this actually brakes
[16:51] <urulama> it's a bug as in not fully implemented, but it might not be critical
[16:51] <alexisb> frankban, I a m pestering cherylj so her responses will be slow
[16:52] <frankban> alexisb: np
[16:52] <ericsnow> urulama: thanks for clarifying
[16:53] <urulama> so, the plan is to test it and in case it's critical, we'll work in it tomorrow
[16:53] <ericsnow> urulama: how can the store determine the channel from the charm URL?
[16:53] <urulama> today is eod for eu
[16:53] <ericsnow> (resolved URL)
[16:54] <urulama> ericsnow: so, the case when this will brake is when stable channel has more rights than development channel.
[16:55] <urulama> ericsnow: so, you'd get a resolved url, then the CS logic check if you can deploy it from stable first, then from development, then unpublished
[16:55] <urulama> ericsnow: if you have access to stable but not development, then you can deploy it
[16:55] <ericsnow> urulama: in the case the user specified explicitly the channel they want
[16:55] <katco> urulama: that doesn't seem quite right... what if the charm was deployed from development to begin with?
[16:55] <urulama> ericsnow: but the revision is the same
[16:55] <ericsnow> urulama: right
[16:56] <urulama> i said it's not filly implemented
[16:56] <urulama> it's just not as critical to be a blocker
[16:56] <katco> urulama: ah ok, that's the edge-case
[16:56] <ericsnow> urulama: k
[16:56] <urulama> well, unless someone else call it a blocker :)
[16:56] <katco> urulama: i don't think we should implement the fallback algo. you described while we wait for full implementation
[16:57] <katco> urulama: it's just a guess at a path that may or may not be correct
[16:57] <rick_h_> right, it's a feature in a beta. It can not work properly in the beta
[16:57] <rick_h_> katco: urulama ^
[16:57] <urulama> katco: that's already in the charmstore ... once the channel is passed to addcharm, everything will be ok
[16:57] <ericsnow> katco: for download all we need is the resolved URL, which is the same for the different channels
[16:57] <urulama> ericsnow: yes
[16:58] <katco> ericsnow: how does that account for resources?
[16:58] <ericsnow> katco: so the edge case is that the requested channel doesn't actually have that revision, but that is checked when we resolved the URL
[16:58] <ericsnow> urulama: I think I get it now
[16:58] <ericsnow> katco: for resources we still need the channel
[16:59] <katco> rick_h_: understood... i'm just trying to connect urulama with cherylj/you so the right calls can be made. again, my team does not have a horse in this race.
[16:59] <rick_h_> katco: rgr
[17:00] <katco> rick_h_: in fact, i would encourage direct communication b/t those parties :)
[17:01] <katco> ericsnow: we are just adding confusion. let's remove ourselves from the conversation going forward
[17:02] <urulama> cherylj: seems we need to talk ... gimme an hour of my so called life, will be back later :)
[17:02] <cherylj> pfft...  "life"
[17:03] <cherylj> isn't this job your life?!
[17:04] <urulama> it is :)
[17:05] <urulama> cherylj: so, in 1h ... is that ok for you?
[17:05] <cherylj> urulama: yeah, I'll be here :)
[17:05] <cherylj> just ping me
[17:06] <urulama> ok, i do want to verify this, tbh, fell more at ease with proper QA then a bunch of guesses :)
[17:07] <katco> ericsnow: have you looked at natefinch 's http://reviews.vapour.ws/r/4269 ?
[17:09] <ericsnow> katco: I reviewed it yesterday but haven't looked since
[17:09] <ericsnow> katco: will take a look
[17:09] <katco> ericsnow: it seems like there's a lot of resources functionality that should live in the component? but unsure
[17:25] <cherylj> damn, I was just about to ping rogpeppe about breaking master!!
[17:26] <cherylj> anyone know why he would've removed github.com/gabriel-samfira/sys	 from dependencies.tsv?
[17:27] <cherylj> ericsnow: ^^  I see you reviewed the PR.  Any thoughts?
[17:27] <ericsnow> cherylj: I expect it was accidental
[17:28] <cherylj> ericsnow: okay, thanks.  Just wanted to sanity check before I add it back in
[17:28] <ericsnow> cherylj: np
[17:38]  * natefinch is back
[17:38] <katco> natefinch: wb
[17:38] <katco> natefinch: i was mentioning to ericsnow: for your patch, it looked like there was some resources functionality in there that maybe belonged in the component? but wasn't sure
[17:40] <katco> ericsnow: how hard would it be to keep http://reviews.vapour.ws/r/4272 going? i don't think we should land it before 2.0 because i don't want to be a huge source of conflicts for incoming branches
[17:41] <natefinch> katco: hmm... good question.
[17:42] <ericsnow> katco: what do you mean "keep it going"?
[17:42] <katco> ericsnow: keep the patch updated with changes as they come in
[17:43] <ericsnow> katco: as to conflicts, it would only be a problem for new HTTP endpoints, not new facades
[17:43] <ericsnow> katco: I doubt there will be much churn in that bit of code
[17:43] <katco> ericsnow: are you aware of any new endpoints coming in with the 2.0 feature branches?
[17:44] <ericsnow> katco: no, though I could image model migrations potentially having something
[17:44] <katco> ericsnow: alright... i suppose we can land this code if we can also assist in any merge conflicts
[17:45] <katco> natefinch: btw what are you working on now?
[17:45] <ericsnow> katco: k
[17:47] <redir> ericsnow: yes
[17:47] <natefinch> katco: I'd spent a little time trying to clean up my patch from last night, so there wasn't so much duplication and unnecessary levels of abstraction... but that's not super pressing right now.  I was going to ask what I should do next.
[17:47] <redir> whoops, was scrolled. nm ericsnow
[17:47] <ericsnow> redir: :)
[17:49] <katco> natefinch: for now focus on reviews to unblock ericsnow
[17:49] <natefinch> katco: happy to
[17:49] <katco> natefinch: i'm peeking at the backlog, but open to any pets you or ericsnow feel need addressing
[17:50] <ericsnow> katco: we do need to sort out the long-lived macaroon issue in the relative "soon" timeframe
[17:51] <katco> ericsnow: meaning before the apr. 8th deadline?
[17:51] <natefinch> katco, ericsnow: do we clean up old resources when we remove a service?
[17:51] <katco> natefinch: i think ericsnow landed that patch
[17:51] <ericsnow> natefinch: yep
[17:51] <katco> natefinch: we took care of all the critical bugs
[17:52] <natefinch> cool... I thought I remembered that, but just wanted to make sure
[17:52] <katco> natefinch: so now we're onto uh... "bothersome"? bugs? and charmstore implementation
[17:52] <katco> natefinch: but we should take the rest of the iteration to just do bugs and stay agile for the release
[17:52] <ericsnow> katco: the macaroon issue will keep private charms from working with resources
[17:52] <natefinch> katco" I think there's some gap between the channel work that roger did and what I did, I'd have to look to know for sure.
[17:53] <ericsnow> natefinch: FYI, I'm reviewing your patch right now
[17:53] <katco> natefinch: there is, and will that will remain until they have a full implementation up. nothing to do for now.
[17:53] <katco> ericsnow: natefinch: so sounds like the long-lived macaroon should come next. i'll start drafting that email
[17:54] <natefinch> ericsnow: yeah, I'm interested to hear your thoughts... looking at it with fresh eyes this morning, I think there's a bunch of cleanup I could do to avoid duplicate abstraction
[17:54] <natefinch> katco: cool
[17:54] <ericsnow> natefinch: yeah, I'm jotting down my thoughts right now :)
[17:55] <natefinch> ericsnow: I think we can collapse Client and BaseClient and just have my clientWrapper interface to abstract away the ugly details of csclient.Client and the charmstore repo dance.
[17:56] <natefinch> ericsnow: but I may be missing some externalities that you were taking into consideration
[17:56] <mup> Bug #1560593 opened: debian lintian reports mis-spellings <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1560593>
[17:56] <mup> Bug #1560595 opened: help text for juju show-cloud needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1560595>
[17:56] <ericsnow> natefinch: baseClient *is* that wrapper
[17:57] <ericsnow> natefinch: baseClient and Client represent different things
[17:57] <natefinch> ericsnow: except with my code, there's a lot more logic inside baseClient than basically anywhere else in the file
[17:57] <natefinch> ericsnow: maybe that was just me putting the logic in the wrong layer, though
[17:58] <ericsnow> natefinch: it's partly a consequence of not having that logic living under the charmrepo repo
[17:58] <ericsnow> natefinch: and of dealing with the way channels are handled in csclient.Client
[17:59] <natefinch> ericsnow: right.. so we need our own wrapper to make using csclient/charmrepo less awful
[18:00] <ericsnow> natefinch: and that's what baseClient is for
[18:00] <natefinch> ericsnow: but that's really the point of the entire package, so why do we need Client?
[18:02] <ericsnow> natefinch: let me finish my review and we can discuss it some more
[18:02] <natefinch> ericsnow: sure :)  Sorry :)
[18:06] <redir> what's JFDI?
[18:06] <cherylj> redir: it's a keyword that lets you try to merge changes into a branch, even if it's blocked by a bug
[18:06] <redir> just do it. got it, tx
[18:07] <cherylj> redir: you can see if branches are blocked here:  http://juju.fail/index.html
[18:11] <redir> marked, thanks
[18:12] <cherylj> hey rogpeppe, was there a reason https://github.com/juju/juju/pull/4807/ removed github.com/gabriel-samfira/sys from dependencies.tsv?  or was it an accident?
[18:12] <rogpeppe> cherylj: oh bother
[18:12] <rogpeppe> cherylj: i forgot to do GOOS=windows godeps.
[18:13] <cherylj> so accident, then :)
[18:13] <rogpeppe> cherylj: yes
[18:13] <rogpeppe> cherylj: oops
[18:13] <cherylj> rogpeppe: http://reviews.vapour.ws/r/4299/
[18:14] <rogpeppe> cherylj: reviewed
[18:14] <rogpeppe> cherylj: sorry for the inconvenience
[18:14] <cherylj> rogpeppe: it happens :)  You were up rather late getting these things in
[18:15] <rogpeppe> cherylj: no excuse though :)
[18:15] <natefinch> rogpeppe: we should import _ "github.com/gabriel-samfira/sys/unix" somewhere just to avoid that
[18:16] <rogpeppe> natefinch: godeps should be better about tagged imports.
[18:17] <natefinch> rogpeppe: if only we had a good relation with its author ;)
[18:17] <cherylj> heh
[18:17] <ericsnow> natefinch: my review is up
[18:17] <rogpeppe> natefinch: how would that help?
[18:18] <ericsnow> natefinch: as to merging baseClient and Client, baseClient is a wrapper around csclient.Client
[18:18] <natefinch> ericsnow: but isn't that what Client is, too?
[18:18] <ericsnow> natefinch: and Client is a wrapper around BaseClient, thus keeping a tighter control on what functionality we depend on in Juju
[18:19] <mgz> rogpeppe: you already looked at the build issues with your charmv5 api branch right?
[18:19] <ericsnow> natefinch: Client also provides some Juju-specific functionality
[18:19] <rogpeppe> mgz: yeah, cherylj pointed out that I'd mucked up the deps
[18:19] <natefinch> ericsnow: if it lives under github.com/juju/juju, it's all juju-specific
[18:19] <ericsnow> natefinch: whereas baseClient adapts csclient.Client (and charmrepo.CharmStore) to a more sensible API
[18:19] <rogpeppe> mgz: i'm hoping that's the only issue
[18:20] <arosales> aside from 'kill-contoller' any folks have any hints on how to reclaim and juju 2.0 environment?
[18:20]  * arosales stuck in this loop http://paste.ubuntu.com/15473933/
[18:20] <cherylj> arosales: you gotta manually delete the info from the cache.yaml
[18:20] <cherylj> I've been doing that all week :/
[18:21] <arosales> cherylj: ah, ok thanks
[18:21] <cherylj> we should totally fix that for beta3
[18:21] <mgz> rogpeppe: oh, so you've not looked at reports.vapour.ws/releases/3799 directly?
[18:21] <rogpeppe> mgz: nope
[18:21] <mgz> rogpeppe: not sure the other build problems all come from windows dep
[18:21] <rogpeppe> mgz: I'm eod
[18:21] <cherylj> mgz: that was a temporary branch that rogpeppe already deleted
[18:21] <ericsnow> natefinch: there are many things in the core repo that aren't Juju-specific, but no one has taken the time to pull them out
[18:21] <cherylj> I pinged him about it this morning :)
[18:22] <mgz> cherylj: okay, all I want to know is if I need to report bugs, sounds like not?
[18:22] <cherylj> mgz: no, not for that branch
[18:22] <cherylj> mgz: and for the windows build failure on master, I've already submitted a fix for dependencies.tsv
[18:22] <mgz> excellent
[18:22] <rogpeppe> mgz: sorry, we needed a temporary branch to make godeps work in another repo with a circular dependency with juju-core
[18:22] <rogpeppe> mgz: see mattyw for details
[18:23] <mgz> ah, but didn't actually want it tested?
[18:23] <ericsnow> natefinch: ideally baseClient would go away and we'd use csclient.Client (or some external surrogate) directly
[18:23]  * rogpeppe thinks that "base" is an insidious qualifier for any name.
[18:24] <mattyw> mgz, yeah, we have some horrific circular dependency thing going on :(
[18:24] <arosales> cherylj: safe to just rm ~/.local/share/juju/models/cache.yaml and start anew?
[18:24] <ericsnow> rogpeppe: it's a base class <wink>
[18:24] <cherylj> arosales: as long as you don't have any other controllers you need to talk to
[18:24] <natefinch> rogpeppe: +1
[18:24] <arosales> cherylj: nope
[18:25] <natefinch> ericsnow: blech
[18:25] <natefinch> ericsnow: (re: base classes)
[18:25] <cherylj> arosales: you may also need to clean up ~/.local/share/juju/controllers.yaml
[18:25] <ericsnow> natefinch: lol
[18:25] <arosales> cherylj: ok, thanks for the the help.
[18:25] <cherylj> np, I'll see if we can get that bug fixed on beta3
[18:25] <cherylj> too many people are hitting it
[18:26] <mgz> mattyw: you can probably push the rev to the repo without actually creating a branch
[18:27] <mgz> then reference the rev directly
[18:27] <mgz> this is all rather corner-casey though
[18:27] <mgz> you could also ask someone in CI to blacklist a branch you don't want tested
[18:29] <natefinch> katco, ericsnow: so about the problem with GetResource not having all the data... can we just have the charmstore return the rest of the metadata?  The only things it's missing is Origin, Type, and Description, which seem like a trivial amount of data to return along with the bytes themselves.
[18:30] <ericsnow> natefinch: the charm store client is supposed to be returning that info (see https://docs.google.com/document/d/1T_7XQ-pmE4gFiD2SSaZnQUqlcLkA7dk0c0PB_ebEkrI)
[18:36] <natefinch> ericsnow: ok, we need to adjust GetResource on csclient.Client, then
[18:40] <natefinch> ericsnow: are we doing a multipart body, or dumping the extra data into headers?  Right now there's a header for revision and hash, we'd need additional headers for type, path, description, and origin.
[18:41] <natefinch> ericsnow: (I presume the latter, since we haven't dealt with multipart bodies anywhere else yet)
[18:41] <katco> natefinch: i would do headers as the metadata is metadata about what's in the body
[18:41] <ericsnow> natefinch: origin is strictly inferred and the fingerprint should be in a header
[18:42] <ericsnow> natefinch: the type, path, and description come from the charm metadata, which may or may not help depending on our use of charmrepo.CharmStore
[18:43] <natefinch> ericsnow: current use does not make that helpful.  It seems like it makes the API friendlier if we just return all the metadata along with the bytes, given that the payload is tiny compared to the bytes themselves.
[18:44] <ericsnow> natefinch: the correct way would be to use a multipart body, but it's a pain
[18:44] <natefinch> ericsnow: agreed on both points
[18:45] <ericsnow> natefinch: at least take a look to see how much work it would be to do a multipart body
[18:46] <natefinch> ericsnow: there is a library for it... I'll have to check how much of it exists in 1.2, though
[18:47] <ericsnow> natefinch: well, we did multi-part for backups with 1.2, so...
[18:56] <mup> Bug #1560618 opened: Cloud types are unknown <docteam> <juju-core:New> <https://launchpad.net/bugs/1560618>
[19:08] <mup> Bug #1560624 opened: cmd supercommand.go:448 failed to bootstrap model: no matching tools available <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1560624>
[19:10]  * thumper goes to find the cat, another trip to the vet for us, yay
[19:31] <natefinch> ericsnow: so, multipart seems fine, I'll get that adjusted, and then that'll fix the metadata problem for that PR
[19:31] <ericsnow> natefinch: sweet
[19:34] <TheMue> thumper: oh, hope not too bad.
[19:34]  * TheMue loves cats
[19:39] <thumper> TheMue: she has diabetes, and we are getting the insulin levels checked
[19:40] <natefinch> ericsnow: I'm just going to assume the first part is the metadata and the second is the bytes... that seem reasonable?
[19:40] <ericsnow> natefinch: yep
[19:41] <natefinch> ericsnow: so much cleaner and nicer this way.
[19:41] <TheMue> thumper: oh, possible for cats too? our last one sadly had troubles with his kidneys. leaving us after being a family member for more than 14 years.
[19:41] <ericsnow> natefinch: yep :)
[19:41] <thumper> TheMue: yeah, was a surprise to us too
[19:41] <thumper> only found out a month ago
[19:41] <thumper> hence the regular visits now
[19:42] <TheMue> thumper: so it's good they found it and you can take care for it
[19:42] <thumper> yeah
[19:42] <natefinch> my wife was a vet tech for a while, she says kidney problems and diabetes are super common for cats
[19:45] <TheMue> natefinch: about kidney problems we then learned too. so we're now more careful and try to detect troubles earlier
[19:45] <TheMue> natefinch: but our new cat, we've got it since some weeks now, already trains us. she owns us already. :D
[19:47] <natefinch> TheMue: :)  We're cat people, too.  We had one cat, and decided he needed a friend, so we went to the shelter to get one more cat... and came home with two more :D
[19:48] <TheMue> natefinch: *rofl* but you're not only cat people. when I see the pics of your zoo.
[19:50] <natefinch> TheMue: the goats and chickens are actually not much harder to take care of than the cats... we do have to trim the goats' hooves every 6 weeks, and clean out the chicken coop once a month or so... but otherwise it's just like cats, make sure they have food and water, and they're fine
[19:51] <TheMue> natefinch: I love it when I see your kids, ok, the girls, take care for them. and the junior surely soon will too
[19:52] <natefinch> rogpeppe: how important is it to print out the data in this error message? https://github.com/juju/charmrepo/blob/v2-unstable/csclient/csclient.go#L669   seems like we could use json.Decoder to parse directly off the reader, rather than copying into a buffer first
[19:53] <natefinch> TheMue: yeah, it's great having the animals for the kids, and they're fun for us too
[19:56] <TheMue> natefinch: can imagine. I've grown up on countryside with many animals around me. always have been great (ok, sometime much work *g*)
[20:06] <rogpeppe> natefinch: i've found those error messages extremely useful in the past
[20:07] <rogpeppe> natefinch: particularly when the problem comes from a proxy not the service itself
[20:08] <mup> Bug #1560665 opened: help text for juju status needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1560665>
[20:08] <mup> Bug #1560667 opened: help text for juju list-clouds needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1560667>
[20:10] <natefinch> rogpeppe: fair enough... was trying to avoid reading the full data into memory is all
[20:39] <alexisb> wallyworld, thumper, fearless juju managers, when you have a moment I would like to steal you guys
[20:40] <thumper> alexisb: when and for what?
[20:40] <TheMue> hehe, stealing
[20:40] <alexisb> review priorities as we get down to the wire
[20:40] <alexisb> thumper, I am flexible
[20:41] <alexisb> I can put something on the calendar for this afternoon if that is easier
[20:41] <katco> alexisb: fearless juju managers are now only wallyworld & thumper, yeah?
[20:41] <alexisb> katco, yep
[20:41] <alexisb> feel free to crash but I only need them, lucky souls
[20:41] <katco> :)
[20:43]  * TheMue continues to extend his tomb-alike loop to allow also hierarchically monitored and restarted goroutines
[20:44] <alexisb> thumper, I am going to send an invite, let me know if the time doesnt work for you
[21:02] <alexisb> cherylj, ping
[21:02] <natefinch> ericsnow: standup?
[21:03] <cherylj> alexisb: wrapping up a meeting now
[21:03] <natefinch> wallyworld: you up?
[21:03] <ericsnow> natefinch: coming
[21:03] <wallyworld> natefinch: have a meeting clash :-(
[21:38] <thumper> alexisb: I can tell when I'm not wanted ;-|
[21:38] <alexisb> :)
[21:39] <thumper> http://reviews.vapour.ws/r/4300/
[21:39] <thumper> menn0: ^^ trade for yours
[21:39] <menn0> thumper: looking
[21:41] <menn0> thumper: done
[22:08] <urulama> katco, ericsnow: just verified and was able to deploy a development charm from charm store
[22:08] <urulama> with --channel development
[22:09] <urulama> wallyworld: ping you around
[22:10] <wallyworld> urulama: i am, just finishing a meeting
[22:10] <urulama> np, i'll wait
[22:11] <wallyworld> won't be long
[22:25] <urulama> wallyworld: forgot we have sync in a few hours ... in between, take a look at these https://pastebin.canonical.com/152562/ https://pastebin.canonical.com/152560/ ... last one is multiseries charm
[22:25] <wallyworld> urulama: looking in 30 seconds
[22:26] <cherylj> well this is exciting:  "go1: internal compiler error: in fold_binary_loc, at fold-const.c:10124"
[22:29] <mgz> cherylj: yeah, I didn't get as far as filing a bug for that but filled in the issue
[22:29] <cherylj> I suspect the answer is going to be "use go 1.6"
[22:29] <cherylj> mwhudson: how goes 1.6 in trusty?
[22:30] <mwhudson> cherylj: slangasek promised he'd look at it today
[22:30] <cherylj> cool
[22:30] <mwhudson> cherylj: is that on ppc64el, or some other platform?
[22:31] <cherylj> mwhudson: yes, ppc64el
[22:31] <cherylj> so, ppc64 seems to go okay, just ppc64el falls over
[22:33] <mwhudson> ppc64?
[22:35] <cherylj> mgz:  but the build-binary-trusty-ppc64el succeeded?
[22:35]  * cherylj is confused
[22:37] <mgz> cherylj: it may only be a tests compile issue
[22:37] <mgz> building binaries doesn't compile *_test.go
[22:37] <cherylj> ah
[22:37] <cherylj> ok
[23:14] <axw> wallyworld: sorry I was away from computer last night. have started reviewing, will finish after standup
[23:30] <mgz> cherylj: so, it's not test only, for some reason the way dpkg-buildpackage does the build just doesn't hit the issue
[23:30] <mgz> probably because it does itsybitsy steps and then links everything at the end
[23:30] <mgz> rather than doing go build .../...
[23:31] <mgz> but I can repo the failure building just that package in charmstore so nfc
[23:45] <mup> Bug #1560732 opened: Azure endpoint ACLs disappear after machine-0 restart <juju-core:New> <https://launchpad.net/bugs/1560732>
[23:51] <mup> Bug #1560732 changed: Azure endpoint ACLs disappear after machine-0 restart <juju-core:New> <https://launchpad.net/bugs/1560732>
[23:53] <mgz> welll this works as a fix...
[23:54] <mup> Bug #1560732 opened: Azure endpoint ACLs disappear after machine-0 restart <juju-core:New> <https://launchpad.net/bugs/1560732>