[00:09] thumper: http://reviews.vapour.ws/r/955/, thanks === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [00:42] wallyworld_: fyi i plan on attending the stand up tonight [00:42] wot? it's the weekend :-) [00:43] wallyworld_: WHAT! no one told me! ;p === kadams54 is now known as kadams54-away [01:14] anastasiamac_: review done on your mega branch [01:15] anastasiamac_: I didn't go through all of it as I wanted some response on what I had suggested first [01:17] katco: we lost you [01:17] axw: doh [01:34] thumper: it's amazing! thnx :D i wasn't expecting u to have a chance to look but really appreciate u did! [02:17] thumper: sendError() on httpHandler only takes an error message [02:18] I know [02:18] thumper: i need both coe and message :D hence an additional sendError method that taeks and error instead of string [02:18] anastasiamac_: read my answer again, and if you still have questions, we should talk [02:18] but OTP right now [02:27] wallyworld_: I forget if I already sent you this link before, this is my WIP for the storage provisioner: https://github.com/axw/juju/tree/worker-storage [02:28] thanks, will look after i finishing looking at the storage lifecycle branch [02:28] wallyworld_: thanks. it doesn't need review, just an FYI [02:29] kk === kadams54 is now known as kadams54-away [03:46] axw: in type VolumeParams struct, should the Attachment field be of type *VolumeAttachmentParams rather than *AttachmentParams? [03:46] wallyworld_: yeah, I think so [03:46] ta, will fix [03:46] I was thinking not before, but there may be volume-specific attachment params [03:47] yeah [03:57] axw: the path == "" check in rootfs createfilesystem - you say that the path value in FilesystemAttachmentParams should be set by the caller - that would imply it's up to the storage provisioner to set it. But the storage provisioner would then need to keep track of the ConfigStorageDir param. It is not easier to keep the code as is and let rootfs provider use a default path? [03:57] wallyworld_: hold up, need to refresh my memory [03:57] http://reviews.vapour.ws/r/956/ [03:58] wallyworld_: do you mean location==""? [03:58] axw: i've change location to path [04:00] wallyworld_: hmmm. so, this is a provider-independent thing. I think it's unnecessarily onerous to make it the responsibility of the provider to come up with a unique path to mount at [04:00] wallyworld_: I think I' [04:01] d prefer if we just had the storage provider set location to /var/lib/juju/storage//tag [04:01] axw: that's what storageDir is for [04:01] it's the only thing it is used for atm [04:01] i guess it can be the absoluet tpath [04:02] but then we'd not need the attachment params path attr [04:02] wallyworld_: I don't see why the provisioner having to track ConfigStorageDir is a problem. in fact, it doesn't track it, it specifies it based on the agent's data-dir [04:02] wallyworld_: yes we do, because the user can specify path [04:03] wallyworld_: this storage-dir path should only be used if the user didn't specify one [04:03] s/user/charm author/ [04:03] right, ok. then perhaps the config attr should be called DefaultStorageDir [04:04] wallyworld_: actually I don't think that config attr should come into it [04:05] wallyworld_: that directory was meant to be for storing info about volumes and filesystems [04:05] wallyworld_: not for where the mount points end up [04:05] wallyworld_: e.g. in the loop provider, we should create the file in ConfigStorageDir, but then mount it at "location" [04:07] ok, so we need to ensure then that Path is always set, and the provider needs to choose a sensible location if the user doesn't specify one [04:07] provisioner [04:07] right [04:08] np. the way i've had it till now is how we had id in the feature branch [04:08] but that was all done for the demo [04:39] axw: hiya. in environs/cloudinit/cloudinit.go:AddAptCommands, do you know why required packages aren't being installed when enable-os-refresh-update is false [04:39] ? [04:39] axw: it means that rsyslogd is completely broken when enable-os-refresh-update is turned off. [04:40] menn0: I think it's because some of the packages may not be found, because they're in cloud-tools [04:41] axw: i feared that there might be some complication like that. [04:41] menn0: rsyslogd-gnutls should always be found I think ... we could be more selective there [04:41] axw: yeah rsyslog-gnutls is needed in order for logging to work [04:46] wallyworld_: were there specific tests you found missing in my branch, apart from the existing tests you mentioned? [04:46] wallyworld_: I've identified a problem with the RemoteStorageInstance test, and I ended up removing that method [04:47] since I don't think it should be possible to remove a storage instance directly, only destroy & remove attachments which will do the job [04:47] axw: mainly just tests to check that the business logic rules that cause the txns to retry when things are done concurrently [04:47] wallyworld_: ok [04:47] do you know the bits i mean? [04:48] around checking for attachment count > 0 (or = 0) etc [04:48] can't recall specifics [04:48] wallyworld_: yup [04:49] menn0: if you set refresh to false, you are promising to juju that your image has everything needed [04:49] that's why it's true by default [04:50] wallyworld_: i'm doing scale tests with just the ubuntu charm so I figured it would be safe to turn off to speed things up [04:50] wallyworld_: i'll turn it back on for now [04:50] ah, i see [04:51] menn0: what series are you using? precise? trusty? [04:51] wallyworld_: this is trusty on EC2 [04:51] hmmm, i would have hoped trusty would be ok with false [04:51] :-( [04:52] wallyworld_: i'm not convinced the logic in juju is quite right. as axw also indicates, there are probably some package that should always get installed even if an apt-get update isn't being done. [04:53] yeah, that is true [04:53] it's a blunt instrument right at the moment [04:56] wallyworld_: most of these tests can't be done concurrently, because of lack of support for shared storage. e.g. in theory you could add unit, then concurrently add another unit and remove the first one's attachment, ensuring the instance isn't removed [04:56] but we can't do the in theory bit yet [04:56] I'll do what I can, but I don't think it's much [04:56] ok, just wanted to be really sure that if itwere possible to test the bad cases, we could [04:57] axw: there's 2 choices with the Path passed to rootfs provider already existing - 1. be really paranoid and assume that another storage is already using that path and return an error (will revisit later when shared storage supported), or 2. see if dir is empty and return an error if not [04:58] or 3. - something else? [04:58] eg just let it slide, but i don't think we should do that [04:58] wallyworld_: we should be guaranteeing #1 is not a possibility, I think [04:59] in which case, #2 [04:59] axw: that's the provisioner's job yeah [04:59] hence i was also leaning to#2 [04:59] wallyworld_: partially, we also need to prevent multiple storage instances with the same path [04:59] storage attachments* [05:00] i.e. explicitly specified path in the charm metadata [05:00] yes, but not inside rootfs [05:00] yep [05:00] I mean at a level higher than the provisioner, and also in the provisioner [05:00] yeah [05:00] i'll add the empty check to rootfs [05:01] axw: you going to land the disktag rename pr? [05:01] wallyworld_: I'll do it later, I'd like to get the state one fixed first [05:02] ok [05:02] wallyworld_: it's just a sed to fix up [05:02] my rootfs one depends on it also, but it can wait [05:03] wallyworld_: it depends on my branch? [05:04] wallyworld_: can you just land using DiskTag, and I'll fix up later? [05:04] axw: i added filesystemtag on top of your volumetag branch in juju/names [05:04] ah, right [05:04] wallyworld_: I'll land it now then [05:04] it's no biggies, i can wait [05:04] i'm still fixing the rootfs branch [05:24] wallyworld_: merged [05:24] axw: awesome, ty === Guest33721 is now known as benonsoftware [05:58] axw: http://reviews.vapour.ws/r/956/ has been updated; once you are free from your other stuff, would be great if you could look. i have to duck out to do school pickup, so bbiab [05:58] wallyworld_: thanks, just pushing changes to http://reviews.vapour.ws/r/969/ too [05:58] ok, will look as soon as i'm back === Murali_ is now known as Murali [06:25] thumper: did you manage to get the rework from executive summary through the rest of the JES CLI document? [06:25] jam: yes [06:25] * thumper shouldn't be here === benonsoftware is now known as Guest48867 === Guest48867 is now known as benonsoftware [06:53] wallyworld_: ;) I can rename it to "TestCDSIRSARI" ? ;) [06:53] yeah, why not :-) .... kidding :-) [07:09] hey wallyworld_, thanks for that cloud-image-utils fix for precise [07:10] dimitern: hi there, and thanks for landing [07:10] dimitern: did you see the little govet issue in provisioner.gp? [07:10] wallyworld_, np [07:10] wallyworld_, mm no? [07:10] checking: go vet ... [07:10] apiserver/provisioner/provisioner.go:1028: arg addr for printf verb %q of wrong type: *github.com/juju/juju/state.IPAddress [07:11] was introduced yesterday i think [07:11] wallyworld_, cheers, I'll have a look [07:11] there's about 6 of them [07:11] wallyworld_: sabdfl just gave a +1 on storage CLI [07:11] and liked your layout [07:11] i hope we can release 1.22 finally :-) [07:11] jam: that's awesome news, ty [07:12] none of us liked the CLI n the spec [07:12] he really liked using the "juju status --help" syntax to understand how it all looks [07:12] yeah, that approach was done with the juju metadata stuff for tools and images [07:13] wallyworld_: can you do the edits to the actual Storage Spec ? [07:13] jam: yep, can do, just need to check i have dit permissions [07:13] edit [07:14] I think I gave you edit for the last round [07:14] yep, just checked [07:17] wallyworld_, where have you seen these go vet warnings? I've run go vet ./... on trunk now and 99% of what I get is "using unkeyed fields" [07:18] jam, wallyworld_: thnx for nice storage CLI approval :D [07:18] dimitern: i basically saw it when i pushed my branch, after rebasing. it is a legit error - %q expects a string [07:18] anastasiamac: wallyworld_: thanks for a nice proposal :) [07:18] wallyworld_, and in that case you've mentioned "%q" for a *state.IPAddress is fine, because it has String() method [07:19] jam: wallyworld_and axw proposed:D i just had fun with 3 level commands :) [07:19] so it's not a string but it's a Stringer [07:19] dimitern: so, it's the pre push hook that is invoking go vet - perhaps there's a warning level that's different? [07:20] wallyworld_, I'm not sure I have that pre-push hook configured locally - what should I do? [07:20] dimitern: the pre-push hook should be in VCS [07:21] in the scripts dir [07:21] wallyworld_, ok, but do you enabled it somehow? [07:21] enable* [07:21] anastasiamac: cool :) [07:22] dimitern: you have to edit .git/config [07:22] yeah, i can't remember exactly - it should be on the contributing page [07:22] wallyworld_: u know how i could not get my PR to have RB request? [07:22] jam, wallyworld_ , ok, will do [07:22] wallyworld_: and i had to resolve conflicts and re-propose? [07:22] which branch? [07:23] wallyworld_: well, i have just pushed to the same PR and found that there are conflicts again... The RB is not updated tho :( [07:23] wallyworld_: block-cmd-update... [07:23] 967? [07:23] wallyworld_: https://github.com/juju/juju/pull/1638 [07:23] yes [07:24] if rb isnot updating, let eric know and he might be able to help fix it [07:24] wallyworld_: and btw, u r no longer on PM [07:24] i am on free node [07:25] i can also see channels on canonical server [07:25] wallyworld_: couple of minutes ago, i was told u were not ;D [07:26] jam: thanks for fixing my blunder in liveSource [07:26] anastasiamac: go figure, i have no idea wtf is happening with my stupid network [07:27] wallyworld_: u r putting it under a lot of pressure? :D [07:28] not that i know of :-) [07:33] anastasiamac: so i'd fix your merge conflicts and repush to GH and see if that then allows rb to updates [07:34] wallyworld_: thnx :D will try, just one more push... :D [08:15] menn0: scale testing sometime ? [08:19] morning [08:27] jam: i've been doing exactly that [08:27] menn0: k, I don't think I'd seen anything back from you, so just figured I'd give you a poke and see how its goin [08:28] jam: i [08:29] jam: i was going to contact you when I had some numbers. I have numbers for the logging to mongodb case but logging via rsyslog has been giving me problems. === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: none [09:49] restore is finally landed [09:49] * perrito666 cries [09:50] perrito666, \o/ [09:51] now its no longer just my problem :p [10:16] perrito666: epic :) [11:18] dimitern: o/ [11:19] anastasiamac, hey there [11:19] dimitern: got trunk to resolve my conflicts and am getting test failures in apiserver/provisioner/prepare_test.go [11:19] dimitern: how r u? [11:20] anastasiamac, oh, let me have a look? [11:20] anastasiamac, I'm better than last week :) - no blockers [11:20] dimitern: ""cannot allocate addresses: dummy.NetworkInterfaces is broken" [11:20] line138/288 [11:20] :D [11:21] anastasiamac, hmm I mean can you paste the failures? [11:21] anastasiamac, to see the context [11:22] dimitern: http://pastebin.ubuntu.com/10370778/ [11:22] dimitern: really appreiate ur help :D [11:22] appreciate even [11:22] anastasiamac, right, have you merged the changes to the dummy provider? [11:23] dimitern: ? [11:23] dimitern: i got the trunk, created my branch and applied my changes [11:23] dimitern: running tests, gives me this error :D [11:23] dimitern: what m i missing? [11:23] dimitern: :) [11:23] anastasiamac, let me have a look.. [11:24] dimitern: do u want the link to PR? [11:24] anastasiamac, my tests on trunk are passing, so maybe you haven't merged all changes? [11:24] anastasiamac, yes please [11:24] dimitern: https://github.com/juju/juju/pull/1652 [11:24] dimitern: RB http://reviews.vapour.ws/r/979/ [11:26] anastasiamac, looking [11:26] dimitern: tyvm [11:27] dimitern: ping [11:27] anastasiamac, well, istm you haven't pulled everything in there from master - e.g. the apiserver/provisioner changes I made recently (#1646) require some changes in state (#1631) and the dummy provider (#1632) [11:28] anastasiamac, these are probably missing (the last one for sure), hence the error [11:28] TheMue, pong [11:28] dimitern: k. thnx :D i'll double check! [11:30] anastasiamac, i suspect you've merged master partially [11:30] dimitern: stumbled over the usage of network.Address in state. once we use it directly, so w/o any tags, the other time we have already a local substitute with a tag giving the Scope field the name networkscope [11:30] TheMue, can you give me examples? [11:31] dimitern: hangout? [11:31] dooferlad, in 5m pls [11:32] dimitern: yep, look at addmachine.go:45 and address.go:183 [11:32] dimitern: sure. [11:32] dimitern: similar with hostPort in address.go few line later too [11:33] TheMue, I'll get back to you after my 1:1 with dooferlad, if that's ok [11:34] dimitern: sure, thx [11:54] dimitern: contacted on PM [11:57] anastasiamac, sure, in a meeting will get back to you shortly [12:16] * TheMue is out for lunch [13:09] dimitern: have you seen fwereade today? [13:10] jam, no, but I've heard he's having connection issues [13:10] k [14:23] OCR PTAL http://reviews.vapour.ws/r/981/ <-- fixes ./scripts/verify.bash pre-push hook warnings when using newer versions of go [14:27] jw4: I would have expected the formatting function to call strig [14:27] string [14:28] perrito666: agreed, but it seems %q isn't handled quite the same as %s [14:29] jw4: wellI would assume it is, since the output of calling that actually works [14:29] perrito666: and I think it works, it's just that newer versions of go vet warn about it [14:29] It sounds to me that govet is broken [14:29] perrito666: possibly [14:29] ma windows takes a lot to download [14:29] man* [14:31] sinzui: ping me when you have a moment :) I am about to make you the happiest QA person in the world [14:33] perrito666, really? you can tell me my our maas 1.5, 1.7, and 1.8 hate juju 1.22 and 1.23 [14:34] sinzui: no but, I just merged the last bit of restore :) [14:34] perrito666, NOoooooo...... [14:35] perrito666, the restore tests have been very reliable this year. Why complete a feature to risk a failure? [14:35] perrito666, sorry about the sarcasm [14:35] sinzui: I have not nuked the old restore [14:35] :p [14:37] jw4, ping [14:37] sinzui: I need to discuss with you how to do this, I could just make the old restore call the new one with parameters that make it do the same, but output might change [14:38] jw4, yeah - go vet seems amiss here [14:38] dimitern: pong [14:38] perrito666, we do need old restore to call new restore because enterprises may have scripted juju 1.18 restore. [14:39] dimitern: from previous experience I doubt we'll get go vet fixed if it is a bug in go vet, and anyone using go1.4+ won't be able to get past the pre-push hook [14:39] perrito666, as for the output change, I don't think there is a contract for the output. [14:39] sinzui: ack, btw, there are a couple of new test cases to add :p sorry [14:39] perrito666, if CI fails because it scanned output, then we will change ci [14:39] dimitern: fwiw I'm about to propose a tweak to verify.bash that allows ignoring go vet with an envar [14:40] perrito666, old restore only need to work its way. New cases can require the new restore [14:41] sinzui: yes, the new cases are for the new restore, just sending a heads up [14:41] will send you an email with details [14:42] jw4, sure, sgtm, I'll have a look at your PR as well [14:42] dimitern: ta [14:42] * dimitern needs to start using go1.4 [14:42] dimitern: I am [14:42] thank you very much perrito666 . the email will be helpful as I am not fully caffeinated. [14:43] sinzui: I am on that process, I assisted a wedding on saturday and my liver seems to be off for repairs [14:43] :) [14:45] dimitern: http://reviews.vapour.ws/r/982/ <-- allows environment variable to bypass go vet failing the pre-push hook [14:45] perrito666, OCR ^ [14:45] jw4, already approved :) [14:46] dimitern: thanks! [14:46] :) [14:47] jw4, hmmm you know what? looking at your last PR gave me an idea [14:47] dimitern: yeah? [14:48] jw4, it seems we're not adding Logf to the list of printfuncs in verify.bash, and it does seem 1.4 go vet reports only them, but not e.g. logger.Tracef one, which have %q as well [14:48] dimitern: I think Logf is automatically included and we have to explicitly add the others... [14:49] jw4, ah, no - my mistake, go vet did report logger.Infof("assigned address %q to container %q", addr, container) for example [14:49] jw4, so it's that [14:49] it's not that even [14:52] jw4, LGTM on the other one [14:55] tx dimitern [14:56] np === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424669 [15:02] dimitern, natefinch can you find someone to look into a gccgo problem in bug 1424669 [15:02] Bug #1424669: ppc64el fail multiple definitions of juju_juju_api_networker.NewState

