/srv/irclogs.ubuntu.com/2015/08/04/#juju-dev.txt

davechen1ybdx: no00:18
davechen1ybdx: why do you ask ?00:18
mwhudsondavechen1y: rebuild testing suggests that making 'real go' the default  on ppc64 would lead to unhappiness00:21
mwhudsonmostly because of the limited cgo00:21
moqqalexisb: FYI after wrestling around with a failed upgrade-juju its working and the cpu is behaving. will hit up that bug report if anything goes sideways again01:23
davechen1ymwhudson: why do we need cgo ?01:31
mwhudsondavechen1y: "we" as in juju don'01:31
mwhudsont but lots of things in the archive do01:31
davechen1ywhen you say lots01:32
davechen1ycan you quantify ?01:32
davechen1y10,000 packages ?01:32
davechen1y10 packages ?01:32
davechen1yi find it hard to believe that gccgo's cgo support is better ?01:32
mwhudsonin between those01:32
mwhudsoncgo on ppc64el is internal linking only01:32
mwhudsonso it's pretty easy to step outside the bounds of what that can handle01:33
mwhudsoni'll be able to quantify better tomorrow, still lots of builds going01:33
mwhudsonsome of these indeed don't build on ppc64el with gccgo either01:33
davechen1yhttp://paste.ubuntu.com/11997181/01:33
davechen1yoh come on01:34
davechen1ymwhudson: i'm annoyed by this01:34
davechen1ythis is a problem canonical has done to itself01:34
mwhudsondavechen1y: i am also annoyed01:34
davechen1yand if that means we don't get go 1.5 everywhere01:34
davechen1yi will be more than just annoyed01:34
mwhudsona recent go 1.5 change breaks docker and my go tools packages are insane for reasons i don't understand01:35
davechen1ymwhudson: more practically01:35
davechen1yis now the time to suggest taht go versions be versioned in ubuntu in the same way gcc is ?01:35
davechen1yie, go-1.4, go 1.501:36
davechen1ylike we have gcc-4.801:36
mwhudsoni think there is certainly merit in that idea01:36
davechen1yhow do we make that a reality ?01:36
davechen1yit needs to happen immediately01:36
davechen1yie, before the 20th01:36
davechen1yhmm that means they also need to be co installable01:37
mwhudsonyeah01:37
davechen1yand it's going to widen the set of alternatives for who owns /usr/bin/go01:37
mwhudsonit wouldn't be trivial01:37
davechen1yco installable is doable01:37
davechen1ywho owns /usr/bin/go will be more complicated01:38
mwhudsonyeah not super hard, just a bunch of pain01:38
mwhudsonwell that's managed by alternatives now01:38
mwhudson(which is not how gcc does /usr/bin/gcc)01:38
davechen1yyeah01:38
mwhudsonmm01:39
mwhudsonmaybe i should retract my opening statement01:39
mwhudsonso long as go 1.5 builds juju and lxd on ppc64el01:39
mwhudsoni don't know how much of this other stuff we care about01:40
mwhudsonoh01:45
mwhudsonlxd fails to build :(01:45
mwhudsonhttps://launchpadlibrarian.net/213514232/buildlog_ubuntu-wily-ppc64el.lxd_0.14-0ubuntu3_BUILDING.txt.gz01:45
mwhudsonstill if it's just that, we can build it with gccgo01:45
mwhudson(which does work)01:45
davechen1yit doesn't build because go-sqlite3 does not support ppc01:47
davechen1yoh01:47
davechen1ycrap01:47
davechen1yfucking cgo01:47
davechen1ywhy does that encode a database ?01:47
davechen1ywhy does every fucking project have to have a database01:47
davechen1yhow is that helping us, as a species ?01:48
davechen1yhttps://bugs.launchpad.net/juju-core/+bug/148113301:56
mupBug #1481133: version: tests fail on arm64 14.04 <juju-core:New> <https://launchpad.net/bugs/1481133>01:56
davechen1yif this is a test isolation problem I'm going to throw a shoe01:57
mwhudsondavechen1y: i guess there was never a precise for arm64?01:58
mwhudsonif that is the cause, i think shoe-throwing would still be appropriate01:59
davechen1yi'm going to throw both01:59
davechen1yhttps://bugs.launchpad.net/juju-core/+bug/1481133/comments/102:02
davechen1yFML02:02
mupBug #1481133: version: tests fail on arm64 14.04 <juju-core:New> <https://launchpad.net/bugs/1481133>02:02
mupBug #1481133 opened: version: tests fail on arm64 14.04 <juju-core:New> <https://launchpad.net/bugs/1481133>02:10
mupBug #1481133 changed: version: tests fail on arm64 14.04 <juju-core:New> <https://launchpad.net/bugs/1481133>02:13
mwhudsondavechen1y: is the proto-plan to try juju on ppc64 next?02:21
davechen1ymwhudson: i guess02:21
davechen1yactually, yes02:22
davechen1ynow I have the script02:22
mupBug #1481133 opened: version: tests fail on arm64 14.04 <juju-core:New> <https://launchpad.net/bugs/1481133>02:25
=== moqq_ is now known as moqq
axwwallyworld: I'm wanting to add status to volumes and filesystems. what's the appropriate way to marshal that over the API? existing stuff is using api.AgentStatus, which doesn't seem quite right for a non-agent entity... but it is being used for workload and service status too06:41
wallyworldaxw: from memory, that struct grew to accomodate the extra workload status info, somewhat avoiding api churn. it's messy because there's stuff from 1.18, different stuff added in 1.19 which is supposed to be removed, the legacy info for backwards compat, and the new stuff06:44
wallyworldmaybe it's time to bite the bullet and add a new api06:44
axwwallyworld: okey dokey. I'll look into that, thanks06:44
axwkinda what I figured, was hoping I'd overlooked something06:45
wallyworldnah :-(06:45
wallyworldall a bit messy06:45
dimiternwe're using ErrorResults.Combine() now instead of OneError() ?!07:05
dimiternok, only in a few cases it seems, otherwise it would've been *insane*07:06
dimiternfwereade just texted me they have a power cut and he'll come online when he can07:13
voidspacedimitern: is it correct that in EC2 you can have multiple NICs, but only one subnet per machine (even if you have multiple NICs)?07:20
dimiternvoidspace, subnets in ec2 map 1:1 with AZs, so you definitely *can't* run an instance with multiple NICs attached to subnets in different AZs07:23
dimiternvoidspace, it's unclear though if you can run an instance with multiple NICs bound to separate subnets in the same VPC and AZ07:23
dimiternvoidspace, probably not, but it can be verified easily07:24
voidspacedimitern: ok - the network model document states that machines and subnets map 1:1 and you *can't* have multiple NICs bound to different subnets07:27
dimiternvoidspace, we don't intend to allow this initially, yes07:31
dimiternvoidspace, to simplify the implementation, but effectively a machine can end up in multiple spaces and subnets07:31
dimiternvoidspace, so which subnet a machine is in is not the right question to ask, as NICs are bound to subnets, not machines directly07:32
jamdimitern: there was a recent bug that made me think https://bugs.launchpad.net/juju-core/+bug/147866007:32
mupBug #1478660: juju uses proxy to access bootstrap node <juju-core:Fix Committed by cherylj> <juju-core 1.24:In Progress by cherylj> <https://launchpad.net/bugs/1478660>07:32
jamwe should probably be adding the space to the no-proxy list07:32
jamdimitern: ^ what do you think?07:32
voidspacedimitern: right, it's fine to say we don't support it - the doc implies it's an EC2 restriction and that machines map to subnets 1:107:33
voidspacedimitern: I'll add a comment07:33
dimiternjam, is that what we want to do always?07:33
dimiternvoidspace, cheers07:34
jamdimitern: I don't think you want to proxy for things that you consider on your local LAN do you ?07:34
dimiternjam, is this for MAAS or in general?07:34
jamdimitern: in general I'm thinking07:34
dimiternjam, trying to think of scenarios - AWS is different from MAAS for example07:34
jamdimitern: they mentioned working around wget, but ISTM that just fixing our wget is shortsighted07:34
jamdimitern: still, if you're in a space, it seems to define that you have direct access to other things in that space07:35
jamvoidspace: I think the idea right now is that service endpoints map 1:1 to a space, not machines07:35
dimiternjam, that's right, yes it seems we should do what you suggest07:35
dimiternjam, I got confused by client-side proxies for a moment07:35
jamdimitern: so in general, I think we should avoid proxies for things that want to talk to the state server (consider debug-log, or any future file downloads, etc). It may be that we explicitly ignore proxy settings in our code07:36
dimiternjam, and that relates to voidspace's comment yesterday - *thou shalt always be able to connect to any state servers*07:36
voidspacejam: the network model docs state that for EC2 machines map to subnets 1:1 - so a service can only be on one space07:36
voidspace*in one space07:36
voidspacejam: as a machine can only be on one subnet (even with multiple NICs)07:37
jamvoidspace: I do see that text, I haven't expiremented personally to know if it is true, though it might complicate (or maybe simplify) things.07:38
dimiternvoidspace, you mean a machine, not service, right?07:39
dimiternvoidspace, a service spans multiple units (machines in different subnets of the space)07:39
voidspacedimitern: well, you deploy services not machines (well you do both)07:39
voidspacedimitern: so the deploy command can only take one positive space for EC207:40
jamdimitern: page 9 of Network Model Phase 1.1 says machines map to subnets 1:1 verbatim07:40
voidspacedimitern: a service can only be in one space *because* machines can only be on one subnet (i.e. one space)07:40
jamvoidspace: dimitern: it should probably take as long as this discussion to bring up a machine, create 2 subnets in the same AZ, and see if you can attach 2 network interfaces from each subnet to it07:41
voidspace:-)07:41
voidspaceprobably longer for me, but it would be time well spent I think07:41
* dimitern gets increasingly confused07:41
jamvoidspace: I do think that if that constraint is true, we need to think carefully about the ramifications to the network model07:41
dimiternwe need to chat about this at standup07:41
dimiternI'm trying to review a bunch of things and am distracted right now07:42
jamspecifically, if you ever want to separate the ADMIN endpoint for MYSQL onto a separate space from the DB endpoint, then we need to know if that is actually possible.07:42
voidspacejam: the space model seems to only be *really* useful when you can have some of your services on multiple spaces07:42
voidspacejam: and you have firewalling between the spaces07:42
jamvoidspace: well, it can be useful between services (postgres is only in the DB space, and WebApp is in a different space) with custom routing/firewalling07:43
voidspaceright07:43
voidspacewe need to do the custom routing07:43
voidspacefair enough07:43
voidspaceand we also need to do custom routing for the state server07:43
jamso I thought for P1 we still had the flat space for Juju traffic.07:44
voidspacejam: you mean no firewalling?07:44
jamvoidspace: we aren't directly controlling the firewall yet (relations != connections in all cases)07:44
jamvoidspace: but I mean that being in *a* space means you are actually in 2 (the Juju meta space and the explicit one for the service)07:45
voidspacejam: "the Juju meta space" isn't something mentioned in the network doc07:46
voidspacejam: can all machines in every space route to each other through the meta space?07:46
voidspaceas spaces are described as being "a security subdivision of a network" it seems that they only have any reason to exist if traffic between them is restricted / controlled (or am I wrong)?07:47
voidspaceis the "meta space" just a consequence of having no routing restrictions - or is it (or will it be) something else (a specific set of routing rules)?07:48
jamvoidspace: so I think it was a pragmatic decision in first phase to make sure everything can talk to the state server without requiring the server to have an address in every space.07:50
jambut it may have been in conversations and not captured in the doc07:50
voidspaceright07:50
jamit certainly does get us away from strong security if we don't have binding07:51
jam(if your service always binds to all available interfaces, then having an interface on a globally routable space means you lost the security aspect)07:51
voidspacewhich is the raison d'etre for spaces to exist at all :-)07:52
voidspacejam: when I login to the AWS console and then navigate to EC2 I get a "Your service sign-up is almost complete!" message07:55
voidspaceI've tried us-east-1 and us-west-207:55
voidspacejam: could you verify it works for you? (sorry to be a pain)07:55
voidspaceI can try from go-amz instead07:56
jamvoidspace: trying to go in07:56
voidspaceseems like I get the same response from all the AZs07:57
jamvoidspace: I see a juju-env machine running in us-east-107:57
jamm1.small07:57
voidspaceok, must be a problem with my account07:57
jamthough that is via the master account, if you are using an IAM role07:57
jamvoidspace: is it a personal account?07:57
jamor shared?07:57
voidspaceI logged in with the wrong account first (and then signed out) - it maybe a cookie issue07:57
voidspacejam: it's my canonical account07:58
jamvoidspace: interesting, your mfoord user in the shared account has password last used of 2014-1107:58
voidspacejam: odd, I get the same result from another browser too08:00
voidspacejam: gah, user error08:01
voidspacejam: I have a personal account with my canonical email address08:02
voidspacejam: I wasn't using the shared account08:02
voidspacejam: when launching an instance I can create multiple nics bound to different subnets (in the same AZ)08:11
voidspacedimitern: ^^^08:11
dimiternvoidspace, I can't say off hand, but should be easy to verify by using the AWS CLI commands08:18
dimiternvoidspace, or even the web UI08:18
dimiternTheMue, I've responded on your review, but I'm afraid I found even more issues missed earlier, ping me if anything is unclear08:18
TheMuedimitern: ah, great, thank you. just wanted to ping you that I added some questions/remarks. but the I found your mail about the sprint and currently answering it.08:19
dimiternTheMue, cheers08:20
dimiternaxw, are you still around?08:22
dimiternwallyworld, or you?08:22
axwdimitern: I'm here, what's up?08:32
dimiternaxw, I'm reviewing your RB2295 and found out we're now using things like storage.XXXResults similarly to apiserver/params.XXXResults with Error fields08:33
dimiternaxw, but that's in the providers; wasn't clear at first, but I figured it out, sorry for the noise :)08:33
axwdimitern: well, this is the first place it's done AFAIK. I'm trying to enable bulk provider API calls, even though the current ones mostly don't support it08:34
axwdimitern: some do (DestroyVolumes for some), some don't (all CreateVolumes)08:34
axwdimitern: cool, no worries08:35
dimiternaxw, we need this for sure - we can use it for ReleaseAddresses as well for example08:35
axwdimitern: you might be interested in the next branch I put up, which does retries for failed operations. the storage provisioner will include a scheduler for operations, with failed ones being put back on the schedule to retry at a later date08:36
dimiternaxw, think about a few common cases there: retrying transient errors (how to make that easier to convey) as well as a few helpers on the results types that have errors to verify e.g. the number of results == number of args08:36
dimiternaxw, nice! I'll definitely be interested in looking at that08:37
axwhm yes I suppose it should check those things08:37
axwI'm currently relying on the fact that it's all in the same process, so we *should* be able to rely on them doing the right thing08:37
axwbut I could make it more pedantic08:38
dimiternmight be worth it in the face of future extensions to the behavior/implementation08:39
dimiternaxw, it seems a bit unwieldy how ([]error, error) returns are handled - a some common Combine() helper might be useful08:40
axwdimitern: that's a stop-gap. in a follow-up, the individual errors will be used to decide whether or not to reschedule, and they won't surface. a further follow-up will propagate the errors to status08:41
axwso you can see the provisioning error from the CLI08:41
axwI had it as one big branch, but it was >1200 LOC :)08:41
dimiternwow :)08:42
dimiternaxw, ok, I'll follow the follow-ups then08:42
axwdimitern: thanks for the review08:52
dimiternaxw, thanks for starting to solve the retrying in general for providers :)08:53
voidspacedimitern: I have verified it!08:57
voidspacedimitern: I was saying I *can* create an instance with multiple nics on different subnets08:57
dimiternvoidspace, ah, I see08:59
dimiternvoidspace, well that's AWS, in other clouds we'll have different constraints like this, OpenStack being an example of almost "all is allowed" sort of cloud09:00
voidspaceTheMue: dooferlad: stdup?09:02
TheMuevoidspace: omw, fetch a coffee09:02
TheMuefetched09:02
=== Spads_ is now known as Spads
perrito666morning all11:02
TheMueheya perrito66611:06
dimiternperrito666, hey, my fellow OCR :)11:09
* perrito666 feels something coming his way11:10
dimiternperrito666, I've left you the best review of all - william's final leadership one11:10
* dimitern ducks11:10
dimitern:)11:10
perrito666dimitern: aren t you a sweetie11:11
dimiternperrito666, I'll buy you a beer on the next sprint hehe11:11
perrito666ill make some coffee before this11:11
wwitzel3ericsnow: ping11:19
dimiterndooferlad, I think the build errors you're getting might be due to the "type SpaceDoc spaceDoc" definition in export_test.go (or something else like this when only happens while running tests)11:56
perrito666dimitern: well it was the second time around most of these changes11:59
perrito666which made them a bit easier11:59
dimiternperrito666, I've been on some of the previous ones as well, but there are new things there as well12:00
perrito666dimitern: yep, but still much better than the first time12:00
perrito666:)12:00
* dimitern found out this background music makes it a *lot* easier to go through reviews :) https://www.youtube.com/watch?v=exWNztpgfIw12:01
perrito666dimitern: sounds like it would make you shoot at the review at some points12:03
dimiternperrito666, it occasionally does, yes :)12:04
dooferladdimitern: the code builds fine here. Very strange12:22
dooferladdimitern: in fact I have 100% tests passing, and I have rebased on upstream so I should have identical code.12:22
dooferladdimitern: maybe a go version thing? I am on 1.4.212:26
dimiterndooferlad, I'm on 1.2.1 which is the same CI uses IIRC, I'll pull your branch and try it here12:26
dooferladdimitern: thanks. I thought we had moved to 1.4.2. Guess not. Are we waiting for 1.5?12:30
dimiterndooferlad, we are12:30
dimiterndooferlad, but it's useful to have a mix of versions until then, just for such issues12:30
voidspacedooferlad: ping12:31
dooferladvoidspace: hi12:31
voidspacedooferlad: hey, you available to hangout?12:31
dooferladvoidspace: yea, I can come back to this.12:32
voidspacedooferlad: cool, stdup hangout?12:32
dooferladsure12:33
dimiternmgz, ping12:38
dimiterndooferlad, btw while looking at the changes your branch introduced - https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-state-add-space I noticed the last change - removing Assert: isAliveDoc from Subnet.EnsureDead() - why is that?12:56
dooferladdimitern: odd.12:56
voidspacedimitern: must spaces list be a bulk call?12:56
dimiternvoidspace, I don't think so, but it should take filters12:57
voidspacedimitern: what do you mean by filters?12:57
voidspacedimitern: filtering output by name or something?12:57
voidspacedimitern: the CLI doesn't have filters (like that)12:58
dimiternvoidspace, let me double-check the model12:58
* voidspace too12:58
dimiternI might be thinking of subnet list12:58
voidspacedooferlad: the juju command is actually "space" rather than "spaces"12:59
voidspacedooferlad: so "space" seems more correct12:59
voidspacesubnet list hasn't been done yet13:00
dimiternvoidspace, no filters for space list13:00
voidspaceso I can't just copy it13:00
voidspacedimitern: yeah13:00
dimiternvoidspace, the --short argument is purely a CLI thing - we still get all the details from the API13:01
voidspacedimitern: ok13:01
voidspacedimitern: and what about format?13:01
voidspacedimitern: do we do that on the server?13:01
voidspaceI'll find another list cli command and look at that13:01
dimiternvoidspace, how about this? http://reviews.vapour.ws/r/1390/13:02
dimiternvoidspace, the format is also a CLI thing13:02
voidspacedimitern: yeah, I meant the apiserver bit13:02
voidspacedimitern: thanks though, worth looking at13:02
dimiternvoidspace, ah, yeah - no apiserver support for listing spaces, but it should just call Backing.AllSpaces13:03
voidspacedimitern: so if format, output and short are all handled on the client - ListSpaces takes no arguments13:04
dimiterndooferlad, please reintroduce that assert13:05
dooferladdimitern: will do. Did you have any problems with go 1.2?13:05
dimiternvoidspace, yeah13:05
dimiterndooferlad, tests are still running - so far a few failures which look like flakyness13:06
mgzdimitern: hey13:18
dimiterndooferlad, passed the cmd package where the build issue happened on the CI machine - no issues13:18
dooferladdimitern: I thought the problem was in state.13:18
dimiternmgz, hey, I'm trying to analyze why this merge fails with such an odd error: http://juju-ci.vapour.ws:8080/job/github-merge-juju/4188/consoleFull13:18
dooferladdimitern: you could "cd state; go test -c" to check for a compile error13:18
dimiternmgz, it's happening a few times now and both I and dooferlad get no errors when running tests with the same branch locally, I'm on 1.2.1, he's on 1.4.213:19
mgzdimitern: that's not one I've seen before13:19
dimiterndooferlad, I know, but just in case it's some weird issue which *only happens* under load or when running the full suite..13:19
dimiternmgz, can you force the instance to stay after the tests fail, so we can get in and inspect it?13:20
mgzhm, I should just attatch the tarball as an artifact13:24
mgzugh, that branhc adds more ConnSuite derived tests?13:26
mgzdimitern: I bet the problem is the export_test13:27
dimiternmgz, that's what I suspected, but there's no redefinition of that type there13:28
mgzI am surpised it worsk for you on 1.21 but not on the clean instance for the bot13:29
dimiternmgz, and since #testmain is involved, I strongly suspect it's actually due to the way we're running CLI tests (another possibility is a dirty GOPATH on the CI instance)13:29
mgzdimitern: try running `make check` and see if you get it?13:30
dimiternmgz, I did, it's running for a while now13:30
dimiternmgz, and there it is! I've reproduced it (in a different package, but that's due to suites running in parallel I guess)13:31
dimiterndooferlad, I've got a repro13:31
dooferladdimitern: sweet!13:31
alexisbkatco, are you in today?13:32
katcoalexisb: i am :)13:34
dimiterndooferlad, now running go test ./... in cmd/juju to see if that triggers it13:39
dimiternincredibly annoying :(13:41
dimiternit's not that then trying cmd/jujud/13:42
dimiterndooferlad, I managed with go test -c in state/13:44
katcodimitern: perrito666: more input needed on this: http://reviews.vapour.ws/r/2199/13:47
dimiternkatco, ack, will look shortly13:47
dimiterndooferlad, found a workaround13:48
perrito666katco: will look13:49
dimiterndooferlad, if you change "func (s *Space) Doc() spaceDoc { return s.doc }" to "func SpaceDoc(s *Space) spaceDoc { return s.doc }" (and the tests from space.Doc().X to state.SpaceDoc(space).X) it builds ok here13:50
dimiterndooferlad, amazingly it doesn't complain about spaceDoc not being exported, which I expected13:50
dimiternoh boy PowerShell13:51
dimiterngsamfira, ping :)13:51
dimiternperrito666, I'm with you on that one re PS13:52
perrito666dimitern: ?13:53
dimiternperrito666, about http://reviews.vapour.ws/r/2199/13:54
dimiternkatco, replied, if somewhat unhelpfully I guess13:56
dooferladdimitern: thanks. Just setting up a container to let me test in a clean environment before I try and merge again, (trusty + default go)14:01
dimiterndooferlad, +114:02
mupBug #1481366 opened: leader-get may fail in -departed hooks <juju-core:New> <https://launchpad.net/bugs/1481366>14:06
katcoalexisb: hey i'm out tomorrow14:08
alexisbkatco, ok np14:09
alexisbI need to catch pat before she goes on vacation, so just decline the call14:09
katcoalexisb: k will do14:10
katcoalexisb: just lemme know what you need from me14:10
perrito666katco: that patch is still a hughe powershell blob, I have no idea what is going on inside14:28
mupBug #1481368 opened: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down <canonical-bootstack> <deploy> <state-server> <juju-core:Triaged> <https://launchpad.net/bugs/1481368>14:30
alexisbperrito666, ping16:03
perrito666alexisb: pong16:18
perrito666sorry was having lunch16:18
alexisbperrito666, no worries16:18
alexisbI saw https://launchpad.net/bugs/1481368 come in on the proposed 1.24.416:18
mupBug #1481368: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down <canonical-bootstack> <deploy> <state-server> <juju-core:Triaged> <https://launchpad.net/bugs/1481368>16:18
alexisblooks to potentially be status related16:18
* perrito666 checks16:18
alexisbwas curious on your perspective16:19
perrito666alexisb: mm, I think it might be something else being masked by status16:22
alexisbperrito666, katco, cherylj, wwitzel3, ericsnow, natefinch if someone has free cycles https://launchpad.net/bugs/1481368 needs to be worked16:30
mupBug #1481368: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down <canonical-bootstack> <deploy> <state-server> <juju-core:Triaged> <https://launchpad.net/bugs/1481368>16:30
katcoalexisb: might be possible later. today is moonstone's catchup+planning day16:30
katcoalexisb: since i was out on fri.16:31
alexisbkatco, ack16:31
cheryljalexisb: I can take a look in a few16:35
alexisbcherylj, thank you as always16:38
=== Guest47499 is now known as anthonyf
=== anthonyf is now known as Guest410
=== Guest410 is now known as anthonyf
=== anthonyf is now known as Guest26675
sinzuicherylj: I am trying to force CI to retest your commit to master.19:23
cheryljsinzui: for bug 1480298?19:24
mupBug #1480298: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Fix Committed by cherylj> <https://launchpad.net/bugs/1480298>19:24
sinzuicherylj: yes. the branch failed because of a logging test that may have been intermittent19:26
cheryljah, ok19:26
mbruzekHello core devs.  Someone is setting up a network for a conference and wants to know all the ports to open to get Juju to work.  I know about 22 and 37017 and 38017, are there any other ones that I am forgetting?20:31
mbruzekwhen I do a google search for juju ports I only get the open ports for charms.20:31
katcowwitzel3: ericsnow: we'll delay the remainder of planning until thurs. do you feel like you have a good idea of what to work on tomorrow?20:37
ericsnowkatco: yep20:37
ericsnowkatco: I also did my best to flesh out the cards we have20:37
katcoericsnow: awesome ty20:37
mbruzekThe default port numbers for api-port, state-port, and storage-port are 17071, 37017, and 8040 respectively.20:42
wwitzel3katco: yep, sounds good20:56
wwitzel3ericsnow: thanks :)20:56
perrito666menn0: ping21:16
menn0perrito666: sorry, in standup21:19
perrito666menn0: np, just ping me when you have a moment plz21:42
menn0perrito666: ok i'm done. what's up/22:06
perrito666you dont seem happy to see me :p22:06
perrito666ill go priv so I have proper logs to read after22:07
mupBug #1481500 opened: automatic devel streams selection for beta releases <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1481500>22:16
perrito666aghh my fix depends on fwereade patch23:00
alexisbperrito666, this one:   https://github.com/juju/juju/pull/290923:14
perrito666yeah, I am trying to make a patch for it23:14
perrito666alexisb: mm, it seems he did not fwport all of it, ill propose a patch tailored to master23:17

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