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:03 |
wallyworld_ | ok, will look soon, just finishing something | 00:04 |
anastasiamac | menn0: m not able to review today. i trust u'd get reviews from others \o/ | 00:13 |
menn0 | anastasiamac: thanks anyway :) | 00:13 |
anastasiamac | menn0: no worries :0 | 00:16 |
=== thumper-dogwalk is now known as thumper | ||
thumper | keep forgetting to reset that | 00:29 |
thumper | menn0: I'm looking now | 00:29 |
menn0 | thumper: thank you | 00:29 |
thumper | menn0: lgtm - you can await another if you choose | 00:33 |
menn0 | thumper: thanks. I think wallyworld_ offered to have a look too | 00:34 |
wallyworld_ | looking now | 00:34 |
wallyworld_ | menn0: at first glance, it seems not all occurrences of st.getCollection() have been ported across? | 00:37 |
menn0 | wallyworld_: that's right... I wasn't aiming to change everything to go via the Database | 00:40 |
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:41 |
* menn0 has to go | 00:42 | |
menn0 | biab | 00:42 |
wallyworld_ | menn0: lgtm too. been wanting progess is ths area for a while, so is great | 00:47 |
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:17 |
babbageclunk | anastasiamac: looking | 01:18 |
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:21 |
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:24 |
babbageclunk | anastasiamac: do you know whether there's a way to purge old status history? | 01:25 |
anastasiamac | babbageclunk: i thought that we r. wallyworld_ might even know how often :) | 01:26 |
wallyworld_ | the history is capped | 01:27 |
wallyworld_ | there's a worker to purge | 01:27 |
babbageclunk | anastasiamac: we're sorting by -updated, -_id in the model code | 01:31 |
thumper | ugh | 01:42 |
* thumper is having a WTF moment | 01:42 | |
thumper | ugh | 01:52 |
thumper | got it now | 01:52 |
thumper | FFS | 01:52 |
anastasiamac | thumper: glad we could help \o/ | 01:53 |
* redir eojs | 02:06 | |
babbageclunk | hyperlol | 02:07 |
anastasiamac | redir: o/ | 02:13 |
redir | \o | 02:21 |
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:23 |
thumper | o/ redir | 02:25 |
thumper | redir: so long and thanks for all the fish | 02:25 |
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:26 |
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:30 |
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:35 |
wallyworld_ | no, only the manual provider supports that | 02:36 |
axw | sinzui: you can do "juju bootstrap manual/ubuntu@jimm-a.vapour.ws" | 02:36 |
wallyworld_ | that's the syntax i was looking for | 02:37 |
sinzui | axw: Doesn't that undermine subsequent deployments in aws? | 02:41 |
axw | sinzui: I don't understand your question | 02:41 |
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:42 |
axw | sinzui: ok. you cannot bootstrap aws to an existing instance | 02:43 |
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:44 |
* 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:45 |
* 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:46 |
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:47 |
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:48 |
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:49 |
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:53 |
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:54 |
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:55 |
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:56 |
blahdeblah | thumper: I'll just try a 2.1 upgrade and see how it goes | 02:57 |
thumper | blahdeblah: can't hurt, right? | 02:57 |
blahdeblah | How do I show what the current version of tools is in my running controller/models? | 02:58 |
blahdeblah | sorry - source, not version | 02:59 |
blahdeblah | Version is easily seen in the status output; I want to know where they came from | 02:59 |
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:03 |
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:04 |
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:06 |
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:08 |
blahdeblah | thumper: no indication in there about which stream the agents came from | 03:09 |
thumper | blahdeblah: ah... model-config? | 03:09 |
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:10 |
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:11 |
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:12 |
blahdeblah | OK, looks like I never changed from released stream, so I think we're all good. | 03:16 |
blahdeblah | Thanks everyone | 03:16 |
* thumper headdesks | 03:25 | |
menn0 | axw: done. looks good | 03:28 |
jam | menn0: axw: thumper: tech board? | 03:28 |
axw | menn0: thanks! | 03:28 |
axw | jam: still 1 minute! ;) omw | 03:29 |
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:31 |
sinzui | blahdeblah: sync-tools does that by default it only uses disk if you pass extra args | 03:39 |
sinzui | blahdeblah: you want to sync 2.1 from released into your controller? | 03:40 |
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:41 |
blahdeblah | sinzui: Are you saying that the above will cause it to sync directly from streams? | 03:42 |
sinzui | blahdeblah: yes | 03:42 |
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:43 |
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:44 |
blahdeblah | This is not downloading directly from streams to the controller; it's definitely coming via my connection. | 03:45 |
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:46 |
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:47 |
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:48 |
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:49 |
sinzui | blahdeblah: probably not. the sync-tools command is actually *less* precise than juju-upgrade --agent-version 2.1.0 | 03:50 |
blahdeblah | Thanks sinzui - juju upgrade-juju --agent-version="2.1.0" --debug worked a lot faster for me | 03:51 |
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:52 |
blahdeblah | cool - thanks very much | 03:54 |
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 | 04:53 |
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:29 |
axw | wallyworld_: ah, except old agents wouldn't be able to understand a new format | 06:30 |
axw | hm | 06:30 |
wallyworld_ | doh, yeah | 06:30 |
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:00 |
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:01 |
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:02 |
wallyworld_ | such is life. i told folks we would be pushing it | 07:03 |
=== frankban|afk is now known as frankban | ||
jam | anyone for reviewing my update to perrito666's patch: https://github.com/juju/juju/pull/7054 ? | 10:02 |
=== frankban is now known as frankban|afk | ||
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:24 |
jam | (that's the test I updated and confirmed it failed from before, suceeeds with my cahnge) | 10:25 |
anastasiamac | jam: u answered my one and wallyworld_ the other questions :D so +1 as per review | 10:27 |
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:28 |
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:29 |
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:30 |
jam | I like elicit logic | 10:32 |
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:33 |
wallyworld_ | i like that we defer to lxd in > 2.3 | 10:34 |
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:37 |
jam | I think I made the bot unhappy, has anyone else been able to land branches? | 10:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
jam | in theory, we get to see 'in the flesh' next week | 10:49 |
* perrito666 tries to figure out what time does his plane leaves | 10:50 | |
perrito666 | Sun 1:50 which translates to Sat night | 10:50 |
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 | 11:20 |
=== frankban|afk is now known as frankban | ||
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? | 14:08 |
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:18 |
rick_h | kjackal: not seen a bug on that but :/ at it oops | 15:25 |
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 | 15:32 |
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:05 |
perrito666 | nevermind | 16:06 |
=== frankban is now known as frankban|afk | ||
=== beisner- is now known as beisner | ||
* thumper running dog down for her haircut | 21:09 | |
perrito666 | thumper: just hack a roomba with some scisors | 21:10 |
veebers | thumper: short back and sides, or a perm this time? | 21:11 |
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 :) | 21:36 |
babbageclunk | I really want an introspection worker that dumps out a dot representation of the dependency dag. <waggles eyebrows at thumper> | 22:04 |
thumper | babbageclunk: sounds interesting | 22:29 |
babbageclunk | thumper: currently trying to do the same with the "dependency not available" lines from the log | 22:30 |
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:32 |
babbageclunk | thumper: what are you doing? | 22:37 |
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:38 |
babbageclunk | thumper: I mean, what 1.8 feature do you need? (Just curious.) | 22:42 |
babbageclunk | thumper: Oh, the tag differences? | 22:43 |
* wallyworld uses 1.8, it's glorious | 23:05 | |
wallyworld | so fast | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!