[01:28] <qwebirc18289> Anybody notice that lately mythfrontend eats CPU when idle again?  I think it's tied to ICEAuthority, but touching the file as root to keep it from recreate it locks out XFCE from logging in.


[00:01] <perrito666> katco: how optional am I on the second standup?
[00:03] <anastasiamac> perrito666: it's almost philosophical - what variations of optional there are? hard optional? soft optional? :D
[00:03] <anastasiamac> perrito666: disclaimer:  this question ^^ does not imply ur optionality
[00:05] <perrito666> anastasiamac: there is a whole range between "we cant live if living is without you" and  "I dont ever want so see you again"
[00:05] <perrito666> (I had to google for the second song, there aren't as many hate you songs as one would expect)
[00:06] <anastasiamac> perrito666: really, i was told swift covers a lot of hate ranges
[00:07] <perrito666> anastasiamac: the thing is, that is very close to my bike time and I might not make it everyday
[00:08] <anastasiamac> perrito666: ack. i have school drop-off at that time too, so cannot do either :/
[00:11] <wallyworld> menn0: thanks for review, i've updated pr
[00:11] <menn0> wallyworld: for some reason RB isn't showing any changes between diffs 1 and 2
[00:11] <menn0> wallyworld: but I trust you, so ship it
[00:11] <wallyworld> hmm, ok, ty, i double check
[00:12] <menn0> wallyworld: it says there's files changed but when I what to see the diffs there's nothing
[00:12] <menn0> looks like a RB problem
[00:13]  * perrito666 sends the kind of mail that makes someone hate you
[00:13] <wallyworld> menn0: i just checked github and the commit it there
[00:13] <wallyworld> so wtf rb
[00:13]  * menn0 looks quickly at the changes on GH
[00:14]  * wallyworld waits in anticipation
[00:14] <menn0> wallyworld: looks good! my ship it stands :)
[00:14] <wallyworld> yay, tyvm
[00:23] <wallyworld> anastasiamac: hey, i commented on the pr, sorry it needs rework
[00:23] <anastasiamac> wallyworld: i disagree with ur stmt
[00:24] <anastasiamac> wallyworld: quick hangout?
[00:24] <wallyworld> sure
[00:24] <anastasiamac> 1:1
[00:25] <mup> Bug #1546348 opened: cannot use or destroy controller after bootstrap <azure-provider> <bootstrap> <ci> <ec2-provider> <gce-provider> <joyent-provider> <kill-controller>
 <regression> <status> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546348>
