=== kadams54-away is now known as kadams54 [01:16] jw4 katco: yep, that was baby's first plantuml diagram :) [01:16] axw: lol [01:38] anastasiamac: lmk when you've forwarded it [01:39] ACK! one of my rules was deleting it! [01:41] katco: you mean the 'killfile anastasiamac' rule? [01:42] jw4: lol no [01:42] :) [01:42] jw4: it deleted an email from alexisb as well =| [01:42] jw4: gmails filtering syntax doesn't work like i thought it did apparently =| [01:42] urg. [01:42] katco: waht rule do u have? delete all from anyone starting with "A"? [01:42] hahaha [01:42] anastasiamac: LOL === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [02:44] axw: here's a trivial 1.22 fix when you get a chance http://reviews.vapour.ws/r/927/ [02:44] looking [02:45] wallyworld_: are all the clouds updated? [02:46] axw: the packaging change is for the deb in the cloud archive repo [02:46] right, ok [02:46] so the cloud images don't need updating [02:47] wallyworld_: LGTM [02:47] ty [03:08] wallyworld_: http://www.reddit.com/r/golang/comments/2vo357/if_you_use_jetbrains_intellij_for_development_the/ [03:08] you use intellij right? [03:08] yeah [03:09] i use a go plugin from someone on github [03:09] this might be a different one [03:10] oh, no same one [03:11] i normally compile from source as i've done a patch or two to it [03:14] wallyworld_: http://reviews.vapour.ws/r/923/, PTAL [03:14] sure [03:20] axw: did you push? still the old rev [03:20] wallyworld_: bleh, I guess the hook didn't transfer to RB [03:20] np, i look in gh === kadams54 is now known as kadams54-away [03:32] wallyworld_: I've just rebased and pushing again, I've deleted that file [03:32] ok [03:33] wallyworld_: btw I don't think the storage/pool package should be depending on storage/provider, it should be the other way around if anything [03:33] storage/provider is common providers... I don't think the pool package doesn't need to know about it [03:33] yeah, the dependencies are a little messy [03:34] pool uses provider to reference ProviderType [03:35] maybe defaultpool should move [03:38] axw: done, i hate it how gh sends comments before you have a chance to correct them [03:38] wallyworld_: heh yeah :) [03:38] sorry, I should've waited [03:39] np :-) === kadams54-away is now known as kadams54 [03:56] axw: how idid u come accross the idea article? r u thinking of converting to the dark side? [04:04] anastasiamac: I just saw it on http://www.reddit.com/r/golang [04:04] and no, I am not :) [04:05] axw: ic :D [04:06] axw: m sure if they got runtime debugging going, it would convert a few .. [04:14] works for me [04:19] wallyworld_: debugging works for u? like stepping through at runtime? [04:20] yep [04:20] but it doesn't go over the api [04:20] so limited use [04:20] oh i c... [04:23] anastasiamac: i can step through code in emacs as well :) === kadams54 is now known as kadams54-away [09:11] good morning! [09:13] Muntaner: o/ [09:59] morning [09:59] perrito666, o/ [10:00] heya perrito666 [10:01] voidspace, dooferlad, standup? [10:01] dimitern: see you're in but it doesn't work [10:02] dimitern: omw [10:17] frankban: ping [10:17] perrito666: morning [10:17] hello :) [10:17] frankban: I broke your code and defintely could use a bit of guidance fixing it [10:18] perrito666: hope I can help, what's up? [10:19] frankban: so, this is the deal, I am working on having agent status and unit status split up [10:19] what used to be status for unit, now is status for an agent entity, that holds nothing else other than status [10:19] and unit now has a different status with a new globalKey [10:20] so, for transitions sake, unit uses the same globalKey than it used to for most things except status [10:21] with your last addings to mega/multi watcher it seems that if I am watching agent (that is what you actually want to know) it never gets informed when ports change [10:21] and if I watch unit, it never gets informed of the other changes :) [10:21] I might add agent and unit to the watcher and split things up [10:21] but I will most likely break whatever you are using the watcher for [10:22] so I could use some light in that department [10:23] oh and al of this before coffee [10:23] :-) [10:24] * perrito666 tries to defeat the lazyness to turn on the expresso machine [10:26] perrito666: so the status for the unit is already updated by watching a separate collection right? [10:26] if I let the code as is, yes, it watches the unit and gets updates for port changes (although the states are not the one you would expect) [10:26] and then you loose the agent statuses [10:27] if I change it to watch agent instead, you loose the ports [10:27] so I definitely need to watch both [10:28] perrito666: I am not sure I understand how status and ports are related, perhaps you can show me some code, or we could have an hangout? [10:29] frankban: I can do both :) [10:30] perrito666: https://plus.google.com/hangouts/_/canonical.com/gogogo?authuser=1 [10:31] * perrito666 checks that he can speak english this early, check [10:31] lol [10:32] frankban: hold a sec, my computer jsut los sound... because of reasons [10:32] * perrito666 restart [10:38] * perrito666 is in trying to join the call to long [10:38] there, you go, wrong authuser [10:49] frankban: you froze [10:50] frankban: but that's ok I got the info I needed, Ill let you know whenever this is ready to land so you can take a look [10:52] perrito666: my machine decided to freeze :-/ I am back in the hangout [10:53] frankban: brt [10:55] * perrito666 wonders who designed his computer and didn't add a kb key for play/pause [10:57] I filed bug 1421606 as a blocker [10:57] Bug #1421606: TestAddServiceStorageConstraints fails on ppc64

