=== thumper-dogwalk is now known as thumper [00:05] thumper: good news, we're now getting much better tear down suite errors [00:05] http://paste.ubuntu.com/15324360/ [00:05] bad news, tests still fail on my machine [00:05] seems to be load related [00:08] has someone done somethign dumb and mongo always listens on the same port or somethign [00:26] davecheney: I don't think so [00:27] because I can still have multiple test runs running in parallel [00:57] still trying to figure out it === ses is now known as Guest72666 [01:28] welp, at least people are talking about Juju :) [01:29] https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o [01:29] if it's one thing I know how to do, it's start a nerd slap fight [01:46] heh [01:46] * thumper goes to look [02:10] davecheney: good times, juju breaking teh toolz [02:16] thumper: https://github.com/juju/juju/pull/4629 [02:16] PTAL [02:16] i have removed every single use of the words 'upgrade in progress' from juju [02:17] they all come from the params.CodeUpgradeInProgress constant now [02:17] i still need to test this manually [02:17] with bootstrap, and the backup/restore dance [02:23] natefinch: quick review? https://github.com/juju/charm/pull/194 [02:23] katco: sure [02:24] katco: see now, how can I make a miraculous save at the last minute if you get there first? :) [02:24] natefinch: by staying focused on resources ;) [02:25] katco: I [02:25] katco: i've been thinking about ways to make the merge easier, since the changes to juju/juju necessarily touch ~170 files [02:25] katco: well, not necessarily, given my idea [02:26] katco: the main problem is that I moved version to an external repo, which changes friggin' everything. But all the charm package *really* needs it for, is to verify that the string someone put in metadata.yaml is a valid version string [02:27] natefinch: yeah wallyworld and i were just discussing that [02:28] katco: if instead of making charm.minjuversion a "version.binary" struct, we just kept it as a string and shared the regex that verifies it... that suffices, and reduces the changelist by about 98% in juju/juju [02:29] s/version.Binary/version.Number [02:30] natefinch: let me see how the merging goes, but a little copy/paste sounds like a great trade-off for that dep [02:30] katco: ok. easy enough to give it a try. I'd prefer the version stuff were out in its own repo, but the churn is ouchy. [02:30] katco: thanks for taking that on. I had planned to burn some sleep time tonight seeing if I could come up with a fix, 'cause I really wanted min-juju-version in 2.0 [02:31] natefinch: thanks for the thought, but getting resources all buttoned up is way more important [02:31] natefinch: happy to take this on for the team [02:34] katco: you got a LGTM from me... feels kinda weird reviewing what is mostly my own code ;) [02:34] natefinch: well, you're the sanity-check for the merges. wallyworld also gave a review, so we're covered :) [02:35] i do like the idea of having the min version as a string in charm meta though [02:35] greatly simplifies everything [02:36] I love the way it simplifies the change.... though I think it is far superior to have it as a struct... it's hard to justify the sheer volume of churn that produces. [02:38] one other possibility is to have charm use the external repo just to verify with Parse(), then store it as a string... then after 2.0 we can make the change to switch everything over to the external repo (if we think it's worth it at that point). [02:39] I guess that doesn't really buy us anything different than just stealing the regex for 2.0 [02:39] * natefinch stops thinking about versions and goes back to resources. [03:49] natefinch: did you have a test script to test this manually? [03:50] katco: you can just add juju-min-version: 1.25 to any metadata.yaml, verify it deploys ok, then change it to 99.99 and verify it tells you it can't be deployed [03:50] natefinch: cool, ty [04:12] wallyworld: natefinch: https://github.com/juju/juju/pull/4648 not showing on RB for some reason [04:12] yay rb [04:14] well, not like rb would make it any easier to review 2281 changed files [04:14] omg, it's all the model stuff, no wonder [04:15] LOL: commits 250+ [04:15] "I dunno.. more than 250" [04:16] wallyworld: natefinch: i listed the merge conflicts in the commit if you just want to review those. CI will catch most everything else [04:17] katco: that would be very much handy [04:17] wallyworld: natefinch: ah there's RB: http://reviews.vapour.ws/r/4091/ [04:17] just took a while to digest [04:18] wallyworld: probably b/c it's python. /troll [04:18] lol [04:18] sigh [04:18] wallyworld: natefinch: updated conflicts in RB [04:20] This diff has been split across 114 pages [04:21] katco: I don't know tht reviewing the merge from master is terribly useful. I think looking at the PR from this branch to master after this merges would be a lot more instructive [04:22] natefinch: i'll have CI try and merge it. i'm sure a test will fail [04:23] Bug #1532063 changed: Unit seems unable to proceed after watcher died in the middle of hook execution [04:28] 15:20 < natefinch> This diff has been split across 114 pages [04:28] ^ that's going straight to the quotes page [04:29] davecheney: to be fair, it's 3 months of updates to master getting merged into a feature branch [04:32] Bug #1550770 changed: TestContainerStartedAndStopped cannot create mock container on ppc64el/arm64 xenial/wily