[00:25] <mup> Bug #1546350 opened: All juju models tagged with "local" <azure-provider> <ec2-provider> <gce-provider> <joyent-provider> <openstack-provider> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546350>
[00:36] <perrito666> state tests take a bit too long
[00:40] <perrito666> someone thought this was a useful test failure error:
[00:40] <perrito666> Error: entity contents mismatch; same length 1
[00:41] <anastasiamac> perrito666: juju deals with paradoxes :D
[00:44] <axw> wallyworld: I think the CI issue is due to the change from <controller> -> local.<controller>
[00:44] <wallyworld> ah
[00:45] <wallyworld> axw: that sounds like it's Ci scripts not juju
[00:45] <axw> wallyworld: model "aws-deploy-trusty-amd64" not found    <-- that'd be because it's called local.aws-deploy-trusty-amd64
[00:45] <wallyworld> axw: that's the model though not the controller
[00:46] <axw> wallyworld: yeah, the admin model is currently called the same as the controller
[00:46] <wallyworld> axw: ah, ok, so when we create the admin model,  we need to strip local.
[00:46] <axw> wallyworld: that's going to cause problems, due to code expecting controller==model
[00:46] <axw> wallyworld: (without the branch I'm working on)
[00:46] <wallyworld> fark
[00:47] <wallyworld> axw: so we need to get your current branch landed i guess
[00:47] <axw> wallyworld: yeah, I think so.
[00:47] <axw> wallyworld: in the mean time, CI could prefix with local.
[00:47] <axw> not sure how much effort that'd take
[00:47] <wallyworld> ok, i'll let the qa folks know. i don't think they'd be up for changing scripts now
[00:56] <axw> wallyworld: they'll need to change them to expect the model name to be "admin" anywya, in case that's not obvious
[00:56] <axw> unless we change it to be the non-prefixed controller name as an intermediate step
[00:57] <wallyworld> axw: i'm discussing with sinzui in #juju now
[04:00] <blahdeblah> Anyone able to explain to me why juju does what it does to /root/.ssh/authorized_keys, and what I can do to fit in with what it does whilst still enabling what I want, which is that a charm needs to be able to write working entries in there.
[04:00] <blahdeblah> There should have been a ? somewhere in that line.
[04:04] <wallyworld> np
[04:18] <natefinch> does anyone know how to debug the uniter tests?  The failures basically read like "Here's a big struct vaguely describing what the test is... oh something failed somewhere"
[04:19] <natefinch> brb
[04:20] <bradm> anyone here know about the multi user stuff?  say we were to run it on top of an openstack cloud, we would only need the top env to be deployed with juju 2.0, right?  the underlying cloud could be a stable juju, say 1.25.3?
[04:36] <natefinch> back
[04:37] <natefinch> bradm: yeah, the juju that deploys openstack wouldn't need to be multi-user unless you cared about having multiuser for controlling openstack itself
[04:37] <natefinch> bradm: you could definitely have whatever juju deploys on top of openstack be 2.0+ to get multi-user for those services
[04:38] <natefinch> bradm: the layers don't talk to each other at all.  As far as the top level juju is concerned, it doesn't know or care how openstack is deployed.
[04:39] <bradm> natefinch: excellent, I thought that was the case but wanted to confirm before deploying with 1.25.3 for the underlying stack
[05:08] <axw> wallyworld: RB bot seems to be asleep, here's the first fix: https://github.com/juju/juju/pull/4442
[05:09] <wallyworld> ta, will look soon
[05:20] <wallyworld> axw: damn, you and i are going to conflict :-)
[05:20] <axw> wallyworld: where? register?
[05:21] <wallyworld> SetBootstrapEndpointAddress
[05:21] <wallyworld> maybe elsewhere
[05:21] <axw> wallyworld: ah. my changes there are pretty trivial
[05:21] <wallyworld> yeah, i have 2 tests to fix before proposing, we can land yours first
[05:28] <wallyworld> axw: so just to confirm, "-m model" works, and tags are without local-
[05:28] <axw> wallyworld: I'll bootstrap aws now to verify, but tested with lxd and -m model works
[05:28] <wallyworld> great
[05:36] <anastasiamac> axw: wallyworld: when/if u get a chance, PTAL "simple"streams PR - surface difference increased somewot :P
[05:42] <axw> wallyworld: confirmed that tags don't have local in them, and I can do "juju status -m <controller-name-without-local-prefix>"
[05:43] <wallyworld> awesome
[05:44] <axw> anastasiamac: if you must have them at all: please move all of the bug references out of the production code, and into the tests that verify they're fixed
[05:45] <axw> if we break the code, the tests will fail and the broken tests will point at the bugs
[05:45] <axw> then we don't have bug references littered all over the code
[05:48] <anastasiamac> axw: sure
[05:58] <axw> wallyworld: based on your comment "we don't want one or the other", should we be changing the data sources to take a set of public keys?
[05:59] <wallyworld> axw: we could do that, or create separate datasources. it's really a corner case for this image-metadata-url datasource. in practice, we don't have the private key used on cloud-images.u.c so maybe we just use the custom key if defined
[06:00] <wallyworld> and leave off the key if not defined
[06:01] <axw> wallyworld: so custom ones just use the "user signing key"? sounds sane
[06:01] <wallyworld> axw: except that we also control the official key for tools
[06:01] <wallyworld> and so the qa guys may want to test that with a custom source
[06:01] <axw> simple :)
[06:02] <wallyworld> streams :-)
[06:02] <wallyworld> but we do know what's an image vs tools data source so we can make a call there
[06:02] <axw> yup
[06:02] <wallyworld> except for the common data source at bootstrap
[06:03] <wallyworld> which points to a top level dir containing tools and images from memory
[06:03] <wallyworld> maybe we construct a couple of data sources as needed and allow a signing verification error to be non fatal
[06:03] <wallyworld> i think that's what we do now
[06:04] <axw> wallyworld: different topic: would you be ok with temporarily reverting adding the "local." prefix altogether? then when we're through CI we can add it back, and change the initial mode to admin at the same time
[06:05] <axw> mode=model
[06:05] <wallyworld> axw: sure, the thought had crossed my mind, but the pr landing now makes things good right?
[06:06] <axw> wallyworld: still can't destroy-controller with the controller name minus prefix
[06:06] <axw> wallyworld: dropping the prefix would fix that
[06:06] <wallyworld> we were going to match local if there were no non-local?
[06:06] <wallyworld> that might be a smaller change
[06:08] <axw> wallyworld: so I'm a bit reluctant to add that logic into jujuclient, which currently is agnostic of the names. but adding it in anywhere else would be error prone, given the number of places we're going to write them. and the spec doesn't call for it...
[06:09] <wallyworld> it is agnotic, it was to be a short term fix. the issue is that if we ship with the UX deviating from the spec in such a visible way, there may be issues
[06:09] <wallyworld> ie fix for beta1, remove as soon as beta1 ships and Ci gets updated
[06:11] <axw> wallyworld: it's definitely not not going to be a smaller fix, btw. we'd need to canonicalise the controller names, which we currently expect are canonical
[06:11] <wallyworld> ok, i guess we can release note it loudly
[06:11] <axw> wallyworld: and also already deviating from spec, since model is not admin
[06:12] <wallyworld> yes, but that's not as in your face :-)
[06:12] <axw> it should be trivial to fix both at the same time
[06:12] <wallyworld> ok
[06:12] <wallyworld> let's revert for beta1
[06:12] <wallyworld> and we'll ensure Ci drops the -m etc at the same time
[06:14] <axw> wallyworld: another question I have is whether it should be local. or local: -- we use local: for clouds
[06:14] <wallyworld> yeah, and the spec uses local.model
[06:14] <wallyworld> we can ask rick
[06:15] <axw> wallyworld: hrm actually it can't be local:, because then there'd be ambiguity with "local" as a controller name
[06:15] <wallyworld> ah yes
[06:17] <wallyworld> axw: right, time to see how bad the conflicts are
[06:17]  * wallyworld takes a deep breath
[06:17] <axw> wallyworld: sorry :)
[06:17] <axw> shouldn't be too bad
[06:17] <wallyworld> tis all good
[06:19] <wallyworld> 4 files
[06:24] <axw> anastasiamac: the answer to your last question on the PR is ^^^^
[06:24] <axw> wallyworld: (above "different topic")
[06:24] <axw> erer
[06:24] <axw> anastasiamac:
[06:29] <anastasiamac> axw: wallyworld: plz clarify in PR for posterity (and my sanity)
[06:30] <anastasiamac> axw: m not seeing a definite answer above, just tossing ideas :D
[06:49] <axw> wallyworld: trivial one: http://reviews.vapour.ws/r/3881/
[06:49] <wallyworld> looking
[07:25] <dimitern> axw, hey, could this https://github.com/juju/juju/pull/4444 also fix bug 1546043?
[07:25] <mup> Bug #1546043: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043>
[07:25] <axw> dimitern: that's the one
[07:25] <dimitern> axw, awesome! it was bugging me for a while now :)
[07:29] <axw> wallyworld: I'm going to rename the "create admin model..." card and create another one, since bulk of the work is done. just need to flip a switch to set it to admin
[07:29] <wallyworld> +1
[07:29] <axw> actually I'll just create a new card and transfer points
[07:31] <axw> wallyworld: when you're done, can we have a chat about what's next?
[07:31] <dimitern> axw, you've got a review btw, and I hope you don't mind - I assigned yourself to that bug
[07:31] <axw> dimitern: thanks, not at all
[07:31] <wallyworld> axw: sure, more tests to fix, won't be long
[07:33] <axw> dimitern: master's blocked though, I'll land it once the beta's out I guess
[07:36] <axw> dimitern: why do we care about sorting the addresses w.r.t. v4/v6 on the client?
[07:36] <dimitern> axw, that's ok - btw I've just confirmed your patch prevents apiserver/logsink.log creation
[07:36] <axw> dimitern: thanks
[07:37] <dimitern> axw, ah, that due to the somewhat well-intended-but-not-well-implemented prefer-ipv6 setting
[07:38] <axw> dimitern: where does that preference actually matter though?
[07:38] <axw> dimitern: I'm wondering if we should care on the client
[07:38] <dimitern> axw, it will change soon (first for maas, later for all providers gradually), as we're making controller endpoint selection based on spaces
[07:38] <axw> because we try all addresses
[07:39] <dimitern> axw, we do try all of them, but we still put the last we successfully connected to on top
[07:39] <dimitern> axw, and yeah, it shouldn't matter at the client side
[07:40] <axw> dimitern: ok, thanks
[07:41] <axw> wallyworld: ^^ maybe we don't need to worry about it anymore
[07:41] <wallyworld> that would be good
[07:42] <wallyworld> axw: quick chat now in standup channel?
[07:42] <axw> wallyworld: be there in a sec
[08:20] <frobware> dooferlad_: running 15 mins late for our sync. sorry!
[08:23] <wallyworld> axw: st.ModelUUID is different to st.Model().ComtrollerUUID() since the latter returns model.serverUUID
[08:23] <axw> wallyworld: the UUID of the admin model is the same as the controller UUID
[08:24] <wallyworld> axw: i guess that's true but it seems then we're making an assumption that may change and the code as it is is immune to that
[08:24] <axw> wallyworld: there's also a controllerTag field on state, we could just expose that
[08:24] <wallyworld> ok, maybe the latter is better
[08:25] <axw> wallyworld: avoids a db read
[08:25] <wallyworld> indeed, but mongo is web scale
[08:35] <axw> wallyworld: finished reviewing
[09:10] <axw> anastasiamac: I suggest, for now, you change the image datasources just to use the user-supplied public key
[09:10] <axw> anastasiamac: nobody is likely to be using the official one with a custom location
[09:11] <axw> anastasiamac: and that's a separate issue as you noted in the bug
[09:11] <axw> anastasiamac: so, drop the ImagePublicKey function you added, and just use simplestreams.UserPublicSigningKey in the *image* data sources only
[09:11] <axw> anastasiamac: the tools ones should continue to use SimplestreamsJujuPublicKey
[09:14] <frobware> dooferlad_: ping
[09:16] <axw> anastasiamac: you have a shipit once that's addressed
[09:17] <frobware> dimitern: ping
[09:17] <dimitern> frobware, pong
[09:17] <frobware> dimitern: can we talk about L2 in the standup HO? If not convenient just say.
[09:19] <dimitern> frobware, sure, sounds good
[09:19] <dimitern> frobware, omw
[09:22] <axw> wallyworld: still buggered: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/canonistack-deploy-trusty-amd64/4041/console
[09:23] <wallyworld> oh
[09:24] <wallyworld> axw: so it's just the kill. the cli *appears* ok
[09:25] <wallyworld> oh, also the connect
[09:25] <wallyworld> after bootstrap, damn
[09:25] <axw> wallyworld: actually the kill worked, bootstrap returned an error code
[09:25] <axw> oh, maybe both failed actually
[09:26] <axw> wallyworld: cannot read controller info: model "canonistack-deploy-trusty-amd64:canonistack-deploy-trusty-amd64" not found
[09:26] <axw> for bootstrap and kill
[09:26] <wallyworld> axw: for legacy, we record foo:foo, in new client store, we want just foo, right
[09:26] <wallyworld> so maybe there's a mix up somewhere
[09:27] <axw> wallyworld: oh, my bad. bootstrap is failing due to ssh timeout
[09:28] <axw> ... probably because canonistack
[09:28] <axw> and destroy is failing because it didn't bootstrap
[09:28]  * axw checks a different substrate
[09:30] <axw> wallyworld: sorry, canonistack is non-voting. I'll raise the alarm if another voting substrate fails
[09:30] <wallyworld> whew
[09:30] <axw> so far so good on azure..
[09:33] <axw> wallyworld: it's a little bit unclear, but I think that test you removed is to ensure we can connect with the addresses/creds on disk, without requiring the bootstrap config
[09:34] <wallyworld> ok, i'll take a look
[09:46] <axw> wallyworld: winner: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/azure-arm-deploy/217/console
[09:47] <wallyworld> goo :-)
[09:47] <wallyworld> good
[09:55] <axw> wallyworld: sorry, I didn't see that you had just changed the existing blank address check... leave it if you think there's potential for errors there
[09:56] <wallyworld> axw: a bunch of tests fail which i am fixing. maybe we can hope juju itself is now not broekn anymore
[09:57] <axw> wallyworld: I'll have to go soon, but will check back later to see your changes
[09:57] <wallyworld> ok, np, have a few to go
[09:57] <axw> wallyworld: or I can review tomorrow if you want to finish it tomorrow
[09:58] <wallyworld> would be nice to land tonight, take a peek if you want later and hopefully will be +1
[09:58] <axw> sure
[11:16] <voidspace> dimitern: frobware: http://reviews.vapour.ws/r/3884/
[11:17] <dimitern> voidspace, looking
[11:18] <fwereade> dimitern, am bumping up against cmd/jujud/agent.MachineSuite.testAddresserWorkerNewResult
[11:18] <fwereade> dimitern, is it still relevant, or should we actually just never run it?
[11:18] <dimitern> fwereade, let me have a look
[11:18] <fwereade> dimitern, (or always? which would be bad, because it currently seems like "never" ;p)
[11:18] <fwereade> cheers
[11:19] <dimitern> fwereade, ah, it's disabled as flaky
[11:20] <dimitern> fwereade, but we're dropping the address-allocation feature flag soon
[11:20] <fwereade> dimitern, indeed, but I want to know what the status is of the stuff it's dealing with
[11:21] <dimitern> fwereade, you mean whether to migrate it to use the dep engine?
[11:22] <fwereade> dimitern, I already have, I'm just not 100% sure what the expected behaviour is
[11:22] <fwereade> dimitern, and the agent tests are not making it any easier to figure out ;p
[11:23] <dimitern> fwereade, as it currently is, it should start and stop immediately when address-allocation feature flag is off (as it calls CanDeallocateAddresses first thing before it starts, which in turn uses the flag)
[11:24] <dimitern> fwereade, was that helpful? :)
[11:24] <fwereade> dimitern, it confirms that it's currently doing the right thing
[11:24] <fwereade> dimitern, and I think that *that* specific behaviour doesn't need testing at agent level
[11:25] <fwereade> dimitern, well, ok, it's arguable
[11:25] <dimitern> fwereade, agreed - those couple of tests effectively test the finished worker behavior
[11:26] <fwereade> dimitern, ehh, it's mainly just a bit annoying that my check-all-workers-are-running thing fails when one of the standard workers is sanely and blamelessly not running
[11:27] <dimitern> fwereade, ah :) I see
[11:27] <fwereade> dimitern, and while I *could* just ignore that skipped test I would *know* it'd fail against my current changes when reactivated, and that would be evil
[11:28] <fwereade> dimitern, so I need to take some action and am rambling at you in the hope that it will become clearer :)
[11:28] <dimitern> fwereade, I wouldn't worry too much about that particular test - perhaps an expected failure when not skipped + TODO will make it obvious?
[11:29] <fwereade> dimitern, it's still a timebomb for whoever hits it -- do you recall the nature of the flakiness?
[11:30] <dimitern> fwereade, yeah, it failed to pass under heavy load IIRC
[11:30] <fwereade> dimitern, ok, then I'm entirely unsurprised, bloody singularRunner patch :)
[11:31]  * fwereade hopes what he has is a bit less awful
[11:31] <dimitern> fwereade, my point about not worrying too much about is that we'll drop the addresser soon anyway
[11:31] <fwereade> dimitern, that's even better then
[11:32] <voidspace> frobware: thanks for the review
[11:33] <dimitern> voidspace, I have a concern re updated dependencies.tsv btw
[11:33] <voidspace> frobware: the uint comes from the gomaasapi Space object - so unrelated
[11:33] <frobware> voidspace: np, the only thing that really stuck out was int/uint for ID
[11:33] <dimitern> voidspace, changing just the sha hash makes it difficult to compare the dates
[11:34] <voidspace> dimitern: how do I get the date? Running the update steps for dependencies.tsv shown in CONTRIBUTING.md omitted the date.
[11:34] <voidspace> dimitern: I can just put todays date in
[11:34] <dimitern> voidspace, godeps github.com/juju/juju/...
[11:34] <dimitern> voidspace, dumps the result at the end
[11:35] <voidspace> dimitern: with no dates
[11:35] <voidspace> dimitern: on my machine
[11:36] <dimitern> voidspace, make sure you have the latest godeps
[11:37] <dimitern> voidspace, go get -u -v launchpad.net/godeps/...
[11:38] <voidspace> frobware: the "int" is purely to convert from the  float that comes out of json
[11:38] <voidspace> frobware: I can use uint I suppose
[11:38] <dimitern> voidspace, that's what I got on my in-progress branch when running godeps github.com/juju/juju/...: http://paste.ubuntu.com/15099666/
[11:38] <voidspace> dimitern: are you sure *you* have the latest version?
[11:39] <voidspace> heh
[11:39] <dimitern> voidspace, yes, I did run go get -u -v launchpad.net/godeps/... before suggesting it :)
[11:39] <voidspace> dimitern: I've updated and I get dates
[11:39] <voidspace> dimitern: I'll add it
[11:40] <voidspace> dimitern: I've updated that
[11:42] <mup> Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
[11:42] <dimitern> voidspace, tyvm
[11:43] <dimitern> voidspace, almost done with your review btw
[11:45] <mup> Bug #1546492 changed: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
[11:45] <voidspace> frobware: fmt.Sprintf("%.0f", float) works...
[11:45] <voidspace> and is less round the houses
[11:46] <dimitern> network.Id(fmt.Sprintf("%v", x)) will also work for v interface{} :)
[11:46] <frobware> voidspace: yep
[11:46] <voidspace> dimitern: but if x is a float %v will do the wrong thing
[11:47] <voidspace> dimitern: i.e. 2.0 will become network.Id("2.0") and we need network.Id("2")
[11:47] <voidspace> dimitern: and what comes out of json is a float even if the source is an int
[11:47] <voidspace> because json
[11:47] <voidspace> because javascript
[11:48] <wallyworld> axw: if you're around, pr updated
[11:48] <mup> Bug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>
[11:48] <dimitern> voidspace, uint(2.0) then?
[11:50] <voidspace> or fmt.Sprintf("%.0f", v)
[11:50] <voidspace> rather than strconv.Itoa(uint(...))
[11:53] <voidspace> dimitern: frobware: did you get disconnected too or was it just me?
[11:57] <voidspace> dimitern: I don't think newAddressOnSpaceWithId should move to network
[11:57] <voidspace> dimitern: in future we'll be setting provider id *or* name
[11:57] <voidspace> dimitern: at which point we'll probably need a "NewAddressOnSpaceId
[11:57] <voidspace> dimitern: this PR is a little bit of an intermediate one where we're setting both, but it won't stay like this
[11:57] <voidspace> dimitern: probably next PR...
[11:58] <frobware> voidspace:just you
[11:58] <voidspace> frobware: weird
[11:58] <dimitern> voidspace, I think freenode is experiencing DDoS attacks today (yet again)
[12:00] <voidspace> dimitern: ah
[12:00] <dimitern> voidspace, I'm not sure about "or"
[12:00] <frobware> voidspace: I take it back.
[12:00] <voidspace> frobware: hehe
[12:00] <voidspace> dimitern: that's the current plan
[12:00] <voidspace> dimitern: we shouldn't use space names directly from the provider
[12:00] <voidspace> dimitern: so if the space comes from the provider we should set the id not the name
[12:01] <voidspace> dimitern: so if we have a name set we *know* it's a juju name
[12:01] <dimitern> voidspace, what's wrong with having either name and no ID or both?
[12:01] <voidspace> dimitern: rather than having a mix of juju names and provider names floating through our code
[12:01] <frobware> dimitern, voidspace: why can't we indirect through the ID for the name?
[12:01] <voidspace> dimitern: because if you see a name on an address you need to know if it's a juju name or provider name
[12:02] <voidspace> frobware: we should do, that's what I'm saying
[12:02] <dimitern> voidspace, frobware, I think a space name should always be a valid juju name
[12:02] <voidspace> frobware: we won't have an id for ec2 addresses of course because there's no provider id
[12:02] <voidspace> dimitern: but that isn't currently the case with maas
[12:02] <voidspace> dimitern: and our current definition of "valid juju name"
[12:02] <voidspace> dimitern: if they change to be in sync that's a different matter
[12:03] <voidspace> but even then there's no *problem* with being strict on using id *or* name - there's just less need
[12:03] <voidspace> but at the moment there's a need
[12:04] <dimitern> voidspace, yeah - they should change in names so that [A-Za-z0-9-_]+ is a valid juju space name
[12:04] <dimitern> voidspace, but as it will be the case in maas
[12:05] <dimitern> voidspace, s/but//
[12:05] <voidspace> dimitern: yep
[12:05] <dimitern> voidspace, that's why I suggested to keep the name even if we have an ID
[12:05] <voidspace> dimitern: my next PR will address this anyway, so I'm going to drop that issue from this PR
[12:06] <voidspace> dimitern: the trouble is that until they do it (which they say they will but may never do) it's dangerous to mix up juju names and maas names
[12:06] <dimitern> voidspace, I'm ok with that
[12:06] <voidspace> dimitern: cool
[12:08] <frobware> voidspace, dimitern: totally agree with "it's dangerous to mix up juju names and maas names" +1
[12:11] <dimitern> frobware, voidspace, the only danger I can see is due to bugs in maas atm
[12:12] <frobware> dimitern: we should stop working around bugs, IMO. fix the root cause.
[12:13] <axw> wallyworld: are you still working on changing UpdateControllerAddresses to not take UUID?
[12:14] <dimitern> frobware, I'm not saying we should work around the bugs in maas that prevent us in some cases to use a valid maas space name as a juju space name
[12:14] <voidspace> dimitern: well, that maas space name definition is broader than juju is not a "bug", it's due to a lack of communication between us
[12:14] <voidspace> dimitern: it sounds like they will fix it though
[12:14] <voidspace> dimitern: duplicate names are a bug :-)
[12:15] <wallyworld> axw: it takes a controllerUUID in one case - after api login when controller name is not known, only uuid. i guess i could look up controller name at that point
[12:15] <dimitern> voidspace, yeah - spaces allowed in names and duplicate names are 2 bugs they need to fix
[12:15] <axw> wallyworld: when would we ever not know the controller name?
[12:16] <dimitern> voidspace, they said they'll fix those two and we should consider them "fixed" - i.e. build our code onto that assumption
[12:16] <wallyworld> damn, in that one place, i didn't see we had controlle rname
[12:16] <wallyworld> i'll rework a bit
[12:17] <dimitern> voidspace, which means if it's not so - i.e. CI maas setups or other (older) 1.9 maas deployments won't work
[12:17] <dimitern> until those bugs are fixed
[12:21] <blahdeblah> Repeating earlier question: Why does juju mangle /root/.ssh/authorized_keys, and what I can do to fit in with that, whilst still enabling my charm to write a working entry in there?
[12:26] <wallyworld> axw: updated, feature test for register runs ok
[12:26] <axw> wallyworld: ok, looking in a sec. I noticed in CI that manual bootstrap fails because we're now expecting "juju bootstrap manual/<host>", and CI is passing bootstrap-config in config.ayml
[12:27] <axw> wallyworld: should I try and fix it, or just ask CI to retest with that small change?
[12:27] <wallyworld> axw: yeah, saw that too, i beliebe aaron knows about that
[12:27] <axw> wallyworld: we could allow bootstrap-host in config as well, would be better not to deviate from other providers tho
[12:28] <wallyworld> i will ask them to re-test tomorrow, i prefer consistency
[12:29] <axw> wallyworld: LGTM, thanks for changes
[12:30] <wallyworld> axw: np, thanks for review, Ci looking good too
[12:30] <wallyworld> except for manual of course
[12:31] <axw> wallyworld: and a few things say they're still pending, but yeah, lots of green :)
[12:32] <wallyworld> release notes tomorrow, will be quite an essay
[13:15] <voidspace> dimitern: frobware: my branch has an unrelated failure in featuretests
[13:15] <voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)
[13:15] <voidspace> dimitern: frobware: I'll land my branch on maas-spaces2 and fix this failure with a follow-up on master
[13:18] <dimitern> voidspace, sounds good +1
[13:40] <jcastro> is there a quick getting started guide on building juju from source?
[13:40] <jcastro> I think I found a bug in the alpha but I wanted to confirm with trunk
[13:44] <Ursinha> jcastro, maybe there's a ppa with daily builds from trunk?
[13:44] <Ursinha> that would be a good idea regardless :)
[13:46] <Ursinha> (I realize this is not what you're asking for but figuring out such ppa would make me happy as well solve your problem to test trunk :))
[13:50] <jcastro> yeah I am wondering why there's not just a daily PPA
[13:59] <rick_h_> natefinch: wasn't there a thread recently that talked about a doc on building juju core? I can't seem to find it and thought you replied in it.
[14:00] <rick_h_> Ursinha: jcastro we're looking at ways to get builds out faster. Because of the use of streams and such, we don't do daily builds. We need a less invasive way to get that out.
[14:06] <natefinch> rick_h_: it's not really very well written for first timers: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
[14:06] <rick_h_> natefinch: ah ok thanks
[14:07] <natefinch> rick_h_: we really should write a step by step "this is how you build juju"... which I think that document wants to be, but tries to do too much, and so obscures the actual steps you need to do to build
[14:07] <rick_h_> natefinch: agreed, good to find this and we'll see what we can do.
[14:10] <alexisb> natefinch, I used that doc for my first build, wasn't too bad
[14:12] <natefinch> fwereade:
[14:12] <natefinch> fwereade: heh, oops.  Wanted to ask about uniter tests
[14:15] <mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
[14:18] <mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
[14:24] <mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>
[14:31] <natefinch> redacting the API params during tests is dumb.
[14:34] <fwereade> natefinch, oops sorry; uniter tests?
[14:36] <natefinch> fwereade: there's a bunch of "match hooks" where we expect a specific list of hooks to be fired.  I presume that if that list changes, that's a bad thing?  I'm still working on this resources code, and what I'm getting is an extra upgrade-charm hook firing
[14:36] <perrito666> uh, that part still exists?
[14:37] <natefinch> unless something changed in the last 5 or 6 days?
[14:38] <perrito666> I hoped that to go in the uniter refactor sprint
[14:38] <natefinch> also, it seems like there's a bug, or at least an inefficiency in the matchHooks code: https://github.com/juju/juju/blob/master/worker/uniter/util_test.go#L250
[14:39] <natefinch> This match hooks call gets retried until a LongWait expires... but really, after the first time this check fails, we know it'll never ever pass
[14:40] <perrito666> natefinch: it is not a bug, its a feature :p
[14:40] <natefinch> we don't ever remove things from the hooksCompleted list, so if one of them doesn't match... that's it, we're done, it'll never match.
[14:41] <perrito666> no, really its a design flaw
[14:42] <perrito666> that whole thing is a big bad idea, it is depending a lot on an implementation accident
[14:42] <perrito666> but fwereade might not agree with me :p
[14:42] <natefinch> heh
[14:43] <natefinch> yeah, that was my question... I'm changing the implementation slightly... in theory it should fire the exact same events that it did before, but it's possible some niggling bits in watcher/worker code cause a hook to fire more than once... so I can't tell if I've introduced a bug, or if the tests are just too specific about their expectations.
[14:45] <perrito666> ok, fwereade might correct me here, tests rely on a hook order that we dont really guarantee, much of the fact that the expected and obtained hook match depends on delicate time balance
[14:46] <natefinch> som, for example, here's what my change does to the "SteadyStateUpgrade" hooks: http://pastebin.ubuntu.com/15100335/  (I changed the line prefixes so they make more sense without looking at the code, and so the lists match up for easier visual comparison)
[14:47] <natefinch> (that used to be ctx.hooks vs. ctx.hooksCompleted)
[14:50] <perrito666> natefinch: you are triggering more hook calls, which is not bad per se
[14:57] <frobware> fwereade: maybe related to your login issue ^^ "voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)"
[15:03] <frobware> dimitern, voidspace: release note sync
[15:06] <voidspace> frobware: oops, soory - lost track of time
[15:06] <voidspace> frobware: 5 mins, grabbing coffee
[15:11] <dimitern> oops sorry, omw
[15:19] <katco> natefinch: ericsnow_: just want to o/ since no standup in the morning
[15:20] <katco> natefinch: ericsnow_: how's everything going?
[15:20] <voidspace> dimitern: frobware: http://reviews.vapour.ws/r/3886/
[15:21] <ericsnow_> katco: good
[15:21] <ericsnow_> katco: talked with Ian about that worker
[15:21] <voidspace> frobware: fwereade: what login issue?
[15:21] <katco> ericsnow_: yeah? what's the consensus
[15:22] <ericsnow> katco: we don't need a worker for that
[15:22] <ericsnow> katco: the precedent (downloading lxc images) indicates that a worker should not be used
[15:23] <katco> ericsnow: it occurred to me this morning that maybe i didn't represent it accurately. this will be running 100% of the time polling the charm store for all the services, correct?
[15:23] <ericsnow> katco: no
[15:23] <ericsnow> katco: that is a different worker
[15:23] <katco> ericsnow: oh, i see you picked up a diff. card
[15:23] <katco> ericsnow: ok, so the download worker, is not a worker. gotcha. what is it?
[15:24] <ericsnow> katco: the one we were discussing related to using a worker to download from the charm store into state in response to resource-get
[15:24] <mup> Bug #1546272 changed: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:Invalid> <https://launchpad.net/bugs/1546272>
[15:25] <ericsnow> katco: in the API code we stream directly from the charm store into the blob store
[15:25] <ericsnow> katco: (API server side)
[15:25] <katco> ericsnow: and if the stream errors out?
[15:25] <ericsnow> katco: since resource-get blocks a worker doesn't add anything
[15:25] <ericsnow> katco: then we retry (on the server side)
[15:26] <katco> ericsnow: what's the mechanism for doing so?
[15:26] <ericsnow> katco: the usual suspect: utils.AttemptStrategy
[15:26]  * natefinch is here but doesn't want to interrupt.
[15:26] <katco> natefinch: it's irc ;)
[15:27] <natefinch> katco: :)
[15:27] <katco> ericsnow: ok, well glad you worked it out. thanks for bringing it up
[15:28] <katco> ericsnow: natefinch: i'm working on release notes for resources; i'll want you to review here in a bit
[15:28] <ericsnow> katco: also, per wallyworld regarding workers: "workers are more for reacting to changes in state"
[15:28] <ericsnow> katco: no, thanks for the discussion
[15:28] <natefinch> katco: the uniter tests are a beast.  There are currently about 5 failures that I'm trying to determine if they represent bugs I have introduced, or tests that need to be updated.
[15:28] <katco> ericsnow: good to know
[15:28] <ericsnow> katco: it helped paint an even clearer picture about workers in general :)
[15:29] <katco> natefinch: :( i understand those are difficult to deal with. thanks for reaching out to perrito666. we need that done today, so do whatever is needed to make that happen (e.g. pair if necessary)
[15:29] <katco> ericsnow: definitely
[15:30] <ericsnow> katco: FYI, wallyworld also pointed me to the "charmrevisionupdater" worker as something similar to the charmstore poller I'm writing for resource info
[15:30] <katco> natefinch: ericsnow: btw we have a new card we need to point: validating file extensions
[15:30] <katco> ericsnow: oh, awesome!
[15:31] <ericsnow> katco: it's not particularly re-usable for this, but does provide an example; and validation that I'm on the right track :)
[15:31] <katco> ericsnow: just as useful imo :)
[15:31] <ericsnow> katco, natefinch: I'm free to point that whenever y'all are ready
[15:32] <natefinch> fwereade: let me know if you come available
[15:32] <katco> ericsnow: natefinch: gimme 5 and we'll hop in moonstone?
[15:32] <natefinch> ericsnow katco sounds good
[15:33] <ericsnow> katco: +1
[15:38] <katco> ericsnow: natefinch: ok i'm in there
[15:54] <fwereade> frobware, voidspace: nah, I was being dumb, had changed a client-side code path without full awareness
[15:55] <fwereade> natefinch, perrito666: sorry! short version: I am inclined to consider unexpected hook firings to be a problem
[15:56] <fwereade> natefinch, I am available, just quite deep into code, sorry
[15:56] <natefinch> fwereade: understandable. that was my assumption as well.
[15:56] <fwereade> natefinch, cool
[15:58] <fwereade> natefinch, it *may* be the case that the layers of indirection around the tests are such that we can't reliably induce specific uniter behaviour, but that's still a problem
[15:59] <fwereade> natefinch, by the way, I think I'm misunderstanding something -- did I see a recent mail from jam saying that new resources are only delivered on resource-get?
[16:00] <fwereade> natefinch, is it the case that we do an upgrade-charm to inform of new *available* resource versions or something, but nothing has actually changed in the charm at that point?
[16:03] <natefinch> fwereade: we fire upgrade-charm when you push up a local resource to the controller.  At that point, the unit does not have the bytes from the new resource, and must call resource-get
[16:04] <fwereade> natefinch, upgrade-charm seems a bit surprising compared to resources-changed or something?
[16:06] <fwereade> natefinch, the only connection I can see is that they're both sort of to do with the charm, and you can say that about almost anything ;p
[16:06] <natefinch> fwereade: the idea is that the resource bytes are integral to the functionality of the charm. So changing a resource is just as disruptive as changing the charm version
[16:07] <natefinch> fwereade: firing upgrade-charm is what is declared in the spec, per rick_h_, mark, jam, etc
[16:07] <fwereade> natefinch, oh joy
[16:08]  * natefinch is Not In Charge™
[16:08] <fwereade> natefinch, we start by saying "charm logic and payloads can vary independently, let's add tooling to make those use cases easier" and we end up with "upgrade-charm now means two completely distinct things, have fun charmers!"
[16:09]  * marcoceppi watches as this develops
[16:10]  * fwereade turns to marcoceppi and gestures vaguely -- if this *is* a happy outcome for you and those you represent, that's awesome -- is it?
[16:11] <natefinch> marcoceppi, fwereade: http://media0.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif
[16:11] <fwereade> natefinch, haha
[16:11] <marcoceppi> fwereade: I had concerns of not being a hook available, but was convinced that this was okay. If there's still a way to get a hook I'd be happier
[16:12] <marcoceppi> fwereade: if charms have a way to query the version of the resource, without fetching it, then it's not that bad. Just some additional logic in upgrade-charm to determine if it's is new charm code or new resources
[16:12] <fwereade> marcoceppi, yeah, absolutely, any state we show you as a charmer *should* be guarded by some hook that's guaranteed to fire if it changes
[16:13] <fwereade> marcoceppi, or both ;p
[16:13] <marcoceppi> but I'd rather have this feature with upgrade-chram than delay to 2.1
[16:13] <marcoceppi> we can build libraries in the new reactive framework to work around this
[16:13] <marcoceppi> or rather, not work around, but enhance this
[16:15] <fwereade> marcoceppi, sure, understood, I'm just digging to check that "when we introduce new state to charmers, we should introduce new hooks to inform of changes to same" fits with your baseline desires
[16:16] <marcoceppi> fwereade: I'd prefer new hooks, the more granular the event dispatcher the better
[16:16] <fwereade> marcoceppi, because, y'know, if we don't tell you about the changes that's obviously stupid, and if we repurpose old hooks we potentially expose latent bugs all over the charm store by changing what hooks will get run in what situations
[16:17] <fwereade> marcoceppi, cool
[16:18] <fwereade> marcoceppi, to put it another way: you *can* work around a mish-mash of events, many of which mean "some combination of X, Y and Z distinct things changed", but it kinda sucks to have to
[16:18] <marcoceppi> in so many words
[16:19] <marcoceppi> with the exception of the hook thing, th eresources stuff is brilliant
[16:22] <katco> fwereade: marcoceppi: sorry, just read through the backscroll
[16:23] <katco> fwereade: marcoceppi: i think the reason that decision was made is because resources never stand alone, it's always the tuple of the charm and resources that is the concept to consider
[16:24] <marcoceppi> right, but you can also upgrade resources seperately from the charm
[16:24] <katco> fwereade: marcoceppi: so having being notified of a resource being updated is meaningless if you accept that premise
[16:24] <katco> marcoceppi: my understanding is that you cannot
[16:24] <marcoceppi> I was informed otherwise
[16:24] <katco> marcoceppi: resource updated = new rev of the charm
[16:24] <marcoceppi> but since you've done the work I'm happy to accept that
[16:24] <katco> marcoceppi: who am i contradicting?
[16:24] <marcoceppi> so if I release a new version of my applicaiton, that's a charm rev?
[16:25] <katco> marcoceppi: yep
[16:25] <marcoceppi> but it's just an updated resource
[16:25] <rick_h_> marcoceppi: the 'revision' of a charm becomes a 'revision set'
[16:25] <rick_h_> marcoceppi: that set is the published set of the charm rev, and the rev of each resource
[16:26] <rick_h_> marcoceppi: updating any part of that, is an new revision set that much be processed by the upgrade-charm hook.
[16:26] <rick_h_> that's the way it's currently set out.
[16:26] <katco> marcoceppi: check out the 3rd bullet of the 1.0 mvp
[16:26] <marcoceppi> okay, so is there a way for me to query, without first accepting the payload, that I've got a new version?
[16:26] <marcoceppi> in the charm
[16:26] <katco> marcoceppi: as a charmer, not currently. as an admin, yes
[16:26] <rick_h_> marcoceppi: we need that yes. It's not there now, but agree. Honestly it was an optimization thing that came up as we get into using it
[16:27] <marcoceppi> okay
[16:27] <rick_h_> marcoceppi: and good feedback that we need to go back with
[16:27] <marcoceppi> then I'm cool
[16:27] <katco> marcoceppi: you are cool, marcoceppi.
[16:27] <marcoceppi> as long as I can say "resource update"
[16:27] <katco> very cool :)
[16:27] <marcoceppi> at the end of the day, with reactive, we're not going to care about upgrade-charm hook
[16:27] <marcoceppi> well some will, most wont
[16:27] <rick_h_> marcoceppi: katco I think we need something like resource-version or resource-changed to go with resource-get. My concern with resource-changed is that if something fails and you retry, will we have the right answer.
[16:27] <marcoceppi> we'll only really care about @when('resource.<RESOURCE_NAME>.updated')
[16:28] <rick_h_> marcoceppi: katco so I think there's some thought we need to get that right
[16:28] <katco> rick_h_: well, isn't resource-changed redundant? i.e. anytime it would fire, upgrade-charm would also have fired
[16:28] <rick_h_> katco: not as a hook, but as a hook command
[16:28] <rick_h_> katco: e.g. resource-changed mysourcecode
[16:28] <rick_h_> returns true/false
[16:29] <marcoceppi> rick_h_ katco is resource-list a hook-tool?
[16:29] <rick_h_> katco: so if one new resource is uploaded out of 3, I can tell which one I need to untar, process, etc
[16:29] <katco> marcoceppi: no, juju list-resources
[16:29] <fwereade> katco, rick_h_: the issue is surely that upgrade-charm means "your charm logic has changed" and resource-changed means "some of your tweakable blobs have changed"
[16:30] <katco> rick_h_: well, that is an optimization. i believe resource-get on a resource that hasn't changed is a nop
[16:30] <marcoceppi> so, as a charmer, I want to be able to run "resource-list" in a hook with --format json and get something like "resource_name": "version" for each resource
[16:30] <rick_h_> katco: I'm not so sure
[16:30] <fwereade> katco, rick_h_: that we have a tuple of things that represent "exactly what's running on this unit" is... coincidental, if you like? we don't even officially expose charm urls to charmers right now
[16:31] <katco> ericsnow: natefinch: is resource-get on an unchanged resource a no-op right now?
[16:31] <natefinch> FWIW, we certainly could add a command that tells the unit whether or not it has the latest version of a resource.  We store the version each unit has and the version that is current for the service.
[16:31] <rick_h_> fwereade: well it was designed/built to not be coincidental. I see what you mean on "charm logic" vs "blob of data" though.
[16:32] <rick_h_> fwereade: the goal is that when you publish to the charmstore you're declaring "this revision of the charm logic with this revision of this blob and that blob pass tests and work together"
[16:32] <marcoceppi> natefinch: exposing that I think will be crucial to making the join charmversion + resourceversion + upgrade-charm work for a charm authors perspective
[16:32] <rick_h_> fwereade: it's the local case that's more muddy
[16:32] <marcoceppi> joint*
[16:32] <katco> rick_h_: fwereade: yeah it all begins at 1st principles. either the tuple defines the charm, or it doesn't. if it does, then there's no such thing as updating just the blob
[16:32] <rick_h_> marcoceppi: +1 the thing is catching the failure cases and making sure it behaves predictably
[16:33] <natefinch> katco: we don't do that optimization... resource-get will always just download the bytes
[16:33] <katco> natefinch: fair enough for v1
[16:33] <rick_h_> natefinch: right, I think we can't noop right now because it means the hooks aren't idempotent
[16:33] <katco> rick_h_: mm not true
[16:33] <fwereade> natefinch, katco: so the upshot is that every time you get an upgrade-charm, you *have* to resource-get *all* your resources before you can safely move on?
[16:33] <natefinch> rick_h_: sure they are... the bytes on disk are the same before and after
[16:33] <katco> rick_h_: idempotent = end state is always the same
[16:33] <rick_h_> katco: ah, I see. the bytes are in the folder
[16:34] <katco> rick_h_: correct
[16:34] <natefinch> fwereade: yes :/
[16:34] <katco> fwereade: yeah, as designed currently\
[16:34] <fwereade> how does this even happen with a supposed "user focus" in design?
[16:34] <rick_h_> fwereade: no, it just means you have to process your logic.
[16:34] <rick_h_> fwereade: happy to hop on a call if you've got questions
[16:34] <katco> rick_h_: would join to be a fly on the wall
[16:34] <rick_h_> fwereade: but you're starting to cross into unproductive territory here
[16:35] <fwereade> rick_h_, let's, I fear that I misunderstand something horribly
[16:35] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 for all interested parties
[17:08] <perrito666> I think I broke RB
[17:10] <perrito666> k people bbl
[17:10] <perrito666> cheers
[17:28] <mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
[17:37] <mup> Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
[17:40] <mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
[17:43] <mup> Bug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
[17:49] <mup> Bug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>
[17:58] <mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
[18:01] <mup> Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
[18:12] <perrito666> anyone ever heard of StateServerInstances() ?
[18:13] <mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
[18:16] <mup> Bug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
[18:16] <perrito666> fwereade: still here?
[18:17] <perrito666> fwereade: nevermind
[18:19] <mup> Bug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>
[18:19] <perrito666> mup: you are a very annoying thing
[18:19] <mup> perrito666: Strictly speaking, I'm not intelligent enough to understand that.
[18:20] <perrito666> it shows
[18:20] <perrito666> :p
[18:33] <perrito666> bbl
[18:40] <natefinch> katco: so in talking with william and rick, it sounds like we really need a hook command that can tell the charm what resources are out of date for the unit.  That should be really easy, since we have all the backend code, we'd just replicate a bunch of juju resources <unit> in a hook command.
[18:43] <katco> natefinch: i agree that sounds like a good idea. let's revisit after we deliver what's on our plate already
[18:46] <natefinch> katco: yep... and FWIW, rick was able to convince william that we should stick with the charm-upgrade hook, mostly because it's sorta too late to do anything else.
[18:46] <katco> natefinch: yeah
[18:47] <katco> natefinch: i wonder if we looked at how we support things, we couldn't support releasing changes like that more easily
[18:47] <natefinch> katco: I think making a new hook wouldn't been the end of the owrld, but it woudl definitely be  a few more days work than finishing up what we have... and we don't really have a few days to spare.
[18:47] <katco> natefinch: then the conversation becomes, "that's a good idea. we'll do that next month" instead of "omg change course! change course! we can't have a breaking change!"
[18:48] <natefinch> katco: rick was positing that it could be delivered later... I'm not 100% convinced that's true, though, since it would break charms that rely on charm-upgrade getting called.
[18:48] <natefinch> (for resource changes)
[18:48] <katco> natefinch: we should make more liberal use of our versioned concepts outside of the macro version of juju
[18:49] <katco> natefinch: and deprecate old versions of things more regularly (apis, hook commands, cli)
[18:49] <natefinch> katco: well, yeah, we should deliver min-juju-version, which would help with that
[18:49] <katco> natefinch: true
[18:51] <natefinch> katco: (in our spare time)
[18:51] <natefinch> perrito666: you back yet?
[19:02] <natefinch> super short review for someone?  re-enables showing full API params during tests (if you use the verbose flag during the test). http://reviews.vapour.ws/r/3887/diff/#
[19:12] <voidspace> EOW, bye all
[19:23] <natefinch> gah, what I wouldn't give for focused unit tests in the uniter code, so I could narrow down where the bug is in my code :/
[19:39] <katco> natefinch: i think you and ericsnow better pair up to get through this
[19:40] <natefinch> katco: yep
[19:40] <natefinch> katco: sorry, missed when he came back online.
[19:41] <natefinch> ericsnow: help me ericsnowcurrently, you're my only hope!
[19:41] <ericsnow> natefinch: let's get it done!
[19:42] <katco> ericsnow: natefinch: i'm done with admin stuff. reviewing your code now
[19:56] <rick_h_> cherylj: I've got to get the boy from school and will be late to our meeting with folks. Can you bug thumper please?
[19:56] <rick_h_> cherylj: I'll have to work with him to move that back since it's sitting in this bad spot
[19:57] <cherylj> rick_h_: sure, will do
[20:42]  * thumper heading to dentist with daughter two
[20:43] <rick_h_> thumper: doh, looks like I missed you
[20:55] <davecheney> 0 for 2 rick_h_
[20:56] <rick_h_> davecheney: yea, he's avoiding me. Scheduling things during school time and then running off to dentists.
[20:56] <rick_h_> :P
[21:23] <perrito666> Katco I won't make it to your standup, stuck in traffic sorry
[21:23] <katco> perrito666: np, i just marked you and anastasiamac as optional
[21:23] <wwitzel3> perrito666 do it from the car :P
[21:24] <perrito666> I can IRC from traffic jams, how cool is that?
[21:24] <perrito666> Honestly if the lte dongle wasn't in the trunk I could
[21:25] <wwitzel3> ahh, the person grabbed it from you as you pushed them in there?
[21:25] <wwitzel3> ;)
[21:26] <perrito666> There is no respect anymore
[21:28]  * perrito666 shouts at the trunk
[21:35] <perrito666> Traffic is moving bbl
[21:53]  * perrito666 is back
[22:02] <perrito666> wallyworld: around?
[22:05] <wallyworld> in a meeting
[22:06] <natefinch> ericsnow: sorry... I'll give that a test and see if it needs tweaking or anything
[22:06] <natefinch> ericsnow: thanks for the help
[22:06] <ericsnow> natefinch: cool
[22:23] <perrito666> yay go 1.6
[22:28] <marcoceppi> perrito666: time to pack it up and move juju to 1.6 ;)
[22:33] <bogdanteleaga> I'm actually thinking of going back to an older version to save those insane compilation times
[22:38] <perrito666> bogdanteleaga: the only way to advance is forward
[22:40] <mup> Bug #1546790 opened: availability zone not set <juju-core:New> <https://launchpad.net/bugs/1546790>
[22:41] <bogdanteleaga> perrito666, at least by golang 2.0 the test suite run time won't be the bottleneck
[22:58] <mup> Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
[22:58] <mup> Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
[23:01] <mup> Bug #1546794 changed: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
[23:01] <mup> Bug #1546795 changed: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
[23:11] <mup> Bug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>
[23:11] <mup> Bug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>
[23:13]  * perrito666 prepares for standup, suddenly remembers there is no standup today
[23:27] <wallyworld> perrito666: anastasiamac: axw: meeting finished early, let's have standup
[23:29] <mup> Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>
[23:35] <mup> Bug #1546805 changed: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>
[23:38] <mup> Bug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>