[15:02] sinzui, I was looking at this since saturday [15:02] sinzui, it's another random ppc64 gccgo compiler issue [15:02] sinzui, like the last blocker [15:03] sinzui, I've requested access to a ppc64 machine to all me to run tests and analyze whether building a more recent version of gccgo will resolve this [15:03] dimitern, It is consistent since those the commits, the ppc suite are not unreliable [15:04] dimitern, I will get you access to stilson-09 in a few minutes [15:04] sinzui, yes, but it only happens on ppc64, right? [15:04] sinzui, ah, great! [15:05] dimitern, yes, but the duplicate definition issue was identified to be a gccgo problem. Test need to be written a certain way to ensure the real impl isn't seen by the compiler [15:05] sinzui, I can usually reproduce such gccgo issues easily on my trusty amd64 machine with gccgo, but not this one [15:06] sinzui, hmm is there some document or instructions on this? [15:07] dimitern, I don't know, jam and wallyworld fixed the bugs in the past [15:08] dimitern, I think the issue related to passing interfaces vs passing strings [15:08] sinzui, ok, I'll look into that [15:16] natefinch: Have you had a chance to look more into bug 1424069? [15:16] Bug #1424069: juju resolve doesn't recognize error state [15:18] aisrael: no, sorry, haven't put any more time into it. I'll spend some time trying to figure it out today. [15:18] natefinch: much appreciated. It's a bit of a blocker for me, unfortunately === whit_ is now known as Guest39130 [15:55] natefinch, dimitern : The QA team are looking for advice regarding bug 1424695. We don't know if this issue is juju or CI. We are happy to change CI to make juju pass [15:55] Bug #1424695: cloud-init cannot download agent from state-server

