=== fuzzy__ is now known as Poyo === Poyo is now known as Ponyo === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [03:15] morning all [03:44] mattyw: o/ [03:46] anastasiamac, \o [03:49] mattyw: ur morning is my afternoon :D but morning to u nonetheless! [03:50] anastasiamac, http://www.total-knowledge.com/~ilya/mips/ugt.html [03:51] anastasiamac, it's a good point - you're still active in the channel on a sunday afternoon [03:52] mattyw: monday afternoon :D [03:52] mattyw: m k with ugt but [03:52] mattyw: u didn't ugt [03:54] anastasiamac, I thought you were south america? [03:54] mattyw: ug is shorter :D for both start (*universal greeting*) and finish (*universal goodbye*) [03:54] anastasiamac, I'm now starting to think that was wrong [03:55] mattyw: m in Australia [03:55] anastasiamac, monday afternoon makes much more sense to be now :) [03:55] anastasiamac, I'm in Malayia at the moment - but only for the next month - then I'm back in the UK [03:56] mattyw: nice place to spend coldest month of the year :D [03:58] anastasiamac, it's tough working from home ;) [05:43] mattyw: jealous of all the tasty food you're likely eating :( [05:44] axw, The best part is I've still managed to loose weight - it's win win! [05:44] mattyw: hah, winner :) [05:50] anastasiamac: would you mind if we rename the "storage" API to "storagemanager"? there will be a "storageworker" (possibly "storageprovisioner") API, and the names are likely going to get muddled [05:50] axw: +1 to rename but r u sure about "manager'? [05:51] anastasiamac: I'm not fussed on the name, just picked that to go with "usermanager", "environmentmanager", "imagemanager", etc. [05:52] anastasiamac: there's also metricsmanager which doesn't fit the same pattern, and "diskmanager" which should be renamed anyway [05:52] diskmanager's job is now just to publish info on block devices [05:54] axw: what would "manager" be primarily responsible for? crud ops? [05:54] anastasiamac: yep, I think so [05:54] anastasiamac: the user's view into that subsystem [05:55] axw: k. lets rename it to "storagemanager" to align with majority of managers :D [05:55] okey dokey [05:55] axw: hopefully, all the "managers" that do not do crud will be renamed :D [05:56] anastasiamac: that's difficult, since they exist in released code [05:56] well, the metrics one [05:56] the disk one is easy [05:56] axw: my "hopefully" is not prescriptive :) [09:32] dimitern: if you see william around, poke him for me. I'll try to keep an eye out. [09:33] fwereade: apparently invoking your name was enough to wake you up (I just tried to ping your 30s ago :) [09:33] jam, sure [09:33] jam, haha, jolly good [09:33] jam, sorry, my sleep got a bit confused over the flights home [09:33] jam, I *think* I slept more than usual in24h but it's a bit hard to follow [09:34] jam, ah yes and my calendar is still on za time, so I thought we were strting at 11 [09:35] voidspace, hey old chap ;) [09:35] fwereade: I was just about to grab a coffee and a snack, but I'll be back on the hangout in a couple mins [09:35] jam, cool, will be there in a mo [09:36] dimitern: morning [09:36] voidspace, morning! [09:36] voidspace, even though I'm officially off today, I'll be joining the standup to sync up [09:37] dimitern: welcome back to Europe [09:37] dimitern: ah, ok [09:37] dimitern: cool [09:37] dimitern: I'm grabbing coffee, brb [09:37] voidspace, ok [09:39] how's the expert on juju metadata generate-tools? [09:39] s/how's/who's/ [09:39] dimitern, wallyworld [09:42] fwereade, yeah, so since he's off today I guess I need the next guy who knows his way around there [09:42] dimitern, is this the "it generates index not index2" thing or something else? [09:43] dimitern, I might suggest someone from curtis' team, because they're the ones who have to do most of the generating in anger [09:43] fwereade, Muntaner here has issues bootstrapping a private openstack cloud due to not finding the juju tools - he had issues before with images, but that's resolved now and bootstrap launches an instance, but can't find the tools [09:44] logs -> http://paste.ubuntu.com/10139639/ [09:44] fwereade, ok, so just to summarize it for you - generate-tools did create what's needed in the dir, but the tarballs themselves are missing - how should you get them for a stable release? [09:46] guys, I need a review on these PRs - http://reviews.vapour.ws/r/890/ (main one for 1.21), http://reviews.vapour.ws/r/891/ (foreport for 1.22 of the same fix), http://reviews.vapour.ws/r/892/ (foreport for 1.23) [09:46] these fix bug 1418433 [09:46] Bug #1418433: unit ports not populated by API megawatcher

