[00:03] <menn0> axw, thumper-dogwalk, wallyworld_, babbageclunk, anastasiamac: review please: https://github.com/juju/juju/pull/7050
[00:03] <menn0> axw, thumper-dogwalk, wallyworld_, babbageclunk, anastasiamac: this one is hairy enough that it probably needs 2 reviewers
[00:04] <wallyworld_> ok, will look soon, just finishing something
[00:13] <anastasiamac> menn0: m not able to review today. i trust u'd get reviews from others \o/
[00:13] <menn0> anastasiamac: thanks anyway :)
[00:16] <anastasiamac> menn0: no worries :0
=== thumper-dogwalk is now known as thumper
[00:29] <thumper> keep forgetting to reset that
[00:29] <thumper> menn0: I'm looking now
[00:29] <menn0> thumper: thank you
[00:33] <thumper> menn0: lgtm - you can await another if you choose
[00:34] <menn0> thumper: thanks. I think wallyworld_ offered to have a look too
[00:34] <wallyworld_> looking now
[00:37] <wallyworld_> menn0: at first glance, it seems not all occurrences of st.getCollection() have been ported across?
[00:40] <menn0> wallyworld_: that's right... I wasn't aiming to change everything to go via the Database
[00:41] <menn0> wallyworld_: just to get watchers and settings working with modelBackend instead of State
[00:41] <wallyworld_> ok
[00:41] <menn0> wallyworld_: I'm happy to do another PR which goes further
[00:41] <wallyworld_> no worries, just checking the scope
[00:41] <menn0> wallyworld_: I started doing that but it got huge and I didn't want to make this PR too hard to follow
[00:42]  * menn0 has to go
[00:42] <menn0> biab
[00:47] <wallyworld_> menn0: lgtm too. been wanting progess is ths area for a while, so is great
[01:17] <anastasiamac> babbageclunk: in menn0's absence, any advise on https://bugs.launchpad.net/juju/+bug/1668646?
[01:17] <mup> Bug #1668646: Model migration fails <juju:New> <https://launchpad.net/bugs/1668646>
[01:18] <babbageclunk> anastasiamac: looking
[01:21] <babbageclunk> anastasiamac: ok, I know what that's about. apparently we're not using the index on status history when exporting.
[01:21] <anastasiamac> babbageclunk: ah!
[01:24] <babbageclunk> anastasiamac: The index is {"model-uuid", "globalkey", "updated"}
[01:24] <babbageclunk> anastasiamac: just looking in the code to see how we're getting the history in the model
[01:25] <babbageclunk> anastasiamac: do you know whether there's a way to purge old status history?
[01:26] <anastasiamac> babbageclunk: i thought that we r. wallyworld_ might even know how often :)
[01:27] <wallyworld_> the history is capped
[01:27] <wallyworld_> there's a worker to purge
[01:31] <babbageclunk> anastasiamac: we're sorting by -updated, -_id in the model code
[01:42] <thumper> ugh
[01:42]  * thumper is having a WTF moment
[01:52] <thumper> ugh
[01:52] <thumper> got it now
[01:52] <thumper> FFS
[01:53] <anastasiamac> thumper: glad we could help \o/
[02:06]  * redir eojs
[02:07] <babbageclunk> hyperlol
[02:13] <anastasiamac> redir: o/
[02:21] <redir> \o
[02:23] <babbageclunk> redir: o/
[02:23] <redir> babbageclunk: o/
[02:23] <redir> my nick will likely still be hanging out here....
[02:23] <redir> so reach out if you have questions
[02:25] <thumper> o/ redir
[02:25] <thumper> redir: so long and thanks for all the fish
[02:26] <menn0> wallyworld_: do you think I should take this modelBackend change further and get rid of getCollection etc now?
[02:26] <wallyworld_> would be nice if you had time
[02:26] <wallyworld_> but other stuff more important
[02:26] <wallyworld_> imo
[02:26] <menn0> wallyworld_: yeah fair enough
[02:26] <wallyworld_> i really want to get rid of ForModel()
[02:30] <menn0> wallyworld_: I think ForModel could be made a lot cheaper with a bit of restructuring
[02:30] <wallyworld_> yes it could
[02:30] <wallyworld_> we don't want the workers
[02:30] <wallyworld_> just access to state
[02:30] <menn0> wallyworld_: for example there's no need to do all the DB setup work again and the workers need to move out
[02:30] <wallyworld_> yep
[02:30] <menn0> for another time though
[02:30] <wallyworld_> sadly yes
[02:35] <sinzui> wallyworld_: axw : QA needs to test the controller running with a valid cert. I have DNS pointing to a machine, but I need a --to or --constraint to incantation to bootstrap on the machine jimm-a.vapour.ws. The aws provider does not like --to ssh:ubuntu@jimm-a.vapour.ws
[02:36] <wallyworld_> no, only the manual provider supports that
[02:36] <axw> sinzui: you can do "juju bootstrap manual/ubuntu@jimm-a.vapour.ws"
[02:37] <wallyworld_> that's the syntax i was looking for
[02:41] <sinzui> axw: Doesn't that undermine subsequent deployments in aws?
[02:41] <axw> sinzui: I don't understand your question
[02:42] <sinzui> axw once the controller is up, we expect to deploy applications into many models. The machine is in aws so I expcect to use the aws provider
[02:43] <axw> sinzui: ok. you cannot bootstrap aws to an existing instance
[02:44] <sinzui> axw wallyworld_ I want to bootstrap with --config autocert-dns-name=jimm-a.vapour.ws which should trigger juju to install a cert *if* the hosts ip matches DNS. So I think I need the machine up *before* I bootstrap
[02:45]  * wallyworld_ hasn't used the autocert functionality before, so not sure tbh
[02:45] <axw> sinzui: I don't think you do though? you should be able to bootstrap with autocert-dns-name, then set up your DNS, then use the DNS name from your client
[02:45] <axw> sinzui: the autocert stuff only kicks in for clients that attempt to connect via the DNS name
[02:46]  * thumper sighs
[02:46] <thumper> wow this is tedious work
[02:46]  * thumper is adding state.Export to 1.25 branch
[02:46] <sinzui> axw :( That is awkward. Bootstrap, the  fallback to another tool to associate an elatic IP. That is better I suppose than trying to register DNS for a random IP several times an hour
[02:47] <sinzui> s/the fallback/then fallback
[02:47] <axw> sinzui: ideally we'd have bootstrap just register with route53 I think, but we don't have that atm
[02:48] <axw> or use an elastic IP I guess
[02:48] <sinzui> axw, oh, maybe I missed something you wrote? how do I tell the client to use the dns name if I didn't boostrap with the name?
[02:48] <axw> but yeah, that's the current state of affairs
[02:49] <axw> sinzui: you have to modify your controllers.yaml, replace the IPs with the DNS name
[02:49] <sinzui> axw, associating an elastic IP is jsut a nusancec and just a single line in a script before starting the hard work of the test
[02:49] <axw> sinzui: or use "juju register domain.name"
[02:49] <sinzui> axw, okay, thank you!
[02:49] <axw> sinzui: np
[02:53] <rick_h> sinzui: axw I was just talking to urulama about that today
[02:53] <rick_h> We've got it on the list of topics for next week
[02:53] <rick_h> Because it almost does the right thing but needs the s/IP/DNS name tweaks
[02:54] <axw> rick_h: I'd like to hear the outcome. I won't be at the sprint
[02:54] <rick_h> axw: will do.
[02:54] <blahdeblah> thumper: ping; just trying to get you up-to-date info for my 2.1 controllers - is there anything that needs to change in terms of agent streams & stuff in upgrading from 2.1-rc2 to 2.1 stable?
[02:55] <thumper> blahdeblah: um... not sure to be honest
[02:55] <thumper> sinzui: ^^
[02:55] <thumper> blahdeblah: 2.1-rc2 info is fine
[02:55] <thumper> blahdeblah: what I'm looking at hasn't changed in there
[02:56] <menn0> thumper, wallyworld_: i'm not going to be able to make tech board today due to a thing at my son's preschool
[02:56] <menn0> it's one of those days
[02:56] <blahdeblah> thumper: It's not fine with me :-)
[02:56] <thumper> blahdeblah: ah
[02:56] <thumper> :)
[02:56] <wallyworld_> pk
[02:56] <thumper> menn0: that's fine, I had completely forgotten about it
[02:57] <blahdeblah> thumper: I'll just try a 2.1 upgrade and see how it goes
[02:57] <thumper> blahdeblah: can't hurt, right?
[02:58] <blahdeblah> How do I show what the current version of tools is in my running controller/models?
[02:59] <blahdeblah> sorry - source, not version
[02:59] <blahdeblah> Version is easily seen in the status output; I want to know where they came from
[03:03] <axw> wallyworld_: it's a big-un, but PTAL when you can: https://github.com/juju/juju/pull/7052
[03:03] <wallyworld_> sure, will do. just finishing something, will look soon
[03:03] <axw> menn0: ^^ if you are doing OCR
[03:04] <menn0> axw: thanks for the reminder :) looking
[03:04] <axw> blahdeblah: source? as in, whether it came from streams.c.c or uploaded or whatever?
[03:06] <sinzui> blahdeblah: upgrades from 2.1-rc2 is fine, tested, is is just a version string change
[03:06] <blahdeblah> axw: yes - as in, did I mangle some config to pull devel tools at some point in the past, and do I need to change them back to stable now?
[03:08] <thumper> blahdeblah: juju status will show what is currently in use
[03:08] <thumper> blahdeblah: if you add --format yaml, there are more details
[03:08] <thumper> by default status now only shows the version for the model, rather than every agent
[03:09] <blahdeblah> thumper: no indication in there about which stream the agents came from
[03:09] <thumper> blahdeblah: ah... model-config?
[03:10] <sinzui> blahdeblah: ther rc1 was only in devel streams. but regardless, if you didn't force agent-stream=devel, juju will select released
[03:10] <axw> blahdeblah: I think the only place we store that info is on disk. there's a file caled downloaded-tools.txt
[03:11] <axw> I think we also have it in the DB actually, but don't think we expose it to the CLI anywhere
[03:11] <sinzui> blahdeblah: "juju upgrade-juju --agent-version 2.1.0 --dry-run" will tell you if the upgrade can happen
[03:12] <axw> blahdeblah: it'll only tell you the URL we grabbed the agent from tho, not the stream. the stream name is just in model config as per ^^
[03:16] <blahdeblah> OK, looks like I never changed from released stream, so I think we're all good.
[03:16] <blahdeblah> Thanks everyone
[03:25]  * thumper headdesks
[03:28] <menn0> axw: done. looks good
[03:28] <jam> menn0: axw: thumper: tech board?
[03:28] <axw> menn0: thanks!
[03:29] <axw> jam: still 1 minute! ;)  omw
[03:31] <blahdeblah> Gah; "juju sync-tools" == "juju destroy-my-uplink"
[03:31] <blahdeblah> Is there a way to get this thing to sync from the streams rather than from my client?
[03:39] <sinzui> blahdeblah: sync-tools does that by default it only uses disk if you pass extra args
[03:40] <sinzui> blahdeblah: you want to sync 2.1 from released into your controller?
[03:41] <blahdeblah> sinzui: yes - direct from streams rather than via my client, which is halfway around the world from the controller
[03:41] <sinzui> blahdeblah: yeah, that sucks, though there are only 6 agents instread of 27 now
[03:41] <sinzui> blahdeblah: juju sync-tools --version 2.1 --dry-run
[03:42] <blahdeblah> sinzui: Are you saying that the above will cause it to sync directly from streams?
[03:42] <sinzui> blahdeblah: yes
[03:43] <blahdeblah> Is it supposed to tell me anything?
[03:43] <sinzui> blahdeblah: It doesn't? what have a dry run if if it sin't verbose
[03:43] <blahdeblah> Unless I give --debug, it says nothing
[03:44] <blahdeblah> also, should it be 2.1.0 rather than 2.1?
[03:44] <sinzui> blahdeblah: it only accepts major.minor, the looks for the newest version in streams.
[03:44] <blahdeblah> according to --debug, there are still 27 agents to sync:
[03:44] <blahdeblah> 13:43:22 INFO  juju.environs.sync sync.go:136 found 176 tools in target; 27 tools to be copied
[03:45] <blahdeblah> This is not downloading directly from streams to the controller; it's definitely coming via my connection.
[03:46] <sinzui> blahdeblah:oh, juju if a fuckwit. there are 27 names, but exactly 6 agents. 4 for ubuntu series by arch, 1 for centos, and 1 for all 10 windows series
[03:46] <sinzui> :/
[03:47] <sinzui> blahdeblah: do you need to sync? Juju usually gets agents from streams.canonical.com as needed. 99% of the time that is just the ubuntu amd64 agent
[03:48] <sinzui> blahdeblah: what I am asking is, can the controller see streams.canonical.com? if so, just run upgrade-juju --version 2.1.0
[03:48] <blahdeblah> sinzui: I have no idea whether I need to sync.  What would determine that?  I'm following our existing upgrade procedure, possibly naively: https://wiki.canonical.com/InformationInfrastructure/IS/JujuUpgrades
[03:49] <blahdeblah> The controller should be able to see streams.c.c
[03:49] <sinzui> blahdeblah: I see. there is a history of prodstack and friends from stay away from live streams
[03:49] <blahdeblah> I wouldn't think that's a hard requirement any more
[03:50] <sinzui> blahdeblah: probably not. the sync-tools command is actually *less* precise than  juju-upgrade --agent-version 2.1.0
[03:51] <blahdeblah> Thanks sinzui - juju upgrade-juju --agent-version="2.1.0" --debug worked a lot faster for me
[03:52] <sinzui> blahdeblah: yes, it is much faster in 2.x and it will abort if 2.1.0 is not available. Juju will not select an alter alternat agent behind you back.
[03:54] <blahdeblah> cool - thanks very much
[04:53] <jam> axw: did you want to chat? I don't think I have much more than a quick recap of "working on 2.1.1 bugs"
[04:53] <axw> jam: happy to skip. my update is same as yesterday
[06:29] <axw> wallyworld_: AFAICR, filesystem and volume IDs are not exposed to charms, only to users via "juju storage". so I'm thinking we could probably change the ID format to be unambiguous
[06:29] <wallyworld_> yeah, that would be sweet I think, certainly easier for users
[06:30] <axw> wallyworld_: ah, except old agents wouldn't be able to understand a new format
[06:30] <axw> hm
[06:30] <wallyworld_> doh, yeah
[07:00] <axw> wallyworld_: so I've had another thought, still a bit loose: I don't think it's helpful to users to distinguish between "storage instance" and "volume/filesystem". to them, they're one and the same (I think). so we could perhaps have the storage instance remain in the model, and have that be the thing you attach/detach
[07:01] <wallyworld_> axw: yeah, the distinction between volume/filesystem and storage instance has (to end users) been murky and I think an exposing of the internal model which we could/should abstract over
[07:02] <axw> wallyworld_: I'll play with that a bit, and leave the remove-storage command alone for now
[07:02] <wallyworld_> sgtm
[07:02] <axw> wallyworld_: I can't see us having anything interesting to demo next week
[07:02] <axw> for storage I mean
[07:03] <wallyworld_> such is life. i told folks we would be pushing it
=== frankban|afk is now known as frankban
[10:02] <jam> anyone for reviewing my update to perrito666's patch: https://github.com/juju/juju/pull/7054 ?
=== frankban is now known as frankban|afk
[10:24] <anastasiamac> jam: lgtm'ed
[10:24] <jam> anastasiamac: we have TestFindAvailableSubnetWithExisting10xNetworks
[10:24] <jam> is that not the collision test you were looking for?
[10:25] <jam> (that's the test I updated and confirmed it failed from before, suceeeds with my cahnge)
[10:27] <anastasiamac> jam: u answered my one and wallyworld_ the other questions :D so +1 as per review
[10:28] <jam> wallyworld_: did you have review feedback as well? or LGTM
[10:28] <wallyworld_> jam: still looking, was thinking we could use a map[net.IP]bool instead of separate set and slice
[10:29] <wallyworld_> in getKnowmIps()
[10:29] <wallyworld_> but meh, whatever works
[10:29] <jam> wallyworld_: so we can, but we still iterate over the slice in the end. I'm fine tweaking it, but in reality we'll have at most like 10
[10:30] <wallyworld_> yeah, hence the meh. but the logic is a bit simpler and exlicit
[10:30] <wallyworld_> let me just finish reading the rest
[10:32] <jam> I like elicit logic
[10:33] <wallyworld_> lol
[10:33] <wallyworld_> jam: seems ok to  me, testing steps seem to verify it works. anastasiamac asked for an additional test so whatver make you guys happy, i'm happy
[10:34] <wallyworld_> i like that we defer to lxd in > 2.3
[10:37] <jam> well, aside from bug #1668547 where we defer to LXD but it doesn't actually work :)
[10:37] <mup> Bug #1668547: juju doesn't configure lxdbr0 properly with new LXD (>2.3) <bridge> <lxd> <network> <juju:Triaged by jameinel> <https://launchpad.net/bugs/1668547>
[10:39] <jam> I think I made the bot unhappy, has anyone else been able to land branches?
[10:40] <jam> Both this one and https://github.com/juju/juju/pull/7044 have a "$$merge$$" but the bot hasn't responded for 30 minutes
[10:41] <anastasiamac> jam: axw landed some today but that was almost 5hr ago
[10:41] <jam> and there it just woke up
[10:41] <jam> 'a minute ago' on both of them
[10:41] <anastasiamac> jam: \o/
[10:41] <jam> ah, sorry, it still hasn't noticed 2.1-into-develop. I think it is because I stopped the request last time
[10:41] <jam> because it had a bug
[10:41] <jam> so probably I need sinzui's help to unblock that branch again.
[10:42] <jam> (I had 2 tabs open on the same pr)
[10:42] <anastasiamac> jam:  as far as I know for bot to pick it up again, pr has to have a 'merge failed' msg
[10:43] <anastasiamac> jam: something like "Build failed: Generating tarball failed"
[10:43] <anastasiamac> then re-enter merge command and it should get picked up again
[10:44] <perrito666> morning all
[10:44] <anastasiamac> perrito666: \o/
[10:44] <jam> hey perrito666. I wasn't sure if you were back in today or tomorrow
[10:45] <jam> good to see you
[10:45] <perrito666> jam: given that we live in different days I believe both are true :p
[10:45] <perrito666> jam: mm no, wit its tue for you
[10:45] <jam> its late Wed for me
[10:45] <perrito666> yes, wed sorry, its early wed for me
[10:45] <jam> same day as you, just a bit later
[10:46] <perrito666> jam: since yesterday we are the only two living in the past
[10:46] <jam> perrito666: you live further in the past than I. but there is Eric as well
[10:46] <perrito666> jam: does this mean you obsoleted/merged my pr? https://github.com/juju/juju/pull/7054
[10:47] <perrito666> jam: ah true, I forgot about eric, he lives in the past too
[10:47] <jam> perrito666: merged
[10:47] <perrito666> jam: tx, its amazig to have someone take care of the boring parts of my PRs
[10:47] <perrito666> :p
[10:48] <jam> heh. exteralreality is his IRC nick. I don't think I've seen him on IRC yet. I guess he's starting late for Tim?
[10:48] <perrito666> I have seen him on irc and also "in person" a.k.a in a hangout
[10:49] <jam> in theory, we get to see 'in the flesh' next week
[10:50]  * perrito666 tries to figure out what time does his plane leaves
[10:50] <perrito666> Sun 1:50 which translates to Sat night
[11:20] <menn0> jam: did you want to talk at all?
[11:20] <jam> menn0: sure
[11:20] <menn0> jam: now is literally the first moment I've had since we last talked
[11:20] <jam> https://hangouts.google.com/hangouts/_/canonical.com/john-menno?authuser=1
=== frankban|afk is now known as frankban
[14:08] <kjackal> hi juju-devs, there is a problem with the juju bootstrap dialog and localhost:  http://pastebin.ubuntu.com/24090147/
[14:08] <kjackal> Is this a known issue?
[15:18] <zeestrat> kjackal: I ran into the same issue. Not sure if there's a bug in launchpad. If you do not use the dialog, you can just say juju bootstrap lxd <name-of-controller>
[15:25] <rick_h> kjackal: not seen a bug on that but :/ at it oops
[15:32] <kjackal> zeestrat: rick_h: opened this ticket: https://bugs.launchpad.net/juju/+bug/1669003
[15:32] <mup> Bug #1669003: "juju bootstrap" dialog failing for localhost <juju:New> <https://launchpad.net/bugs/1669003>
[15:32] <rick_h> kjackal: ty much
[16:05] <perrito666> jam: any clue on where the interfaces checking/renaming happens in code? this should be cloudinit right?
[16:05] <perrito666> ayway, re-locating again
[16:06] <perrito666> nevermind
=== frankban is now known as frankban|afk
=== beisner- is now known as beisner
[21:09]  * thumper running dog down for her haircut
[21:10] <perrito666> thumper: just hack a roomba with some scisors
[21:11] <veebers> thumper: short back and sides, or a perm this time?
[21:36] <thumper> her ears often look like she has had a perm
[21:36] <thumper> but something like a number 4 over most of the body :)
[22:04] <babbageclunk> I really want an introspection worker that dumps out a dot representation of the dependency dag. <waggles eyebrows at thumper>
[22:29] <thumper> babbageclunk: sounds interesting
[22:30] <babbageclunk> thumper: currently trying to do the same with the "dependency not available" lines from the log
[22:32] <thumper> hmm... I now wish we were using Go 1.8
[22:32] <thumper> it would make some of what I'm doing easier...
[22:37] <babbageclunk> thumper: what are you doing?
[22:38] <thumper> assigning structs for different packages
[22:38] <thumper> where refactoring has happened
[22:38] <thumper> and things moved
[22:38] <thumper> adding state.Export to the 1.25 codebase
[22:42] <babbageclunk> thumper: I mean, what 1.8 feature do you need? (Just curious.)
[22:43] <babbageclunk> thumper: Oh, the tag differences?
[23:05]  * wallyworld uses 1.8, it's glorious
[23:05] <wallyworld> so fast