| axw | wallyworld: can you please create the feature branch? I don't have permissions to | 00:41 |
|---|---|---|
| wallyworld | ah, ok | 00:41 |
| wallyworld | axw: there now | 00:44 |
| axw | wallyworld: ta | 00:44 |
| axw | wallyworld: I'll land the branch you LGTMd there, then propose the next one against it | 00:45 |
| wallyworld | +1 | 00:45 |
| mup | Bug #1550074 opened: ec2/ebs: ListVolumes should not return root volumes <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1550074> | 00:58 |
| wallyworld | axw: when you're free could you look at http://reviews.vapour.ws/r/3971/ | 01:09 |
| axw | wallyworld: ok, looking | 01:10 |
| menn0 | axw: ping | 01:36 |
| axw | menn0: pong | 01:36 |
| menn0 | axw: in b16d1e85879d1cccb38a860b04c65125b87567f1 you made ConnectionInfoForName private (in cmd/modelcmd) | 01:37 |
| menn0 | in a feature branch I'm using it | 01:37 |
| menn0 | for the "juju migrate" command | 01:37 |
| menn0 | any problems with exporting it again? | 01:38 |
| axw | menn0: all those old things are going away. what're you using it for? | 01:38 |
| axw | menn0: can you point me at the migrate code? | 01:38 |
| menn0 | axw: ok, if there's a better way | 01:38 |
| menn0 | axw: I need to get the API server and auth details for the controller to migrate a model to | 01:38 |
| * menn0 digs up a link | 01:39 | |
| menn0 | axw: https://github.com/juju/juju/blob/model-migration-control/cmd/juju/commands/migrate.go#L87 | 01:39 |
| axw | menn0: sorry got called downstairs, one moment | 01:43 |
| axw | menn0: something like this: http://paste.ubuntu.com/15202778/ | 01:50 |
| axw | menn0: configstore will be going away, so best not to revive the old method | 01:51 |
| menn0 | axw: tyvm, this looks great | 01:52 |
| menn0 | axw: I'll update the migrate command | 01:52 |
| menn0 | axw: I knew this stuff was changing but it hadn't when I wrote it | 01:52 |
| axw | menn0: yup, such is life with feature branches :) | 01:52 |
| menn0 | axw: yep, they are are a double edged sword | 01:53 |
| menn0 | axw: am I right in thinking that the store can be easily swapped out for testing? it looks that way from what I can see. | 01:54 |
| axw | menn0: yes, c.SetClientStore before wrapping the command | 01:54 |
| axw | menn0: the Init method will only set the default store if one hasn't been set already | 01:54 |
| menn0 | axw: that's what I was looking at. perfect. | 01:55 |
| anastasiamac | yep, menn0. axw and wallyworld r pretty awesome \o/ | 01:55 |
| axw | menn0: also note that SetModelName and SetControllerName return an errors now, didn't before - in case you use that anywhere | 01:55 |
| menn0 | ok great | 01:56 |
| axw | I should probably document how it works and send that out | 01:56 |
| menn0 | axw: looks like ModelByName doesn't need AccountName | 01:59 |
| axw | menn0: you may need to rebase | 01:59 |
| menn0 | axw: I just rebased this branch to the latest blessed master | 01:59 |
| menn0 | has it changed since? | 01:59 |
| axw | menn0: 3 days ago | 02:00 |
| menn0 | axw: probably just after then | 02:00 |
| menn0 | axw: this branch will be around for a while yet so I'll get right up to tip | 02:00 |
| axw | wallyworld: my desktop keeps rebooting. need to run tests, will be off for a while | 03:04 |
| wallyworld | ok | 03:04 |
| menn0 | axw: thanks for your help earlier, the migrate command is working again. | 04:13 |
| axw | menn0: great, np | 04:13 |
| menn0 | axw: I wonder if MemStore should have some extra methods to make it easier to set up test configs. | 04:14 |
| menn0 | axw: I had to make about 6 calls to set up a workable config for the migrate command | 04:14 |
| menn0 | axw: and it took a while to figure out how to do it right | 04:14 |
| axw | menn0: do you have something in mind? you can initialise the maps directly | 04:15 |
| axw | menn0: I agree it's a bit tedious - initialising maps directly is a bit better, but still a bit verbose | 04:15 |
| menn0 | axw: I was thinking some sort of call which sets up a model, controller and account all at once | 04:16 |
| davecheney | https://github.com/juju/juju/pull/4401 | 04:16 |
| davecheney | can I get a review on this one please | 04:16 |
| menn0 | axw: it's fine the way it is | 04:16 |
| davecheney | for whatever reason the bot has decided to ignore it | 04:16 |
| menn0 | axw: just wondering if it could be better | 04:16 |
| menn0 | I didn't even consider fiddling with the maps directly so i'm not sure how that would have looked | 04:16 |
| axw | menn0: yeah, I think it can. something along the lines of testing/factory might be nice | 04:17 |
| menn0 | axw: yeah, that style of helper might be nice | 04:17 |
| menn0 | axw: not urgent though | 04:17 |
| menn0 | davecheney: LGTM | 04:17 |
| davecheney | ta | 04:18 |
| wallyworld | axw: depending on how far you get before eod with the default host model, can you push up something even if wip so it can be landed into feature branch and i can take over when you're gone? | 04:51 |
| axw | wallyworld: yup. just finished adding --default-model, still need to write tests | 04:52 |
| wallyworld | awesome, ta | 04:52 |
| axw | wallyworld: actually I think I'm going to have to rework things a bit, so we know what the UUID of the hosted model is up front | 05:11 |
| axw | wallyworld: needed so I can set the current model from the CLI without waiting for completion | 05:12 |
| wallyworld | that doesn't surprise me | 05:12 |
| axw | anyway, will send you a link when I'm done | 05:12 |
| wallyworld | axw: ok, i am off to meet anastasia for 1:1 and then to soccer but will be back later | 05:12 |
| axw | wallyworld: I might reappropriate "uuid" in the initial config for the hosted model, and add a new "controller-uuid" attribute | 05:12 |
| axw | wallyworld: later | 05:12 |
| wallyworld | controller-uuid is more explicit | 05:12 |
| jam | mgz: sinzui: If I accidentally submitted a merge request but the branch was targetting the wrong branch, I want to cancel the merge job so it doesn't waste time. | 06:13 |
| jam | how do I determine which merge job it is? | 06:13 |
| jam | When I go to the juju-ci page, I can see the pending request, but I can't see any of the details | 06:13 |
| jam | like right now, there are 2 pending jobs, I have no way to distinguish them. | 06:14 |
| davecheney | jam: best i know how to do is to open each of them | 06:19 |
| davecheney | scroll down to the output | 06:20 |
| davecheney | and then look at the branch | 06:20 |
| davecheney | o | 06:20 |
| davecheney | sory, that won't work if they haven't started to run yet | 06:20 |
| jam | right | 06:21 |
| jam | menn0: frobware: I updated my LXD branch to Skip() one of the tests that I know is not very nice (talks to LXD on your running machine and starts containers), and fixed newInstanceSummary to actually parse Mem correctly. | 09:10 |
| jam | ericsnow: I also responded to your review feedback. Hopefully someone feels its good enough to at least land on the feature branch. | 09:11 |
| jam | tych0: ^^ branch updated | 09:16 |
| jam | http://reviews.vapour.ws/r/3973/diff/# | 09:16 |
| frobware | jam: merging upstream/master was an intentional thing? | 09:25 |
| jam | frobware: well, I do intend to keep up to date with master, yes. | 09:43 |
| jam | frobware: just shouldn't have happened as part of the review. | 09:43 |
| jam | So I landed master into the target branch directly, so now the diff is nice again. | 09:43 |
| jam | frobware: I just misunderstood one of your comments. You said "this is missing a parameter" meaning the Print statement, but I read it as the network.Address() | 09:44 |
| jam | so I thought I was out of date with master. | 09:44 |
| jam | (which I was rather far behind) | 09:44 |
| dooferlad | frobware, dimitern, voidspace: https://plus.google.com/hangouts/_/canonical.com/sapphire | 10:01 |
| voidspace | dooferlad: sorry, got lost in code | 10:01 |
| voidspace | dooferlad: omw | 10:01 |
| * fwereade_ popping out for a bit, bbl | 10:02 | |
| mgz | jam: the only way to see which build is which that I know is by hover on *the main page* which is generally full of bundle test junk | 10:31 |
| mgz | but you can see which job is which and cancel from there | 10:31 |
| jam | mgz: the lines and lines of "charm-bundle-test-aws" | 10:32 |
| mgz | yeah, it's joy | 10:32 |
| jam | there appears to be about 100 lines there. | 10:32 |
| jam | mgz: did you see my email about setting up a CI test from one of the current LXD tests? | 10:34 |
| mgz | jam: yeah, it seems like a good idea | 10:34 |
| voidspace | oh the irony: Test killed with quit: ran too long. github.com/juju/juju/worker/terminationworker | 10:35 |
| voidspace | dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3981/ | 10:48 |
| dimitern | voidspace, looking | 10:53 |
| dimitern | voidspace, reviewed | 11:00 |
| voidspace | dimitern: I've fixed two of the issues and replied to the other two - I think we should drop the issue about providerId conversion and I am reluctant to include spaces with no subnets | 11:23 |
| voidspace | dimitern: how about we skip them for now and revisit that if it becomes a practical issue anyone cares about | 11:24 |
| voidspace | dimitern: I think including them is dangerous | 11:24 |
| dimitern | voidspace, that's fine - added a comment | 11:30 |
| voidspace | dimitern: thanks | 11:31 |
| dimitern | voidspace, frobware, dooferlad, please have a look http://reviews.vapour.ws/r/3972/ | 11:35 |
| dimitern | voidspace, frobware, dooferlad, and this is the straw-man proposal for addresses - http://paste.ubuntu.com/15204914/ (we should decide on the doc / collection / state type names - singular and plural) | 11:37 |
| dooferlad | dimitern: what is the urgency on having a discussion around that? | 11:38 |
| dimitern | dooferlad, because that's what I'm about to start implementing | 11:38 |
| dooferlad | dimitern: That clears that up :-) | 11:39 |
| dimitern | :) cheers | 11:39 |
| dimitern | if we don't reach consensus though, I can switch to doing the Machine.UpdateLinkLayerDevices() instead | 11:39 |
| frobware | dimitern: ignore my comment about empty ops - just looked again and makes perfect sense. | 11:42 |
| frobware | dimitern: rule 1, don't be blocked. :) | 11:42 |
| dimitern | frobware, :) cheers, I still replied though, as it's a fair question | 11:44 |
| dooferlad | dimitern: I can't think of any more information that we need for an ipAddressDoc. +1 | 11:47 |
| dimitern | dooferlad, sweet, thanks! | 11:48 |
| frobware | dimitern: Did we settle on DNSSearchDomains for DNSDomains? | 11:52 |
| frobware | dimitern: type 'IPAddressConfigMethod' is missing loopback. | 11:53 |
| dimitern | frobware, good point - will rename DNSDomains to DNSSearchDomains | 11:54 |
| dimitern | frobware, as for loopbacks.. the config type is still static I think (actually always static) | 11:55 |
| frobware | dimitern: iface lo inet loopback | 11:55 |
| dimitern | frobware, but the "loopback" part is the device type | 11:56 |
| frobware | dimitern: don't believe so. | 11:56 |
| frobware | dimitern: given the number of args in 'iface', it is the config method, | 11:56 |
| dimitern | frobware, loopback devices have no options to set | 11:57 |
| dimitern | frobware, so it can't have an address - it's always 127/8 | 11:57 |
| frobware | dimitern: but things like "address" are iface options. the way I read interfaces(5) loopback is the config method. | 11:58 |
| dimitern | frobware, hmm.. well if we use config type loopback that actually solves the minor inconsistency with what SubnetID to use for 127.0.0.1 | 11:59 |
| frobware | dimitern: if you read through the manpage it talks about 'auto' method, then 'loopback', 'static', 'dhcp, 'manual' (in that order). | 12:00 |
| dimitern | frobware, so, good idea - LoopbackIPAddress type does not accept a SubnetID or GatewayAddress | 12:00 |
| dimitern | s/does not/won't/ | 12:00 |
| frobware | dimitern: ooh, and in the xenial manpage there is also 'v4tunnel' method. | 12:01 |
| frobware | dimitern: and '6to4'. | 12:01 |
| frobware | (I'll stop now.) | 12:01 |
| dimitern | frobware, there are other methods I know - but we shouldn't worry about them yet I think | 12:01 |
| frobware | dimitern: agreed. but if we wanted to faithfully generate /e/n/i then I think we should cover loopback. that's been around a while now. :) | 12:02 |
| dimitern | frobware, I have a cunning plan to support pptp/tun devices at some point as devices with 2 parents or something like that | 12:02 |
| dimitern | frobware, yeah, agreed - for completeness sake loopback devices and their addresses should be represented in the model | 12:03 |
| dooferlad | dimitern: reviewed http://reviews.vapour.ws/r/3972/ - basically it is really close to being generic and I provide, what I think, is a simple suggestion to make it generic without having to change the rest of your code. | 12:04 |
| frobware | dimitern: the 'ipAddressDoc' comment could also include an example; might clear up what we mean by link-layer network device. | 12:04 |
| dimitern | dooferlad, thanks, I'll respond shortly | 12:05 |
| dooferlad | dimitern: I am about to get some lunch. No big rush. | 12:06 |
| * dooferlad goes for lunch | 12:06 | |
| frobware | dimitern: other than that, but dooferlad, voidspace should take a quick pass once these ^^ changes are done. | 12:06 |
| mup | Bug #1550306 opened: 1.25.3 can't bootstrap xenial environments <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1550306> | 12:06 |
| frobware | dimitern: other than that LGTM | 12:06 |
| dimitern | frobware, thanks! voidspace, dooferlad: here's an up-to-date paste http://paste.ubuntu.com/15205049/ | 12:11 |
| frobware | dimitern: do we need to handle unknown? | 12:19 |
| frobware | dimitern: if so, how and when do we get into that state? | 12:20 |
| dimitern | frobware, no, like with devices it will be rejected if trying to add it | 12:20 |
| frobware | dimitern: if that's the case why do we need the unknown type? | 12:23 |
| dimitern | frobware, good question - it looks like we don't anymore (remember my earlier comments about possibly allowing unknown devices/addresses for containers before we know their real type? well I guess that's no longer relevant) | 12:25 |
| dimitern | so I'll do a follow-up after finishing the addresses (without UnknowIPAddress ) to remove UnknownDevice as well | 12:26 |
| frobware | dimitern: great, thx. removing code always a bonus. | 12:27 |
| * frobware lunches | 12:27 | |
| perrito666 | morning | 13:00 |
| mup | Bug #1550338 opened: destroy-controller reports warning endlessly <juju-core:New> <https://launchpad.net/bugs/1550338> | 13:15 |
| mup | Bug #1550338 changed: destroy-controller reports warning endlessly <juju-core:New> <juju-core 2.0:New> <https://launchpad.net/bugs/1550338> | 13:45 |
| tych0 | jam: cool. do you need anythingn from me right now? | 14:28 |
| natefinch | ericsnow, katco: upgrade-charm --resources is ready for review | 14:46 |
| ericsnow | natefinch: k | 14:46 |
| natefinch | http://reviews.vapour.ws/r/3974/ | 14:47 |
| natefinch | ericsnow: is that poller merge PR ready for review? I could do that next | 14:55 |
| ericsnow | natefinch: yes and that would be great | 14:56 |
| voidspace | dimitern: ping | 15:12 |
| dimitern | voidspace, pong | 15:12 |
| voidspace | dimitern: so I'm looking at bindings in the provisioner | 15:13 |
| voidspace | dimitern: EndpointBindings | 15:13 |
| voidspace | dimitern: do they need to be names or ids? | 15:13 |
| voidspace | dimitern: they come from state and are supplied originally as space names | 15:13 |
| voidspace | dimitern: so I'm hoping they'll just be stored as names, so there's no work to do there | 15:14 |
| voidspace | unless we've translated into juju names and need to go back into maas names (which will be redundant once maas is fixed) | 15:14 |
| voidspace | dimitern: I think bindings for startMachine needs to be names not ids, right? (that's the one place we use names - and they can be validated at the time they're specified) | 15:15 |
| dimitern | voidspace, let's have a quick HO ? | 15:16 |
| voidspace | dimitern: ok | 15:16 |
| voidspace | dimitern: https://plus.google.com/hangouts/_/canonical.com/sapphire?authuser=0&hceid=Y2Fub25pY2FsLmNvbV9pYTY3ZTFhN2hqbTFlNnMzcjJsaWQ5bmhzNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cktt9qpgdt7im58l9qt9ianpag | 15:16 |
| voidspace | https://plus.google.com/hangouts/_/canonical.com/sapphire | 15:16 |
| natefinch | ericsnow: gah.... we really gotta get the charmstore stuff going... all this fake stuff and todos is wicked distracting during code review (not your fault). | 15:54 |
| ericsnow | natefinch: agreed! | 15:54 |
| katco | ericsnow: natefinch: this iteration! :) | 15:55 |
| natefinch | katco: yeah :) | 15:55 |
| dooferlad | dimitern: why do we expect bindings to be an empty string if unspecified? Don't we cope with the key/value pair not being populated? | 15:58 |
| dooferlad | dimitern: ref: juju/deploy.go getEffectiveBindingsForCharmMeta | 15:58 |
| katco | natefinch: you get a ship it! | 15:59 |
| katco | ericsnow: and you ghet a ship it! | 15:59 |
| * ericsnow is gonna cry | 15:59 | |
| ericsnow | katco: thanks | 15:59 |
| dimitern | dooferlad, exactly because there were not specified - so we don't pretend they're not by storing a made-up default | 16:00 |
| dimitern | s/there were/they were/ | 16:01 |
| dooferlad | dimitern: why not just store nothing | 16:01 |
| dooferlad | ? | 16:01 |
| dimitern | dooferlad, because the endpoints exist anyway - regardless whether we bound them or not | 16:01 |
| dooferlad | dimitern: sure, the endpoints exist, but we have no need to store something. Not storing something makes as much sense as an empty string. | 16:02 |
| dooferlad | dimitern: we still will be doing v, ok := binding[endpoint] style accesses, right? | 16:03 |
| dimitern | dooferlad, well, it's also because storing them makes it easier to read them back for network-get | 16:03 |
| dimitern | dooferlad, the list of all endpoints depends on the charm used by the service, same as for settings | 16:04 |
| dooferlad | dimitern: But bindings aren't endpoints. Endpoints exist without them. | 16:04 |
| dimitern | dooferlad, let me double take it then - why do you think storing them is wrong? | 16:05 |
| natefinch | katco: thanks | 16:05 |
| katco | natefinch: ty for getting that proposed so quickly. love how simple it is! | 16:06 |
| dooferlad | dimitern: If we have to validate if a space is valid after we get it out of the binding map, that just adds work. | 16:07 |
| natefinch | katco: yeah, I was super happy with how it went... other than having to change 1000 tests.. but now that the methods take configuration structs, that shouldn't need to happen again next time we add a parameter. | 16:09 |
| natefinch | katco: I almost wish Go had optional arguments, just to avoid churn like this. | 16:10 |
| katco | natefinch: it goes against their simplicity > ease philosophy, but i agree. i really miss optional args | 16:11 |
| dimitern | dooferlad, it will be valid once stored, as it's validated beforehand; if it's empty - nothing to validate | 16:11 |
| katco | natefinch: keyword args are even better | 16:12 |
| katco | natefinch: but i suppose passing in a struct is roughly equivalent. just less syntactic sugar | 16:12 |
| natefinch | katco: yeah, I loved it when C# added named arguments. Just make function calls so much more clear... no more doSomething(true, true, false, 3) | 16:12 |
| dooferlad | dimitern: you still have to check if it is empty. You can't just iterate over the map. You need to iterate and check for empty. Then you need to see if non-empty stuff is valid. | 16:12 |
| katco | natefinch: i wish it could be smart enough to see that it takes a struct Foo, and then you could just do Bar({Baz: "whee"}) | 16:12 |
| dimitern | dooferlad, which part of the code are you talking about? | 16:13 |
| katco | natefinch: that syntax doesn't look horrible | 16:13 |
| katco | natefinch: but still boilerplate to create arg structs | 16:13 |
| dimitern | dooferlad, deploy-time validation for bindings? | 16:13 |
| dooferlad | juju/deploy.go getEffectiveBindingsForCharmMeta adds the spaces. | 16:14 |
| ericsnow | natefinch, katco: I'm going to hold my tongue :P | 16:14 |
| dooferlad | I bumped into this because tests had changed and I hadn't understood what was happening when I merged, so didn't pick up the expected empty strings. | 16:14 |
| dooferlad | so failures happened. | 16:14 |
| dooferlad | once I dug into it, it seemed reasonable to ask why we changed the behaviour. | 16:15 |
| katco | ericsnow: ok, cool... btw, just totally off topic: python sucks! | 16:15 |
| dooferlad | dimitern: ^^ | 16:15 |
| ericsnow | katco: apparently you *still* haven't tried it (just this once, everyone is doing it) | 16:15 |
| katco | ericsnow: haha | 16:15 |
| dimitern | dooferlad, well, the initial behavior which assumed they're never empty complicated the case where they were not specified by the user | 16:15 |
| natefinch | katco: eliding the struct name in the function call would seem to be a pretty valid feature... | 16:16 |
| dimitern | dooferlad, so instead of inventing a sane default, we not don't store them | 16:16 |
| katco | ericsnow: honestly i have likely been ruined by CL. python is fine, but i've already gotten the "lightweight and flying feeling" from CL, and i prefer lispy syntax (my gawd it's full of parens!) | 16:16 |
| * natefinch shudders | 16:16 | |
| dooferlad | dimitern: but we are storing an invalid value | 16:16 |
| dimitern | dooferlad, it sounds reasonable to not store them unless they're explicitly specified by the user | 16:17 |
| ericsnow | katco: yeah, but you use/live in emacs | 16:17 |
| katco | ericsnow: (sheds a tear) i am more emacs now than not. | 16:17 |
| dooferlad | dimitern: that is what I thought :-) | 16:17 |
| dimitern | dooferlad, but to do that some refactoring is in order | 16:18 |
| katco | ericsnow: but vim has a perfectly fine para-edit mode. makes editing sexps very easy | 16:18 |
| dooferlad | dimitern: before I rebased on maas-space2 I was working quite happily not storing bindings that weren't specified. | 16:19 |
| dimitern | dooferlad, the changes that made unspecified bindings stored as empty is on master as well | 16:20 |
| dooferlad | dimitern: yea, I was working off a really old maas-spaces. | 16:21 |
| dimitern | dooferlad, ah, well ;) | 16:21 |
| natefinch | why do we pass UUIDs around as strings? | 16:21 |
| dimitern | dooferlad, anyway, I'm happy to continue the discussion over the ML or something, but I really need to go out now | 16:21 |
| dooferlad | dimitern: sure. Have a good weekend! | 16:21 |
| dimitern | dooferlad, likewise ;) | 16:22 |
| frobware | katco: did you ever dabble with Clojure? | 16:35 |
| katco | frobware: dabbled *very* briefly | 16:35 |
| frobware | katco: likewise, but circa 2009 | 16:35 |
| natefinch | I've heard horror stories about Clojure... where the smartest guy in the company can write code that no one but him understands.... | 16:36 |
| natefinch | (or her) | 16:36 |
| katco | natefinch: really? i've never heard that... it's hard to think why that would be the case | 16:37 |
| natefinch | katco: when I get some time I'll see if I can dredge up the article.... something about obscure parts of the language and complicated mathematical constructs.... I think it wasn't impossible for others to understand, it just took a lot of time to understand like one line of code. | 16:38 |
| katco | natefinch: that sounds more like haskell | 16:38 |
| frobware | katco: bingo! | 16:38 |
| * katco admits haskel is on her list of languages to learn | 16:39 | |
| frobware | katco: talk to john wiegley, he does a lot of elisp/lisp/haskell. | 16:40 |
| katco | frobware: of ledger-cli.org fame? | 16:41 |
| frobware | katco: yep. | 16:41 |
| frobware | katco: also now emacs maintainer | 16:41 |
| katco | frobware: ah yes, forgot about that | 16:41 |
| katco | frobware: what do you mean talk to him? "hey i'm random internet person #434562. i like lisp! hi!" | 16:42 |
| mup | Bug #434562: phpmyadmin error <apport-package> <i386> <phpmyadmin (Ubuntu):New> <https://launchpad.net/bugs/434562> | 16:42 |
| frobware | katco: for john that would work. :) | 16:42 |
| katco | lol mup... that wasn't a bug number | 16:42 |
| katco | frobware: i'm actually trying to migrate to ledger for personal finance | 16:42 |
| katco | frobware: but stumbling a bit on getting the data out of my banks in a cron job | 16:42 |
| frobware | katco: I signed up recently with yodlee to do it MY way... :) | 16:43 |
| frobware | katco: yodlee provide a rest api to your bank account, complete with aggregation. | 16:43 |
| katco | O.O | 16:43 |
| katco | i am checking this out | 16:43 |
| katco | frobware: i have to admit, part of the reason to switch to ledger was so that my financial life isn't aggregated into 1 spot on someone else's server | 16:44 |
| frobware | katco: well, that was my weekend hack. I'll let you know if it a) actually happens and b) is really viable. I so so hope it is... | 16:44 |
| katco | frobware: awesome... lmk for sure :) | 16:45 |
| frobware | katco: burning bushes always gets in the way of real work. :-D | 16:45 |
| katco | frobware: not aware of that phrase... what does it mean? | 16:46 |
| frobware | katco: there's always something more important that the most important thing you're working on. and when you get there it wasn't the great fire of london, just some small incidental problem, hence the bush... | 16:46 |
| ericsnow | natefinch: ship-it | 16:48 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| natefinch | ericsnow: thanks. Almost done reviewing yours. | 16:53 |
| === Makyo_ is now known as Makyo | ||
| === alexisb is now known as alexisb-afk | ||
| natefinch | katco, ericsnow: we should have a conversation about returning interfaces at some point, since it has come up a few times. | 17:23 |
| ericsnow | natefinch: +1 | 17:24 |
| katco | natefinch: ericsnow: agreed | 17:24 |
| === lazypower_ is now known as lazyPower | ||
| natefinch | ericsnow: good point about making the arg struct change separate from the functional change.... I was thinking that since I'd have to change each callsite anyway, I might as well do them at the same time... but if I did the arg struct change first, then the functional change wouldn't need to touch any of those lines.... ahh well, I'll do it next time. | 17:27 |
| ericsnow | natefinch: no worries :) | 17:28 |
| * natefinch lunches | 17:30 | |
| === natefinch is now known as natefinch-lunch | ||
| === _stowa_ is now known as _stowa | ||
| evilnickveitch | does anyone know what is replacing the 'upload-tools' command? | 18:20 |
| evilnickveitch | it seems to be on the list of things to be deprecated, but it isn't clear to me how the functionality will be replaced | 18:21 |
| evilnickveitch | sorry ^ i meant sync-tools | 18:25 |
| === natefinch-lunch is now known as natefinch | ||
| katco | ericsnow: hey you know how yesterday you were saying the endpoints for getting a charm shouldn't include version/archo? | 18:46 |
| ericsnow | katco: yep | 18:46 |
| katco | ericsnow: i think it needs to include arch for sure since there may be different versions for arch (think jre) | 18:47 |
| katco | ericsnow: and version... how will old versions of charms pull down their coupled resources? | 18:47 |
| katco | ericsnow: we need a version concept i think | 18:47 |
| ericsnow | katco: the mandate was that each arch would have its own resource name | 18:47 |
| natefinch | katco: charms, AFAIK, have no concept of arch | 18:47 |
| === ses is now known as Guest76207 | ||
| katco | ericsnow: ah ok, missed that one | 18:47 |
| natefinch | katco: it's unfortunate, but that is the way they exist now... they only care about series, which is honestly backwards of the way I would have done it. | 18:48 |
| katco | natefinch: yeah, i guess apt takes care of most of that, but seems like it should be a 1st-order concept | 18:48 |
| katco | ericsnow: and version? i think we need that | 18:48 |
| ericsnow | katco: as to version, that corresponds with resource revision (hence the "comment" info we have punted on) | 18:49 |
| katco | ericsnow: right, so s/version/revision/g... w/e. i think the concept needs to be there | 18:50 |
| ericsnow | katco: I thought it is | 18:50 |
| katco | ericsnow: it is... but i thought yesterday you said it didn't need to be | 18:50 |
| ericsnow | katco: no, we don't need "version", we still need revision | 18:51 |
| natefinch | gah... if we can avoid having both version and revision, let's do that, because, geez that is confusing | 18:51 |
| katco | ericsnow: i'm not sure what the diff. is lol, but at any rate it's called revision in the spec | 18:51 |
| natefinch | ^^^^^ exactly | 18:51 |
| katco | that's what i needed to know... revisions stays in | 18:52 |
| ericsnow | katco: I thought there was a "version" field in the API stuff | 18:52 |
| katco | ericsnow: not that i can see. the variable is revision, but when discussed it's called version | 18:52 |
| ericsnow | katco: my point is that we can update the API spec to look like this: "GET id/resources/name" and "GET id/resources/name-2" | 18:53 |
| katco | ericsnow: bc afaict that's the same damn concept | 18:53 |
| ericsnow | katco: yeah, I was wrong :) | 18:53 |
| katco | ericsnow: i think we still need revision | 18:53 |
| katco | ericsnow: for reasons i highlighted prior | 18:54 |
| ericsnow | katco: I agree | 18:54 |
| ericsnow | katco: its the "-2" in the example I gave | 18:54 |
| ericsnow | katco: in the current spec it's the "[-revision]" part | 18:54 |
| katco | ericsnow: and actually... the current api spec says that id refers to the charm... does id represent a specific rev of the charm? | 18:55 |
| ericsnow | katco: it must | 18:55 |
| katco | ericsnow: if that's the case, then we don't need rev | 18:55 |
| katco | ericsnow: because it will already narrow the scope of the resource to that rev of the charm, and thus use the correct rev of resource automatically | 18:56 |
| ericsnow | katco: [-revision] is the resource revision, not the charm revision | 18:56 |
| katco | ericsnow: but the two are coupled | 18:56 |
| katco | ericsnow: new rev of resource implies new rev of charm | 18:56 |
| ericsnow | katco: ah, right | 18:56 |
| ericsnow | katco: the only catch is that you can change the resource revision for a given charm revision | 18:57 |
| katco | ericsnow: can you? that contradicts the edict that charms and resources are coupled | 18:57 |
| ericsnow | katco: my understanding is that the tuple of (charm rev, resource rev...) is the identifier | 18:59 |
| natefinch | yeah, there's a line in the spec that mentioned you can change the revision of a resource for a revision of the charm | 19:00 |
| natefinch | there is now a higher-order meta-revision for the charmRev+resourcesRev that we don't reallyhave a name for and doesn't have an identifier... which seems bad | 19:00 |
| katco | yeah | 19:01 |
| ericsnow | katco: BTW, if the API should support charm IDs that don't have a revision then [-revision] (for the resource) *is* necessary (a point you were making) | 19:01 |
| ericsnow | katco: I have a feeling that we'll have to support that | 19:01 |
| ericsnow | natefinch: yeah, that | 19:01 |
| katco | is this confusing to anyone else? | 19:02 |
| natefinch | katco: I had the exact same confusion which I brought up with Rick... because it seemed logical to increment the charmrev when we changed resources... but the charmrev is just for the charm code | 19:02 |
| ericsnow | katco: uh, yeah :/ | 19:02 |
| natefinch | help us rick_h_, you're our only hope | 19:02 |
| katco | ericsnow: natefinch: i mean i get it now that it's been explained... but man... i feel like we have this conversation *every* *time* | 19:02 |
| natefinch | katco: yep | 19:03 |
| ericsnow | katco: I was just thinking that | 19:03 |
| natefinch | katco: and if the developers on the project have this confusion, what about users? | 19:03 |
| katco | natefinch: yes, this. | 19:03 |
| ericsnow | natefinch: they only need to know that they can change a resource revision for a given charm revision | 19:03 |
| natefinch | ericsnow: right, but when Bill says "hey, my MySql charm seems broken" and Laura asks "Oh, what version are you running?" ... how is he going to answer that? | 19:04 |
| ericsnow | natefinch: yep | 19:05 |
| ericsnow | natefinch: not ideal | 19:05 |
| katco | natefinch: it does seem broken to not rev the charm when you rev a resource | 19:05 |
| katco | natefinch: effectively that's a new build | 19:05 |
| ericsnow | katco: identifying your configuration | 19:06 |
| katco | natefinch: unless you looks at it like a shared lib which -- as long as it's revving a minor version -- can be swapped out | 19:06 |
| natefinch | katco: I think we just need the higher-order concept. It's very useful to know that between these two charm revisions, nothing in the code of the charm has changed | 19:06 |
| katco | natefinch: i agree | 19:06 |
| ericsnow | natefinch: I'd say that revving the charm with a resource change would do it | 19:07 |
| natefinch | katco: if we had a charm-overall-revision, which always got bumped if anything changed, then at least people could just say "I am running mysql v1.2" and that would relate to a single charm-code-rev and resources-revs | 19:07 |
| ericsnow | katco: yeah, though it may make sense to call that the charm revision and call what that is currently something like "charm info revision" | 19:09 |
| katco | natefinch: ericsnow: i dunno. why introduce a new concept? why not just have the charm version rev anytime anything with it changes? | 19:11 |
| === alexisb-afk is now known as alexisb | ||
| katco | natefinch: ericsnow: any time a piece changes, the whole has changed | 19:11 |
| ericsnow | katco: to distinguish between the-charm-changed and a-resource-changed | 19:11 |
| natefinch | we should discuss with jam and rick_h_ when they're available. I'm sure they have a reason why it is how it is. | 19:12 |
| katco | natefinch: i think we're too close to change anything really, but would be interesting to discuss at any rate | 19:12 |
| ericsnow | katco: we've definitely implemented the feature with the understanding that resource revisions are not fixed for a charm revision | 19:14 |
| ericsnow | (though the resource names *are* by virtue of the metadata.yaml) | 19:14 |
| natefinch | also, keep in mind, you can always upload different bytes for the resources... and then what? Now you have mysql 1.2, except one of the resources is differnt. | 19:15 |
| natefinch | given that, I think having an overall revision that makes any sense is not possible | 19:16 |
| natefinch | which sucks... but also doesn't mean someone can't come up with a name for the concept of the tuple of charm-code-rev + resources-revs | 19:18 |
| natefinch | preferably without using the word tuple | 19:18 |
| ericsnow | natefinch: are you saying that the resource file for a given resource revision may change? | 19:19 |
| natefinch | katco, ericsnow: BOOM! 5 more points for this iteration | 19:19 |
| ericsnow | natefinch: sweet!!! | 19:19 |
| katco | natefinch: duuuuuud! you rock! | 19:19 |
| katco | natefinch: you just got us a high score on points for an iteration :D | 19:20 |
| katco | natefinch: AND pushed our projected delivery to not just the xenial release, but the FFE deadline | 19:20 |
| natefinch | katco, ericsnow: https://www.youtube.com/watch?v=l0e8ZMVqVCc&t=82 | 19:22 |
| katco | natefinch: wtg crash override | 19:23 |
| natefinch | ericsnow: no no... I'm saying that we can't have an overall revision for a charm, because any time you upload a resource, it would invalidate that overall revision,and now you're just on some-custom-revision for your overall-revision of the charm | 19:24 |
| natefinch | ericsnow: I was just thinking about the conversation between Bill and Laura... sure, if Bill hasn't uploaded anythnig, he could say he's on mysql 1.2, but as soon as he uploads a custom resource, he has to fall back to talking about charm-code-rev + resource-rev | 19:25 |
| ericsnow | natefinch: right, it's a mess | 19:26 |
| * natefinch puts on the Hackers soundtrack | 19:26 | |
| ericsnow | either way | 19:26 |
| katco | natefinch: such a good soundtrack | 19:27 |
| natefinch | katco: yeah, really awesome soundtrack | 19:27 |
| natefinch | we should merge master if we can... the tests keep popping up that annoying browser thingy | 19:29 |
| katco | natefinch: i can take care of that | 19:29 |
| natefinch | cool | 19:29 |
| natefinch | then we can get our latest goodness into peoples' hands | 19:29 |
| natefinch | (after merging into master) | 19:30 |
| katco | sinzui: will ci run on feature-resources this weekend? | 20:21 |
| sinzui | katco: No. CI doesn't test branches on weekends because all resources are used for repeatability and reliability trests | 20:22 |
| katco | sinzui: do you think we could get a bless before EoD? that way we can merge into master before EoD | 20:23 |
| sinzui | katco: no, lxd is not testing that will take us to about the time branch testing will stop | 20:24 |
| katco | sinzui: ah ok | 20:24 |
| sinzui | katco: maybe I want to disable weakend tests. | 20:24 |
| sinzui | katco: your branch and others might test if I can disable or jut run the minimum set of tests | 20:24 |
| katco | sinzui: well, just lmk so i know when we can merge into master | 20:25 |
| sinzui | okay katco. | 20:26 |
| katco | ericsnow: natefinch: don't forget to email me your 360 picks | 20:29 |
| ericsnow | katco: k | 20:30 |
| perrito666 | ohh picks | 20:30 |
| natefinch | katco: oops | 20:30 |
| perrito666 | I read pics | 20:30 |
| natefinch | that is a lot of pics | 20:30 |
| natefinch | hope you like pics of my kids | 20:30 |
| katco | perrito666: >.< | 20:30 |
| natefinch | katco: I'm definitely not choosing ericsnow ;) | 20:30 |
| ericsnow | natefinch: me either :) | 20:31 |
| katco | natefinch: i've heard of this ericsnow guy. kind of a wild card? really loud? works out of a secret room? | 20:31 |
| natefinch | katco: drinks like a fish, too | 20:31 |
| katco | natefinch: yeah... that's the one | 20:31 |
| perrito666 | ericsnow: I prefer your previous background, looked more conspiracy theorist | 20:31 |
| ericsnow | perrito666: sometimes I miss that closet, but I get over it a few seconds later :) | 20:32 |
| natefinch | ericsnow: aren't you behind a secret door, now? | 20:33 |
| katco | natefinch: ^^^ "secret room" | 20:33 |
| ericsnow | natefinch: of course not, that's ridiculous! | 20:33 |
| natefinch | katco: I just meant, secret door >> closet | 20:33 |
| katco | his house is practically the size of a super-villain's secret island | 20:33 |
| natefinch | ^ this is true | 20:33 |
| katco | speaks parseltongue | 20:34 |
| katco | it's legit. ericsnow is an evil character | 20:34 |
| ericsnow | katco: I wish none of you had found out; was starting to like you | 20:35 |
| perrito666 | ericsnow: was definitely more evil character when we had standup in the mornings with wild hair and the creepy basement background | 20:35 |
| katco | LOL | 20:35 |
| * ericsnow flips some switches | 20:35 | |
| * natefinch would quit with some mysterious message... but sometimes it takes xchat 5+ minutes to log back in :/ | 20:37 | |
| katco | natefinch: you need a bouncer my friend | 20:37 |
| perrito666 | or, to learn /leave or /part | 20:38 |
| natefinch | aww... learning... | 20:38 |
| perrito666 | natefinch: btw, there is something wrong with your xchat, I presume it is the fact that you use xchat instead of hexchat | 20:38 |
| natefinch | perrito666: it seems to slowly be getting better... maybe it was just a head cold | 20:46 |
| perrito666 | natefinch: but seriously, hexchat is a fork of xchat with better maintenance | 20:47 |
| natefinch | perrito666: I'm all for that | 20:47 |
| natefinch | perrito666: of course that requires me figuring out what my password is for the canonical servers | 20:52 |
| perrito666 | natefinch: xchat2 stores it in plaintext, obviously | 20:55 |
| natefinch | perrito666: lol | 20:55 |
| natefinch | perrito666: so it does. Nice | 20:56 |
| perrito666 | well, I dont know if nice is the word I would use | 20:59 |
| === natefinch_ is now known as natefinch | ||
| natefinch | perrito666, I was being sarcastic | 21:01 |
| perrito666 | natefinch: irc lacks sarcasm | 21:01 |
| natefinch | well, seems to work, and logged right in | 21:01 |
| natefinch | perrito666: I think irc lacks non-sarcasm | 21:02 |
| natefinch | perrito666: thanks... that was pretty painless, and I'm happy to be on a better maintained product. | 21:05 |
| perrito666 | happy to help | 21:10 |
| perrito666 | while I was using it I found it to be very nice | 21:10 |
| katco | ericsnow: standup time | 21:31 |
| katco | ericsnow: ping? | 21:37 |
| rick_h_ | natefinch: just walked in from the airport | 21:50 |
| rick_h_ | natefinch: what's the fire? | 21:51 |
| katco | rick_h_: no fire, just friday silliness | 21:51 |
| rick_h_ | ah then wheeeeee | 21:51 |
| katco | rick_h_: you can travel in peace :) | 21:51 |
| rick_h_ | travel done, now for snow shoveling | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!