| rick_h_ | thumper-gym: hey, tracking the debug-log work. Is that branch you've got proposed the final? | 00:35 |
|---|---|---|
| davecheney | o/ thumper-gym | 00:38 |
| === thumper-gym is now known as thumper | ||
| thumper | hi davecheney | 01:29 |
| davecheney | thumper: o/ | 01:31 |
| davecheney | re that that change to peergrouper | 01:31 |
| davecheney | i thought it was a fix | 01:31 |
| davecheney | but it just made things more confusing | 01:31 |
| thumper | heh | 01:31 |
| davecheney | rog says that the peergrouper shold return things in order | 01:31 |
| davecheney | but it doesn't | 01:31 |
| davecheney | even fixing the mock server to make it respect order doesn't return things in order | 01:31 |
| davecheney | so I don't know what to do | 01:31 |
| davecheney | if order is important to the operation of the peergropuer | 01:31 |
| davecheney | then there is a problem | 01:31 |
| davecheney | if its not | 01:32 |
| davecheney | then we can just go back to my previous commit | 01:32 |
| davecheney | s/commit/proposal | 01:32 |
| davecheney | the point is, both proposals can't be right or wrong | 01:32 |
| waigani | hi all :) | 01:34 |
| thumper | o/ waigani | 01:35 |
| davecheney | waigani: thumper http://paste.ubuntu.com/7215168/ | 02:02 |
| davecheney | getting there, slowly | 02:02 |
| waigani | davecheney: I've been out of action sorry, getting back into it now | 02:02 |
| davecheney | waigani: no worries | 02:07 |
| waigani | davecheney: fyi I put up a wip at the end of last week: https://codereview.appspot.com/84360043. I'm just reading it now to remind myself where I was at. | 02:08 |
| davecheney | waigani: i can't reproduce the issue | 02:18 |
| davecheney | do you have the latest gccgo and gccgo-go ? | 02:18 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core/provider/local$ go test . | 02:21 |
| davecheney | ok launchpad.net/juju-core/provider/local 30.707s | 02:21 |
| waigani | davecheney: oops, just saw your message hmm | 02:27 |
| waigani | i can't reproduce it now either. Though when I run make check I'm hitting nil pointer panics. - something to do with mongo being checked for | 02:30 |
| davecheney | waigani: can you paste waht you see ? | 02:30 |
| davecheney | waigani: do you have a /usr/bin/mongod ? | 02:31 |
| davecheney | i suspect you will not | 02:31 |
| waigani | davecheney: http://pastebin.ubuntu.com/7215232/ | 02:31 |
| waigani | davecheney: ah, I'll have a look - I need to run to a standup now | 02:31 |
| waigani | bb in 30min | 02:31 |
| waigani | davecheney: I do not have /usr/bin/mongod. I am confused as I thought that mongod was a dependancy of juju-local, which I do have. | 02:54 |
| waigani | davecheney: I thought the idea was to add juju-local to install-dependencies in the Makefile and check only for juju-local as mongod would be installed as a dependency of juju-local | 02:56 |
| waigani | davecheney: though I may very easily got that wrong - thumper? | 02:57 |
| thumper | I'm busy responding | 02:57 |
| thumper | please hold | 02:57 |
| davecheney | waigani: there is a bug | 03:02 |
| davecheney | you need to symlink /usr/lib/..../mongod to /usr/bin | 03:02 |
| waigani | davecheney: ah okay | 03:03 |
| waigani | davecheney: if this is a bug, does it make sense for me to fix it in this branch? As it now relies on mongod being installed correctly as a dep. | 03:04 |
| waigani | s/it/we | 03:04 |
| waigani | wallyworld_: is the simplestreams a universal metadata format juju specific? | 03:06 |
| wallyworld_ | universal | 03:06 |
| waigani | hmm, how did I miss that? I'll have to read up. | 03:06 |
| wallyworld_ | from the project page on lp | 03:06 |
| wallyworld_ | Simple Streams describe streams of like items in a structural fashion. | 03:06 |
| wallyworld_ | A client provides a way to sync or act on changes in a remote stream. | 03:06 |
| wallyworld_ | It's been used to described cloud images which we just happen to make use of in Juju | 03:07 |
| waigani | ah, that helps, thanks | 03:07 |
| waigani | Does the server API rely on it? | 03:08 |
| waigani | anyway, I shouldn't distract you - I'll read up :) | 03:08 |
| thumper | davecheney, waigani: there is another problem with the tests on trusty, in that they should use the juju-mongodb mongo, and not the mongodb-server mongo | 03:09 |
| waigani | thumper: okay, I'll update my branch | 03:10 |
| waigani | thumper: your comment about cloud-init. I don't understand? | 03:28 |
| thumper | waigani: hangout? | 03:30 |
| waigani | sure | 03:30 |
| waigani | give me a sec | 03:31 |
| davecheney | thumper: yes, exactly | 03:31 |
| waigani | thumper: got a link? Tried calling via hangs, no luck. | 03:33 |
| * thumper goes through axw's review comments | 03:53 | |
| axw | btw I have been through the tests now, and just had the one additional comment - expect no more pedantry :) | 03:53 |
| axw | until you reply at least | 03:53 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core/provider/openstack$ go test | 03:54 |
| davecheney | OK: 53 passed, 5 skipped | 03:54 |
| davecheney | PASS | 03:54 |
| davecheney | ok launchpad.net/juju-core/provider/openstack 59.350s | 03:54 |
| davecheney | \o/ | 03:54 |
| davecheney | gentlemen, we have TWO (at least) ways of creating fake tools | 03:54 |
| davecheney | everyone should feel ashamed of themselves | 03:54 |
| thumper | davecheney: only two? | 03:56 |
| thumper | axw: wondering about agent vs. entity | 03:56 |
| thumper | axw: the log files are agregated by agent | 03:56 |
| thumper | for now at least | 03:57 |
| thumper | I'll change to entity | 03:57 |
| thumper | just because I think it makes more sense | 03:57 |
| thumper | we can work out what to do later when we merge the unit agents into the machine agent | 03:57 |
| davecheney | thumper: i'd be fine with N, where N was the number of providers | 03:57 |
| davecheney | but it's two | 03:57 |
| axw | thumper: thanks | 03:58 |
| axw | thumper: that'll be "interesting" :) | 03:58 |
| thumper | davecheney: I think it would be N where N is the number of developers who have needed it :-) | 03:58 |
| davecheney | thumper: well played | 03:58 |
| * davecheney runs go test ./... and goes to make lunch | 03:58 | |
| * davecheney throws a chair | 04:16 | |
| davecheney | everywhere we use version.Current | 04:17 |
| davecheney | that should be a version number, not a full number/arch/series | 04:17 |
| thumper | axw: refactoring the authentication may be bigger than I want | 04:19 |
| thumper | I'll attempt it | 04:19 |
| thumper | and see how massive it is | 04:19 |
| axw | mk | 04:19 |
| thumper | I didn't know it was a copy | 04:19 |
| thumper | was in the work I was passed | 04:19 |
| axw | ah right | 04:19 |
| tvansteenburgh | thumper: i'm looking at https://bugs.launchpad.net/juju-core/+bug/1302935 | 04:26 |
| _mup_ | Bug #1302935: trusty local provider unit agents stuck pending <deploy> <local-provider> <lxc> <juju-core:Incomplete by thumper> <https://launchpad.net/bugs/1302935> | 04:26 |
| tvansteenburgh | `sudo lxc-ls` returns 'juju-precise-template' | 04:26 |
| thumper | axw: which is better `maxLines value "foo" is not a valid unsigned number` or `maxLines value "foo" is not a valid unsigned number: strconv.ParseUint: parsing "foo": invalid syntax` | 04:26 |
| thumper | tvansteenburgh: yeah... | 04:26 |
| tvansteenburgh | do i need to kill that somehow? | 04:27 |
| thumper | no, it makes no difference | 04:27 |
| thumper | it is filtered out before anyone cares | 04:27 |
| waigani | What write permissions should /usr/lib/juju have? | 04:27 |
| thumper | waigani: why? | 04:27 |
| thumper | 0755 at least | 04:28 |
| axw | thumper: I see, fair enough :) | 04:28 |
| axw | leave it then | 04:28 |
| waigani | thumper: http://pastebin.ubuntu.com/7215512/ | 04:28 |
| tvansteenburgh | thumper: hrm, not the answer i was hoping for. i deleted the trusty lock file, redeployed, and same result. i'll post the new log file | 04:28 |
| waigani | it seems the dirs can be created, no problem | 04:29 |
| thumper | tvansteenburgh: how long did you wait? | 04:29 |
| thumper | tvansteenburgh: for me to create a new template, and start it, it took over 5 minutes | 04:29 |
| * tvansteenburgh turns suddenly sheepish | 04:30 | |
| tvansteenburgh | thumper: you're right, now it's all started up | 04:30 |
| tvansteenburgh | sorry :( | 04:30 |
| thumper | tvansteenburgh: the slow startup is just the first time the template is started | 04:30 |
| thumper | tvansteenburgh: that is fine | 04:30 |
| thumper | we should communicate this more clearly | 04:30 |
| thumper | tvansteenburgh: it will be much faster now :-) | 04:31 |
| thumper | tvansteenburgh: on my todo list is a plugin command to create the template out of band | 04:31 |
| thumper | with more feedback | 04:31 |
| thumper | so you can see what is going on | 04:31 |
| tvansteenburgh | cool. unfortunately i would have never figured out the lock file thing on my own | 04:31 |
| thumper | yeah, another problem with communication I think | 04:31 |
| tvansteenburgh | but now i know, so thanks for that | 04:32 |
| thumper | we should be aware that people will kill it in the middle there | 04:32 |
| tvansteenburgh | i guess i killed it at some point, but didn't even remember that | 04:32 |
| thumper | axw: I'm up for ideas on how we can make the destroy environment call on Ctrl-C remove the lock file if it created one | 04:32 |
| thumper | tvansteenburgh: this is good feedback though | 04:33 |
| thumper | don't feel sheepish | 04:33 |
| axw | thumper: which lock file is that? | 04:33 |
| thumper | axw: when we create a new lxc template for a series | 04:33 |
| thumper | axw: it can take a while | 04:34 |
| thumper | we take a fslock | 04:34 |
| axw | thumper: is there a reason we don't just use flock? then we wouldn't have this problem, because nobody would be holding the lock | 04:35 |
| thumper | axw: I'm sure there was originally, but now I'm not so sure... | 04:36 |
| wallyworld_ | hazmat: you online? | 04:38 |
| axw | thumper: otherwise it'll get messy if you want to handle multiple users concurrently trying to add containers in different environments | 04:40 |
| axw | which is why it's in /var/lib/juju, rather than data-dir, I presume | 04:40 |
| thumper | yeah | 04:40 |
| axw | can't just blow it away; you'd probably want to record the PID, and check if it's alive, etc. | 04:41 |
| thumper | meh... add it to the todo list | 04:43 |
| * thumper is refactoring http auth rubbish | 04:43 | |
| * davecheney consoles thumper | 04:43 | |
| waigani | wip: https://codereview.appspot.com/84360043/ | 04:47 |
| thumper | axw: refactored the auth code | 04:59 |
| thumper | axw: reusing the httpHandler now | 05:00 |
| axw | thumper: cool, thanks | 05:00 |
| thumper | just waiting on lbox now | 05:00 |
| * axw looks forward to cutting out that particular bottleneck | 05:01 | |
| axw | takes 5-10 mins for me sometimes... | 05:02 |
| thumper | geez, how to freak out people: http://www.dailydo.co.nz/garden/glowgravel495499?utm_source=Dunedin&utm_campaign=b90cc26652-Dunedin+2014-04-07&utm_medium=email&utm_term=0_4768a78a2f-b90cc26652-280945562 | 05:02 |
| axw | thumper: ah yeah, I forgot NewTailer starts immediately. thanks, start makes that clearer | 05:06 |
| thumper | np | 05:11 |
| davecheney | https://codereview.appspot.com/84860046 | 05:18 |
| davecheney | if anyone has time | 05:18 |
| thumper | davecheney: lgtm | 05:18 |
| === vladk|offline is now known as vladk | ||
| davecheney | thumper: ta | 05:24 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| vladk | jam: I will be available at 10:10 for hangout, sorry | 05:27 |
| === vladk is now known as vladk|offline | ||
| dimitern | morning all | 05:56 |
| thumper | hmm... dimitern is here... | 05:57 |
| thumper | time to leave | 05:57 |
| thumper | o/ dimitern | 05:57 |
| dimitern | hey thumper | 05:57 |
| === vladk|offline is now known as vladk | ||
| dimitern | hey jam1 | 07:17 |
| dimitern | jam1, it seems my ssh key is missing from the bot - can't login | 07:18 |
| jam1 | dimitern: hmm... I'll go check | 07:26 |
| dimitern | jam1, thanks | 07:26 |
| jam1 | dimitern: dimitern@kubrik is on the bot, are you sure you're connecting as the "ubuntu" user? | 07:28 |
| dimitern | jam1, yes | 07:28 |
| dimitern | jam1, https://pastebin.canonical.com/107836/ | 07:29 |
| jam1 | dimitern: that is machine-0, I wouldn't expect you to be able to connect there, just machine 1 @ 118 | 07:30 |
| rogpeppe | mornin' all | 07:41 |
| wallyworld_ | fwereade: got time for a quick implementation discussion? | 07:41 |
| voidspace | rebooting :-) | 08:41 |
| vladk | dimitern: good morning | 08:49 |
| dimitern | vladk, morning | 08:50 |
| vladk | I need to get all MACs related to node via MAAS interface, I know http://paste.ubuntu.com/7216131/, but it does not return MAC addresses | 08:51 |
| dimitern | vladk, I'm working on reading the node hardware list (xml output of lshw), which contains all ethernet cards and their interface names and mac addresses | 08:52 |
| vladk | dimitern, cool, it is very convenient to know device names, instead of their MAC addresses | 08:53 |
| dimitern | vladk, I'll propose it a bit later then I'm done and send you a link if you like | 08:54 |
| vladk | can I expect something like 'NetworkInfo struct' before newCloudinitConfig call? | 08:54 |
| dimitern | vladk, StartInstance will gather the networkining info and return it, but will populate machine config with the necessary info so newCloudinitConfig can prepare the scripts | 08:56 |
| vladk | Why not to get that information from commissioning stage. I really need network information before cloudinit | 08:59 |
| vladk | dimitern: ^ | 08:59 |
| dimitern | vladk, that's exactly where we're getting the info from | 09:00 |
| dimitern | vladk, it's before cloudinit | 09:00 |
| vladk | dimitern: now, I am trying to use mgz's GetNetworksList function that uses above API call, so it becomes useless | 09:02 |
| mgz | morning all | 09:02 |
| dimitern | morning mgz | 09:02 |
| dimitern | vladk, we need the result of GetNetworksList to get the network details - also part of []NetworkInfo returned by StartInstance | 09:03 |
| dimitern | vladk, so []NetworkInfo is populated by GetNetworksList and the new call that returns NIC details for a node | 09:04 |
| vladk | mgz, morning | 09:04 |
| vladk | dimitern, mgz: I fixed GetNetworksList, it assumes that VlanTag is string but it is a number or null in JSON, so I'm going to create a merge request | 09:09 |
| dimitern | vladk, great, thanks! | 09:10 |
| vladk | do I need to create a bug in LP or card in kanban? | 09:10 |
| vladk | dimitern: ^ | 09:11 |
| mgz | vladk: a card wouldn't hurt | 09:12 |
| jam1 | rogpeppe: I made it back, care to join the hangout? | 09:12 |
| jam1 | morning mgz | 09:12 |
| rogpeppe | jam1: standup hangout? | 09:13 |
| jam1 | rogpeppe: our 1:1 hangout | 09:13 |
| rogpeppe | jam1: ha! 1-1! | 09:13 |
| rogpeppe | jam1: joining | 09:13 |
| dimitern | vladk, card is fine | 09:14 |
| dimitern | vladk, you could add a bug as well, but in this case i don't think it's worth it | 09:14 |
| fwereade | rogpeppe, would you take a look at https://codereview.appspot.com/84430044/ please? I don't quite see what's going on there | 09:32 |
| jamespage | fwereade, quick question - what should the behaviour of upgrade-juju look like with a 1.18.0 client against a 1.17.7 environment? | 09:49 |
| jamespage | fwereade, also noted this potential upgrade problem - bug 1303697 | 09:57 |
| _mup_ | Bug #1303697: peer relation disappears during upgrade of juju <juju-core:New> <https://launchpad.net/bugs/1303697> | 09:57 |
| fwereade | jamespage, the env should be upgraded to 1.18.0, does that not happen? | 09:58 |
| jamespage | fwereade, without --version 1.18.0 it did not | 09:58 |
| fwereade | jamespage, I *thought* we were upgrading from dev to stable without explicit args, but I may have missed something -- dimitern, can you comment? | 09:59 |
| fwereade | jamespage, and that bug is weird, I will peer closer | 09:59 |
| jamespage | fwereade, thanks | 09:59 |
| dimitern | fwereade, the original logic was to try to upgrade to the next stable without --version | 10:00 |
| dimitern | fwereade, (or current) | 10:00 |
| dimitern | jamespage, did you use --upload-tools ? | 10:01 |
| fwereade | dimitern, I thought so too, do you recall anyone working on that subsequently? | 10:01 |
| mgz | jam: 1:1! | 10:01 |
| jamespage | dimitern, nope | 10:02 |
| dimitern | fwereade, not that i know of | 10:02 |
| jamespage | dimitern, I saw the same with both maas (using streams.canonical.com) and openstack (using a local mirror of streams.canonical.com) | 10:02 |
| jam | yep, be there in 1sec | 10:02 |
| jam | mgz: ^^ | 10:02 |
| mgz | cool | 10:02 |
| dimitern | jamespage, did you try --debug to see what's going on? | 10:04 |
| jamespage | dimitern, I did not | 10:04 |
| jamespage | dimitern, I did hop onto the bootstrap node and looked at the log - messages about it picking 1.17.7 | 10:04 |
| dimitern | jamespage, hmm... weird | 10:04 |
| rogpeppe | fwereade: sorry, was in a call with john. looking. | 10:05 |
| fwereade | jamespage, I don't suppose you have the unit agent log from lp:1303697 ? | 10:10 |
| jamespage | fwereade, lemme check | 10:10 |
| mgz | c'mon internet | 10:11 |
| rogpeppe | fwereade: i'm not sure i see what's going on either | 10:15 |
| rogpeppe | fwereade: in the comment i made in the previous review, i was talking about address order *within* a machine, not the order of machinesw | 10:15 |
| jam | bug 1303697 | 10:19 |
| _mup_ | Bug #1303697: peer relation disappears during upgrade of juju <juju-core:New> <https://launchpad.net/bugs/1303697> | 10:19 |
| fwereade | jamespage, ok, I can see why the juju run could have failed | 10:24 |
| fwereade | jamespage, in fact I suspect an ill-timed one could have panicked the unit agent, hence the second config-changed | 10:25 |
| fwereade | jamespage, root cause remains unclear | 10:25 |
| jamespage | fwereade, the call in the charm pretty much does the same thing in the config-changed hook | 10:25 |
| fwereade | jamespage, yeah, but it turns out we start listening for juju run commands while the uniter is less than half initialized | 10:28 |
| fwereade | jamespage, but I can't see that code path that would allow a config-changed hook to berun in those circumstances | 10:28 |
| perrito666 | good morning everyone | 10:30 |
| jamespage | fwereade, it looks like it runs multiple times | 10:30 |
| jamespage | I had to resolve it twice | 10:30 |
| jamespage | fwereade, and I'm def not changing the config :-) | 10:31 |
| fwereade | jamespage, config-changed runs every time the unit agent restarts | 10:32 |
| mgz | hey perrito666 | 10:32 |
| jamespage | fwereade, ah | 10:32 |
| fwereade | jamespage, and that juju-run could easily have bounced the agent, because the code is decidedly unsafe | 10:33 |
| jamespage | fwereade, right - I see | 10:33 |
| jamespage | fwereade, I'm less worried about the juju run failing and more worried that whenever I upgrade juju, keystone will hook error as its can't access the peer relation :-) | 10:34 |
| fwereade | jamespage, indeed, that's why I'm stillpoking around | 10:34 |
| jamespage | fwereade, OK - I'll get out of your hair then :-) | 10:34 |
| fwereade | jamespage, I'd still love to see the agent log if you have it :) | 10:35 |
| jamespage | fyi I've tested on openstack and local for trusty; just validating against the lastest maas | 10:35 |
| jamespage | fwereade, I'll repro that for you now | 10:35 |
| * jamespage downgrades and pushed the car backup the hill | 10:39 | |
| fwereade | jamespage, I doubt that behaviour would vary by provider | 10:41 |
| jamespage | ok | 10:41 |
| fwereade | jamespage, I consider it a big deal anyway ;) | 10:41 |
| jamespage | fwereade, I'm reproducing on openstack as that is quicker | 10:41 |
| fwereade | jamespage, cool | 10:42 |
| dimitern | fwereade, rogpeppe, mgz, jam, wallyworld, standup | 10:45 |
| jam | rogpeppe: standup? | 10:48 |
| jamespage | fwereade, unit log - http://paste.ubuntu.com/7216528/ | 11:00 |
| jamespage | fwereade, machine log - http://paste.ubuntu.com/7216527/ | 11:00 |
| jamespage | fwereade, and one new issue - http://paste.ubuntu.com/7216530/ | 11:00 |
| jamespage | fwereade, bug 1303735 | 11:04 |
| _mup_ | Bug #1303735: private-address change to internal bridge post juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1303735> | 11:04 |
| fwereade | jamespage, thanks | 11:04 |
| jamespage | fwereade, sorry :-) | 11:04 |
| fwereade | jamespage, nothing to be sorry for, except on our side ;p | 11:05 |
| jamespage | fwereade, I could not say whether the address change thing is a new problem | 11:05 |
| jamespage | I don't spend that mich time upgrading juju environments | 11:05 |
| voidspac_ | Plugging my iphone in appears to have locked up my computer | 11:06 |
| voidspac_ | all except audio! | 11:07 |
| voidspac_ | So I'll have to reboot and rejoin the hangout | 11:07 |
| voidspac_ | sorry | 11:07 |
| rogpeppe | fwereade, jam: the client doesn't necessarily need to read from the master | 11:56 |
| === rogpeppe is now known as rogpeppe1 | ||
| === rogpeppe1 is now known as rogpeppe | ||
| jam | rogpeppe: well, we always do Strong consistency, right? | 11:57 |
| rogpeppe | fwereade, jam: i'm giving up. connection too crappy. | 11:57 |
| tvansteenburgh | hey guys, wondering if this is something i should file a bug on: http://pastebin.ubuntu.com/7216718/ | 12:01 |
| hazmat | wallyworld, am now | 12:18 |
| hazmat | er.. ping | 12:18 |
| hazmat | re azure, does this mean the provisioning interface now knows the workload prior to machine allocation or is just fed constraints/parameters ? | 12:20 |
| adeuring | could somebody please have a look here: https://codereview.appspot.com/84470053 | 12:21 |
| dimitern | smoser, i just got hit by bug 1303617 | 12:33 |
| _mup_ | Bug #1303617: Latest curtin version prevents Juju from bootstrapping on MAAS <landscape> <curtin:New> <curtin (Ubuntu):Confirmed> <https://launchpad.net/bugs/1303617> | 12:33 |
| dimitern | smoser, and since version 0.1.0~bzr121-0ubuntu1 is no longer in trusty I cannot downgrade to work around it | 12:47 |
| rogpeppe | natefinch: you've got a LGTM on https://codereview.appspot.com/81980043/ | 13:09 |
| vladk | I found a reason: gomaasapi gives a panic in testing mode when GET /MAAS/api/1.0/networks/?node=xxx and no assigned network to the node | 13:11 |
| dimitern | vladk, yeah that's the issue, but I don't see panics when running maas tests otherwise | 13:11 |
| dimitern | fwereade, mgz, vladk, perrito666, get a list of NICs with mac addresses in maas https://codereview.appspot.com/84850045 | 13:12 |
| vladk | dimitern: because you don't call GetNetworksList before environ.startNode() | 13:13 |
| dimitern | vladk, startNode shouldn't panic - if there are no networks requested for the machine it shouldn't try to get them (or if it fails it should ignore it) | 13:14 |
| natefinch | rogpeppe: thanks | 13:14 |
| perrito666 | dimitern: tx | 13:17 |
| vladk | dimitern: it panics only in testing mode (testservice.go networksHandler() function) | 13:18 |
| dimitern | vladk, take a look at TestGetNetworksList - it adds a network and then a connects a node to it | 13:19 |
| vladk | dimitern: from GetNetworksList I have (net_name, addr, mask, vlan, descr), from getInstanceNetworkInterfaces I have (mac_addr, iface_name) | 13:20 |
| vladk | dimitern: I need to extract mapping between net_name and mac_addr via MAAS API | 13:21 |
| dimitern | vladk, the macs will be there if the node is connected to the network | 13:22 |
| dimitern | vladk, and you can get the networks with the macs | 13:23 |
| dimitern | vladk, i.e. GetNetworksList needs to return mac addresses (when set) | 13:23 |
| vladk | dimitern: what I really need i multimap(iface_name->vlan) | 13:24 |
| vladk | dimitern: GetNetworksList doesn't read mac addresses now | 13:24 |
| vladk | dimitern: I may change it, do you know MAAS API to read MAC addresses? | 13:25 |
| vladk | dimitern: as to TestGetNetworksList, this will work if I manually add a network to each instance before bootstrap.Bootstrap() or testing.AssertStartInstance() | 13:27 |
| vladk | I think that panic should be changed to error code in gomaasapi | 13:27 |
| dimitern | vladk, so I can get the macs from maas maas-root network list-connected-macs vlan0 | 13:28 |
| vladk | dimitern: this will be very long way | 13:29 |
| dimitern | vladk, with is equivalent to doing /api/1.0/networks/<name>?op=list-connected-macs | 13:31 |
| dimitern | vladk, s/with/which/ ...(I hope) | 13:31 |
| dimitern | list_connected_macs actually | 13:31 |
| dimitern | vladk, it seems MAAS does not allow us to get a list of all networks along with their mac assignments - just for a single network, so we'll need multiple API calls for each network | 13:32 |
| vladk | dimitern: long way: from GetNetworksList I get []networkNames, than for each networkName I read a listConnectMacs and search for my node in that list | 13:33 |
| vladk | dimitern: we definitely need a separate API call for all this stuff | 13:34 |
| dimitern | vladk, we could have a separate api, but we don't have it now, so we can work around it with multiple calls | 13:36 |
| * dimitern needs to step out for a while | 13:36 | |
| wallyworld | hazmat: hi, just wanted a clarification. you said in an email that you wanted upload-tools to use the jujud binary and you had hardwired it to do so. AFAICT juju actually looks for the jujud executable in the current path and uses that if found. so could you clarify where you see the problem with the current behaviour? Have I missed something? | 13:44 |
| hazmat | wallyworld, sorry that wasn't clear.. i mean mentally i've hardwired myself to use upload-tools | 13:46 |
| hazmat | wallyworld, indeed the tool lookup by path works fine | 13:46 |
| wallyworld | ah, ok :-) thanks | 13:46 |
| wallyworld | pinned bootstrap using exact version match should help with that for public clouds | 13:47 |
| vladk | dimitern: I take a task of changing GetNetworksList to myself | 13:53 |
| natefinch | rogpeppe: what work did you do on the HA branch after I left on Friday? I forget exactly where we left it. | 14:18 |
| * rogpeppe tries to remember | 14:19 | |
| rogpeppe | natefinch: i did this: https://codereview.appspot.com/84540044/ | 14:21 |
| rogpeppe | natefinch: (and possibly some more as well; i forget) | 14:21 |
| rogpeppe | natefinch: over the weekend, i also tried to integrate the branches to see what might actually work | 14:22 |
| rogpeppe | natefinch: there are a few things that we will need to do | 14:23 |
| rogpeppe | natefinch: we need to apt-get install mongo inside EnsureMongoServer | 14:23 |
| rogpeppe | natefinch: we need EnsureMongoServer to write the server secret files | 14:23 |
| rogpeppe | natefinch: we need to add SystemIdentity to StateServingInfo | 14:23 |
| natefinch | rogpeppe: that seems like stuff that can be in separate CLs, right? Not needed for the single-server mode we're using right now | 14:24 |
| rogpeppe | natefinch: the state server Initiate needs to add the machine tag to the replica set entry | 14:24 |
| rogpeppe | natefinch: yeah, although it does make EnsureMongoServer make sense. | 14:24 |
| axw | rogpeppe: doesn't cloud-init know the intended jobs? so it can do apt-get as usual? | 14:24 |
| natefinch | rogpeppe: I really want to get the MA-HA branch into trunk ASAP so we don't have to keep maintaining a huge branch | 14:25 |
| rogpeppe | natefinch: +1 | 14:25 |
| natefinch | rogpeppe: I honestly don't care if it makes sense today, as long as it doesn't break anything today | 14:25 |
| rogpeppe | axw: i would much prefer to isolate all the mongo installation into EnsureMongoServer | 14:25 |
| rogpeppe | axw: which means that cloud-init doesn't need to know anything at all about mongo | 14:25 |
| axw | rogpeppe: fair enough | 14:26 |
| axw | although, there may be trickiness around adding apt sources | 14:26 |
| rogpeppe | axw: the apt sources *can* be added by cloud-init | 14:26 |
| rogpeppe | axw: because they're needed for lxc too | 14:27 |
| axw | yeah okay | 14:27 |
| natefinch | rogpeppe: you had a change to make the replicaset member host separate from the dial info... is that in your version of the MA-HA branch? | 14:28 |
| rogpeppe | axw: BTW juju ssh is broken currently if $SHELL isn't sh-compatible | 14:29 |
| rogpeppe | axw: the fix is trivial, but i haven't got around to it yet, sorry | 14:29 |
| axw | oy vey | 14:29 |
| axw | what's the issue? | 14:29 |
| axw | or you didn't get to the bottom of it? | 14:30 |
| rogpeppe | axw: ssh proxying uses $SHELL to execute the proxy command | 14:30 |
| rogpeppe | natefinch: did you merge my version of the MA-HA branch? | 14:30 |
| natefinch | rogpeppe: doing so no | 14:31 |
| natefinch | now | 14:31 |
| axw | rogpeppe: as in, ProxyCommand is executed using $SHELL? | 14:31 |
| rogpeppe | natefinch: yes, my version of the branch adds a MemberHostPort member to InitiateMongoParams | 14:31 |
| rogpeppe | axw: yes | 14:31 |
| axw | rogpeppe: is that to separate dialing address from the member address? | 14:32 |
| axw | I was just about to ask about that | 14:32 |
| rogpeppe | axw: yes | 14:32 |
| axw | cool | 14:32 |
| rogpeppe | axw: because you need to dial localhost otherwise you don't get access to mongo | 14:33 |
| axw | yep | 14:33 |
| axw | I spent most of Friday learning a bunch about the quirks around replica sets, localhost exception, etc. | 14:34 |
| natefinch | axw: yeah, mongo replicaset stuff is like 100% quirks | 14:34 |
| axw | hehe :) | 14:34 |
| * natefinch wonders if he's the only one who types bzr bootstrap --debug and juju install ./... | 14:37 | |
| mgz | :) | 14:38 |
| natefinch | I need one command that picks juju, go, or bzr based on the command and does the right thing | 14:38 |
| natefinch | switch being the only tricky one between juju and bzr | 14:38 |
| smoser | dimitern, fix is uploaded. | 14:39 |
| smoser | dimitern, https://launchpad.net/ubuntu/+source/curtin/0.1.0~bzr125-0ubuntu1/+build/5886362 | 14:40 |
| smoser | and really sorry/embarrased on that. | 14:40 |
| smoser | dimitern, you just need to upgrade curtin on your maas system. the actual fix is in curtin-common. | 14:42 |
| hazmat | any ppc enablers around? | 14:44 |
| hazmat | there's some client agent failures in the logs ref'd in https://bugs.launchpad.net/juju-core/+bug/1303787 here that need attention | 14:45 |
| _mup_ | Bug #1303787: hook failures - nil pointer dereference <hooks> <local-provider> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1303787> | 14:45 |
| * hazmat falls back to email | 14:47 | |
| perrito666 | fwereade: is there any written spec on how a placement directive can look like? I see a set of tests that assert that varios values passed to machineornewcontainer yield true or false, but I am not sure how to interpret all of them | 14:48 |
| fwereade | that google doc is all we have | 14:49 |
| fwereade | the only ones implemented are lxc/kvm | 14:49 |
| fwereade | and they all take <pseudo-provider>:<host-machine-id> | 14:49 |
| fwereade | perrito666, ^^ | 14:49 |
| fwereade | perrito666, the juju-core/names package has the definition for a machine id | 14:50 |
| axw | perrito666: what are you working on? I'm starting to look at some placement stuff, just wondering if we're going to collide... | 14:54 |
| perrito666 | axw: well I am working on something that is tangential to it, I was trying to do network checkings on a given instance when specified in --to | 14:55 |
| perrito666 | and well, trying to get the instance I tried to get the id for the instance | 14:55 |
| perrito666 | and one thing led to another | 14:55 |
| axw | ah ok | 14:55 |
| perrito666 | axw: nothing coded yet | 14:55 |
| axw | so not actually extending --to | 14:55 |
| natefinch | haha... I just got an offer letter in email from some company I've never heard in my gmail inbox. Addressed to Nate Finch and everything.... not the first time I've gotten email for the wrong Nate Finch, but first time actual legal documents have been mailed to me that way. | 14:57 |
| voidspace | natefinch: nice. Anything interesting? | 14:57 |
| mgz | natefinch: what's your new job? | 14:58 |
| natefinch | voidspace, mgz: http://centricconsulting.com/ | 14:58 |
| natefinch | Looks kinda boring, actually | 14:58 |
| perrito666 | natefinch: ah I get the fanmail of a famous chilean singer whose gmail acct is the same words as mine but reversed :p its fun | 14:58 |
| perrito666 | natefinch: just answer telling them that paychecks should be sent to your address too | 14:59 |
| natefinch | Haha, nice | 14:59 |
| nessita | hello! re-pasting a question I just posted in # juju | 15:15 |
| nessita | 11:54 < nessita> hello everyone, I'm having an issue with juju deploy that is showing up since I updated juju-core to 1.18. Error is: "only charm store charm references are supported, with cs: schema" when deploying the solr-jetty charm | 15:15 |
| nessita | 11:54 < nessita> more debug output in https://pastebin.canonical.com/107885/ | 15:15 |
| nessita | 11:54 < nessita> any ideas? | 15:15 |
| nessita | 11:55 < nessita> perrito666, would you know who can help me with that ^? | 15:15 |
| perrito666 | nessita: no clue about, sorry | 15:16 |
| nessita | perrito666, thanks | 15:16 |
| nessita | perrito666, any idea how could help me debug further? I'm happy to file a bug, but I'd also need, ideally, a workaround or instructions to fix that | 15:16 |
| rogpeppe | natefinch: are you in a hangout? | 15:23 |
| natefinch | rogpeppe: nope | 15:24 |
| mgz | nessita: can you rerun with --debug? also, can you verify the version of juju *deployed*, not just the local copy? | 15:24 |
| nessita | mgz, hi! this is the --debug output https://pastebin.canonical.com/107892/ | 15:25 |
| nessita | mgz, what do you mean with the juju version deployed? | 15:25 |
| rogpeppe | natefinch: let's have a chat in a little bit - there's an issue that would help from a couple of people thinking about it, i think | 15:25 |
| rogpeppe | natefinch: 10 minutes, maybe? | 15:25 |
| natefinch | rogpeppe: sure | 15:25 |
| mgz | nessita: as in, ssh t0 machine 0 and look at what juju it has, will be in the log in /var/log/juju/... I'd think | 15:26 |
| nessita | mgz, would that be "juju ssh" or plain ssh? | 15:27 |
| mgz | addCharmViaAPI looks correct to me, but something must be up | 15:28 |
| mgz | nessita: `juju ssh 0` is easiest, but anything that works | 15:28 |
| nessita | mgz, while I ssh in, this is machine0.log: https://pastebin.canonical.com/107893/ | 15:28 |
| mgz | ta | 15:28 |
| nessita | $ juju ssh 0 | 15:28 |
| nessita | Permission denied (publickey,password). | 15:28 |
| nessita | ERROR rc: 255 | 15:28 |
| mgz | nessita: can you look for references to your charm in the other juju logs, sibling to that (the version seems fine...) | 15:29 |
| mgz | nessita: ah, yeah, juju ssh is still probably borked for the local provider | 15:30 |
| mgz | so, just look at the logs in situ :) | 15:30 |
| nessita | on it | 15:30 |
| mgz | hadn't twigged it was local, so no version mismatch possibilities | 15:31 |
| natefinch | anyone else see a problem destroying local environments? I'm getting this on trunk: | 15:31 |
| natefinch | $ juju destroy-environment local -y | 15:31 |
| natefinch | ERROR exec ["stop" "--system" "juju-db-v2"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist) | 15:31 |
| nessita | mgz, no result when grepping for "solr" inside the ~/.juju/local/log folder | 15:31 |
| jam | natefinch: that looks like your dbus is hosed, since I think it is trying to send a signal to stop a machine, and DBus doesn't think that interface exists. | 15:32 |
| jam | Sounds (to me) like an incomplete dbus upgrade | 15:32 |
| natefinch | jam: could be, I just updated yesterday and rebooted for it this morning | 15:32 |
| natefinch | jam: I'll rerun update/upgrade | 15:32 |
| jam | natefinch: I'm pretty sure we don't call out to dbus directly | 15:33 |
| nessita | mgz, in the mean time I filed the bug LP: #1303880 | 15:33 |
| jam | that appears to be "stop" not talking to upstart correctly. | 15:33 |
| jam | bug #1303880 | 15:33 |
| _mup_ | Bug #1303880: After upgrade to 1.18, can not longer deploy the solr-jetty charm using local provider <juju-core:New> <https://launchpad.net/bugs/1303880> | 15:33 |
| mgz | nessita: thanks | 15:34 |
| mgz | the workaround is a simple downgrade I guess | 15:34 |
| nessita | mgz, right. Let me know if I can get any extra debug info it may be useful | 15:35 |
| natefinch | jam: update/upgrade didn't help, I'll try a reboot, see if that shakes anything out | 15:35 |
| nessita | mgz, FYI, seems like the deploy of local unit is somehow broken, because noodles775 tried to deploy another charm (elasticsearch) and it failed too | 15:37 |
| mgz | nessyeah, this is long before anything charm specific | 15:38 |
| * nessita edits the bug summary | 15:39 | |
| mgz | nessita: can you try cding to the --repository location, and specifying just local:precise/CHARMNAME? | 15:39 |
| nessita | mgz, trying | 15:39 |
| mgz | pretty sure issue is after the cmd parsing and url expansion, but simple to verify | 15:40 |
| nessita | mgz, just to verify, I should be in ./../.juju-repo not in ./../.juju-repo/precise, right? also, would this be the correct command? juju deploy -e local local:precise/solr-jetty | 15:41 |
| mgz | nessita: yup, that's it | 15:41 |
| mgz | expecting the same error | 15:41 |
| nessita | mgz, hum, I got Added charm "local:precise/solr-jetty-1" to the environment. | 15:42 |
| mgz | ha, well, that works then | 15:42 |
| mgz | next step: work out if it was the --repository or the charm url expansion that's borked | 15:42 |
| nessita | mgz, anything I should do in that front? | 15:43 |
| mgz | you can remove the service, then try either the cd and no --repository, or the local:CHARMNAME and see which works and which fails | 15:44 |
| nessita | ack | 15:44 |
| natefinch | rogpeppe: want to talk? I have to go in 15 minutes for lunch | 15:47 |
| rogpeppe | natefinch: https://plus.google.com/hangouts/_/canonical.com/juju-core-team?authuser=1 | 15:48 |
| nessita | seems like the charm url change makes it work: | 15:50 |
| nessita | $ juju deploy -e local --repository=./../.juju-repo local:precise/solr-jetty solr-jetty | 15:50 |
| nessita | Added charm "local:precise/solr-jetty-1" to the environment. | 15:50 |
| nessita | (that is ran from a location outsite the repository folder) | 15:50 |
| mgz | nessita: thanks | 15:50 |
| nessita | np | 15:53 |
| dimitern | vladk, i'll change https://codereview.appspot.com/84850045/ as you suggest | 16:35 |
| dimitern | vladk, can I have an LGTM? :) | 16:35 |
| vladk | dimitern: done | 16:37 |
| dimitern | vladk, thanks! | 16:37 |
| voidspace | rogpeppe: spectacularly failed to get anything useful committed today. Off to Krav maga, may have another stab on my return. | 17:01 |
| voidspace | rogpeppe: in case I don't, branch is: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 | 17:02 |
| rogpeppe | voidspace: thanks | 17:02 |
| voidspace | rogpeppe: rename done, only requires a test | 17:02 |
| * voidspace hangs head | 17:02 | |
| voidspace | right, EOD folks | 17:02 |
| voidspace | and EOW | 17:02 |
| voidspace | off to PyCon tomorrow | 17:02 |
| rogpeppe | voidspace: have fun! | 17:02 |
| voidspace | back to work a week on Friday | 17:02 |
| voidspace | rogpeppe: thanks, hope so | 17:03 |
| voidspace | language summit first | 17:03 |
| stokachu | sinzui: do you have a wiki page or a tentative eta for 1.18, we are blocked on bug 1299588 | 17:12 |
| _mup_ | Bug #1299588: LXC permission denied issue with 1.17.7 <cloud-installer> <landscape> <lxc> <micro-cluster> <regression> <juju-core:Fix Committed by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588> | 17:12 |
| sinzui | stokachu, I.18 was release Saturday | 17:13 |
| sinzui | stokachu, It is in the juju PPA, Ubuntu is packaging it now | 17:13 |
| stokachu | ok must not be in trusty archive yet | 17:13 |
| stokachu | gotcha | 17:13 |
| stokachu | sinzui: thanks for the update | 17:13 |
| sinzui | stokachu, yep, not in the archive yet. I am polling to check for the arm64 and ppc ports | 17:14 |
| stokachu | sinzui: ok cool, i didnt see it in the proposed queue | 17:14 |
| jam | sinzui: fwereade: jamespage bug #1303697 is this a release blocker bug? | 17:19 |
| _mup_ | Bug #1303697: peer relation disappears during upgrade of juju <juju-core:Triaged> <https://launchpad.net/bugs/1303697> | 17:19 |
| jam | It feels like if this is how it worked in the past, then it wouldn't be a blocker | 17:20 |
| jam | if we are changing behavior that used to work, then we should focus on it. | 17:20 |
| sinzui | jam: I think it is. If not, then I would lower the importance to High | 17:20 |
| jamespage | jam: I don't think so - its a pita | 17:20 |
| fwereade | jam, sinzui: I fear it may be, it certainly should not have acted like that, I failed to figure it out earlier but will take another look now | 17:20 |
| jamespage | jam: I can't say whether this used to work or not | 17:21 |
| jam | fwereade: so if you feel we know we shouldn't have acted that way, then I'm ok with it being critical | 17:21 |
| jamespage | this is a new use of the peer relation in the keystone charm | 17:21 |
| sinzui | jam: actually, we have released. Maybe we want to target it to 1.18.1 | 17:21 |
| jam | sinzui: well this is targetted against 1.19 | 17:21 |
| * sinzui created the milestone a few hours ago just in case | 17:21 | |
| jam | but it should target 1.18.1 if it is actually Critical | 17:21 |
| sinzui | okay jam, if we agree it is critical It goes to 1.18.1, if not we lower the importance. | 17:22 |
| jam | sinzui: correct | 17:22 |
| fwereade | jamespage, unless you upgraded the charm to add the peer relation immediately before upgrading juju, that would be a different story, but I'm pretty sure I saw the logs joining cluster:3 some time before | 17:23 |
| jam | fwereade: sinzui, jamespage: bug #1303735 feels more like it should be Critical, blocking 1.19, and backported to 1.18.1 | 17:23 |
| _mup_ | Bug #1303735: private-address change to internal bridge post juju-upgrade <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1303735> | 17:23 |
| fwereade | jamespage, it would still be a sucky story but atm it looks like a regression to me | 17:23 |
| fwereade | jam, that depends on whether it's a regression -- jamespage seemed uncertain, I don't have any specific input there | 17:25 |
| jam | fwereade: well, we changed what private address we are reporting, from a routable-private address to a fully hidden one, (from what I can see) | 17:26 |
| jam | fwereade: bug #1302205 | 17:26 |
| _mup_ | Bug #1302205: manual provisioned systems stuck in pending on arm64 <add-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1302205> | 17:26 |
| jam | It feels like probably not a regression | 17:26 |
| jam | just that we aren't supporting arm64 well yet | 17:26 |
| jam | sinzui: I've been opening up a 1.19.1 for "things which we need for the next release, but don't have to block getting a dev snapshot along the way" | 17:27 |
| jam | does that seem ok for you? | 17:27 |
| sinzui | jam +1 | 17:28 |
| mramm2 | For those of you who like positive feedback: http://www.reddit.com/r/Ubuntu/comments/22ehsz/ubuntu_maas_and_juju_wow_im_impressed_what_are/ | 17:29 |
| mramm2 | they are loving the juju and MAAS | 17:30 |
| === mramm2 is now known as mramm | ||
| mramm | also if you think it is useful stuff, please feel free to upvote it ;) | 17:31 |
| jam | fwereade: bug #1208430, jamespage is this something we should be spending cycles on now/ | 17:33 |
| _mup_ | Bug #1208430: mongodb runs as root user <mongodb> <juju-core:Triaged by natefinch> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1208430> | 17:33 |
| jam | ? | 17:33 |
| jam | I don't think natefinch actually is working on it | 17:33 |
| jam | (since we need to create a user, get mongo running it, etc) | 17:33 |
| fwereade | jam, yeah, agree re 1302205 | 17:35 |
| jamespage | jam: I think we could defer that for now | 17:38 |
| natefinch | jam: yes, I am not working on that currently | 17:38 |
| * natefinch just got back from a longer than expected lunch | 17:39 | |
| jam | fwereade: so bug #1303697. If we want it to be critical for 1.19, we need to assign it to someone. Care to nominate ? | 17:40 |
| _mup_ | Bug #1303697: peer relation disappears during upgrade of juju <juju-core:Triaged> <juju-core 1.18:Triaged> <https://launchpad.net/bugs/1303697> | 17:40 |
| fwereade | jam, if dimitern has any spare cycles I think he did stuff around there semi-recently... my perception is that vlan is making reasonable progress? | 17:43 |
| jam | fwereade: it is, but he's currently on the critical path to getting VLAN completed. | 17:43 |
| jam | so if this should block 1.19.0, I'd rather give it to someone else | 17:44 |
| fwereade | jam, indeed so -- I mention him only because he's the only person with recent experience there | 17:44 |
| mramm | How about andrew, ian or tim? | 17:44 |
| fwereade | jam, can we ... yeah, what mramm said :) | 17:44 |
| jam | fwereade: mramm: other than I don't control those guys :) | 17:45 |
| fwereade | jam, sure; they *are* doing important stuff, but also explicitly doing bugs as well | 17:45 |
| fwereade | jam, (depending on how my evening goes) I will likely see if I can make it thumper's problem | 17:46 |
| jam | fwereade: sgtm | 17:46 |
| stokachu | sinzui: just saw it show up in proposed queue | 17:57 |
| stokachu | sinzui: for all the archs | 17:57 |
| sinzui | thank you stokachu | 17:57 |
| stokachu | np | 17:58 |
| === vladk is now known as vladk|offline | ||
| * rogpeppe is done for the day | 18:16 | |
| rogpeppe | g'night all | 18:16 |
| natefinch | night rog | 18:17 |
| dimitern | mgz, fwereade, natefinch, in case you're still here I'd like a review on https://codereview.appspot.com/85060043 | 18:30 |
| natefinch | dimitern: I'll review later if I have time, really trying to get HA landed | 18:32 |
| dimitern | natefinch, sure, np, if you can | 18:32 |
| * dimitern reached eod | 18:32 | |
| === BradCrittenden is now known as bac | ||
| perrito666 | natefinch: o cmon, we all know you are watching a DVD :p | 18:40 |
| natefinch | rofl | 18:41 |
| natefinch | well, I mean, I am *now*. | 18:45 |
| perrito666 | natefinch: a long, long, long, time ago, debian solved that problem by having us and non-us repos, dunno how legal that was | 18:54 |
| natefinch | perrito666: doesn't that still mean the US people are screwed? :) | 18:55 |
| natefinch | (for some value of screwed that just requires a quick google... but still) | 18:55 |
| perrito666 | natefinch: as you can imagine, I never encountered said problem | 18:55 |
| perrito666 | :p | 18:56 |
| natefinch | heh | 18:56 |
| perrito666 | natefinch: but hey, that solved the problem for all but a portion of the world | 18:56 |
| natefinch | I wish our copyright laws weren't so draconian. It's really ridiculous that you need to pay for the right to play the DVD you already paid for, and that getting around what is basically just an encoding counts as breaking the law. | 18:57 |
| perrito666 | natefinch: Is 25 bucks too much for a dvd player? (I have no idea what is the cost of a windows one) | 18:57 |
| natefinch | perrito666: windows comes with a dvd player, nothing to pay for (after you pay for windows) | 18:57 |
| perrito666 | natefinch: ahh true, I used one called power something, bundled with my discrete videocard | 18:58 |
| perrito666 | which, iirc, had some hardware decoding feats | 18:58 |
| natefinch | ahh, yeah, probably Cyberlink's PowerDVD ... it gets bundled with some OEMs, and comes with some players etc etc but you don't really need it. It used to be that you needed it more for burning DVDs, but eventually windows actually built that into the OS | 18:59 |
| perrito666 | natefinch: ah, well I switched from win to osx around 2004 and never came back from *nix, living on a country where you cant patent software has some good things :p | 19:00 |
| natefinch | perrito666: and yes, $25 is too much for something that is a solved problemwith open source software.... plus the reviews say the software isn't that great. | 19:01 |
| natefinch | perrito666: don't even get me started on software patents.... hopefully in my lifetime they'll go away. | 19:01 |
| perrito666 | natefinch: you just need to move away :p this country has all the other flaws but we can watch dvds :p | 19:01 |
| natefinch | haha | 19:02 |
| perrito666 | ironically we can legally use bittorrent too so that makes the DVD part kind of useless | 19:02 |
| natefinch | I can watch DVDs too, I just have to break a law that no one enforces anyway | 19:02 |
| natefinch | I can legally *use* bittorrent. :) | 19:02 |
| perrito666 | natefinch: heh | 19:03 |
| natefinch | I just can't legally watch movies I haven't paid for. So I don't legally watch them :) | 19:03 |
| perrito666 | heh, I can pay for movies but cannot legally get them delivered via regular mail without an equal change of either getting them stolen or have to pay 50% import tax :p | 19:05 |
| thumper | hazmat: hey | 19:38 |
| thumper | hazmat: I'm just going to go make breakfast | 19:38 |
| thumper | hazmat: but hit me up on PMs for demo issues | 19:38 |
| thumper | I'll be back later | 19:38 |
| hazmat | thedac, ack | 19:43 |
| hazmat | thumper, ack | 19:43 |
| === Ursinha_ is now known as Ursinha | ||
| waigani | morning all | 20:11 |
| natefinch | morning | 20:15 |
| waigani | I'm trying to work out why gccgo does not want to use the local package. "unexpected reference to package", "reference to undefined identifier ‘local.Provider’": http://pastebin.ubuntu.com/7218823/ | 20:49 |
| natefinch | waigani: is there a local variable clashing with an imported package name or something? | 20:52 |
| waigani | natefinch: ah, true I'll have a hunt | 20:53 |
| natefinch | waigani: that first error looks like you're trying to print out a variable called local.. but there's a package called local (you can't print out packages) | 20:53 |
| waigani | natefinch: that is my newbie mistake. Thanks. | 20:54 |
| natefinch | waigani: no problem, happens :) | 20:54 |
| waigani | natefinch: though that debug line does at least confirm that it is a reference to a package, which rules out a variable clash right? | 20:57 |
| natefinch | waigani: yeah.... it looks like the problem is that there is no variable called local. There's a package called local. Whatever variable you're intending to reference is either not defined or called something else | 20:58 |
| waigani | natefinch: right. So the real question is why local.Provider is referencing an undefined identifier. | 21:01 |
| natefinch | waigani: can you just pastebin the whole file? I can take a look | 21:01 |
| waigani | natefinch: when I run "provider/local$ go test -gocheck.f TestOpenFailsWithProtectedDirectories" I get this: http://pastebin.ubuntu.com/7218823. | 21:06 |
| waigani | natefinch: here is the first file in the error stack: http://pastebin.ubuntu.com/7218888/ | 21:07 |
| natefinch | waigani: the first error references a log line on line 36 that doesn't exist in that file.... which is weird. try blowing away $GOPATH/pkg and then run the test again. It's possible something weird got stuck in there (it's happened to a few people on the team lately) | 21:08 |
| waigani | natefinch: sorry, my bad. I just took out my debug line, so it is referencing 37 | 21:10 |
| waigani | natefinch: valid, err := local.Provider.Validate(testConfig, nil) | 21:10 |
| natefinch | waigani: local.Provider is defined in provider/local/export_test.go, in the var block at the top of the file. Does that exist in your branch? | 21:13 |
| waigani | natefinch: yes | 21:13 |
| natefinch | That's the thing that it says is undefined, which is weird if it's there | 21:14 |
| waigani | natefinch: I'm testing on gccgo on a ppc vm. I wounder if I need to make or build anything for gccgo recognise the package? | 21:14 |
| natefinch | it's a normal test file, it shouldn't have any special requirements except "running during go test" | 21:15 |
| natefinch | waigani: it's still probably worth trying to wipe out your $GOPATH/pkg directory. Some intermediate files can get stuck in there sometimes, and usually the symptom is symbols not reflecting what is in the code files, like this | 21:17 |
| waigani | natefinch: okay I'll do that now | 21:17 |
| waigani | natefinch: no luck :( | 21:18 |
| natefinch | dang | 21:18 |
| waigani | natefinch: here is my wip: https://codereview.appspot.com/84360043/ | 21:19 |
| waigani | you might get the same result on your machine if you run " go test --compiler=gccgo ..." | 21:20 |
| natefinch | waigani: does this only fail with gccgo? | 21:22 |
| waigani | natefinch: to the best of my knowledge, yes | 21:22 |
| natefinch | ahh ok. It must be a gccgo bug, then | 21:22 |
| natefinch | yeah, it definitely passes on my machine with gc | 21:23 |
| waigani | right, I hit another bug on my machine, but I think that is because of my perms | 21:23 |
| waigani | as explained in my wip | 21:23 |
| natefinch | So, let me explain what that code is doing... local is the package name, Provider is a public variable in that package, in a _test.go file, which means it's only compiled during tests. What it's doing is exposing access to a private variable, by assigning it to a public variable (but since it's only available during tests, it's not hurting anything) | 21:24 |
| waigani | natefinch: yep | 21:25 |
| natefinch | It seems like gccgo is somehow simply not compiling that file | 21:25 |
| waigani | hmmm | 21:25 |
| waigani | you're welcome to poke around the vm if you're keen | 21:26 |
| waigani | natefinch: if you run with gccgo compiler on your machine, do you get the same error? | 21:26 |
| natefinch | possibly because it has no test methods in it? I 'm not sure. Try slapping a TestFoo(t *testing.T) {} method in provider/local/export_test.go | 21:26 |
| * natefinch installs gccgo | 21:27 | |
| natefinch | huh, weird, no, it passes for me with gccgo 4.9 on your branch | 21:29 |
| waigani | hmph | 21:29 |
| natefinch | one of the prereqs tests fails, but I think that's an environment problem on my machine, not really a test failure | 21:30 |
| waigani | natefinch: I've found with a few issues, that they are only reproducible on ppc arch | 21:30 |
| natefinch | waigani: we're getting paid a lot of money for this, right? :) | 21:31 |
| waigani | natefinch: to get juju working on ppc? I believe so. | 21:32 |
| natefinch | heh yes | 21:32 |
| waigani | slapping on a vm with vi is painfully slow | 21:33 |
| natefinch | waigani: in provider/local/export_test.go add this line to the imports: | 21:34 |
| waigani | ah man, same error with the added test: "reference to undefined identifier ‘testing.T’" | 21:34 |
| natefinch | coretesting "testing" | 21:34 |
| natefinch | and then make the test: | 21:35 |
| natefinch | func TestFoo(t *coretesting.T) { | 21:35 |
| natefinch | t.Error("you should see this") | 21:35 |
| natefinch | } | 21:35 |
| waigani | natefinch: will do | 21:35 |
| natefinch | (sorry, the testing package that is imported in that file is our testing package, not the standard library's) | 21:35 |
| waigani | right, we might be onto something ... fingers crossed | 21:35 |
| natefinch | you should see something like this: | 21:37 |
| natefinch | --- FAIL: TestFoo-8 (0.00 seconds) | 21:37 |
| natefinch | export_test.go:60: you should see this | 21:37 |
| natefinch | if you *don't see that, then it's not compiling that file | 21:37 |
| waigani | :( | 21:38 |
| waigani | natefinch: no luck | 21:38 |
| natefinch | so, do you see that output? | 21:38 |
| waigani | natefinch: exactly the same original output | 21:38 |
| waigani | erroring on local.Provider | 21:39 |
| natefinch | so, either it's not compiling that file, or something is stuck in the precompiled binaries somewhere. If you comment out that first validate line (line 36/37), does it at least not report that same error anymore? That would be a good way to check that it's actually picking up changes in the source code | 21:40 |
| waigani | natefinch: it printed out my debug line, so yes it is picking up changes | 21:41 |
| natefinch | ok, well that's good at least | 21:41 |
| natefinch | I can't imagine why it's not compiling export_test.go .... that's bizarre | 21:41 |
| waigani | let me try some other tests ... | 21:42 |
| * fwereade is an idiot -- he just coded a fix that would work perfectly if he could retroactively apply it to 1.17.7 :-/ | 21:42 | |
| natefinch | I gotta run, unfortunately. It's past end of day for me. Try renaming export_test.go to foo_test.go or something. See if that does anything | 21:42 |
| natefinch | fwereade: doh | 21:42 |
| waigani | natefinch: thanks for your help man | 21:43 |
| fwereade | and all the shops are closed, too | 21:43 |
| jcw4 | lbox propose insists on using sensible-browser for the oauth stuff, which in a non-gui environment doesn't work for me... any clues? | 21:43 |
| fwereade | ... *and* it actually can't be fixed cleanly unless we can guarantee state servers upgrade before unit agents | 21:44 |
| fwereade | dammit | 21:44 |
| waigani | heh | 21:44 |
| jcw4 | fwiw, I just hacked lpad/oauth.go to immeditately return "", nil to force out of band auth | 21:53 |
| waigani | thumper: when I pull down my branch to test in on the ppcvm I put it here: ~/go/src/launchpad.net/mybranch | 22:13 |
| thumper | otp | 22:13 |
| waigani | thumper: otp? | 22:14 |
| thumper | on the phone | 22:14 |
| waigani | ooooh | 22:14 |
| waigani | thumper: putting it there seems to have caused the error I was debugging all morning. | 22:15 |
| waigani | thumper: when I merged ~/go/src/launchpad.net/mybranch with ~/go/src/launchpad.net/juju-core and ran tests I no longer got the error | 22:16 |
| jcw4 | any help for this one? I have a cobzr branch of juju-core. identical except for a few revisions in worker/uniter/charm/. go build ./... works in master. fails in my branch. ran godeps -u in both; dependencies.tsv is identical in both | 22:30 |
| jcw4 | all the failures are in the provider/azure/environ.go which was fixed in master by using godeps | 22:31 |
| jcw4 | looks like I had to switch to the working branch, do a go get -u ./..., then do a godeps -u dependencies.tsv, then finally able to build | 22:38 |
| sinzui | wallyworld, thumper I broke canonistack testing. probably by removing admin-secret and control-bucket from the config: http://pastebin.ubuntu.com/7219300/ | 23:17 |
| sinzui | ^ Do I need those keys. Do I need to put them back as they where | 23:17 |
| sinzui | were | 23:17 |
| wallyworld | sinzui: control bucket is no longer needed in the yaml | 23:17 |
| wallyworld | it will be geneated on the fly | 23:17 |
| sinzui | wallyworld, thumper if there is cruft left behind, I would prefer to nuke it | 23:17 |
| sinzui | wallyworld, okay, I understood that much | 23:18 |
| wallyworld | i think the same applies to admin secret | 23:18 |
| wallyworld | so, you should just nuke what's there and start again | 23:18 |
| wallyworld | it should then create a new control bucket and away it goes | 23:18 |
| sinzui | wallyworld, Hp is not broken, I remove admin-secret and public-pubic from it too | 23:19 |
| wallyworld | hmmm. so you must still have the jenv file then | 23:19 |
| wallyworld | cause when bootstrap first happens, the jenv file gets created and the yaml file is then redundant | 23:19 |
| wallyworld | when you say removed from config, do you mean yaml file, jenv, or actual environ config using juju unset? | 23:20 |
| sinzui | wallyworld, There is no jenv file | 23:21 |
| * sinzui checks nova | 23:21 | |
| * wallyworld has to take something to car, back in a minute | 23:21 | |
| sinzui | wallyworld, nova doesn't show any machines. | 23:21 |
| wallyworld | sinzui: so you are trying to bootstrap a new env from scratch? | 23:24 |
| sinzui | wallyworld, no, one that existed in the last round of tests | 23:25 |
| * sinzui tries a rename | 23:25 | |
| wallyworld | but there is no jenv file | 23:25 |
| wallyworld | hence it will create a new control bucket et al | 23:25 |
| wallyworld | if the control bucket has been deleted from yaml | 23:25 |
| sinzui | wallyworld, more interesting, new env name and same error. | 23:28 |
| * sinzui looks at bigger diff | 23:28 | |
| wallyworld | does sound like a permissions issue | 23:29 |
| wallyworld | if control bucket can't be created | 23:29 |
| sinzui | wallyworld, I just restored the config and got nothing. Maybe I am having a panic attack...canonistack is actually tits up | 23:33 |
| wallyworld | oh | 23:34 |
| wallyworld | at least that explains it. canonistack does seem to be way overcommitted | 23:35 |
| sinzui | wallyworld, I cannot bootstrap as myself it seems | 23:35 |
| wallyworld | i'll try also | 23:35 |
| sinzui | wallyworld, looks like the dashboard was setup for lcy02. It cannot list containers. | 23:36 |
| wallyworld | hmm, ok | 23:36 |
| === bigjools_ is now known as bigjools | ||
| davecheney | https://codereview.appspot.com/85100044 | 23:47 |
| davecheney | quick review | 23:47 |
| davecheney | fixes test explosion if you're missing mongod | 23:47 |
| davecheney | waigani: maybe one for you | 23:47 |
| === arosales_ is now known as arosales | ||
| waigani | davecheney: why do you no longer need to zero set inst.addr etc? | 23:55 |
| davecheney | waigani: 'cos we return an error | 23:56 |
| waigani | davecheney: so why do you need to remove inst.dir ? | 23:56 |
| davecheney | 'cos we're cleaning up our failure | 23:57 |
| waigani | so why no remove addr etc to clean up failure? | 23:57 |
| davecheney | 'cos the policy is once you return an error | 23:58 |
| davecheney | you cannot make any assuptions about the state of the value | 23:58 |
| davecheney | honestly if this is going to be a sticking poiint | 23:58 |
| davecheney | i'll put thoselines back | 23:58 |
| davecheney | it doesn't make any different | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!