[04:39] TheMue: // cannot import apiserver to get access to apiserver.UpgradeInProgress [04:39] // because that creates and import loop. [04:39] thumper // cannot import apiserver to get access to apiserver.UpgradeInProgress [04:39] // because that creates and import loop. [04:39] ^ i'm crying [04:40] :/ [04:41] davecheney: where is that? [04:42] davecheney: please watch over us while i sleep [04:42] wallyworld: natefinch: missed juju/version in dependencies.tsv. kicked off another merge into feature branch. calling it a night. tc [04:42] o/ [04:43] see ya [04:43] no, i wrote that comment [04:43] katco: thanks! [04:43] davecheney: oh [04:43] once I get this branch landed and the pressure is off [04:43] i'm merging apiserver and apiserver/common [04:43] davecheney: in that case s/and import loop/an import loop [04:44] :D [04:44] * natefinch focuses on the important bits. [04:44] they are actually the same the package, but have been split by a londitudinal fissure for reasons that don't make sense any more [04:44] ahh yes, I'm working in one of those myself [04:53] Bug #1536587 changed: juju's MAAS bridge script is echoed to the console by cloud-init during bootstrap

[04:58] commit 33438a26ed2b98438bc881a20fd14032bff56093 [04:58] Author: Dave Cheney [04:58] Date: Tue Mar 8 15:55:00 2016 +1100 [04:58] Angry rant time! [04:58] UpgradeInProgressError used to be defined in apiserver/admin.go and used in apiserver/upgrading_root.go. __BUT__, the logic that turns errors into rpc messages is inside apiserver/common/error.go. This creates a potential import loop as apiserver already imports common, so common cannot import apiserver to get a type. [04:58] So, to ~~solve~~ workaround this clusterfuck, we move UpgradeInProgressError to apiserver/params, which everyone imports and solve the import loop. [04:58] This is _SHIT_. apiserver and apiserver/common are clearly the same package, thay cannot function without each other and have been bifurcated for reasons that no longer make sense. [04:58] Once this PR is landed, I will merge the two packages and then we can define, and use UpgradeInProgressError in _one_ place, and then we can also unexport it because things should not be checking for it explicitly on that apiserver side of the blood/brain RPC layer. [05:01] davecheney: -1 from me that apiserver and apiserver/common are rge same package [05:01] apiserver/common contains shared server side implementation that is embedded in several facades [05:01] that's fair [05:01] apiserver is other stuff [05:01] but some parts of the apiserver/common package belong to apiserver itself [05:01] specfically apiserver/common/error.go [05:01] that may well be true :-) [05:02] wallyworld: did you see the "failed bootstrap leaves stuff in cache.yaml" bug? [05:03] jam: i did see it float passed, have not looked closely [05:05] jam: is it this one? bug 1554042 [05:05] Bug #1554042: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap [05:05] wallyworld: np. just wanted you to be aware. It seems if something gets into cache.yaml then we don't have a way via kill-controller, etc to get rid of it [05:05] wallyworld: yep [05:06] jam: cache.yaml is almost gone, will need to check what the story is with the other yaml files to see if we are cleaning up [05:06] thanks for the heads up [05:06] on my big long todo list [05:06] just wanted to add an entry, I don't think it is very high priority [05:09] why does cmd/juju import cmd/jujud/agent ... ? [05:10] davecheney: it does? i had a quick look but didn't see where, but i could be blind [05:11] it imports it transitively via components/all [05:13] components/all imports a lot of stuff... forget why agent [05:13] natefinch: presumably because "component" work implements front end and backend stuff in the same package [05:13] because it is grouped by topic instead of by layer [05:13] wallyworld: http://paste.ubuntu.com/15325996/ [05:15] jam: well, the component stuff is grouped by topic inside the component code itself (payloads, resource)... but the component package wires it all up from the same place. That's a mistake, and actually pretty easily fixed. The code is already separated into functions for server vs. client, they could easily be put in different pacakges. [05:15] oh, transitively, ok [05:15] jam: sorry, I meant it's grouped by layer inside the component folders (payloads, resources) [05:17] jam: FWIW, the components/all stuff is basically unrelated to the component setup. It exists for dependency injection purposes.... which I don't entirely agree with. [05:19] "dependency injection" [05:19] ^ taht's the most creative use of that word i've ever seen [05:19] that should have got Leonardo's Oscar [05:21] it's not the way that I would have done it.... but I can only provide so many dissenting opinions [05:25] davecheney: is there an easy way to fill out a fake http.Response? [05:25] maybe, which fields do you want to fake ? [05:27] davecheney: all I really need is the body and statuscode... which I guess I can just set to whatever... luckily out code seems not to look at much else [05:28] davecheney: which is to say, nevermind, I think I'm fine :) [05:35] \o/ best support issue [05:35] one that solves itself [08:44] Bug #1554417 opened: Juju 2.0: ERROR cannot deploy bundle: machine "0" is not referred to by a placement directive (and 4 more errors)

