| mup | Bug #1554797 opened: juju 2.0 bootstrap should explain what was missing <juju-core:New> <https://launchpad.net/bugs/1554797> | 00:05 |
|---|---|---|
| mup | Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802> | 00:05 |
| mup | Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807> | 00:05 |
| alexisb | so a noob go question what exactly does the "..." do | 00:10 |
| alexisb | so for example you have "...string" instead of "string" | 00:10 |
| davecheney | it's the varargs operator | 00:11 |
| davecheney | so in a function declaration | 00:11 |
| davecheney | func f (args ...string) lets you write | 00:11 |
| mup | Bug #1554802 changed: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802> | 00:11 |
| mup | Bug #1554807 changed: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807> | 00:11 |
| davecheney | f("a", "b", "c") | 00:11 |
| davecheney | inside f args will be of type []string | 00:12 |
| alexisb | ok thanks davecheney | 00:12 |
| davecheney | alexisb: https://golang.org/ref/spec#Passing_arguments_to_..._parameters | 00:12 |
| menn0 | alexisb: also: https://gobyexample.com/variadic-functions | 00:12 |
| davecheney | it's slightly confusing when using f if you aready have a []string | 00:13 |
| davecheney | in that case you have to use the ... as a suffix | 00:13 |
| davecheney | var s []string | 00:13 |
| menn0 | alexisb: ... can also be used during a function call to expand a slice into separate arguments | 00:13 |
| davecheney | f(s...) // don't treat s, []string as a single argument, treat it as the arguments | 00:13 |
| alexisb | o! davecheney that last bit is very helpful | 00:14 |
| mup | Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802> | 00:14 |
| mup | Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807> | 00:14 |
| davecheney | alexisb: we have both styles inside juju | 00:18 |
| davecheney | if you have a fn that already uses a []string (or another slice) then it can be a little more work to pass it down to something else with the ... suffix | 00:18 |
| davecheney | OTOH we have many APIs that take a []slice of things, but almost always are called with just one thing | 00:19 |
| davecheney | so there is a lot of typing to declare a literal slice of just one thing, in which case changing those APIs to be variadic can make them more pleasant to use | 00:19 |
| alexisb | thank you davecheney; that explanation gave me the insight I needed to figure out how to update the func call | 00:21 |
| alexisb | geeze I wasted too much time on that :) | 00:21 |
| davecheney | wallyworld: everything was going so well | 00:22 |
| davecheney | lucky(~/src/github.com/juju/juju) % juju create-model testing2 | 00:22 |
| davecheney | ERROR provider validation failed: invalid EC2 provider config: model has no access-key or secret-key | 00:22 |
| davecheney | create model the right thing ? | 00:22 |
| davecheney | a controller has many models ? | 00:22 |
| davecheney | so if I have the local.testing controller | 00:22 |
| davecheney | i should be able to create a new model in that ? | 00:23 |
| wallyworld | davecheney: currently, as of forever, each time you create a new model, you need to supply credentials | 00:23 |
| wallyworld | but | 00:23 |
| wallyworld | there's a feature branch which relaxes that requirement | 00:23 |
| davecheney | so, i dn't need credentials to create the first model | 00:23 |
| wallyworld | if you are controller admin, you don't need to re-suipply | 00:23 |
| wallyworld | correct | 00:23 |
| davecheney | but every subsiquent one I do ? | 00:23 |
| davecheney | wat ? | 00:23 |
| wallyworld | yes, that was the jes design | 00:23 |
| wallyworld | you were on that team :-) | 00:24 |
| davecheney | so much for avoiding head trauma | 00:24 |
| davecheney | wallyworld: I blame tim | 00:24 |
| davecheney | by default | 00:24 |
| wallyworld | we are fixing it for 2.0. there was a valid reason at the time | 00:24 |
| arosales | Hello juju-core! | 00:37 |
| arosales | should I see juju 2.0 in the Xenial archive when I apt-cache search or apt-get install juju? | 00:37 |
| arosales | I am currently only seeing 1.25, but could be pilot error | 00:37 |
| arosales | scratch that I see 2.0-beta1-0ubuntu1~16.04.1~juju1 in the archive | 00:39 |
| arosales | keep up the good work. Looking forward to beta2 | 00:40 |
| axw | wallyworld: hey sorry I missed standup, didn't get home till 1:30am, so slept in a bit | 00:51 |
| davecheney | wallyworld: is the format of creds.yaml document ? | 00:51 |
| wallyworld | davecheney: it's in the release notes | 00:51 |
| wallyworld | axw: no worries :-) did you want a chat now? | 00:51 |
| davecheney | wallyworld: ta | 00:51 |
| axw | wallyworld: sure, will be in tanzanite in a minute | 00:52 |
| wallyworld | davecheney: the tooling is improving around managing creds, not quite there yet | 00:52 |
| alexisb | wow, first experience of existing unit test catching an actual error I introduced into the code | 00:52 |
| alexisb | nice | 00:52 |
| wallyworld | davecheney: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U | 00:53 |
| wallyworld | alexisb: yay tests :-) | 00:53 |
| alexisb | btw davecheney I always blame tim by default as well ;) | 00:53 |
| axw | wallyworld: there now | 00:54 |
| mup | Bug #1554819 opened: juju help create-model is misleading <juju-core:New> <https://launchpad.net/bugs/1554819> | 01:09 |
| perrito666 | wallyworld: are you around? | 01:09 |
| wallyworld | perrito666: in standup hangout with andrew | 01:09 |
| perrito666 | jam: you dont have the pre push script in your git | 01:09 |
| perrito666 | wallyworld: that is an invitation? | 01:09 |
| wallyworld | we are talking work stuff so feel free | 01:10 |
| katco | wallyworld: natefinch: fyi: https://github.com/juju/juju/compare/nate-minver#files_bucket | 01:13 |
| wallyworld | katco: ty, will look after meeting | 01:13 |
| katco | wallyworld: natefinch: nate-minver has master merged in; can merge into master with a bless | 01:13 |
| thumper | well that took longer than I was expecting... | 01:18 |
| thumper | but I guess I should expect that | 01:18 |
| thumper | menn0: http://reviews.vapour.ws/r/4100/ | 01:20 |
| menn0 | thumper: looking | 01:26 |
| thumper | menn0: I'm just preparing a branch to merge master into model-migration | 01:26 |
| thumper | menn0: and I'm thinking we should merge model-migration-control into model-migration | 01:26 |
| menn0 | thumper: I was thinking the same thing | 01:27 |
| thumper | menn0: because you are going to want these functions RSN | 01:27 |
| menn0 | thumper: indeed | 01:27 |
| thumper | cool | 01:27 |
| thumper | let's get model-migration synced up with master first | 01:27 |
| thumper | because I think model-migration-control is ahead of it there | 01:27 |
| menn0 | thumper: CI has picked up a timing problem with one of the tests which I'm working on now | 01:27 |
| menn0 | thumper: and we can merge afterwards | 01:27 |
| thumper | sounds good | 01:28 |
| * thumper has make check running on merge master | 01:28 | |
| thumper | good time to go make a coffee | 01:28 |
| thumper | yep | 01:38 |
| thumper | tests still running | 01:38 |
| davecheney | thumper: that's how you know your change is good :) | 01:38 |
| davecheney | thumper: how long do the tests ttake on your machine ? | 01:38 |
| davecheney | mine are the best part of 30 mins | 01:38 |
| thumper | I don't think I have timed a full run recently | 01:39 |
| thumper | it used to be around 23 minutes | 01:39 |
| davecheney | it takes 25 mins in CI | 01:44 |
| davecheney | my times are 30-40 mins locally | 01:44 |
| thumper | hmm... | 01:48 |
| thumper | my machine has going suspiciously quiet | 01:48 |
| davecheney | time.Sleep(60 * time.Minute) | 01:48 |
| thumper | github.com/juju/juju/cmd/jujud/dumplogs | 01:48 |
| thumper | last pass | 01:48 |
| davecheney | somethings' waiting for monog to time out | 01:49 |
| davecheney | then you will receive _ALL_ the stack traces | 01:49 |
| thumper | \o/ | 01:49 |
| davecheney | lucky(~/src/github.com/juju/juju) % juju list-models | 01:54 |
| davecheney | NAME OWNER LAST CONNECTION | 01:54 |
| davecheney | testing admin@local 20 seconds ago | 01:54 |
| davecheney | lucky(~/src/github.com/juju/juju) % juju destroy-model testing | 01:54 |
| davecheney | ERROR "testing" is a controller; use 'juju destroy-controller' to destroy it | 01:54 |
| davecheney | so, is "testing" a model or not !?! | 01:54 |
| thumper | davecheney: cmd/jujud/reboot timed out | 02:04 |
| davecheney | rup row | 02:04 |
| thumper | davecheney: testing is probably the controller model | 02:04 |
| thumper | ah poo | 02:07 |
| thumper | someone has added another exported field to serviceDoc | 02:07 |
| * thumper goes to see what it is | 02:07 | |
| thumper | CharmModifiedVersion | 02:08 |
| thumper | wallyworld: do you know about this? ^^ | 02:08 |
| thumper | maybe? | 02:08 |
| wallyworld | thumper: that i believe is from the resources work | 02:08 |
| thumper | hmm.. | 02:08 |
| thumper | yeah | 02:08 |
| thumper | nate did it | 02:08 |
| wallyworld | it is used to track whether a chanr for a service has changed at all | 02:09 |
| wallyworld | and fires a hook if needed | 02:09 |
| thumper | for what purpose? | 02:09 |
| wallyworld | if resources change | 02:09 |
| wallyworld | a hook is fired | 02:09 |
| wallyworld | it uses the same pattern as we use for config-changed hooks | 02:09 |
| wallyworld | thumper: although why that is on the serviceDoc i am not sure | 02:10 |
| wallyworld | i guess for config we always fire an initial config changed hook | 02:11 |
| wallyworld | whereas for charm-upgrade we don't want to do that | 02:11 |
| davecheney | menn0: 2016-03-09 00:08:41 INFO juju.worker runner.go:281 stopped "engine", err: cannot open api: agent should be terminated | 02:15 |
| davecheney | is this a dependency engine thing ? | 02:16 |
| davecheney | i've never seen that final error message | 02:16 |
| menn0 | davecheney: that's something fwereade's been working on I believe although I didn't realise it was in master | 02:18 |
| menn0 | davecheney: when are you seeing it? | 02:18 |
| davecheney | in master | 02:18 |
| menn0 | davecheney: I under conditions I meant? | 02:19 |
| davecheney | oh, bootstrap worked but the rest of the agents in the deploy just went to sleep and never woke | 02:21 |
| davecheney | i'll have to redeploy to figure out what happened | 02:21 |
| davecheney | to be fair, I did a backup while units were deploying | 02:21 |
| davecheney | then restored the backup over the top | 02:21 |
| menn0 | davecheney: that would do it | 02:21 |
| davecheney | I didn't expect that to be a good result | 02:21 |
| davecheney | i just wanted to see how many pieces broke off | 02:22 |
| menn0 | davecheney: i believe that you get that error when a machine or entity can't be found at login (or is no longer in the Alive state) | 02:22 |
| menn0 | davecheney: they thing that connects to the API returns that error in that case, which has special meaning: stop the agent and uninstall from the init system so it doesn't get restarted | 02:23 |
| menn0 | davecheney: that behaviour has been there forever | 02:23 |
| menn0 | davecheney: but Will has been fixing and improving that functionality | 02:23 |
| davecheney | and that is indeed what it did | 02:23 |
| davecheney | agent stoped and the upstart job went away | 02:23 |
| menn0 | davecheney: i'm not sure if you're dealing with the old or the new version of it (not sure where fwereade is at with merging) | 02:23 |
| menn0 | davecheney: I have no idea how restore is actually supposed to be used - i.e. what are the expected preconditions | 02:25 |
| davecheney | me neither | 02:25 |
| davecheney | which makes it a bit hard to tell if I broke it | 02:25 |
| menn0 | thumper: review done | 02:26 |
| thumper | menn0: ta | 02:26 |
| menn0 | davecheney: really though you shouldn't be able to hose things like this using it | 02:26 |
| thumper | davecheney: can I get you to try cmd/jujud/reboot tests? | 02:32 |
| thumper | even running by themselves, they are timing out | 02:32 |
| thumper | menn0: re Backend | 02:42 |
| thumper | menn0: was talking to fwereade this morning | 02:42 |
| thumper | before that it was stateMethods | 02:42 |
| thumper | he suggested using backend | 02:43 |
| thumper | so I went for consistency | 02:43 |
| thumper | happy to be more descriptive | 02:43 |
| menn0 | thumper: I was thinking something like BinariesUploadBackend, or just UploadBackend | 02:43 |
| thumper | hmm... | 02:43 |
| menn0 | thumper: given that there's other stuff in migration.go that's not related to tools/charms upload | 02:44 |
| menn0 | thumper: I don't feel too strongly about it if you disagree | 02:44 |
| thumper | hmm... | 02:44 |
| thumper | sounds fine | 02:44 |
| * thumper makes changes | 02:44 | |
| thumper | tools/lxdclient/client_instance.go:331: wrong number of args for format in Tracef call: 1 needed but 2 args | 02:49 |
| thumper | how did this even get into master? | 02:49 |
| menn0 | thumper: yeah, I saw that too | 02:49 |
| thumper | I thought we caught that shit | 02:49 |
| davecheney | % juju deploy wordpress -n 3 && juju deploy mysql -n 2 && juju add-relation wordpress mysql | 02:50 |
| davecheney | [Units] | 02:50 |
| davecheney | ID WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE | 02:50 |
| davecheney | mysql/0 error idle 2.0-beta2.1 4 3306/tcp 54.160.80.170 hook failed: "db-relation-joined" for wordpress:db | 02:50 |
| davecheney | mysql/1 unknown idle 2.0-beta2.1 5 3306/tcp 54.205.17.37 | 02:50 |
| davecheney | wordpress/0 unknown executing 2.0-beta2.1 1 80/tcp 54.226.146.198 | 02:50 |
| davecheney | wordpress/1 maintenance executing 2.0-beta2.1 2 54.204.148.132 (config-changed) installing charm software | 02:50 |
| davecheney | wordpress/2 unknown executing 2.0-beta2.1 3 80/tcp 54.159.101.133 | 02:50 |
| davecheney | \o/ reproducable builds | 02:50 |
| natefinch | thumper: I'm around if you want to talk about CharmModifiedVersion | 02:59 |
| natefinch | actually, brb | 03:02 |
| natefinch | back | 03:05 |
| thumper | menn0: http://reviews.vapour.ws/r/4100/ updated | 03:09 |
| thumper | hi natefinch | 03:09 |
| thumper | natefinch: what is the purpose of the number? | 03:10 |
| natefinch | thumper: we needed to update the service doc such that it would trigger charm-upgrade for something other than changing its charm url | 03:10 |
| natefinch | thumper: this is because charm-upgrade is supposed to fire when resources change | 03:11 |
| natefinch | thumper: so when resources change, we increment CharmModifiedVersion (we also increment it when the charm url changes, just in case) | 03:11 |
| thumper | ok | 03:13 |
| natefinch | thumper: the PR review, if you're curious: http://reviews.vapour.ws/r/3910/ | 03:14 |
| mup | Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863> | 03:15 |
| thumper | menn0: my update to model-migrations landed (master) | 03:17 |
| thumper | menn0: I'll propose one that merges model-migration-control | 03:17 |
| thumper | and look | 03:17 |
| mup | Bug #1554863 changed: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863> | 03:18 |
| mup | Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863> | 03:21 |
| thumper | menn0: http://reviews.vapour.ws/r/4102/ | 03:23 |
| thumper | if you are happy to merge that branch in, lets do it | 03:23 |
| menn0 | thumper: yep, I have that test fix ready | 03:26 |
| menn0 | thumper: 2 secs | 03:26 |
| thumper | menn0: so.. you are going to merge one final thing into the model-migratiion-control branch first? | 03:27 |
| thumper | menn0: when it has the right commits, I'll let you get the bot to merge the two | 03:27 |
| menn0 | thumper: yep, just this: http://reviews.vapour.ws/r/4103/ (review pls) | 03:27 |
| menn0 | thumper: yep, I can handle the merge | 03:27 |
| natefinch | wallyworld: you around? | 03:28 |
| menn0 | thumper: mm-control into mm right? | 03:28 |
| wallyworld | yup | 03:28 |
| thumper | menn0: yeah, this one: https://github.com/juju/juju/pull/4662 | 03:28 |
| menn0 | thumper: ah right, you've already done the merge | 03:29 |
| thumper | menn0: well, I clicked on a github button | 03:29 |
| thumper | not a lot to do really :) | 03:29 |
| wallyworld | natefinch: did you have a q? | 03:29 |
| menn0 | thumper: so that PR should update if I get further changes into model-migration-control I guess | 03:30 |
| thumper | menn0: why add the wait? | 03:31 |
| * thumper actually reads the comment | 03:32 | |
| natefinch | wallyworld: yes, so... I was going to write those tests for charm push-resource by mocking out the http Client... however, it occurs to me, that it's pretty damn fragile to do it that way. I mean, it requires the tests to know what exact responses some package two layers away is expecting.. totally breaks encapsulation and relies on internal implementation details. | 03:32 |
| thumper | menn0: to be honest, still not sure why it waits | 03:33 |
| menn0 | thumper: yeah, it took me a while of looking at the shared api watcher loop code to figure it out | 03:33 |
| menn0 | thumper: there's a goroutine which calls Stop as the client side loop exits. it's outside of the main loop monitored by the tomb and can run *after* the worker loop exits | 03:33 |
| menn0 | thumper: it never happens on my machine but it does in CI, especially on i386, ppc and arm | 03:34 |
| wallyworld | natefinch: yeah, for unit tests that's not very useful. that's where the CharmStore strcu can help. but then we need tests to ensure CharmStore does the right thing. and we do at some point need to next the calling of the csclient | 03:34 |
| thumper | menn0: but what does that do? | 03:34 |
| thumper | menn0: so are we saying that sometimes on other architectures, the results don't come as fast? | 03:35 |
| menn0 | thumper: yep, on slower or different archs that cleanup goroutine runs a bit later and so the test wasn't seeing the Stop call | 03:35 |
| menn0 | thumper: https://github.com/juju/juju/blob/master/api/watcher/watcher.go#L73-L86 | 03:36 |
| thumper | menn0: shipit | 03:37 |
| menn0 | thumper: ship it for http://reviews.vapour.ws/r/4100/ | 03:38 |
| menn0 | 2 little suggestions | 03:38 |
| natefinch | wallyworld: well, I have tests to test that charmstore works and I have tests that test that csclient works... we should also have some full stack CI and/or feature tests, but if those fail, it really just means we have some assumptions that aren't well communicated in our APIs and not covered in our unit tests, which could be fixed easily. | 03:41 |
| natefinch | s/charmstore/charmrepo.CharmStore | 03:41 |
| thumper | menn0: ta | 03:42 |
| wallyworld | natefinch: yep, a feature test to round it all out sounds like is all we need now | 03:42 |
| natefinch | wallyworld: ok | 03:42 |
| thumper | menn0: ah... yeah, sould have fixed those | 03:42 |
| natefinch | my kingdom for people to use an interface, once in a while, somewhere. | 04:23 |
| mup | Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867> | 04:24 |
| mup | Bug #1507867 opened: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867> | 04:36 |
| mup | Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867> | 04:39 |
| mup | Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561> | 04:39 |
| natefinch | ug.... I can't believe the charm command depends on code inside github.com/juju/juju .... and of course it's now broken | 04:42 |
| mup | Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561> | 04:48 |
| mup | Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561> | 04:54 |
| wallyworld | axw: could i get a small review? https://github.com/juju/charm/pull/196 | 05:32 |
| axw | wallyworld: ok, looking | 05:33 |
| axw | wallyworld: VerifyLocal isn't used anywhere except in a test. where will it be used? | 05:40 |
| axw | wallyworld: oh, this is just the charm package. it'll be used in juju... never mind | 05:41 |
| wallyworld | axw: i'm doing a core branch that will use it - wehn we deploy bundles with local charm paths | 05:41 |
| axw | wallyworld: LGTM | 05:41 |
| wallyworld | i almost have that branch ready | 05:41 |
| wallyworld | ty | 05:41 |
| davecheney | dummy is the only provider that imports the apiserver | 06:41 |
| davecheney | and it doesn't do anything with the api | 06:41 |
| davecheney | if I delete the call to the apiserver from Dummy's bootstrap method | 06:41 |
| davecheney | millions of tests fail | 06:41 |
| TheMue | morning o/ | 08:10 |
| jam | davecheney: fundamentally after bootstrap completes we should have an API server running. Its just that all other bootstraps do it via "jujud bootsrap-???". | 08:20 |
| fwereade | davecheney, the main thing is that the dummy provider is basically evil -- but I'm pretty sure it *does* do things with the api? in that it exposes the info necessary to connect to the api, which comes from the apiserver it actually runs | 08:59 |
| fwereade | davecheney, the fact that a "dummy" provider goes so far as to actually run an apiserver is the heart of the problem | 09:00 |
| fwereade | davecheney, life would be better if dummy were dumber | 09:00 |
| fwereade | davecheney, jam: is there a name for that style of test double, that attempts to *simulate* some external component, and invariably ends up hideously complex and brittle? | 09:01 |
| dooferlad | frobware: hangout? | 09:02 |
| davecheney | fwereade: i want to find out what dummy is doing and move it into a test suite | 09:31 |
| davecheney | the interesting thing is not all of the tests fail, only some packages, albeit spectularly | 09:32 |
| davecheney | so I suspect that a byproduct of importing dummy is the get a sort of kind of working api server, which we helpfully advertise via a package singleton, and have logic that avoids reinitalising it if it is already present | 09:32 |
| fwereade | davecheney, yeah, and we have that happy fun Reset lark as well :( | 09:34 |
| fwereade | davecheney, fwiw, tests that *don't* fail when you break dummy would be excellent candidates for disentangling from JujuConnSuite, I think | 09:35 |
| fwereade | davecheney, easier bits to carve off the edges, hopefully makes it easier to see what the pleftover problematic tests are depending on, maybe? | 09:35 |
| davecheney | the sadface was I wasn't trying to eviscerate dummy | 09:39 |
| davecheney | i was actually doing some refactoring of th apiserver | 09:39 |
| davecheney | and found a bonkers circular dependency from juju/testing to dummy to the apiserver | 09:39 |
| frobware | dimitern, jam: standup? | 10:03 |
| rogpeppe | i need a second review on this simple change to the charm package; anyone care to take a look? https://github.com/juju/charm/pull/195 | 10:39 |
| dimitern | rogpeppe, isn't it better to switch to yaml.v2 throughout? | 10:43 |
| rogpeppe | dimitern: i'm not going to be responsible for changing juju-core to use yaml.v2 throughout | 10:43 |
| dimitern | rogpeppe, I meant the charm package | 10:44 |
| rogpeppe | dimitern: and it's kinda reasonable to be compatible with both, i think | 10:44 |
| rogpeppe | dimitern: it does use yaml.v2 only | 10:44 |
| rogpeppe | dimitern: but clients can use yaml.v1 to marshal a Meta value | 10:44 |
| rogpeppe | dimitern: and i don't want to break that | 10:44 |
| dimitern | rogpeppe, any important differences between v1 and v2 wrt behavior ? | 10:45 |
| rogpeppe | dimitern: there are a few differences - i think they were documented somewhere | 10:45 |
| rogpeppe | dimitern: *most* of juju-core seems to use v2 now | 10:45 |
| dimitern | rogpeppe, so marshaling with v1 and unmarshaling with v2 works as well as vice versa? | 10:45 |
| rogpeppe | dimitern: it's possible that the only two places in core which use v1 are doing so by mistake | 10:46 |
| rogpeppe | dimitern: yeah | 10:46 |
| rogpeppe | dimitern: it's still YAML | 10:46 |
| dimitern | rogpeppe, btw I had some issues recently with changes spanning multiple subrepos with slightly different dependencies.tsv | 10:47 |
| rogpeppe | dimitern: yeah, it can be awkward | 10:47 |
| rogpeppe | dimitern: i've found the new -N flag to godeps very useful | 10:47 |
| dimitern | rogpeppe, it turned out we don't have a good way of enforcing same revs across multiple related projects | 10:47 |
| rogpeppe | dimitern: for converging on an agreed set of deps | 10:47 |
| dimitern | rogpeppe, what does it do? | 10:47 |
| rogpeppe | dimitern: it updates dependencies only if the deps are newer than what's already there | 10:48 |
| dimitern | rogpeppe, that's useful indeed | 10:48 |
| rogpeppe | dimitern: i think there is fundamentally no way of enforcing revs across projects | 10:48 |
| rogpeppe | dimitern: separate projects are independent | 10:49 |
| dimitern | rogpeppe, there should be a way to declare nested deps for juju/juju/ at least and other standalone projects | 10:49 |
| dimitern | rogpeppe, that PR LGTM btw | 10:49 |
| rogpeppe | dimitern: what do you mean by "nested deps"? | 10:50 |
| dimitern | rogpeppe, i.e. dependencies.tsv or juju/juju "including" other .tsvs per import path | 10:50 |
| rogpeppe | dimitern: what would it do if those tsvs conflicted? | 10:51 |
| dimitern | rogpeppe, some way to verify revisions in juju/juju/deps.tsv for repo X matches the rev used by repo Y that depends on X, and juju/juju depends on both X and U | 10:51 |
| dimitern | s/U/Y/ | 10:51 |
| rogpeppe | dimitern: that sounds like it's going to produce conflicts more often than not | 10:52 |
| dimitern | rogpeppe, if they conflicted, you can know and do something about it, rather than get random build failures for subrepos (like I had for charm.v6 recently) | 10:52 |
| rogpeppe | dimitern: what I tend to do now is something like: for repo in $(awk '{print $1' < dependencies.tsv}); godeps -N -u $(godir $repo)/dependencies.tsv; done | 10:53 |
| dimitern | because charm.v6 needs bundlechanges, which in turn needs revX of yaml.v1 (and charm.v6 uses revY of yaml.v2), effectively refusing to build charm.v6 unless it also depends on yaml.v1 with same revX | 10:54 |
| rogpeppe | dimitern: you got a build failure in charm.v6 because of a juju/juju tsv file? | 10:54 |
| rogpeppe | dimitern: if in doubt, choose the latest version of all dependencies | 10:55 |
| rogpeppe | dimitern: because it's fairly unusual for something to depend on being *earlier* than a certain revision | 10:55 |
| dimitern | rogpeppe, yeah, that's what I usually do - and that works well for repos with merge gating that uses godeps -u as part of testing the merge | 10:55 |
| rogpeppe | dimitern: one problem is that it's allowed to have cyclic dependencies between repos | 10:57 |
| rogpeppe | dimitern: at least you had a build failure rather than a bug later on | 10:57 |
| dimitern | rogpeppe, yeah, that's causing some of the issues I suppose | 10:58 |
| rogpeppe | dimitern: i found that godeps -N eased my pain quite a bit | 10:58 |
| dimitern | rogpeppe, this is the issue I was talking about: https://github.com/juju/bundlechanges/pull/16 | 10:58 |
| rogpeppe | dimitern: 'cos you can just run it without worrying too much | 10:58 |
| dimitern | rogpeppe, bundlechanges thus far didn't have to depend on yaml.v2, but without it it won't build as charm.v6 needs it | 10:59 |
| rogpeppe | dimitern: charm.v6 doesn't need it | 11:00 |
| rogpeppe | dimitern: only its tests do | 11:00 |
| rogpeppe | dimitern: if you run godeps, it'll tell you that | 11:00 |
| dimitern | rogpeppe, so you're saying that gating job for bundlechanges should've called godeps -u -t dependencies.tsv instead? | 11:03 |
| rogpeppe | dimitern: i don't understand. that's an invalid godeps command. | 11:04 |
| rogpeppe | dimitern: the gating job for bundlechanges should always call godeps -u dependencies.tsv as usual | 11:05 |
| dimitern | rogpeppe, the "-t" according to "godeps -h" updates tests deps as well | 11:06 |
| rogpeppe | dimitern: ah, that's an ambiguity in the help. -t is a no-op with -u. | 11:08 |
| rogpeppe | dimitern: it only influences whether testing deps are printed without the -u flag. | 11:08 |
| rogpeppe | dimitern: -u always updates all the deps mentioned | 11:08 |
| dimitern | rogpeppe, ah, didn't know that detail :) thanks | 11:11 |
| rogpeppe | dimitern: i should probably make the docs clearer | 11:12 |
| dimitern | +1 :) | 11:16 |
| * dimitern steps out for ~1h | 11:16 | |
| xnox | who is on-call reviewer? | 12:08 |
| xnox | =) please review | 12:08 |
| xnox | https://github.com/juju/utils/pull/199 | 12:08 |
| TheMue | xnox: S390? Mainframe? | 12:16 |
| TheMue | xnox: neat | 12:16 |
| dooferlad | dimitern: http://reviews.vapour.ws/r/4002/ should, I hope, be ready. | 13:01 |
| * dooferlad goes for lunch | 13:02 | |
| dimitern | dooferlad, cheers, will look shortly | 13:02 |
| mup | Bug #1555083 opened: Certificate error when visiting the embedded Juju GUI <juju-core:New> <https://launchpad.net/bugs/1555083> | 13:34 |
| dimitern | dooferlad, we should have a quick chat when you're back | 13:56 |
| perrito666 | I am not sure you people saw this since its the sort of stuff that happens during the night :p | 14:12 |
| perrito666 | https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD29j5LRb96QZC4mZDn72gAE4/edit#gid=0 | 14:12 |
| perrito666 | quite interesting | 14:12 |
| perrito666 | comes from https://github.com/davecheney/benchjuju | 14:12 |
| natefinch | ...and this is why I still build with 1.4 | 14:15 |
| natefinch | btw, the discussion among the Go devs: https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o | 14:17 |
| natefinch | also, looks like the govmomi code is a SIGNIFICANT addition to our compile times | 14:19 |
| natefinch | and this is probably why: https://github.com/juju/govmomi/blob/master/vim25/types/types.go | 14:20 |
| perrito666 | natefinch: curious name :p | 14:22 |
| natefinch | perrito666: it's the vmware cloud api wrapper | 14:23 |
| perrito666 | I was talking about the vim part :p | 14:23 |
| natefinch | yeah, dunno | 14:25 |
| perrito666 | the whole juju takes 1m3.982s here | 14:27 |
| perrito666 | 55s of that are jujud | 14:28 |
| natefinch | perrito666: what go version are you using, and did you remove $GOPATH/pkg first? | 14:28 |
| perrito666 | 1.5 | 14:29 |
| perrito666 | natefinch: yep | 14:29 |
| perrito666 | on my desktop | 14:29 |
| perrito666 | if I tried this on my laptop I would get significantly higher numbers | 14:30 |
| TheMue | simply imagine juju would be written in C++ making high usage of boost. | 14:30 |
| TheMue | heya btw | 14:31 |
| natefinch | perrito666: is that real time or user time? | 14:31 |
| perrito666 | natefinch: real | 14:32 |
| perrito666 | natefinch: do you know how can I run the test build step without running the actual tests? | 14:32 |
| natefinch | perrito666: go test -run=xxx | 14:35 |
| natefinch | perrito666: it's still slow as hell, since it builds a binary per package | 14:35 |
| perrito666 | natefinch: that is what I want | 14:35 |
| natefinch | perrito666: but obviously faster than actually running tests | 14:35 |
| * perrito666 times the test build times | 14:38 | |
| dooferlad | perrito666: to speed up subsequent runs go test -i will install deps rather than using them as a one-off build. | 14:42 |
| dooferlad | dimitern: did you want to jump in a hangout? | 14:43 |
| perrito666 | dooferlad: tx | 14:43 |
| natefinch | perrito666: 28s building with go 1.4.2, 1m5s building with go 1.5.3 | 14:44 |
| * natefinch goes back to 1.4 | 14:44 | |
| dimitern | dooferlad, sure, is top of the hour ok? | 14:45 |
| perrito666 | time go test --run=xxx github.com/juju/juju/... <--- 7m16.197 | 14:45 |
| dooferlad | dimitern: yep | 14:45 |
| dimitern | frobware, voidspace, dooferlad, please have a look at http://reviews.vapour.ws/r/4104/ | 14:47 |
| dooferlad | dimitern: *click* | 14:48 |
| ericsnow | natefinch: PTAL http://reviews.vapour.ws/r/4099/ | 14:48 |
| dimitern | the diff got messed up somewhat - ipaddresses_test.go is entirely new, while the legacy_ipaddresses_test.go is unchanged | 14:48 |
| ericsnow | natefinch: also, I responded in http://reviews.vapour.ws/r/4090/ | 14:48 |
| TheMue | natefinch: buy a faster computer *lol* | 14:51 |
| natefinch | TheMue: the fastest computer in the world isn't going to make 1.5 compile faster than 1.4 ;) | 14:51 |
| natefinch | ericsnow: thanks | 14:51 |
| perrito666 | interesting, when timing it some tests fail | 14:52 |
| ericsnow | natefinch: no, thank you! | 14:52 |
| katco | ericsnow: natefinch: o/ | 14:52 |
| ericsnow | katco: \o | 14:52 |
| natefinch | ericsnow: I think I'd prefer that service-exists check on the way out... so we are sure we don't get into a race condition | 14:52 |
| katco | ericsnow: natefinch: got master merged into minver... i think if we get a bless it will be in 2.0! | 14:52 |
| natefinch | katco: amazing, thanks so much! | 14:52 |
| TheMue | natefinch: that's right, I only described typical behavior needing always more faster computers to do the same as before | 14:52 |
| natefinch | TheMue: yep | 14:53 |
| ericsnow | katco: sweet | 14:53 |
| katco | natefinch: thanks for coding it up. just wish it wasn't a rushed blitz at the end to land features | 14:53 |
| ericsnow | natefinch: that's a good idea, I'll try it out | 14:53 |
| natefinch | ericsnow: i.e. try the DB op, see that it failed, check if the service exists, if not, then we have a good idea why it failed ;) | 14:53 |
| ericsnow | katco: the mad rush is really making it hard to collaborate with others in the same situation :( | 14:54 |
| katco | ericsnow: i know... there are many, many, negatives | 14:54 |
| natefinch | ericsnow, katco: working on reviews and getting my stuff landed this morning. See if we can drain that under review column some | 14:59 |
| ericsnow | natefinch: +1 | 15:00 |
| katco | yeah nk | 15:00 |
| dooferlad | dimitern: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ? | 15:00 |
| katco | i'm very sorry i haven't been able to perform reviews... i just have 1 last thing in my backlog | 15:00 |
| natefinch | esp since we don't actually have any points landed yet :/ | 15:00 |
| dimitern | dooferlad, omw | 15:01 |
| ericsnow | natefinch: I could land this one with re-review from katco (hint, hint): http://reviews.vapour.ws/r/3975/ | 15:01 |
| ericsnow | katco: :) | 15:01 |
| katco | ericsnow: ok ok you just popped to the head of the queue | 15:01 |
| perrito666 | natefinch: the almost full test run on my desktop 16m58.859s | 15:04 |
| natefinch | perrito666: yeah.... *shudder* | 15:04 |
| katco | cherylj: did you say the lxd instance with no ssh issue had a fix, or some progress had been made? | 15:04 |
| * TheMue remembers the times when juju has been so small running build and tests in a few seconds | 15:08 | |
| natefinch | TheMue: must have been long before I got here :) | 15:10 |
| katco | ericsnow: you have a review, sir | 15:15 |
| cherylj | katco: the outstanding issues that I know about with lxd have been addressed. | 15:15 |
| ericsnow | katco: (ノ^_^)ノ┻━┻ ┬─┬ ノ( ^_^ノ) | 15:16 |
| katco | cherylj: hm, ok. i think jrwren was having some issues | 15:16 |
| * ericsnow puts table back | 15:16 | |
| katco | lol | 15:16 |
| cherylj | heh | 15:16 |
| katco | ericsnow: you've been hanging around wwitzel3 too long | 15:16 |
| katco | cherylj: sounds like it may have been a lxd issue though... cmars is chatting with jrwren | 15:16 |
| katco | cherylj: hey, when can we expect a bless on the nate-minver branch? | 15:17 |
| cherylj | katco: I think that depends on the content of that branch ;) | 15:18 |
| cherylj | katco: are you asking when to expect a CI run? | 15:18 |
| katco | cherylj: yes :) | 15:18 |
| TheMue | natefinch: yep, and we've been a small team too. porting juju from python to go, later exchanging zookeeper with mongo | 15:24 |
| TheMue | natefinch: and in a pre-api era, only direct access to the database | 15:25 |
| katco | cherylj: ping, have an answer for me yet? :) | 15:59 |
| cherylj | katco: sorry, was on a call. | 16:13 |
| natefinch | ericsnow: ug.. in that check extension patch... you were right to wonder where the definition for formatMediaType was.... it was in files that didn't get added to git... and unfortunately subsequently got deleted as I switched between branches. | 16:13 |
| katco | cherylj: no worries | 16:13 |
| cherylj | sinzui or abentley would know better than I | 16:14 |
| ericsnow | natefinch: :( | 16:14 |
| cherylj | about what the queue looks like | 16:14 |
| katco | natefinch: switching branches shouldn't delete files i don't think? | 16:14 |
| ericsnow | natefinch: you don't need it if you use a query arg <wink> | 16:14 |
| natefinch | katco: no, but when you look and see a resources directory that shouldn't exist and so you delete it.... they do :/ | 16:14 |
| katco | ... | 16:15 |
| * natefinch clutches his foot where he shot it. | 16:15 | |
| natefinch | luckily this was just the code to copy the FormatMediaType code from 1.6, so it's pretty trivial to replace. | 16:15 |
| natefinch | ericsnow: IETF says it should be in the filename param of the content-disposition. | 16:16 |
| ericsnow | natefinch: for server responses (not requests), no? | 16:16 |
| abentley | katco: it appears to be 6th in the order. | 16:17 |
| perrito666 | oh please, dont pass content metadata in query parameters, that is a sin in several major religions | 16:17 |
| katco | abentley: cool, ty! any eta? | 16:17 |
| natefinch | ericsnow: UNder the section called "Form-based File Upload in HTML" : "The original local file name may be supplied as well, either as a 'filename' parameter either of the 'content-disposition: form-data' header or in the case of multiple files in a 'content-disposition: file' header of the subpart." | 16:18 |
| abentley | katco: roughly a day, everything going smoothly. | 16:18 |
| katco | abentley: great, thanks :) | 16:18 |
| natefinch | ericsnow: http://tools.ietf.org/html/rfc1867 | 16:18 |
| natefinch | ericsnow: search for filename | 16:18 |
| abentley | katco: Less if any of the branches ahead of it have failed to update their version number :-) | 16:18 |
| katco | lol | 16:19 |
| ericsnow | natefinch: that's for form-based upload | 16:19 |
| ericsnow | natefinch: I suppose you could interpret this that way | 16:19 |
| natefinch | ericsnow: yes, and the GUI guys will thank me when they want to write a form to let people upload resources :) | 16:19 |
| ericsnow | natefinch: I still think it makes more sense as a query arg | 16:19 |
| ericsnow | natefinch: good point, though they will still have to supply the other query arg | 16:20 |
| katco | abentley: i'm glad you said something... it looks like the version is wrong in the nate-minver branch b/c we were fiddling with that file | 16:20 |
| katco | abentley: master has what it's supposed to be set at? | 16:20 |
| abentley | katco: Right. | 16:21 |
| abentley | katco: We actually tried to test it earlier today: http://reports.vapour.ws/releases/3724 | 16:23 |
| rick_h__ | ericsnow: natefinch +1 to gui wanting to upload resources down the road | 16:24 |
| natefinch | rick_h__: is content-disposition: "formdata; filename=foo.zip" the correct place for a filename for a file we're uploading? I'd like to make sure we're using a standard place | 16:25 |
| katco | abentley: looks like this was the issue? "[description-setter] Could not determine description." | 16:25 |
| abentley | katco: No, the issue was that get_git_version failed to determine the version. Description-setter tries to include the version so that's why *it* failed. | 16:26 |
| katco | abentley: 1-line review? http://reviews.vapour.ws/r/4106/ | 16:27 |
| katco | abentley: gah actually hold on. totally screwed that up | 16:28 |
| katco | abentley: ok, corrected | 16:30 |
| rick_h__ | natefinch: the filename comes up from the browser, I'd defer to hatch on it since it's been a while since I tinkered with it. | 16:31 |
| * hatch pokes head in | 16:31 | |
| natefinch | hatch: file upload via http... we want to include the filename... Content-Disposition: form-data; filename=foo.zip ... or just pass it as a query param? | 16:32 |
| natefinch | hatch: note this is in Go code, so we can make it do wahtever we want... but I want it to stick to standards so no one is surprised down the road | 16:32 |
| hatch | this is for resources I see from the backscroll? | 16:33 |
| natefinch | yeah, uploading resource files to the controller | 16:33 |
| natefinch | from your local machine | 16:34 |
| hatch | do we want to allow people to upload multiple files or are we saying it needs to be in an archive(zip) | 16:34 |
| katco | ericsnow: can you give me a 1-line review? http://reviews.vapour.ws/r/4106/ | 16:34 |
| natefinch | filename was a stand-in. It'll be one at a time | 16:34 |
| ericsnow | katco: sure | 16:35 |
| natefinch | filename=foo.somedata :) | 16:35 |
| ericsnow | katco: LGTM | 16:35 |
| katco | ericsnow: ty | 16:36 |
| hatch | natefinch: ahh ok so one at a time....sounds good to me | 16:37 |
| hatch | natefinch: so sorry I don't understand the question - you want to know what information we will be sending? I suppose that depends on what resources requires, I'm not really familiar with it | 16:37 |
| mup | Bug #1555211 opened: Model name that "destroy-model" accepts doesn't match "list-models" output <juju-core:New> <https://launchpad.net/bugs/1555211> | 16:38 |
| natefinch | hatch: sorry, no... I'm wondering what the standard way is to include the filename for an HTTP upload of a file | 16:38 |
| natefinch | hatch: my googling suggests a header with Content-Disposition: form-data; filename=foo.something ... but just wanted to make sure that was correct | 16:39 |
| hatch | ohh NOW i understand what you're asking | 16:39 |
| hatch | ;D | 16:39 |
| hatch | sorry | 16:39 |
| hatch | yes that is good | 16:39 |
| hatch | :) | 16:39 |
| natefinch | no, my fault for not describing it more clearly | 16:39 |
| natefinch | coo | 16:39 |
| natefinch | cool | 16:39 |
| natefinch | ericsnow: FWIW, that's what chrome produces when you do a file upload, too (granted, that's explicitly from a webpage not a raw API call... but it seems like a good idea to mimic a browser when doing http calls, to make our lives easier later) | 16:40 |
| ericsnow | natefinch: okeedokee :) | 16:41 |
| perrito666 | natefinch: http cares little about if you are using a web form or just making the request by hand | 16:52 |
| cory_fu | Anyone have any idea what "agent-status: failed" means? http://pastebin.ubuntu.com/15335596/ | 17:00 |
| perrito666 | cory_fu: that juju failed (workload being the charm) | 17:05 |
| perrito666 | I would guess juju failed to run the relation-changed hook? | 17:05 |
| cory_fu | perrito666: The workload status doesn't show any error | 17:06 |
| perrito666 | cory_fu: unless its a bug, agent status shows errors from juju itself and workload errors in the charm, (agent is being renamed to juju-status in 2.0 to make this more clear) | 17:07 |
| perrito666 | cory_fu: so this might mean that the workload itself is ok but juju could not run the hook | 17:08 |
| perrito666 | cory_fu: I am not sure I am explaining this clearly :( | 17:08 |
| cory_fu | No, I understand. This seems to be the error that caused it: http://pastebin.ubuntu.com/15335783/ | 17:09 |
| cory_fu | After that, the log is just filled with "failed to start "uniter" manifold worker: dependency not available" messages | 17:09 |
| perrito666 | cory_fu: using master? | 17:10 |
| cory_fu | 1.25 | 17:10 |
| perrito666 | cory_fu: could you submit a dmesg on that machine? | 17:11 |
| perrito666 | that should be trying to write in /var/lib/juju/.../agent.conf | 17:12 |
| perrito666 | I am a bit worried that you get an io timeout | 17:12 |
| cory_fu | perrito666: Where should I submit that? | 17:13 |
| ericsnow | uiteam: the resources endpoints shouldn't be in the v4 API, right? | 17:40 |
| ericsnow | rogpeppe, rick_h__: ^^^ | 17:44 |
| rogpeppe | ericsnow: that's right | 17:44 |
| ericsnow | rogpeppe: the v4 ReqHandler embeds the v5 one, so the endpoints get pulled along for the ride :( | 17:45 |
| rogpeppe | ericsnow: delete 'em from the map | 17:45 |
| ericsnow | rogpeppe: k | 17:45 |
| mup | Bug #1555248 opened: help text for juju destroy-controller needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1555248> | 17:53 |
| mup | Bug #1555260 opened: (1.25.3) agent-status: failed (could not write settings ... timeout) <juju-core:New> <https://launchpad.net/bugs/1555260> | 17:53 |
| bogdanteleaga | any reason wily isn't here? https://github.com/juju/utils/blob/master/series/supportedseries.go#L92 | 18:11 |
| rogpeppe | uiteam: migration tests (still not for the new channels model though): https://github.com/juju/charmstore/pull/567/files | 18:11 |
| natefinch | ericsnow: what do you think for the "filename" constant name? FilenameParam? pretty much every combination of words I can think of is confusing in some way | 18:56 |
| ericsnow | natefinch: if possible, I'd not use a constant (or declare the constant right next to where you use it); I'd expect it to be used in 1 place inside a helper | 18:57 |
| natefinch | ericsnow: well, 2 places, one for setting and one for getting | 18:58 |
| natefinch | ericsnow: which is why I made it a constant.... 2 places in the same file, I could almost just swing making it a raw string... it just makes me twitch | 18:59 |
| ericsnow | natefinch: really the string should be hidden away in some library helper; beyond that I'd say just use some ridiculous (non-exported) name that explicitly declares it | 18:59 |
| natefinch | ericsnow: filenameParamForContentDispositionHeader... got it | 19:00 |
| ericsnow | natefinch: the tricky thing is that the value is dependent part of a "standard" and should be hidden away in something that couples it to handling that RFC | 19:01 |
| ericsnow | natefinch: fine with me :) | 19:01 |
| natefinch | ericsnow: I agree, believe me. I hate implementing standards ad-hoc in the middle of the rest of my code. | 19:02 |
| ericsnow | natefinch: yeah, no joke :( | 19:02 |
| mup | Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291> | 19:05 |
| natefinch | ericsnow: the build tag means only build if go 1.6 is not defined.... I was calling this _go15 to indicate it's go 1.5 (and below)... I just didn't know how to indicate "and below". open to suggestions. | 19:09 |
| ericsnow | natefinch: just drop _go15 bit; given the existence of a _go16.go file, that implies the alternative covers everything else | 19:10 |
| natefinch | ericsnow: good point. I was using them as placemarkers, too, hoping to delete all of those files once we move to 1.6 for everything.. but I think the TODOs are ok | 19:12 |
| ericsnow | natefinch: it may also make sense to reverse that, using XXX.go for the 1.6+ code and XXX_pre-go16.go for the rest | 19:13 |
| natefinch | ericsnow: I think I like that better, since in theory we should be able to just delete all the go15 files at some point | 19:14 |
| ericsnow | natefinch: exactly | 19:14 |
| mup | Bug #1555291 changed: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291> | 19:14 |
| ericsnow | natefinch: make the exceptional case stand out | 19:14 |
| natefinch | ericsnow: nice, thanks | 19:14 |
| ericsnow | natefinch: np | 19:15 |
| ericsnow | natefinch: also, I left a few more comments on that review request | 19:15 |
| ericsnow | natefinch: but that should be about it for me :) | 19:15 |
| natefinch | ericsnow: at least filenames are trivial to change | 19:18 |
| thumper | o/ | 19:26 |
| mup | Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291> | 19:29 |
| katco | ericsnow: natefinch: new version of the architectural doc up. relevant section on the charm command pasted into https://docs.google.com/document/d/1T_7XQ-pmE4gFiD2SSaZnQUqlcLkA7dk0c0PB_ebEkrI/edit# for discussion | 19:41 |
| ericsnow | katco: thanks | 19:41 |
| katco | ericsnow: natefinch: and now i'm free for reviews! what can i do? | 19:42 |
| natefinch | katco: https://github.com/juju/charmrepo/pull/65 http://reviews.vapour.ws/r/4047/ http://reviews.vapour.ws/r/4006/ https://github.com/CanonicalLtd/charmstore-client/pull/181 | 19:43 |
| katco | natefinch: ty | 19:43 |
| ericsnow | natefinch: I have http://reviews.vapour.ws/r/4090/ and http://reviews.vapour.ws/r/4099/, but natefinch's 4006 should take priority | 19:44 |
| natefinch | ericsnow: ship it on the file extension stuff? | 20:03 |
| ericsnow | natefinch: I'd still like to see that copied code in a separate package (like we've done in the past for code copied from the stdlib, etc.) | 20:04 |
| natefinch | ericsnow: bah, ok... yes, that's probably for the best | 20:04 |
| deanman | I'm interested on writing a new provider for a cloud infra not currently supported. Do i have to write it in Go or can i use other programming lanugages? | 20:05 |
| ericsnow | natefinch: I explained a little more in a comment on my review | 20:06 |
| katco | deanman: at the moment, you'll have to write it in go | 20:06 |
| katco | deanman: all providers live in the main repo here: https://github.com/juju/juju/tree/master/provider | 20:06 |
| katco | deanman: we've tried to push for a plug-in model in the past so that you can write providers in any language, but that has been met with resistance. if that's something you'd like to see, please do reach out on the mailing list | 20:07 |
| deanman | Can i wrap an already provided CLI tool in a Go provider or do i have to implement REST calls in Go from scratch? | 20:07 |
| katco | deanman: i think the implementation doesn't matter so much. juju just needs to know how to interop with your provider | 20:08 |
| ericsnow | deanman: adding dependencies on some CLI may also be a harder sell (harder than depending on some 3rd party Go library) | 20:09 |
| deanman | katco: Is there any guide on how to start about on such a project? | 20:10 |
| katco | deanman: https://github.com/juju/juju/wiki/Implementing-environment-providers | 20:11 |
| katco | deanman: i also have some diagrams that aren't on the wiki (my fault) if you're interested | 20:11 |
| deanman | I wanted to be able to manage eucalyptus infrastructure and did try to use the AWS one but it seems Euca was returning something extra (although claiming close to 100% AWS compatibility) so i decided whether it is reasonable to implement it from scratch... | 20:12 |
| katco | deanman: we do have some precedent for similar providers | 20:12 |
| katco | deanman: the recommendation is that you find the commonality, split that out into modules of responsibility (e.g. authenticator, instanceCreator, whatever), and then pass those into each provider which would receive interfaces | 20:13 |
| deanman | katco: What do you mean? (yeah i would be interested in any material i can get to start researching and hacking) | 20:13 |
| katco | deanman: architectural diagrams. here's probably the most helpful one: https://www.dropbox.com/s/kxlg150cjm3sggl/drivers-class.eps?dl=0 | 20:21 |
| katco | deanman: it may be a bit out of date, but combined with the wiki that should get you going | 20:22 |
| deanman | katco: thank you for your help... | 20:25 |
| natefinch | deanman: hopefully it would be a matter of tweaking the AWS provider so it can work with Eucalyptus as-is (without harming AWS compatibility)... if that's not feasible, refactor it so you can swap out the parts that need to be different between the two | 20:25 |
| katco | deanman: hth, and welcome to the juju community ^.^ | 20:25 |
| katco | natefinch: that would add cyclomatic complexity... best not to have several if statements in the body of the provider | 20:26 |
| deanman | natefinch: Yeah, i believe so, some first tests showed that euca was returning a "timestamp" field which aws provider didn't expect or something like that.. | 20:26 |
| natefinch | katco: hopefully it wouldn't just be if statements... I was thinking more like being slightly more flexible about the expected responses etc | 20:27 |
| katco | natefinch: and how would you implement that flexibility? ... :) | 20:27 |
| natefinch | katco: depends on how you need to be flexible... ignoring fields you don't understand, rather than erroring out, for example. | 20:28 |
| katco | natefinch: and how would you make that decision to ignore the field? | 20:29 |
| katco | natefinch: tldr; at some point you're talking about a branching conditional, i.e. cyclomatic complexity | 20:29 |
| ericsnow | natefinch: thanks for addressing all my concerns! :) | 20:35 |
| ericsnow | natefinch: LGTM | 20:35 |
| natefinch | ericsnow: thanks for helping making the code better :) | 20:38 |
| ericsnow | natefinch: teamwork! :) | 20:39 |
| * natefinch sings kumbaya | 20:39 | |
| mup | Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325> | 20:41 |
| mup | Bug #1555325 changed: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325> | 20:47 |
| mup | Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325> | 21:02 |
| natefinch | dammit godeps | 21:09 |
| katco | ericsnow: natefinch: standup time | 21:16 |
| === urulama is now known as urulama__ | ||
| thumper | :-( | 21:58 |
| thumper | just found that doing /o\ on my rigged standing desk is double fail | 21:59 |
| thumper | all tilts | 21:59 |
| menn0 | thumper: http://reviews.vapour.ws/r/4107/ please (boring one) | 22:00 |
| * thumper looks | 22:01 | |
| thumper | shipit | 22:02 |
| * thumper is poking around with service leadership... | 22:02 | |
| thumper | oh FFS | 22:05 |
| * thumper headdesks | 22:05 | |
| thumper | sometimes I think we do things hard just for the hell of it | 22:05 |
| mup | Bug #1555355 opened: MachineSerializationSuite.TestAnnotations unit test failure (Go 1.6) <ci> <go1.6> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1555355> | 22:06 |
| natefinch | thumper: lol yep | 22:07 |
| alexisb | thumper, you sound like you are having a fun morning | 22:09 |
| thumper | yeah... *fun* | 22:09 |
| thumper | today is a crazy day just with home stuff | 22:10 |
| thumper | don't need crazy work stuff too | 22:10 |
| alexisb | is there work that exists without crazy? | 22:10 |
| thumper | heh, yeah | 22:12 |
| * thumper goes and pokes code with a stick while thinking about making a coffee | 22:15 | |
| menn0 | thumper: easy one: http://reviews.vapour.ws/r/4108/ | 22:38 |
| thumper | shipit | 22:39 |
| menn0 | thumper: cheers | 22:40 |
| thumper | I still struggle with simple go integer for loops | 22:45 |
| thumper | I always want to write: | 22:45 |
| thumper | for i := 0; i < n; ++i { | 22:45 |
| alexisb | thumper, those of us on the release call will be late to the leads call | 23:01 |
| thumper | alexisb: ok | 23:01 |
| mup | Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368> | 23:06 |
| mup | Bug #1555368 changed: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368> | 23:12 |
| thumper | alexisb: ETA? | 23:14 |
| perrito666 | wallyworld: standup not happening? | 23:14 |
| wallyworld | perrito666: not on thursdays, stuck in meetings :-( | 23:15 |
| perrito666 | wallyworld: I know, but since sometimes it happens I ask | 23:15 |
| wallyworld | perrito666: we can catch up a bit later maybe | 23:15 |
| perrito666 | better safe | 23:15 |
| wallyworld | ty | 23:15 |
| perrito666 | I ve been wanting to write a blog post for days, this is my chance | 23:16 |
| mup | Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368> | 23:18 |
| katco | ericsnow: can you move the resources tech debt cards to the tech debt board? | 23:32 |
| ericsnow | katco: sure | 23:33 |
| katco | ericsnow: also, we have past 3/22 to fix bugs. ~4/12. so we should figure out what's most important to work on next | 23:34 |
| ericsnow | katco: k | 23:34 |
| katco | ericsnow: imo, it's definitely supporting revisions of resources in the resource flag. wallyworld ? | 23:35 |
| ericsnow | katco: fine with me | 23:35 |
| wallyworld | ericsnow: katco: yeah, i think we do the resource flag work | 23:35 |
| katco | wallyworld: k | 23:35 |
| katco | ericsnow: we should point this | 23:36 |
| katco | ericsnow: can you create a user story card with tasks defined so we can point first thing tomorrow? | 23:38 |
| katco | ericsnow: sorry otp | 23:38 |
| ericsnow | katco: sure | 23:38 |
| katco | ericsnow: ta | 23:38 |
| wallyworld | perrito666: wanna do standup now? too late? | 23:41 |
| === thumper is now known as thumper-dogwalk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!