[10:57] frankban: look into chrome://gpu if your hardware acceleration is dissabled you migh need to hack a bit your chrome launcher to bypass dri check [10:58] perrito666: good to know, ty [11:07] time-appropriate greetings to everyone! just wanted to consult you guys a little on something [11:08] I'm currently working on getting CentOS fully supported (cloudinit and sshinit-capable), my first point of concern being abstracting away the differences between apt and yum (mostly for sshinit purposes) [11:10] my question is, how necessary is it we set up apt-package pinning, I see it's only actually done in a couple of places and does not seem (from what I can discern) to be that necessary really. would dropping the whole pinning process be too much to take? [11:13] aznashwan: without knowing where and why I cant tell you for sure [11:14] perrito666: my bad. they're declared here: https://github.com/juju/juju/blob/master/cloudinit/cloudinit.go#L32 [11:15] aznashwan: not very explicit of what is that for [11:15] aznashwan: doesn't yum support some sort of pinning? [11:16] perrito666: and the only place one is used (apart from a couple of test files), is here: https://github.com/juju/juju/blob/master/environs/cloudinit/cloudinit.go#L370 [11:16] that is a rather important one [11:16] perrito666: yes it does, but for settling priorities for whole repositories, not for a single package available in multiple sources [11:17] aznashwan: you dont want to en up with an unsupported cloud tools [11:18] aznashwan: my take, just add a mock implementtion of pining for the moment [11:19] perrito666: true, but this gets us to a bigger problem: that's a cloud tools repo full of .deb's (which is a topic we'll be pitching next week, about how we also need rmp's for all the specific stuff, like the juju specific mongo package you guys have...) [11:20] aznashwan: I dont think that old app to install debs in redhat still exist right ? :) [11:22] perrito666: that's a good question, either way it wouldn't be too much work, just the juju-mongodb package and these tools, which I suspect you guys have built automatically, and the main juju package for CentOS... [11:22] perrito666: will look further into the matter, and will take your advice for now and just work around this [11:24] aznashwan: seems the easiest way for the moment [11:24] perrito666: much obliged :D [11:36] gsamfira: o/ [11:36] I'll be back at work on windows + juju on Monday [12:15] perrito666: is someone looking at https://bugs.launchpad.net/juju-core/+bug/1421606 I just saw its blocking trunk [12:15] Bug #1421606: TestAddServiceStorageConstraints fails on ppc64

