/srv/irclogs.ubuntu.com/2013/11/20/#juju-dev.txt

=== thumper-afk is now known as thumper
* thumper takes a deep breath01:06
* thumper dives into local provider syslog01:07
* thumper shakes his head03:26
* thumper sighs03:26
* thumper thinks...03:26
axwwhat'cha doing thumper?03:27
thumperaxw: trying to make the syslog udp port configurable03:27
thumperall done for the machines03:27
thumperbut the deployer is a problem03:27
thumperas we need api calls to work it out03:27
thumperthen I notice that the deployer makes multiple api calls instead of just one specialist call03:28
thumpertrying to work out how far to go with this...03:28
thumperthe State address calls methods are icky03:28
thumpersince we ask for Addresses and APIAddresses, we get the environment config twice03:28
thumpersince I also want to get the SyslogPort from config03:29
thumperthat would be another03:29
thumperideally we should just have one call...03:29
thumperI don't want to shave the whole yak03:29
axwheh03:29
thumperwe are incredibly inefficient in the calls03:30
thumperbut it is way less than the network lag03:30
thumperso noone cares03:30
thumperaargghh...03:33
thumperstabby stabby03:33
thumperstate/address.go:103 c.f. :8903:34
* thumper sighs03:35
* thumper gets out the mega-razor with the number one clip03:37
axwthumper: I'm looking at finishing off synchronous bootstrap, specifically the cancellation behaviour03:46
axwI'm thinking of modifying the Environ interface to be like this: http://paste.ubuntu.com/6446222/03:46
axwdoes that look sensible?03:46
* thumper looks03:46
axwthe returned function will do the synchronous bit, and cmd/juju will install a signal handler to tomb.Kill03:47
thumperso the finalisation function is to call back to kill the environment instance03:47
axwno, it's to SSH to the machine and install the agent03:48
axwbut it takes a tomb so it can be cancelled03:49
axwthumper: I made it a callback so the signal handling can be in the CLI03:49
thumperok, I think03:51
thumperyeah, seems ok to me03:51
axwokey dokey, will plough ahead - ta03:52
thumperwell, that is the hind quarters shaved04:04
thumperI should stop shaving04:04
* thumper is reminded yet again how terrible our cloudinit tests are04:06
thumperI'm almost prepared to pay someone to fix these tests04:08
thumperfark04:17
* thumper has a nearly hairless yak04:18
thumperwow...04:33
thumperthat "simple" refactoring is: 25 files changed, 194 insertions(+), 58 deletions(-), total diff size of 846 lines04:33
thumperand that is before I start what the branch needs04:33
* thumper creates another pipe04:33
* thumper takes a breath again and tries to work out what the original aim was before the hairy yak raised its ugly head04:36
* thumper goes swimming04:57
wallyworldthumper: how close are you to pushing a kvm broker implementation?04:57
thumperwallyworld: FWIW, I was able to deploy ubuntu to a local kvm environment04:58
thumperbut no logging04:58
wallyworld\o/04:58
thumperso I need to fix that04:58
wallyworldok, just checking04:58
thumperwallyworld: a day or two04:58
wallyworldi have a branch ready to plug into that04:58
* thumper nods04:58
wallyworldie the NewKvmBroker() is a place holder04:58
thumper:)04:58
wallyworldand just now pushed a ranch to clean up provisioner04:58
thumpercoolio04:59
* thumper has swimming coaching in 15 minutes, so I need to get a move on04:59
thumperciao04:59
wallyworldlater04:59
jammgz: poke09:17
=== axw_ is now known as axw
* fwereade is experiencing some intestinal discomfort and is going to lie down for a bit09:42
TheMuefwereade: get well soon09:47
jamfwereade: rest well, feel better09:49
rogpeppe1rebooting10:34
jamstandup time: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig10:45
jamfwereade: (if you're feeling better) ^^10:45
jammgz, TheMue, rogpeppe, dimitern: ^^10:45
jamespagehey juju devs - I'm seeing this issue in one of the QA labs:10:50
jamespagehttps://bugs.launchpad.net/juju-core/+bug/117831210:50
_mup_Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>10:50
jamespagewhenever I bootstrap a server10:50
jamjamespage: have you set "ssl-hostname-verification: false" in your env config ?10:58
jamespagejam: makes no difference - its a verification failure between the juju client and mongodb11:01
jamjamespage: so do you actually match the description of "you have an outdated .pem on a second machine from the one that did the actual bootstrap" ?11:02
jamespagejam: no this is all on a single client endpoint11:02
jamif you're doing a fresh bootstrap and it still fails, then it isn't exactly that bug11:02
jamthough we might have another one11:03
jamespagejam: probably a new bug then11:03
jamyou *might* have a local ".pem" file that is actually invalid11:03
jamespagejam: where do I find those?11:03
jamjamespage: it would be in ~/.juju/$ENVNAME.pem I believe. New versions of Juju put the cert contents into the $ENVNAME.jenv file11:03
jambut I *think* it tries to use a .pem if it already existed11:04
jamI would have thought you couldn't bootstrap if you had an invalid one, but there have been weirder things11:04
jamjamespage: a pastebin of the output of "juju bootstrap --debug && juju status --debug" might be helpful11:04
jamjamespage: for example, is someone trying to hijack your connection and redirecting you do another machine, or running HTTP on a HTTPS port etc11:05
jamespagejam; http://paste.ubuntu.com/6447597/11:06
jamespagejam: and http://paste.ubuntu.com/6447604/11:10
jamespagejam: I could see stuff in the .jenv11:10
jamespageso I scrubbed .juju/environments and re-tried - same problem11:10
jamespagejam: I can see the client connections being rejected by mongod on the bootstrap node once its up11:10
jamespage(i.e. I can ssh to it)11:11
jamjamespage: can you paste the /var/log/cloud-init-output.log11:13
jamand possibly /var/log/juju/machine-0.log11:14
jamespagejam:sure - can do11:14
jamand if we're being complete /var/lib/juju/**/agent.conf (i think it is /var/lib/juju/agents/machine-0/agent.conf but I'm not positive)11:14
jamjamespage: This is a little bit concerning: 2013-11-20 11:09:15 DEBUG juju.environs.configstore disk.go:77 Making /var/lib/jenkins/.juju/environments 2013-11-20 11:09:15 INFO juju.environs open.go:156 environment info already exists; using New not Prepare 2013-11-20 11:09:15 DEBUG juju.provider.maas environprovider.go:33 opening environment "maas".11:15
jam"Using New not Prepare"11:15
jamI'm guessing that is because you have to sync-tools first?11:15
rogpeppejam: ~/.juju/$ENVNAME.pem is no longer used AFAIK11:17
rogpeppejam: it's all kept in the .jenv file now11:17
jamrogpeppe: I realize we don't create it, but I thought we might use it if it existed11:18
jamas part of the migration strategy11:18
jamrogpeppe: as in, if it exists, we'll put it into the .jenv when we create it11:19
jamespagejam: http://paste.ubuntu.com/6447635/11:19
rogpeppejam: hmm, yes we probably do, if there's no .jenv file11:19
jamespagecloud-init-output11:19
jamjamespage: so I think I can get what I was looking for from cloud-init. Maybe the .jenv next (unless you've already nuked it)11:20
rogpeppejamespage: i understand the issue here - we should do a better job of knowing when to retry a connection11:20
jamrogpeppe: well the problem is that we just bootstrapped and then failed11:20
jamto do status11:20
rogpeppejam: from a different machine, right?11:20
jamrogpeppe: no, from the same machine11:21
jamespagejam: http://paste.ubuntu.com/6447662/11:21
jamespagejenv11:21
jamas in "juju bootstrap && juju status" => bad TLS cert11:21
rogpeppejamespage: ah, ok, i'm looking at bug #1178312 - is that not what we're talking about here?11:21
_mup_Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>11:21
jamespagerogpeppe, I thought so but it appears not11:21
jamrogpeppe: so bug #1178312 is about "I bootstrapped again and now other people can't talk to it because the cert doesn't match"11:22
_mup_Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>11:22
jamrogpeppe: *but* I think james has a different bug which is "I bootstrapped, and I can't connect to the thing I just started"11:22
rogpeppejam: if that's the case, that definitely is a bug11:23
jamjamespage: so if I decode the data in cloud-init-output.log it *doesn't* match the data in your .jenv file11:23
jamespagejam: well that sucks :-)11:24
jamjamespage: you're sure this is a matching "destroy-environment" into "bootstrap" into "status" ?11:24
jamIf you just nuke the file and bootstrap again, it may fail to bootstrap but still generate a new cert, etc.11:24
jamespagejam: cloud-init-output and jenv definately match11:25
* rogpeppe wishes that certificates were encoded in opaque asn1 format11:26
rogpeppes/were/were no/11:26
rogpeppet11:26
jamespagehttp://paste.ubuntu.com/6447671/11:26
jamespagethats status11:26
jamespagethe bootstrap was already OK11:27
jamjamespage: "was already ok" ?11:27
jamespagejam: I'd given you the output of the environment I just boostrapped already11:28
jamjamespage: if you nuked ~/.juju/environments/* then we don't have the cert recorded anymore11:28
jamespagejam: no - that was prior to this run through11:28
jamjamespage: k, so you nuked it, then ran bootstrap and status11:28
jamespageyup11:28
rogpeppei agree with jam - the cert and private key in the cloudinit output don't seem to match the .jenv contents11:28
rogpeppejamespage: you didn't just check the first few lines, did you?11:29
jamespageOK - lemme teardown, scrub and do it again11:29
jamrogpeppe: but does it match the stateserver key or does it match the cacert key11:29
jamI'm checking that one11:29
rogpeppejam: the certificate should be the same in both cases, i think11:30
jamrogpeppe: I thought we had a CA key that then generated other keys for all the agents11:30
jamregardless something funny11:31
rogpeppejam: we do, but i'm just looking at the certificate which signs that key11:31
jambecause .jenv(ca-cert) matches the first ~5 lines of cloud-init-output cacert.decode('base64')11:31
jambut they *don't* match the remaining lines11:31
jamwhich seems surprising11:31
rogpeppejam: i mean which is signed by that key, i guess11:31
rogpeppejam: the first 5 lines are boilerplate11:32
rogpeppejam: the actual rsa key comes later on in the cert data11:32
rogpeppejam: that's why it would be nice to have human-readable certs...11:32
jamespagejam, rogpeppe: http://paste.ubuntu.com/6447700/11:34
jamespagebootstrap-jenv-status - all appear to be a consistent key11:35
rogpeppejamespage: so is it working now?11:35
jamespagejust waiting for the bootstrap unit to startup11:35
jamespage(its is maas on physical hardware)11:35
jamrogpeppe: well, I can load it into python and OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cacert)) but I'm not sure that helps much :)11:36
rogpeppejam: i've used openssl before, i think11:37
jamrogpeppe: I just mean I can get it into a parsed form, but I'm not really sure what to do from there11:37
rogpeppejam: dump it out as text...11:37
rogpeppejam: it would be really nice if we generated the env uuid client-side and encoded in the certificate somewhere11:39
jamespagewtf - now its working11:40
rogpeppejam: here's the textual form of the cert, BTW: http://paste.ubuntu.com/6447718/11:40
jamespagethe bootstrap node landed on a different machine11:40
jamespagewonder if we have something wonky in DNS/DHCP world11:40
rogpeppejamespage: i have a faint suspicion as to what might have been going on for you11:40
rogpeppejamespage: or... maybe not :-)11:40
rogpeppejamespage: if you really were trying to talk to the wrong machine, then everything was working as designed.11:41
rogpeppejamespage: except that it would be nice to have some better error messages11:41
jamespagerogpeppe, I don't think that was the case11:41
jamespageall of the other servers in the lab are powered off apart from the bootstrap node11:42
rogpeppejamespage: that's a fair indication :-)11:42
rogpeppejamespage: so, i suspect that you accidentally bootstrapped twice11:42
rogpeppejamespage: each bootstrap generates its own CA cert11:42
rogpeppejamespage: if you wipe ~/.juju/environments, it can't know that it's a bad idea to try to bootstrap again11:43
rogpeppejamespage: (if a .jenv file already exists, it won't recreate CA cert, BTW)11:43
jamespagesure11:43
jamespagemaybe11:44
jamespagelets see11:44
jamrogpeppe: but if you actually wiped it, then it wouldn't know what machine was started earlier, and it would either (a) look up the provider-state to see if it already existed or (b) generate a new control bucket which means it would bootstrap another machine)11:44
* jamespage runs the full test cycle again11:44
rogpeppejamespage: it would look up the provider-state, which in this case would have the old machine, right?11:45
rogpeppes/jamespage/jam/11:45
jamespagephew11:45
jamespage:-)11:45
rogpeppejam: which makes me think that it would be good to keep the env uuid in the provider state for sanity checking11:46
rogpeppejam: not that we can do that currently, of course11:46
jamrogpeppe: but *bootstrap* would fail with "already bootstrapped" not succeed and just have generated new cruft11:47
jamrogpeppe: I have no problem with the sanity checks.11:47
rogpeppejam: it would, yes, but if you ignored that error message and typed "juju status", wouldn't you get the symptoms we've seen above?11:47
jamrogpeppe: and certainly for bug #1178312 we should notice that it is a TLS error (not a failed to connect but a I didn't get what I thought would be there) and die immediately rather than retrying11:48
_mup_Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>11:48
jamrogpeppe: you would if james hadn't already pasted the bootstrap output without a failure message11:48
rogpeppejam: which also comes back to: if we've generated a .jenv file when bootstrapping, and the bootstrap fails, we should remove the .jenv file11:48
jamrogpeppe: the original bootstrap: http://paste.ubuntu.com/6447604/11:48
jamrogpeppe: I'm a little concerned about: juju.provider.maas environ.go:193 picked arbitrary tools11:49
jambut that shouldn't affect anything with mongo11:49
rogpeppejam: presumably that's not the *original* bootstrap, otherwise there wouldn't have been a .jenv file already there11:50
jamrogpeppe: so to follow the conversation, james had done one in the past, then nuked it and deleted everything from ~/.juju/environments then did it again, and the bootstrap + status + cloud-init-output (etc) were all from that pristine try11:52
jamespageurg - its back11:52
rogpeppejamespage: you've got the same problem again?11:52
jamespagejuju/maas picked a different node (the one that it picked earlier) and I get this issue11:52
jamjamespage: how are you killing the system ?11:52
jamwith "juju destroy-environment" /11:52
jam?11:52
jamespageyes11:53
rogpeppejam: there's actually something useful we can determine from the certs - we can find out when the cert was created11:54
jamjamespage: so if all of this is fresh, the contents of cloud-init-output.log and .jenv give us enough info to see if they are actually not matching.11:54
rogpeppejamespage: ok, so, from scratch now: could you paste the contents of the .jenv file and the contents of the cloud-init-output log file on the bootstrap node, please?11:54
jampreferably in the same paste so we don't get confused later :)11:55
jamespagehttp://paste.ubuntu.com/6447758/11:55
jamespagejenv11:55
jamespagecloud-init-output: http://paste.ubuntu.com/6447759/11:55
jamespagejam, rogpeppe: all yours ^^11:56
rogpeppejamespage: the bootstrap node was bootstrapped on the 8th november11:58
rogpeppejamespage: it has not just been created11:58
rogpeppejamespage: i guess that means that destroy-environment has not destroyed it correctly11:58
TheMuerogpeppe: any chance to take a quick look on https://codereview.appspot.com/24040044/11:59
TheMue?11:59
rogpeppejamespage: which is, i suppose, only to be expected, because we're using the new metadata to try to destroy the old environment11:59
jamespageurgh - OK - lemme go check wtf is going on11:59
jamespageits being powercycled but it looks like its not being re-isntalled11:59
rogpeppejam: would it be a terrible security hole if we allowed unauthenticated access to an API to find out its uuid?12:01
jamrogpeppe: the clietn would still have to allow a TLS connection to a machine it doesn't recognize12:02
rogpeppejam: not necessarily12:02
rogpeppejam: we could allow http access for just that info12:02
rogpeppejam: although... https and http are on different ports, aren't they?12:02
rogpeppejam: or, actually, it's just a client-side thing isn't it?12:03
jamso I think you can technically do both on the same port, but it is really hard to do12:04
jambecause https is just TLS and raw HTTP underneath12:04
jamand I *think* the server inits the TLs data12:04
rogpeppejam: we could just provide a UUID method alongside Login, and the client could fall back to trying https allowing any cert to make a decent error message12:04
jamrogpeppe: well, we can assume that the UUID is wrong if the TLS cert doesn't match12:05
jamI don't think reporting a UUID actually helps *users*12:05
jamas they don't know WTF12:05
jamit is12:06
rogpeppejam: well, if the TLS cert doesn't match, it may be because someone's trying to break in, i suppose12:06
jamrogpeppe: if they can break in, then unauthenticated UUID isn't going to help us12:07
rogpeppejam: another possibility is that the client could look at the certificate presented by the server and use it to tell the user when the environment was bootstrapped12:08
rogpeppejam: that's probably more useful12:09
rogpeppejam: but i do think that env uuids will become more useful (and recognised) as time goes on and multi-environment setups become more common.12:09
jamrogpeppe: it is still a UUID which means random hex bytes12:10
jamnot "my environment named X"12:10
jamI think env name + timestamp might make way more sense to the user12:10
rogpeppejam: we have to think carefully about the role of environment names12:11
rogpeppejam: currently there's nothing stopping an environment having different names for different clients, i think12:11
rogpeppejam: s/for/when used by/12:12
rogpeppejam: currently an environment certificate does include the name that the environment was given, but that's by no means unique12:13
jamrogpeppe: sure, but it isn't quite about uniqueness, it is about giving them something that they can understand12:14
jamand UUID is not that12:14
jamthey can lookup a UUID somewhere, and kind-sorta-squint to see if it looks like this other one12:14
jambut it doesn't have *meaning*12:14
rogpeppejam: i'm concerned it might be misleading12:15
rogpeppejam: for example, if i send someone a .jenv file and they store it as "foo.jenv" but the original bootstrapper named it "bar.jenv", the messages will print "bar" but the user would expect "foo"12:16
rogpeppejam: because that's their local name for the environment12:16
jamrogpeppe: if you send it to them, it has a name already12:16
jamso "yes" with a big "but not really"12:17
rogpeppejam: depends how you send it to them12:17
jamrogpeppe: 90% of all ways involve a filename  (yes you could paste it somewher)12:17
rogpeppejam: yeah, i was thinking pastebin12:18
rogpeppejam: and i might *need* to rename it - for example, if you sent me an "ec2.jenv", i'd need to rename it so it didn't clash with my own env of that name12:19
rogpeppejam: i think this may tie in with user auth stuff12:19
rogpeppejam: for instance, if the name was "john meinel's ec2", that would be more useful12:20
* TheMue => lunch12:27
bachi jam, i have some questions about juju local's use of mongo.  do you know much about how it works?13:34
jambac: I know a bit at least13:34
jamwhat's up?13:34
adeuringrogpeppe: could please you have a look here: https://codereview.appspot.com/29680043 ?13:34
jamadeuring: I reviewed it already13:34
jamthough you're welcome to ask for another13:34
bacjam i see it creates /etc/init/juju-db-bac-blah.  is that supposed to be removed when the environment is destroyed?13:35
bacjam i ask b/c it lingered and upon reboot prevented my *real* /etc/init/mongdb.conf from launching the mongo i need for other work13:35
adeuringjam: thanks, that was fast.-- should haved looked at the page first ;)13:35
jambac: I believe so. I know axw__ has been doing some work in that area.13:35
jamadeuring: I just happened to see the email come in13:35
bacjam: if that mongo instance is ephemeral, why put entries in /etc/init?13:36
jambac: because it isn't13:36
jambac:  that is the central DB talking about all of the instances you have on your machine13:37
jamif you reboot, it is supposed to come up again13:37
bacjam, ah, ok13:37
bacjam, well it needs to play nice with real mongo13:37
bacjam, now that i understand more i can file a better bug.  thank you.13:38
jambac: so you can certainly file a bug that we shouldn't be setting something in /etc/default/mongodb. We *do* it because everywhere but local that machine isn't running a mongo otherwise13:38
jamand installing the mongodb-server automaticlaly starts an instance we won't use13:38
jamwithout that line13:38
jambac: I believe the fix is to have juju depend on a "juju-db" package which is mongo without the default instance13:38
jambac: you can poke jamespage for more details there13:38
bacjam, i don't thing /etc/default/mongodb is the problem but the /etc/init/juju-db-<user> one13:39
jambac: we write "don't start" to /etc/default/mongodb when we create ours13:39
bacjam: a good bug report is descriptive not prescriptive so i'll leave the solution to y'all.  :)13:39
bac(or so preaches bigjools)13:39
jamespagejam, bac: yeah - not done that yet13:40
jamjamespage: but you agree on the proposed "how it should be fixed" ?13:40
jam(we stop writing to /etc/default/mongodb, but depend on a different package)13:40
jamespagejam: broadley yes13:40
jamespagebinary only package +113:40
jambac: so even if we do/don't remove that file, you need to fix /etc/default/mongodb13:41
jamif you want an actual Mongo running13:41
jamthey *can* coexist, but we have the problem that on "normal" nodes we were starting 2 processes and only wanted 113:41
jambut that does impact a local test when you actually do want the other one to run13:42
bacjam, i have not /etc/default/mongodb.13:42
bacjam the problem i see is /etc/init/juju-db starts before /etc/init/mongodb and the latter sees an instance running and does nothing13:42
bacs/have not/have no13:43
jamjamespage,bac: ok, so this is slightly different. I know we do write /etc/default/mongodb but that *might* only be triggered in non-local.13:46
jamjamespage: the issue bac is pointing to is that the default /etc/init/mongodb just uses 'start-stop-daemon'13:46
jamwhich seems like it just does a ps to see if anything named "mongodb" is running13:46
jamand doesn't notice that the one that is running is using a different config13:46
jamespagehmm13:46
rogpeppebac: i'm slightly surprised that /etc/init/mongodb sees an instance running - how does it know that?13:46
jamespagethat sucks a bit13:46
bacjam, jamespage: bug 1253084 files.  please augment as needed.13:47
_mup_Bug #1253084: local use of mongo prevents default mongodb from starting <juju-core:New> <https://launchpad.net/bugs/1253084>13:47
rogpeppejamespage: ah, i see13:47
rogpeppes/jamespage/jam/ !13:47
jamrogpeppe: right "man start-stop-daemon"13:47
rogpeppejam: that sounds like definite crack to me13:47
jamrogpeppe: it works well if you have things controlled by one file and really want just one running13:47
rogpeppejam: if /etc/init/mongodb will only work properly if there's no other mongodb started anywhere, then we have a problem13:49
jamjamespage: so if we called the binary only thing /usr/bin/jujudb we would get aroud that, but I 'm not sure that is great, either13:49
jamespagejam: its fixable13:49
rogpeppewhy is /etc/init/mongodb using start-stop-daemon anyway?13:50
rogpeppeit *is* the daemon... or should be13:50
jamrogpeppe: cause its a shortcut for doing that sort of thing13:50
jamit handles the pid file, etc.13:50
jamrogpeppe: it is "/etc/init/mongodb.conf" which isn't a daemon13:50
rogpeppejam: it bypasses all the nice namespacing that upstart gives you13:51
jamrogpeppe: I can imagine it was because someone ported an /etc/init.d scripte13:51
jamscript13:51
rogpeppejam: sounds very plausible13:51
rogpeppejam: i suppose what i mean is that upstart should be the one keeping track of started processes and daemons.13:52
jamrogpeppe: sounds like, but I think jamespage would know best here13:53
jamespagerogpeppe, yup13:53
rogpeppejamespage: that /etc/init/mongodb uses start-stop-daemon seems pretty much like a straight-up bug to me13:54
jamespagethe fix is a hack - you just tell start-stop-daemon to look for a process name that will never exist13:54
jamespagerogpeppe, that is not13:54
jamespagea bug13:54
jamjamespage: that doesn't prevent it from double starting, does it?13:54
jamespageupstart manages the process via start-stop-daemon just fine13:55
jamso if you did "start mongodb; start mongodb" you'd end up with 2 of them ?13:55
jamespageall its doing is changing the uid13:55
jamespage(unlike the juju mongodb which just runs as root :-))13:55
jamespagejam: ^^ that will get picked up in the MIR work this cycle13:55
jamjamespage: k. Because juju mongodb doesn't need root (AFAICT)13:56
jamespageyup13:56
jamespageI think I raised that bug :-)13:56
jamjujud probably does13:56
jamespageagreed13:56
jamespagethat's OK tho13:56
jcastrohttp://summit.ubuntu.com/uds-1311/2013-11-20/13:57
jcastrorogpeppe, or fwereade ^^^13:58
jcastrowe have a session in 2 hours13:58
rogpeppejcastro: "juju code dev update" ?13:58
jcastroyeah basically what users can expect for 14.0413:59
rogpeppejcastro: fwereade has a better bird's eye view than me at this point14:00
jamjamespage: so there isn't a way to ask upstart to change the UID ?14:00
rogpeppejamespage: so could mongodb.conf just use sudo -u mongodb /usr/bin/mongodb ... ?14:00
jamespagerogpeppe, that is exceptionally bad as it starts a user session14:01
jamespage(try shutting down a desktop when you do that)14:01
jamrogpeppe: http://superuser.com/questions/213416/running-upstart-jobs-as-unprivileged-users14:01
jamnew versions can use "setuid"14:01
jamespagejam: there is bit globally for the configuration14:01
rogpeppejamespage: no way to avoid that?14:01
jambut maybe we need to still support P?14:01
jamespageso you can do mkdir -p /var/lib/mongodb in pre-start14:01
jam(which it does)14:02
jcastrofwereade, are you available in 2 hours?14:02
rogpeppejcastro: he wasn't too well earlier. i'm ok doing it if he can't make it.14:04
rogpeppejcastro: or perhaps jam might want to14:05
jcastroI don't care who it is as long as they can just talk about juju14:05
jcastrojam is fine! :)14:05
jamrogpeppe: jcastro: its pretty late for me14:05
fwereadejcastro, rogpeppe: well, I just crawled up to tell people I wasn't likely to come back today14:05
jcastrook14:05
rogpeppefwereade: np14:05
jcastrois there anyone available?14:05
rogpeppefwereade: could you maybe link me to our current roadmap document, if there is one?14:05
rogpeppefwereade: i'm not quite sure what's likely to get in 14.04 currently14:06
fwereaderogpeppe, I'm pulling all that back together into something resembling sanity but it's not currently a oc14:06
jamjcastro: so the ones you want someone are for 16:05 UTC and 18:05UTC, except there are 2 Juju ones at 18:05 (I guess one is GUI)14:06
fwereaderogpeppe, I will give you the overview14:06
rogpeppefwereade: thanks14:06
jamrogpeppe: there is also https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0At5cjYKYHu9odDJTenFhOGE2OE16SERZajE5XzZlRVE&usp=drive_web#gid=014:06
jamwhich isn't 100% up to date, but can give some hints14:07
jamrogpeppe: the one at 18:05 looks more like a jamespage one14:07
jam"what do we need to do to get Juju into main"14:07
jamhttp://summit.ubuntu.com/uds-1311/meeting/22112/juju-core-development-update/ looks like a summary of what is going on14:08
natefinchjam, rogpeppe, fwereade: I'm also available to go to meetings, since they're more in my time zone14:16
rogpeppejamespage, jam: ISTM that another and slightly easier fix to /etc/init/mongodb.conf would be to pass "-u mongodb" to start-stop-daemon14:28
jamespagerogpeppe, "--name mongodb-server" will also work as no process will ever be named mongodb-server14:34
jamespagewhich avoids problems if someone wants to run multiple mongod processes under the mongodb user14:34
rogpeppejamespage: it's not clear to me how --exec interacts with --name interacts with --start14:35
=== vds` is now known as vds
jcsackettsinzui, abentley: can one of you look at https://code.launchpad.net/~jcsackett/charmworld/better-sparklines/+merge/195972 when you have time?15:26
abentleyjcsackett: looking15:45
jcsackettabentley: thanks15:47
abentleyjcsackett: r=me.15:48
jcsackettabentley: thanks!15:48
rogpeppejcsackett: have you got a hangout link?16:04
rogpeppeoops16:05
rogpeppes/jsackett/jcastro/16:05
rogpeppejcastro: ^16:05
jcsackett:-P16:05
jcsacketthappens all the time. :-)16:05
rogpeppejcsackett: i can see why16:05
jcastrosec16:05
jcastrohttps://plus.google.com/hangouts/_/7ecpjmodidvjime8kk2kb7s28k?authuser=0&hl=en16:06
jcastrorogpeppe, he's the good looking one16:06
jamgood job rogpeppe16:37
rogpeppejam: thanks. did i sound reasonably coherent?16:37
jamyeah16:37
jamI felt you did well16:37
rogpeppejam: phew :-)16:38
jamespagewho from the juju-dev team is attending the Juju activities for 14.04 session starting shortly?18:04
natefinchjamespage: I can attend18:05
jamespageexcellent18:05
jamespage#ubuntu-uds-servercloud-118:05
rogpeppeg'night all19:05
natefinchnight roger19:06
sinzuinatefinch, I think Bug #1057665 is fix committed in trunk19:25
_mup_Bug #1057665: juju destroy-environment is terrifying; please provide an option to neuter it <canonical-webops> <destroy-environment> <pyjuju:Fix Committed by hazmat> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1057665>19:25
jamsinzui: it depends how you interpret that bug. I think they are actually asking for a sort of "termination protection" so that you can't just destroy-environment it19:28
jamwe do make it slightly better by requiring you to name it19:28
jamwe could spin off another bug about termination protection19:29
sinzuijam, I agree with what is being asked for, but my understanding was that we decided on an argument change19:29
sinzuijam, why are you awake?19:30
jamit isn't midnight here yet19:30
jam30 min to go19:30
sinzuinatefinch, jam, I need to decide if the bug is fix committed, or deferred to the next milestone.19:31
sinzuimoving it to the next is easy19:31
jamsinzui: I'm fine closing that one, but I'd like to capture the thought about a second command19:31
jamwhether we *do* that one we can decide later19:32
sinzuijam, do you know if Bug #1236691 is really In Progress?19:33
_mup_Bug #1236691: null provider bootstrap fails if default-series does not match target <ssh-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1236691>19:33
jamI think axw was looking at it19:33
jambut it shouldn't block the release if it doesn't land19:34
sinzuithank you19:34
jamsinzui: have a good night19:38
* jam heads to bed19:38
sinzuigoodnight19:39
natefinchsinzui: hey, I stepped out for a bit.  Sounds like you and jam figured it out, though19:42
natefinchsinzui: in my opinion, the change I made addresses the problem they stated they had.  I didn't implement their solution to the problem, but that's a different story, as jam said.  I think the feature they proposed is interesting, but problematic to implement, and therefore seems unlikely to be implemented any time soon, with the priorities and manpower we have right now.19:44
sinzuinatefinch, I agree. I prefer bugs reports to state the problem, not prescribe a solution. The later is almost always a unique feature. While the former, is easily grouped and duped to form a solution19:54
natefinchsinzui: yep, exactly19:57
thumpero/20:07
natefinchthumper: howdy20:08
thumperhey20:09
natefinchthumper: do you know if the mouse pointer will resize along with the font setting?  I haven't rebooted since I changed the font setting, so it might not have gotten applied... but that's one thing that is surprisingly annoying on the high res screen - trying to find and use a really tiny pointer.20:17
thumperIIRC the mouse pointer is special, and drawn by the graphics driver, most likely fixed size20:18
natefinchthumper: boo.  I looked for an accessibility thing for that and also failed... hoped there'd be a "bigger mouse pointer for people with bad eyesight" but no luck20:18
hazmatis there api support yet for deploy ... more specifically charm upload?21:52
hazmathmm..21:53
hazmatconn.PutCharm21:53
natefinchhazmat: https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-cli-api21:53
natefinchsays dimiter is working on deploy21:53
thumperHA!21:54
thumperI think I found the bug where the local provider doesn't start properly21:54
thumperjust encountered it.21:54
* thumper adds it to the FIX IT stack21:55
hazmatnatefinch, thanks21:55
natefinchhazmat: no problem21:56
natefinchgah... mgo refuses to dial into mongo if I pass it --replSet ... mongo sees the connection and then the connection is immediately dropped.  Sigh.  Gotta figure out what's going on in mgo.21:57
natefinch... but not today.   later all22:00
davecheneysinzui: ping22:59
davecheneyyou were going to send me details on the jenkins setup22:59
davecheney<gentle:reminder/>22:59
sinzuiyep23:31
davecheneysinzui: ta muchly23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!