=== alexlist` is now known as alexlist [01:11] wallyworld: could you please tag goose for juju-1.12 [01:12] sure [01:12] rev 99 i think? [01:12] hold up [01:12] i need this tag, juju-1.12.0 at the same revno as juju-1.11.4 [01:12] ok [01:13] davecheney: done [01:13] * davecheney hugs wallyworld [01:13] * wallyworld goes all gooey [01:13] wallyworld: what cmd did you use ? [01:14] bzr tag -d bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/goose/trunk -r99 juju-1.12.0 [01:14] rev 99 was what i did the other tag for [01:18] ok [01:18] i don't understand bzr tags [01:18] but that dovetails nicely into all the other things i don't understand [01:32] wallyworld: today is a bit here and there [01:32] wallyworld: have to take the dog to the vet for a 2pm apt [01:32] did you want a quick chat now? [01:32] thumper: sure [01:32] thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6 [01:42] If anyone is curious wtf the new guy is doing, I'm going to look at implementing debug-hooks. Feel free to redirect my attention though. [01:45] axw: +1 [01:45] axw: there is a branch for the client side part [01:45] davecheney: yep thanks, I saw you made a start [01:45] but the logic to intercede in the agent is an open problem [01:45] yeah I see there's a problem with replacing the ZK ephemeral node thingy [02:13] thumper: found out what's up with the bot - lyc02 is down for maintenance \o/ [02:14] maybe we shouldn't run prod stuff on canonistack :-/ [02:31] haha [03:37] thumper: we don't really need to record how a machine is started because we know that from the ContainerType attribute, hence can use that to figure out how to get an address [03:37] may still need to record if manually provisioned perhaps [03:37] wallyworld: no... [03:37] yes, manually provisioning hits this [03:38] but in manual case we would just write the ip address directly to Addresses [03:39] so i'm not sure we need to record anything extra [03:40] wallyworld: about my desktop, it seems that there is no eth0 in my /etc/network/interfaces file [03:41] you need to add it [03:41] it won't be there [03:41] well I have an eth0 [03:41] problem is that it has a static ip [03:41] yes, but it doesn't have an entry in that file by default [03:41] and if futz with that, other things fail [03:42] you can add an entry in there with a static ip afaik [03:42] wallyworld: yeah, but that doesn't help the bridge does it? [03:42] or mark it as manual or something like that to tell it not to use dhcp [03:42] this is all getting very confusing [03:42] yes [03:43] those web links from yesterday had examples for nics with static ips i'm sure [03:49] thumper: i think i read somewhere that the host nic needs to be set to promiscuous mode using a pre-up statement on br0 bridge interface [03:50] not sure though [03:50] that sounds right [03:50] otherwise it is likely to filter only those for its mac address [03:55] wallyworld: I'm going to write up a proposal for something hacky that might work [03:55] thumper: i also read that some kernels have filtering enabled which will break it and you need to use sysctrl to fix that [03:55] bigjools: can I have access to your maas instance? [03:55] all very complicated [03:55] it will cost you [03:55] wallyworld: we need a network specialist to work with IMO [03:55] yes indeed [03:55] to make sure we don't fuck up [03:56] bigjools: what's the cost? [03:56] yep. surely we have one of those [03:56] a night in your arms [03:56] haha [03:56] but you have boy couties [03:56] don't worry, it's not transmittable in saliva [03:57] * thumper is speechless [03:57] * bigjools wins \\o/ [03:57] so that doesn't mean he won't get it via other fluids [03:57] * thumper blocks his ears and hands over eyes [03:57] lalalalala [03:57] ok give me an hour or so as I need to finish a review and then I need to refresh the package and OS [03:57] on my maas box itself [03:57] bigjools: not today, but may need for testing next week if that is ok [03:58] sure [03:58] what OS do you need? [03:58] saucy? [03:58] precise [03:58] thumper: what are you going to try? [03:58] you're SoL [03:58] SoL? [03:58] wallyworld: some hackery [03:58] it's currently on raring and I ain't gonna downgrade :) [03:58] Shit Outta Luck [03:59] how am I supposed to put charms on it then? [03:59] * bigjools rolls eyes [03:59] bigjools: isn't this easy with maas? [03:59] the maas server is irrelevant to what gets provisioned on nodes [03:59] ok, in which case I don't care [03:59] yes it's trivial [03:59] good :) [03:59] bigjools: all i need is access to something that I can bootstrap with maas and juju [04:00] actually you probably need the saucy daily since juju broke maas recently [04:00] wallyworld: so, boostrap a maas precise image [04:00] wallyworld: shell in [04:00] wallyworld: tweak the interfaces file [04:00] it was trying to upload zero sized state files [04:00] wallyworld: make sure I have a hacked up juju [04:00] thumper: I will arrange that for you, no prob [04:00] wallyworld: so I can override the default network bridge with an environment variable [04:01] wallyworld: then try to start some containers [04:01] and see if they are pingable / addressable [04:01] bigjools: it needed to create an empty file to get a url it could use later [04:01] bigjools: why did that break? the test doubles worked ok [04:02] yeah.... test doubles ... might have a been a bit different to reality :/ [04:02] it's fixed in latest trunk for maas anyway [04:02] sure, but why does creating a 0 length file break? [04:02] maas was rejecting it [04:02] well that sucks [04:02] indeedy [04:02] but no longer [04:03] thumper: so you are just setting up a "standard" lxc bridged environment [04:06] ? [04:06] wallyworld: yeah, set eth0 to manual [04:06] and bridge to dhcp over eth0 [04:06] i tried that and lxc didn't boot [04:07] worked for me [04:07] on ec2 [04:07] I want to try on metal [04:07] hmmm. ok [04:07] and maas [04:07] may be hacky [04:08] but if it leads to installing openstack nicely on containers in maas [04:08] we may be ok with it... [04:08] maybe [04:08] i just has to work for iom [04:08] it [04:08] huh [04:09] and not be entirely string, spit and duck tape [04:09] but it would be nice to have a network guy say "do it like this" [04:09] * thumper nods [04:09] surely there's someone we can ask [04:09] maybe from is? [04:09] that's going to be part of my email [04:09] will fire up to mramm and william [04:10] so i still don't think we need to record the origin of a machine in state [04:10] since we can write the address to martin's new data model [04:10] I'd be happy enough if we could use hallyn's suggested hackery for IOM and MAAS with something more concrete/understandable later [04:11] hallyn? [04:11] wallyworld: hallyn is serge [04:11] ah right [04:11] wallyworld: sometimes we don't know the ip address until after the machine agent has started [04:11] wallyworld: so the machine agent needs to know how to find out [04:12] well, the the manual provisioning case, it just gets written directly into env [04:12] for lxc, can't we add something to cloud init [04:13] to record the correct address in state so the agent can read it [04:13] I still think that sticking something in state is the right approach [04:13] jsut gut feel right now [04:14] * thumper untangles gut feelings into an email [04:14] we are sticking something in state - the addresses :-) [04:14] no need for any indirection [04:16] * thumper punches wallyworld for not listening [04:16] huh? [04:16] * thumper punches wallyworld because he is frustrated [04:16] perhaps more honest [04:16] stand still wallyworld [04:17] ouch [04:17] i listened, didn't necessarily agree :-) [04:17] I think we need it for later, perhaps not entirely needed now [04:17] as we can force it in [04:17] wallyworld: if you are looking for something to do, we need to be able to parameterise machines with the containers they support [04:17] so let's just do what we are sure we need for now and iterate later if needed [04:18] and be able to set and update that [04:18] and have the deployments honour it [04:18] ok. i think i have hit a roadblock with my removal of control-bucket :-( [04:18] wallyworld: so we can then only start an lxc provisioner if we support lxc [04:18] bootstrap? [04:19] bootstrap works fine. but the next time you try a juju command, it doesn't know what the control bucket is cause it's stored in state and it can't access state cause it needs a control bucket to do so [04:21] which make me wonder how we are going to support someone going to a different pc and using juju for the env they have set up elsewhere [04:22] thumper: so we would parameterise machines based on the provider which created them i guess? ie all ec2 machines support x,y.z; all mass machines support a,b,c ? [04:22] no, I don't think so [04:22] could be kernel limited [04:22] so some kernals support kvm, some don't [04:22] so how do we know then what a machine supports? [04:23] well... [04:23] some job in the machine agent will need to interrogate the machine [04:23] if lxc is not installed, no lxc containers [04:23] if kernal foo, no kvm [04:23] etc [04:23] and then sets state [04:24] doesn't sound very scalable to have to track all the kernal versions supporting kvm etc [04:25] i think also a machine could it self write into state what it supports [04:25] so a job would be called by cloud init and the machine would contact the state server and update its details [04:26] ? [04:33] your guess is as good as mine right now [04:33] and at the end of friday I have run out of fucks to give [04:35] np. i'll try it and see if it works [04:35] lots of dead ends this week :-( [04:35] sometimes you have shitty weeks [04:35] that's life [04:35] and the landing bot is still fucked [04:35] accept it and move on [04:36] * thumper finishes early [04:57] wallyworld: a question about the "signedImageDataOnly" parameter to imagemetadata... Is that about requiring images to be signed, or does it mean the simplestreams index etc. must be signed? [04:58] it's about requiring that the metadata be signed [04:58] not the images themselves [05:05] Ah OK, that explains a few things. Thanks. [05:06] (This was actually documented as I recall, but it's one of those cases where you first need to know enough to rule out the potential for ambiguity.) [05:21] wallyworld: do we have anything like a test double for simplestreams? === jtv1 is now known as jtv [05:32] wallyworld: also, there seem to be "releases" and "daily" versions of the base URL, but also "releases" and "daily" streams inside the indexes found at those base URLs. Is that correct? [06:45] jtv: yes, there are releases and daily. we use releases unless specified otherwise [07:23] wallyworld_: what I mean is, there's separate base URLs for releases and daily, but that doesn't seem to be the same thing as setting the Streams selector to "releases" or "daily," is it? [07:24] i've only ever used the base url with "releases" at the end. and within that, chosen the releases metadata as opposed to the daily metadata [07:25] i've not used a daily base url. didn't know one existed [07:38] Maybe it's outdated... there's a bug open for the "daily" one not having an Azure file. [07:47] jtv: we've always just used the release images for openstack and ec2 [07:48] jtv: as far as a test double - we have tests that set up sample data and a matching http service, but that hasn't been packaged into a re-usable instance [07:49] So I may have to export it. [07:50] export it? [07:51] Capitalize some names. [07:51] sure, but what is "it"? [07:51] testRoundTripper. [07:52] just make a new one [07:52] var testRoundTripper = &jujutest.ProxyRoundTripper{} [07:52] i guess it could be packaged [07:52] And the code that puts it in place. [07:53] i think it's all of 4 lines [07:54] the image data will be different for each test case i would imagine [07:54] mornin' all [07:54] g'day [07:54] wallyworld_: hiya [07:55] rogpeppe: i went to land that simplestreams branch today cause i really need it. but canonistack went down for maintenance and now our landing bot is gone [07:55] and i don't know how to restart it [07:55] wallyworld_: oh dear [07:55] yeah :-( [07:56] wallyworld_: mgz probably does [07:56] the IS guys said why the fuck are you running prod stuff on canonistack? [07:56] i didn't have a good answer :-) === mthaddon` is now known as mthaddon [08:04] rogpeppe: i'm unsure about the correct way to do stuff with the api changes. in the jujud Machineagent Run() method, it is kosher to get a state object using openState() and then go machine = st.getMachine(234) and then invoke methods on the machine object? [08:05] wallyworld_: the correct answer depends on what you're trying to do [08:05] rogpeppe: a code snippet http://pastebin.ubuntu.com/5914001/ [08:05] i want to write some data to the machineDoc [08:06] on which the agent is running [08:08] wallyworld_: i *think* that will probably be best done in one of the machine agent workers [08:08] wallyworld_: probably deployer, or maybe machiner [08:09] rogpeppe: the code to set up the supported containers is in the run method [08:09] so i have the info at hand at that point [08:11] * rogpeppe thinks [08:11] i'll see if i can move the code [08:11] cause some more lxc sruff is done in StateWorker() [08:12] so it might make sense to put it all together [08:12] i'm just reading all this code for the first time [08:12] i think i can stick it in StateWorker() [08:16] wallyworld_: i think that's reasonable for the moment. we're going to be moving away from doing anything in the state worker though, as we start to use the API for everything [08:17] wallyworld_: so we'll need a SetSupportedContainers API call in the relevant worker (or perhaps on MachineAgent.State [08:17] ) [08:17] rogpeppe: except i just saw that StateWorker is only run on bootstrap node. and it just calls openState() anyway. so i might leave the code in the Run method [08:18] wallyworld_: no, every client runs StateWorker currently [08:18] wallyworld_: otherwise nothing would work, because we haven't moved all the agents to using the API yet [08:19] ok. i'm still not across all the new design [08:19] wallyworld_: can we really not tell what containers a machine supports until it comes up? [08:20] wallyworld_: i'm thinking that this breaks the nice usual mode of operation: if i interpret this right, you won't be able to deploy to a given container on a machine until that machine has actually come up [08:21] wallyworld_: or am i misunderstanding what SetSupportedContainers is to be used for here? [08:22] rogpeppe, if you have any clever way of determining the answer to that question we would be most interested to hear it [08:23] rogpeppe, wallyworld_: but I don't think we can prevent adding containers until the host's up [08:23] fwereade: i'm thinking that we should probably *allow* deployment to a container before a machine's up, yes [08:23] fwereade: but the deployment should fail if the container's not supported [08:23] rogpeppe, wallyworld_: isn't that just a provisioning failure? [08:24] fwereade: +1 [08:24] fwereade: but perhaps that's what wallyworld_'s envisaging anyway, i'm not sure [08:24] rogpeppe: there's a method called EnsureLXCContainers [08:24] that is called at the start of the Run method [08:25] wallyworld_: method on what? [08:25] so we know then if lxc is supported [08:25] MachineAgent [08:25] wallyworld_: you mean EnsureWeHaveLXC ? [08:25] yeah [08:25] sorry, bad memory [08:26] rogpeppe: and yes, set supported containers is supposed to be used so that we only attempt to create a container on a host that can support it [08:26] eg not all hosts can run kvm [08:26] or lxc (eg windows) [08:26] wallyworld_, I'm a bit worried about the inconsistency there === tasdomas_afk is now known as tasdomas [08:26] wallyworld_: i think that breaks juju's basic workflow, unfortunately [08:27] wallyworld_, what's the benefit of having two different ways of failing the same operation? [08:27] fwereade: rogpeppe: i have to go have dinner and play soccer, i'll talk to you later this evening when i'm back [08:27] wallyworld_: np, have fun [08:27] wallyworld_, sure, have fun [08:27] fwereade: also, bot is down [08:27] grar, ty [08:27] canonistack got nuked today for upgrade [08:27] and bot disappeared [08:27] and i have nfi how to restart it [08:28] we need to not run bot on canonistack [08:28] anywats, ttyl [08:28] mgz, do I recall that jam handed bot-bouncing duties over to you when he left? [08:48] * fwereade getting breakfast quickly [09:11] fwereade: when you have a moment, can you please read my comment here? https://bugs.launchpad.net/juju-core/+bug/1027876 [09:11] <_mup_> Bug #1027876: cmdline: Support debug-hooks

