thumperwallyworld: quick call then00:00
thumperwallyworld: 1:1 ?00:00
wallyworldthumper: didn't you notice the sarcasm?00:00
thumperwallyworld: I actually thought that you were looking forward to working00:00
rick_h_wallyworld: :p00:17
wallyworldrick_h_: living the dream once again, wheeeeee00:18
rick_h_hey, you know you missed it! can't miss the finish line00:21
rick_h_wallyworld: ^00:21
wallyworldrick_h_: indeed, wasn't my first choice to disappear this last little while00:22
anastasiamacisn't it one of the relay strategy to put strongest sprinters last? :D00:25
rick_h_good times while away wallyworld ?00:25
rick_h_i'm heading out next week. leave to the best of the best at the end :p00:26
wallyworldrick_h_: i wish, spent the entire time working my fingers to the bone - ended up having to buy a chain saw to get everything done :-D00:26
rick_h_wallyworld: oooh new tools ftw!00:27
wallyworldrick_h_: you camping or something next week?00:27
wallyworldyeah, new tools :-)00:27
rick_h_wallyworld: i wish. snowing today00:27
wallyworldi wish we had snow00:27
rick_h_wife and i celebrating 10yrs in hawaii00:28
wallyworldrick_h_: oh congrats00:28
rick_h_so i'll be closer where i can keep an eye on you :)00:28
wallyworldi'll wave from my balcony00:28
rick_h_new camper is done may 11 so after these may sprints i'll live from the woods for a while00:29
wallyworldwith no wifi :-(00:31
rick_h_nope have a booster antenna for the mifi device00:32
davecheneyfatal error: concurrent map read and map write00:32
davecheneygoroutine 1660 [running]:00:32
davecheneyruntime.throw(0x18945e0, 0x21)00:32
davecheneybzzt, cannot land my 1.25 fix wihtout fixing gomanta00:32
davecheneyfairy nuf00:32
rick_h_davecheney: that seems ungood00:32
davecheneyrick_h_: thumper cherylj menn0 http://reviews.vapour.ws/r/4507/00:40
davecheneyfix is here00:40
davecheneyi need to land that before I can land that other fix00:40
wallyworlddavecheney: fwiw, in master joyent doesn't use manta anymore, still may need to clean up some old tests00:46
davecheneywallyworld: thanks for that00:52
davecheneyi need to land this on master to backport it00:52
davecheneythen i'll raise a tech debt care to remove the manta library as a dep00:52
davecheney+1, less things to depend on, wheee!00:52
wallyworlddavecheney: sure, np. the change to not use manta only landed recently, still scrambling to clean everything up00:52
wallyworldbut yes, less deps is good. and we now don't need provider storage so long as the provider supports tagging00:53
menn0cherylj, wallyworld, davecheney, sinzui: launchpad is down so the check blockers script is dying at the start of merge attempts00:55
davecheneylooks like i picked a bad day to quit sniffing glue00:55
blahdeblahmenn0 cherylj wallyworld sinzui: we're working on it00:56
wallyworlddid the hamster die00:56
menn0blahdeblah: ok great00:56
* menn0 starts following @launchpadstatus00:57
davecheneyyou must construct more pylons01:01
sinzuimenn0: I can comment out the check01:02
davecheneysinzui: pleaes01:03
menn0sinzui: that would be good but it might not be enough. juju has deps on packages hosted on launchpad. godeps might complain.01:03
menn0sinzui: it's worth a try though01:03
sinzuimenn0: bzr is working so disabling the check might be enough01:08
menn0sinzui: great01:09
sinzuimenn0: http://juju-ci.vapour.ws:8080/view/Juju%20Ecosystem/job/github-merge-juju/7283/console is retying now01:09
menn0sinzui: looks good so far01:10
menn0spoke too soon01:10
sinzuino I just got godeps01:10
* menn0 nods 01:11
menn0seems to be stuck at godeps01:11
menn0progress! :)01:11
menn0sinzui: it seems to be moving... i'll keep an eye on it01:11
menn0sinzui: thanks!01:11
sinzuinp menn001:12
menn0launchpad.net appears to be back now anyway01:13
mupBug #1568643 opened: RebootSuite times out if unrelated lxd containers exist <juju-core:New> <https://launchpad.net/bugs/1568643>01:21
alexisbsinzui, I am pretty sure you are a machine that never sleeps01:25
alexisbthanks for the 1.6 work01:25
sinzuialexisb: I don't sleep well :)01:25
davecheneywallyworld: https://github.com/juju/juju/pull/506501:26
davecheney^ backport to 1.25 which unblocks my other change landing01:26
axwanastasiamac: reviewed your branch01:40
anastasiamacaxw: thnx \o/01:41
menn0grrr... why has lxd suddenly stopped working?02:21
alexisbmenn0, we have lots of lxd bugs going around atm02:24
alexisbthere are about 3 criticals against juju-core that are impacting lxd/lxd provider02:25
cheryljaxw: did you want to take one more look:  http://reviews.vapour.ws/r/4502/ ?02:26
menn0alexisb: yep I know... lxd just stopped working for me in the middle of a complex test reproduction - annoying02:26
cheryljmenn0: what happened?02:26
axwcherylj: looks good, thanks02:27
cheryljthanks, axw!02:27
menn0cherylj: I was deploying the dummy charm various models under one controller02:27
cheryljmenn0: what were you seeing?02:27
menn0the first machine came up as normal02:27
menn0the other were stuck in pending02:27
menn0no activity02:27
menn0nothing in juju's logs about it02:28
menn0nothing in the lxd logs that I could find02:28
cheryljoh fun, I've seen that too02:28
menn0the machines didn't exen exist when I ran "lxc list"02:28
cheryljmenn0: do the machines exist in the database?02:28
menn0they were showing in status so had to have been in the DB02:28
menn0it's like juju didn't ask lxd to create the instances, or lxd didn't create them for some reason02:29
cheryljah, I've hit an issue where the services show up, but no machines to host them were ever created02:29
menn0that sounds like what I just saw02:29
cheryljI mean, they didn't even exist in mongo02:29
menn0oh right... in my case the machines did show up in status02:31
menn0so they must have been in the DB02:31
menn0cherylj: ^02:32
davecheneyit's been a while since tht one failed03:05
davecheneygood to see it's as unreliable as ever03:05
davecheneycherylj: are you happy with the response to https://bugs.launchpad.net/bugs/156860203:11
mupBug #1568602: Cannot build OS X client with stock Go 1.6 <ci> <go1.6> <osx> <packaging> <regression> <juju-ci-tools:Fix Released by sinzui> <juju-core:Invalid> <https://launchpad.net/bugs/1568602>03:11
davecheneywe see that report a lot03:11
davecheneyand it's always a crapped up go install03:11
davecheneyusually by not removing the old version before unpacking the new version03:11
cheryljdavecheney: thanks for looking at it.  sinzui mentioned he got it working now03:12
mupBug #1568602 changed: Cannot build OS X client with stock Go 1.6 <ci> <go1.6> <osx> <packaging> <regression> <juju-ci-tools:Fix Released by sinzui> <juju-core:Invalid> <https://launchpad.net/bugs/1568602>03:13
mupBug #1568654 opened: ec2: AllInstances and Instances improvement <juju-core:New> <https://launchpad.net/bugs/1568654>03:13
davecheneycool, let me know03:14
davecheneyI can provide some suggestios for how to use the upstream tarball concurrently03:15
davecheneyif needed03:15
davecheneyit's pretty straight forward03:15
cheryljnot sure if we'll need that.  sinzui ?  ^^03:16
cheryljwallyworld: can you take another look?  http://reviews.vapour.ws/r/4504/03:16
davecheneybuild times go up, build times go down. you cannot explain that03:16
cheryljwallyworld: I had to move things around to avoid circular dependencies03:16
wallyworld_cherylj: lgtm, ty03:18
cheryljwallyworld_: thanks!03:18
sinzuidavecheney: getting it working was easy for me but not CI. You were right about more than one tool chain on the host. CI in an effort to purge the env I setup for, disocvered the wrong go tool chain. It found the go I used to compile the go 1.6 we place in a special dir away from the system. All that is resolved now03:19
davecheneyokie dokes03:20
davecheneythis might be the one time that i actually say "you should set GOROOT"03:20
davecheneybut please, don't tell anyone I said thta03:21
cheryljCan I get another review?  http://reviews.vapour.ws/r/4510/03:30
cherylj(pretty easy)03:30
davecheneycherylj: LGTM, ship it03:33
cheryljthanks, davecheney!03:33
cheryljI'll have to get in line...  lots of merges lined up :)03:34
cheryljmenn0: model-migration merge completed!03:34
menn0cherylj: *\o/*03:36
davecheneywallyworld_: provider/joyent/local_test.go:03:39
davecheney10:     lm "github.com/joyent/gomanta/localservices/manta"03:39
davecheney^ ja'cuse03:39
davecheneystill some code using gomanta03:39
davecheneyshould I kill it with spite ?03:40
wallyworld_davecheney: yes, please, all the manta stuff needs to go away03:40
wallyworld_davecheney: 2.0 should not import gomanta at all03:40
davecheneyhulk smash!03:41
davecheneyso what does joyent use now ?03:42
menn0wallyworld_ or axw: can I get some help with a charm storage / GridFS related issue?03:44
axwmenn0: sure, what's up?03:44
wallyworld_depends what it is :-)03:44
menn0so I fixed this: https://bugs.launchpad.net/juju-core/+bug/154148203:45
mupBug #1541482: unable to download local: charm due to hash mismatch in multi-model deployment <2.0-count> <juju-release-support> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1541482>03:45
menn0it turns out the api server had a local cache of charms, which wasn't model specific03:45
menn0it was easy to fix03:45
menn0but fixing it has exposed another problem03:46
menn0if you deploy a local charm to one model03:46
menn0and then deploy the same charm to another model in the same controller, the unit in the 2nd model can't download the charm03:46
menn0if the local charm is the same but with slight modification it works03:47
menn0but not if it's exactly the same charm03:47
wallyworld_menn0: was this cache added by something in charmrepo?03:47
menn0i've added lots of debug logging and everything looks fine03:47
menn0wallyworld_: no the cache is in the charm download API handler03:47
wallyworld_ok, there's also one in charmrepo from memory03:48
menn0wallyworld_: it uses a directory to download charms out of storage into03:48
menn0wallyworld_: the cache assumes that the contents of a charm with a given charm URL is always the same03:49
menn0wallyworld_: but that isn't true for local charms across models03:49
axwmenn0 wallyworld_: I think the "binarystorage" index might not be model-specific, checking...03:49
wallyworld_menn0: i'm not familair with the code - why does the api server need a cache of stuff from mongo?03:49
menn0wallyworld_: good question. the endpoint supports returning file listings and downloading particular files out of the charm archive03:50
menn0wallyworld_: I guess the expectation is that there will be many API calls for the one charm archive03:50
wallyworld_right, so a local cache adds very little that i can see03:50
wallyworld_i guess so03:51
menn0wallyworld_: at any rate, the cache isn't the problem here03:51
wallyworld_is the index model specific?03:51
menn0wallyworld_: the cache was hiding a deeper bug in charm storage03:51
axwmenn0: sorry had my wires crossed, that's just for tools...03:51
menn0axw, wallyworld_: the way charms are stored looks fine but there's obviously a problem03:52
* menn0 prepares a paste03:52
wallyworld_menn0: the charns collection should be model aware03:54
menn0wallyworld_: yep it is03:54
menn0wallyworld_: the problem isn't there I don't think03:54
wallyworld_that's where the charm doc goes - the url is not model aware but that shouldn't matter03:55
menn0wallyworld_: it's in the GridFS put/get code I think03:55
wallyworld_there's a PutForBucket api03:55
wallyworld_so long as we set the bucket id to be the model uuid that should be enough03:55
menn0wallyworld_, axw : http://paste.ubuntu.com/15752687/03:56
menn0wallyworld_, axw : that's the output from a bunch of debug logging I added03:56
menn0wallyworld_, axw : does that help?03:57
menn0so for the second charm post, the GridFS entry appears to get reused03:58
thumperoh poo03:58
menn0but during the download attempt for the second model it can't be found03:58
thumpermy maas update seemed to loose all the power settings for the machines03:58
wallyworld_menn0: that looks like it's using the old blobstore03:58
wallyworld_should be blobstore.v203:58
wallyworld_with PutForBucket03:58
menn0this is blobstore.v203:59
wallyworld_not that it should matter i guess in terms of this bug03:59
wallyworld_some internal methods were not renamed03:59
mupBug #1568666 opened: provider/lxd: non-juju resource tags are ignored <juju-core:Triaged> <https://launchpad.net/bugs/1568666>04:01
mupBug #1568668 opened: landing bot uses go 1.2 for pre build checkout and go 1.6 for tets <juju-core:New> <https://launchpad.net/bugs/1568668>04:01
mupBug #1568669 opened: juju 2.0 must not depend on gomanta <juju-core:New for dave-cheney> <https://launchpad.net/bugs/1568669>04:01
wallyworld_menn0: it doesn't make sense at first glance - the resource path i think from memory is the raw access to the blob - that should not be affected by wthat happens above with bucket paths etc04:04
wallyworld_so the resource path should be there - unless something is deleting it04:05
wallyworld_is it worth putthing debug in the remove methods04:05
menn0wallyworld_: ok, i'll try that. I have put some in some of the cleanup-on-error defers already but they're not firing04:06
menn0wallyworld_: i'm also checking how things look in the DB04:06
wallyworld_menn0: so to be sure i understand - the issue is that the second upload correctly creates resource metadata for the new model uuid etc, and it rightly shares a de-deuped blob with the first upload, but the attempt to access that blob fails04:07
wallyworld_and it is failing at the point at which the blob itself is retrieved04:07
menn0wallyworld_: spot on. that's my best understanding at the moment04:07
wallyworld_hmmm, so yeah, that blob should be there unless deleted04:07
wallyworld_this should all be orhtogonal to any bucket uuid stuff04:08
axwyeah, it seems to be passing the right path to gridfs ..04:08
axwbased on the error04:08
menn0looking at the storedResources collection and the blobstore db directly, everything looks ok04:09
wallyworld_jeez, well that sucks04:10
menn0i'll add more debug logging in the lookup side of things04:10
wallyworld_at least the storage side looks correct - it is using the model uuid correctly04:11
wallyworld_and de-duping across models04:11
menn0wallyworld_: it certainly *looks* like it's doing the right hting04:15
wallyworld_still could be a subtle issue i guess04:15
menn0i've just added a lot more logging on the get side of things04:16
menn0wallyworld_, axw: I think I've found it04:25
menn0wallyworld_, axw: the GridFS instance is created with the model UUID as the prefix04:26
menn0wallyworld_, axw: so even though the charm is being requested with the correct de-duped UUID04:26
menn0wallyworld_, axw: the GridFS prefix prevents it being found04:27
wallyworld_the namespace?04:27
menn0wallyworld_: yes04:27
menn0does that seem right?04:27
wallyworld_so maybe the namespace should be the controller uuid04:27
wallyworld_i think so04:27
wallyworld_this was all done pre-multi model04:28
arcticlightHi! Am I in the right place to ask about filing a bug against Juju? I'm kind of new to the whole FOSS community thing and I have *no idea* how to use Launchpad.04:28
wallyworld_arcticlight: sure, ask away04:28
wallyworld_and welcome04:29
wallyworld_menn0: does each controller get a different uuid in HA?04:30
menn0wallyworld_: naively fixing this by changing the charms code to use a statestorage with the controller's UUID will no doubt break existing deployments04:30
wallyworld_i think so right?04:30
wallyworld_menn0: it will break existing yes04:30
arcticlightwallyworld_: It's actually really simple... Juju doesn't seem to depend on `curl` but goes ahead and uses it anyway. But on Ubuntu Server 14.04 LTS it's not installed by default, or at least it wasn't on my system (I have a fresh install) and `juju bootstrap` blew up. Thought I'd mention it04:30
menn0wallyworld_: in HA the controller is really the whole cluster04:31
menn0wallyworld_: there is only one controller model and one UUID04:32
menn0wallyworld_: so that's not a problem04:32
wallyworld_arcticlight: yes, it does use curl - to retrieve the tools binaries at bootstrap. i'm surprised 14.04 lts doesn't have it out of the box, but i'm not a packaging guy04:32
wallyworld_arcticlight: thanks for mentioning, i'll followup with someone who knows more about ubuntu default packaging and see if we need to fix anything04:32
arcticlightwallyworld_: Yeah. I fixed it by installing curl, but it did blow up on a fresh install. I figured someone should know so they can add a dependency on curl.04:32
arcticlightwallyworld_: Welcome!04:33
wallyworld_arcticlight: just ask if there's anything else you get stuck on. lots of folks here who can help04:33
wallyworld_menn0: so the "easy" option is to use the controller uuid with gridfs namespace. i'm ok with release notes telling poeple they need to re bootstrap between betasa, but that's IMHO04:34
arcticlightwallyworld_: OK! Good to know. I've been fooling around with MAAS/Juju since around 2013. I'm just really shy lol~ Figured this was simple enough to just pop on and ask about tho04:34
wallyworld_we don't bite04:35
wallyworld_unless really provoked :-)04:35
menn0wallyworld_: what about 1.25 systems?04:36
wallyworld_menn0: we have sooooooo many tings to fix with upgrades there04:36
wallyworld_this is just one more04:36
wallyworld_menn0: upgrading from 1.25 will be really, really difficult04:37
wallyworld_menn0: i suspect we'll considering migrayions :-)04:37
wallyworld_might be easier in the long run04:37
menn0wallyworld_: you realise that would mean backporting migrations to 1.25?04:38
wallyworld_yes, or a form thereof04:38
wallyworld_that will likely be so much easier that the alternative04:38
anastasiamacjeez wallyworld_, u made thumper quit with all this upgrades talk04:38
menn0wallyworld_: I've realised for some time that this was on the cards :-/04:38
wallyworld_na, i just bit him hard04:38
wallyworld_menn0: i think we all have :-) sort of a slowly increasing dread04:39
anastasiamacdread != anticipation04:40
menn0dread is more accurate :)04:43
* menn0 tries the naive fix04:43
anastasiamacsure... but when u dread problems become harder and motivation disappears... when u anticipate, besides being prepared, there is always something to look forward to..04:47
menn0wallyworld_: were you proposing we pass the controller UUID to charm related calls to state/storage.NewStorage() or were you proposing that we use the controller UUID in the call that stateStorage makes to blobstore.NewGridFS()?04:58
axwmenn0: I think the latter04:59
wallyworld_menn0: i think(?) just the latter is all we need04:59
wallyworld_that would be my preference04:59
axwso they're all sharing a common gridfs namespace, and we have model-specific catalogues that point into it04:59
menn0wallyworld_: cool that makes sense (the latter, not the former). I misunderstood what you meant the first time around and then realised it didn't make sense as I started to change all the calls to NewStorage()05:01
wallyworld_oh sorry :-)05:01
wallyworld_i should have been more clear05:02
menn0wallyworld_: no it was my bad05:02
menn0wallyworld_: use the controller UUID over a fixed value? the controller UUID isn't readily available in stateStorage05:03
wallyworld_menn0: isn't there a helper method on state? you don'r have access to that in stateStorage?05:03
menn0wallyworld_: no it gets a MongoSession, not a State05:03
menn0wallyworld_:  I can rejig things05:04
wallyworld_where does it get the model uuid from then?05:04
menn0wallyworld_: or use a fixed value "juju" or "state" or "jujustate"05:04
menn0the model UUID is passed in with the MongoSession05:04
menn02 args05:04
wallyworld_so can't we change that to controller uuid?05:04
axwmenn0 wallyworld_: may as well just use a constant, it doesn't really need to be the controller UUID05:05
axwit just needs to be the same for all views on the db05:06
wallyworld_except if we want to share a mongo instance between controllers05:06
blahdeblahAnyone know if there are moves afoot to introduce DNS as a Service support into either juju itself or the charm store?05:25
menn0wallyworld: i've just tried using a fixed GridFS namespace ("juju") in state/storage.NewStorage() and that fixes the problem05:26
wallyworld_menn0: great. if it's easy to get controller uuid in there that would be good05:27
menn0wallyworld: your reasoning for that is to avoid any chance of collision in case of a mongodb instance being shared by multiple controllers?05:28
wallyworld_menn0: yeah05:28
wallyworld_we just don't know what might need to be supported in the future05:28
menn0wallyworld_: but that would break anyway... our main db is called "juju"05:28
menn0and the collection names in it are fixed05:29
wallyworld_well, we use model uuids though05:29
wallyworld_i guess "juju" is ok for gridfs05:29
menn0wallyworld_: I was about to allow my mind to be changed :)05:30
wallyworld_quick win for now05:30
wallyworld_menn0: i guess there's pros and cons. maybe if it's easy to do....05:31
menn0wallyworld_: if we were to do it then it would probably make sense to have NewStorage just take a *State05:31
menn0it could then pull the model uuid, controller uuid and session off that05:31
menn0sound ok?05:31
menn0it looks like all the call sites have a *State05:32
wallyworld_menn0: let's use a bespoke interface that just declares the state methods it needs05:33
wallyworld_pass in the concrete state.State from the caller05:33
wallyworld_but declare the NewGridFS() method to use a smaller interface05:33
wallyworld_or just add a controller uuid param05:34
menn0wallyworld_: ok sounds good. i'll pass in state but via an interface05:34
wallyworld_blahdeblah: i don't think there's anything coming in core, but i thought the ecosystems/charm guys had something for juju itself they use05:35
menn0wallyworld_: state doesn't currently have a ControllerUUID method but i'll add one05:35
wallyworld_menn0: i though it did?05:35
menn0wallyworld_: nope. there's ControllerModel and you can get it from there but that's messy05:35
menn0wallyworld_: there's a unexported controllerTag field so I'll just expose the UUID via that05:35
wallyworld_like we do for ModelUUID()05:36
* menn0 bids05:36
menn0nods even05:36
blahdeblahwallyworld_: thanks - will ping them05:44
menn0wallyworld_: I just noticed that state/imagesstore uses a fixed "osimages" prefix05:50
wallyworld_menn0: ah yes. i think the thinking there was that it is ok to share cached generic lxc images between controllers05:51
menn0wallyworld_: and state.ToolStorage uses the model UUID05:51
wallyworld_hmmm, so tools storage could break the same way maybe?05:52
* menn0 wonders if ToolsStorage could end up with the same problem where an entry is inaccessible05:52
menn0yes I think so05:52
menn0wallyworld_: it's probably hard to trigger at the moment05:52
wallyworld_menn0: do we even need a namespace?05:52
menn0wallyworld_: can you upload tools for a hosted machine05:52
wallyworld_i think the controller stores all the tools tarballs for the hosted models, would need to check05:53
menn0wallyworld_: I guess if you do juju upgrade-juju --upload-tools for 2 hosted models you might hit the same problem05:53
wallyworld_not sure, but sounds plausible doesn't it05:54
menn0if you used exactly the same tools05:54
wallyworld_yes, that's they key - need to be the same05:54
menn0wallyworld_: does upload-tools recompile the tools05:54
wallyworld_depends - if it finds binaries in the path, then no05:54
wallyworld_is my recollection05:54
menn0wallyworld_: ok. if it did recompile then the odds of the binary being exactly the same is slim05:55
wallyworld_but let's not count on it05:55
menn0wallyworld_: regarding whether we need a namespace, I think you need to provide soemthing.05:55
menn0wallyworld_: the docs say the convention when there's only one namespace required is to use "fs"05:56
menn0wallyworld_: I think it still makes sense to use a namespace for different uses of gridfs05:56
wallyworld_menn0: so maybe we just use a const "osimages", "tools", "charms" etc?05:56
menn0wallyworld_: yep.05:58
menn0wallyworld_: or we use the controller UUID...05:58
menn0wallyworld_: no a prefixes per use seems better05:59
wallyworld_menn0: i think not looking at the different usages - namespaces for images, charms, tools etc seems ok05:59
wallyworld_we still differentiate by model uuid inside each namespace06:00
menn0wallyworld_, axw: why does ToolsStorage and GUIStorage not use state.NewStorage()?06:00
menn0what's different about binaryStorage?06:00
wallyworld_menn0: not sure, i know someone renamed binary storage recently, but can't recall the details06:01
wallyworld_i can recall the specifics ottomh06:02
menn0wallyworld_: ok. well I'll avoid fixing the world.06:02
wallyworld_not in this pr :-)06:02
wallyworld_next one06:02
menn0wallyworld_: thanks for your help and input06:04
* menn0 is gone for now06:04
wallyworld_menn0: np, didn't do much :-)06:04
wallyworld_thanks for fixing06:04
axwmenn0: I think they probably could. tools storage was written before that IIRC06:04
mupBug #1566345 changed: kill-controller leaves instances with storage behind <juju-release-support> <kill-controller> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1566345>06:10
=== urulama__ is now known as urulama
mupBug #1568715 opened: simplestreams needs to be updated for Azure Resource Manager <juju-core:Triaged> <https://launchpad.net/bugs/1568715>07:05
frobwaredimitern: ping; are you using/testing LXD containers on trusty?08:14
dimiternfrobware, hey, yes - I did, but mostly testing with xenial now08:19
frobwaredimitern: I saw you landed the /e/n/i change. It's only half the story though as we need to delete eth0.cfg.08:20
frobwaredimitern: my MAAS/LAN/OTHER seems borked at the moment as having a lot of problems bootstrapping.08:20
dimiternfrobware, ok, I'll propose a fix that deletes eth0.cfg08:23
frobwaredimitern: I was trying to verify on trusty but ran into deploy problems.08:23
frobwaredimitern: I also wanted to understand the order a little better. Who wins doe 00-juju.cfg and eth0.cfg08:24
dimiternfrobware, I'm also working on sketching the next steps to fix network config setting properly08:24
frobwaredimitern: I might still see the issue where the MA needs bouncing on xenial before a containers gets its correct network profile08:25
dimiternfrobware, well, on trusty you need to add "trusty-backports" to /e/a/sources.list and a-g update08:25
frobwaredimitern: tried that...08:25
dimiternfrobware, and then a-g install trusty-backports/lxd ?08:25
frobwaredimitern: question is, should the have been done by juju for trusty?08:26
dimiternfrobware, yes, i think so08:28
dimiternfrobware, wasn't jam doing something about that?08:28
dimiternfrobware, hmmm or maybe it IIRC trusty-backports are *supposedly enabled* by default, so that steps were unnecessary ?08:30
dimiternI haven't seen a cloud image of trusty where backports is on by default08:31
frobwaredimitern: right; just expected juju to do the business. Only switched to trusty because I had issues with xenial.08:31
frobwaredimitern: was going to do some testing before I land the `rm eth0.cfg' change. Wanted to understand the order of when 00-juju.cfg wins over eth0.cfg to see if we need to down/up all interfaces.08:39
dimiternfrobware, sure08:41
frobwaredimitern: I also wonder whether our rm should be a bit smarter. rm all but 00-juju.cfg.08:46
dimiternfrobware, alternatively, we can change /e/n/i/ to source interfaces.d/*.juju :)08:47
dimiternor something like that08:47
* fwereade has a filthy cold, please excuse me dimitern voidspace et al09:04
dimiternfwereade, get well soon! :)09:05
voidspacefwereade: yep, recover quickly09:16
* TheMue dccs wishes to get well soon to fwereade 09:22
jamdimitern: frobware: you shouldn't need to directly add trusty-backports as it should be *available* by default (but not active), and "juju bootstrap" should be doing "apt-get -t trusty-backports install lxd"10:28
jamif it isn't then we have a bug we should be aware of10:29
jamdimitern: I've done several bootstraps on Trusty images on AWS and they work.10:29
jamdimitern: now, we've had bugs with *trusty* and "go-1.2" with official releases (juju-2.0-beta3) because go-1.2 doesn't work with LXD10:29
jamso it tells you "unknown" or somesuch.10:30
jambut Master or "juju bootstrap --upload-tools" should all work, and next release should be built with 1.610:30
dimiternjam, I've yet to see a trusty cloud image on maas that has trusty-backports in /e/apt/sources.list tbo10:30
jamdimitern: so I'm not sure where it is enabled, but it does work.10:31
jamhave you tried just doing "apt-get -t trusty-backports install lxd" ?10:31
mgzdimitern: it should be there, but not at a prio that installs packages unless explictly selected10:31
jamI'm bootstrapping now to confirm, but I have tested it in the past10:31
jamhi mgz10:31
dimiternjam, yes, and it says trusty-backports is unknown or something10:32
jamdimitern: what cloud/what region/what version of juju?10:32
dimiternjam, mgz, hmm ok I'm trying now again to confirm after updating all images10:32
dimiternjam, maas/2.0 and juju from master tip10:32
dimiternvoidspace, I'm getting a lot of "Failed to power on node - Node could not be powered on: Failed talking to node's BMC: Unable to retrieve AMT version: 500 Can't connect to at /usr/bin/amttool line 126." errors with 2.0 maas10:33
dimiternit works but unreliably10:33
dimiternlike 1-2 out of 5 power checks fail10:33
voidspacedimitern: weird10:35
voidspacedimitern: that really sounds like maas bug10:35
voidspacedimitern: I don't hit that because I'm not setting the power type I guess10:35
voidspacedimitern: or maybe it's a new version of amttool in xenial10:36
voidspaceor virsh10:36
voidspaceeither way - maas problem10:36
dimiternvoidspace, indeed10:37
jamdimitern: "sudo apt-get -t trusty-backports install lxd" works for me on a Trusty image created with 2.0.0-beta3 in AWS (even though Juju 2.0.0b3 wouldn't be able to talk to it with released tools)10:37
dimiternjam, mgz here it is - fresh install of trusty - http://paste.ubuntu.com/15756105/10:38
dimiternMAAS Version 2.0.0 (beta1+bzr4873)10:38
dimiternjam, mgz, is it possible AWS uses different cloud images than MAAS ?10:39
mgzdimitern: it does10:39
jamdimitern: I'm sure they are different builds, as the root filesystem is different10:39
jambut I thought they were supposed to be as much the same as possible.10:39
jamdimitern: we need a bug on MaaS and Juju that tracks that10:40
jamthanks for noticing.10:40
dimiternwell that's kinda crappy ux :/10:40
dimiternjam, yeah10:40
dimiternjam, looking at http://images.maas.io/query/released.latest.txt and http://images.maas.io/query/daily.latest.txt it looks like the trusty images MAAS is using are 2 years old10:50
jamdimitern: that doesn't sound good10:50
voidspacebabbageclunk: are you working on the MAAS2 version of maasObjectNetworkInterfaces?11:45
voidspacebabbageclunk: pretty sure you are - in which case I'll leave it as a TODO in my branch11:45
babbageclunkvoidspace: yes11:45
voidspacebabbageclunk: ok11:45
voidspacebabbageclunk: it will need wiring into my branch when done11:45
babbageclunkvoidspace: just pushing and creating a PR for the storage - spent longer than expected bashing my head on golang features.11:46
voidspacebabbageclunk: heh, welcome to go :-)11:46
perrito666bbl (~1h)11:47
frobwarejam: trying again; got sidetracked by h/w11:48
babbageclunkvoidspace: https://github.com/juju/juju/pull/507011:54
babbageclunkvoidspace: would you prefer I work on finishing off stop-instances or interfaces next?11:56
voidspacebabbageclunk: https://github.com/juju/juju/pull/507111:56
voidspacebabbageclunk: well, StopInstances and then deploymentStatus get us closer to bootstrap11:57
voidspacebabbageclunk: bootstrap isn't actually blocked on interfaces yet11:57
voidspacedimitern: frobware: two PRs for you11:57
voidspacedimitern: frobware: http://reviews.vapour.ws/r/4513/11:57
babbageclunkvoidspace: ok, stop instances next then11:57
voidspacebabbageclunk: cool11:58
voidspacebabbageclunk: thanks11:58
voidspacedimitern: frobware: http://reviews.vapour.ws/r/4514/11:58
dimiternvoidspace, looking11:58
dimiternvoidspace, both reviewed12:09
* dimitern steps out for ~1h12:09
voidspacedimitern: thanks12:26
voidspacedimitern:  that point about the comment is in a test that currently doesn't run (I changed the name to DONTTestAcquireNodeStorage...)12:29
voidspacedimitern: because it needs the work that babbageclunk has done on storage12:29
voidspacedimitern: so that will be updated next12:29
voidspacedimitern: so effectively that whole test is commented out - and there *is* a TODO comment at the start of the test to explain why.12:30
* voidspace lunch12:30
=== babbageclunk is now known as babbageclunch
mupBug #1568845 opened: help text for juju autoload-credentials needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568845>13:09
dimiternvoidspace, ok,sgtm13:12
mupBug #1560457 changed: help text for juju bootstrap needs improving <juju-core:Triaged> <https://launchpad.net/bugs/1560457>13:39
mupBug #1568848 opened: help text for juju bootstrap needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568848>13:39
mupBug #1568854 opened: help text for juju create-model needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568854>13:39
mupBug #1568862 opened: help text for juju needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1568862>13:39
=== babbageclunch is now known as babbageclunk
katcomorning all14:16
mgzwotcha katco14:18
voidspacedimitern: did you see the reply from babbageclunk on his PR14:21
voidspacedimitern: he doesn't understand your review comment, and nor do I14:21
voidspacewe so missed an opportunity14:21
voidspaceour maas feature branch should have been called maaster14:22
babbageclunkvoidspace: amazing14:22
dimiternvoidspace, babbageclunk, sorry - I've posted a reply14:22
babbageclunkvoidspace: I mean, amaazing14:22
dimiternthe diff mislead me I guess14:22
voidspacebabbageclunk: I like babbagelunch by the way - nice14:23
babbageclunkvoidspace: thanks14:23
voidspace*clunch even14:23
babbageclunkdimitern: no worries!14:24
babbageclunkfrobware: are you ok with that panic if a test sets up the fakeController without files?14:25
frobwarebabbageclunk: panic seems bad14:25
babbageclunkfrobware: what other way is there of failing the test?14:26
frobwarebabbageclunk: sorry, sidetracked again.14:31
natefinchpanic is ok if it indicates a programmer error, especially during tests.  It's sort of a nice "don't do that!" as long as it happens right away with an obvious cause.14:32
frobwarebabbageclunk: I replied in the review14:37
babbageclunkI'll change it to return a generic error with a clear message indicating what the problem is.14:37
babbageclunkfrobware: cool, thanks!14:41
natefinchcherylj: what's the color coding on the bug squad board?14:46
natefinchcherylj: nvm... card type. I see14:46
natefinchcherylj: I was looking at priority for priority and they were all normal, which was confusing me14:47
natefinchcherylj: just grab a critical off the top somewhere, or do you have a suggestion?14:48
cheryljnatefinch: just pick one on the criticals that interest you :)14:48
katcocherylj: ty :) all of moonstone will be on bug squad now14:49
frobwarejam: not sure if you're still about but I had no joy with add-machine lxd:0. See bug #156889514:56
mupBug #1568895: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>14:56
cheryljcool, thanks katco.  If there are new bugs found in CI, I might need to redirect people :)14:56
katcocherylj: we're at your direction14:56
cheryljsinzui:  is master running in CI now?14:56
cheryljkatco: I'm actually wondering if I need to block things as we're trying to get a release out tomorrow14:56
cheryljI'd rather not, but we really really need a good run14:57
katcocherylj: if we need stability then i'd agree =/14:57
sinzuicherylj: 1.25 strted about 45 miniutes ago14:57
cheryljsinzui: could you kill it and run master?14:57
sinzuicherylj: I hesitate to. killing it means waiting for other things to complete and cleanup.14:58
* sinzui looks14:58
cheryljsinzui: understood14:58
cheryljkatco: and technically, master is blocked from a different bug :)14:58
katcocherylj: what bug is that?14:58
katcocherylj: nm i see it14:59
cheryljkatco: one of many that I opened over the weekend for failures14:59
katcocherylj: looks like fix committed14:59
katcocherylj: by you ;p15:00
cheryljoh snap, I forgot15:00
sinzuicherylj: Can we compromise? it will take an hour for some of the current jobs to complete, but I can see we are half way though 1.25 tests. I can make some jobs not retry to get to master faster15:00
cheryljsinzui: did you turn back on the block checker?15:00
cheryljsinzui: yeah, just make them not retry15:00
sinzuicherylj: I can enable it now15:00
cheryljsinzui: thank you15:00
cheryljkatco: lp was having issues yesterday, so sinzui disabled the blocking bug check15:01
cheryljso people should get bounced back again once sinzui re-enables if they're trying to merge15:01
cheryljkatco: did you guys have anything you needed to add to release notes?15:01
katcocherylj: i don't think so, but i'll check with the team15:02
katconatefinch: standup time15:03
mupBug #1568895 opened: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>15:03
natefinchkatco: oh, sorry, I expected it to be tonight... coming15:04
tych0frobware: any luck on the networking stuff for lxd?15:04
frobwaretych0: the /e/n/i is partially fixed. need to delete eth0.cfg, but also wanted to understand if I can just do this carte-blanche in cloud-init.15:06
frobwaretych0: sidetracked by the fact that juju/lxd is not installing on trusty (for me at least)15:06
tych0frobware: ah, i saw that bug. can you just use --series=xenial?15:07
frobwaretych0: yes, but had problems there so I though... I'll just use trusty... and the rest is history15:07
frobwaretych0: so, yes. back to trusty... but also wary that deleting eth0.cfg might also break precise.15:08
frobwaretych0: correction, back to xenial...15:08
cheryljalexisb: was the cached-images command one on your list to flatten?15:13
alexisbcherylj, yes15:22
alexisbcherylj, I am behind15:22
babbageclunkvoidspace: What does this mean? https://github.com/juju/juju/pull/507015:22
frobwarevoidspace: AA - did we say disable this across the board, or just for MAAS?15:22
cheryljalexisb: no problem.  I'm asking for a friend ;)15:22
babbageclunkvoidspace: that I wasn't up to date with master?15:22
frobwarecherylj: is master blocked on bug #156831215:25
mupBug #1568312: Juju should fallback to juju-mongodb after first failure to find juju-mongodb3.2 <blocker> <ci> <mongodb> <juju-core:Fix Committed by cherylj> <https://launchpad.net/bugs/1568312>15:25
frobwarecherylj: nevermind, mup answered my question15:25
cheryljfrobware: master really should be blocked with a stabilization bug15:25
cheryljsince we're trying to get a release out tomorrow15:25
frobwarecherylj: right. was trying to help answer babbageclunk's question above15:26
cheryljah, ok15:26
babbageclunkfrobware: Ah, is that bug  blocking my merge?15:26
frobwarebabbageclunk: yes15:26
mgzbabbageclunk: we want to do a clean release before landing all the maas2 changes, with the current batch of breakage on master dealt with15:27
babbageclunkmgz: makes sense - so should I hold off until a release is cut?15:28
frobwarebabbageclunk: keep stacking those branches up. :)15:28
babbageclunkfrobware: :) I was so close!15:28
mgzfrobware: if you need to, create a fork under juju to land on15:29
mgzfrobware: whatever makes it easiest to coordinate your work15:29
frobwarevoidspace, babbageclunk: I think we can keep stacking stuff for a day. thoughts? ^^15:30
mupBug #1568925 opened: Address Allocation feature flag still enabled for MAAS provider in Juju 2.0 <juju-core:New> <https://launchpad.net/bugs/1568925>15:33
babbageclunkfrobware, voidspace: yeah, no big problem for me.15:34
katcocherylj: hey, for bug 1567170 what does "hosted model" mean? aren't all models hosted?15:35
mupBug #1567170: Disallow upgrading with --upload-tools for hosted models <upgrade-juju> <juju-core:Triaged by cox-katherine-e> <https://launchpad.net/bugs/1567170>15:35
cheryljkatco: non-admin model15:35
cheryljsorry, was using old-terminology15:35
katcocherylj: ahhh ok15:35
frobwarecherylj, katco: how does one, in development, update a model that is not ":admin"?15:36
katcocherylj: so that's interesting... the binaries are different for non-admin models?15:36
frobwarecherylj, katco: I got caught by this friday, just ended up doing my upgrade-juju in the admin model15:37
cheryljfrobware: the idea is that you can do an upgrade to a published (in devel or stable) release15:37
cheryljfrobware: a later feature request is "upgrade my model to match what the state server is at"15:38
frobwarecherylj: everytime I tried this I ran into "version mismatch". And each time it tried it bumped the version number15:38
mupBug #1568925 changed: Address Allocation feature flag still enabled for MAAS provider in Juju 2.0 <juju-core:New> <https://launchpad.net/bugs/1568925>15:39
mupBug #1568925 opened: Address Allocation feature flag still enabled for MAAS provider in Juju 2.0 <juju-core:New> <https://launchpad.net/bugs/1568925>15:42
bogdanteleagais it possible to get the tools from the state machine through http, instead of trying insecure https?15:42
voidspacefrobware: babbageclunk: heh, I got mine in just before the block15:45
babbageclunkfrobware, voidspace: Just checking I understand - the bug number jujubot's quoting is a red herring (the fix was merged early this morning), it's just blocking merges until the release is done?15:45
babbageclunkvoidspace: grrr! :)15:45
frobwarebabbageclunk: guessing so. cherylj mentioned that there really should be a stabilisation bug15:47
babbageclunkfrobware: ok, got it - cool15:47
voidspacebabbageclunk: the block isn't removed by the jujubot until the bug is changed by QA to "fix released"15:53
voidspacebabbageclunk: "fix committed" (i.e. merged) is not sufficient to unblock as it hasn't been QA verified yet15:53
babbageclunkvoidspace: ah, thanks15:54
voidspacebabbageclunk: this block will probably be left in place (as frobware said) until the release is done15:54
babbageclunkooh, networking meeting15:54
natefinchcherylj: How firm is the suggested wording on #1564622?16:00
mupBug #1564622: Suggest juju1 upon first use of juju2 if there is an existing JUJU_HOME dir <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1564622>16:00
natefinchcherylj: (if you know)16:00
rick_h_natefinch: it's rough16:00
rick_h_natefinch: please feel free to suggest something better. It was on the fly at a sprint16:00
ericsnowtasdomas: PTAL http://reviews.vapour.ws/r/4515/16:01
natefinchrick_h_: ok.  Sometimes it's hard to know what's set in stone and what is not.  I'll play with it and see what seems to work best.16:02
mupBug #1568943 opened: Juju 2.0-beta4 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1568943>16:03
mupBug #1568944 opened: Failure when deploying on lxd models and model name contains space characters <juju-core:New> <https://launchpad.net/bugs/1568944>16:03
ericsnowkatco: that bug was more trivial than expected, so I'm going to pick up another (#1456916)16:03
natefinchericsnow: nice16:04
bogdanteleagacan somebody not call HEAD on a state machine endpoint with tools16:13
natefinchno idea if we support HEAD or not... possibly not16:13
natefinchwell, wait, which endpoints? It's basically all websocket16:14
ericsnownatefinch: tools, charms, backups, and resources all have HTTP endpoints16:15
natefinchahh, thus the reference to tools... misunderstood :)16:16
ericsnow(plus a few others)16:16
katcoericsnow: sorry was otp... that's always a nice problem to have :)16:16
ericsnowdooferlad: are you working on bug #145691616:17
mgzbug 1456916 looks like a pain to fix well16:17
mgzthere are lots of ways to try and fix it badly16:18
ericsnowdooferlad: just noticed it's assigned to you in LP but not on the card in leankit16:18
frobwarebabbageclunk: I'm still in the call if you wanted to chat16:21
babbageclunkfrobware: can't get back in for some reason16:25
frobwarebabbageclunk: want to drop into the sapphire standup HO instead?16:25
babbageclunkfrobware: can't get to there either.16:26
voidspacebabbageclunk: do you get a redirect loop?16:27
voidspacebabbageclunk: I've had that and had to force a log back in by going to something else canonical work related16:28
voidspacesomething else on google I mean16:28
voidspacelike docs.google.com16:28
voidspacewhich should then let you log back in without a redirect loop16:28
voidspacebut that may not be your problem at all16:29
babbageclunkvoidspace: yeah, might be something to do with SSO like Jay had.16:30
babbageclunkWould make sense,16:30
ericsnownatefinch: small patch: http://reviews.vapour.ws/r/4515/16:31
ericsnowredir: thanks for the review :)16:31
jamfrobware: lxd had a packaging bug in trusty for 2.0.0~rc916:32
jamfrobware: that should be fixed as of 20 minutes ago Stephan uploaded a bugfix16:32
frobwarejam: great, will try again16:36
frobwarejam: I'm using releases for my trusty images. is that enough or do I need to switch to daily?16:37
natefinchericsnow: lol wow16:44
ericsnownatefinch: yep16:44
natefinchericsnow: awesome. ship it.16:45
ericsnownatefinch: alas, master is blocked now16:45
ericsnowrogpeppe: re: bug #1566431, are you talking about different AWS accounts or different Juju accounts?16:52
mupBug #1566431: cloud-init cannot always use private ip address to fetch tools (ec2 provider) <juju-core:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1566431>16:52
ericsnowrogpeppe: I'mm looking at how to repro16:52
rogpeppeericsnow: different AWS accounts16:52
ericsnowrogpeppe: figured :)16:52
rogpeppeericsnow: problem doesn't manifest in us-east, for some reason16:54
jamfrobware: it should be an archive change. I don't know how long it will take to propagate17:07
jamnow dimiter's finding about no 'trusty-backports' in maas images is a different bug17:08
natefinchrick_h_: for #1564622 do we actually execute the requested action, or no? like, juju bootstrap is conceivably a valid action at that point.17:26
mupBug #1564622: Suggest juju1 upon first use of juju2 if there is an existing JUJU_HOME dir <juju-release-support> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1564622>17:26
redirso if master is blocked does that mean I should do something differently? or simply that my commits won't make it to master until unblocked?17:30
mgzredir: you don't do $$merge$$ till unblock17:31
redirmgz: that's what I was looking for:) Thanks.17:32
=== natefinch is now known as natefinch-lunch
rick_h_natefinch-lunch: sorry, was otp, looking18:05
rick_h_natefinch-lunch: intresting, I guess you're right there's a list of actions that are legit.18:07
rick_h_natefinch-lunch: so if you've got juju1 home dir stuff, and you run your very first juju2 command...I think it'd be ok to block and output it once18:10
rick_h_natefinch-lunch: and make them redo the command a second time if they knew they were looking for 2.018:11
rick_h_natefinch-lunch: hmm, but my suggested text falls over there doesn't it heh18:11
perrito666mwhudson: hey, are you around?18:16
perrito666mm, I would guess not yet18:17
ericsnowrogpeppe: what did you do to get the provider to create instances under a different AWS account?18:21
rick_h_natefinch-lunch: updated the bug with another round of thoughts. Let me know what you think18:24
cheryljarosales: with your update to bug 1566420 - do your machines show up in the machine section?18:31
mupBug #1566420: lxd doesn't provision instances on first bootstrap in new xenial image <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1566420>18:31
cheryljarosales: or just the services?18:32
arosalescherylj: replying in #juju as the reporter is there18:33
alexisbcherylj, perrito666 is looking for a task, can he just take any bug of the board or do you have a particular one that needs eyes?18:38
cheryljperrito666: here's a quick one for you - bug 156894418:39
mupBug #1568944: Failure when deploying on lxd models and model name contains space characters <juju-core:Triaged> <https://launchpad.net/bugs/1568944>18:39
perrito666cherylj: tx a lot18:39
cheryljperrito666: but remember that master is blocked for now :(18:40
perrito666cherylj: I know18:40
cheryljI feel like we should create a feature branch for people to merge into for now18:40
cheryljuntil we unblock master18:40
perrito666cherylj: nah, the merge back will be a nightmare18:40
cheryljany thoughts (anyone)?18:40
perrito666I do believe that we should do a branch for the release18:40
cheryljperrito666: well, hopefully master won't change18:40
cheryljah, so the opposite :)18:41
cheryljbranch the other thing18:41
perrito666exactly, so master keeps being master18:41
perrito666and if fixes are required for the bless, you can merge just those18:41
cheryljsinzui, mgz, abentley, any thoughts on creating a temporary branch for our 2.0-beta4 release?18:41
cheryljwill that cause problems when we have to release / tag?18:42
sinzuicherylj: It wont affect the tag in git18:42
cheryljit's just weird having people who can actually work bugs while we're trying to get ready for a release :)18:43
sinzuicherylj: are people trying to merge post 2.0  features now?18:43
cheryljperrito666: if you want to tackle some of the help text bugs too, I won't say no :)    https://bugs.launchpad.net/juju-core/+bugs?field.tag=helpdocs18:44
mgzcherylj: it seems a little unnessersary from what I've seen of the pending prs18:44
abentleycherylj: I think it is a good idea.  It's less friction for devs.  There is a risk that bug fixes won't get applied to the 2.0-beta4 branch, but I think that can be managed.18:44
mgznot much chance of mass conflicts between then18:44
perrito666cherylj: everytime I write text for juju I end up sounding like tonto18:44
cheryljperrito666: the text is there, you just need to copy it in :)18:45
cheryljperrito666: the docs team has been busy writing up help text for all the commands18:45
perrito666oh, then I could :p18:45
perrito666ill give a try to the lxc one and then go to docs otherwise18:45
abentleyperrito666: I don't understand why you said the first case would be a nightmare.  Should be exactly as much effort as merging 2.0-beta4 into master.18:45
cheryljsinzui: post 2.0-beta4 bugfixes18:46
perrito666abentley: why would you merge beta4 into master?18:46
abentleyperrito666: Because it has bugfixes.18:46
perrito666abentley: ideally bugfixes should do bug->master->beta18:46
perrito666or the other way but just the one merge, not the whole branch18:47
abentleyperrito666: I am pretty sure that your policy is bug -> release -> master.18:47
perrito666abentley: yes18:47
perrito666we are using github a bit poorly which causes a lot of merge conflicts18:47
abentleyperrito666: If you want to do one merge per bugfix, you can, but it seems inefficient to me.18:49
perrito666abentley: that is what we where doing for 1.24, 1.25, 1.x maintenance18:49
abentleyperrito666: Isn't that just to get bug fixes merged in a timely manner?18:51
rogpeppeericsnow: you need to create a model inside the controller that uses different creds18:51
rogpeppeericsnow: every model inside a controller has a different set of model attributes18:52
ericsnowrogpeppe: I thought I tried that though18:52
rogpeppeericsnow: we could chat about this if you like18:52
ericsnowrogpeppe: sure18:52
=== redir is now known as redir_lunch
perrito666cherylj: I would like your input in the lxc bug, I added a question/suggestion, in the mean time ill go add some help texts :)19:30
=== thomnico is now known as thomnico|Brussel
mupBug #1563590 changed: 1.25.4, xenial, init script install error race <landscape> <juju-core:Invalid> <systemd (Ubuntu):In Progress by pitti> <https://launchpad.net/bugs/1563590>19:40
cheryljperrito666: which lxc bug?  (sorry, been in calls)19:58
cheryljoh ffs19:59
cherylj2016-04-11 19:38:30 ERROR cmd supercommand.go:448 region "DFW" in cloud "rackspace" not found (expected one of ["dfw" "ord" "iad" "lon" "syd" "hkg"])20:00
rick_h_cherylj: case is important?20:01
cheryljrick_h_: shouldn't be20:01
rick_h_cherylj: sorry, I missed the :/ on the end there20:01
cheryljwe changed it to be lower case because sabdfl asked us to, but to keep from regressing people, we should convert the region to lower case before trying to use it20:01
rick_h_cherylj: quit talking sense :P20:02
cheryljBug reporting activated20:02
cheryljses_2: I also see this error coming out of CI:  Test recovery strategies.: error: unrecognized arguments: --charm-prefix=local:trusty/20:04
frobwarecherylj, alexisb: the other known LXD issue - https://bugs.launchpad.net/juju-core/+bug/156889520:05
mupBug #1568895: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>20:05
frobwarecherylj, alexisb: but may be resolved by "tomorrow" if all I'm waiting on is a package update20:06
cheryljfrobware: I remember a conversation not too long ago where someone said backports was enabled by default??20:07
cheryljfrobware: maybe juju is overriding this somehow?20:07
frobwarecherylj: let me trying just deploying trust from my MAAS20:09
* cherylj too20:09
frobwarecherylj: https://bugs.launchpad.net/juju-core/+bug/1568895/comments/620:13
mupBug #1568895: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>20:14
mupBug #1569024 opened: Region names for rackspace should accept caps and lowercase <rackspace> <juju-core:Triaged> <https://launchpad.net/bugs/1569024>20:16
cheryljfrobware: looks like maybe we're overwriting it?20:16
cheryljfrobware: a fresh deploy through AWS shows it enabled:  http://paste.ubuntu.com/15767200/20:16
frobwarecherylj: so on MAAS only?20:17
cheryljfrobware: did you do that through  a maas deploy or juju?20:17
cheryljfrobware: this was not a juju provisioned machine20:17
frobwarecherylj: what's your /etc/cloud/build.info20:17
frobwarecherylj: neither was mine, just MAAS deployed20:17
cheryljserial: 2016040620:17
cheryljfrobware: interesting20:18
frobwarecherylj: daily or releases image on AWS?20:18
cheryljfrobware: daily - I choose the latest from here:  https://cloud-images.ubuntu.com/locator/daily/20:19
frobwarecherylj: going to switch to daily, as I have two "releases" MAAS setups atm20:19
thumpero/ frobware20:19
thumperfrobware: still working?20:19
frobwarethumper: only virtually20:20
frobwarethumper: haven't left standup yet :)20:20
frobwarethumper: still talking about.... CONTAINERS!20:20
mgzfrobware: contain yourself!20:21
cheryljah fudge, should we allow people to specify regions in their cloud definitions that have caps?20:25
cheryljor should we lowercase everything?20:25
cherylj(like we do with users?)20:25
cheryljthumper ^^  thoughts?20:26
mgzI am confused by the bug in general20:26
thumperpersonally I like lowercasing them20:27
anastasiamaccherylj: some regions must b caps coz of provider. axw made some changes in the area...20:27
thumperI don't believe in forcing it if it could cause a problem20:27
thumperanastasiamac: yeah... was thinking it might be something like that20:27
cheryljso I guess people using rackspace need to just change to use lower case region names?20:28
cheryljmaybe we can handle that internally to the rackspace provider20:29
* cherylj looks20:29
ses_2cherylj, I will fix that20:32
cheryljthanks, ses_220:32
=== natefinch-lunch is now known as natefinch
frobwarecherylj: https://bugs.launchpad.net/maas/+bug/1554636 - interesting read if I'm just switching between daily and releases20:39
mupBug #1554636: maas serving old image to nodes <landscape> <MAAS:New> <MAAS 1.9:New> <https://launchpad.net/bugs/1554636>20:39
cheryljfrobware: interesting!  I noticed that my trusty images were old too20:44
cherylj(from like 3 weeks ago)20:44
frobwarecherylj: https://bugs.launchpad.net/juju-core/+bug/1568895/comments/720:56
mupBug #1568895: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>20:56
frobwarecherylj: I don't see any difference with switching to daily images20:56
frobwarecherylj: neither have trusty-backports by default20:57
cheryljI wonder if curtin screws with it20:57
frobwarecherylj: if I launch a container via lxc (locally on my desktop) then I do see backports listed; not all cloud images are created equally20:59
mwhudsonperrito666: hi!21:00
natefinchkatco: wallyworld: moonstone standup or tanzanite or ?21:01
wallyworld_natefinch: nothing on the calendar so i was assuming it hadn't been rescheduled yet21:02
katcowallyworld_: natefinch: correct hasn't been rescheduled. natefinch, remember i was going to discuss with wallyworld?21:02
natefinchkatco: oh, right.  ok21:03
frobwarecherylj: https://bugs.launchpad.net/juju-core/+bug/1568895/comments/821:03
mupBug #1568895: Cannot add LXD containers in 2.0beta4 on trusty <juju-core:New> <https://launchpad.net/bugs/1568895>21:03
* frobware is done... hopefully the MAAS fairies will point me towards the URL of truth...21:04
mupBug #1569047 opened: juju2 beta 3: bootstrap warnings about interfaces <landscape> <juju-core:New> <https://launchpad.net/bugs/1569047>21:16
perrito666mwhudson: hi, so, are we having problems to bootstrap or just to test?21:17
mwhudsonperrito666: i haven't tried bootstrapping, i don't actually know how to use juju :-p21:20
menn0cherylj: https://bugs.launchpad.net/juju-core/+bug/156905421:36
mupBug #1569054: GridFS namespace breaks charm and tools deduping across models <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1569054>21:36
menn0cherylj: I've also created a card for it on the bug squad board21:38
perrito666mwhudson: mmm, ok, have you attached the logs to the bug?21:46
perrito666from the test I mean21:46
mupBug #1569054 opened: GridFS namespace breaks charm and tools deduping across models <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1569054>21:46
mwhudsonperrito666: not the most recent run probably, let me do that21:47
mwhudsonperrito666: https://bugs.launchpad.net/juju-core/+bug/1567708/comments/1121:49
mupBug #1567708: unit tests fail with mongodb 3.2 <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1567708>21:49
perrito666that was fast21:49
mupBug #1569054 changed: GridFS namespace breaks charm and tools deduping across models <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1569054>21:52
mwhudsonperrito666: that was from my run yesterday, i haven't run the tests today...21:54
perrito666tis ok, nothing changed21:55
mupBug #1569054 opened: GridFS namespace breaks charm and tools deduping across models <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1569054>21:58
alexisbthumper, I am running late22:00
thumperalexisb: ok, just on a call with mpontillo22:00
alexisbthumper, on the HO when you are ready, no rush22:06
katcoericsnow: i thought we fixed this? bug 156717022:10
mupBug #1567170: Disallow upgrading with --upload-tools for hosted models <upgrade-juju> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1567170>22:10
katcoericsnow: sorry wrong bug. bug 154511622:10
mupBug #1545116: When I run "juju resources <service>" after a service is destroyed, resources are still listed. <2.0-count> <juju-release-support> <resources> <juju-core:Confirmed> <https://launchpad.net/bugs/1545116>22:10
ericsnowkatco: pretty sure we did22:11
menn0wallyworld_, thumper, cherylj : I've gone for an even simpler fix for the gridfs namespace issue. it's ready now - just doing some manual testing.22:24
wallyworld_menn0: awesome, ty22:25
alexisbthumper, I dropped off the standup, please ping when you are available22:27
thumperalexisb: ok, here now22:27
alexisblol of course22:27
mupBug #1569072 opened: juju2 bundle deploy help text out of date <landscape> <juju-core:New> <https://launchpad.net/bugs/1569072>22:46
perrito666mwhudson: is there I way I can get my hands into this?22:47
mwhudsonperrito666: you mean test on s390x?22:47
mwhudsonperrito666: the failures occur on intel too though22:47
perrito666mwhudson: ok, so to reproduce this you do what exactly?22:48
perrito666sorry I asked you this already :)22:48
perrito666just making sure I am doing things right22:48
mwhudsonperrito666: install the juju-mongodb3.2 from ppa:juju/experimental22:49
mwhudsonperrito666: run JUJU_MONGOD=/usr/lib/juju/mongo3.2/bin/mongod go test github.com/juju/juju/...22:49
* perrito666 is pretty sure he is about to break something in his desktop22:51
menn0wallyworld_: http://reviews.vapour.ws/r/4523/23:03
menn0wallyworld_: I went with the approach of making the gridfs namespace the same as the DB name (as per osimages)23:04
menn0wallyworld_: I came to the conclusion that anything more elaborate was just YAGNI23:04
menn0wallyworld_: tested with local and charm store deployments23:05
perrito666mwhudson: I get juju-mongodb3 and juju-mongo3 which is a transitional23:05
wallyworld_menn0: lgtm23:07
menn0wallyworld_: cheers23:07
mwhudsonperrito666: well you should check with sinzui i guess but i'm preeeeetttty sure juju is jumping from 2.6 to 3.2, not to 323:08
perrito666sinzui: care to shed some light into this ?23:08
perrito666wallyworld_: wb btw23:08
wallyworld_it's 3.223:09
perrito666mm, there is juju-mongodb3 package in version 3.2.0-0ubuntu0~juju8~ubuntu15.10.1~15.1023:09
mwhudsonperrito666: if you've been making juju compatible with 3.0 that would explain some things :-)23:09
mwhudson(presumably that work is a subset of the work to be compatible with 3.2 so not wasted effort entirely)23:10
perrito666wallyworld_: mwhudson https://pastebin.canonical.com/153956/23:10
mwhudsonah i bet my reply to this is "3.2 is only built for xenial"23:10
perrito666mwhudson: good to know :p23:10
perrito666ok, here goes my machine's stability23:11
* perrito666 upgrades to xenial23:11
mwhudsonah yes, probably23:11
mwhudsonhah uh, or use a lxd or ec2 instance or something? :)23:11
mwhudsoni do need to upgrade myself soon23:11
wallyworld_perrito666: juju-mongodb3.2 is not in the archives yet afaik23:12
wallyworld_that's the whole issue that has been hanging around for several weeks23:12
wallyworld_which is why my pr should not have been landed yet23:13
mwhudsoni am about to upload juju-mongodb3.2 RIGHT NOW!!!one23:13
perrito666wallyworld_: your pr issue has been dealt with23:13
mwhudsonunfortunately it will then sit in NEW for a while23:13
perrito666I am now trying to see mwhudson issue23:13
wallyworld_mwhudson: new or proposed for a while?23:14
wallyworld_should be out of proposed for xenial pretty quickly?23:14
mwhudsonwallyworld_: NEW as in https://launchpad.net/ubuntu/xenial/+queue23:14
* mwhudson afk for 523:14
menn0thumper or wallyworld_: here's the fix for the original bug: http://reviews.vapour.ws/r/4524/23:15
perrito666wallyworld_: axw anastasiamac i am trying to find my laptop for the standup be right there23:15
anastasiamacperrito666: k23:15
wallyworld_menn0: will look after standup23:15
menn0wallyworld_: np23:16
mupBug #1569086 opened: Juju controller CA & TLS server keys are weak <juju-core:New> <https://launchpad.net/bugs/1569086>23:31
mupBug #1569047 changed: juju2 beta 3: bootstrap warnings about interfaces <landscape> <juju-core:New> <https://launchpad.net/bugs/1569047>23:52
ericsnowaxw: re: bug #1566431, unfortunately there's more to it than fiddling with the provisioner-side...tools stuff has to be tweaked as well23:54
mupBug #1566431: cloud-init cannot always use private ip address to fetch tools (ec2 provider) <juju-core:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1566431>23:54
axwericsnow: yeah, doesn't surprise me :/23:54
ericsnowaxw: looks like you had to deal with a related issue last year23:54
axwericsnow: oh? what was that?23:54
ericsnowaxw: https://github.com/juju/juju/blob/master/apiserver/common/tools.go#L35923:55
axwericsnow: ah that comment's just about HA really23:55
ericsnowaxw: the comment applies regardless, I think23:56
axwericsnow: yup23:56
ericsnowaxw: we do the separate "tools URL" thing for the sake of possibly using alternate tools servers, no?23:57
axwericsnow: we've got a very small window to make a breaking change, if we can fix it... :)23:57
ericsnowaxw: yeah :)23:57
axwericsnow: can't remember why, sorry23:57
ericsnowaxw: np23:57
=== ses is now known as Guest97064
axwericsnow: I think that is the case, just to encapsulate that logic for the several places where we need to get tools URLs23:58
axwit may be redundant if we're just returning all the addresses23:59

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