[00:21] <domas> anyone ever seen such installer error: http://p.defau.lt/?1XZtv34Fg4nT3UcUa_o1WQ ?
[01:04] <glphvgacs> http://paste.ubuntu.com/412831/
[02:07] <domas> how do I find out partition table on ubuntu-server? parted rounds to megabytes, and fdisk doesn't work with GPT
[02:26] <domas> can anyone share preseed magic to align file systems? :)
[10:17] <nobse> hi
[10:17] <Dr4g> Guys i'm on ubuntu server version 8. What alternatives are there to cPanel ??
[10:17] <twb> ebox
[10:19] <Dr4g> Looks good. But no file directory access, or vhost setup.
[10:19] <twb> IMO all "I want to administer the system from my browser" solutions are utter, utter shite.
[10:21] <Dr4g> Ditto. I'm the sys admin but the directors are uneasy that i'm the only linux dev in the building.
[10:21] <Dr4g> so they want GUI access
[10:21] <Dr4g> I gave them SCP/SFTP acess and phpMyAdmin acess
[10:21] <twb> As opposed to, you know, training the other sysadmins :-/
[10:21] <Dr4g> but still not enough :S
[10:22] <twb> I tried to sell my bosses on putting gnome-system-tools on the server and having the faux sysadmins access it using xming32
[10:22] <twb> Since AFAICT all they REALLY needed was the ability to add and remove users.
[10:23] <Dr4g> hehe
[10:23] <twb> Instead we're running webmin (urgghh!)
[10:42] <Dr4g> twb, what would you want to use insterad o webmin ?
[10:42] <Dr4g> it looked not bad.. mysql, email, ftp administration.
[10:42] <twb> Dr4g: a shell.
[10:43] <twb> Re. FTP, http://mywiki.wooledge.org/FtpMustDie
[10:43] <Dr4g> twb, i was referring to a web product like cPanel
[10:44] <twb> Something that doesn't have hundreds of lintian errors, several of them critical?
[11:16] <Omahn> Does Ubuntu have a command line tool that will collect all the various system configuration files and logs then bundle them up for sending to support?
[11:16] <Omahn> (Other than just creating a tarball each time)
[11:26] <twb> reportbug?
[11:26] <twb> Except that Ubuntu NIHd debbugs :-/
[11:33] <Omahn> Looks like a little script might be easiest.
[12:07]  * amine_ hello
[13:10] <ttx> soren: ping
[13:23] <eagles0513875> hey guys im trying to upgrade ubuntu server from karmic to lucid and i keep getting this message
[13:23] <eagles0513875> Exception during pm.DoInstall():  E:Internal Error, Could not perform immediate configuration (2) on mountall
[13:23] <eagles0513875> any solution or way i can upgrade to lucid
[13:29] <pmatulis> eagles0513875: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/559582
[13:29] <zul> ttx: does euca have a built in dhcp server or uses the dhcp server
[13:29] <eagles0513875> pmatulis: should i go ahead and confirm it
[13:29] <pmatulis> eagles0513875: add that you are also affected (near the top)
[13:31] <ttx> zul: i'm not sure I understand your question... eucalyptus hands off IP addresses to the VMs
[13:31] <zul> ttx: k i think i figured it out
[13:32] <eagles0513875> pmatulis: ty and i added myself to that list :)
[13:33] <eagles0513875> pmatulis: so no way to upgrade
[13:33] <eagles0513875> unless i do an entirely clean install
[13:34] <pmatulis> eagles0513875: are you on #ubuntu+1 ?  if not, you should be if you are running lucid
[13:34] <eagles0513875> pmatulis: i am but im on karmic trying to upgrade im just asking if my solution would be a clean install
[13:34] <eagles0513875> since upgrade process is broken
[13:35] <pmatulis> eagles0513875: i would wait and try again in a while.  is it a VM?
[13:35] <eagles0513875> non virtualized setup
[13:37] <pmatulis> eagles0513875: how did you perform you uprade anyway?
[13:37] <eagles0513875> pmatulis: like the wiki says
[13:37] <eagles0513875> updated fully
[13:37] <eagles0513875> then ran sudo do-release-upgrade -d
[13:38] <pmatulis> eagles0513875: ok.  just asking b/c the bug poster says he manually edited sources.list
[13:38] <eagles0513875> pmatulis: that used to be the way back in the days of edgy etc
[13:38] <eagles0513875> no need for that now
[13:38] <eagles0513875> used to use source o matic hehe
[13:38] <pmatulis> eagles0513875: yes, i know
[13:44] <zul> ttx: the case sensitivy bug has been re-opened fyi ;)
[13:45] <eagles0513875> man this is upsetting
[13:47] <pmatulis> eagles0513875: so your system is a regular install (Server ISO)?
[13:47] <eagles0513875> pmatulis: ya
[13:47] <eagles0513875> nothing is setup on the machine have been using it as a testing and development machine
[13:47] <pmatulis> eagles0513875: ok, i'm investigating
[13:47] <eagles0513875> pmatulis: thanks :)
[13:48] <pmatulis> eagles0513875: fresh karmic install?
[13:48] <eagles0513875> yep
[13:49] <pmatulis> eagles0513875: how long ago?
[13:49] <eagles0513875> few weeks
[13:49] <eagles0513875> its fully up to date
[13:57] <ScottK> ttx: Who's the mysql expert these days?  We (Kubuntu) are still having akonadi/mysql problems and we need to coordinate on packaging changes.
[13:58] <ttx> ScottK: mathiaz
[13:58] <ScottK> ttx: Any idea when he'll be around?
[13:58] <ttx> ScottK: usually in one hour
[13:58] <ScottK> ttx: Thanks.
[14:02] <eagles0513875> ScottK: any ideas on a rather nasty upgrade bug
[14:02] <eagles0513875> bug 559582
[14:02] <ScottK> Nope.
[14:08] <zul> ttx: ping about bug 276472 i vaguely remembering seeing a kernel patch in the samba bugzilla
[14:09] <ttx> zul: if you can find the reference back, post it as a comment -- just give Surbhi a chance to fix it
[14:11] <zul> ttx: ok
[14:12] <smoser> ttx, someone maybe should look at https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/557909 . it needs more information, but looks like it is fairly severe
[14:25] <ttx> smoser: ack
[15:18] <J_P> hi all
[15:19] <J_P> I have this error in client (ubuntu desktop 9.10) trying to mount on server (ubuntu 8.04 server):
[15:19] <J_P> mount.nfs: mount system call failed
[15:20] <J_P> But if I try to mount in localhost (server) mount nfs ok
[15:20] <J_P> any idea?
[15:20] <J_P> no firewall between client and server
[15:22] <zul> ttx: ping had a look at 556343 yet?
[15:23] <ttx> zul: no, it's all yours to debunk
[15:23] <zul> i think we already debunked it
[15:24] <ttx> zul: ah ? We determined that it's not an apparmor issue, but the upgrade problem still remains, no ?
[15:25] <zul> ttx: yeah i dont think its a really a bug though its just a verbose warning
[15:25] <ttx> zul: the post-installation script fails with exit status 1... tat's not a warning
[15:25] <zul> because cups, ntpd, mysql will give the same warning
[15:25] <ttx> zul: I don't care about the "apparmor_parser" warning
[15:26] <jdstrand> the apparmor thing is a verbse warning (and didn't cause the postinst to fail)
[15:26] <ttx> zul:  I care about what makes the upgrade fail (which is *not* the warning)
[15:26] <zul> ttx: k
[15:26] <ttx> zul: if you can't reproduce failure on upgrade (but just the warning) then we'll de-prioritize it
[15:27] <zul> thats what Im saying
[15:27] <ttx> zul: if you do hardy+bind -> lucid upgrade it doesn't fail ?
[15:27] <J_P> anyone?
[15:28] <zul> no it doesnt
[15:29] <ttx> zul: check if mvo is he can reproduce on every run of his upgrade tester... maybe it only occurs when all tasks are installed (that's what he tests upgrade from)
[15:29] <ttx> ...check with mvo if...
[15:29] <zul> k
[15:30] <mvo> zul: it happens only on the tasks all profile, but I can reproduce it in the VM 100% of the time
[15:30] <mvo> zul: its also transient, at the end of the upgrade I can restart bind just fine
[15:30] <ttx> mvo: so it's not blocking ? Perhaps zul missed it if it's just transient
[15:31] <mvo> ttx: well, its transient in the sense that it will fail only during the upgrade. but it still fails and makes dpkg/apt unhappy
[15:31] <mvo> ttx: so we should fix it (or at least figure out more about it :)
[15:32] <mvo> I commited a change that stops apparmor before dpkg runs so at messages about apparmor that are red-herrings should be gone with the next u-m upload
[15:32] <ttx> mvo: you can reproduce on a VM with only server + bind task, or you test the "all tasks" install ?
[15:32] <mvo> all tasks
[15:32] <mvo> I have not tried with server + bind only
[15:32] <ttx> mvo: ok, so maybe it's a conflict, if zul can't reproduce on server+bind
[15:32] <mvo> I can start a run for this in a little while, first the kernel needs to be sorted
[15:33] <ttx> mvo: zul will try to reproduce first
[15:33] <mvo> http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ <- rather unhappy because the kernel can not be downloaded anymore
[15:33] <mvo> ttx: ok, thanks
[15:56] <zul> ttx/mvo: im going to be doing the testing from an iso and will let you know after
[16:04] <ScottK> ttx: Still no mathias.  Anyone else?
[16:31] <axisys> how come I can ssh to a down interface here ?
[16:31] <axisys> http://pastebin.com/izmZ7Ce4
[16:31] <axisys> i can ssh to the ip bind to eth1
[16:33] <eagles0513875> pmatulis: might have found a work around from someone on the bug you linked me to im testing it out now
[16:33] <eagles0513875> this bug https://launchpad.net/bugs/559582
[16:33] <zul> ScottK: ping can you have a look at #535185 for me please?
[16:33] <ScottK> Looking.
[16:34] <mathiaz_> zul: hi - what's the status of mysql-5.0 in lucid?
[16:34] <zul> mathiaz_: will be done tonight
[16:35] <pmatulis> eagles0513875: yeah, i'm getting the bugmail
[16:37] <eagles0513875> pmatulis: testing it as we speak
[16:40] <ScottK> zul: Approved.
[16:40] <zul> ScottK: thanks
[16:44] <eagles0513875> pmatulis:  :) seems to be working
[16:44] <pmatulis> eagles0513875: nice
[16:44] <eagles0513875> hopefully nothing breaks :(
[16:47] <Genk1> Hello ! what is the topology of a network equipped with a an IPS host ?
[16:47] <Genk1> I mean where can I put the ips in my network !
[16:49] <eagles0513875> Genk1: are you talking about a dhcp server
[16:49] <eagles0513875> which dynamically allocates ip addresses to machines on ur network for a certain period of time
[17:14] <ttx> ScottK: mathiaz is here now
[17:14]  * ttx stops for the day
[17:15] <ScottK> mathiaz: We're still having some Akonadi/Mysql issues in Kubuntu.  Could you join us in #kubuntu-devel to discuss possible package adjustments?
[17:34] <zomGreg> can anyone point me to some eucalyptus "certified" ubuntu804 LTS images?
[18:37] <mathiaz> ScottK: sorry - I'm busy for now
[18:38] <mathiaz> ScottK: I should have more time in a couple of hours
[18:38] <ScottK> mathiaz: OK.
[18:38] <mathiaz> ScottK: should I drop by #kubuntu-devel later or could you send me an email?
[18:39] <ScottK> mathiaz: Please drop by.
[18:40] <mathiaz> ScottK: ok - will do in a few hours
[18:40] <ScottK> Thanks.
[18:49] <realmatt> has anyone here used gpart on a 4TB raid array?
[19:38] <Zider> are there any "official" fix for the problem with the init not waiting for cryptdisks to finish before attempting to mount them?
[19:41] <apw> kirkland, about ?
[19:41] <kirkland> apw: yo
[19:42] <apw> we have some patches for kvm which we would like to apply before release, but after the last disaster i'd like to get them tested before i commit them ... would you be able to test them out
[19:42] <apw> and do you have an amd based kit to test on?  i think it went bang there last time
[19:43] <apw> kirkland, plus ... is svm the thing that kvm used on amd64?
[19:44] <Zider> I find it odd that noone else seems to have this issue.. I mean, surely others must run encrypted drives, right?
[19:44] <kirkland> apw: vmx is intel, svm is amd, yeah
[19:44] <apw> Zider, i think you would be supprised just how few do
[19:45] <Zider> apw: perhaps they don't because of the initscript problem :P
[19:45] <kirkland> apw: i do have both intel and amd kit here
[19:45] <kirkland> apw: though my amd kit is very old (though still supports kvm)
[19:45] <kirkland> apw: it's hardly comprehensive
[19:45] <apw> i may have something which can test it
[19:45] <kirkland> apw: do you have a kernel?
[19:45] <kirkland> apw: in a ppa or what?
[19:46] <apw> kirkland, not as yet... if you can test i'll get some building
[19:46] <kirkland> apw: sure, i'll test
[19:53] <sherr> Zider: I run encrypted on my laptop - what bug?
[19:54] <Zider> sherr: mount-script tries to mount the disks before cryptdisks finishes unlocking them
[19:54] <axisys> i have two interface eth0 and eth1 .. with different IP .. eth1 is down.. when I ping from remote host even the eth1 reponds .. but the arp shows mac address of only eth0 .. a bug ?
[19:54] <sherr> Zider: is there a logged bug I can look at?
[19:55] <Zider> sherr: I'm not sure it logs anything special at bootup.. it seems to run all scripts at the same time, which screws up the order if you have many encrypted disks
[20:00] <alvin> Zider: Are you talking about bug 475936 or 456274?
[20:00] <Zider> alvin: where can I see those?
[20:00] <alvin> Well, bug 456274 (show 'm uvirtbot!°
[20:01] <alvin> Zider: Click on the links and see whether the description matches your experience
[20:01] <Zider> alvin: it's 456274
[20:02] <Zider> no wait..
[20:02] <Zider> 475936
[20:02] <alvin> That one is fix released I see
[20:02] <Zider> sorry, I c&p'ed wrong
[20:04] <Zider> well, it somewhat applies anyway, I don't have any random-encrypted disks, just "regular" ones.. but there's 5 of them, and they don't get unlocked in time before mountall runs
[20:08] <alvin> Ah, 5. Hmm, could you uncomment one in /etc/fstab? In LVM, you also can only mount 4 volumes (in Lucid)
[20:09] <Zider> to shorten the start-time you mean?
[20:09] <alvin> No, the LVM thing is actually a real bug, but mabe the shorter start time does do something
[20:10] <alvin> Karmic had the same problems with NFS: network not up fast enough = blocked boot
[20:10] <Zider> I don't use LVM afaik
[20:10] <alvin> Not enough people do :-)
[20:10] <Zider> I don't really see a point to :)
[20:10] <alvin> Oh, there are many. Even for a desktop system. Snapshots for example.
[20:11] <_ruben> resizing and snapshotting are the most common ones
[20:11] <Zider> I don't use either. :)
[20:11] <sherr> LVM is proving very useful. Better perf. for virt. devices as well.
[20:12] <Zider> I just have the drives mounted in separate dirs
[20:15] <alvin> Can someone confirm my suspicion that the upgrade to Lucid changes all LVM fstab entries to mount-by-uuid?
[20:16] <hggdh> smoser: can we chat about the EC2 test cases?
[20:16] <smoser> sure
[20:17] <hggdh> smoser: I see you started working on them, and already have it pretty much done, sort of
[20:17] <smoser> "sort of"
[20:17] <smoser> :)
[20:17] <hggdh> :-)
[20:17] <ChmEarl> when might this be available for karmic or lucid? http://packages.debian.org/sid/linux-image-2.6.32-4-xen-amd64
[20:17] <hggdh> much more than what *I* had, and it is alomost complete
[20:19] <hggdh> smoser: I have some Qs: (1) the tests are quite inclusive, but I am unsure on how we report an error on one of them
[20:19] <hggdh> for example, would it be a good idea to add the different models explicitly?
[20:20] <smoser> models ?
[20:21] <smoser> the general "test suite" is quite hacky.
[20:21] <smoser> and much of the tests (so far) require me to look at console output.  I basically run the test-multi.sh and then 'vi *'.
[20:22] <smoser> which is obviously going to be error prone , but is *considerably* better than launching all that by hand and looking at output one by one.
[20:22] <hggdh> yes, I agree. I am trying to arrive at something that can done by (theoretically) anybody
[20:22] <hggdh> well, as long as this "anybody" is willing to spend money ;-)
[20:24] <smoser> hggdh, so the stuff that isn't automated, can probably be automated. i collect enough data from each instance.
[20:24] <smoser> (and if not, we can just collect more)
[20:25] <smoser> i'd suggest adding a directory of tests that run maybe after console data had been collected, before termination
[20:25] <smoser> that could do things like verifying the ssh keys are what the console said they should be
[20:25] <smoser> hggdh, its embarrasingly hacky at this point :)
[20:26] <smoser> but it works
[20:26] <smoser> one thing i've wondered, though, is why anyone would *want* to spend money just to run an automated test suite
[20:27] <hggdh> smoser: don't ask me... there are always somebody willing (and I really welcome them, BTW)
[20:27] <smoser> well, i understand being interested in finding bugs you care about, or making sure your hardware works.
[20:28] <smoser> but this seems just simply a donation to amazon
[20:28] <smoser> but anyway
[20:28] <hggdh> heh
[20:31] <hggdh> smoser: as far as I can see, I agree with you --- one test is enough here
[20:32] <hggdh> smoser: I mean one *tester*
[21:15] <hggdh> mathiaz: I have added euca-get-console-output to your uec-testing-scripts, can I propose a merge?
[21:34] <airliasdesign> anyone here to help me?
[21:35] <guntbert> !ask | airliasdesign
[21:36] <MagicFab> hi all
[21:36] <airliasdesign> I'm looking into possible server OS options for a new website I'm running, and I'm looking to run a clouding setup with Ubuntu as my OS, would it be possible to run 1 instance of Apache with all of my node resources dedicated to that Apache server, then run a MySQL cloud, then a mail cloud and so forth?
[21:37] <airliasdesign> In other words, it would be separate clouds on separate ip addresses and hubs
[21:37] <MagicFab> I was wondering if there is a list of kvm enhancements/new features/fixes that would cover 8.04LTS -> 10.04LTS ? Other than the fully detailed changelog
[21:37] <MagicFab> specifically, re: running Windows guests in KVM (Win2008 server)
[21:38] <MagicFab> nijaba, mathiaz  ^
[21:38] <airliasdesign> is 10.04LTS out yet?
[21:38] <ruben23> hi
[21:40] <guntbert> airliasdesign: not yet
[21:40] <airliasdesign> thought so
[21:40] <airliasdesign> my 9.10 CDs came in the mail yesterday lol
[21:40] <airliasdesign> I'm going to start a collection
[21:40] <airliasdesign> lmao
[21:41] <nimrod10> airliasdesign, it is out in beta : http://releases.ubuntu.com/10.04/
[21:42] <airliasdesign> ahh ok
[21:42] <airliasdesign> anyone know about the clouding question?
[21:42] <airliasdesign> well
[21:42] <airliasdesign> 17 days until 10.04
[21:51] <ScottK> sommer: FYI - Bug #561825
[22:02] <airliasdesign> hey guys
[22:02] <airliasdesign> nevermind
[22:02] <airliasdesign> wrong box
[22:11] <apw> kirkland, dunno what time it is for you, but those kernels are uploading ... will msg the location
[22:11] <kirkland> k
[22:18] <airliasdesign> ok
[22:18] <airliasdesign> I want to replace CentOS with ubuntu
[22:18] <airliasdesign> is there any way to transfer the user's files ?
[22:22] <netnull> ciao ragazzi, ho un problema configurando la posta su un server virtuale tiscali, mi potreste aiutare?
[22:23] <netnull> hello guys..sorry, i didnt see its an english channel.. could someone help me to set up a mail server on a virtual server?
[22:27] <ruben23> hi guys anyway i can implement a domain controller with active directory on an ubuntu server..
[22:31]  * genii ponders "anyway, I can do something" as opposed to "any way I can do something?"
[22:34] <jetole> Hey guys. I'm setting up a small HA web server scenario right now. In this case only 3 web servers where all requests will be round robin setup between the servers. What I wanted to know is what is a good way to keep the filesystem replicated across all servers that will scale well as the number of web servers grows?
[22:36] <jetole> I was thinking about rsync but that doesn't seem well designed for this. DRBD is a thought I had and have experience with but I'm not sure how well that will work as the numbers grow. I have also never tried DRBD with more then two nodes. I have looked briefly into OpenAFS but don't have experience with it. What do you guys recommend?
[22:41] <RoAkSoAx> jetole, i would go with DRBD
[22:41] <RoAkSoAx> jetole, sample setups with new cluster packages can be found in: wiki.ubuntu.com/ClusterStack/LucidTesting
[22:42] <jetole> RoAkSoAx: Thanks for the advice
[22:46] <jetole> RoAkSoAx: I have another question for you. Suppose I want to configure files to be manages by rsync that typically need root access for example /etc/drbd/*. How would I set this up without creating root ssh logins/keys ?
[22:47] <jetole> or is there another way I should manage shared configuration files?
[22:47] <RoAkSoAx> jetole, you can take a look to csync2
[22:47] <jetole> Thanks again. googling now
[22:47] <RoAkSoAx> jetole, http://www.roaksoax.com/2008/06/cluster-sinchronization-tool-csync2
[22:48] <jetole> awesome!
[22:48] <jetole> RoAkSoAx: reading thatnow
[22:49] <RoAkSoAx> ;)
[23:05] <panamaquono> hello
[23:07] <panamaquono> I'm using opera to do this, is that a mistake?
[23:07] <mathiaz> hggdh: hi - merges are free - so please go ahead
[23:07] <panamaquono> I've run into a wall
[23:07] <mathiaz> hggdh: are you using the test rig for now?
[23:07] <panamaquono> I tried to install ImageMagick on my Ubuntu Server
[23:08] <panamaquono> I need to know how to completely remove it
[23:09] <panamaquono> I tried rm -r and that seems to only work on folders, I'm not sure what I'm aiming at is a folder
[23:09] <panamaquono> I'm very novice
[23:10] <panamaquono> is this working?
[23:11] <genii> Yes
[23:11] <genii> panamaquono: Also, yes
[23:12] <panamaquono> wonderful, I wasn't sure I haven't used opera in a while
[23:13] <panamaquono> I tried to wget a fresh version of it and 'roll out the tarball' and then make, and then 'sudo make uninstall' - that was supposed to do it,
[23:13] <panamaquono> but it's still shows up if I type ls
[23:14] <panamaquono> I also believe the actual program to be running
[23:14] <panamaquono> perhaps I should look for a chat room for that thing?
[23:23] <jetole> does anyone know how I can see whats using the most bandwidth on my network from looking at pcap files?
[23:26] <jeeves> what is the be all and end all way of fixing an apt failure?
[23:31] <hggdh> mathiaz: no, I am not
[23:32] <hggdh> mathiaz: your uec-testing-scripts is under ./+junk, should I just send you the diff?
[23:33] <mathiaz> hggdh: can't you create a merge proposal?
[23:33] <jeeves> what is the be all and end all way of fixing an apt failure?
[23:33] <mathiaz> hggdh: or push to your +junk/ branch as well
[23:36] <mathiaz> smoser: are you using the uec test rig?
[23:47] <isnoop> Is there a command line path to upgrade 8.04 to 10.4 Beta2?  Perhaps a flag for do-release-upgrade?
[23:48] <isnoop> -d gave me "An unresolvable problem occurred while calculating the upgrade"
[23:49] <hggdh> mathiaz: I will push to my own +junk, I cannot create a merger proposal for +junk branches
[23:50] <mathiaz> hggdh: ok - that looks good enough
[23:50] <mathiaz> hggdh: can you subscribe me to your branch?
[23:55] <hggdh> mathiaz: done