[09:27] axw, that looks pretty plausible actually [09:27] axw, are you interested in investigating that a little bit? [09:27] yeah, I'd be happy to have a crack at it [09:28] it'll probably take me a little while longer than others, still learning things obviously :) [09:28] thanks for taking a look [09:28] axw, the only wrinkle I can see is clearly communicating what's going on when two users try to debug hooks on the same unit (and making sure it works if two people are doing different units on the same machine) [09:29] axw, cool, that would be very much appreciated [09:29] yeah I dd think of that as I was writing it up... only simple solution I could think of was the time out the ssh command and print something useful [09:30] axw, I can live with a bit of inelegance there, though, it is very much a charmer-focused tool [09:30] actually the flock can do that [09:30] ok [09:30] cool [09:53] so, second part of syncing is in: https://codereview.appspot.com/11910043 [09:53] anyone interested in a review? [09:54] TheMue: I think I can take it. [09:54] jtv: thx [09:57] I'm off. Have a nice weekend everyone. === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: mgz | Bugs: 5 Critical, 76 High - https://bugs.launchpad.net/juju-core/ [10:18] dimitern, ping [10:18] fwereade: pong [10:18] dimitern, any thoughts on CanDeploy? AFAICT we don't really need it [10:19] dimitern, because we'll get unath errors out of Life for any unit we're not meant to know about [10:19] fwereade: well it started as AssignedMachineId [10:19] fwereade: but you're probably right [10:19] dimitern, the plan was that we could drop all of that bit, I think -- "responsible" is now handled implicitly behind the api [10:19] dimitern, that's what getAuthFunc does for us [10:20] fwereade: any chance for mistakes? like recalling a unit we think we cannot access? [10:20] dimitern, so long as we're barfing on error that aren't unath, and we're only returning unauth errors in appropriate situations I think we're good [10:21] dimitern, and CanDeploy just duplicates the work of getAuthFunc from the other direction AFAICT === teknico1 is now known as teknico [10:21] dimitern, you should be able to drop the CanDeploy bit and all tests should still pass, I think [10:21] dimitern, if that doesn't work we should look closer [10:22] fwereade: i'll try that out [10:34] Hi folks — I was wondering why the Virtual RoundTripper in environs/jujutest/metadata.go lists files as an array of filename/content tuples? Wouldn't a map from filenames to contents be easier to understand? [10:42] jtv, sounds like it'd eliminate possible confusion too, but I don;t specifically know about that code [10:51] Thanks. Something to keep in mind... I found it hard to get my mind around the test setup, but I figured it was a better investment than mindlessly copying what everybody else does. :-) [10:51] jtv, +1 [11:13] fwereade, rogpeppe: I'd like to leave the UnitTag, consts, regexpes and other common stuff between api and state that's now duplicated to be cleaned up in a follow up, if you don't mind, not to complicate this CL [11:13] dimitern: sgtm [11:13] dimitern, ah, has duplication already started elsewhere? [11:14] fwereade: yeah, in a few places, not many [11:14] dimitern, ok, yeah, best clear it up all in one go after this then [11:14] fwereade: yeah [11:14] dimitern, does CanDeploy evaporate cleanly? [11:15] fwereade, rogpeppe: I also removed CanDeploy altogether and reverted the NotAssignedError changes, running tests now, then will test it live, if it works it should be done [11:15] dimitern, lovely, tyvm [11:16] dimitern: brill, thanks [11:17] rogpeppe, fwereade: yep, tests pass without it, testing live now [11:33] wallyworld_: standup? [11:56] * rogpeppe goes for lunch [12:00] dimitern: re William question in my review, i don't see a StringsWorker in the worker package (there is only a notifyWorker), so I guess it's not yet implemented, correct? [12:01] dimitern: so, the go-bot creds, can you send them to me? [12:03] frankban: yes it's not - so far only one worker could use it - the machiner, if others appear we can factor out the common code into a stringsworker [12:03] mgz: just a sec [12:04] dimitern: well, the minunits worker will be the second one [12:05] frankban: great [12:06] frankban: we can follow the notifyworker pattern then [12:07] so, for now, people should manually land on trunk I think [12:07] if anyone is not sure how to do that or wants help, poke me [12:08] * dimitern boo we want the bot!! [12:08] :) [12:08] once you bot, you don't want to go back... [12:09] sure! [12:13] fwereade, rogpeppe: https://codereview.appspot.com/11800045/ updated [12:24] so, first step done, a pre-check [12:45] mgz, rogpeppe, I might have lunch before I chat to you guys, will you be around a bit later? am I blocking you at all? [12:45] fwereade: i'll be around [12:47] dimitern: "No, if I do the test still succeeds, but it takes 10s (LongWait) more." [12:48] dimitern: i'd like to understand why that's true [12:48] dimitern: i can't see why it would be [12:48] dimitern: because isRemoved doesn't call Sync or StartSync [12:49] fwereade: I shall lunch as well [12:50] dimitern: and anyway Sync doesn't affect anything except watchers, and waitFor doesn't use a watcher [12:50] mgz: enjoy [12:51] reviewing dimitern's branch but off shortly, cath's whereabouts are unknown [12:51] rogpeppe: I don't know but I observed so [12:51] dimitern: that's really weird [12:52] fwereade: lost in a maze of twisty passages, all alike? [12:52] rogpeppe, london streets have the occasional distinguishing feature, but yeah [12:52] fwereade: ah, i thought you were still in a large country house in wiltshire... [12:54] rogpeppe: pull the branch and try it out for yourself, if you want [12:55] dimitern: am just doing that [12:59] dimitern: i can't reproduce the behaviour [12:59] dimitern: did you change BackingState to State in waitFor too? [13:00] dimitern: because that *would* have the results you saw [13:06] rogpeppe: I changed them everywhere [13:07] rogpeppe: when I saw the delays of 10s [13:07] dimitern: ah, that was not my suggestion [13:07] dimitern: the only place it makes a difference for a call to Sync [13:07] s/for/is for/ [13:07] dimitern: i think it's worth using BackingState only when necessary rather than changing it as if it's magic powder :-) [13:08] s/changing/using/ [13:08] :) [13:08] rogpeppe: ok will try [13:08] dimitern: tbh, i'm not sure we should have provided BackingState at all - JujuConnSuite.Sync/StartSync would probably be a better idea [13:10] rogpeppe: it's useful sometimes [13:11] rogpeppe: with watchers through the api [13:11] dimitern: agreed, but what would you ever need to do on it other than call Sync or StartSync ? [13:12] dimitern: (genuine question) [13:13] rogpeppe: i can't think of other uses, but jam probably has some [13:14] dimitern: i can't think of any other case where it would make a difference [13:14] dimitern: after all, they're both talking to the same underlying mongo [13:16] rogpeppe: but different connections [13:16] dimitern: sure, but why would that make a difference? [13:16] dimitern: we don't do any caching [13:17] rogpeppe: probably nothing, just thinking out loud [13:26] guys, got this in today's update of the whole juju-core stack from trunk: [13:26] # launchpad.net/gwacl [13:26] ../go/src/launchpad.net/gwacl/management.go:317: function ends without a return statement [13:26] I'm on raring [13:27] it doesn't even say if that's an error or a warning [13:27] ahasenack: ah, that's because the builder is running go1.1 [13:27] ahasenack: there are no warnings [13:27] go likes to change syntax every now and then, heh? [13:27] ahasenack: go1.1 is more lenient about return statement positioning [13:28] rogpeppe: so what do I do? [13:28] ahasenack: you could install go1.1 [13:28] no [13:28] that would hide the problem [13:28] ahasenack: most of us use that [13:28] do you plan on backporting go1.1 to raring, quantal and precise? [13:28] ahasenack: that is the plan, yes [13:28] ahasenack: although i don't know where we are with it [13:28] then I'll get go1.1 when it's backported :) [13:29] although it sounds like saucy will be out before :) [13:29] ahasenack: in which case, you should file a bug with gwacl [13:29] ok [13:29]