[12:16] i realize that ideally axw or wallyworld_ would be looking at it [12:16] * perrito666 looks [12:16] but I think its past their EOD [12:16] (and thus past their EOW, I believe) [12:16] * perrito666 hears an incoming email from axw as soon as jam said that [12:20] perrito666: he sets them up on notifies from IRC [12:20] lol [12:20] jam: but short answer is no, no one was looking at that, I guess we will have to since that seems to lock CI :) [12:20] perrito666: ype [12:20] yep [12:21] jam: incidentally, isn't today like saturday for you? [12:21] perrito666: yeah, but I had a big meeting, so I was around, and tried to submit one of my backlog packages, respond to email, etc. [12:27] jam: lots of people or very important? ;) [12:28] wwitzel3: very important [12:28] spec review with Mark, though hopefully we'll get that regularly scheduled on a workday for me :) [12:28] ah the infamous: "meeting on saturday or unemployment on monday" :p [12:28] jam: ahh, which spec? [12:29] * perrito666 runs to see his spec to make sure it hasn't changed [12:29] wwitzel3: well, we're hopefully going to be doing regular weekly chats about features we're working on. though today's was about the Juju Unit and Service States (aka charm health) [12:29] s/States/Status/ [12:29] jam: :( I thought we where done with that [12:30] perrito666: nothing major. mostly just moving the stuff we discussed in the overview into the core of the doc [12:30] jam: nice === kadams54 is now known as kadams54-away [12:47] hmm, is writing "shit it" due to friday afternoon? [12:48] TheMue: ? [12:48] dislexic are we [12:48] ? [12:49] typo during review, thankfully not published w/o correction [12:49] ;) === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [13:10] * dimitern steps out for ~1h [13:10] hi all.. a question: trying to bootstrap my ec2 environment in eu-west-1.. but i'm getting the following error: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1a" for flag --hardware: unknown characteristic "availability-zone" [13:10] 13:56 [13:10] juju version 1.22-alpha1-trusty-amd64 [13:11] also juju (at least this version) does not seem to know about t2.micro instances (free tier eligible ) if i specify --constraints 'instance-type=t2.micro' [13:14] ashipika: you can type juju help ec2-provider for specific help with EC2, but the placement directive should just be zone, not availability-zone [13:14] ashipika: also looking at our instance types, you are right, we only know about t1.micro atm [13:17] wwitzel3: zone= [13:19] wwitzel3: but then it says: unknown constraint zone [13:21] ashipika: right, the zone placement should be outsize the constraints [13:23] ashipika: juju bootstrap zone=name --constraints="" [13:24] wwitzel3: juju bootstrap zone="eu-west-1c" —upload-tools -> unrecognized args ["zone=.... [13:26] wwitzel3: ah.. juju bootstrap —to zone=eu-west-1c .... [13:28] ashipika: you got there first :), was just typing that, my fault .. I've never actually used zone with bootstrap, only with add-machine, and with add-machine you don't need to specifiy a --to [13:30] wwitzel3: not solved the problem, though.. still getting [13:30] dimitern: so when you say forwarding needs to be setup in container initialisation, you mean from the "initialiseAndStartProvisioner" method of ContainerSetup. [13:30] wwitzel3: error: invalid value "arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M availability-zone=eu-west-1c" for flag --hardware: unknown characteristic "availability-zone" [13:30] ERROR failed to bootstrap environment: subprocess encountered error code 1 [13:33] ashipika: right, you need to remove that availability-zone from your constraints === kadams54 is now known as kadams54-away [13:33] wwitzel3: i ran -> juju bootstrap --to zone=eu-west-1c --upload-tools === kadams54-away is now known as kadams54 [13:38] wwitzel3: and the same error without —to [13:38] ashipika: try running a destroy-environment (you may have to use --force), to clean up, then retry bootstrap [13:38] wwitzel3: did.. a few times already.. after every failed attempt [13:40] ashipika: you can check ~/.juju/environments , probably an old amazon.jenv hanging around [13:40] wwitzel3: nah.. deleted .juju and ran juju init.. [13:42] ashipika: hrmph .. then I don't know, you may have found a bug, unless someone else here has some ideas? [13:44] wwitzel3: trying with region set to us-east-1 in the .yaml config.. if that fails i'll create a bug report [14:00] dimitern: btw, why do we use int for ports, instead of uint16? [14:18] gsamfira: ping [14:43] hi to everyone! [14:46] TheMue, it's doesn't matter in practice [14:47] TheMue, i.e. saving a few bytes at (de)serialization time is negligible [14:48] dimitern: I'm not talking about parameters, but as a field type which only allows uint16 values. a port number -1 would be strange ;) [14:50] turicasto: o/ [14:51] TheMue: using int means that you get a better failure mode if someone happens to get some arithmetic wrong and passes a negative number [14:52] rogpeppe: a better one? uints can't even be negative [14:53] TheMue: if you accidentally substract 64 from 62 and pass -2, you don't really want it to be treated as 65534 [14:54] TheMue: better to have it fail with an out of bounds error [14:54] rogpeppe: arg, yes, this arithmetic behavior [14:54] TheMue: there's a similar argument for not allowing negative slice indexes like in python [14:55] TheMue, you mean in network.Port ? [14:55] dimitern: yep [14:55] TheMue, yeah, that sounds like a good idea, I'd suggest adding this to your list of things to change in the next PR :) [14:56] dimitern: Number is an int and so could have invalid values [14:56] dimitern: shit, I shouldn't have asked [14:56] :D [14:56] TheMue, they are validated internally, but yeah [14:56] ;) [14:57] dimitern: one of the arguments for static typed languages is to have more safety. thankfully go provides very detailed types here (ok, not uint48 *lol*) [14:58] or uint128 for uuids, but that better would be a bitstring [14:58] TheMue, +1 [15:00] do we do pull requests for just adding a deprecation comment? https://github.com/juju/charm/pull/84 [15:00] TheMue, I'd even go further and suggest having a type PortType uint16 in the network package and use it everywhere for port values [15:00] dimitern: +1 [15:01] * TheMue always likes the simple type definition in Go [15:03] TheMue, yeah, and you can even have methods on it;) [15:03] dimitern: yeah, that's cool === kadams54 is now known as kadams54-away [15:05] ericsnow: wwitzel3 ? [15:08] dimitern, TheMue: a large but totally trivial change: https://github.com/juju/juju/pull/1601/files [15:09] dimitern: i'd appreciate a quick review so that it doesn't get stale, if poss - there are no manual changes there at all. [15:09] rogpeppe, will have a look [15:09] dimitern: ta! [15:09] rogpeppe: currently standup, but will look then [15:09] TheMue: ta [15:16] TheMue: http://reviews.vapour.ws/r/932/ [15:16] TheMue: that is for fixing https://bugs.launchpad.net/juju-core/+bug/1417875 [15:16] Bug #1417875: ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate signed by unknown authority [15:16]