[09:06] dimitern: sync? [09:10] frobware, hey, sorry got carried away while testing :) [09:11] omw - 2m [09:45] Bug #1554436 opened: Juju adds any RFC1918 address it finds on any state servers to the apiaddresses list in agent.conf

[10:01] jam: you doing standup? [10:01] sure [10:02] brt [12:49] dimitern: I saw you review comments - they are useful but questioning the value if this code will be deleted as soon as we land maas-spaces2 [12:49] dimitern: if this code lives on, then sure [12:50] frobware, np, feel free to drop them [12:51] frobware, just as I'm writing tests as well now those just crossed my mind :) [12:51] dimitern: if we don't feel this code is going away then I can address them [12:52] frobware, it should, yeah - this is temporary [13:03] morning juju-ers o/ [13:03] morning TheMue [13:06] frobware: dimitern: dooferlad: passing SpaceInfo rather than just id turned out to be really easy [13:06] frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/4096/ [13:06] and bindings already have a name, so nothing to do there [13:09] voidspace, cheers, looking [13:09] TheMue, hey ;) [13:15] found a way to run irc here too (ok, not here, but ssh to my server and irssi there) ;) [13:16] still missing our team [14:00] hi TheMue [14:00] good to see you around [14:01] dimitern: MAAS meeting [14:02] voidspace: ^^ [14:02] oh yeah [14:02] brt [14:02] tych0: I did a bit more work on my branch to further the "grab images via ImageCopy instead of lxd-images import" [14:02] omw [14:02] tych0: but that made me look deeper into what our "caching" story is going to be, because that really changes where we search for images. [14:03] tych0: I hope I wrote that up nicely in my email. But I think we can take my branch and quickly turn that into just CopyImage from cloud-images.ubuntu.com if we want stepping stones along that path. [14:03] jam: oh, did you see my PR? [14:03] jam: i did all that already :\ [14:05] tych0: np. I'll look at it now. I didn't see it earlier. But what I did doesn't really overlap with what you're doing. [14:07] jam: oh, ok. sounds very similar :) [14:08] tych0: I was trying to go via ConnectInfo rather than DefaultConfig, "ubuntu". I was also looking at wiring up "daily" streams vs "released" streams, etc. [14:09] jam: yeah, always following Canonical, and here especially Juju news [14:10] jam: sure, it's not intended to be feature complete. mostly we want to deprecated lxd-images, so i'm trying to get you guys off of it before we do [14:11] jam: the lxd provider patch is a complaint from danwest, though [14:11] tych0: reviewed http://reviews.vapour.ws/r/4086/ [14:11] tych0: the thing I proposed? [14:11] The comment isn't on the github PR, can you elaborate? [14:12] tych0: anyway, I'm EOD now. if you want to send me an email, or maybe I can come back to chat in a couple hours. [14:13] jam: no, sorry, just one of the patches in the series about "lxd provider". nothing to do with what you proposed [14:14] tych0: k, I seem to be missing the context for that. I think I've heard some rumors about it, but I don't think I have any direct info. [14:15] jam: np. just wanted to clarify the seemingly unrelated patch [14:15] jam: i can switch it to have all the testing indirection. just seemed unecessarily complicated ot me when there aren't any actual tests :) [14:15] tych0: well, I've been slowly changing that [14:16] tych0: "seemingly unrelated patch", I haven't been able to find another patch [14:16] have a link? [14:17] https://github.com/tych0/juju/commit/3e13edaad7fd199d50b0f3f0b4b38a95c7c280ec [14:19] tych0: so we were certainly intending to go there, so I wouldn't consider it arbitrary [14:19] I appreciated that you did it. [14:20] I'm not 100% sure if that is the right time to do it, but it is certainly what we want. [14:20] jam: oh. what's the right itme? [14:20] tych0: I just haven't analyzed it [14:20] that may be the right time [14:21] the other option i suppose would be to do it when you launch an instance [14:21] vs. having two seperate call point sin the provider and the container type [14:21] tych0: well "bootstrap" *is* launching an instance [14:21] tych0: the very first one that we are putting teh agent into [14:21] yep [14:22] tych0: so eventually Juju will need to get much more nuanced in the cloud case about how it gets images, but for Local I think that's just fine. [14:23] jam: well, it's not local but lxd, but yeah, i think so. [14:24] tych0: IMO calling it "LXD provider" is not very good, because there are LXD instances in all clouds as well. but it is what it got called. [14:25] * tych0 closes the can of worms :) [14:35] jam: ok, just pushed a fix for your review comments [14:48] tych0: reviewed [14:49] man I wish we gave our db entries UUIDs. [14:50] natefinch: +1 [14:50] I wish we gave our db entries a relational db :p [14:50] that too :) [14:50] jam: r.e. the CopyImage thing [14:51] natefinch: don't have to be always v4, v3 or v5 are nice to have value based uuids [14:51] jam: i thought you wanted it there since it was supposed to be a complete interface? [14:51] jam: i've been deleting the unused ones as i come across them, happy to delete this one too [14:51] dimitern: I would appreciate if you could take another look over http://reviews.vapour.ws/r/4055/ [14:51] jam: but then i misunderstood the review request :) [14:51] perrito666: postgresql, can also handle json nicely [14:51] TheMue: I don't really care so long as I don't have to ever worry about duplication [14:52] natefinch: we needed ids based on namespace and input values, but still uuids. [14:54] TheMue: and we needed that because of the watchers, right? because all we get is the id [14:54] tych0: the point is to keep all of them, AIUI [14:55] tych0: we seem to be talking past eachother [14:55] jam: :) [14:55] jam: i just pushed a commit to delete CopyImage then, but i can revert it if you want [14:56] jam: just let me know what to do. [14:56] frobware, looking [14:56] tych0: Keep CopyImage in the interface [14:56] tych0: sorry [14:57] keep CopyImage in the client_raw interface, but I don't think we need it in the ListAliases interface [14:57] jam: ok, will do [14:57] jam: ah, i see [14:58] natefinch: hmm, always had my troubles with watchers. would like to see message queues here. but thats a big step. [15:00] frobware, one optional simplification, otherwise looks great [15:01] ericsnow, katco: https://github.com/juju/charmrepo/pull/65 [15:01] dimitern: done [15:01] jam: ok, i put the one back in client_raw [15:03] ericsnow, katco: I still need reviews on this: http://reviews.vapour.ws/r/4006/ [15:12] natefinch: like your argument. it's the cleaner interface [15:19] ericsnow: i know. so help me i will get to reviews today [15:24] lol "HEAD is now at b12bd10... aaaaahhhhhh godeps" [15:25] natefinch: laughing at your own commit message. classy. ;) [15:25] katco: haha... not exactly, laughing at how it looks when printed out in CI. [15:27] sinzui: abentley: why do we sed the version.go file in CI? [15:27] katco: they read the version of juju out of it [15:28] katco: I had renamed the version folder to jujuversion... then put it back, but it looks like it's not back in that branch [15:28] katco: We cannot test a release version. also packges need to know the version of the release tarfile. [15:28] sinzui: abentley: isn't there a better way to check the version than introspecting the code? seems like we're relying on an implementation detail [15:29] katco: we get code and need to make a tarfile form the source. we read files. This is also how ubuntu makes packages [15:29] You cannot build without first knowing the version [15:29] sinzui: oh, chicken and egg problem? [15:29] katco: I think you're running off the wrong branch... there's two branches... you want nate-minver from github.com/natefinch/juju [15:30] katco: yeah. it is awkward [15:30] sinzui: i'm sure, thanks for the pointers :) [15:30] katco: nate-minver has the version code back in /version fir exactly this reason [15:30] katco: once we know where to find the version, we can teach ci to look there and also update Ubuntu packaging to do the same. [15:30] natefinch: is that the only diff? [15:31] katco: mainly, yeah. Sorry... I forget why there are two minver branches... but definitely the one with /version is correct, specifically because it breaks CI otherwise. [15:37] katco: sorry.. this is all three months old in my head, so it's kinda dusty and full of cobwebs [15:38] natefinch: np we'll get it straightened out [15:41] katco: just to double check, creating the resources commands off the charm command is what I'm supposed to be working on, right? [15:42] natefinch: yeah, should be able to complete 2 of those cards today? [15:42] natefinch: doesn't matter which 2 [15:43] katco: I think so. just checking out the code now [16:07] natefinch: ? [16:07] katco: sorry, already off and running. it looks good. [16:07] natefinch: k, so 2 of the 1-point cards today? [16:08] natefinch: well, by tomorrow i mean [16:08] katco: yeah [16:08] natefinch: cool, ty! good work [16:08] katco: I haven't done it yet ;) [16:09] natefinch: on getting the previous card done despite bumps along the way :) [16:09] natefinch: also, eric needs a lot of reviews [16:09] katco: ahh, welcome :) [16:10] katco: oh... you know what, I've been watching reviewboard, but I forgot most of his now are elsewhere.... if nothing else, reviewboard is nice in that it makes it easy to keep tabs on what needs reviewing. [16:10] natefinch: yeah. i'd use our "under review" column as the index for this iteration [16:14] katco, ericsnow: can I make a suggestion? That we put links to the reviews right on the cards, so we don't have to go looking for them? In the main window of the card, in the lower right, there's a place for a link and a title for the link. You can then get to that link from the dropdown menu on the card under the "Link To" section. See my Validate file extension card for an example. [16:14] natefinch: fine with me [16:20] natefinch: yeah fine with me [16:31] katco: heh, it's Tuesday and we already have 13 points in the review queue [16:31] ..plus a bunch of unpointed stuff [16:31] natefinch: i know =| we're definitely not doing a great job of getting those things through. [16:32] ericsnow: hit me with some review links and I'll get to work. [16:33] katco: if there's a lot of code to review, it could cut into my coding time, but I'll try to get through it quickly. [16:33] natefinch: https://github.com/juju/charmrepo/pull/68 and https://github.com/juju/charmstore/pull/563 [16:34] natefinch: also http://reviews.vapour.ws/r/4090/ [16:35] about the only time i regret selecting an ultra-portable as my main work machine is when i deal with our tests. [16:35] ericsnow: looks like we duplicated some work on the resource data in the csclient API... essentially the same code though [16:36] the 8-core desktop it's sitting on is looking very tempting right now [16:36] katco: yep, that's why I went for a beastly machine [16:36] katco: ha, yeah [16:36] i'm just *compiling* our tests, not even running them [16:36] natefinch: hmm, the part in my PR wasn't on the list until last night [16:37] katco: ouch [16:39] ericsnow: for "Add an API data type for resources" ... you commented on my implementation of the same stuff a few days ago ;) [16:40] natefinch: classic [16:41] ericsnow: we're moving fast, I'm not surprised we'd get confused. [16:45] ericsnow: I like my implementation 10% better, but yours has standalone tests (mine is tested implicitly when testing the code that uses it)... tough call. [16:45] natefinch: I just copied and pasted from our API code :) [16:47] ericsnow: btw, my PR with similar code: https://github.com/juju/charmrepo/pull/65 [17:36] katco, ericsnow, natefinch is there a way to specify a different bridge for the lxd provider? [17:36] cherylj: probably in the lxd config for juju. tych0? [17:37] i think it's hardcoded maybe [17:37] katco: how do you specify the lxd config? [17:37] cherylj: it's created for you, it's specific to juju [17:37] oh [17:37] right, no, it's not hard coded [17:37] cherylj: i don't think you can specify which config [17:38] there's no way to set it from juju, you can change the default lxd profile, though [17:38] thanks, katco, tych0! [17:38] cherylj, this is work that overlaps with what sapphire is doing on multi-nic support for lxd I believe [17:39] for future reference [17:39] ok, thanks alexisb [17:57] cherylj: you can do this by editing the profile, or creating a new "bridged" profile and applying that to the container. [17:57] thanks, frobware! [17:58] cherylj: I'm uncomfortable landing the change for bug# 1549545 tonight - needs some live testing post my changes today. [17:58] frobware: want me to help out? [17:58] cherylj: if you're happy to test my branch again, that would certainly help. [17:59] frobware: okay, I can give it a go. Is everything in the PR? Could I just apply that patch? [17:59] cherylj: there's potentially additional unit testing that can be done, but trying to weight the effort up because this will be a temporary change until we land maas-spaces2 [18:00] frobware: understood. It's also the last fix we're waiting on to ship beta2 [18:01] cherylj: yep [18:01] cherylj: the new function is tested, there's no unit test case for the case where an instance does not have a Gateway address - that change is much larger. [18:02] cherylj: so it has been reviewed, and live tested by you. A further confirmation would help to ensure that the small changes to the core functionality have broken its liveness. At that point you could choose to $$merge$$ [18:02] s/have broken/have NOT broken/ Gah! [18:03] frobware: okay, I will test it with bootstrap / deploy node / deploy container on multi-NIC node on trusty, wily and xenial (daily) today [18:03] cherylj: thanks. I have to run soon. [18:04] frobware: np. If my testing is good, I'll plan to $$merge$$ it for you. Good? [18:04] cherylj: I'm guessing that if you're trying xenial you'll also be using daily images for trusty and wily. [18:04] frobware: yes [18:04] cherylj: yep, good! [18:04] but I do have my 2nd maas on 1.9.1 now, so I could do concurrent testing with daily and released [18:04] cherylj: you're ahead of the curve. :) [18:04] sweet [18:06] natefinch: FYI, I've reviewed all your patches [18:19] ericsnow: thanks! [19:07] katco: ug... the charm command has its own wrapper for the csclient.Client type [19:07] natefinch: >.< [19:07] natefinch: what does the wrapper do? [19:09] katco: auth stuff.. [19:12] natefinch: ah, so that's the stuff we talked about pulling into charmrepo.CharmClient? [19:14] katco: yes... didn't really think about that as part of this card [19:14] natefinch: i think we talked about you doing a follow-up overhead card to the card you just completed [19:15] natefinch: but if you need it now, just go ahead and do it and leave a comment in the card you're working on [19:16] natefinch: so how would you like to proceed on our two patches that have params.Resource? [19:17] natefinch: FYI, it's a blocker for my charmstore PR [19:17] katco: yeah. I have to do it first. I have push resource 2/3rds done, except it can't call the charmrepo.CharmStore since everything here is set up to use this csClient type. [19:17] ericsnow: yeah, everything blocks everything else :) [19:17] ericsnow: at least the non juju/juju repos build and test super fast [19:18] natefinch: (╯°□°)╯︵ ┻━┻ [19:18] i dream of a day when core is like that [19:18] katco: yep [19:18] it would be so amazing if we had a complete suite of unit tests [19:18] run in a few seconds [19:18] le'sigh [19:18] katco: have you seen this? https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o [19:19] ericsnow: just land yours, it's fine. I'll tweak mine to comlpy [19:19] comply [19:19] natefinch: yeah i have [19:19] Bug #1554675 opened: Unable to bootstrap lxd provider on s390x

[19:20] natefinch: that took 10s to load bc my machine is under load from compiling. irony +1 [19:20] katco: lol try running a hangout at the same tine. you'll basically be reduced to smoke signals [19:21] natefinch: can't land without LGTM from uiteam and they're all EOD [19:21] katco: luckily, your CPU will be producing plenty of that ;) [19:22] ericsnow: boo [19:22] ericsnow: you get +1 from this side of the ocean? [19:22] rick_h__: from natefinch [19:22] ericsnow: k, so should have code fairy in the AM then hopefully [19:24] natefinch: could you throw a LGTM on that PR just so folks can see it? https://github.com/juju/charmrepo/pull/68 [19:31] natefinch: thanks [19:32] ericsnow: natefinch: hey so just talked with rick_h__ [19:33] natefinch: you don't have to support the publish flag on charm push [19:33] natefinch: further, where we were previously planning on erroring out if you try and push without all resources defined, we should allow that, but on the charm publish command, error out if not all resources are a) provided with the resource flag or b) have any revision avail [19:34] natefinch: i'll update the user stories so that's crystal clear [19:34] ericsnow: natefinch: questions? [19:35] katco: funny, that's the way I thought we were going to do it already :) [19:36]