/srv/irclogs.ubuntu.com/2016/03/11/#juju-dev.txt

wallyworldaxw: when you get a chance, no rush, a small tweak to series validation. i'll then update dep in the master pr https://github.com/juju/charm/pull/19800:25
davecheneythumper: https://github.com/juju/juju/pull/468800:40
* thumper looks00:41
davecheneyi tried a few ways yesterday to merge these two handlers into one00:41
davecheneybut as the one from api/private/server comes with a compelte implementation of a python mocking framework00:41
davecheneyit was infeasable00:41
davecheneythis is a smaller change which does the same thing00:41
davecheneyand the author of the original code will have to figure out how to merge the two types00:41
thumperdavecheney: change looks good +100:45
davecheneythumper: ta00:46
thumperhmm... third time today I've hit bad record mac trying to land things01:13
thumperwallyworld: can you meet early?01:16
wallyworldthumper: sure, give me a couple of minutes01:16
thumperok01:16
natefinchevening all01:24
alexisbevening natefinch01:28
katconatefinch: kiddo feeling any better?01:28
natefinchkatco: not really... she's only had water & pedialyte since 6pm last night, and threw up even the water just before bed tonight.  But that's only #3 since 8am, so I'll take it over last night, for sure.01:29
katconatefinch: jees :(01:30
natefinchkatco: my wife is slightly better off... she's managed to have, I think, two crackers, besides various liquids since around 8pm last night.   Crazy bad virus.01:31
alexisbnatefinch, that sounds terrible :(01:32
natefinchalexisb: OMG, it was horrible.  We had to call our babysitter at 10pm to come help with the baby until about 3am when my wife was finally able to get off the bathroom floor and be in the bedroom.01:34
alexisb:(01:35
natefinchworst ever, and we've had some bad ones.01:35
* alexisb wishes she had gofmt for 'c' in her kernel days01:43
natefinchtiotally... man, I remember having autoformat wars at my last job... if you didn't configure your autoformatter exactly right, every time you commit your stuff, you reformatted the code to be slightly differently.  Another guy on my team kept doing that... the aggravating thing was that he didn't notice, which made me really wonder if he even looked at what he was checking in.01:45
natefinchkatco: ericsnow left a comment on my charmrepo PR about this needing to get merged into the new-channels-model branch.  Should I just PR this against that branch as well?  ref: https://github.com/juju/charmrepo/pull/6501:47
natefinchkatco: just landed that 3 pointer in charmrepo.v2 (master)01:59
davecheneythumper, menn0: https://github.com/juju/juju/pull/469102:12
davecheneyfollowup from previous CL02:12
menn0davecheney: thumper is about to drive up to Christchurch so i'll do it02:12
davecheneyta02:13
davecheneythis is more refactoring to remove the apisever/common dependency from the resource/api02:13
davecheneybecause apiserver imports resource/api02:13
davecheneyso if I want to move apiserver/common.ServerError to apiserver02:13
davecheneyi need to break that import loop02:13
davecheneyand i want to move apiserver/common.ServerErr to apiserver to pay down the technical debt from the UpgradeInProgress refactor02:14
cheryljmenn0: ping?02:39
menn0cherylj: howdy02:40
cheryljmenn0: hey there, wanted to pick your brain on this mongo problem02:41
cheryljso we had mario run mgopurge02:41
cheryljand we told it to skip objects with an invalid token02:41
cheryljbut I was wondering...  do those need to get cleaned up anyhow?02:42
cheryljsome how?02:42
menn0cherylj: yeah, i was going to reply to that email thread today but have been flat out02:42
cheryljwe're panicking in the same sort of way now in jujud - the token is invalid02:42
menn0cherylj: are the bad txn tokens in the txn-queue field?02:43
menn0cherylj: if so, yes they'll need to be removed. I kind thought that's what we were getting mgopurge to do but I could be misremembering02:43
cheryljmenn0: that's what I'm wondering / thinking.  I haven't downloaded the db yet to look02:43
menn0cherylj: seems likely if that's the case02:43
menn0cherylj: mgo/txn will be trying to look up those txns, failing to find them and panicking02:44
cheryljmenn0: but what I added in to prevent mgopurge from panicking was just to skip those transactions02:44
menn0cherylj: I was going to say on the email that they should get the replicaset healthy *before* trying to fix anything else02:44
cheryljmaybe there's something else I need to add which removes them from the queue02:44
cheryljmenn0: it sounds like they've done that02:45
menn0cherylj: he said that 2 out of the 3 nodes are ok02:45
menn0cherylj: that's not healthy02:45
menn0cherylj: they should get that 3rd node happy again first02:45
cheryljmenn0: ah, gotcha02:45
cheryljmenn0: I can ask Mario to do that02:46
menn0cherylj: and it sounds like making mgopurge remove the bad txn tokens needs to happen too02:47
menn0cherylj: a bad/empty token should just be treated the same as a missing txn02:47
cheryljmenn0: yeah, that's what I was thinking.  I'll take a closer look at the PurgeMissing code02:47
menn0cherylj: the same logic that removes missing txns from the txn-queue field can then be used to remove the bad ones too02:47
cheryljbleh this mgo stuff is hard to read02:51
katconatefinch: i'd say just master and they an bug us if the merge conflicts are too bad03:08
axwwallyworld: charm change LGTM03:20
wallyworldtyvm03:21
=== akhavr1 is now known as akhavr
axwwallyworld: adding cloud name, etc. to controllers.yaml doesn't really work :/   if you did "juju register", we've got nowhere to pull that information from03:48
axwwallyworld: so I think it goes back into bootstrap-config.yaml, and we cross-reference that in list-controllers03:48
wallyworldaxw: ok, let's go with that; we can be clear about the limitations. the only other option i guess it to make an api call03:52
rick_h__axw: is this for the provider type info?03:52
axwwallyworld: IMO that's out of the question03:53
wallyworldyeah, agreed, was just making sure we covered all options03:53
axwrick_h__: sorta. it's for that, plus the bits we need to kill-controller if the controller is dead03:53
axwrick_h__: we could store the provider type easily, but the other information not so much03:53
rick_h__axw: ah ok, for the provider type user query I'd hope we could put that in the show-controller metadata03:53
rick_h__axw: gotcha03:53
rick_h__axw: yea, /me didn't catch the rest of the convo for the kill-controller link03:54
axwrick_h__: two birds, one stone :)03:54
rick_h__axw: yea, but let's make sure they're both birds and not one moose and one bird03:54
axw;)03:54
rick_h__no thumper? curses03:55
menn0rick_h__: thumper is driving up to christchurch (where I live). he's taking his kids to a convention up here.04:16
menn0rick_h__: can I help at all?04:16
=== menn0 is now known as menn0-afk
axwwallyworld: just thinking out loud... we could forget about storing the credential label/origin, and just auto-detect and use whatever it returns, like at bootstrap04:36
axwwallyworld: and if none auto-detected, say something like "no credentials detected". I guess the origin is still useful though...04:37
axwwallyworld: (just trying to minimise surface for such a corner case)04:38
wallyworldaxw: sorry, was out with anastasia talking lxd image caching. yeah, we went around and around on minimising the serface for the corner case didn't we. but the idea of storing the label/origin is so that if we autodetected the wrong credentials, we could prompt for the correct ones05:24
wallyworldbut is the effort worth it05:24
axwwallyworld: yeah, I suppose so. I'll add it later, doing the minimal work for now to support lxd05:24
wallyworldsgtm. i don't think it's that much extra to store the label/origin, let's take a view once things have settled a bit05:25
TheMuemorning o/08:00
mupBug #1555969 opened: API server stops responding after juju add-unit <juju-core:Triaged> <https://launchpad.net/bugs/1555969>08:10
axwwallyworld: if you're around later and feel like looking, here's the WIP: https://github.com/juju/juju/compare/admin-controller-model...axw:bootstrapconfig-partial-ondemand08:21
axwwallyworld: all working, lots of tests to update now.08:22
frobwarevoidspace: did this (http://reviews.vapour.ws/r/3955/) get back into master?09:12
voidspacefrobware: well, the code it was changing wasn't on master I don't think09:13
voidspacefrobware: I can have a look09:14
voidspacefrobware: the subnetToSpaceIds function it changes doesn't exist on current master09:15
dimiternfrobware, hey, I've realized I gave you bad advice yesterday wrt dependencies.tsv :/09:15
=== menn0-afk is now known as menn0
frobwaredimitern: so let's fix it before we merge to master09:15
dimiternfrobware, those imports which were removed with the master merge caused issues on windows09:15
frobwaredimitern: I was looking at the report09:16
dimiternfrobware, yeah, I suppose just adding back the missing ones will fix 3 of the curses09:16
frobwaredimitern: can I just merge in what I had done?09:16
frobwareoriginally09:16
menn0fwereade__: i'm aiming to review your model agent integration PR soon09:16
dimiternfrobware, I'd try to use GOOS=windows godeps -N ... as suggested in the linked bug report09:16
frobwarevoidspace: if we're going to get maas-spaces2 into master next week we can wait till then09:16
frobwarevoidspace: I was just curious if you ported that single fix into master. I guess not because it was only broken on maas-spaces209:17
voidspacefrobware: right, it *couldn't* be ported to master...09:18
dimiterndooferlad, hey, I see getMongoSpace changes caused a data race in the last CI run09:22
dooferladdimitern: really? Grr.09:22
dimiterndooferlad, can you have a look at that? http://reports.vapour.ws/releases/3735/job/run-unit-tests-race/attempt/1095#highlight09:22
dooferladdimitern: on it09:23
dimiterndooferlad, cheers09:23
fwereade__menn0, <309:23
fwereade__menn0, I recommend ignoring everything under worker/dependendency; core/life; and all the */lifeflag bits09:24
fwereade__menn0, because I can and will extract those09:24
menn0fwereade__: ok will do09:24
dimiternfrobware, in my experiments yesterday I found this quick hack significantly reduces the initial boot time: http://paste.ubuntu.com/15346394/09:25
dimiternfrobware, ~2m (average) from allocated to deployed09:26
frobwaredimitern: the bridge wait I understand, the ntp is a step too far...09:41
dimiternfrobware, that's because of the race I was telling you about when trying to ifup a lot of static interfaces09:43
dimiternfrobware, I was seeing 4-5 bash instances trying to run ntpdata and getting blocked on trying to create a lockfile09:44
frobwaredimitern: I'm going to try an experiment with a one-time reboot post our butchering of eni09:47
frobwaredimitern: but somewhat secondary to getting the devices work done09:47
dimiternfrobware, I tried that as well - depending on when you reboot, it might not work at all - e.g. before installing bridge-utils09:48
dimiternfrobware, agreed09:48
frobwaredimitern: the bridge-utils is a pre-req so is already present before we run the script09:48
dimiternfrobware, yeah, that's assuming we got the chance to even run apt-get install bridge-utils09:49
dimiternfrobware, which will happen after the bridge script completes09:49
frobwaredimitern: it happens the other way round.09:56
frobwaredimitern: our script would fail catastrophically if it wasn't present09:56
frobwaredimitern: you can see this if you deploy from MAAS, cp the script, and run it. the whole thing fails because there is no brctl09:57
dimiternfrobware, that's what I'm talking about :)09:59
dimiternfrobware, since the script runs as a bootcmd, it will run before any packages listed in the generated userdata are installed..09:59
frobwaredimitern: I was confused. you said "after the bridge script completes"09:59
dimiternfrobware, hmm.. I might be wrong - just observed something like that10:00
frobwaredimitern: there is no way we could bring the interface up without bridge-utils being there10:01
frobwaredimitern, voidspace, dooferlad: standup/planning10:01
voidspacefrobware: omw10:02
menn0fwereade__: review done. lots of great stuff. thank you. it will be great to get this landed.10:51
dimiternfrobware, this is the gist of what's needed: http://paste.ubuntu.com/15346665/, and those API calls follow the pattern in http://paste.ubuntu.com/15241590/10:53
* menn0 bed10:53
dimiternfrobware, so if we agree on the interface, I can use a stub for now, and later we integrate10:55
dimiternfrobware, let me know what you think10:56
frobwaredimitern: will look in a bit10:59
frobwaredimitern: I don't see a great deal of diff with your godeps incantation; https://pastebin.canonical.com/151643/11:03
dimiternfrobware, that's exactly the missing import causing the curse11:05
frobwaredimitern: :) yes, just read the bug.11:05
dimiternfrobware, well, now we know what this package is for :)11:06
frobwaredimitern: so another alternative is that we merge from master again this morning11:06
frobwaredimitern: we would get that ^^ for free11:06
dimiternfrobware, also works, and will give us updated lxd stuff as a benefit11:08
frobwaredimitern: right, I'll do that instead.11:08
dimiternfrobware, however, that should be followed up by dooferlad's fix not long after the merge lands in order not to waste a CI run11:09
frobwaredimitern: good point11:09
frobwaredimitern: can we HO re: the godeps stuff again. as in what's the best way to merge and or update it11:13
dimiternfrobware, ok11:13
dimiternfrobware, I'm in the sapphire HO (last one we used)11:14
dooferladdimitern / frobware / voidspace: http://reviews.vapour.ws/r/4132/ fixes those races.11:55
dimiterndooferlad, looking11:57
dimiterndooferlad, did you run the test with -race?11:59
dooferladyes11:59
dimiterndooferlad, so the issue is easy to reproduce and verify the fix12:00
dimiterndooferlad, LGTM, thanks that was quick :)12:01
dooferladdimitern: yea, just running the tests with -race showed it and then it was just a moment of "oh crumbs, that was dumb"12:01
dimitern:)12:02
frobwaredooferlad: we should try and land the changes close together; just running make check on my merge from master and will propose12:02
dooferladfrobware: I hit $$merge$$ about two seconds before you said that.12:02
frobwarec'est la view12:03
frobwarevie...12:03
dooferladfrobware: it will take some time to test, so as long as we get to reviewing your code soon we will be fine.12:03
frobwaredimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4133/ -- merge master into maas-spaces212:32
voidspacefrobware: did you land one yesterday?12:32
frobwarevoidspace: yes12:32
voidspacefrobware: ah yes, this one isn't as huge12:32
voidspacefrobware: go for it12:32
frobwarevoidspace: that commit was also a blessed build.12:32
frobwarevoidspace: if there's one thing to look at its dependencies.txt12:33
frobwarevoidspace: I meant dependencies.tsv12:33
voidspacefrobware: yeah, I looked - LGTM12:34
voidspacefrobware: although we seem to be depending on stuff in people's own github repositories now12:34
dimiternfrobware, looks good12:34
dimiterndooferlad, your fix should merge cleanly onto frobware's merge PR right?12:35
frobwaredimitern: going to grab some lunch and then let's do devices... \o/12:41
dimiternfrobware, sweet!12:41
frobwaredimitern, voidspace, dooferlad: both merged. we should, in theory, get a blessed CI run now.13:05
dimiternfrobware, let's hope we do :)13:07
rogpeppe2natefinch: ping13:13
=== rogpeppe2 is now known as rogpeppe
frobwaredimitern: whenever works for you let's sync13:31
dimiternfrobware, in 15m ?13:31
frobwareyep13:32
dimiternfrobware, let's use the standup HO?14:00
dimiternfrobware, well, last one we used anyway14:01
frobwareok14:01
natefinchrogpeppe: pong14:24
mattywfwereade__, ping?14:27
mupBug #1556113 opened: TestCleaner should have fired by now <ci> <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1556113>14:35
mupBug #1556116 opened: TestDeployBundleMachinesUnitsPlacement mismatch <ci> <gccgo> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces2:Triaged> <https://launchpad.net/bugs/1556116>14:35
fwereade__mattyw, heyhey14:36
mupBug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>14:50
natefinchericsnow: let me know if you need help with that cards you took over from me14:59
mupBug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>15:02
mupBug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>15:05
mattywericsnow, ping?15:13
mattywericsnow, do you know if the todo comment at the top of this file is currently being worked on? https://github.com/juju/juju/blob/master/cmd/juju/charmcmd/store.go15:13
* ericsnow takes a look15:14
ericsnowmattyw: not really15:15
mattywericsnow, ok that's fine, I might have to end up doing some of it for the stuff I'm working on, wanted to make sure I wasn't going to be duplicating work15:15
ericsnowmattyw: I have a patch that accomplishes that but haven't had a chance to pursue landing it15:15
mattywericsnow, i'd be interested in seeing that if possible15:16
ericsnowmattyw: k, thanks for the heads up15:16
ericsnowmattyw: looking it up as we speak15:16
mattywericsnow, many thanks15:16
ericsnowmattyw: pretty sure this is the branch: https://github.com/ericsnowcurrently/juju/tree/resources-charmstore-client15:22
ericsnowmattyw: it isn't quite right at this point, but the key thing is the httpcontext package15:22
ericsnowmattyw: however, it looks like the new "charm" command would use it too, so it may make more sense in some other common repo15:23
ericsnownatefinch: #155614615:29
mupBug #1556146: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>15:29
ericsnownatefinch: bug #155614615:29
mupBug #1497801 changed: provider/joyent: data races <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1497801>15:29
mupBug #1461961 opened: UniterSuite teardown fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1461961>15:29
mupBug #1556146 opened: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>15:29
katcoericsnow: natefinch: planning time15:32
mattywericsnow, thanks, I'll take a look15:34
mupBug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>15:39
mupBug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>15:39
mupBug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>15:48
mupBug #1556155 changed: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>15:48
=== benji is now known as Guest47292
mupBug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>16:00
mupBug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>16:00
natefinchericsnow: review a single character bug fix? http://reviews.vapour.ws/r/4135/diff/#16:03
mupBug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Invalid> <juju-core maas-spaces2:Fix Committed by dooferlad> <https://launchpad.net/bugs/1556152>16:09
mupBug # opened: 1556153, 1556157, 1556161, 1556167, 155617116:09
HollyRaindoes the Juju license is going to change? the issue is that at using a library like "juju/service", it does that all my code been AGPL16:31
natefinchHollyRain: very doubtful that the license will change16:31
HollyRainnatefinch, well, at least there is an alternative to handle services: kardianos/service16:33
HollyRainin github.com16:33
natefinchHollyRain: if you mean github.com/juju/juju/service - anything under github.com/juju/juju is not really intended to be used as a general library16:36
HollyRainok16:36
mupBug #1556176 opened: TestCmdLine dial unix no such file or directory <ci> <go1.5> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556176>16:39
mupBug #1556180 opened: MachineSuite.TestManageModelRunsRegisteredWorkers mismatch <go1.5> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556180>16:39
mupBug #1556183 opened: help text for list-controllers needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556183>16:39
frobwarecherylj: ping16:51
cheryljfrobware: in stand up, responses will be slow :)16:52
frobwarevoidspace: you still about?17:16
voidspacefrobware: yup17:19
frobwarevoidspace: any joy with MAAS 2.0? I didn't get around to installing...17:19
voidspacefrobware: not yet, recloning my vm and installing xenial - about to install a newer version of maas (different ppa) that may fix the bug17:20
voidspacefrobware: did some diagnostic work with roaksoax and he thinks it might be fixed in this version17:20
mupBug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>17:27
mupBug #1556207 changed: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>17:30
frobwarecherylj: we've made sure that maas-spaces2 is up to date w.r.t to master. if we get a clean CI build on maas-spaces2 we'd like to merge into master and continue the multi-NIC and MAAS 2.0 work elsewhere. Is master still locked down?17:31
cheryljfrobware: yes, we want to merge perrito666's machine-provisioning-status before we unblock17:33
cheryljfrobware: if your branch is ready, we can put it on the list to get shepherded in next17:33
frobwarecherylj: waiting to see if the couple of fixes we did today give us a blessed CI run; should find out a bit later.17:34
cheryljfrobware: okay, cool.  I'll keep an eye on it17:37
mupBug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>17:42
katcosinzui: hey, is this a spurious curse? http://reports.vapour.ws/releases#nate-minver18:24
sinzuikatco: maybe. The lack of bless might be because the branch makes juju less reliable. The azure arm-bundle looks interesting. I can retest it18:31
natefinchspurious curse is the name of my goth metal band18:32
katcosinzui: thanks, i would appreciate it. i don't think there should be anything in there that would cause it to be less reliable18:32
katcosinzui: but appreciate your more informed opinion18:32
mupBug #1556238 opened: Missing a Juju shell <juju-core:New> <https://launchpad.net/bugs/1556238>18:42
mupBug #1556249 opened: help text for juju list-models needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556249>19:18
=== ericsnow is now known as ericsnow_afk
mupBug #1556252 opened: help text for juju show-user needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556252>19:48
marcoceppisinzui: is juju2 the name of the binary going forward?20:15
marcoceppiI noticed juju-core and juju are no longer listed and installing juju2 removes them20:15
natefinchmarcoceppi: it's a vast underworld conspiracy20:21
marcoceppiwell, it breaks the new charm and charm-tools command20:28
marcoceppiso I'd just like to align those packages20:28
marcoceppiit also means we can't install 1.25 and 2.0 sidebyside which completely kills this blog post from last week20:29
marcoceppihttp://marcoceppi.com/2016/03/testing-juju-without-wrecking-juju/20:29
marcoceppioh, jk, it doesn't break juju-core, just juju-core220:30
natefinchmarcoceppi: I'm 99% sure that we are supposed to be able to run them side by side.  WE've done a lot of work to enable that.20:30
marcoceppiI'm actually okay with that20:30
marcoceppiI'll jus tneed to update the packaging for charm and charm-tools20:30
natefinchmarcoceppi: I think it's juju-core and juju (the latter being juju 2)20:31
natefinchmarcoceppi: but I am certainly not the authority on these things20:31
marcoceppinatefinch: I upgraded and both versions are still there, I jus tneed to update the other packaging20:31
natefinchrick_h__, katco: charm publish --channel=stable cs:rabbit-22 --resources "foo-6 bar-3" ... this command seems to require that resource names not have spaces in them, in order to parse them in a single string like that.  Do we want to start to enforce that, or should we change this to be --resource foo-3 --resource bar-6?  or some third way?20:33
katconatefinch: yes, separate flags to mirror deploy20:34
katconatefinch: check out rick_h__ 's comment in the 1-pager20:34
natefinchkatco: awesome.  I love consistency20:34
katco+120:34
marcoceppiomg I just bootstrapped lxd \o/20:39
natefinchmarcoceppi: huzzah20:41
natefinchkatco: I kinda wish that for publish, it was --resource foo=3 --resource foo=5 ... but I understand that we're trying to make them like charm revisions, where it's part of the name20:57
natefinchs/foo=5/bar=520:57
katconatefinch: yeah, i prefer = as well20:58
katconatefinch: but, precedent and all20:58
katconatefinch: ericsnow_afk: we don't need to do a standup21:05
=== ericsnow_afk is now known as ericsnow
ericsnowkatco: k21:05
sinzuimarco yes, juju2 is the package name. juju2 is also the name of binary.21:13
sinzuimarcoceppi: if you havw juju-core and juju2 installed, you can use alternates to switch which Juju is /usr/bin/juju21:13
marcoceppisinzui: right, it's just that juju2 removes some packages, including charm and charm-tools21:14
sinzuimarcoceppi: it does? how?21:15
natefinchmarcoceppi: hmm, that seems wrong.  It definitely shouldn't *remove* anything21:15
sinzuimarcoceppi: a package cannot remove another package and it is intended to be co-installable.21:15
perrito666sinzui: cant a deb remove another if it is marked as conflicts or replaces?21:16
marcoceppiperrito666: yes21:16
sinzuiperrito666: yes, replaces, but we don't use that. conflicts blocks and lets a user choose21:16
marcoceppisinzui: juju2 removed juju which are depends on charm and charm-tools21:16
perrito666sinzui: I would re-check the package definition given what marcoceppi says21:17
sinzuimarcoceppi: oh, I can remove that metapackage. we don't need it21:17
marcoceppisinzui: which metapackage?21:17
sinzuijuju is a metapackage marcoceppi. It hasn't been a real package in 4 years21:17
natefinchmarcoceppi: welcome.... to the real world21:18
perrito666oh that is right, juju is to pull juju-core and juju-local right?21:18
marcoceppisinzui: I know. but charm-tools, amulet, etc, depend on Juju21:18
sinzuiright, and juju2 is really just juju2 now. no other deps21:18
sinzuimarcoceppi: I think we need to drop the juju metapackage from the juju2 package. two source packages cannot provide it an be co-installable21:19
natefinchmarcoceppi: what do charm-tools and amulet etc need from the juju package that isn't in core?21:20
sinzuimarcoceppi: juju2 source package coul provide juju2-all or juju2-dev to get the authoring tools21:20
* sinzui likes juju2-authors more than juju2-dev21:20
marcoceppiwe just need juju installed whenever a user installs these tools21:20
sinzuimarcoceppi: which juju needs to be install when someone installs those tools? if so, then shouldn't those package depend on juju-core or juju2?21:21
marcoceppiwell either juju is fine21:21
marcoceppijust a juju21:21
natefinchmarcoceppi: why do those tools need juju?21:21
marcoceppihence the metapackage21:21
marcoceppiwell, it's not a depends21:21
marcoceppiit's a Recommends21:22
marcoceppithe idea being that multiple things can provide a juju, so I'm just going to have it Recommend: juju2 || juju21:22
sinzuimarcoceppi: the juju-core package we put in the ppa:juju/stable doesn't have a recommends or depends on amulet charm-tools. maybe the Ubuntu version of the package does21:25
marcoceppisinzui:21:29
marcoceppino amulet and charm-tools and charm recommends juju21:29
marcoceppithat way if you install them, you21:29
marcoceppi'll get juju21:30
marcoceppiwell, amulet depends on juju, the rest recommend it21:30
sinzuimarcoceppi: okay, so amulet could "Depends: juju2 | juju-local"21:31
marcoceppiwhy juju-local? you mean juju-core?21:31
sinzuimarcoceppi: yes, juju-core is fine for 1.x. I just assumed that a charm author would want local-provider21:32
natefinchOMG, so glad we dumped local provider for 2.021:33
sinzuimarcoceppi: I can add a metapackage to the new juju2 source package to install everything you think a charm-author needs.21:33
sinzuinatefinch: \o/21:33
sinzuiWe can take half a day and close 200 bugs21:33
sinzuimarcoceppi: also, we don't need to wait for the next release to remake the juju2 package to provide a metapackage for authors21:34
ericsnownatefinch: http://reviews.vapour.ws/r/4138/21:35
marcoceppisinzui: well, I think juju2 should recommend the charm command21:36
marcoceppisinzui: and charm depends on charm-tools21:36
marcoceppiand that'll all work21:36
sinzuimarcoceppi: as in the charm package I see sitting in ppa:juju/devel... "Recommends: charm"21:39
natefinchwhat's the user-experience for "recommended" packages?21:40
sinzuinatefinch: it will be installed, if it exists21:40
natefinchsinzui: so we're forcing every user of juju to install charm authorship tools?21:40
sinzuinatefinch: the user can specify not to install recommends21:40
sinzuinatefinch: I most often use recommends for cases where we know older ubuntu series don't have the optional package21:41
natefinchsinzui: I don't really see why juju would ever recommend charm authorship tools.  charm authors, in theory, should be like .1% or less of juju users21:42
sinzuinatefinch: yeah, that is why I suggested a metapackage names charm-authors to be clear who wants the extra packages21:42
natefinchsinzui: agreed21:42
natefinchericsnow: looking21:43
natefinchericsnow: btw, thanks for tackling that..sorry you got burdened with the result of my misunderstanding.21:44
ericsnownatefinch: glad to do it21:44
ericsnownatefinch: it's all complicated by our usual high-coupling/low-encapsulation21:45
natefinchericsnow: seems like we could use an AuthorizedCharm struct or something, that holds a CharmURL + macaroom21:48
ericsnownatefinch: I was totally thinking that the whole time :/21:48
natefinchericsnow: or even slap a macaroom on the charm.URL struct21:48
ericsnownatefinch: yep21:48
natefinchblah21:49
sinzuiperrito666: machine-provisioning-staus branch is merge21:58
perrito666sinzui: oh, you just made my weekend21:58
natefinchericsnow: only had time for a half a review, sorry.  I'll finish up the rest later tonight.22:00
natefinchericsnow: mostly looks good, just didn't get through it all.22:00
ericsnownatefinch: np22:01
ericsnownatefinch: thanks22:01
=== natefinch is now known as natefinch-afk
mupBug #1556293 opened: Invalid volume ID <ci> <destroy-environment> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1556293>22:25
alexisbanyone know how I make this go away:22:31
alexisbchecking: go vet ...22:31
alexisbtools/lxdclient/client_instance.go:329: wrong number of args for format in Tracef call: 1 needed but 2 args22:31
alexisbI can build and run locally on my machine22:32
katcoalexisb: what version of go are you compiling with locally?22:32
alexisb1.6rc222:33
katcoalexisb: and CI is giving you this error?22:34
perrito666katco: I had the same22:35
perrito666alexisb: its a vet issue introduced by jam22:35
alexisbso I can build locally but the "go vet" check in the prepush script is failing22:35
alexisbperrito666, ah ok22:35
alexisbI will follow-up with him22:35
perrito666alexisb: just go to that line and delete the second argument to the Tracef22:36
katcoalexisb: ah... yeah vet is separate than building, but it's probably because CI is using a different version of go than you22:36
perrito666katco: is CI running vet?22:36
katcoalexisb: they change how vet works between versions sometimes22:36
katcoperrito666: it should be22:36
katcoperrito666: that should be blocking imo22:36
katcoperrito666: and i thought it was22:36
perrito666katco: me too22:36
perrito666but apparently it isnt22:36
katcoperrito666: i think it is, and CI is just using an older version of go22:37
katcoperrito666: thus, the change jam made is fine22:37
perrito666katco: I thought go vet was catching that before22:37
perrito666odd22:37
perrito666in any case, it breaks with go 1.522:37
katcoperrito666: ci is building with 1.2.1 still22:38
katcoalexisb: perrito666: lots o' things have changed between 1.2.1 and 1.5, let alone 1.6r222:38
alexisbkatco, not for 2.022:38
perrito666that explains22:38
alexisbfor trusty we build with 1.2.1, until 1.6 is officially in updates22:39
alexisbthat did it perrito66622:39
katcoalexisb: i think our CI workers are still using 1.2.1. sinzui can you comment?22:39
katcoalexisb: i.e. the workers that $$merge$$ changes22:39
sinzuikatco: oh, the merge job is using a trusty ami, so it is using go 1.2.122:40
perrito666sinzui: mm, that is wrong for 2.022:40
katcoalexisb: ^^^ hence, go vet change made it in, but is incompatible with go1.6-r222:40
sinzuikatco: The release agreed to switch to ggo 1.6 nexgt week22:40
sinzuiand that that time, we expect master to be blocked as we fix bugs22:41
sinzuikatco: the merge job nor Juju's one Makefile does not specific how to install a version of go on a temporary instance in AWS. It gets the version from the Ubuntu release. so switching to xenial images will select golang (2:1.6-0ubuntu3)22:45
katcosinzui: understood, and that sounds correct. just trying to inform alexisb22:47
katcosinzui: by the by, how goes the retest of nate-minver?22:48
sinzuikatco: it failed? but I am looking to it still as a substrate issue the same bundle passed on other substrates22:49
katcosinzui: oh, i thought you were going to retest with a higher timeout? does this mean we can merge into master?22:49
sinzuikatco: I did  and we still timeout22:50
katcosinzui: ah ok. what do i need to do to get it landed into master? just wait for you guys to work your magic?22:51
sinzuikatco: If am hoping to retest and provide good results, or find some reason why the banch fails22:51
katcosinzui: ok, when will you know more?22:52
sinzuimaybe by morning. katco.22:52
katcook ta sinzui22:53
alexisbsinzui, thanks for pushing hard to get releases out this week, have a great weekend!23:01
sinzuithank you alexis. you too23:02
mupBug #1551276 changed: 2.0-beta2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1551276>23:31
=== ses is now known as Guest4655

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!