davecheney | thumper: wanna shoot for a 1:1 today ? | 00:07 |
---|---|---|
beisner | hi davecheney - what do you think? are we trying something too crazy? | 00:26 |
davecheney | beisner: deploying anything to machine 0 is crazy | 00:30 |
davecheney | but that isn't the problme | 00:30 |
davecheney | best I can tell the error is coming from upstart | 00:30 |
beisner | davecheney, lol. | 00:30 |
davecheney | deploying units to machine 0 has been responsible for 100% of customer data loss | 00:30 |
beisner | davecheney, good to know. fwiw, this is related to automated deployment testing, and we do that only for density. the whole enviro gets torn down after openstack tempest tests run. | 00:31 |
beisner | what else do you think, aside from our crazy unit 0 ways? ;-) | 00:32 |
davecheney | the error is coming from upstart | 00:34 |
davecheney | can you make an issue and attach the raw file from upstart | 00:34 |
davecheney | the one you pasted | 00:34 |
davecheney | it has to be the raw file | 00:34 |
davecheney | i suspect there is some control characters or other whitespace crap in there that is throwing off upstart | 00:35 |
beisner | davecheney, yes, i'd be happy to. will ping you in a bit. | 00:36 |
thumper | davecheney: yeah, how about after lunch your time? | 00:45 |
beisner | davecheney, so that's getting interesting (copying the raw file) with the 1/lxc/3 having "no internal address." | 01:00 |
beisner | ahh never fear. there's always /var/lib/lxc/juju-machine-1-lxc-3/rootfs/etc/ ... grabbing it. | 01:02 |
beisner | davecheney, https://bugs.launchpad.net/juju-core/+bug/1420049 | 01:07 |
mup | Bug #1420049: jujud: Syntax error: word unexpected (expecting ")") <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1420049> | 01:07 |
=== kadams54-away is now known as kadams54 | ||
thumper | menn0: the more I think about it, the more I reckon the services running on the api server machines on behalf of another environment should not appear in the other environment log, but in the state server environment log | 01:29 |
menn0 | thumper: I guess that sort of makes sense | 01:30 |
thumper | which does keep things much simpler | 01:30 |
menn0 | thumper: but if I was investigating a problem within an environment I might want to see those logs... | 01:31 |
thumper | well, you'd have to ask | 01:31 |
thumper | :) | 01:31 |
thumper | I think we should definitely have some way to record which env certain logs are for... | 01:31 |
menn0 | thumper: but if I was a user with access to an env, but not the state server env then I wouldn't be able to | 01:31 |
thumper | but probably as part of the module | 01:31 |
thumper | exactly | 01:31 |
thumper | I don't think this is a bad thing | 01:32 |
menn0 | thumper: it's certainly safer that way | 01:32 |
thumper | much safer | 01:32 |
thumper | and a good starting position | 01:32 |
menn0 | thumper: for a user like that, the state server should probably be a black box | 01:32 |
thumper | I'm prepared to be convinced that we may want to change in the future | 01:32 |
thumper | but as a solid well defined starting position | 01:33 |
thumper | the state server for other environments is as you just mentioned, a black box | 01:33 |
menn0 | thumper: you've convinced me :) | 01:33 |
thumper | menn0: lets start with that assumption then | 01:33 |
thumper | and document decisions | 01:33 |
menn0 | thumper: not state server... JES | 01:33 |
thumper | sure | 01:33 |
thumper | axw: hey, updated http://reviews.vapour.ws/r/864/diff/# | 02:01 |
axw | thumper: looking | 02:07 |
axw | thumper: LGTM | 02:14 |
thumper | axw: ta | 02:14 |
thumper | axw: the expected behaviour is that if you created a new environ config instance with New, then it will fail if there is already one with the same noe | 02:15 |
thumper | name | 02:15 |
axw | thumper: ok, I'm just looking at the contract of EnvironInfo specifically | 02:16 |
* thumper scratches his head | 02:16 | |
axw | thumper: I think it needs clarification | 02:16 |
axw | not a big deal | 02:16 |
thumper | also... all likely to change soon | 02:16 |
axw | :) | 02:16 |
thumper | you have me wondering now... | 02:17 |
* thumper looks | 02:17 | |
thumper | I had to change the memory implementation to check for created and !initialized in order to get the second write working while failing two news | 02:18 |
thumper | and thought that the check should be the same with the disk implementation | 02:19 |
* thumper looks again | 02:19 | |
thumper | hmm... | 02:21 |
thumper | I thought I tested that | 02:21 |
thumper | just using !iniitalized in both places does work | 02:21 |
* thumper goes with simpler | 02:21 | |
mattyw | morning all | 03:10 |
mattyw | davecheney, ping? | 03:11 |
=== kadams54 is now known as kadams54-away | ||
axw | anastasiamac: https://github.com/juju/errors/pull/17 please | 03:26 |
mattyw | anastasiamac, and when you're done with that would you mind taking a look at this one http://reviews.vapour.ws/r/903/ :) | 03:27 |
anastasiamac | axw: done but m not graduated :D | 03:28 |
axw | thanks | 03:28 |
anastasiamac | mattyw: np - m going thru another one of axw | 03:28 |
axw | thumper: teeny weeny change to errors, would you mind? https://github.com/juju/errors/pull/17 | 03:28 |
anastasiamac | mattyw: it's a lot of fun - storage - it' s huge | 03:28 |
anastasiamac | mattyw: but will be done soon and will look at urs :D | 03:29 |
mattyw | anastasiamac, wnjoy that - mine is just a backport of a pr that landed yesterday so should be simpler :) | 03:29 |
anastasiamac | mattyw: sure thing :D | 03:29 |
thumper | axw: done | 03:35 |
thumper | davecheney: still want to do a 1:1? | 03:35 |
mattyw | anastasiamac, and one more - I've tried to make it as trivial as possible | 03:37 |
mattyw | anastasiamac, .... and here's the link: http://reviews.vapour.ws/r/904/ :) | 03:37 |
anastasiamac | mattyw: i will .. thnx :D | 03:37 |
mattyw | anastasiamac, you'll struggle to find a simpler one than /r/904 - ever I think | 03:38 |
anastasiamac | mattyw: :D i'll let u know where it is on my scale... | 03:38 |
axw | thumper: thanks | 03:59 |
anastasiamac | mattyw: out of interest, where r the credentials for metrics set? | 04:13 |
anastasiamac | mattyw: and yes, 904 is trivial. the only that would beat it, would a punctuation/typo correction ;D | 04:14 |
anastasiamac | mattyw: urs takes the rpize | 04:14 |
anastasiamac | prize* | 04:15 |
mattyw | anastasiamac, they're set here https://github.com/juju/juju/blob/master/state/unit.go#L1790 | 04:16 |
mattyw | anastasiamac, it's one level up from the todo in the scheme of things | 04:17 |
anastasiamac | mattyw: ah | 04:17 |
mattyw | anastasiamac, but it makes everything much easier | 04:17 |
anastasiamac | mattyw: thnx :D | 04:19 |
bodie_ | hmmmm; so I'm told the table test approach is hard to debug and I shouldn't use it except for trivial cases? | 04:23 |
bodie_ | just want to get confirmation of that | 04:23 |
bodie_ | i.e., for i, test := range []struct{...}{...}{do some tests on test} | 04:27 |
thumper | bodie_: hey there | 04:27 |
bodie_ | o/ | 04:27 |
thumper | bodie_: I'd say tables are fine if the body of the test in the loop is simple | 04:27 |
thumper | ie | 04:27 |
thumper | minor setup | 04:28 |
thumper | err := some-test | 04:28 |
thumper | if test.err { c.Assert(err, gc.ErrMatches, test.err); } | 04:28 |
thumper | else { | 04:28 |
thumper | c.Assert(err, jc.ErrorIsNil) | 04:28 |
thumper | other assertions | 04:28 |
thumper | if there are other if statements in the body, break the tests apart | 04:29 |
thumper | there are some table based tests in our code that really shouldn't be | 04:29 |
bodie_ | that makes sense | 04:29 |
bodie_ | :) thanks thumper | 04:29 |
thumper | np | 04:29 |
thumper | anastasiamac: here's a good one for you: http://reviews.vapour.ws/r/902/ | 04:31 |
* thumper runs away | 04:31 | |
anastasiamac | thumper: i'd add to it, that u might not want to have tables if u need to take adavantage of setup/teardown | 04:31 |
thumper | anastasiamac: agreed | 04:31 |
thumper | anastasiamac: FYI, a previous branch of mine added PrepareForCreateEnvironment, and renamed Prepare to PrepareForBootstrap | 04:33 |
thumper | some environments need to do additional checks for bootstrap | 04:33 |
thumper | like the local provider makes sure the ports aren't in use | 04:33 |
bodie_ | I wrote a super ugly one.. or two.. using a func(){}() to wrap a defer... :P | 04:33 |
thumper | most other providers are much more simple | 04:33 |
thumper | bodie_: while that isn't too terrible, it makes it harder to follow | 04:34 |
thumper | one key indicator I have is "a test should be easy to follow and obviously correct" | 04:34 |
thumper | it is hard enough to decode convoluted code | 04:35 |
thumper | add convoluted tests to that and it just hurts more | 04:35 |
* thumper looks at the uniter tests | 04:35 | |
bodie_ | oh god | 04:35 |
bodie_ | I'll keep that in mind | 04:36 |
thumper | night all | 04:36 |
anastasiamac | jam: thnx for ur elegant comments on RB894. i was hoping there was a convention :D | 06:00 |
anastasiamac | jam: or at least a precedence | 06:00 |
jam | anastasiamac: happy to, thanks for doing the review as well | 06:00 |
Muntaner | ericsnow: fwereade, good morning | 08:23 |
Muntaner | and good morning to every1 | 08:23 |
TheMue | morning | 08:29 |
fwereade | Muntaner, o/ | 08:42 |
Muntaner | fwereade: can you have a look? https://bugs.launchpad.net/juju-core/+bug/1420155 | 08:42 |
mup | Bug #1420155: Juju fails to bootstrap on a private OpenStack cloud due to not finding image metadata <bootstrap> <cloud> <juju> <private> <ubuntu-openstack> <juju-core:New> <https://launchpad.net/bugs/1420155> | 08:42 |
Muntaner | since I'm italian, maybe my english made this launchpad bug not understandable :) | 08:43 |
fwereade | Muntaner, no, that's clear, and much appreciated | 08:44 |
Muntaner | fwereade: I'm curious about how developers work | 08:44 |
Muntaner | all of the confirmed bugs get fixed in a single release? | 08:44 |
Muntaner | or you choose the most urgent and important and fix them ASAP? | 08:45 |
fwereade | Muntaner, afraid not -- there are many bugs, and somewhat harsh constraints on which ones actually get chosen at a given time | 08:45 |
fwereade | Muntaner, fwiw, I am rather grumpy that we have this particular bug and that it's lived so long | 08:45 |
Muntaner | fwereade: maybe it came out because nobody had tried a configuration like mine | 08:46 |
Muntaner | fwereade: is that possible? just thinking loud :) | 08:46 |
fwereade | Muntaner, most likely, yes -- we see an awful lot of use of juju *deploying* private openstack clouds with maas | 08:47 |
fwereade | Muntaner, and maas has its own image handling | 08:47 |
Muntaner | fwereade: well, my situation is "more new" then - I don't have MAAS in my configuration | 08:48 |
fwereade | Muntaner, yeah -- thank you very much for your help in tracking down the problem | 08:49 |
Muntaner | fwereade: no problem! btw, I noticed that dimitern had reported this situation in another launchpad -> https://bugs.launchpad.net/juju-quickstart/+bug/1411574 | 08:52 |
mup | Bug #1411574: quickstart should detect private clouds somehow and generate metadata url in the environments.yaml <juju-quickstart:Triaged> <https://launchpad.net/bugs/1411574> | 08:52 |
Muntaner | dunno if it needs to be merged | 08:52 |
fwereade | Muntaner, quite possibly, and ericsnow found another that looked very closely related too | 08:53 |
fwereade | Muntaner, funny how many ways there are of characterising the exact same underlying issue ;) | 08:53 |
Muntaner | fwereade: so, the problem is that the upload of the metadatas fails in a LAN environment? | 08:54 |
fwereade | Muntaner, I have a strong suspicion that the metadata-uploading is just *broken*, which is what I'm mainly so grumpy about | 09:01 |
fwereade | Muntaner, I suppose that in general, for a prod environment, I'd expect a separate server for the metadata anyway, so maybe that's why it hasn't been spotted | 09:02 |
Muntaner | fwereade: yes - I agree that our configuration is somewhat "raw" :) | 09:02 |
mattyw | fwereade, ping? | 09:10 |
mattyw | jam, ping? | 09:12 |
jam | hey mattyw | 09:13 |
voidspace | dooferlad: TheMue: making coffee, be with you in a minute or two... | 10:01 |
=== benji is now known as Guest47535 | ||
perrito666 | morning all | 11:05 |
TheMue | perrito666: heya | 11:08 |
voidspace | perrito666: o/ | 11:11 |
perrito666 | man, I am waay to far from europe to get an ubuntu phone | 11:42 |
TheMue | voidspace: the latest change on the Prepare... branch is pushed | 11:44 |
voidspace | TheMue: cool | 12:00 |
TheMue | voidspace: the current test for the exhausting of addresses knows the number of available IPs on a fresh dummy machine. that's no real good dependency. I added AddressesAvailable to subnet, but sadly I've got no access to the subnet from inside the test | 12:03 |
TheMue | voidspace: so if you know a good approach here it's welcome | 12:03 |
mattyw | is the build server feeling sick? | 12:10 |
* TheMue is out to lunch | 12:13 | |
perrito666 | mattyw: ? | 12:13 |
mattyw | perrito666, seems to have been rejected branches for the last hour with all kinds of weird test failures | 12:14 |
perrito666 | mattyw: mm odd... well not that odd | 12:14 |
perrito666 | mgz ? | 12:14 |
voidspace | TheMue: why do you need AddressesAvailable? | 12:25 |
voidspace | TheMue: you have AllocatableIPLow and AllocatableIPHigh | 12:25 |
voidspace | TheMue: available is High - low + 1 - numberAlreadyAllocated | 12:26 |
voidspace | TheMue: I don't really understand your problem | 12:26 |
voidspace | TheMue: point me to the test you think has the bad dependency | 12:26 |
* TheMue is back | 12:36 | |
TheMue | voidspace: AddressesAvailable IS High - low + 1 - numberAlreadyAllocated ;) | 12:37 |
TheMue | voidspace: I only created it to have an external access to this information | 12:38 |
TheMue | voidspace: especially with the retrieval of the numberAlreadyAllocated | 12:38 |
voidspace | TheMue: I don't understand the problem you're trying to solve | 12:39 |
voidspace | TheMue: there is code that calculates this before attempting to pick a new address | 12:39 |
voidspace | TheMue: so it knows if the address space is exhausted | 12:40 |
voidspace | TheMue: and it has to fetch all the allocated IPs anyway | 12:40 |
voidspace | TheMue: so it's no extra work | 12:40 |
TheMue | voidspace: it's only for testing, I would like to know how many are still available opposite to simple pick them until they exhausted | 12:40 |
TheMue | voidspace: it's not for the productive code | 12:41 |
voidspace | TheMue: can't you create a subnet, then manually allocate specific addresses? | 12:41 |
voidspace | TheMue: sorry, I thought you said you wanted to add AddressesAvailable to Subnet | 12:41 |
voidspace | that *would* be external code | 12:41 |
voidspace | why not just create a known situation | 12:41 |
voidspace | TheMue: ah, but you don't have access to the subnet anyway? | 12:42 |
voidspace | is that the problem | 12:42 |
voidspace | so adding AddressesAvailable wouldn't help anyway | 12:42 |
TheMue | voidspace: yep, no access inside the test | 12:42 |
TheMue | voidspace: sadly currently not, exactly | 12:42 |
voidspace | I don't think it's needed anyway | 12:42 |
voidspace | TheMue: I'm about to leave :-/ | 12:42 |
TheMue | voidspace: ok, thanks anyway | 12:42 |
voidspace | TheMue: you'd have to manipulate the test setup | 12:43 |
voidspace | which with our test heirarchy is non-trivial | 12:43 |
TheMue | voidspace: hoped for a simpler answer :D | 12:43 |
TheMue | voidspace: currently my test relies on knowing the hard coded subnets of the dummy provider. but once somebody changes it the test would break. | 12:44 |
perrito666 | TheMue: well they will most likely notice :p | 12:45 |
voidspace | TheMue: my answer would be that address space exhaustion is already tested | 12:45 |
TheMue | perrito666: yeah, indeed | 12:45 |
voidspace | TheMue: so it doesn't need testing at this level | 12:45 |
voidspace | TheMue: mock out the call that would produce the error and check the error is handled well | 12:45 |
voidspace | TheMue: but you don't need to simulate actual exhaustion | 12:46 |
TheMue | voidspace: ok | 12:46 |
wwitzel3 | voidspace: do you have a maas setup? | 13:08 |
voidspace | wwitzel3: yes | 13:09 |
wwitzel3 | voidspace: in all my attempts I am failing to reproduce https://bugs.launchpad.net/juju-core/+bug/1417875 | 13:09 |
voidspace | wwitzel3: I'll have to look at it on my return, I'm off out to a meeting | 13:10 |
voidspace | wwitzel3: but I'll give it a go | 13:10 |
wwitzel3 | voidspace: all I need is for you to bootstrap and deploy something to using --to 0 and see if the logging gives you the x509 cert error. | 13:10 |
wwitzel3 | voidspace: thanks, appreciate it | 13:10 |
perrito666 | how did I not set my vim to run go fmt before saving before? this is glorious. | 13:17 |
wwitzel3 | perrito666: indeed, there is no other appropriate way | 13:29 |
perrito666 | wwitzel3: I used to, git diff, review, git commit, git push, notice go fmt is sad, scream, kick, insult, go fmt ./..., git commit --amend, git push | 13:30 |
wwitzel3 | perrito666: sounds exhausting | 13:30 |
perrito666 | restore 4 out of 6 merged :') | 14:53 |
ericsnow | FYI, at some point Reviewboard will be down for (hopefully) at most an hour while we switch to a new environment | 15:02 |
ericsnow | I'll be sure to notify everyone when we're close | 15:02 |
TheMue | ericsnow: thx for info | 15:10 |
ericsnow | natefinch: one-on-one? | 15:24 |
ericsnow | natefinch: (in 5 min I guess) | 15:25 |
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== whit is now known as whit|review-q | ||
perrito666 | really another backup/restore bug breaking 1.21? | 15:50 |
sinzui | perrito666, sorry, two in fact | 15:51 |
perrito666 | o ffs | 15:51 |
perrito666 | ok, on it | 15:51 |
perrito666 | I wonder if we should add testing support for this in the already bloated CI test | 15:53 |
alexisb | hey there hazmat ! | 15:55 |
hazmat | alexisb: greetings | 15:55 |
=== kadams54_ is now known as kadams54-away | ||
=== benji_ is now known as benji | ||
sinzui | Hi natefinch, do you have a moment to review http://reviews.vapour.ws/r/906/ | 17:06 |
natefinch | sinzui: ship it@ | 17:07 |
natefinch | ! | 17:07 |
sinzui | thank you natefinch | 17:07 |
natefinch | sinzui: welcome | 17:07 |
=== kadams54-away is now known as kadams54_ | ||
* perrito666 is back, from a 3g network in a dentist's waiting room | 18:12 | |
=== ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1420426 | ||
sinzui | katco, perrito666, ericsnow: CI just found a cross-compile regressions. bug 1420426 | 18:21 |
mup | Bug #1420426: backups_nonlinux.go import error <ci> <osx> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1420426> | 18:21 |
perrito666 | you have got to be kidding me | 18:21 |
ericsnow | perrito666: perhaps we should just disable all tests in state/backups on non-linux | 18:22 |
ericsnow | perrito666: (in package_test.go add c.Skip() if runtime.GOOS != "linux") | 18:23 |
perrito666 | ericsnow: could you tacle this one? I have my hands full with the other two restore blockers | 18:23 |
ericsnow | perrito666: sure | 18:23 |
perrito666 | tx a lot, I owe a beverage of your chooice | 18:23 |
perrito666 | :) | 18:23 |
perrito666 | sinzui: I apologize, that was most likely my | 18:29 |
perrito666 | my fault | 18:29 |
ericsnow | perrito666: http://reviews.vapour.ws/r/907/ | 18:55 |
voidspace | g'night all | 19:28 |
voidspace | EOD | 19:28 |
=== fuzzy__ is now known as Ponyo | ||
=== Spads_ is now known as Spads | ||
perrito666 | orry I was suddenly trapped for the past hour in my mother in law's home, its a good thing I know how to tear apart a door | 19:57 |
perrito666 | ericsnow: that diff is correct? | 20:00 |
perrito666 | I am extremely curious how that got merged to begin | 20:00 |
=== kadams54_ is now known as kadams54-away | ||
ericsnow | perrito666: because it would only have failed under non-linux (which I presume the merge bot does not try) | 20:05 |
perrito666 | ah makes sense | 20:05 |
=== kadams54-away is now known as kadams54_ | ||
ericsnow | davecheney: regarding that backups fix, I had considered checking runtime.GOOS, but version.Current.OS gives us better granularity | 20:18 |
davecheney | ericsnow: replied on the review | 20:34 |
ericsnow | davecheney: thanks | 20:34 |
perrito666 | sinzui: is it possible to backport (and release off course) a fix to 1.20? | 20:41 |
sinzui | perrito666, we can, though it is disabled at this time | 20:43 |
niedbalski | perrito666, sinzui 1.21 is OK to me, if you can confirm that juju upgrade-juju works from 1.20.8.1 to 1.21.x | 20:44 |
niedbalski | :) | 20:44 |
sinzui | niedbalski, 1.20.8.1 is either a custom build or juju built using upload-tools, it is not an official release and not in streams | 20:45 |
sinzui | niedbalski, but I can confirm 1.20.x can upgrade to 1.21.x. | 20:46 |
perrito666 | ok, that is all I needed to hear | 20:46 |
sinzui | niedbalski, but I will call your attention to https://bugs.launchpad.net/juju-core/+bug/1416928 which murdered my beloved juju-ci3 env | 20:47 |
mup | Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928> | 20:47 |
sinzui | niedbalski, suspect t juju flipped out when it found lxc installed in the bootstrap server | 20:47 |
thumper | cmars: can I defer our call? | 20:51 |
rharper | so, I'm trying to invoke an rpc of addmachine and I want to pass an arg that will be converted to a placement.instance, much lik what the juju cli does when you do juju machine add foo (it converts it to {env-uuid: foo}) ... I'm sending over a Placement value in the MachineParams structure, and the response is that it cannot unmarshal strings to an instance.Placement ; so the question then is how do I pass the argument to the AddMachines | 20:51 |
rharper | request such that it does what the juju cli machine add does ? | 20:51 |
niedbalski | sinzui, this is the simpler way to reproduce ( A. start an instance in a cloud and install lxc on it. With the manual provider, attempt to bootstrap it. ) | 20:51 |
niedbalski | ? | 20:51 |
rharper | I'm using the python-jujuclient as the sender FWIW; | 20:51 |
=== kadams54_ is now known as kadams54-away | ||
natefinch | rharper: placement expects to be scope:directive | 20:57 |
natefinch | rharper: so, like lxc:1 | 20:57 |
rharper | except I can do juju add-machine foo | 20:57 |
rharper | and it will do a env-uuid:foo as an instance.Placement | 20:57 |
rharper | object | 20:57 |
rharper | this allows me to have the provide add that machine (maas backend) | 20:57 |
rharper | I want to do the same via rpc, but I can't see how to pass the args that the Init() in cmd/juju/machine/add.go does | 20:58 |
rharper | it attempts to construct an placement object from the args value, and if it fails, it prepends 'env-uuid' | 20:58 |
natefinch | rharper: this is the code that does the parsing of the string: https://github.com/juju/juju/blob/master/instance/placement.go#L53 | 20:59 |
rharper | yep | 20:59 |
rharper | https://github.com/juju/juju/blob/master/cmd/juju/machine/add.go#L131 | 20:59 |
rharper | that's the bit where it takes extra args from machine add <args> and prepends 'env-uuid' and then calls instance.Placement() | 21:00 |
cmars | thumper, sgtm | 21:00 |
rharper | that's the code that appears to allow juju add-machine foo.maas to pass foo.maas (placement ) to the provide which in turns starts up foo.maas | 21:00 |
rharper | natefinch: what I don't know is how incoming json rpc requests are unmarshal; it appears from the response that it can't convert strings to instance.Placement objects ... http://paste.ubuntu.com/10163887/ | 21:02 |
sinzui | niedbalski, That is one scenario | 21:03 |
sinzui | niedbalski, for my case. I think I need to bootstrap 1.20.14, install lxc, reboot the machine, upgrade to 1.21. I think those are the events that happened on my server | 21:05 |
natefinch | rharper: oh, I see, ok. so for just normal json unmarshalling you just need to make placement an object with Scope and Directive string values so, "Placement": { "Scope": "foo", "Directive": "bar"} | 21:05 |
natefinch | rharper: I actually think that placement parsing code is for translation from the CLI | 21:06 |
natefinch | sorry, my mistake | 21:06 |
rharper | no worries; just trying to figure out how to do the same thing the cli is doing via rpc; | 21:06 |
rharper | lemme play with that now | 21:06 |
sinzui | natefinch, do you have a minute to review http://reviews.vapour.ws/r/910/ | 21:28 |
perrito666 | sinzui: the 2 restore ones are now committed to 1.21 | 21:38 |
sinzui | perrito666, you rock | 21:39 |
perrito666 | sinzui: in this case niedbalski rocks, because he put up with all the "try this" ideas I had and added some of his own :p | 21:39 |
sinzui | thank you niedbalski | 21:40 |
rharper | natefinch: thanks for the tip; I've got it working, I need to extract the environment's config uuid, pass that in as the scope, and the directive uses the machine name; | 21:47 |
natefinch | rharper: cool, glad you got it working | 21:48 |
niedbalski | sinzui, np | 21:56 |
niedbalski | perrito666, thanks for the fixes :) | 21:56 |
=== whit|review-q is now known as whit | ||
perrito666 | I really hate juju bot | 22:17 |
jw4 | perrito666: tsk tst | 22:18 |
perrito666 | jw4: we all do | 22:21 |
perrito666 | admit it | 22:21 |
jw4 | perrito666: lol | 22:27 |
* hazmat pats juju bot on the head | 22:30 | |
jw4 | heh | 22:31 |
alexisb | ericsnow, release call? | 22:32 |
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
sinzui | wallyworld_, can you review https://github.com/juju/juju/pull/1580 | 23:03 |
wallyworld_ | sure | 23:03 |
wallyworld_ | well that was hard | 23:04 |
ericsnow | alexisb: sorry, had a dentist appt. | 23:08 |
anastasiamac | waigani: morning! as an OCR,could u plz cast ur eyes over http://reviews.vapour.ws/r/888/ | 23:36 |
waigani | anastasiamac: yep, just finishing a rather big one off, you're next on the list | 23:37 |
anastasiamac | waigani: thnx :D | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!