[15:56] sinzui, I'll look into it [15:56] dimitern, we are working on getting logs, so the bug is reported from my memory [15:57] sinzui, yeah logs will be good to have - I've been monitoring those failing maas jobs on 1.22 for a few days [15:58] dimitern, if John's fix isn't ready for the next run, we will intercept machine-1 before it is destroyed [15:58] sinzui, great, please let me know [16:15] natefinch, do you think that https://bugs.launchpad.net/juju-core/+bug/1424069 may be a result of current LE work? [16:15] Bug #1424069: juju resolve doesn't recognize error state [16:16] wwitzel3: http://reviews.vapour.ws/r/983/ [16:26] alexisb: no idea, I'm working on investigating it now. At least it's easily reproducible [16:26] natefinch, ack [16:29] ericsnow: will take a look [16:29] wwitzel3: ta [16:37] dimitern: beside the types to move we also have methods on State responsible those types (would be nice to move them too) and which use the package private network related docs, like ipaddressDoc [16:44] TheMue, that sounds like a good idea, but can it be done? [16:44] TheMue, i.e. state.State can't have methods defined on it in a subpackage [16:45] dimitern: I'm currently checking, many depending places [16:46] dimitern: yes, otherwise the new sub-package has to provide functionality used by those functions [16:46] dimitern: like e.g. State.AddIPAddress() [16:46] dimitern: a wonderful candidate [16:46] :) [16:47] TheMue, yeah :) [16:48] dimitern: thinking of a NetworkState type in the network package, returned by State and containing all needed data [16:48] dimitern: and then move the methods to this type [16:49] TheMue, experiment a bit and I'll see what you've pushed later [16:49] dimitern: so nwst := st.NetworkState() and nwst.AddIPAddress() [16:49] dimitern: will do === kadams54 is now known as kadams54-away [17:44] TheMue, can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/ [17:46] natefinch, perrito666, ^^ [17:48] katco, ^^ [17:48] TheMue / dimitern: could you take a look at this monster diff? https://github.com/juju/juju/pull/1657 Two whole lines! [17:49] dooferlad, looking :) [17:51] dooferlad, reviewed [17:52] dimitern: thanks! [17:52] dimitern: Doh! Good point! [17:53] dooferlad, ;) np [17:53] ericsnow, ping [17:53] dimitern: hey [17:54] ericsnow, hey :) I'm glad someone is around - can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/ [17:54] * ericsnow takes a look [17:54] ericsnow, thanks! [17:57] dimitern: done [17:57] ericsnow, cheers [18:03] ahoy abentley! We are seeing an error on the automated testing system. Can you take a look? http://juju-ci.vapour.ws:8080/job/charm-bundle-test-azure/46/console [18:04] abentley: I see a few error messages in there that I don't know how to resolve. [18:04] ERROR cannot assign unit "kubernetes/0" to machine 2: unit placement is not supported with availability-sets-enabled === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [18:08] mbruzek, AFAIK azure does not support --to for deployments [18:08] dimitern: OK I thought it was just a setting in the azure setup that we could change. [18:08] mbruzek, when you have "availabiliy-sets-enabled: true" set [18:09] dimitern: could we set that to false? [18:09] or do we need that? [18:09] mbruzek, I suppose if you haven't heard of it you don't need it :) [18:09] mbruzek, it's an env.yaml setting [18:10] mbruzek, but it's enabled by default for azure [18:11] dimitern: We want to be able to pass on Azure, and our bundle needs some co-located charms for it to work. [18:12] dimitern: So are you saying that if we set that to false, Azure will not honor the --to command? [18:12] mbruzek, so then try adding "availability-sets-enabled: false" in your env.yaml for that environment and bootstrap again (it can't be changed after bootstrap) [18:12] mbruzek, I'm saying the opposite :) [18:13] dimitern: OK. This is the automated CI system I need abentley or sinzui to help with that. [18:13] mbruzek, if it's false --to is supported [18:13] mbruzek, +1 [18:13] dimitern: thanks for your help [18:14] mbruzek, np [18:18] sinzui, one blocker down, one to go - but I'm at eod for some time now, so somebody else perhaps; getting logs from the machine (1,2) will definitely help there [18:24] dimitern, I am almost to it. [18:24] sinzui, great! I hope it works === kadams54-away is now known as kadams54 [19:15] natefinch, abentley : we need to discuss bug 1424777 [19:15] Bug #1424777: local-provider precise failed to upgrade

[19:16] sinzui: sure thing. The usual hangout? [19:16]