[15:16] wwitzel3: already opened, will review after standup [15:17] TheMue: thanks === kadams54-away is now known as kadams54 [15:29] wwitzel3: +1 [15:31] rogpeppe, LGTM [15:32] dimitern: thanks! [15:32] dimitern: aw, remind me of the juju magic word for submitting a PR please? [15:33] rogpeppe, $$anything-between-two-dollar-signs$$ [15:33] :) [15:35] dimitern: thx, you've been faster [15:35] np [15:35] rogpeppe: won't merge due to missing fix, but is reviewed. so should be comming soon [15:36] TheMue: cool. hopefully it won't conflict. [15:36] dimitern: hey sorry, what are you meaning when you say "d"? [15:36] katco: delete [15:37] perrito666: ty [15:37] katco, :) d==delete this line [15:37] dimitern: so are you referring to whitespace in a lot of those? [15:37] katco: which you would know if you used vi :p [15:37] katco, but d it's nicer and geeky :D [15:37] haha [15:37] perrito666: shouldn't it be dd? [15:37] dd would be clearer :P [15:38] katco, yeah, I don't mind it that much though [15:38] katco won... [15:38] d-> is enough :p [15:38] dd only if you use vim [15:38] dimitern: i tend to use whitespace to aid in readability [15:38] katco: I actually interrupted my lunch to troll you, and you counter troll me [15:38] :p [15:38] and C-k is longer to type :) [15:38] perrito666: i muahaha at you sir! [15:39] katco, I understand [15:39] *LOL* [15:39] katco, so I'll leave it up to you ;) [15:39] dimitern: ok, ty for the review :) [15:39] katco, I'm not done yet :) [15:39] dimitern: oh i know, but i wanted to say ty :) [15:40] * katco making some tea [15:40] katco, np === kadams54 is now known as kadams54-away [15:56] katco, you have a review [15:56] dimitern: tyvm! [15:57] dimitern: hey rq about the SignedURL [15:57] dimitern: i thought this might come up... the new v4 signing messes with request headers, so there's no concept of a signed url [15:58] katco, I'd like to read about this more if you have the source [15:59] dimitern: check out aws/sign.go [15:59] katco, also, is the v4 signing process now mandatory for all s3 operations? [15:59] dimitern: https://github.com/go-amz/amz/blob/v1/aws/sign.go#L82 [15:59] dimitern: it is not; you pass in which signing you'd like into S3 ctor [16:00] katco, ok so for older versions URL and SignedURL still make sense to exist, and at least URL should be implementable for V4 [16:01] dimitern: for v2, signedurl could still work [16:02] dimitern: for URL, it didn't make much sense to me. what would you do with it? [16:03] katco, get a link to something in your bucket that's accessible to public (permission-wise) [16:04] dimitern: ah ok [16:04] katco, :) [16:04] katco, we do still use this in juju IIRC [16:05] katco, and even if we didn't and URL/SignedURL no longer make sense, we can't just drop them - such a change needs a version bump (e.g. a separate PR for v3-unstable) [16:05] dimitern: that was the idea :) [16:06] jam: thanks for the reply re: fakes [16:06] dimitern: so if you'd like to keep SignedUrl, how should we detect that the signing method supports a signed url? [16:06] jam: I sent a follow-up to get some clarification [16:06] katco, I see, well - is this something we'll need to use in juju soon? [16:06] dimitern: it's targetted for 1.23. feature freeze is 2w from today. [16:07] katco, so that's why it needs to go in v2, but because of the versioning rules, we can't also drop stuff from the exported interface [16:07] katco, ...in v2, but we can in v3-unstable [16:08] dimitern: is versioning of goamz tied to something? why can't we do a cut? [16:08] katco, out of respect for any potential users [16:08] dimitern: they're free to remain on v2 aren't they? [16:08] katco, yes [16:09] katco, but once your change lands, their code won't compile anymore with v2 [16:09] if they use URL and/or SignedURL [16:09] dimitern: my change is targetted against v3-unstable isn't it? === kadams54-away is now known as kadams54 [16:09] katco, aww :/ [16:09] katco, that's my bad, sorry - I should've looked [16:10] dimitern: oh no worries.. i was very confused! lol [16:10] katco, and I actually asked you to re-target it :) [16:10] katco, ok, then it's fine [16:10] katco, still isn't URL worth keeping? [16:10] dimitern: sure, i can add that back in [16:10] katco, thanks [16:11] katco, I'll update the review - how about the live tests? [16:11] dimitern: it will be a function that is: .Region.ResolveS3BucketEndpoint(b.Name)+"/"+path [16:11] dimitern: i still need to do that [16:11] katco, however, just a sec [16:11] dimitern: as you pointed out, obviously unit tests pass [16:12] katco, if this needs to go in juju for 1.23, then you'll need to cherry-pick what's relevant from this and backport it to v2, isn't it? [16:12] dimitern: any reason we can't move juju to v3? [16:13] katco, we could, but this'll mean carefully integrating changes from v2, renaming v3-unstable to v3 and branching v4-unstable of it [16:13] katco, as we can't depend on v3-unstable for a release in juju [16:13] dimitern: right [16:14] dimitern: i'm good with whatever you suggest [16:14] katco, there are not many things to port from v2 to v3 IIRC [16:15] katco, then let's agree to do this migration - I have a couple of PRs for goamz which I'll need to land before the freeze, so I'll re-target them to v3 as well [16:15] dimitern: ok cool [16:16] katco, cheers! [16:16] katco, I didn't quite get your response on whether you've run go test -check.v -amazon in s3/ [16:16] dimitern: :) and progress marches inexorably forward! [16:17] dimitern: no i haven't done that yet [16:17] katco, as it should :) [16:17] katco, ok, just a reminder then [16:17] dimitern: yep, ty i didn't know about that flag [16:17] dimitern: i was going to test manually [16:18] katco, that's fine (ideally we'd like a live test using both s3test and live AWS), but at minimum let's ensure no existing local/live s3test/AWS tests break [16:19] dimitern: will do. thanks for the pointers and your help. [16:20] katco, no worries, thank's for bearing up with me :) [16:20] dimitern: it was not a burden; great questions === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1416928 1421621 1421606 [16:20] thanks even [16:20] :) === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [17:21] dimitern: ping [17:21] voidspace, pong [17:21] dimitern: hey, hi [17:21] dimitern: I'm really struggling to test the lxc-broker changes [17:22] dimitern: I could just mock out the call that takes the NetworkInfo and check that the results of PrepareContainerInterfaceInfo are used [17:22] dimitern: but that seems yucky [17:22] voidspace, hmm, let me think [17:22] dimitern: and as far as I can tell the results of calling broker.StartInstance don't include network details to check [17:22] surprisingly result.NetworkInfo is empty (nil) so I can't inspect that [17:22] voidspace, do you have a wip branch up to have a look? [17:23] dimitern: yep, hang on [17:23] dimitern: I'll push what I have [17:23] voidspace, cheers [17:23] ah, there might be an lxc.conf file I can look at... [17:23] just discover3ed [17:23] voidspace, so the result of StartInstance after PCII() did its job must have NetworkInfo populated [17:23] dimitern: shall I check that first? [17:24] voidspace, yes please [17:24] well, it doesn't but I can confirm that our code is being called... [17:24] dimitern: I'll check the conf file and see if it has testable info [17:24] voidspace, because this is later needed in other cases [17:25] voidspace, so, the result of PCII() is used to generate lxc.conf, cloud-init userdata, and to run a few commands essentially [17:25] right [17:25] voidspace, so all these should be testable, but I might've missed something [17:26] testing the commands would just duplicate the production code in the tests so seems pointless [17:27] dimitern: see TestNetworking in this branch [17:27] dimitern: https://github.com/voidspace/juju/compare/container-prepareprovisioner [17:27] voidspace, looking [17:27] dimitern: the output of lxc.NetworkInfo is "[]network.InterfaceInfo(nil)" [17:28] so NetworkInfo on the StartInstanceResult is not populated [17:28] (and I haven't moved forwarding setup to container initialisation yet because that's trivial to do - although also not easy to test) [17:29] niemeyer: thanks for the feedback on "fakes" [17:29] voidspace, not in my demo branch, but it should be populated [17:29] niemeyer: it's very insightful and has given me plenty to think about :) [17:29] dimitern: oh, you mean this is something additional that should be done? [17:31] voidspace, well, my plan is to support passing non-empty args.NetworkInfo to StartInstance() for cases like "start with statically configured network" or "create these 3 nics like this", etc. [17:31] ok [17:32] ericsnow: Glad it's being useful [17:32] voidspace, then, inside PCII() handle what's needed and return an updated NetworkInfo which is then returned by StartInstance for other uses [17:33] voidspace, e.g. to update the firewall rules or something else that happens on the host of the newly provisioned container [17:33] ok [17:33] dimitern: by the way, pretty sure we'll get the keys to the new house on Wednesday [17:33] dimitern: so I'll be in Monday and Tuesday [17:33] voidspace, +1, sure [17:34] dimitern: thanks [17:34] voidspace, so coming back to your question [17:34] voidspace, these are a few ideas of what needs testing there [17:35] voidspace, 1. given a networkInfo and provided networking and address allocation is supported, verify we get an updated networkInfo out of start instance [17:36] (updated like - having an Address, DNSServers and GatewayAddress, as well as ConfigStatic) [17:37] voidspace, 2. test local dns servers are parsed and added, when available (mocking where you read them from ofc) [17:38] voidspace, 3. the necessary commands for setting up routes, etc. are called (also by mocking - there are a few similar examples in the cmd/ package IIRC and around cloudinit/sshinit) [17:39] voidspace, 4. for lxc specifically, check the lxc.conf is updated as expected, and the cloud-init userdata gets updated [17:39] voidspace, all these are just the happy path tests [17:40] voidspace, the failures need testing as well - like if PCII fails or one of the other steps fail [17:41] voidspace, how does this sound? [17:43] dimitern: so that will mean *adding* the networkInfo :-) [17:43] dimitern: lxc.conf does include some details from PCII() (network name and MAC) [17:43] dimitern: testing 2 & 3 will effectively mean duplicating the commands straight from the code into the test [17:44] dimitern: so they're not very good tests [17:44] voidspace, well, not quite :) [17:44] dimitern: mock and record the calls, check the calls match the expected calls [17:44] voidspace, the command tests can separately test the behavior around parsing resolv.conf and setting up iptables, etc. [17:45] dimitern: what do you mean by "command tests"? [17:45]