| perrito666 | katco: how optional am I on the second standup? | 00:01 |
|---|---|---|
| anastasiamac | perrito666: it's almost philosophical - what variations of optional there are? hard optional? soft optional? :D | 00:03 |
| anastasiamac | perrito666: disclaimer: this question ^^ does not imply ur optionality | 00:03 |
| perrito666 | anastasiamac: there is a whole range between "we cant live if living is without you" and "I dont ever want so see you again" | 00:05 |
| perrito666 | (I had to google for the second song, there aren't as many hate you songs as one would expect) | 00:05 |
| anastasiamac | perrito666: really, i was told swift covers a lot of hate ranges | 00:06 |
| perrito666 | anastasiamac: the thing is, that is very close to my bike time and I might not make it everyday | 00:07 |
| anastasiamac | perrito666: ack. i have school drop-off at that time too, so cannot do either :/ | 00:08 |
| wallyworld | menn0: thanks for review, i've updated pr | 00:11 |
| menn0 | wallyworld: for some reason RB isn't showing any changes between diffs 1 and 2 | 00:11 |
| menn0 | wallyworld: but I trust you, so ship it | 00:11 |
| wallyworld | hmm, ok, ty, i double check | 00:11 |
| menn0 | wallyworld: it says there's files changed but when I what to see the diffs there's nothing | 00:12 |
| menn0 | looks like a RB problem | 00:12 |
| * perrito666 sends the kind of mail that makes someone hate you | 00:13 | |
| wallyworld | menn0: i just checked github and the commit it there | 00:13 |
| wallyworld | so wtf rb | 00:13 |
| * menn0 looks quickly at the changes on GH | 00:13 | |
| * wallyworld waits in anticipation | 00:14 | |
| menn0 | wallyworld: looks good! my ship it stands :) | 00:14 |
| wallyworld | yay, tyvm | 00:14 |
| wallyworld | anastasiamac: hey, i commented on the pr, sorry it needs rework | 00:23 |
| anastasiamac | wallyworld: i disagree with ur stmt | 00:23 |
| anastasiamac | wallyworld: quick hangout? | 00:24 |
| wallyworld | sure | 00:24 |
| anastasiamac | 1:1 | 00:24 |
| mup | Bug #1546348 opened: cannot use or destroy controller after bootstrap <azure-provider> <bootstrap> <ci> <ec2-provider> <gce-provider> <joyent-provider> <kill-controller> | 00:25 |
| mup | <openstack-provider> <regression> <status> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546348> | 00:25 |
| mup | Bug #1546350 opened: All juju models tagged with "local" <azure-provider> <ec2-provider> <gce-provider> <joyent-provider> <openstack-provider> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546350> | 00:25 |
| perrito666 | state tests take a bit too long | 00:36 |
| perrito666 | someone thought this was a useful test failure error: | 00:40 |
| perrito666 | Error: entity contents mismatch; same length 1 | 00:40 |
| anastasiamac | perrito666: juju deals with paradoxes :D | 00:41 |
| axw | wallyworld: I think the CI issue is due to the change from <controller> -> local.<controller> | 00:44 |
| wallyworld | ah | 00:44 |
| wallyworld | axw: that sounds like it's Ci scripts not juju | 00:45 |
| axw | wallyworld: model "aws-deploy-trusty-amd64" not found <-- that'd be because it's called local.aws-deploy-trusty-amd64 | 00:45 |
| wallyworld | axw: that's the model though not the controller | 00:45 |
| axw | wallyworld: yeah, the admin model is currently called the same as the controller | 00:46 |
| wallyworld | axw: ah, ok, so when we create the admin model, we need to strip local. | 00:46 |
| axw | wallyworld: that's going to cause problems, due to code expecting controller==model | 00:46 |
| axw | wallyworld: (without the branch I'm working on) | 00:46 |
| wallyworld | fark | 00:46 |
| wallyworld | axw: so we need to get your current branch landed i guess | 00:47 |
| axw | wallyworld: yeah, I think so. | 00:47 |
| axw | wallyworld: in the mean time, CI could prefix with local. | 00:47 |
| axw | not sure how much effort that'd take | 00:47 |
| wallyworld | ok, i'll let the qa folks know. i don't think they'd be up for changing scripts now | 00:47 |
| axw | wallyworld: they'll need to change them to expect the model name to be "admin" anywya, in case that's not obvious | 00:56 |
| axw | unless we change it to be the non-prefixed controller name as an intermediate step | 00:56 |
| wallyworld | axw: i'm discussing with sinzui in #juju now | 00:57 |
| === ses is now known as Guest63483 | ||
| blahdeblah | Anyone able to explain to me why juju does what it does to /root/.ssh/authorized_keys, and what I can do to fit in with what it does whilst still enabling what I want, which is that a charm needs to be able to write working entries in there. | 04:00 |
| blahdeblah | There should have been a ? somewhere in that line. | 04:00 |
| wallyworld | np | 04:04 |
| natefinch | does anyone know how to debug the uniter tests? The failures basically read like "Here's a big struct vaguely describing what the test is... oh something failed somewhere" | 04:18 |
| natefinch | brb | 04:19 |
| bradm | anyone here know about the multi user stuff? say we were to run it on top of an openstack cloud, we would only need the top env to be deployed with juju 2.0, right? the underlying cloud could be a stable juju, say 1.25.3? | 04:20 |
| natefinch | back | 04:36 |
| natefinch | bradm: yeah, the juju that deploys openstack wouldn't need to be multi-user unless you cared about having multiuser for controlling openstack itself | 04:37 |
| natefinch | bradm: you could definitely have whatever juju deploys on top of openstack be 2.0+ to get multi-user for those services | 04:37 |
| natefinch | bradm: the layers don't talk to each other at all. As far as the top level juju is concerned, it doesn't know or care how openstack is deployed. | 04:38 |
| bradm | natefinch: excellent, I thought that was the case but wanted to confirm before deploying with 1.25.3 for the underlying stack | 04:39 |
| axw | wallyworld: RB bot seems to be asleep, here's the first fix: https://github.com/juju/juju/pull/4442 | 05:08 |
| wallyworld | ta, will look soon | 05:09 |
| wallyworld | axw: damn, you and i are going to conflict :-) | 05:20 |
| axw | wallyworld: where? register? | 05:20 |
| wallyworld | SetBootstrapEndpointAddress | 05:21 |
| wallyworld | maybe elsewhere | 05:21 |
| axw | wallyworld: ah. my changes there are pretty trivial | 05:21 |
| wallyworld | yeah, i have 2 tests to fix before proposing, we can land yours first | 05:21 |
| wallyworld | axw: so just to confirm, "-m model" works, and tags are without local- | 05:28 |
| axw | wallyworld: I'll bootstrap aws now to verify, but tested with lxd and -m model works | 05:28 |
| wallyworld | great | 05:28 |
| anastasiamac | axw: wallyworld: when/if u get a chance, PTAL "simple"streams PR - surface difference increased somewot :P | 05:36 |
| axw | wallyworld: confirmed that tags don't have local in them, and I can do "juju status -m <controller-name-without-local-prefix>" | 05:42 |
| wallyworld | awesome | 05:43 |
| axw | anastasiamac: if you must have them at all: please move all of the bug references out of the production code, and into the tests that verify they're fixed | 05:44 |
| axw | if we break the code, the tests will fail and the broken tests will point at the bugs | 05:45 |
| axw | then we don't have bug references littered all over the code | 05:45 |
| anastasiamac | axw: sure | 05:48 |
| axw | wallyworld: based on your comment "we don't want one or the other", should we be changing the data sources to take a set of public keys? | 05:58 |
| wallyworld | axw: we could do that, or create separate datasources. it's really a corner case for this image-metadata-url datasource. in practice, we don't have the private key used on cloud-images.u.c so maybe we just use the custom key if defined | 05:59 |
| wallyworld | and leave off the key if not defined | 06:00 |
| axw | wallyworld: so custom ones just use the "user signing key"? sounds sane | 06:01 |
| wallyworld | axw: except that we also control the official key for tools | 06:01 |
| wallyworld | and so the qa guys may want to test that with a custom source | 06:01 |
| axw | simple :) | 06:01 |
| wallyworld | streams :-) | 06:02 |
| wallyworld | but we do know what's an image vs tools data source so we can make a call there | 06:02 |
| axw | yup | 06:02 |
| wallyworld | except for the common data source at bootstrap | 06:02 |
| wallyworld | which points to a top level dir containing tools and images from memory | 06:03 |
| wallyworld | maybe we construct a couple of data sources as needed and allow a signing verification error to be non fatal | 06:03 |
| wallyworld | i think that's what we do now | 06:03 |
| axw | wallyworld: different topic: would you be ok with temporarily reverting adding the "local." prefix altogether? then when we're through CI we can add it back, and change the initial mode to admin at the same time | 06:04 |
| axw | mode=model | 06:05 |
| wallyworld | axw: sure, the thought had crossed my mind, but the pr landing now makes things good right? | 06:05 |
| axw | wallyworld: still can't destroy-controller with the controller name minus prefix | 06:06 |
| axw | wallyworld: dropping the prefix would fix that | 06:06 |
| wallyworld | we were going to match local if there were no non-local? | 06:06 |
| wallyworld | that might be a smaller change | 06:06 |
| axw | wallyworld: so I'm a bit reluctant to add that logic into jujuclient, which currently is agnostic of the names. but adding it in anywhere else would be error prone, given the number of places we're going to write them. and the spec doesn't call for it... | 06:08 |
| wallyworld | it is agnotic, it was to be a short term fix. the issue is that if we ship with the UX deviating from the spec in such a visible way, there may be issues | 06:09 |
| wallyworld | ie fix for beta1, remove as soon as beta1 ships and Ci gets updated | 06:09 |
| axw | wallyworld: it's definitely not not going to be a smaller fix, btw. we'd need to canonicalise the controller names, which we currently expect are canonical | 06:11 |
| wallyworld | ok, i guess we can release note it loudly | 06:11 |
| axw | wallyworld: and also already deviating from spec, since model is not admin | 06:11 |
| wallyworld | yes, but that's not as in your face :-) | 06:12 |
| axw | it should be trivial to fix both at the same time | 06:12 |
| wallyworld | ok | 06:12 |
| wallyworld | let's revert for beta1 | 06:12 |
| wallyworld | and we'll ensure Ci drops the -m etc at the same time | 06:12 |
| axw | wallyworld: another question I have is whether it should be local. or local: -- we use local: for clouds | 06:14 |
| wallyworld | yeah, and the spec uses local.model | 06:14 |
| wallyworld | we can ask rick | 06:14 |
| axw | wallyworld: hrm actually it can't be local:, because then there'd be ambiguity with "local" as a controller name | 06:15 |
| wallyworld | ah yes | 06:15 |
| wallyworld | axw: right, time to see how bad the conflicts are | 06:17 |
| * wallyworld takes a deep breath | 06:17 | |
| axw | wallyworld: sorry :) | 06:17 |
| axw | shouldn't be too bad | 06:17 |
| wallyworld | tis all good | 06:17 |
| wallyworld | 4 files | 06:19 |
| axw | anastasiamac: the answer to your last question on the PR is ^^^^ | 06:24 |
| axw | wallyworld: (above "different topic") | 06:24 |
| axw | erer | 06:24 |
| axw | anastasiamac: | 06:24 |
| anastasiamac | axw: wallyworld: plz clarify in PR for posterity (and my sanity) | 06:29 |
| anastasiamac | axw: m not seeing a definite answer above, just tossing ideas :D | 06:30 |
| axw | wallyworld: trivial one: http://reviews.vapour.ws/r/3881/ | 06:49 |
| wallyworld | looking | 06:49 |
| dimitern | axw, hey, could this https://github.com/juju/juju/pull/4444 also fix bug 1546043? | 07:25 |
| mup | Bug #1546043: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043> | 07:25 |
| axw | dimitern: that's the one | 07:25 |
| dimitern | axw, awesome! it was bugging me for a while now :) | 07:25 |
| axw | wallyworld: I'm going to rename the "create admin model..." card and create another one, since bulk of the work is done. just need to flip a switch to set it to admin | 07:29 |
| wallyworld | +1 | 07:29 |
| axw | actually I'll just create a new card and transfer points | 07:29 |
| axw | wallyworld: when you're done, can we have a chat about what's next? | 07:31 |
| dimitern | axw, you've got a review btw, and I hope you don't mind - I assigned yourself to that bug | 07:31 |
| axw | dimitern: thanks, not at all | 07:31 |
| wallyworld | axw: sure, more tests to fix, won't be long | 07:31 |
| axw | dimitern: master's blocked though, I'll land it once the beta's out I guess | 07:33 |
| axw | dimitern: why do we care about sorting the addresses w.r.t. v4/v6 on the client? | 07:36 |
| dimitern | axw, that's ok - btw I've just confirmed your patch prevents apiserver/logsink.log creation | 07:36 |
| axw | dimitern: thanks | 07:36 |
| dimitern | axw, ah, that due to the somewhat well-intended-but-not-well-implemented prefer-ipv6 setting | 07:37 |
| axw | dimitern: where does that preference actually matter though? | 07:38 |
| axw | dimitern: I'm wondering if we should care on the client | 07:38 |
| dimitern | axw, it will change soon (first for maas, later for all providers gradually), as we're making controller endpoint selection based on spaces | 07:38 |
| axw | because we try all addresses | 07:38 |
| dimitern | axw, we do try all of them, but we still put the last we successfully connected to on top | 07:39 |
| dimitern | axw, and yeah, it shouldn't matter at the client side | 07:39 |
| axw | dimitern: ok, thanks | 07:40 |
| axw | wallyworld: ^^ maybe we don't need to worry about it anymore | 07:41 |
| wallyworld | that would be good | 07:41 |
| wallyworld | axw: quick chat now in standup channel? | 07:42 |
| axw | wallyworld: be there in a sec | 07:42 |
| frobware | dooferlad_: running 15 mins late for our sync. sorry! | 08:20 |
| wallyworld | axw: st.ModelUUID is different to st.Model().ComtrollerUUID() since the latter returns model.serverUUID | 08:23 |
| axw | wallyworld: the UUID of the admin model is the same as the controller UUID | 08:23 |
| wallyworld | axw: i guess that's true but it seems then we're making an assumption that may change and the code as it is is immune to that | 08:24 |
| axw | wallyworld: there's also a controllerTag field on state, we could just expose that | 08:24 |
| wallyworld | ok, maybe the latter is better | 08:24 |
| axw | wallyworld: avoids a db read | 08:25 |
| wallyworld | indeed, but mongo is web scale | 08:25 |
| === ashipika is now known as ashipika__ | ||
| axw | wallyworld: finished reviewing | 08:35 |
| === urulama__ is now known as urulama | ||
| axw | anastasiamac: I suggest, for now, you change the image datasources just to use the user-supplied public key | 09:10 |
| axw | anastasiamac: nobody is likely to be using the official one with a custom location | 09:10 |
| axw | anastasiamac: and that's a separate issue as you noted in the bug | 09:11 |
| axw | anastasiamac: so, drop the ImagePublicKey function you added, and just use simplestreams.UserPublicSigningKey in the *image* data sources only | 09:11 |
| axw | anastasiamac: the tools ones should continue to use SimplestreamsJujuPublicKey | 09:11 |
| frobware | dooferlad_: ping | 09:14 |
| axw | anastasiamac: you have a shipit once that's addressed | 09:16 |
| frobware | dimitern: ping | 09:17 |
| dimitern | frobware, pong | 09:17 |
| frobware | dimitern: can we talk about L2 in the standup HO? If not convenient just say. | 09:17 |
| dimitern | frobware, sure, sounds good | 09:19 |
| dimitern | frobware, omw | 09:19 |
| === ashipika__ is now known as ashipika | ||
| axw | wallyworld: still buggered: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/canonistack-deploy-trusty-amd64/4041/console | 09:22 |
| wallyworld | oh | 09:23 |
| wallyworld | axw: so it's just the kill. the cli *appears* ok | 09:24 |
| wallyworld | oh, also the connect | 09:25 |
| wallyworld | after bootstrap, damn | 09:25 |
| axw | wallyworld: actually the kill worked, bootstrap returned an error code | 09:25 |
| axw | oh, maybe both failed actually | 09:25 |
| axw | wallyworld: cannot read controller info: model "canonistack-deploy-trusty-amd64:canonistack-deploy-trusty-amd64" not found | 09:26 |
| axw | for bootstrap and kill | 09:26 |
| wallyworld | axw: for legacy, we record foo:foo, in new client store, we want just foo, right | 09:26 |
| wallyworld | so maybe there's a mix up somewhere | 09:26 |
| axw | wallyworld: oh, my bad. bootstrap is failing due to ssh timeout | 09:27 |
| axw | ... probably because canonistack | 09:28 |
| axw | and destroy is failing because it didn't bootstrap | 09:28 |
| * axw checks a different substrate | 09:28 | |
| axw | wallyworld: sorry, canonistack is non-voting. I'll raise the alarm if another voting substrate fails | 09:30 |
| wallyworld | whew | 09:30 |
| axw | so far so good on azure.. | 09:30 |
| axw | wallyworld: it's a little bit unclear, but I think that test you removed is to ensure we can connect with the addresses/creds on disk, without requiring the bootstrap config | 09:33 |
| wallyworld | ok, i'll take a look | 09:34 |
| axw | wallyworld: winner: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/azure-arm-deploy/217/console | 09:46 |
| wallyworld | goo :-) | 09:47 |
| wallyworld | good | 09:47 |
| axw | wallyworld: sorry, I didn't see that you had just changed the existing blank address check... leave it if you think there's potential for errors there | 09:55 |
| wallyworld | axw: a bunch of tests fail which i am fixing. maybe we can hope juju itself is now not broekn anymore | 09:56 |
| axw | wallyworld: I'll have to go soon, but will check back later to see your changes | 09:57 |
| wallyworld | ok, np, have a few to go | 09:57 |
| axw | wallyworld: or I can review tomorrow if you want to finish it tomorrow | 09:57 |
| wallyworld | would be nice to land tonight, take a peek if you want later and hopefully will be +1 | 09:58 |
| axw | sure | 09:58 |
| voidspace | dimitern: frobware: http://reviews.vapour.ws/r/3884/ | 11:16 |
| dimitern | voidspace, looking | 11:17 |
| fwereade | dimitern, am bumping up against cmd/jujud/agent.MachineSuite.testAddresserWorkerNewResult | 11:18 |
| fwereade | dimitern, is it still relevant, or should we actually just never run it? | 11:18 |
| dimitern | fwereade, let me have a look | 11:18 |
| fwereade | dimitern, (or always? which would be bad, because it currently seems like "never" ;p) | 11:18 |
| fwereade | cheers | 11:18 |
| dimitern | fwereade, ah, it's disabled as flaky | 11:19 |
| dimitern | fwereade, but we're dropping the address-allocation feature flag soon | 11:20 |
| fwereade | dimitern, indeed, but I want to know what the status is of the stuff it's dealing with | 11:20 |
| dimitern | fwereade, you mean whether to migrate it to use the dep engine? | 11:21 |
| fwereade | dimitern, I already have, I'm just not 100% sure what the expected behaviour is | 11:22 |
| fwereade | dimitern, and the agent tests are not making it any easier to figure out ;p | 11:22 |
| dimitern | fwereade, as it currently is, it should start and stop immediately when address-allocation feature flag is off (as it calls CanDeallocateAddresses first thing before it starts, which in turn uses the flag) | 11:23 |
| dimitern | fwereade, was that helpful? :) | 11:24 |
| fwereade | dimitern, it confirms that it's currently doing the right thing | 11:24 |
| fwereade | dimitern, and I think that *that* specific behaviour doesn't need testing at agent level | 11:24 |
| fwereade | dimitern, well, ok, it's arguable | 11:25 |
| dimitern | fwereade, agreed - those couple of tests effectively test the finished worker behavior | 11:25 |
| fwereade | dimitern, ehh, it's mainly just a bit annoying that my check-all-workers-are-running thing fails when one of the standard workers is sanely and blamelessly not running | 11:26 |
| dimitern | fwereade, ah :) I see | 11:27 |
| fwereade | dimitern, and while I *could* just ignore that skipped test I would *know* it'd fail against my current changes when reactivated, and that would be evil | 11:27 |
| fwereade | dimitern, so I need to take some action and am rambling at you in the hope that it will become clearer :) | 11:28 |
| dimitern | fwereade, I wouldn't worry too much about that particular test - perhaps an expected failure when not skipped + TODO will make it obvious? | 11:28 |
| fwereade | dimitern, it's still a timebomb for whoever hits it -- do you recall the nature of the flakiness? | 11:29 |
| dimitern | fwereade, yeah, it failed to pass under heavy load IIRC | 11:30 |
| fwereade | dimitern, ok, then I'm entirely unsurprised, bloody singularRunner patch :) | 11:30 |
| * fwereade hopes what he has is a bit less awful | 11:31 | |
| dimitern | fwereade, my point about not worrying too much about is that we'll drop the addresser soon anyway | 11:31 |
| fwereade | dimitern, that's even better then | 11:31 |
| voidspace | frobware: thanks for the review | 11:32 |
| dimitern | voidspace, I have a concern re updated dependencies.tsv btw | 11:33 |
| voidspace | frobware: the uint comes from the gomaasapi Space object - so unrelated | 11:33 |
| frobware | voidspace: np, the only thing that really stuck out was int/uint for ID | 11:33 |
| dimitern | voidspace, changing just the sha hash makes it difficult to compare the dates | 11:33 |
| voidspace | dimitern: how do I get the date? Running the update steps for dependencies.tsv shown in CONTRIBUTING.md omitted the date. | 11:34 |
| voidspace | dimitern: I can just put todays date in | 11:34 |
| dimitern | voidspace, godeps github.com/juju/juju/... | 11:34 |
| dimitern | voidspace, dumps the result at the end | 11:34 |
| voidspace | dimitern: with no dates | 11:35 |
| voidspace | dimitern: on my machine | 11:35 |
| dimitern | voidspace, make sure you have the latest godeps | 11:36 |
| dimitern | voidspace, go get -u -v launchpad.net/godeps/... | 11:37 |
| voidspace | frobware: the "int" is purely to convert from the float that comes out of json | 11:38 |
| voidspace | frobware: I can use uint I suppose | 11:38 |
| dimitern | voidspace, that's what I got on my in-progress branch when running godeps github.com/juju/juju/...: http://paste.ubuntu.com/15099666/ | 11:38 |
| voidspace | dimitern: are you sure *you* have the latest version? | 11:38 |
| voidspace | heh | 11:39 |
| dimitern | voidspace, yes, I did run go get -u -v launchpad.net/godeps/... before suggesting it :) | 11:39 |
| voidspace | dimitern: I've updated and I get dates | 11:39 |
| voidspace | dimitern: I'll add it | 11:39 |
| voidspace | dimitern: I've updated that | 11:40 |
| mup | Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492> | 11:42 |
| dimitern | voidspace, tyvm | 11:42 |
| dimitern | voidspace, almost done with your review btw | 11:43 |
| mup | Bug #1546492 changed: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492> | 11:45 |
| voidspace | frobware: fmt.Sprintf("%.0f", float) works... | 11:45 |
| voidspace | and is less round the houses | 11:45 |
| dimitern | network.Id(fmt.Sprintf("%v", x)) will also work for v interface{} :) | 11:46 |
| frobware | voidspace: yep | 11:46 |
| voidspace | dimitern: but if x is a float %v will do the wrong thing | 11:46 |
| voidspace | dimitern: i.e. 2.0 will become network.Id("2.0") and we need network.Id("2") | 11:47 |
| voidspace | dimitern: and what comes out of json is a float even if the source is an int | 11:47 |
| voidspace | because json | 11:47 |
| voidspace | because javascript | 11:47 |
| wallyworld | axw: if you're around, pr updated | 11:48 |
| === jamespag` is now known as jamespage | ||
| mup | Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492> | 11:48 |
| dimitern | voidspace, uint(2.0) then? | 11:48 |
| voidspace | or fmt.Sprintf("%.0f", v) | 11:50 |
| voidspace | rather than strconv.Itoa(uint(...)) | 11:50 |
| voidspace | dimitern: frobware: did you get disconnected too or was it just me? | 11:53 |
| voidspace | dimitern: I don't think newAddressOnSpaceWithId should move to network | 11:57 |
| voidspace | dimitern: in future we'll be setting provider id *or* name | 11:57 |
| voidspace | dimitern: at which point we'll probably need a "NewAddressOnSpaceId | 11:57 |
| voidspace | dimitern: this PR is a little bit of an intermediate one where we're setting both, but it won't stay like this | 11:57 |
| voidspace | dimitern: probably next PR... | 11:57 |
| frobware | voidspace:just you | 11:58 |
| voidspace | frobware: weird | 11:58 |
| dimitern | voidspace, I think freenode is experiencing DDoS attacks today (yet again) | 11:58 |
| voidspace | dimitern: ah | 12:00 |
| dimitern | voidspace, I'm not sure about "or" | 12:00 |
| frobware | voidspace: I take it back. | 12:00 |
| voidspace | frobware: hehe | 12:00 |
| voidspace | dimitern: that's the current plan | 12:00 |
| voidspace | dimitern: we shouldn't use space names directly from the provider | 12:00 |
| voidspace | dimitern: so if the space comes from the provider we should set the id not the name | 12:00 |
| voidspace | dimitern: so if we have a name set we *know* it's a juju name | 12:01 |
| dimitern | voidspace, what's wrong with having either name and no ID or both? | 12:01 |
| voidspace | dimitern: rather than having a mix of juju names and provider names floating through our code | 12:01 |
| frobware | dimitern, voidspace: why can't we indirect through the ID for the name? | 12:01 |
| voidspace | dimitern: because if you see a name on an address you need to know if it's a juju name or provider name | 12:01 |
| voidspace | frobware: we should do, that's what I'm saying | 12:02 |
| dimitern | voidspace, frobware, I think a space name should always be a valid juju name | 12:02 |
| voidspace | frobware: we won't have an id for ec2 addresses of course because there's no provider id | 12:02 |
| voidspace | dimitern: but that isn't currently the case with maas | 12:02 |
| voidspace | dimitern: and our current definition of "valid juju name" | 12:02 |
| voidspace | dimitern: if they change to be in sync that's a different matter | 12:02 |
| voidspace | but even then there's no *problem* with being strict on using id *or* name - there's just less need | 12:03 |
| voidspace | but at the moment there's a need | 12:03 |
| dimitern | voidspace, yeah - they should change in names so that [A-Za-z0-9-_]+ is a valid juju space name | 12:04 |
| dimitern | voidspace, but as it will be the case in maas | 12:04 |
| dimitern | voidspace, s/but// | 12:05 |
| voidspace | dimitern: yep | 12:05 |
| dimitern | voidspace, that's why I suggested to keep the name even if we have an ID | 12:05 |
| voidspace | dimitern: my next PR will address this anyway, so I'm going to drop that issue from this PR | 12:05 |
| voidspace | dimitern: the trouble is that until they do it (which they say they will but may never do) it's dangerous to mix up juju names and maas names | 12:06 |
| dimitern | voidspace, I'm ok with that | 12:06 |
| voidspace | dimitern: cool | 12:06 |
| frobware | voidspace, dimitern: totally agree with "it's dangerous to mix up juju names and maas names" +1 | 12:08 |
| dimitern | frobware, voidspace, the only danger I can see is due to bugs in maas atm | 12:11 |
| frobware | dimitern: we should stop working around bugs, IMO. fix the root cause. | 12:12 |
| axw | wallyworld: are you still working on changing UpdateControllerAddresses to not take UUID? | 12:13 |
| dimitern | frobware, I'm not saying we should work around the bugs in maas that prevent us in some cases to use a valid maas space name as a juju space name | 12:14 |
| voidspace | dimitern: well, that maas space name definition is broader than juju is not a "bug", it's due to a lack of communication between us | 12:14 |
| voidspace | dimitern: it sounds like they will fix it though | 12:14 |
| voidspace | dimitern: duplicate names are a bug :-) | 12:14 |
| wallyworld | axw: it takes a controllerUUID in one case - after api login when controller name is not known, only uuid. i guess i could look up controller name at that point | 12:15 |
| dimitern | voidspace, yeah - spaces allowed in names and duplicate names are 2 bugs they need to fix | 12:15 |
| axw | wallyworld: when would we ever not know the controller name? | 12:15 |
| dimitern | voidspace, they said they'll fix those two and we should consider them "fixed" - i.e. build our code onto that assumption | 12:16 |
| wallyworld | damn, in that one place, i didn't see we had controlle rname | 12:16 |
| wallyworld | i'll rework a bit | 12:16 |
| dimitern | voidspace, which means if it's not so - i.e. CI maas setups or other (older) 1.9 maas deployments won't work | 12:17 |
| dimitern | until those bugs are fixed | 12:17 |
| blahdeblah | Repeating earlier question: Why does juju mangle /root/.ssh/authorized_keys, and what I can do to fit in with that, whilst still enabling my charm to write a working entry in there? | 12:21 |
| wallyworld | axw: updated, feature test for register runs ok | 12:26 |
| axw | wallyworld: ok, looking in a sec. I noticed in CI that manual bootstrap fails because we're now expecting "juju bootstrap manual/<host>", and CI is passing bootstrap-config in config.ayml | 12:26 |
| axw | wallyworld: should I try and fix it, or just ask CI to retest with that small change? | 12:27 |
| wallyworld | axw: yeah, saw that too, i beliebe aaron knows about that | 12:27 |
| axw | wallyworld: we could allow bootstrap-host in config as well, would be better not to deviate from other providers tho | 12:27 |
| wallyworld | i will ask them to re-test tomorrow, i prefer consistency | 12:28 |
| axw | wallyworld: LGTM, thanks for changes | 12:29 |
| wallyworld | axw: np, thanks for review, Ci looking good too | 12:30 |
| wallyworld | except for manual of course | 12:30 |
| axw | wallyworld: and a few things say they're still pending, but yeah, lots of green :) | 12:31 |
| wallyworld | release notes tomorrow, will be quite an essay | 12:32 |
| === perrito667 is now known as perrito666 | ||
| voidspace | dimitern: frobware: my branch has an unrelated failure in featuretests | 13:15 |
| voidspace | dimitern: frobware: it's actually a space discovery related failure (can't login) | 13:15 |
| voidspace | dimitern: frobware: I'll land my branch on maas-spaces2 and fix this failure with a follow-up on master | 13:15 |
| dimitern | voidspace, sounds good +1 | 13:18 |
| jcastro | is there a quick getting started guide on building juju from source? | 13:40 |
| jcastro | I think I found a bug in the alpha but I wanted to confirm with trunk | 13:40 |
| Ursinha | jcastro, maybe there's a ppa with daily builds from trunk? | 13:44 |
| Ursinha | that would be a good idea regardless :) | 13:44 |
| Ursinha | (I realize this is not what you're asking for but figuring out such ppa would make me happy as well solve your problem to test trunk :)) | 13:46 |
| jcastro | yeah I am wondering why there's not just a daily PPA | 13:50 |
| rick_h_ | natefinch: wasn't there a thread recently that talked about a doc on building juju core? I can't seem to find it and thought you replied in it. | 13:59 |
| rick_h_ | Ursinha: jcastro we're looking at ways to get builds out faster. Because of the use of streams and such, we don't do daily builds. We need a less invasive way to get that out. | 14:00 |
| natefinch | rick_h_: it's not really very well written for first timers: https://github.com/juju/juju/blob/master/CONTRIBUTING.md | 14:06 |
| rick_h_ | natefinch: ah ok thanks | 14:06 |
| natefinch | rick_h_: we really should write a step by step "this is how you build juju"... which I think that document wants to be, but tries to do too much, and so obscures the actual steps you need to do to build | 14:07 |
| rick_h_ | natefinch: agreed, good to find this and we'll see what we can do. | 14:07 |
| alexisb | natefinch, I used that doc for my first build, wasn't too bad | 14:10 |
| natefinch | fwereade: | 14:12 |
| natefinch | fwereade: heh, oops. Wanted to ask about uniter tests | 14:12 |
| mup | Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561> | 14:15 |
| mup | Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561> | 14:18 |
| mup | Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561> | 14:24 |
| natefinch | redacting the API params during tests is dumb. | 14:31 |
| === Ursinha_ is now known as Ursinha | ||
| fwereade | natefinch, oops sorry; uniter tests? | 14:34 |
| natefinch | fwereade: there's a bunch of "match hooks" where we expect a specific list of hooks to be fired. I presume that if that list changes, that's a bad thing? I'm still working on this resources code, and what I'm getting is an extra upgrade-charm hook firing | 14:36 |
| perrito666 | uh, that part still exists? | 14:36 |
| natefinch | unless something changed in the last 5 or 6 days? | 14:37 |
| perrito666 | I hoped that to go in the uniter refactor sprint | 14:38 |
| natefinch | also, it seems like there's a bug, or at least an inefficiency in the matchHooks code: https://github.com/juju/juju/blob/master/worker/uniter/util_test.go#L250 | 14:38 |
| natefinch | This match hooks call gets retried until a LongWait expires... but really, after the first time this check fails, we know it'll never ever pass | 14:39 |
| perrito666 | natefinch: it is not a bug, its a feature :p | 14:40 |
| natefinch | we don't ever remove things from the hooksCompleted list, so if one of them doesn't match... that's it, we're done, it'll never match. | 14:40 |
| perrito666 | no, really its a design flaw | 14:41 |
| perrito666 | that whole thing is a big bad idea, it is depending a lot on an implementation accident | 14:42 |
| perrito666 | but fwereade might not agree with me :p | 14:42 |
| natefinch | heh | 14:42 |
| natefinch | yeah, that was my question... I'm changing the implementation slightly... in theory it should fire the exact same events that it did before, but it's possible some niggling bits in watcher/worker code cause a hook to fire more than once... so I can't tell if I've introduced a bug, or if the tests are just too specific about their expectations. | 14:43 |
| perrito666 | ok, fwereade might correct me here, tests rely on a hook order that we dont really guarantee, much of the fact that the expected and obtained hook match depends on delicate time balance | 14:45 |
| natefinch | som, for example, here's what my change does to the "SteadyStateUpgrade" hooks: http://pastebin.ubuntu.com/15100335/ (I changed the line prefixes so they make more sense without looking at the code, and so the lists match up for easier visual comparison) | 14:46 |
| natefinch | (that used to be ctx.hooks vs. ctx.hooksCompleted) | 14:47 |
| perrito666 | natefinch: you are triggering more hook calls, which is not bad per se | 14:50 |
| frobware | fwereade: maybe related to your login issue ^^ "voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)" | 14:57 |
| frobware | dimitern, voidspace: release note sync | 15:03 |
| voidspace | frobware: oops, soory - lost track of time | 15:06 |
| voidspace | frobware: 5 mins, grabbing coffee | 15:06 |
| dimitern | oops sorry, omw | 15:11 |
| katco | natefinch: ericsnow_: just want to o/ since no standup in the morning | 15:19 |
| katco | natefinch: ericsnow_: how's everything going? | 15:20 |
| voidspace | dimitern: frobware: http://reviews.vapour.ws/r/3886/ | 15:20 |
| ericsnow_ | katco: good | 15:21 |
| ericsnow_ | katco: talked with Ian about that worker | 15:21 |
| voidspace | frobware: fwereade: what login issue? | 15:21 |
| === ericsnow_ is now known as ericsnow | ||
| katco | ericsnow_: yeah? what's the consensus | 15:21 |
| ericsnow | katco: we don't need a worker for that | 15:22 |
| ericsnow | katco: the precedent (downloading lxc images) indicates that a worker should not be used | 15:22 |
| katco | ericsnow: it occurred to me this morning that maybe i didn't represent it accurately. this will be running 100% of the time polling the charm store for all the services, correct? | 15:23 |
| ericsnow | katco: no | 15:23 |
| ericsnow | katco: that is a different worker | 15:23 |
| katco | ericsnow: oh, i see you picked up a diff. card | 15:23 |
| katco | ericsnow: ok, so the download worker, is not a worker. gotcha. what is it? | 15:23 |
| ericsnow | katco: the one we were discussing related to using a worker to download from the charm store into state in response to resource-get | 15:24 |
| mup | Bug #1546272 changed: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:Invalid> <https://launchpad.net/bugs/1546272> | 15:24 |
| === Ursinha_ is now known as Ursinha | ||
| ericsnow | katco: in the API code we stream directly from the charm store into the blob store | 15:25 |
| ericsnow | katco: (API server side) | 15:25 |
| katco | ericsnow: and if the stream errors out? | 15:25 |
| ericsnow | katco: since resource-get blocks a worker doesn't add anything | 15:25 |
| ericsnow | katco: then we retry (on the server side) | 15:25 |
| katco | ericsnow: what's the mechanism for doing so? | 15:26 |
| ericsnow | katco: the usual suspect: utils.AttemptStrategy | 15:26 |
| * natefinch is here but doesn't want to interrupt. | 15:26 | |
| katco | natefinch: it's irc ;) | 15:26 |
| natefinch | katco: :) | 15:27 |
| katco | ericsnow: ok, well glad you worked it out. thanks for bringing it up | 15:27 |
| katco | ericsnow: natefinch: i'm working on release notes for resources; i'll want you to review here in a bit | 15:28 |
| ericsnow | katco: also, per wallyworld regarding workers: "workers are more for reacting to changes in state" | 15:28 |
| ericsnow | katco: no, thanks for the discussion | 15:28 |
| natefinch | katco: the uniter tests are a beast. There are currently about 5 failures that I'm trying to determine if they represent bugs I have introduced, or tests that need to be updated. | 15:28 |
| katco | ericsnow: good to know | 15:28 |
| ericsnow | katco: it helped paint an even clearer picture about workers in general :) | 15:28 |
| katco | natefinch: :( i understand those are difficult to deal with. thanks for reaching out to perrito666. we need that done today, so do whatever is needed to make that happen (e.g. pair if necessary) | 15:29 |
| katco | ericsnow: definitely | 15:29 |
| ericsnow | katco: FYI, wallyworld also pointed me to the "charmrevisionupdater" worker as something similar to the charmstore poller I'm writing for resource info | 15:30 |
| katco | natefinch: ericsnow: btw we have a new card we need to point: validating file extensions | 15:30 |
| katco | ericsnow: oh, awesome! | 15:30 |
| ericsnow | katco: it's not particularly re-usable for this, but does provide an example; and validation that I'm on the right track :) | 15:31 |
| katco | ericsnow: just as useful imo :) | 15:31 |
| ericsnow | katco, natefinch: I'm free to point that whenever y'all are ready | 15:31 |
| natefinch | fwereade: let me know if you come available | 15:32 |
| katco | ericsnow: natefinch: gimme 5 and we'll hop in moonstone? | 15:32 |
| natefinch | ericsnow katco sounds good | 15:32 |
| ericsnow | katco: +1 | 15:33 |
| katco | ericsnow: natefinch: ok i'm in there | 15:38 |
| fwereade | frobware, voidspace: nah, I was being dumb, had changed a client-side code path without full awareness | 15:54 |
| fwereade | natefinch, perrito666: sorry! short version: I am inclined to consider unexpected hook firings to be a problem | 15:55 |
| fwereade | natefinch, I am available, just quite deep into code, sorry | 15:56 |
| natefinch | fwereade: understandable. that was my assumption as well. | 15:56 |
| fwereade | natefinch, cool | 15:56 |
| fwereade | natefinch, it *may* be the case that the layers of indirection around the tests are such that we can't reliably induce specific uniter behaviour, but that's still a problem | 15:58 |
| fwereade | natefinch, by the way, I think I'm misunderstanding something -- did I see a recent mail from jam saying that new resources are only delivered on resource-get? | 15:59 |
| fwereade | natefinch, is it the case that we do an upgrade-charm to inform of new *available* resource versions or something, but nothing has actually changed in the charm at that point? | 16:00 |
| === kwmonroe_ is now known as kwmonroe | ||
| natefinch | fwereade: we fire upgrade-charm when you push up a local resource to the controller. At that point, the unit does not have the bytes from the new resource, and must call resource-get | 16:03 |
| fwereade | natefinch, upgrade-charm seems a bit surprising compared to resources-changed or something? | 16:04 |
| fwereade | natefinch, the only connection I can see is that they're both sort of to do with the charm, and you can say that about almost anything ;p | 16:06 |
| natefinch | fwereade: the idea is that the resource bytes are integral to the functionality of the charm. So changing a resource is just as disruptive as changing the charm version | 16:06 |
| natefinch | fwereade: firing upgrade-charm is what is declared in the spec, per rick_h_, mark, jam, etc | 16:07 |
| fwereade | natefinch, oh joy | 16:07 |
| * natefinch is Not In Charge™ | 16:08 | |
| fwereade | natefinch, we start by saying "charm logic and payloads can vary independently, let's add tooling to make those use cases easier" and we end up with "upgrade-charm now means two completely distinct things, have fun charmers!" | 16:08 |
| * marcoceppi watches as this develops | 16:09 | |
| * fwereade turns to marcoceppi and gestures vaguely -- if this *is* a happy outcome for you and those you represent, that's awesome -- is it? | 16:10 | |
| natefinch | marcoceppi, fwereade: http://media0.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif | 16:11 |
| fwereade | natefinch, haha | 16:11 |
| marcoceppi | fwereade: I had concerns of not being a hook available, but was convinced that this was okay. If there's still a way to get a hook I'd be happier | 16:11 |
| marcoceppi | fwereade: if charms have a way to query the version of the resource, without fetching it, then it's not that bad. Just some additional logic in upgrade-charm to determine if it's is new charm code or new resources | 16:12 |
| fwereade | marcoceppi, yeah, absolutely, any state we show you as a charmer *should* be guarded by some hook that's guaranteed to fire if it changes | 16:12 |
| fwereade | marcoceppi, or both ;p | 16:13 |
| marcoceppi | but I'd rather have this feature with upgrade-chram than delay to 2.1 | 16:13 |
| marcoceppi | we can build libraries in the new reactive framework to work around this | 16:13 |
| marcoceppi | or rather, not work around, but enhance this | 16:13 |
| fwereade | marcoceppi, sure, understood, I'm just digging to check that "when we introduce new state to charmers, we should introduce new hooks to inform of changes to same" fits with your baseline desires | 16:15 |
| marcoceppi | fwereade: I'd prefer new hooks, the more granular the event dispatcher the better | 16:16 |
| fwereade | marcoceppi, because, y'know, if we don't tell you about the changes that's obviously stupid, and if we repurpose old hooks we potentially expose latent bugs all over the charm store by changing what hooks will get run in what situations | 16:16 |
| fwereade | marcoceppi, cool | 16:17 |
| fwereade | marcoceppi, to put it another way: you *can* work around a mish-mash of events, many of which mean "some combination of X, Y and Z distinct things changed", but it kinda sucks to have to | 16:18 |
| marcoceppi | in so many words | 16:18 |
| marcoceppi | with the exception of the hook thing, th eresources stuff is brilliant | 16:19 |
| katco | fwereade: marcoceppi: sorry, just read through the backscroll | 16:22 |
| katco | fwereade: marcoceppi: i think the reason that decision was made is because resources never stand alone, it's always the tuple of the charm and resources that is the concept to consider | 16:23 |
| marcoceppi | right, but you can also upgrade resources seperately from the charm | 16:24 |
| katco | fwereade: marcoceppi: so having being notified of a resource being updated is meaningless if you accept that premise | 16:24 |
| katco | marcoceppi: my understanding is that you cannot | 16:24 |
| marcoceppi | I was informed otherwise | 16:24 |
| katco | marcoceppi: resource updated = new rev of the charm | 16:24 |
| marcoceppi | but since you've done the work I'm happy to accept that | 16:24 |
| katco | marcoceppi: who am i contradicting? | 16:24 |
| marcoceppi | so if I release a new version of my applicaiton, that's a charm rev? | 16:24 |
| katco | marcoceppi: yep | 16:25 |
| marcoceppi | but it's just an updated resource | 16:25 |
| rick_h_ | marcoceppi: the 'revision' of a charm becomes a 'revision set' | 16:25 |
| rick_h_ | marcoceppi: that set is the published set of the charm rev, and the rev of each resource | 16:25 |
| rick_h_ | marcoceppi: updating any part of that, is an new revision set that much be processed by the upgrade-charm hook. | 16:26 |
| rick_h_ | that's the way it's currently set out. | 16:26 |
| katco | marcoceppi: check out the 3rd bullet of the 1.0 mvp | 16:26 |
| marcoceppi | okay, so is there a way for me to query, without first accepting the payload, that I've got a new version? | 16:26 |
| marcoceppi | in the charm | 16:26 |
| katco | marcoceppi: as a charmer, not currently. as an admin, yes | 16:26 |
| rick_h_ | marcoceppi: we need that yes. It's not there now, but agree. Honestly it was an optimization thing that came up as we get into using it | 16:26 |
| marcoceppi | okay | 16:27 |
| rick_h_ | marcoceppi: and good feedback that we need to go back with | 16:27 |
| marcoceppi | then I'm cool | 16:27 |
| katco | marcoceppi: you are cool, marcoceppi. | 16:27 |
| marcoceppi | as long as I can say "resource update" | 16:27 |
| katco | very cool :) | 16:27 |
| marcoceppi | at the end of the day, with reactive, we're not going to care about upgrade-charm hook | 16:27 |
| marcoceppi | well some will, most wont | 16:27 |
| rick_h_ | marcoceppi: katco I think we need something like resource-version or resource-changed to go with resource-get. My concern with resource-changed is that if something fails and you retry, will we have the right answer. | 16:27 |
| marcoceppi | we'll only really care about @when('resource.<RESOURCE_NAME>.updated') | 16:27 |
| rick_h_ | marcoceppi: katco so I think there's some thought we need to get that right | 16:28 |
| katco | rick_h_: well, isn't resource-changed redundant? i.e. anytime it would fire, upgrade-charm would also have fired | 16:28 |
| rick_h_ | katco: not as a hook, but as a hook command | 16:28 |
| rick_h_ | katco: e.g. resource-changed mysourcecode | 16:28 |
| rick_h_ | returns true/false | 16:28 |
| marcoceppi | rick_h_ katco is resource-list a hook-tool? | 16:29 |
| rick_h_ | katco: so if one new resource is uploaded out of 3, I can tell which one I need to untar, process, etc | 16:29 |
| katco | marcoceppi: no, juju list-resources | 16:29 |
| fwereade | katco, rick_h_: the issue is surely that upgrade-charm means "your charm logic has changed" and resource-changed means "some of your tweakable blobs have changed" | 16:29 |
| katco | rick_h_: well, that is an optimization. i believe resource-get on a resource that hasn't changed is a nop | 16:30 |
| marcoceppi | so, as a charmer, I want to be able to run "resource-list" in a hook with --format json and get something like "resource_name": "version" for each resource | 16:30 |
| rick_h_ | katco: I'm not so sure | 16:30 |
| fwereade | katco, rick_h_: that we have a tuple of things that represent "exactly what's running on this unit" is... coincidental, if you like? we don't even officially expose charm urls to charmers right now | 16:30 |
| katco | ericsnow: natefinch: is resource-get on an unchanged resource a no-op right now? | 16:31 |
| natefinch | FWIW, we certainly could add a command that tells the unit whether or not it has the latest version of a resource. We store the version each unit has and the version that is current for the service. | 16:31 |
| rick_h_ | fwereade: well it was designed/built to not be coincidental. I see what you mean on "charm logic" vs "blob of data" though. | 16:31 |
| rick_h_ | fwereade: the goal is that when you publish to the charmstore you're declaring "this revision of the charm logic with this revision of this blob and that blob pass tests and work together" | 16:32 |
| marcoceppi | natefinch: exposing that I think will be crucial to making the join charmversion + resourceversion + upgrade-charm work for a charm authors perspective | 16:32 |
| rick_h_ | fwereade: it's the local case that's more muddy | 16:32 |
| marcoceppi | joint* | 16:32 |
| katco | rick_h_: fwereade: yeah it all begins at 1st principles. either the tuple defines the charm, or it doesn't. if it does, then there's no such thing as updating just the blob | 16:32 |
| rick_h_ | marcoceppi: +1 the thing is catching the failure cases and making sure it behaves predictably | 16:32 |
| natefinch | katco: we don't do that optimization... resource-get will always just download the bytes | 16:33 |
| katco | natefinch: fair enough for v1 | 16:33 |
| rick_h_ | natefinch: right, I think we can't noop right now because it means the hooks aren't idempotent | 16:33 |
| katco | rick_h_: mm not true | 16:33 |
| fwereade | natefinch, katco: so the upshot is that every time you get an upgrade-charm, you *have* to resource-get *all* your resources before you can safely move on? | 16:33 |
| natefinch | rick_h_: sure they are... the bytes on disk are the same before and after | 16:33 |
| katco | rick_h_: idempotent = end state is always the same | 16:33 |
| rick_h_ | katco: ah, I see. the bytes are in the folder | 16:33 |
| katco | rick_h_: correct | 16:34 |
| natefinch | fwereade: yes :/ | 16:34 |
| katco | fwereade: yeah, as designed currently\ | 16:34 |
| fwereade | how does this even happen with a supposed "user focus" in design? | 16:34 |
| rick_h_ | fwereade: no, it just means you have to process your logic. | 16:34 |
| rick_h_ | fwereade: happy to hop on a call if you've got questions | 16:34 |
| katco | rick_h_: would join to be a fly on the wall | 16:34 |
| rick_h_ | fwereade: but you're starting to cross into unproductive territory here | 16:34 |
| fwereade | rick_h_, let's, I fear that I misunderstand something horribly | 16:35 |
| rick_h_ | https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 for all interested parties | 16:35 |
| perrito666 | I think I broke RB | 17:08 |
| perrito666 | k people bbl | 17:10 |
| perrito666 | cheers | 17:10 |
| mup | Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796> | 17:28 |
| mup | Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796> | 17:37 |
| mup | Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796> | 17:40 |
| mup | Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796> | 17:43 |
| mup | Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796> | 17:49 |
| mup | Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662> | 17:58 |
| mup | Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662> | 18:01 |
| perrito666 | anyone ever heard of StateServerInstances() ? | 18:12 |
| mup | Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662> | 18:13 |
| mup | Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662> | 18:16 |
| perrito666 | fwereade: still here? | 18:16 |
| perrito666 | fwereade: nevermind | 18:17 |
| mup | Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662> | 18:19 |
| perrito666 | mup: you are a very annoying thing | 18:19 |
| mup | perrito666: Strictly speaking, I'm not intelligent enough to understand that. | 18:19 |
| perrito666 | it shows | 18:20 |
| perrito666 | :p | 18:20 |
| perrito666 | bbl | 18:33 |
| natefinch | katco: so in talking with william and rick, it sounds like we really need a hook command that can tell the charm what resources are out of date for the unit. That should be really easy, since we have all the backend code, we'd just replicate a bunch of juju resources <unit> in a hook command. | 18:40 |
| katco | natefinch: i agree that sounds like a good idea. let's revisit after we deliver what's on our plate already | 18:43 |
| natefinch | katco: yep... and FWIW, rick was able to convince william that we should stick with the charm-upgrade hook, mostly because it's sorta too late to do anything else. | 18:46 |
| katco | natefinch: yeah | 18:46 |
| katco | natefinch: i wonder if we looked at how we support things, we couldn't support releasing changes like that more easily | 18:47 |
| natefinch | katco: I think making a new hook wouldn't been the end of the owrld, but it woudl definitely be a few more days work than finishing up what we have... and we don't really have a few days to spare. | 18:47 |
| katco | natefinch: then the conversation becomes, "that's a good idea. we'll do that next month" instead of "omg change course! change course! we can't have a breaking change!" | 18:47 |
| natefinch | katco: rick was positing that it could be delivered later... I'm not 100% convinced that's true, though, since it would break charms that rely on charm-upgrade getting called. | 18:48 |
| natefinch | (for resource changes) | 18:48 |
| katco | natefinch: we should make more liberal use of our versioned concepts outside of the macro version of juju | 18:48 |
| katco | natefinch: and deprecate old versions of things more regularly (apis, hook commands, cli) | 18:49 |
| natefinch | katco: well, yeah, we should deliver min-juju-version, which would help with that | 18:49 |
| katco | natefinch: true | 18:49 |
| natefinch | katco: (in our spare time) | 18:51 |
| natefinch | perrito666: you back yet? | 18:51 |
| natefinch | super short review for someone? re-enables showing full API params during tests (if you use the verbose flag during the test). http://reviews.vapour.ws/r/3887/diff/# | 19:02 |
| voidspace | EOW, bye all | 19:12 |
| natefinch | gah, what I wouldn't give for focused unit tests in the uniter code, so I could narrow down where the bug is in my code :/ | 19:23 |
| katco | natefinch: i think you and ericsnow better pair up to get through this | 19:39 |
| natefinch | katco: yep | 19:40 |
| natefinch | katco: sorry, missed when he came back online. | 19:40 |
| natefinch | ericsnow: help me ericsnowcurrently, you're my only hope! | 19:41 |
| ericsnow | natefinch: let's get it done! | 19:41 |
| katco | ericsnow: natefinch: i'm done with admin stuff. reviewing your code now | 19:42 |
| rick_h_ | cherylj: I've got to get the boy from school and will be late to our meeting with folks. Can you bug thumper please? | 19:56 |
| rick_h_ | cherylj: I'll have to work with him to move that back since it's sitting in this bad spot | 19:56 |
| cherylj | rick_h_: sure, will do | 19:57 |
| === urulama is now known as urulama__ | ||
| * thumper heading to dentist with daughter two | 20:42 | |
| rick_h_ | thumper: doh, looks like I missed you | 20:43 |
| davecheney | 0 for 2 rick_h_ | 20:55 |
| rick_h_ | davecheney: yea, he's avoiding me. Scheduling things during school time and then running off to dentists. | 20:56 |
| rick_h_ | :P | 20:56 |
| perrito666 | Katco I won't make it to your standup, stuck in traffic sorry | 21:23 |
| katco | perrito666: np, i just marked you and anastasiamac as optional | 21:23 |
| wwitzel3 | perrito666 do it from the car :P | 21:23 |
| perrito666 | I can IRC from traffic jams, how cool is that? | 21:24 |
| perrito666 | Honestly if the lte dongle wasn't in the trunk I could | 21:24 |
| wwitzel3 | ahh, the person grabbed it from you as you pushed them in there? | 21:25 |
| wwitzel3 | ;) | 21:25 |
| perrito666 | There is no respect anymore | 21:26 |
| * perrito666 shouts at the trunk | 21:28 | |
| perrito666 | Traffic is moving bbl | 21:35 |
| * perrito666 is back | 21:53 | |
| perrito666 | wallyworld: around? | 22:02 |
| wallyworld | in a meeting | 22:05 |
| natefinch | ericsnow: sorry... I'll give that a test and see if it needs tweaking or anything | 22:06 |
| natefinch | ericsnow: thanks for the help | 22:06 |
| ericsnow | natefinch: cool | 22:06 |
| === natefinch is now known as natefinch-afk | ||
| perrito666 | yay go 1.6 | 22:23 |
| marcoceppi | perrito666: time to pack it up and move juju to 1.6 ;) | 22:28 |
| bogdanteleaga | I'm actually thinking of going back to an older version to save those insane compilation times | 22:33 |
| perrito666 | bogdanteleaga: the only way to advance is forward | 22:38 |
| mup | Bug #1546790 opened: availability zone not set <juju-core:New> <https://launchpad.net/bugs/1546790> | 22:40 |
| bogdanteleaga | perrito666, at least by golang 2.0 the test suite run time won't be the bottleneck | 22:41 |
| mup | Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794> | 22:58 |
| mup | Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795> | 22:58 |
| mup | Bug #1546794 changed: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794> | 23:01 |
| mup | Bug #1546795 changed: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795> | 23:01 |
| mup | Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794> | 23:11 |
| mup | Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795> | 23:11 |
| * perrito666 prepares for standup, suddenly remembers there is no standup today | 23:13 | |
| wallyworld | perrito666: anastasiamac: axw: meeting finished early, let's have standup | 23:27 |
| mup | Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805> | 23:29 |
| mup | Bug #1546805 changed: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805> | 23:35 |
| mup | Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805> | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