[09:47] dimitern, hmm, I had expected that for a stable release you'd just want to mirror streams.c.c? [09:47] Muntaner, ^^ [09:47] hi fwereade :) [09:47] Muntaner, o/ [09:47] fwereade, that sgtm - so basically download all of it in a local dir and run validate-tools against it? [09:48] fwereade: going a bit crazy with juju + private openstack cloud [09:48] Muntaner, dimitern: it seemed like the lowest-friction thing to do was just to say "mirror streams.canonical.com somewhere your private cloud can see it" [09:49] Muntaner, dimitern: there will surely be cases where that's not good enough, eg if you're testing hotfixes or proposed releases or whatever [09:49] Muntaner, or just put juju-1.21.*.tgz files from http://reviews.vapour.ws/r/892/ [09:50] Muntaner, or just put juju-1.21.*.tgz files from http://streams.canonical.com/juju/tools/releases/ in your local metadata dir at the same path [09:50] sorry, ignore the first url :) [09:50] dimitern: it's fine :) [09:50] I'll try and give feedback now [09:50] Muntaner, cheers [09:50] Muntaner, dimitern: but for the "I just want stable tools" case it's meant to work -- and all the signatures should still match etc so you can still have some confidence in what you're running even though it's not directly from the official source [09:51] Muntaner, dimitern: it would be best of all to use a tools-metadata-url pointing to a local server, rather than keeping it in a local dir, I think [09:52] fwereade: should I do this in environments.yawl? [09:52] what line should I add? [09:52] fwereade, Muntaner, that's if you are willing to do a full mirror of the /juju/tools/ dir from streams.c.c and run a local webserver for them; alternatively you can just generate the tools metadata and copy the tools tarballs in there [09:53] Muntaner, or, maybe even simpler [09:54] Muntaner, have you seen https://juju.ubuntu.com/docs/howto-privatecloud.html#deploying-private-clouds ? [09:54] Muntaner, "For tools, it is often easiest to just mirror https://streams.canonical.com/tools." [09:54] Muntaner, try first of all to specify tools-metadata-url: https://streams.canonical.com/juju/tools in envs.yaml and then bootstrap with --metadata-source [09:54] yes fwereade, but I was following the troubleshooting suggestions by dimitern :) === Tribaal_ is now known as Tribaal [09:55] Muntaner, the doc is the correct source, but it *might* be a bit out of date, if it doesn't work for you as described there we need to file a docs bug to fix it [09:57] Muntaner, so just to be clear: assuming you don't have outside internet access the first thing to try is to mirror streams.c.c on some accessible webserver, and set a suitable value for tools-metadata-url in environments.yaml [09:57] Muntaner, is that failing for you? [09:58] so, my environments.yawl now is: http://paste.ubuntu.com/10139920/ [09:58] gonna run juju bootstrap --metadata-source /home/mike/juju-tools --debug [09:59] Muntaner, ok, give it a try [09:59] Muntaner, I'm not sure you want both of those? [09:59] where oh where has my fwereade gone, where, oh where can he be... :) [09:59] fwereade, he needs the metadata for the images - it's a local openstack [09:59] juju created the vm on my openstack... [09:59] it is running apt-stuff on it [10:00] (communicating via floating-ip) [10:00] installing packages... [10:00] error QQ [10:01] dimitern: fwereade -> http://paste.ubuntu.com/10139949/ [10:04] Muntaner, ok, try tools-metadata-url: https://streams.canonical.com/juju and re-bootstrap [10:04] as far as I can understand... he gets the tools, but fails something else later [10:05] Muntaner, ah, no wait [10:05] dimitern: already got that in environments.yawl :) [10:05] Muntaner, it actually seems to fail finding images [10:06] gtg for now, will come back to you later Muntaner [10:06] maybe should set some other urls in environments.yawl? I remember some tutorial suggesting to do that... [10:09] QQ === ashipika is now known as ashipika|food [10:15] fwereade: in fact, the file http://cloud-images.ubuntu.com/releases/streams/v1/index.json exists, why can't juju read it? [10:19] fwereade: he also is searching for http://cloud-images.ubuntu.com/releases/streams/v1/mirrors.json, which does not exist === ashipika|food is now known as ashipika [10:46] voidspace, btw when you have some time, please have a look at these - http://reviews.vapour.ws/r/890/ (main one for 1.21), http://reviews.vapour.ws/r/891/ (foreport for 1.22 of the same fix), http://reviews.vapour.ws/r/892/ (foreport for 1.23) [10:48] dimitern: ok [10:48] Muntaner, sorry, I'm in a meeting and failing to distribute my attention properly [10:49] fwereade: no problems :) [11:22] dooferlad, hey hey :) [11:23] dimitern: hi :-) [11:23] voidspace, meet the new and improved dooferlad ! [11:23] dooferlad, thanks for doing this! :) [11:24] mgz, hey! o/ [11:24] dimitern: hey! [11:25] mgz, how do you like go-goose? :) [11:25] it's a cute name :) [11:26] dimitern: do you need help migrating the code? [11:26] mgz, yeah :) it became cuter as a side-effect :) [11:27] mgz, I could use some tips to do it faster I guess [11:27] dimitern: if you want, I can do the import and give you the git branch [11:27] if we just want the existing history as per juju-core migration [11:27] mgz, do you like the icon I came up with ? (it took 15m during lunch, but hey - better have one than a blocky generic GH icon) [11:28] yeah, the icon was one of my fav bits :) [11:28] mgz, :D [11:29] mgz, I'd like to keep the history, but we need to migrate the code into a "v1" branch and make that the default, while leaving master alone and putting a "error.go" file that panics in case someone tries to use it (like mgo has) [11:30] dimitern: see lp:~gz/+junk/juju_git_import for instance [11:30] I can do an imports rewrite and then we fiddle with the error.go bit after? [11:31] mgz, awesome, sgtm [11:31] okay, I' [11:31] mgz, do you think we can set up gated merges with the bot relatively easy as well? [11:31] ll adapt that, do the import, then share the branch with you and we can work out what else we needed [11:31] mgz, +1 ta! [11:31] dimitern: that's a little more work, but I have some of the setup for it already [11:32] you'll want to add the juju-bot to the team [11:32] mgz, great, I'll do that then [11:32] mgz, and ask all the hackers to make themselves public for the bot to see them [11:33] mgz, the bot setup can be done in the upcoming days, it's fine - no need to rush it [11:35] dimitern: hehe, nice [11:35] dooferlad: welcome :-) [11:35] voidspace: hi! [11:36] mgz, jujubot is invited in it's own Bots team with write access, like for juju/juju [11:36] dimitern: do, out github path is going to be github.com/go-goose/goose but the imports should be gopkg.in/goose.v1 ? [11:37] dimitern: ta [11:37] mgz, yes, exactly [11:41] mgz, for an easy way to update all imports I used the awesome govers tool rogpeppe1 did [11:43] mgz, dimitern: govers is now at github.com/rogpeppe/govers FWIW [11:44] rogpeppe1, ah, nice - thanks! [11:45] dimitern: github.com/bz2/goose is a first pass import, script for that at lp:~gz/+junk/goose_git_import [11:47] we want to see if there's anything obviously wrong with that, then make any further changes in a new rev and push to the go-goose project - or redo if needed [11:47] mgz, sgtm, looking at those now [11:48] mgz: govers -m github.com/goose gopkg.in/goose.v1 [11:48] hm, seems I didn't get the import renaming somehow [11:48] mgz: also has the advantage that it makes sure that all dependencies are using the same import too [11:48] I'll use rog's thing [11:48] oops [11:49] govers -m launchpad.net/goose gopkg.in/goose.v1 [11:50] mgz, I've created v1 branch from master for go-goose/goose [11:50] rogpeppe1, ta! [11:51] mgz, I think we need it in place before trying to change imports [11:53] well, it's a bit chicken and egg [11:53] just sedding the import paths like I did should make it possible to test locally first [11:53] I'm just confused by the history atm, my commit was wrong... [11:54] missed the -a on commit, rerunning [11:54] mgz, ah, ok [11:55] okay, pushed up new revisions, try again [11:55] that's beetter [11:55] mgz, incidentally, do you have permissions to add dooferlad to juju hackers team? [11:55] sure [11:55] mgz, ta! [11:55] wiiii sosie saco al gaspar [11:55] sorri wrong channel [11:56] perrito667, was that you password ? :D [11:56] dimitern: he's already a member [11:57] mgz, well it doesn't show on his lp page and he can't triage bugs, so I guess something else is wrong [11:57] ah, not github [11:57] mgz, yep, LP [11:57] you mean adding to the ~juju team [11:58] mgz, yes, sorry I should've been more clear :) [11:58] and also I should be an admin there as well hmmm [11:58] I'm not an admin on that one. can bug curtis later or one of the other leads. [11:58] jam, ping [11:58] dimitern: you should now [11:59] mgz, yeah, I'll ask john to add me, thanks [11:59] anybody could http://reviews.vapour.ws/r/889/ ? [11:59] dimitern: couldn't we detect older clients and report port ranges as individual ports? [11:59] dimitern: rather than dropping the ranges [12:00] perrito667, LGTM === perrito667 is now known as perrito666 [12:00] voidspace, we do report ranges that look like single ports into the Ports slice [12:00] voidspace, and that imo is backward-compatible with older clients [12:01] dimitern: still fighting with images metadata [12:01] can you give me some advices? [12:04] Muntaner, have you tried following that section about generating images metadata for private clouds in that docs page? [12:05] fwereade, ping [12:05] yes, totally [12:05] Muntaner, so how far did you manage to go down that path? [12:07] dimitern: brb in 2 hours [12:07] Muntaner, sure [12:07] bye :) [12:09] dimitern: pong [12:09] jam, hey, I've noticed I'm not an admin on LP ~juju so I can't add james to it, can you make me an admin please? [12:10] dimitern: just did both of those things [12:11] fwereade: I'm back around [12:12] jam, thanks! [12:12] dimitern: you may want to independently confirm it :) [12:13] jam, just did [12:20] fwereade, all sorted, please ignore last ping [12:20] voidspace, ah, sorry - now I got what you're asking [12:22] voidspace, and that seems fair, rather than dropping ports add them individually, however that potentially means blowing up the response size with large ranges for the sake of older clients, which will have a few individual ports opened anyway [12:49] dimitern: ah, ok - so you don't need to "detect older clients" as that's what compatiblePorts is for anyway [12:49] dimitern: but if the older client wants to know open ports then shouldn't we tell them? [12:49] voidspace, yes, the older clients will expect Ports to be populated [12:49] my chat window isn't scrolling dammit [12:50] that's why I missed your replies [12:50] voidspace, ah, sorry :) [12:50] dimitern: not your fault... [12:50] dimitern: but if we have a port range open then we won't tell an older client about it [12:50] dimitern: is it alright to just not tell them? [12:50] rest of the PR looks fine including tests [12:51] voidspace, older clients won't use ranges, so if they did open 50, 51, and 52.. hmm I have to check this [12:51] voidspace: you're thinking to map the range into each entry for compat ? [12:51] jam: if 50:52 is open report 50, 51, 52 [12:51] jam: i.e. tell the truth... [12:51] dimitern: I don't know that we need to collapse individual requests into a range, but we should probably return the individual items if a new client opened a range [12:51] voidspace: right [12:51] I think the current behavior is to collapse consecutive ports into a range, so that'll become 50-52 [12:52] jam, yeah, ranges are always there [12:52] voidspace: dimitern: I don't particularly care if we collapse or not, it depends heavily on the close behavior [12:52] IIRC there was a discussion as to whether you have to exact match in a close request [12:52] jam, however, if a newer client opens 5000-6000/tcp and if we list each port individually for the sake of older clients - guess how big the response will be :) [12:52] so if a client does Open(50), Open(51), Open(52), then Close(50) must also work [12:52] whether we represent that as 3 open ports or a range of 50-52 [12:53] dimitern: no bigger than it is today [12:54] jam, but it's much easier to open a huge range with one command today [12:54] how many bytes is a serialised port struct? [12:54] dimitern: again, this is about compatibility [12:54] we deal with it [12:54] a few bytes from the look of it [12:54] new clients won't call the old method [12:54] voidspace, {{Number: 123, Protocol: "tcp"}} x number of ports [12:54] so a thousand is a few kilobytes [12:57] dimitern: voidspace: so yeah, unless there is a really strong problem, I'd just go with "expand port ranges for the compatibility code" [12:57] *especially* if we are auto upgrading [12:57] if you did [12:57] Open(50), Open(51) [12:58] then you better get 50, 51 from "list-open-ports" [12:58] dimitern: I'm failing to trigger the error conditions to test the charmrevisionupdater change [12:58] dimitern: I think we're using a mock api (haven't confirmed that) so setting the env variables fails to cause an error [12:58] voidspace, I'd just mock the updateVersions call to trigger a failure in the test and check the worker exits [12:59] dimitern: ok will do, thanks [13:00] voidspace: dimitern: does my last point make sense? I could sort-of be convinced that if you did a request for a Open 50:52, then maybe the compatible list-ports wouldn't return it (maybe), but *definitely* if we are automatically turning a request for 2 ports to be opened into a range, then we *must* turn a range back into individual items on a list response [13:00] fwereade: are you around yet? [13:00] jam, voidspace, ok, I'll do that instead - return all individual ports in ranges [13:00] cool [13:00] going on lunch [13:00] jam, heyhey, yes I am [13:01] fwereade: I should really go help my son for a sec, but I realized I've been sitting in the room for 30 min and missed the earlier ping. I still want to go over the diff with you, how about in 10 min? [13:01] jam, sgtm [13:01] jam, if you do open(50), open(51), open(52), then close(51), you'll see 50 and 51 as ports in both slices, but if you do open(50-52) you can't close(51) [13:02] dimitern: then why represent it as 50-52 if you can't close it? Is it just a display thing that aggregates the range? [13:02] at least I think you can't - must check the code [13:02] dimitern: I'd really rather not have list return things that you can't then use for close [13:02] jam, because we're representing it as a range, not individual ports [13:02] because I have the feeling that given what you've said [13:03] if you do Open(50), 51, 52. and then you do list and get 50-52, but you can't close(50:52) that's bad [13:03] jam, opened-ports hook tool will return ranges as specified in open-port [13:03] dimitern: do you understand my concern? [13:03] open + opened + close should all work nicely together [13:03] jam, however, if you called open-port 3 times with consecutive numbers, opened-ports will return a collapsed 50-52 range [13:03] changing under the hood is fine, as long as close can still interoperate [13:04] open 50, open 51, open 52, => you must be able to close 51 [13:04] I think we agree on that [13:04] opened => 50:52, you must be able to close 50:52 [13:04] does that also sound sane ? [13:04] jam, yes, and that's how it works for both cases you mention [13:05] dimitern: but open 50, open 51, open 52, then opened returns 50:52, but you can't close 50:52 [13:05] because it doesn't match an open() request [13:05] jam, however the mix of the two - open-port 50-52/tcp then close-port 51/tcp won't work, but opened-ports I believe will return collapsed ranges for the first case (open 50,51,52 individually) [13:06] jam, I have to double-check that case [13:06] dimitern: if I do open(50), open(51), open(52) can I close(50-52) / [13:06] ? [13:06] anyway, I *really* need to go now to catch the bank before it closes [13:06] I *must* be able to close what I open [13:06] jam, I'll verify this as well [13:06] and I *must* be able to close what opened returns [13:06] as long as those two hold true, I don't have a huge care for collapsing vs not [13:08] jam, I agree, and will double check all these cases, then get back to you (tomorrow perhaps) [13:08] dimitern: is there anything else we want to do on the goose repo, before moving it to go-goose? the tests pass locally, I didn't try using it as a replacement with juju-core though [13:08] mgz, well, there will be a few bits we can add post-migration, like CONTRIBUTING.md, README.md, stuff like that [13:09] * dimitern goes out, bbl fwiw [13:52] fwereade: so now I have to do dinner, etc. Are you going to be around later? If you're EOD, then maybe we can just pick up tomorrow? [13:59] jam, I expect I'll be around later, but likely to be off and on slightly at random once laura's home (not so long from now...) === fuzzy__ is now known as Ponyo [14:41] hi devs [14:41] hi dimitern, fwereade [14:50] Muntaner, heyhey [14:51] Muntaner, I should be able to concentrate for a little bit [14:51] Muntaner, what's the latest? [14:51] fwereade: I have fresh logs for you [14:51] I "downgraded" the iso of cloud server to try a workaround [14:51] and get these logs [14:52] fwereade: [14:52] http://paste.ubuntu.com/10143346/ [14:53] envs.yawl -> http://paste.ubuntu.com/10143360/ [14:54] fwereade: the VM is successfully created on the openstack [14:54] and does all the apt-get stuff [14:54] as far as I can see in the logs, it's able to run MongoDB [14:54] but then... that odd error [14:55] need more background, fwereade ? [14:59] fwereade: hard to fix, right? :) [15:06] Muntaner, yeah, I'm scratching my head and hunting through code [15:06] fwereade: is this a mistake in my environment or it's actually juju failing? === negronjl_ is now known as negronjl_afk [15:09] Muntaner, I can't quite figure that out yet, still digging [15:10] Muntaner, I'm a little suspicious about your image-metadata-url (and tools-), though -- I thought you were in an isolated environment? [15:10] fwereade: the thing I can't figure is: how do openstack now which image should instance in the VM if actually fetching of metadata fails? [15:11] well fwereade - I'm with my laptop, connected to the openstack server via Lan (10.0.0.0/24) [15:11] both the machines can naturally go on the internet (the VM created by juju can actually use apt-get stuff) [15:11] I can access VMs via floating IPs, I can ping, ssh them [15:11] and naturally, also the server is contactable [15:15] Muntaner, yeah, that's what's weird -- I can't figure out what you would have started (ie how you got far enough to fail that way) [15:16] Muntaner, ah, ok, I think I see some of it [15:17] Muntaner, with the --metadata-source param you shouldn't need those urls in environments.yaml [15:18] Muntaner, what happens if you just remove them? [15:19] you mean - them in envs.yawl? [15:20] Muntaner, yes [15:20] fwereade: trying it [15:20] Muntaner, I *think* that we're automatically uploading what you need to the right place, but it's not even looking there because it trusts the fields in environments.yaml [15:22] sinzui, ping [15:22] Muntaner, if that works, thank you for finding a bug -- we should at least fail earlier and more clearly if there's no way to sanely handle both those settings [15:22] hi dimitern [15:22] fwereade: not working :( [15:22] seems quite the same log [15:22] sinzui, hey, so re bug 1416928 [15:22] Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents

[15:22] fwereade: http://paste.ubuntu.com/10143716/ [15:23] fwereade: envs.yawl -> http://paste.ubuntu.com/10143723/ [15:23] sinzui, thanks for providing more info [15:24] sinzui, however, I think we shouldn't block 1.21.2 for this bug, I had a chat with xwwt and alexisb in cape town that we can possibly do a subsequent point release with this [15:24] sinzui, that is correct [15:25] sinzui, but I'm interested to hear your thoughts as well [15:25] dimitern, sinzui: We should not block 1.21.2 on this one. We can point release later. [15:25] Muntaner, hmm, I need to dig a bit further, but glad to see you can still launch an instance withoutthose fields [15:25] yep fwereade, but I had to add upload-tools, since I got another error without it [15:25] I'm somewhat confused [15:25] dimitern, I am concerned about multiple releases. But I know stakeholders will appreciate your fix for bug 1416134 [15:25] Bug #1416134: Unable to override network-bridge if container type is kvm (local provider)

Released by dimitern> [15:26] dooferlad, is your fix for bug 1417617 queued for 1.21? [15:26] Bug #1417617: apt-proxy can be incorrectly set when the fallback from http-proxy is used

[15:27] sinzui, yes, that fix among a few other as well - it's still worth releasing 1.21.2 [15:27] sinzui: Hopefully an hour [15:27] dooferlad, sweet! [15:28] dimitern, I will give dooferlad an opportunity get his fix merged and tested while I prepare for a 1.21.2 release to proposed [15:28] thank you sinzui! [15:29] Muntaner, ah, yes, makes sense [15:29] Muntaner, can I see the directory structure for your metadata source please? [15:29] which reminds me to finish the fix for bug 1418433 [15:29] Muntaner, I think I see what's failing [15:29] Bug #1418433: unit ports not populated by API megawatcher