| menn0 | wallyworld: tyvm for the review. You're right about the logging/error handling. I'll improve it. | 00:03 |
|---|---|---|
| wallyworld | menn0: bp, i got distracted and didn't let you know i had done ir, sorry | 00:03 |
| wallyworld | *np | 00:03 |
| menn0 | wallyworld: np, I was busy with the next thing anyway | 00:04 |
| axw | wallyworld: are you working on any of those bugs? just don't want to double up | 01:19 |
| wallyworld | axw: i had good intentions but haven't started yet | 01:20 |
| wallyworld | are they legit issues? | 01:20 |
| axw | wallyworld: nps. yes, I think so. | 01:20 |
| wallyworld | ok | 01:20 |
| axw | wallyworld: actually, create-model would not work on master for manual either | 01:28 |
| axw | wallyworld: but meh, I can fix it on admin-controller-model with one line change | 01:28 |
| wallyworld | axw: that was the point i tried to make and they were not wanting to ack that | 01:28 |
| wallyworld | ok that would be good | 01:28 |
| anastasiamac | axw: there is also a bug for create-model on azure bug 1558769 | 01:32 |
| mup | Bug #1558769: unable to create-model in azure <juju-core:New> <https://launchpad.net/bugs/1558769> | 01:32 |
| anastasiamac | axw: is it related and will b fixed by the one line change above? :D | 01:33 |
| axw | anastasiamac: I saw, thank you. I think wallyworld already fixed it, but I'll double check | 01:33 |
| anastasiamac | \o/ | 01:33 |
| axw | anastasiamac: nah, the manual one is specific to manual | 01:33 |
| anastasiamac | axw: thnx :D | 01:33 |
| axw | wallyworld: sorry, actually, the problem is worse on admin-controller-model. you can't even bootstrap, because we try to create a hosted model automatically | 01:43 |
| wallyworld | axw: understood. but root cause comes form master | 01:44 |
| wallyworld | the test would have seem it if they had existed | 01:44 |
| wallyworld | seen | 01:44 |
| axw | wallyworld: you can't create-model on master, you can't even bootstrap on this branch. yes, we would have caught it earlier if we tested create-model in all substrates | 01:44 |
| wallyworld | axw: indeed. but i want to snure the bug is correctly targetted - i am tired of pushback to fix issues in feature branches which blocks work where the root cause comes from master | 01:46 |
| mwhudson | oh yeah i found https://tracker.debian.org/pkg/golang-golang-x-tools yesterday i think | 01:47 |
| mwhudson | whoops | 01:48 |
| axw | wallyworld: just a few more small things on the PR | 02:38 |
| wallyworld | ok | 02:38 |
| wallyworld | axw: the maas agent-name thing is because we grab the controller model and end up calling PrepareForCreateEnvironment() which doesn't like the agent name being there | 02:39 |
| wallyworld | i need to rework it a bit | 02:39 |
| axw | wallyworld: okey dokey | 02:39 |
| axw | wallyworld: I thought we didn't copy across attrs if they were restricted? | 02:40 |
| axw | or ... non restricted | 02:40 |
| wallyworld | axw: that could be - but it seems we do now | 02:41 |
| wallyworld | likely a bug from me supporting new create model | 02:41 |
| axw | wallyworld: possibly also in the code I added to agent/agentbootstrap | 02:44 |
| wallyworld | yeah, it won't taje much to fix i don't think | 02:44 |
| wallyworld | axw: http://reviews.vapour.ws/r/4222/ | 03:13 |
| axw | wallyworld: looking | 03:14 |
| axw | wallyworld: I'm looking at the other bug btw | 03:14 |
| wallyworld | ta | 03:14 |
| axw | wallyworld: I think your change means the credentials won't be copied across | 03:15 |
| axw | wallyworld: and things from --config | 03:15 |
| wallyworld | isn't the stuff in --config in HostedModelConfig arg? | 03:16 |
| axw | I don't think so, but I'll check | 03:16 |
| wallyworld | i may need to do credentials though | 03:16 |
| axw | wallyworld: nope, it's not | 03:16 |
| wallyworld | damn, what is in that arg? | 03:16 |
| axw | wallyworld: model name, uuid | 03:17 |
| axw | wallyworld: it's set in cmd/juju/commands/bootstrap.go | 03:17 |
| wallyworld | hmmm, ok. may need to add the --config to that arg then maybe | 03:17 |
| axw | wallyworld: and credentials... | 03:17 |
| wallyworld | yup | 03:17 |
| axw | wallyworld: problem is how to separate credentials from things like maas-agent-name | 03:18 |
| wallyworld | on bootstrap we don't need to worry right? | 03:18 |
| wallyworld | and it's taken care of in create model that is used by create-model command | 03:19 |
| wallyworld | maas-aganr-name is add in PrepareForCreateEnvironment. on bootstrap, it won't be there in passed in config, or will error if it is. in create-model we create a skeleton config | 03:20 |
| axw | wallyworld: how are you going to get the credential attrs? | 03:20 |
| wallyworld | need to look into that | 03:21 |
| axw | wallyworld: rhetorical question. the answer is (currently) to call EnvironProvider.BootstrapConfig | 03:21 |
| axw | wallyworld: that adds the credential attrs to the config given a cloud.Credential | 03:22 |
| wallyworld | ok | 03:22 |
| axw | wallyworld: ... but it also adds maas-agent-name | 03:22 |
| wallyworld | ah damn ok | 03:22 |
| axw | wallyworld: I think what we could is this: call RestrictedConfig, make sure we include those, and delete anything that's not passed in via --config | 03:23 |
| wallyworld | except for credentials maybe | 03:23 |
| axw | wallyworld: I was thinking they're restricted... but yeah, they're not | 03:24 |
| axw | le sigh | 03:24 |
| wallyworld | sigh indeed, i found out the same thing | 03:24 |
| wallyworld | axw: it's all good. all i need to do is include --config in the hosted model config arg. (c ModelConfigCreator) NewModelConfig does the right thing with credentials | 03:36 |
| axw | wallyworld: ah, I see | 03:38 |
| axw | wallyworld: uhm, although, it's kinda wrong :/ | 03:39 |
| axw | wallyworld: those credential attributes are not supposed to map 1:1 | 03:39 |
| wallyworld | they sort of do atm in common usage | 03:40 |
| wallyworld | but they don't have to that's true | 03:40 |
| axw | wallyworld: they do atm, but it's an abstraction breakage, and means we're buggered if we change something | 03:40 |
| wallyworld | yep | 03:40 |
| axw | wallyworld: I think we may need something on EnvironProvider to identify which things to carry across | 03:41 |
| wallyworld | was a quick win, we need to fix the tech deby | 03:41 |
| wallyworld | solves the common case for admins creating new models | 03:41 |
| axw | wallyworld: or we update PrepareForCreateEnvironment to take a Credential too | 03:41 |
| wallyworld | that might be better | 03:41 |
| axw | wallyworld: or ... maybe separate BootstrapConfig even further to convert Credential to attrs | 03:42 |
| wallyworld | or that | 03:42 |
| axw | wallyworld: main problem is that some cloud.Credentials only make sense at the client (e.g. ones that refer to files) | 03:43 |
| wallyworld | indeed | 03:43 |
| axw | tho we should convert them | 03:43 |
| wallyworld | we need to think it through | 03:43 |
| axw | wallyworld: https://bugs.launchpad.net/juju-core/+bug/1558803/comments/1 | 03:44 |
| mup | Bug #1558803: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <ppc64el> <regression> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558803> | 03:44 |
| wallyworld | the file values are parsed server side, need to do that client side | 03:44 |
| wallyworld | did you find an issue? | 03:45 |
| axw | wallyworld: a pretty minor one - see comment | 03:45 |
| axw | wallyworld: I've regargeted and lowered importance | 03:50 |
| wallyworld | axw: sorry, got pinged still to look | 03:50 |
| wallyworld | axw: it's not even relevant to admin controller branch is it | 03:51 |
| axw | wallyworld: no, I've removed that | 03:51 |
| wallyworld | ah cool | 03:51 |
| axw | wallyworld: and set the medium, and removed regression tag | 03:51 |
| * wallyworld hits refresh | 03:51 | |
| menn0 | axw or wallyworld: http://reviews.vapour.ws/r/4223/ please | 03:52 |
| wallyworld | menn0: i can look in a bit, just wip atm | 03:52 |
| menn0 | wallyworld: thanks | 03:53 |
| axw | in that case, I'll go get lunch | 03:53 |
| jam | wallyworld: quick ping. Do you remember how to tell a test what tools to use? It looks like EC2 tests were relying on side-effects from some other test to set up tools | 03:54 |
| wallyworld | jam: that has recently changed, we were relying on cloud (provider storage) which is gone. rthere are helpers to uplod tools to state | 03:58 |
| wallyworld | i can look up the methods | 03:58 |
| jam | wallyworld: so with my recent change to fix SetUp stuff, provider/ec2 is not finding tools. It looks like the FakeVersionNumber is 1.99.0 but it only sees 2.0-beta3 tools in the faked out location. | 03:59 |
| jam | looks like something is faking out tools before we fake out the version number | 03:59 |
| jam | trying to sort out where that may be | 03:59 |
| wallyworld | jam: i'll take a look, i am not deeply familiar as i didn't see the final code | 04:00 |
| jam | environs/jujutest/livetests.go SetUpTest looks like it is doing the right thing (calls FakeVersionNumber before it calls UploadFakeTools) | 04:00 |
| jam | wallyworld: k, I have the feeling this is old semi-rotten code | 04:00 |
| wallyworld | axw: pushed new changes to that maas fix | 04:00 |
| jam | ah, maybe its me | 04:00 |
| jam | I moved one of the PatchValue calls | 04:00 |
| wallyworld | ah | 04:01 |
| jam | because it was happening before SetUp | 04:01 |
| wallyworld | joy | 04:01 |
| jam | which is unsafe, because we haven't called IsolationSuite.SetUp yet | 04:01 |
| wallyworld | a lot of the tests rely on patching version | 04:01 |
| mup | Bug #1558901 opened: TestAddLocalCharmSuccess read has been closed <ci> <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1558901> | 04:01 |
| jam | so we haven't told it what test we're about to run. I think I can just patch for the lifetime of the Suite and we'll be ok | 04:01 |
| wallyworld | i think that souuds ok | 04:02 |
| jam | nope... :( | 04:02 |
| jam | wallyworld: we had a lot of tests that were doing "SetUpSuite() { base.SetUpTest() }" | 04:03 |
| jam | those were interesting. | 04:03 |
| wallyworld | wot? | 04:03 |
| wallyworld | wow | 04:03 |
| wallyworld | i hope i didn't write any | 04:03 |
| jam | wallyworld: FakeXDGHomeDir was one of them | 04:04 |
| jam | apparently broken since 2014 according to blame. | 04:04 |
| wallyworld | huh. thats actually old code renamed | 04:04 |
| jam | wallyworld: yeah, a bunch of our base infrastructure was actually wrong. | 04:04 |
| wallyworld | at yeast it will be right now :-) | 04:04 |
| jam | wallyworld: BaseSuite.SetUpSuite() was calling PatchValue(utils.OutsideAccess) | 04:05 |
| wallyworld | lol yeast. i can' type | 04:05 |
| jam | which would be reset on the first test that ran | 04:05 |
| jam | except we leaked it somewhere early | 04:05 |
| jam | so it was always false | 04:05 |
| wallyworld | oh dear | 04:05 |
| anastasiamac | wallyworld: axw: before I can bootstrap master tip on my openstck, I need to add-cloud and i guess add-credential | 04:05 |
| jam | so it was Correct, but for the wrong reasons. | 04:05 |
| jam | anyway, provider/ec2 is the last bastion of failing tests, so I'm close. | 04:05 |
| anastasiamac | where do I put auth-url? in my-cloud.yaml or my-credential.yaml? | 04:06 |
| wallyworld | anastasiamac: that's a credential attribute | 04:06 |
| anastasiamac | k | 04:06 |
| wallyworld | anastasiamac: if you have a novarc and master, it will auto detect | 04:06 |
| jam | wallyworld: auth-url isn't that what URL to hit which is a cloud attribute? | 04:06 |
| jam | (souds like a per-region attribute) | 04:06 |
| wallyworld | jam: we have endpoint url which i think is different but i haven't look specifically at openstack for a bit so could be misremembering | 04:07 |
| wallyworld | jam: but i think you may be right | 04:08 |
| anastasiamac | wallyworld: I have novarc but do I need to have it somehwere in a special place? | 04:08 |
| wallyworld | ~/.novarc | 04:09 |
| anastasiamac | :D | 04:09 |
| anastasiamac | so in this case, I do not need to add-credentials? | 04:09 |
| cherylj | Can I get a review? https://github.com/juju/juju/pull/4783 | 04:10 |
| cherylj | (this is for the restore failure on master) | 04:10 |
| wallyworld | jam: yes, i looked at the code and confirmed you are right | 04:11 |
| wallyworld | cherylj: looking | 04:11 |
| cherylj | thanks, wallyworld. I had to shuffle things around to be able to mock out stuff for testing | 04:12 |
| cherylj | turns out that there really aren't tests for restore :( | 04:12 |
| jam | wallyworld: ... provider/ec2/ LocalLiveTests embeds LiveTests but doesn't call LiveTests.SetUpTest() | 04:15 |
| wallyworld | win | 04:15 |
| axw | anastasiamac: if you have ~/.novarc, or if you just source your novarc in your shell, you can do "juju bootstrap <controller> openstack" | 04:16 |
| wallyworld | cherylj: only ci tests it seems | 04:16 |
| cherylj | yeah | 04:16 |
| axw | wallyworld: eating lunch, will look again soon | 04:16 |
| wallyworld | np, thanks | 04:17 |
| jam | cherylj: why is there a "fakeEnviron" in live code? | 04:17 |
| cherylj | jam: for mocking out the environ in the test. We only set it in tests | 04:18 |
| axw | wallyworld: actually I can review that while eating :) | 04:18 |
| axw | LGTM | 04:18 |
| anastasiamac | axw: i have both ~/.novarc and sourced it in the shell, but when I "juju bootstrap <my controller> openstack" I get "ERROR missing auth-url not valid | 04:18 |
| anastasiamac | " | 04:18 |
| axw | anastasiamac: that would suggest you're missing OS_AUTH_URL from the file | 04:19 |
| axw | anastasiamac: where did you get the novarc file from? | 04:19 |
| jam | cherylj: have you done manual testing of an environment that really hasn't ever existed? | 04:19 |
| anastasiamac | axw: it would... but I don't | 04:19 |
| anastasiamac | it's in the file | 04:19 |
| anastasiamac | that was supplied | 04:20 |
| axw | oh, that's odd | 04:20 |
| axw | anastasiamac: does it have "export OS_AUTH_URL" in it per chance? | 04:20 |
| axw | anastasiamac: wallyworld fixed a bug yesterday to do with that | 04:20 |
| axw | :q | 04:20 |
| axw | oops | 04:20 |
| anastasiamac | axw: yes, everything in the file has an export... and m running from master tip as of 1hr ago :D | 04:21 |
| wallyworld | cherylj: i've made a request to alter things slightly to better set up for testing | 04:22 |
| axw | anastasiamac: ok then, I dunno. sounds like a bug | 04:22 |
| wallyworld | axw: anastasiamac: it's a bug that's been there for a while | 04:23 |
| axw | anastasiamac: try moving the file away from ~/.novarc and sourcing it, and see if that makes a difference | 04:23 |
| wallyworld | DetectRegions() only calls CredentialsFromEnv() | 04:23 |
| jam | cherylj: reviewed. | 04:23 |
| wallyworld | not the new DetectCredentials() code | 04:23 |
| axw | wallyworld: anastasiamac said she sourced it as well tho | 04:23 |
| wallyworld | don't believe it :-) | 04:24 |
| wallyworld | since that should have worked | 04:24 |
| anastasiamac | wallyworld: right.... | 04:24 |
| wallyworld | unless there's a 3rd problem | 04:24 |
| wallyworld | i think openstack has been used with beta2 which is where sourcing the novarc would have been required | 04:25 |
| anastasiamac | wallyworld: m so calling u for that! | 04:25 |
| axw | jam: any idea why SetInstanceStatus is so slow? it's all local, so should be super fast :( | 04:35 |
| jam | axw: I don't know specifically, but IIRC the spec wanted to rate limit charms calling it | 04:35 |
| jam | given how accurate it is to 1.0s | 04:35 |
| jam | I think its just a time.Sleep somewhere. | 04:36 |
| axw | jam: ok, I'll dig. we should probably use the ratelimit package with a token bucket | 04:37 |
| jam | well, it could be that, too. I just get the feeling it is explicitly limiting itself, which interacts poorly with fast downloads and a set number of events | 04:38 |
| jam | wallyworld: and now the test suite "passes" but a test is taking 60s, investigation looks like it is accessing my EC2 credentials and launching a real instance... | 04:54 |
| jam | (ec2.localLiveSuite) not so local | 04:55 |
| wallyworld | jam: localLive tests, from memory, are run both local and live | 04:55 |
| wallyworld | that distinction goes waaaaaay back | 04:55 |
| wallyworld | i wish we dropped live tests, we don't need them now | 04:56 |
| wallyworld | i guess they were added for juju 0.1 before we had CI | 04:56 |
| cherylj | wallyworld: Can you take another look? http://reviews.vapour.ws/r/4224/ | 05:06 |
| cherylj | wallyworld: Also, I think that the backup / restore commands should be controller commands, not model commands | 05:07 |
| cherylj | but that's outside the scope of this PR | 05:07 |
| wallyworld | cherylj: looking | 05:09 |
| wallyworld | cherylj: thanks for that fix. ideally we'd not have the func as an arg to NewRestoreCommand. There'd be a NewRestoreCommandForTest() in export_text. see detectcredentials.go in juju/cmd/juju/cloud and also the NewDetectCredentialsCommandForTest in export_test.go | 05:13 |
| cherylj | wallyworld: ok, I see. Give me a few and I'll update it | 05:15 |
| cherylj | wallyworld: okay, maybe 3rd time's the charm | 05:22 |
| wallyworld | :-) | 05:22 |
| wallyworld | looking | 05:22 |
| wallyworld | cherylj: very small issue, lgtm | 05:26 |
| cherylj | ha, sorry it's taking so long. I'm so very tired | 05:26 |
| jam | wallyworld: hm, looks like it isn't talking to EC2, just that we have a 60s timeout waiting for a security group that is being used to be released | 05:29 |
| jam | maybe a setup was supposed to be changing that timeout | 05:30 |
| jam | (just ran in offline mode and had the same result) | 05:30 |
| wallyworld | could be | 05:30 |
| wallyworld | we have so many tests with clocks to fix | 05:30 |
| wallyworld | cherylj: indeed, you should not be at work | 05:30 |
| cherylj | and with that... bedtime | 05:31 |
| wallyworld | see ya | 05:31 |
| wallyworld | axw: also, i did end up needing to remove all the CompatSalt stuff yesterday, as bootstrap still relied on it and it needed to be killed | 05:32 |
| axw | wallyworld: cool | 05:32 |
| axw | wallyworld: does it need re-reviewing? | 05:32 |
| wallyworld | axw: nah, was 99% cut | 05:32 |
| wallyworld | i tested live | 05:32 |
| axw | wallyworld: sounds good | 05:33 |
| wallyworld | i tested i could log into mongo console from machine 0 as well as a deployment | 05:33 |
| wallyworld | axw: awesome, the interactive add credential branch doesn't appear to compile on go 1.2 | 05:54 |
| axw | wallyworld: ? :/ | 05:55 |
| wallyworld | compiles and runs locally | 05:55 |
| wallyworld | http://juju-ci.vapour.ws:8080/job/github-merge-juju/6912/console | 05:55 |
| wallyworld | i'll have to get go 1.2 to repro | 05:55 |
| wallyworld | unless i'm being dumb | 05:56 |
| axw | wallyworld: nothing obvious to me | 05:57 |
| wallyworld | sigh | 05:57 |
| jam | wallyworld: k. there is definitely a problem with 60s to destroy, but it exists in Master as well, so my code is better than previous | 05:59 |
| wallyworld | jam: i've found and fixed a few bad tests lately too. our code has many :-( | 06:00 |
| mup | Bug #1558924 opened: provider/ec2 localLiveSuite.TestGlobalPorts localLiveSuite.TestStartStop takes 60s <tech-debt> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1558924> | 06:08 |
| wallyworld | axw: am merging master into admin-controller-model... soooo many conflicts \o/ | 07:25 |
| wallyworld | will have to finish after soccer | 07:25 |
| axw | wallyworld: thank you | 07:25 |
| axw | wallyworld: my current status is refactoring modelcmd/juju code in between bouts of sneezing | 07:26 |
| axw | need to refactor so I can pass in alternative credentials | 07:26 |
| wallyworld | ok | 07:26 |
| wallyworld | i still need to install go 1.2 and resolve that other issue also | 07:27 |
| anastasiamac | axw: is this ur juju allergies making u sneeze? :P | 08:07 |
| axw | anastasiamac: naw, got a sleep-deprivation induced cold I think | 08:08 |
| anastasiamac | axw: :( sounds awful | 08:10 |
| voidspace | frobware: ping | 09:22 |
| frobware | voidspace: pong | 09:22 |
| frobware | voidspace: I pushed your branch | 09:22 |
| voidspace | frobware: yeah, I see it | 09:22 |
| voidspace | frobware: no CI run yet though | 09:23 |
| frobware | voidspace: as upstream/drop-maas-1.8-support-from-juju2 | 09:23 |
| frobware | voidspace: nope... | 09:23 |
| voidspace | frobware: I'm writing up a high-level sketch of the maas 2 work | 09:23 |
| frobware | voidspace: but then again our multi-nic branch only only started running this morning | 09:23 |
| frobware | voidspace: thanks! \o/ | 09:24 |
| voidspace | frobware: the gomaasapi test server needs not far short of a full rewrite, so that's not a small chunk of work | 09:24 |
| voidspace | :-/ | 09:24 |
| voidspace | frobware: I think a new one, with some shared code, will be cleaner than a single implementation or an interface based approach | 09:24 |
| frobware | voidspace: given the time remaining is that at all feasible? Or even desirable? | 09:26 |
| voidspace | frobware: I think it's the only reasonable approach | 09:28 |
| voidspace | frobware: the TestServer has about thirty attributes, most of which won't be used for 2.0 | 09:28 |
| voidspace | frobware: so a monster with 60 fields and branches in every method will be impossible to work on | 09:29 |
| voidspace | frobware: that's what I think | 09:29 |
| voidspace | frobware: a lot of the code can be shared (all the endpoint stuff) | 09:29 |
| voidspace | frobware: but maybe there's a middle ground somewhere | 09:29 |
| perrito666 | wallyworld: https://github.com/juju/juju/pull/4761 but for some reason rb didnt pick it, perhaps the conflict? | 09:30 |
| frobware | voidspace: realistically I think we should consider that middle ground, otherwise the potential of adding new bugs is a concern | 09:30 |
| voidspace | frobware: I don't think hugely branching code is less likely to introduce bugs | 09:31 |
| voidspace | that's my worry | 09:31 |
| voidspace | anyway | 09:32 |
| TheMue | morning | 09:32 |
| voidspace | TheMue: o/ | 09:32 |
| fwereade | voidspace, frobware, dimitern, dooferlad: would one of you please check the AddressAllocation test changes in jujud/agent, in http://reviews.vapour.ws/r/4110/diff/5/?page=2 ? | 09:42 |
| fwereade | ashipika, by the way, I am deeply suspicious of what github thinks about that branch -- I am planning to just apply the correct diff to MADE-model-workers in a new branch -- will that inconvenience you horribly? | 09:43 |
| ashipika | fwereade: nah, not really.. just give me the new branch and i'll rebase :) | 09:44 |
| fwereade | ashipika, cool, just a heads up :) | 09:45 |
| ashipika | fwereade: thanks! | 09:45 |
| ashipika | fwereade: when do you expect this to land? | 09:45 |
| fwereade | ashipika, I have a ship it, so hopefully today | 09:46 |
| ashipika | fwereade: \o/ | 09:46 |
| fwereade | ashipika, although that's just onto MADE-model-workers, which needs to be updated with latest trunk and then make CI happy | 09:47 |
| dimitern | fwereade, looking | 09:48 |
| voidspace | frobware: stdup? | 10:03 |
| frobware | voidspace: oops, sidetracked. omw | 10:03 |
| fwereade | dimitern, for reference: I dropped the skipped tests, and added one test that enables the feature flag and checks there's an address-cleaner worker running alongside all the usual ones | 10:10 |
| fwereade | dimitern, I called it address-cleaner because that seemed to be its main job, let me know if I misunderstood anything | 10:10 |
| dimitern | fwereade, that sounds good to me | 10:33 |
| fwereade | dimitern, ok, cool, will be submitting it as RB4225 in a few seconds then :) | 10:34 |
| dimitern | fwereade, go for it :) | 10:37 |
| dimitern | frobware, voidspace, there's the fix for those panics: http://reviews.vapour.ws/r/4226/ | 10:37 |
| frobware | dimitern: will stash the lxd changes and try your PR now | 10:58 |
| dimitern | frobware, cheers | 10:58 |
| frobware | dimitern: do you know why in the container the device are not ifup'd? | 11:00 |
| frobware | dimitern: I now have 3 nics, but without an ifup they have no addrs | 11:01 |
| dimitern | frobware, hmm no idea - it works like that for lxc | 11:01 |
| dimitern | frobware, maybe something is blocking the networking job to finish bringing them up? ntpdate lock contention? | 11:01 |
| frobware | dimitern: will take a look after trying your changes | 11:02 |
| dimitern | frobware, ok | 11:02 |
| dimitern | frobware, btw I've realized we're lagging behind 2 major feature branch merges into master | 11:03 |
| frobware | dimitern: I think we need to decide whether it makes sense to create one singular network profile, or one profile per container | 11:03 |
| frobware | dimitern: this is an entropy judgement call | 11:04 |
| dimitern | frobware, one per container seems to be the simplest option, considering the hwaddr needs to match | 11:04 |
| frobware | dimitern: in my mind we should get the multi-nic branch back to the state of maas-spaces2, CI-wise. | 11:04 |
| dimitern | frobware, I'm looking into how bad the conflicts are | 11:04 |
| frobware | dimitern: then look at merging master | 11:05 |
| dimitern | frobware, that's a good point | 11:06 |
| dimitern | frobware, but if we lag too much behind it will only get harder | 11:06 |
| frobware | dimitern: I know. but equally adding the unknown is ... | 11:07 |
| frobware | dimitern: I think there's benefit in giving the OS folks a known state today | 11:07 |
| frobware | dimitern: yes, the hwaddr forces that decision. | 11:08 |
| dimitern | frobware, I wouldn't rush to do a merge today exactly for that matter | 11:09 |
| dimitern | http://paste.ubuntu.com/15413949/ | 11:09 |
| frobware | dimitern: so entropy level at lines 1..3624. :) | 11:11 |
| dimitern | frobware, that's BS though as I did reset --hard FETCH_HEAD before, redoing it properly now | 11:12 |
| dimitern | frobware, it's entirely not that bad: http://paste.ubuntu.com/15413972/ | 11:15 |
| frobware | dimitern: well, that's a lot better | 11:17 |
| dimitern | frobware, it even builds, running make check now and a live test with the bundle | 11:17 |
| frobware | dimitern: I think we need to decide how to spend the rest of the day; polish the branch and give it to OS folks, or merge and polish | 11:17 |
| dimitern | frobware, I think those two are not necessarily mutually exclusive | 11:20 |
| dimitern | frobware, OS folks can test the maas-spaces-multi-nic-containers + my proposed fix and the workaround bouncing the MA of machine-0 | 11:21 |
| frobware | dimitern: ah, you still need to bounce the MA | 11:21 |
| dimitern | frobware, yeah | 11:21 |
| dimitern | frobware, if you're deploying containers on machine 0 | 11:22 |
| frobware | dimitern: right | 11:22 |
| frobware | dimitern: we can merge master; we can also give the OS folks a specific commit for testing. that would allow us to move on. thoughts? | 11:23 |
| dimitern | frobware, we can give them a binary tarball to try, while we sync up with master (and assuming that does not cause a regression for multi-nic stuff) | 11:23 |
| frobware | dimitern: thedac seemed happy with checkout a commit id last time; it's also easier if we want them to move to a different commit | 11:24 |
| dimitern | frobware, fair enough | 11:24 |
| dimitern | frobware, but otherwise I think that sounds like the plan for today? | 11:24 |
| frobware | dimitern: great | 11:25 |
| frobware | dimitern: ah... one other thing... | 11:25 |
| frobware | dimitern: if we can first resolve the missing mac addr that would allow lxd end-to-end | 11:25 |
| dimitern | frobware, right! | 11:26 |
| frobware | dimitern: can you look at that next? | 11:26 |
| dimitern | frobware, I'll look into that when I'm back ~1h | 11:26 |
| frobware | dimitern: thanks! | 11:26 |
| fwereade | ashipika, MADE-model-workers is up to date with the model-agent-integration work | 11:26 |
| dimitern | and I'll leave the live test and make check going in the mean time | 11:26 |
| frobware | dimitern: I have to say this is why I don't want to merge master: http://reports.vapour.ws/releases/3776 | 11:27 |
| frobware | dimitern: multi-nic came from the tip of maas-spaces2 and that had only 2 failures | 11:27 |
| frobware | dimitern: we should really get back to that state first | 11:27 |
| dimitern | frobware, well, we touched a lot of places in the multi-nic branch | 11:29 |
| dimitern | frobware, voidspace, btw a review on http://reviews.vapour.ws/r/4226/ will be appreciated :) | 11:30 |
| * dimitern is out for ~1h | 11:30 | |
| ashipika | fwereade: that's a feature branch i presume? | 11:30 |
| frobware | dimitern: no issues with what we've changed; just for our own sanity bringing new stuff may make it harder to differentiate root cause analysis | 11:32 |
| fwereade | ashipika, yeah | 11:34 |
| frobware | dimitern: getting closer with lxd: http://pastebin.ubuntu.com/15414021/ | 11:36 |
| frobware | dimitern: cannot login using juju ssh but can ordinarily. error fetching address for machine "0/lxd/0": private no address | 11:38 |
| frobware | voidspace: CI run 3777 is the drop-1.8 support. | 11:41 |
| voidspace | frobware: ah, cool | 12:01 |
| voidspace | frobware: lots blocked and a couple of build-binary failures | 12:02 |
| voidspace | frobware: I'm looking at the failures | 12:02 |
| voidspace | frobware: problems with lxc-start in the build binary | 12:04 |
| frobware | voidspace: log? link? | 12:04 |
| voidspace | frobware: http://data.vapour.ws/juju-ci/products/version-3777/build-binary-wily-amd64/build-884/consoleText | 12:05 |
| voidspace | frobware: same problem on build-binary-wily-arm64 | 12:05 |
| voidspace | doesn't *look* like a problem with the code | 12:05 |
| voidspace | the logs are "terse" though | 12:05 |
| frobware | voidspace: check status of master too | 12:06 |
| voidspace | looking | 12:06 |
| voidspace | frobware: they succeeded on master | 12:06 |
| voidspace | frobware: my guess is that other tests will be gated on the binary build being successful | 12:07 |
| voidspace | mgz: ping | 12:07 |
| frobware | voidspace: so it may depend on when you branched or did your checkout | 12:07 |
| voidspace | frobware: was that a problem on master before? | 12:08 |
| frobware | voidspace: you would have to take a look back through the previous builds | 12:08 |
| voidspace | frobware: failing to build the binary seems likely (to me) to be an infrastructure problem | 12:11 |
| frobware | voidspace: maybe mgz knows more | 12:13 |
| tvansteenburgh | hey guys, i have a fresh xenial with a fresh juju 1.25.3. `ps -aef |grep juju` returns nothing. how do i get juju running, or figure out why it won't start? | 12:22 |
| tvansteenburgh | never mind, got it going again with the juju-clean plugin, sorry for the noise | 12:35 |
| mup | Bug #1559062 opened: ensure-availability not safe from adding 7+ nodes, can't remove stale ones <juju-core:New> <https://launchpad.net/bugs/1559062> | 12:47 |
| dimitern | frobware, voidspace, back again | 12:53 |
| voidspace | dimitern: welcome | 12:54 |
| voidspace | frobware: that test run was useles, all the interesting tests were blocked by the build binary failure | 12:54 |
| voidspace | frobware: waiting for comment on that from mgz | 12:54 |
| frobware | yep | 12:54 |
| dimitern | voidspace, frobware, so I after merging master into multi-nic, make check passes, and the live test with the bundle still works | 12:54 |
| frobware | dimitern: if it was blessed I'm more inclined to say go with it. but it's not. | 12:56 |
| dimitern | frobware, I'll propose it, but we don't have to merge right away.. | 12:57 |
| beisner | hi all - ? re: availability zones. if we have maas machines set in different zones, should that zone be observable to juju via JUJU_AVAILABILITY_ZONE? | 13:05 |
| frobware | dimitern: do you time to HO/sync? Can show you lxd stuff, some question re: mac addr and 'inet manual' | 13:07 |
| dimitern | frobware, sure, just give me 10m | 13:08 |
| frobware | ok | 13:08 |
| frobware | dimitern: let's make it 30 past the hour. I'll grab a very quick lunch. | 13:09 |
| dimitern | frobware, sgtm | 13:09 |
| perrito666 | pseudo morning all | 13:10 |
| dimitern | odd .. I couldn't open google calender for a long time.. | 13:32 |
| frobware | dimitern: sounds like a productivity win | 13:32 |
| dimitern | :D | 13:32 |
| dimitern | frobware, I'm in today's standup HO | 13:33 |
| frobware | omw | 13:33 |
| mup | Bug #1559099 opened: JUJU_AVAILABILITY_ZONE not set in MAAS <juju-core:New> <https://launchpad.net/bugs/1559099> | 13:47 |
| perrito666 | cherylj: are you around? | 13:51 |
| cherylj | perrito666: yeah, what's up? | 13:51 |
| perrito666 | cherylj: silly question, actually two, 1) is master blocked on the restore bug and 2) where is the release note doc? I need to add a few bits | 13:52 |
| cherylj | perrito666: 1 - Yes, but I committed the fix last night. Don't think that there's been a run on master since then. Let me think about unblocking... | 13:53 |
| cherylj | perrito666: 2 - https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit | 13:53 |
| perrito666 | cherylj: tx x 2 | 13:54 |
| cherylj | np :) | 13:56 |
| cherylj | perrito666: did the keystone 3 support land? (I think I saw that it did?) | 14:08 |
| perrito666 | I didnt, lemme see if Ian land it | 14:08 |
| perrito666 | ah yes, it got jfdone | 14:08 |
| perrito666 | :p | 14:08 |
| cherylj | k, will update the blueprint | 14:09 |
| perrito666 | ill update the release notes for all that landed these days | 14:09 |
| cherylj | perrito666: awesome! | 14:09 |
| mup | Bug #1559131 opened: unable to add-credential for maas <conjure> <juju-core:New> <https://launchpad.net/bugs/1559131> | 14:18 |
| katco | ericsnow: natefinch: good morning... final day! | 14:22 |
| katco | natefinch: i see you got your PRs landed... grats! can you follow up with marcoceppi to see when they'll hit the deb? | 14:22 |
| marcoceppi | katco natefinch I'm planning on building those today in about 3 hours | 14:23 |
| katco | marcoceppi: rock! | 14:23 |
| natefinch | awesome | 14:23 |
| katco | marcoceppi: note that most of the commands will currently return errors b/c the charmstore endpoints don't actually do anything yet | 14:23 |
| marcoceppi | katco: yeah, I'm going to coordinate with uros | 14:24 |
| marcoceppi | katco: hopefully the store will be deployed today :\ | 14:24 |
| katco | marcoceppi: no, i mean even after uros deploys they still do nothing. the code hasn't been written | 14:24 |
| marcoceppi | katco: \o/ cool good to know I'll make sure when I announce that there is still backend code being worked on | 14:24 |
| katco | marcoceppi: we are wrapping up some bug fixes in core, and then will be swinging onto implementing the charmstore stuff | 14:25 |
| marcoceppi | katco: is it just anything with --resources ? | 14:25 |
| katco | marcoceppi: yeah i think that's a fair representation | 14:25 |
| marcoceppi | katco: awesome, thanks for the ehads up | 14:25 |
| cherylj | hey katco, I've updated the release table on the feature tracker page to address some of your feedback. Can you take a look and let me know if it's a bit clearer now? https://private-fileshare.canonical.com/~cherylj/juju-features-20.html | 14:25 |
| katco | marcoceppi: anything here prepended by "charmer" https://github.com/CanonicalLtd/juju-specs/tree/master/resources/features | 14:25 |
| katco | cherylj: wow, i didn't even think to ask! ty that's great! | 14:26 |
| katco | cherylj: very clear | 14:26 |
| mup | Bug #1559131 changed: unable to add-credential for maas <conjure> <juju-core:New> <https://launchpad.net/bugs/1559131> | 14:27 |
| cherylj | excellent, thank you katco | 14:27 |
| katco | cherylj: no, really, ty | 14:27 |
| perrito666 | are we actually writing markdown on a google doc? | 14:31 |
| katco | perrito666: # katco's answer | 14:32 |
| katco | perrito666: * Yes of course we are. | 14:32 |
| katco | perrito666: * Why wouldn't we be? | 14:32 |
| katco | perrito666: * It's md! Everyone knows markdown! | 14:32 |
| katco | perrito666: * bullet point 4 | 14:33 |
| perrito666 | its a google doc, it supports 20th century formatting, but besides that is less than ideal as a medium for md | 14:33 |
| katco | perrito666: i know, i'm joking ;) i would think our release notes would be checked into our repo actually | 14:34 |
| perrito666 | well apparently there is more people that knows md than git :p | 14:34 |
| mup | Bug #1559131 opened: unable to add-credential for maas <conjure> <juju-core:New> <https://launchpad.net/bugs/1559131> | 14:36 |
| TheMue | md is a _nice_ simple format | 14:43 |
| natefinch | perrito666: putting the release notes in git as MD would be amazing... PRs to add new sections, PRs for edits, you could actually see who added each piece etc | 14:43 |
| TheMue | natefinch: +1 | 14:43 |
| natefinch | perrito666: I thnnk it's in docs for collaborative editing purposes and low barrier of entry | 14:43 |
| natefinch | perrito666: however, one would assume that people at a software company who use git all day would not be averse to using it a tiny bit more. | 14:43 |
| natefinch | also... being able to preview your markdown to know it's doing what you expect would be nice. | 14:44 |
| perrito666 | nothing says low barrier like a nice google doc full of markdown... | 14:44 |
| natefinch | lol | 14:44 |
| katco | natefinch: hey, don't think i even need to ask, but: you'll have your current card wrapped up today? | 14:45 |
| TheMue | google doc containing html as plain text with a pre section of markdown | 14:45 |
| natefinch | katco: should be, year. It's touching more spots than I originally expected... there's a lot of layers of abstraction to add arguments to, but it's still pretty trivial | 14:46 |
| natefinch | s/year/yeah | 14:47 |
| katco | natefinch: cool... please also coordinate with marcoceppi to let him know eta for next build of charm deb | 14:47 |
| katco | natefinch: i'sok... i read it in a pirate voice as "yar!" | 14:48 |
| natefinch | katco: haha | 14:48 |
| katco | natefinch: but seriously, work closely with marcoceppi on eta/progress, cool? | 14:50 |
| natefinch | katco: yes | 14:50 |
| * marcoceppi elmira hugs natefinch | 14:50 | |
| natefinch | katco: I think I misunderstood the card... I thought I was adding channels to juju charm list-resources | 14:51 |
| natefinch | katco: there isn't a charm list-resources command AFAIK | 14:51 |
| katco | natefinch: gahhh you are correct and i am friday head | 14:52 |
| natefinch | katco: oh good, I thought I was doing the wrong thing | 14:52 |
| katco | natefinch: the card is incorrect... i'll put a juju out in front | 14:52 |
| natefinch | katco: sounds good | 14:52 |
| katco | natefinch: so the charm work you did already included channel support? | 14:52 |
| natefinch | katco: yes, the UI team did the channel work there | 14:53 |
| natefinch | katco: we just tacked resources on top of that | 14:53 |
| katco | natefinch: ok | 14:53 |
| katco | marcoceppi: really i just like pinging you. false alarm, we are truly done with the charm command now. | 14:54 |
| marcoceppi | katco: I like feeling like I'm needed | 14:54 |
| katco | :) | 14:54 |
| natefinch | marcoceppi: and I like hugs :) | 14:54 |
| katco | marcoceppi: also i had to look up elmira... wow there's some neurons that hadn't fired in like 15 years | 14:55 |
| marcoceppi | katco: haha, yeah it's been a while but she def left an impression on me when I was younger | 14:55 |
| natefinch | marcoceppi: aww, I misread it as elvira hug | 14:56 |
| * katco spits out coffee | 14:56 | |
| marcoceppi | natefinch: haha | 14:56 |
| katco | that would be quite different | 14:56 |
| natefinch | indeed :) | 14:56 |
| marcoceppi | elmyra* is apparently the spelling you should be searching with | 14:56 |
| katco | marcoceppi: on a complete tangent: the shirts from the charmer's summit are great. material is very soft and design is awesome | 14:57 |
| marcoceppi | katco: thanks, we decided to them in house. we want people to actually like wearing them ;) | 14:57 |
| katco | hehe | 14:57 |
| katco | if i could get a zip-up juju hoodie i would be so happy | 14:58 |
| natefinch | ditto | 14:58 |
| marcoceppi | which means getting nice fabric | 14:58 |
| katco | i think wwitzel3 made his own | 14:58 |
| marcoceppi | that's good to know, we'll keep that in mind for pasadena | 14:58 |
| ericsnow | katco, natefinch: PTAL http://reviews.vapour.ws/r/4219/ | 15:00 |
| katco | ericsnow: reviewing right now actually! | 15:00 |
| ericsnow | :) | 15:00 |
| natefinch | ericsnow: looking | 15:00 |
| ericsnow | ta | 15:00 |
| katco | ericsnow: natefinch: actually, since we're down to the wire here... just this once, can i ask that natefinch focus on getting his code written? | 15:01 |
| katco | ericsnow: natefinch: i'd like to be able to merge master in by EOD | 15:01 |
| ericsnow | katco: np | 15:01 |
| natefinch | ok | 15:02 |
| katco | natefinch: ta | 15:02 |
| wwitzel3 | katco, marcoceppi: yeah, I took the hoodie to a alterations shop and they put a zipper on it for me | 15:16 |
| wwitzel3 | cost me $11 + the zipper (amazon for $4 iirc) | 15:16 |
| natefinch | my wife said she'd do that for me, but I haven't gotten around to actually asking her to do it | 15:16 |
| wwitzel3 | mine sat in a closet unused until I put a zipper on it | 15:17 |
| wwitzel3 | what kind of uncivilized person uses a pull over | 15:17 |
| natefinch | wwitzel3: lol, right? | 15:18 |
| katco | well put wwitzel3 | 15:18 |
| TheMue | natefinch: your wife can do any sewing job for you. always watching her posts, she's so good. | 15:18 |
| natefinch | TheMue: Thank you :) She's pretty great, yeah :) | 15:19 |
| TheMue | natefinch: absolutely | 15:20 |
| fwereade | katco, do you know why resources/resourceadapters.WorkerFactory is creating a worker from a *State? | 15:36 |
| fwereade | katco, (hi, by the way, sorry abrupt!) | 15:37 |
| katco | fwereade: let me take a peek. ericsnow might have a quicker answer | 15:37 |
| katco | fwereade: np at all lol, hi! :D | 15:37 |
| ericsnow | fwereade: I'll take a look :( | 15:37 |
| ericsnow | fwereade: gah, I'll fix that | 15:39 |
| katco | fwereade: well there ya go. | 15:39 |
| fwereade | katco, ericsnow, before you get too deep into that, I hit this because I'm doing pretty drastic things to the machine agent, and I'm not entirely sure how I should go about integrating that functionality | 15:40 |
| katco | fwereade: ericsnow: is the problem that it's taking in a State pointer? | 15:41 |
| katco | fwereade: ericsnow: and not an interface? | 15:41 |
| fwereade | katco, that's several problems | 15:41 |
| fwereade | katco, an interface would be nicer | 15:41 |
| fwereade | katco, the upsetting thing is that it's a worker that's not going via the api layer | 15:41 |
| ericsnow | fwereade: right, the API part is what I need to fix | 15:42 |
| * ericsnow feels dumb for forgetting that mandate | 15:42 | |
| fwereade | ericsnow, would you take a look at the MADE-model-workers branch please? | 15:42 |
| ericsnow | fwereade: will do now-ish | 15:43 |
| fwereade | ericsnow, in particular, cmd/jujud/agent.MachineAgent.startModelWorkers; and the cmd/jujud/agent/model package | 15:43 |
| ericsnow | fwereade: and sorry for not getting you that review yesterday (model agent integration) | 15:44 |
| ericsnow | fwereade: I was actually just reading through it | 15:44 |
| fwereade | ericsnow, because I am reluctant to make the tests for those packages dependent upon what other packages might have been imported, and it feels like the approaches are at an impasse | 15:45 |
| fwereade | ericsnow, no worries, I am keen to hear your thoughts on it but you weren't blocking me | 15:45 |
| ericsnow | fwereade: k | 15:45 |
| katco | fwereade: is this the whole "imports have a side-effect" conversation? | 15:45 |
| katco | fwereade: via init | 15:46 |
| fwereade | katco, yeah | 15:46 |
| katco | fwereade: to my knowledge we are not doing that, if that helps. | 15:46 |
| fwereade | katco, well, then it's the "logic dependent upon mutable global state" one | 15:47 |
| katco | fwereade: ah, that we are currently doing :) | 15:47 |
| katco | fwereade: although i'd characterize it as "package level state" | 15:47 |
| fwereade | katco, IMO that makes it marginally more tractable, but little less evil | 15:48 |
| katco | fwereade: but i don't understand how the registration pattern makes writing tests harder? or what that has to do with imports? | 15:49 |
| ericsnow | fwereade: oh, you better take a look at our feature branch https://github.com/juju/juju/blob/feature-resources/resource/resourceadapters/workers.go | 15:49 |
| ericsnow | fwereade: I've since merged that worker (in master) with the charmrevisionupdater worker | 15:49 |
| ericsnow | fwereade: (Ian's idea) | 15:50 |
| fwereade | katco, well, I have this Manifolds() func, which returns a representation of the workers we need to run per-model in a controller; I would like to be able to test it, and have confidence that it will do the same thing whatever else may or may not have been called or imported | 15:50 |
| ericsnow | fwereade: the integration between the two takes place in the API server so no workers are involved | 15:50 |
| ericsnow | fwereade: and yeah, I really don't like the registries and would love to talk with you about what I think is the sensible atlernative | 15:51 |
| fwereade | ericsnow, well... that worker is sitting right there on master afaics? https://github.com/juju/juju/blob/master/resource/resourceadapters/workers.go | 15:51 |
| katco | fwereade: sorry for the 2 convos at once. but can't you? your tests have the global view of manifolds in the context of your tests. it should be testing that it does the right thing when you register workers | 15:52 |
| ericsnow | fwereade: right, we haven't merged that part of our feature branch back into master yet | 15:52 |
| katco | ericsnow: actually i am confused as well... the worker is present in the feature branch. you're saying we merged that, but haven't yet deleted it? | 15:53 |
| fwereade | ericsnow, katco: so, parenthetically, it is really not a good thing that that code ever landed on a feature branch, let alone made it into master :( | 15:53 |
| fwereade | ericsnow, katco: but I am much more interested in talking about the tests | 15:53 |
| ericsnow | katco: ??? https://github.com/juju/juju/blob/feature-resources/resource/resourceadapters/workers.go | 15:53 |
| katco | ericsnow: i am missing something. i'm looking at the same worker which takes in state | 15:54 |
| fwereade | katco, if I need to pay attention to ensuring that the context of my tests matches the context at runtime, I will almost certainly screw it up at some point | 15:54 |
| ericsnow | katco: there's no worker there; compare with master: https://github.com/juju/juju/blob/master/resource/resourceadapters/workers.go | 15:55 |
| fwereade | katco, if I write my SUT such that all its dependencies are supplied explicitly, I can have much greater confidence that the tests will remain useful in the long term | 15:55 |
| katco | ericsnow: is this not instantiating a worker? https://github.com/juju/juju/blob/feature-resources/resource/resourceadapters/workers.go#L21 | 15:55 |
| katco | fwereade: you don't have to make sure it aligns with the context of runtime, just that the path is tested | 15:56 |
| ericsnow | katco: correct | 15:56 |
| katco | ericsnow: so, in our feature branch, we have a function that takes in state, and returns a worker looking at state? | 15:56 |
| ericsnow | katco: it returns a "latest charm handler", not a worker | 15:57 |
| katco | fwereade: i.e. register a "foo" worker, does Manifolds() return it? PASS: we successfully know about registered workers | 15:57 |
| fwereade | katco, ericsnow: how can you possibly write such a registration func without magical dependencies across all the components in play? | 15:58 |
| katco | fwereade: well wait, let's resolve the testing line of questioning | 15:59 |
| fwereade | katco, ericsnow: I don't think you can usefully register a manifold without secret knowledge of the names of the workers defined in agent/model | 15:59 |
| fwereade | katco, ok | 15:59 |
| katco | ericsnow: that is perhaps misleading then. it sits in a "workers" package | 15:59 |
| ericsnow | katco: agreed | 16:00 |
| ericsnow | katco: it's left over from when it was a worker | 16:00 |
| cmars | fwereade, is it possible for a relation hook to fire before both services are installed? even if one of those services is a subordinate? | 16:00 |
| fwereade | katco, ericsnow: (either way, the only things that should be using a *State should live in the apiserver) | 16:00 |
| katco | ericsnow: ahhh ok this makes sense | 16:00 |
| ericsnow | fwereade: agreed | 16:00 |
| fwereade | cmars, it should not be | 16:00 |
| fwereade | katco, ok, back to the tests | 16:00 |
| cmars | fwereade, thought so. might be an old juju, i'll find out | 16:00 |
| cmars | thanks | 16:00 |
| * katco listens | 16:00 | |
| fwereade | katco, I am not interested in testing a registration mechanism: I am interested in testing what workers will be started by a model agent | 16:01 |
| fwereade | katco, the mutable global state makes that unknowable | 16:01 |
| katco | fwereade: ah, i see your plight now | 16:01 |
| frobware | dimitern: meeting | 16:02 |
| frobware | voidspace: ^^ | 16:02 |
| katco | fwereade: if we were aligned, this would be a test that would live somewhere in component/... because that's where the list of workers would get passed in | 16:02 |
| katco | fwereade: coding the list in the dependency engine is like hard-coding the state i think | 16:03 |
| fwereade | katco, I am not sure that testing that behaviour in component/ is notably better that testing it under agent/model/ | 16:04 |
| fwereade | katco, a model agent has a number of responsibilities, and those responsibilities have non-trivial interactions | 16:05 |
| katco | fwereade: well, i think it's because in the manifold, you test that the registration works. then where the registration happens, you test that your list is complete | 16:06 |
| fwereade | katco, restate please? | 16:07 |
| katco | fwereade: sure, let me try and think of a different way | 16:08 |
| katco | fwereade: so, starting from these axioms: | 16:08 |
| ericsnow | katco, fwereade: I think that testing it where we are is correct; but we should be testing which manifolds will be run (not which workers) | 16:08 |
| katco | fwereade: 1. unit tests should test 1 thing at a time | 16:08 |
| katco | fwereade: 2. the combination of all unit tests trends towards correctness | 16:09 |
| katco | fwereade: if your goal is to test that the workers we expect to run, are | 16:10 |
| fwereade | katco, (1) concur (2) strongly disagree, quantity of tests does not imply quality of tests | 16:10 |
| katco | fwereade: that's not the point of 2... another way is to say: the more correctly written unit tests you have, the greater confidence you have the system as a whole works | 16:10 |
| katco | fwereade: in other words it's not about the correctness of the test, it's about the combination of correct tests stating something about the system as a whole | 16:11 |
| fwereade | katco, and now we tangle on "correctly written", I fear | 16:11 |
| katco | fwereade: no, i don't think so. it doesn't matter. for any value of correct. | 16:11 |
| katco | fwereade: if it correctly tests the 1 thing the test is supposed to test | 16:12 |
| fwereade | katco, still unconvinced, I think some tests have negative value | 16:12 |
| katco | fwereade: agreed, in overhead. not in emergent correctness of the system | 16:13 |
| fwereade | katco, on the contrary | 16:13 |
| fwereade | katco, a little while ago I found tests for the machine agent that checked it called some api method on some facade | 16:13 |
| fwereade | katco, which (1) it shouldn't have done in the first place | 16:13 |
| voidspace | frobware: oops, sorry | 16:14 |
| fwereade | katco, and (2) it actually didn't anyway, because someone had tweaked the test setup to make that call at the right time, so the test merely tested that the test setup had run | 16:14 |
| katco | fwereade: ok, so that's fails both clauses right? it did not correctly test the thing it was supposed to test, and it wasn't supposed to test it | 16:15 |
| katco | fwereade: strawman | 16:15 |
| voidspace | mgz: ping | 16:16 |
| mgz | voidspace: yo | 16:16 |
| voidspace | mgz: the drop-maas-1.8 CI run failed on build binary, which meant everything failed | 16:17 |
| katco | fwereade: if your goal is to test that the workers we expect to run, are. first thing you should do is test that when workers are registered, the manifold knows about them | 16:17 |
| katco | fwereade: the second thing is that you register the right workers | 16:17 |
| voidspace | mgz: the logs are extremely terse - it just says that lxc-start failed | 16:17 |
| mgz | voidspace: that's fixed | 16:17 |
| voidspace | mgz: so it was a problem with CI, not with the branch? | 16:17 |
| mgz | lxc update broke wily | 16:18 |
| katco | fwereade: through emergence, you have now tested that the workers we expect to run, are | 16:18 |
| fwereade | katco, you seem to be arguing from a position that assumes that we should depend on mutable global state in the first place | 16:18 |
| voidspace | mgz: ah, damn | 16:18 |
| mgz | sinzui had to roll back the package | 16:18 |
| mgz | but the testing is happening for realy | 16:18 |
| katco | fwereade: yes, i prepended all of this by saing "if we were aligned" | 16:18 |
| voidspace | mgz: so we'll get a run in due course | 16:18 |
| voidspace | mgz: thanks | 16:18 |
| voidspace | frobware: ^^^ | 16:19 |
| fwereade | katco, ok, I did not think that "globals are bad mmmkay" was a controversial position | 16:19 |
| katco | fwereade: channeling mr. mackey there :) | 16:19 |
| fwereade | katco, absolutely :) | 16:19 |
| katco | fwereade: but we could just pass the list in... doesn't have to be global | 16:20 |
| fwereade | katco, right, and if we did, that would certainly be more testable and less upsetting | 16:21 |
| frobware | dimitern: so with your patch, some fiddling with the lxd code and adding an 'ifup -a' as a new run command in cloud-init the lxd containers' interfaces are all up! | 16:21 |
| ericsnow | fwereade: note that in our feature branch that worker registry is gone | 16:21 |
| katco | fwereade: under the tests i have laid out, it would be no easier to test. but yes, less upsetting | 16:21 |
| fwereade | katco, but we're still talking about a set of interdependent components | 16:22 |
| frobware | dimitern: first container without `ifup -a', second with. http://pastebin.ubuntu.com/15415766/ | 16:22 |
| fwereade | katco, the agent/model package is about defining the dependencies and interactions between them | 16:23 |
| fwereade | katco, and many parts of that are internal details | 16:23 |
| fwereade | katco, the api caller might be called "api-caller", but if you depend on that from half a docebase away Bad Things will happen | 16:24 |
| katco | fwereade: and we arrive at the real point of contention: IoC vs. not | 16:24 |
| dimitern | frobware, awesomesauce! | 16:24 |
| katco | and as if to signal something, my cat just puked at my feet | 16:25 |
| katco | brb | 16:25 |
| ericsnow | fwereade: ideally I'd like to eliminate all the global registries (and component/all) and accomplish the same thing in the correct places (under cmd/juju, cmd/jujud, etc.) | 16:25 |
| frobware | dimitern: we should sync with stefan (and raise some bugs to track) for some of the timing issues and for the cases where the interfaces don't come up. | 16:25 |
| fwereade | katco, I think I am in favour of IoC... do I seem not to be? | 16:25 |
| fwereade | brb also, talk when you're back | 16:26 |
| dimitern | frobware, yeah | 16:26 |
| ericsnow | fwereade: the challenge is refactoring code so that we pass the necessary "registries" around | 16:26 |
| fwereade | ericsnow, this is absolutely true | 16:29 |
| === natefinch is now known as natefinch-lunch | ||
| fwereade | ericsnow, and I think it's more or less what I've been working towards with all the dependency.Engine work | 16:30 |
| ericsnow | fwereade: exactly | 16:30 |
| ericsnow | fwereade: that's what helped the concept click for me :) | 16:30 |
| fwereade | ericsnow, cool :D | 16:31 |
| cmars | katco, is it possible to select a lxd profile when deploying, by using constraints=... ? | 16:37 |
| katco | cmars: i don't believe so. jam and tych0 have been doing the latest work on this though | 16:38 |
| ericsnow | cmars: not likely (unless jam or tych0 have added that) | 16:38 |
| cmars | katco, ericsnow ok thanks | 16:38 |
| tych0 | not that i know of :( | 16:39 |
| cmars | would such a thing fit into constraints? dang it'd be useful to be able to do that -- adding bind mounts stuff, or making containers privileged | 16:40 |
| cmars | i'd consider hacking away on this... i know y'all are busy | 16:40 |
| fwereade | cmars, that feels like a placement directive? can be passed through to the provider | 16:40 |
| katco | cmars: you can still kind of get this behavior by changing what image ubuntu-<series> points to | 16:41 |
| dimitern | frobware, | 16:41 |
| dimitern | frobware, sorry wrong window :) | 16:41 |
| fwereade | cmars: provider/ec2/environ.go:370 for an example | 16:41 |
| cmars | haven't seen the placement stuff yet, yeah, that makes sense | 16:42 |
| fwereade | cmars, constraints want to be generic, placement is for provider-specific trapdoors | 16:42 |
| fwereade | cmars, generally accessed via --to | 16:43 |
| fwereade | katco, so, IoC? | 16:43 |
| cmars | fwereade, that'd put all the provisioned machines in the same profile.. which would work, but what I really want is to deploy one service into a privileged container while leaving the others unprivileged | 16:44 |
| katco | fwereade: oh, right... sorry | 16:44 |
| fwereade | cmars, deploy myservice --to lxd:profile=myfancyprofile? | 16:44 |
| fwereade | katco, np | 16:44 |
| cmars | oh, works on deploy as well as bootstrap. ok, nice! | 16:45 |
| fwereade | katco, I *think* we're both in favour of ioc? | 16:45 |
| katco | fwereade: no you don't seem to be against IoC. but hard coding things does not seem to be IoC. maybe i've missed the point being that you pass around manifolds? | 16:45 |
| fwereade | katco, the way I see it, a Manifolds func is explicitly responsible for accepting some sort of config that applies to the responsibility it holds, and returning some set of workers that will meet those responsibilities | 16:47 |
| fwereade | katco, if the set of workers were independent, I would agree that a dynamic registry would probably be ok | 16:48 |
| katco | fwereade: so the crux of your argument is that there is a central spot to codify that dependency graph, and you can't test that if outsiders can register things | 16:49 |
| fwereade | katco, basically, yes | 16:49 |
| fwereade | katco, and it makes me sad that code changes many packages away could, e.g. induce a cycle and render the whole lot useless | 16:50 |
| katco | fwereade: tbh i would have to read through the code again to comment on that point | 16:52 |
| fwereade | katco, I think it's a broadly applicable argument? I want local changes to cause local test failures, and the bigger/more-integrationy the test the more distance-risk I take on in exchange for greater certainty about macro behaviour | 16:54 |
| fwereade | ...er, if that makes any sense at all outside my own head | 16:54 |
| dimitern | frobware, I solved the case of the missing mac address | 16:54 |
| frobware | great | 16:54 |
| ericsnow | fwereade: FWIW, I agree that "configuration" of the application, which is how I see this, is ideally all in one place | 16:55 |
| ericsnow | fwereade: which is what I think you are arguing for | 16:55 |
| dimitern | frobware, it turned out much to my surprise that `x := y` is not the same as `x := make([]T, len(y)); copy(x,y)` | 16:55 |
| fwereade | katco, at a high level, yess -- I think the problem I am solving with dependency.Engine is "nobody understands what workers are running at any given time" | 16:55 |
| fwereade | katco, I have been working towards making that more explicit | 16:56 |
| katco | fwereade: yeah i agree with that | 16:57 |
| fwereade | katco, so, from that perspective, you can see why I'm having trouble with components | 16:58 |
| katco | fwereade: oh yes, certainly! i think i'm arguing from some kind of ideal future state that doesn't actually exist yet | 16:59 |
| katco | fwereade: i don't feel the problem is intractable | 17:00 |
| fwereade | katco, would you consider it a slur if I accused the component approach of being reminiscent of aspect-oriented programming? | 17:00 |
| katco | fwereade: but i acknowledge and respect that you are much closer to the problem than i am, so might have a more valid opinion :) | 17:00 |
| katco | fwereade: no not a slur... i don't understand the comparison though | 17:01 |
| fwereade | katco, because it feels to me like it has similar strengths (clear separation of unrelated concerns) and weaknesses (pain when those concerns turn out to intersect in subtle ways) | 17:01 |
| fwereade | katco, just a thought, may be nonsense, probably not a useful comparison if it doesn't immediately speak to you | 17:02 |
| katco | fwereade: mm... i think it's different in that we're trying to advocate codifying those interactions instead of letting them happen naturally | 17:02 |
| katco | fwereade: i.e. if i decorate a method with a bunch of attributes, i may not know how it will act, but if i write a function that says X interact with Y, i can write a test against that | 17:03 |
| katco | fwereade: i suppose i can write a test for how attributes are combined as well | 17:04 |
| katco | fwereade: hey, i love talking about this stuff (and it's important to continue doing so) but i have stuff i need to take care of for the release | 17:05 |
| frobware | dimitern: so it was lost in the pointer copy from before? just impl/patch didn't actually fix it? | 17:05 |
| fwereade | katco, likewise -- and I'm approaching EoD -- but I do need to figure out how to weld these two parts together if I want to merge MADE-model-workers | 17:05 |
| katco | fwereade: when do you need that merged? | 17:06 |
| fwereade | katco, heh, now it's done, as soon as I can, but I know there's no shortage of competition | 17:06 |
| dimitern | frobware, I'm not sure what was wrong with the patch, but using make + copy vs := worked | 17:07 |
| katco | fwereade: so you're aiming to get it in for 2.0? | 17:07 |
| fwereade | katco, last I saw it was on the list | 17:07 |
| voidspace | frobware: when will you have confirmation of the induction sprint dates? | 17:07 |
| katco | fwereade: well if it's just 1 test left, you could land the branch as is and fix the test before the ~8th | 17:08 |
| frobware | voidspace: alexis raised the req for april 18->22 - I haven't seen or heard anything to suggest that it will not be those dates | 17:08 |
| voidspace | frobware: ok, cool - thanks | 17:09 |
| fwereade | katco, well, it's more than that -- it's that it's a replacement of the per-model workers | 17:09 |
| frobware | voidspace: it's mine and dooferlad's birthday that week, so it's a rave! | 17:09 |
| katco | fwereade: oh, so functionality is blocked as well? | 17:10 |
| fwereade | katco, and, well, there's this *State-dependent thing that's just turned up and is partly there because the magic registration mechanism let the implementer avoid seeing the WTF DO NOT DO THIS comment in startEnvWorkers | 17:10 |
| fwereade | katco, yes, my branch will not currently run that worker | 17:10 |
| frobware | ericsnow, katco: would love some feedback on this if you have bandwidth: https://github.com/juju/juju/pull/4789/commits/417c8fd67b40eac734a815707104bfc3c8657af5 | 17:11 |
| frobware | ericsnow, katco: I haven't looked at the lxdclient before, but was trying to make multi-nic containers work with maas/spaces | 17:11 |
| voidspace | frobware: hehe, cool | 17:11 |
| fwereade | katco, and I would like it to, but adding package-level component registration to agent/model is very much at odds with the purpose of the package | 17:11 |
| katco | fwereade: ok, well then we need to discuss syncing up this weekend to meet monday's deadline | 17:12 |
| ericsnow | fwereade: don't forget that once feature-resources is merged back in, the whole model-worker-registry thing is gone | 17:12 |
| katco | frobware: will try and tal in a bit | 17:12 |
| fwereade | ericsnow, so it's just charmrevisionupdater doing both jobs, and using the api and everything? that seems sane | 17:13 |
| ericsnow | fwereade: right | 17:13 |
| frobware | katco: appreciated | 17:13 |
| fwereade | ericsnow, ok, then that is great | 17:13 |
| ericsnow | fwereade: it was Ian's idea :) | 17:13 |
| katco | fwereade: unblocked? | 17:13 |
| fwereade | ericsnow, yeah, they're pretty much the same job | 17:13 |
| voidspace | frobware: we could make it literally a rave... http://www.fabriclondon.com/club/listing/1238 | 17:13 |
| fwereade | katco, not sure | 17:13 |
| voidspace | dimitern: http://www.fabriclondon.com/club/listing/1238 | 17:13 |
| ericsnow | fwereade: yep :) | 17:14 |
| fwereade | katco, don't think I can merge without a functioning worker in the short term | 17:14 |
| frobware | katco: we may land that on maas-spaces-multi-nic-containers anyway to drive through any integration issues. | 17:14 |
| ericsnow | fwereade: it may be worth cherry-picking the particular merge commit from the feature-resources branch? | 17:14 |
| katco | frobware: seems reasonable, but appreciate the heads-up. in that same light, heads up tych0 and jam ^^^ | 17:15 |
| dimitern | voidspace, that's a great idea actually | 17:15 |
| voidspace | dimitern: :-) | 17:15 |
| fwereade | ericsnow, it very probably would, I will have a look for that | 17:16 |
| dimitern | voidspace, haven't been to a party like that in london, so count me in :) | 17:16 |
| fwereade | ericsnow, katco: so, yes, unblocked, thank you :). | 17:16 |
| fwereade | ericsnow, katco: but I think this is a near-miss and we'll have worse interactions before too long, so let's talk more about this right after the release madness | 17:17 |
| ericsnow | fwereade: I believe it is 8758089b35c3120b52b10da6d93514ac0d992f6f (PR #4539) | 17:17 |
| katco | fwereade: yes, totally agree! | 17:17 |
| ericsnow | fwereade: +1 | 17:18 |
| katco | fwereade: we will be doing a retro on the component oriented approach at our next sprint | 17:18 |
| fwereade | ericsnow, katco: cool | 17:18 |
| katco | fwereade: and i'm hoping we can get everyone to close their laptops and participate :) | 17:18 |
| fwereade | katco, whole-team sprint? excellent, +1 | 17:18 |
| katco | fwereade: a juju core sprint | 17:18 |
| === natefinch-lunch is now known as natefinch | ||
| natefinch | arg... I really really really wish that channel was part of a charm.Url | 17:39 |
| ericsnow | natefinch: +1 | 17:39 |
| natefinch | so... uh... do we store the channel of a charm that a service is using? | 17:41 |
| ericsnow | natefinch: I doubt it | 17:42 |
| natefinch | ericsnow: so, how do we know what channel to look in for updates? | 17:43 |
| ericsnow | natefinch: though I expect we should have it for the charmrevisionupdater worker | 17:43 |
| ericsnow | natefinch: yep | 17:43 |
| natefinch | ericsnow: that's what I'm looking at right now | 17:43 |
| natefinch | ericsnow: since LatestCharmInfo now requires a channel | 17:43 |
| natefinch | fwereade, rick_h__: either of you know if juju-core respects channels at all, and if so, how? Seems like we need to remember the channel from which we deployed a service... but I don't see us actually storing that anywhere | 17:47 |
| katco | natefinch: ericsnow: i would have expected that to be part of the work of landing --channel into the deploy command | 17:49 |
| ericsnow | katco: +1 | 17:49 |
| natefinch | katco: there's no mention of channel in deploy.go: https://github.com/juju/juju/blob/master/cmd/juju/service/deploy.go | 17:49 |
| katco | natefinch: ericsnow: when we discussed yesterday, it sounded like the patch hadn't been landed yet | 17:50 |
| natefinch | katco: I guess I'll just hardcode stable and we can fix it when that other stuff lands | 17:51 |
| ericsnow | katco: correct, still not in master | 17:52 |
| ericsnow | natefinch: that's consistent | 17:52 |
| rick_h__ | natefinch: no, it's on the list but it's not been done yet. | 17:54 |
| rick_h__ | natefinch: agree with the assertion that we need to remember what channel the services is following | 17:54 |
| frobware | voidspace: latest drop-1.8 looks better. | 17:54 |
| katco | rick_h__: sounds like rogpeppe2 is doing it. can we expect his patch to store that somewhere and update the existing resources code to take advantage of it? | 17:54 |
| voidspace | frobware: ah, cool | 17:55 |
| rick_h__ | katco: I'd hope so yes. However, I've not seen the code/etc to be 100% on it. | 17:55 |
| frobware | voidspace: all have existing bugs registered against the failure and one was a timeout | 17:55 |
| voidspace | frobware: there's a xenial uniit test failure based on ordering | 17:56 |
| voidspace | frobware: I bet that's a dictionary iteration order change | 17:56 |
| voidspace | ah, existing bug | 17:57 |
| voidspace | frobware: yeah, that's much better | 17:57 |
| voidspace | frobware: when is the plan to land this? | 17:57 |
| natefinch | rick_h__: do you know why we didn't just add a channel field to the charm.Url struct? it's hugely disruptive to the codebase to change basically everywhere we take a charm.Url to now take a charm.Url + channel | 18:01 |
| rick_h__ | natefinch: I'm guessing because a charm can have more than one? e.g. a single charm revision can be development, then made stable, etc | 18:01 |
| rick_h__ | natefinch: but I'm only guessing, I'm not in the implementation calls right now and EU folks would know better than I | 18:01 |
| natefinch | rick_h__: ok, no problem. Just wondered if you were there for the discussion. | 18:02 |
| katco | natefinch: there should be a channel flag on upgrade-charm too, correct? | 18:03 |
| rick_h__ | katco: natefinch yes, but only with --switch to be clear it's changing what it's tracking | 18:04 |
| natefinch | ^ that | 18:04 |
| katco | k | 18:04 |
| natefinch | in general the channel shouldn't change, and therefore only needed at deploy time | 18:05 |
| natefinch | (and even then I presume we'll default to stable, so usually people won't ever need to think about channels) | 18:05 |
| rick_h__ | natefinch: correct | 18:05 |
| rick_h__ | natefinch: channels are a pro-use only tool, hidden from normal users | 18:06 |
| mup | Bug #1559233 opened: juju run gets 'Permission denied (publickey)' in models other than the controller model <juju-core:New> <https://launchpad.net/bugs/1559233> | 18:06 |
| frobware | voidspace: whenever we can get a clean CI - death to long lived feature branches | 18:11 |
| dimitern | frobware, here it is: https://github.com/dimitern/juju/tree/multi-nic-master-fixes | 18:15 |
| frobware | dimitern: looking | 18:16 |
| voidspace | frobware: cool | 18:16 |
| frobware | dimitern: the bridge script tests fail in multi-nic-containers atm | 18:17 |
| dimitern | frobware, really? | 18:19 |
| frobware | dimitern: ok, going to push your branch as maas-spaces-multi-nic-containers-with-master. Viva la tab completion. | 18:19 |
| frobware | dimitern: was a bit surprised too | 18:19 |
| dimitern | frobware, great! thanks | 18:20 |
| frobware | dimitern: ah, no. sorry it was: FAIL: container_userdata_test.go:120: UserDataSuite.TestNewCloudInitConfigWithNetworks | 18:20 |
| dimitern | frobware, ah, yeah - that's fixed in the branch above | 18:20 |
| frobware | dimitern: bleh. too much going on. | 18:20 |
| dimitern | :) | 18:21 |
| frobware | dimitern: confirming tip of your branch is 65322f6d483ab0ea6e19fc466af9b60096f5174e | 18:23 |
| dimitern | frobware, just a sec | 18:23 |
| dimitern | frobware, I'm waiting for the final make check to pass first | 18:23 |
| dimitern | frobware, and it did find one issue - I'll fix it and push an update | 18:24 |
| dimitern | map ordering related, not in our code, but still - http://paste.ubuntu.com/15416689/ | 18:24 |
| natefinch | anyone recognize this: provider/dummy/environs.go:316: "github.com/juju/testing".MgoServer.Reset() used as value | 18:26 |
| frobware | dimitern: I've seen a bug for that | 18:27 |
| frobware | dimitern: tip is now 0cd8eb5b02a9430e31430b65acff595e7dfe0f71? | 18:28 |
| dimitern | frobware, and I have included, but perhaps the last cherry-pick reverted it? dunno | 18:28 |
| frobware | ? | 18:29 |
| dimitern | frobware, yep, I was just about to paste the commit | 18:29 |
| frobware | dimitern: what did you revert? | 18:29 |
| natefinch | nvm, looks like a dependencies problem... because of course it is | 18:29 |
| dimitern | frobware, I mean https://github.com/juju/juju/pull/4787 might have caused the test failure | 18:29 |
| dimitern | which I cherry-picked from master | 18:30 |
| frobware | right | 18:30 |
| frobware | ok, pushing now. | 18:30 |
| dimitern | +1 go for it | 18:30 |
| frobware | dimitern: see natefinch's comment about deps. didn't you see something there today? | 18:31 |
| dimitern | frobware, https://github.com/juju/juju/pull/4759 fixed the map ordering issue in 2 out of 3 providers that have it - i.e. ec2 still have it after that PR, and my last commit fixed ec2 as well | 18:32 |
| dimitern | no, I was having issues with dependencies.tsv after I tried to foolishly rebase after I did merge master | 18:33 |
| frobware | dimitern: * [new branch] maas-spaces-multi-nic-containers-with-master -> maas-spaces-multi-nic-containers-with-master | 18:34 |
| natefinch | I just had to update my dependencies.tsv to point to the head of juju/testing... not sure how I got the code change in core and not the deps change... might have been a simple merge problem | 18:34 |
| dimitern | merging dependencies.tsv starts to get so painful it needs tooling around it | 18:36 |
| dimitern | and I'm not just talking about godeps -N | 18:36 |
| dimitern | frobware, awesome! | 18:36 |
| frobware | dimitern: calling it a week, my lxd patch/branch is out there if you want to take a look, perhaps merge into one of our branches. :) | 18:37 |
| dimitern | frobware, I'll take care of it | 18:39 |
| dimitern | frobware, :) enjoy the holiday | 18:39 |
| frobware | dimitern: I'll sort out some stuff for Christian tomorrow morning, but I will be incognito thereafter. \o/ | 18:39 |
| dimitern | ok, beer o'clock | 18:41 |
| mgz | dimitern: hm, me too | 18:41 |
| dimitern | :) cheers mgz | 18:42 |
| fwereade | ericsnow, I'm confused about the various Connect methods around charmcmd, and what if anything should be using a *cmd.Context | 19:11 |
| fwereade | ericsnow, is that something that came after that commit? | 19:11 |
| natefinch | brb rebooting | 19:12 |
| ericsnow | fwereade: in cmd/juju/charmcmd/store.go? | 19:14 |
| fwereade | ericsnow, yeah, and extending into resource/ I think? | 19:14 |
| katco | fwereade: that was cmars team trying to stop needing to launch a browser to sign in i think | 19:15 |
| ericsnow | fwereade: that | 19:15 |
| cmars | ericsnow, missed some of the scrollback there, just came back from a reboot. *cmd.Context was needed in a few places for terminal interaction, to log in on the command line | 19:17 |
| ericsnow | fwereade: ^^^ | 19:17 |
| katco | natefinch: https://github.com/CanonicalLtd/juju-specs/blob/master/resources/features/charmer-query-charm-metadata.feature#L32-L41 | 19:18 |
| fwereade | ericsnow, katco, cmars, thanks, I'll see what needs to go where :) | 19:20 |
| katco | natefinch: i think we missed this. list-resources is both on the charm command and the juju charm command | 19:20 |
| natefinch | katco: damn | 19:20 |
| natefinch | katco: I mean, of course that makes sense | 19:21 |
| katco | natefinch: finish up the juju side of things and we'll talk | 19:21 |
| natefinch | katco: it's pretty easy to code up, at least | 19:21 |
| natefinch | katco: kk | 19:21 |
| katco | marcoceppi: i just can't stop pinging you | 19:22 |
| katco | marcoceppi: we messed up. we actually do have 1 more thing to land into the charm command | 19:23 |
| mgz | to the tune of "I can't stop loving you"? | 19:23 |
| natefinch | prtty sure that's a song | 19:23 |
| natefinch | lol | 19:23 |
| katco | lol | 19:23 |
| * natefinch hi-5's mgz | 19:23 | |
| katco | to the tune of the CSI theme? | 19:23 |
| natefinch | katco: https://www.youtube.com/watch?v=mzE8cyu9Vf8&t=1m4s | 19:26 |
| * perrito666 is overninetied by the video | 19:29 | |
| katco | https://www.youtube.com/watch?v=QkM-r4ZdX1o&list=PL0Yz4dINw_VIJ0bkHJe3ZV5ktsFsYxL2K | 19:29 |
| natefinch | pea sized hail falling here | 19:31 |
| natefinch | katco: good choice for coding brand new crap on the day of the deadline | 19:31 |
| katco | natefinch: you know it. rage against that machine baby | 19:32 |
| mup | Bug #1559277 opened: cannot set initial hosted model constraints: i/o timeout <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559277> | 19:36 |
| perrito666 | can I force the deletion of an old lxd controller? | 19:49 |
| katco | perrito666: with lxc delete <id> --force | 19:49 |
| perrito666 | katco: since you are in it, what was the new juju destroy --force? | 19:52 |
| perrito666 | in it == answering my stupid questions | 19:52 |
| katco | perrito666: oh thx for clarification :) uh i think destroy-controller although i don't see a --force | 19:53 |
| perrito666 | I recall sinzui mentioning something else the other day | 19:54 |
| sinzui | perrito666: juju kill-controller will call lxd if the controller wont shutdown | 19:56 |
| perrito666 | tx | 19:56 |
| perrito666 | I insist, destroy sounds much harder than kill | 19:56 |
| perrito666 | dunno, destroy sounds like kill then burn the body | 19:58 |
| perrito666 | ERROR cannot obtain bootstrap information: Get https://10.0.3.1:8443/1.0/profiles: x509: cannot validate certificate for 10.0.3.1 because it doesn't contain any IP SANs | 19:59 |
| katco | natefinch: where is the new location for the charm command patches? | 20:02 |
| natefinch | katco: github.com/juju/charmstore-client | 20:02 |
| perrito666 | sinzui: ever had that fun error ^^ | 20:02 |
| natefinch | perrito666: I have that one one of mine | 20:02 |
| perrito666 | natefinch: ? | 20:03 |
| natefinch | perrito666: I think it's the old lxd not playing well with new lxd | 20:03 |
| perrito666 | natefinch: any clue on how to solve it? | 20:03 |
| natefinch | perrito666: I haven't had time to poke at it yet | 20:03 |
| sinzui | perrito666: not woth 2,0. I have seen is with 1.18 and 1.20. I recall x509 errors were associated with clock skew. | 20:03 |
| perrito666 | I clearly have the wrong lxd version | 20:05 |
| perrito666 | which one should I have | 20:06 |
| natefinch | perrito666: well... you may have the right lxd version with an old lxd environment still running from the old lxd | 20:08 |
| natefinch | perrito666: I think that's the case for me | 20:08 |
| perrito666 | natefinch: I cannot create a new one so I think I have the wrong version | 20:08 |
| perrito666 | ERROR invalid config: can't connect to the local LXD server: json: cannot unmarshal number into Go value of type string | 20:08 |
| natefinch | perrito666: ahh, yeah that is definitely the "you have the wrong lxd" error | 20:09 |
| natefinch | perrito666: I think that means you have the one from the ppa... remove the ppa and remove lxd then install the standard one | 20:09 |
| perrito666 | hence my question, what is the right version :) | 20:09 |
| natefinch | apt-get install that is | 20:10 |
| mup | Bug #1559280 opened: creating hosted model config: opening model: endpoint: expected string, got nothing <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559280> | 20:13 |
| mup | Bug #1559285 opened: creating hosted model config: opening model: storage-endpoint: expected string, got nothing <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:New> <https://launchpad.net/bugs/1559285> | 20:13 |
| fwereade | ericsnow, do you recall why charmcmd.CharmstoreClient became *charmstore.Client? | 20:16 |
| ericsnow | fwereade: not precisely but I expect it was due to use elsewhere -> put in a common place | 20:18 |
| katco | natefinch: ericsnow: fyi i'm working on the list-resources subcommand of charm | 20:24 |
| ericsnow | katco: k | 20:24 |
| natefinch | katco: cool | 20:24 |
| natefinch | katco: too bad we can't just use the same implementation in both commands, since in theory they should be identical | 20:24 |
| katco | natefinch: i was thinking it would be ideal if we could somehow share the formatting | 20:25 |
| katco | natefinch: how did channel end up coming along for the ride in the charm command? looking at attach as the example | 20:29 |
| natefinch | katco: channel is set on the csclient.Client | 20:29 |
| katco | natefinch: but how does it get passed to that through the command? | 20:30 |
| katco | natefinch: e.g. charm attach --channel unpublished foo | 20:30 |
| katco | natefinch: i think i see... when the csclient.Client gets instantiated it takes in a *cmd.Context | 20:31 |
| natefinch | katco: attach doesn't use channels, publish does, though | 20:33 |
| katco | natefinch: ah ty | 20:33 |
| mup | Bug #1559293 opened: show-controller fails <ci> <show-controller> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559293> | 20:34 |
| marcoceppi | katco: I can't release anyways, charm store is still not deployed | 20:46 |
| katco | marcoceppi: kk we will keep you posted... coding remaining bit up right now, but then has to be reviewed, etc. we can still land on monday, yeah? | 20:47 |
| perrito666 | marcoceppi: do you happen to know a charm that has status-history implemented? | 20:47 |
| marcoceppi | perrito666: isn't status-history a CLI command? | 20:47 |
| perrito666 | I meant update-status | 20:47 |
| marcoceppi | katco: yeah, but I don't like the closenes | 20:47 |
| marcoceppi | perrito666: sure, a lot of layers have it, but none are like "traditional" charms | 20:48 |
| katco | marcoceppi: me either | 20:48 |
| * perrito666 is really having problems with this "dont drink coffee stuff" | 20:48 | |
| perrito666 | marcoceppi: dont care, I need to check on the excessive verbosity issue and need a charm with it installed | 20:48 |
| marcoceppi | perrito666: sure, any of the big-data ones use it. let me get you one | 20:49 |
| perrito666 | tx | 20:49 |
| katco | ericsnow: standup time | 21:02 |
| mup | Bug #1559299 opened: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559299> | 21:04 |
| mup | Bug #1559305 opened: Process exited with: 1. Reason was: () <bootstrap> <ci> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559305> | 21:04 |
| mup | Bug #1559310 opened: bootstrap fails: "model is not bootstrapped" <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559310> | 21:04 |
| mup | Bug #1559313 opened: admin-secret should never be written to the state <bootstrap> <ci> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559313> | 21:16 |
| perrito666 | trivial review anyone? http://reviews.vapour.ws/r/4233/ | 21:30 |
| mup | Bug #1559329 opened: Relation information is duplicated in status tabular format <juju-core:New> <https://launchpad.net/bugs/1559329> | 22:19 |
| mup | Bug #1559329 changed: Relation information is duplicated in status tabular format <juju-core:New> <https://launchpad.net/bugs/1559329> | 22:31 |
| perrito666 | cmars: you are not here still, are you? | 22:34 |
| perrito666 | ouch I fixed a duplicate bug | 22:41 |
| perrito666 | cherylj: nice catch | 22:42 |
| mup | Bug #1559329 opened: Relation information is duplicated in status tabular format <juju-core:New> <https://launchpad.net/bugs/1559329> | 22:43 |
| perrito666 | there is some irony there, a bug about duplicate status is a duplicate | 22:43 |
| perrito666 | heh | 22:43 |
| cmars | perrito666, did i open a duplicate bug about duplicates? | 22:44 |
| perrito666 | you did | 22:44 |
| cmars | maybe i should call it a week :\ | 22:44 |
| perrito666 | and I fixed it, so if you want to check the 3 line fix before leaving Ill fix it | 22:44 |
| perrito666 | merge it* | 22:44 |
| cmars | oh, awesome, got a link | 22:44 |
| perrito666 | http://reviews.vapour.ws/r/4235/ | 22:44 |
| perrito666 | I was literally playing with vim syntax checkers with that file :p | 22:45 |
| cmars | perrito666, looks good, but probably worth a test | 22:46 |
| cmars | perrito666, for a followup? | 22:47 |
| perrito666 | definitely, tests in status take a couple of hours to write | 22:48 |
| perrito666 | status tests are like a coding speedbump | 22:49 |
| mup | Bug #1559329 changed: Relation information is duplicated in status tabular format <juju-core:In Progress by hduran-8> <https://launchpad.net/bugs/1559329> | 22:49 |
| katco | cherylj: sinzui: either of you still around? easy-peasy question/comment | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!