[00:39] <emgent> keescook, hi
[00:40] <AussieHatter> 2 of my ubuntu servers with completely different hardware have network speed problems *slow*
[02:48] <hatter> can ipv6 enabled nics have an effect on samba within a network ?
[04:30] <ScottK> amavisd-new MIR (and the 8 dependencies) are finally done!
[04:42] <sommer> ScottK: party!
[08:07] <kiggaz> hey there everybody
[08:08] <kiggaz> I gotto question: in mysql replication, how can I ignore replication of a table in the replication db?
[08:10] <kiggaz> replicate-ignore-table=db.table3 statement in the slave mysql my.cnf doesn't help
[08:14] <kraut> moin
[09:21] <XiXaQ> can someone look at http://wiki.ubuntu.com/CalendarServer and add a way for it to start and stop with the system?
[09:24] <ewook> cron it?
[09:25] <ewook> or, simply just add it to init.d
[09:35] <soren> XiXaQ: init script?
[09:35] <XiXaQ> yes.
[09:35] <XiXaQ> I have no idea how to do that.
[09:36] <soren> XiXaQ: You can base it off of /etc/init.d/skeleton
[09:40] <XiXaQ> should it be sufficient to change the values between PATH and SCRIPTNAME, or must I do more?
[09:42] <XiXaQ> I can't read sh-script very well.
[10:21] <soren> XiXaQ: That depends on what you're trying to do.. I haven't read the wiki page.
[10:21] <XiXaQ> would you mind doing so? I think it'd be useful for many people.
[10:38] <qman> hello, I'm having some trouble with software raid...the raid works and all, no failed disks or anything, but at every reboot, it says the raid is not clean, and then gives me "could not bd_claim sde1"
[10:38] <qman> and starts rebuilding the array
[10:39] <qman> I have a 6-disk raid 5, and my dmesg output is here: http://qman.strangled.net:8080/dmesg.txt
[10:42] <ivoks> are you sure there are no failed disks?
[10:42] <ivoks> it looks to me that it's doing syncing
[10:42] <ivoks> check cat /proc/mdstat
[10:43] <qman> it says it's about 40% through a resync
[10:43] <qman> but the thing is, all the disks are new, and I just installed the system and created it
[10:43] <qman> and it does this on every reboot
[10:43] <ivoks> well, syncing does need time
[10:43] <ivoks> sometimes more than 24 hours
[10:44] <qman> hmm
[10:44] <ivoks> attach output of 'cat /proc/mdstat' somewhere
[10:44] <qman> ok
[10:46] <qman> http://paste.ubuntu-nl.org/52122/
[10:47] <ivoks> well, wait for 3 hours and it will finish
[10:47] <qman> I suppose I probably didn't let it finish building, thanks for the help
[10:47] <_ruben> qman: have you ever actually seen the raid finish building?
[10:47]  * _ruben guesses not
[10:47] <_ruben> indeed
[10:48] <qman> I just assumed that since the md process was no longer in top that it was done
[10:48] <qman> but obviously not
[10:48] <ivoks> you can use your disk
[10:48] <ivoks> but it still isn't synced on all disks
[10:48] <qman> yeah, it kept data after the reboot even
[10:48] <qman> it's mounted at /home
[10:48] <qman> so not much on it yet
[10:56] <ivoks> soren: i need your opinion
[10:56] <soren> Chocolate is good.
[10:56] <ivoks> soren: we agreed on doing MIR for drbd, but it requires kernel module
[10:57] <ivoks> there is a upstream progress on integrating drbd into vanilla kernel
[10:57] <ivoks> and, reading lklm, there are some issues which need to be resolved before merging
[10:58] <ivoks> so, i'm not quite sure it's a good idea to merge it into hardy, since there is a big chance code will have partial rewrites
[10:58] <ivoks> what do you think?
[11:03] <soren> Well, if it's being actively rejected by upstream, I'm not very keen on it.
[11:06] <ivoks> i can't say actively...
[11:06] <ivoks> http://lkml.org/lkml/2007/7/21/255
[11:06] <ivoks> but it's quite long discussion :)
[11:07] <soren> I'm on my way to (a long) lunch. We can talk later?
[11:08] <ivoks> enjoy your meal ;)
[12:47] <mok0> how come the stupid NIS slave server decides to serve it's own /etc/hosts??
[16:14] <jdstrand> mathiaz_, soren: I just migrated a gutsy server to using raid1 on /, and discovered that the server kernel's initramfs does not have raid1 included.
[16:14] <jdstrand> I had to add to /etc/initramfs-tools/modules 'md' and 'raid1'
[16:14] <jdstrand> is there a reason this isn't included?
[16:18] <mathiaz_> jdstrand: no reason... You should file a bug.
[16:18] <jdstrand> mathiaz_: will do
[16:26] <c1|freaky> hi all. does someone know of a online, web based addressbook or contact management software, preferably also with a calendar. one with a good quality?
[16:42] <jetole> hey guys, I notice ubuntu does not include apt-spy in gibbon and netselect-apt doesn't seem to work for me (complains about my firewall when I disable akk iptables rules and host is not behind router)
[16:42] <jetole> is there another package I should be aware of to help me find the fastest mirrors?
[16:43] <jetole> or... even better, I just want to simply test a host on a 100Mbps net connection, can anyone tell me anywhere where I can download a file and see close to that speed
[16:46] <_ruben> hmm .. ages ago i read about a method to install debian using a tool similar to (or possibly even using that) debootstrap .. cant seem to find it, nor any docs on an easy 'migration' from one linux distro to ubuntu
[16:47] <_ruben> ah .. found the debian docs .. lets see if i can make this work for ubuntu
[16:47] <jetole> _ruben: did you try apt-cache search debootstrap because I found it pretty quickly on 7.10 server
[16:48] <jetole> and then of coarse you just run apt-get install debootstrap
[16:48] <_ruben> jetole: well .. the goal is to migrate one of my fileservers from opensuse to ubuntu
[16:48] <jetole> might want to comment out the CD in /etc/apt/sources.list
[16:49] <jetole> _ruben: well good luck with that buddy but all IO would expect is to move the files and then see what software configuration files are still compatible, most should be
[16:49] <jetole> but don't expect it to run out of the box
[16:49] <jetole> you are trying to upgrade from one OS to another in a system that was never designed to do so
[16:50] <ScottK> Particularly from an RPM based distro to a Debian based distro.
[16:50] <_ruben> the idea is to end up with a clean ubuntu install .. without me getting out the screwdrivers and all to hook up a cdrom drive ;)
[16:50] <jetole> ubuntu uses all different package names and neither OS is aware of the other ones packages
[16:50] <_ruben> so 'upgrade' or 'migrate' is a bit of an overstatement
[16:50] <jetole> was SuSE rpm?
[16:50] <ScottK> SuSE uses rpm.
[16:51] <jetole> _ruben: if you want a clean install that would be a little more likely and easier
[16:51] <jetole> ScottK: huh, been a decade since I used it
[16:51] <jetole> didn't like it then and don't want to try it now *cough*microsoft*cough*
[16:51] <ScottK> There are scripts for booting off of a USB thumb drive out there.  You could perhaps boot Ubuntu off one of those and install from there.
[16:52]  * ScottK used opensuse, but got tired of being thought of as an SLES beta tester who had no right to expect stuff to actually work.
[16:52] <_ruben> ScottK: hmm .. hadnt thought about that one
[16:52] <jetole> "linux violates our patents, we won't tell you which ones but if you use our linux, I mean our partners linux, then we won't sue you for the patents that we won't admit exist"
[16:52] <_ruben> we actually are using SLES9 at work currently .. working on migrating to ubuntu tho ;)
[16:53] <ScottK> :-)
[16:53] <jetole> _ruben: you can install a clean system from debootstrap, I have done it but it has been a few years since so I don't remember how
[16:53] <jetole> look up a readme on it
[16:53] <jetole> a clean system from deboo strap can usually be done, although you may require a temp partition
[16:53] <jetole> or you can just install the CD Rom, that takes about 5 minutes
[16:54] <_ruben> got a nice start here: http://www.underhanded.org/papers/debian-conversion/remotedeb.html .. tho i dont think i have any spare diskspace to repartition :/
[16:54] <_ruben> jetole: the install would go fast .. that is, once i have the cd in cdrom drive in that box .. it currently doesnt have one :)
[16:55] <jetole> _ruben: right but installing a CD ROM drive has always seemed easy to me
[16:56] <jetole> then again, I am the only person I know who was building computers as an after school job when I was a freshmen in high school
[16:57] <_ruben> jetole: hehe .. the technical part aint the problem .. its the physical side of it .. its currently tucked in nicely between some other boxes with a fair share of cables hooked up and stuff like that :)
[16:59] <_ruben> huh .. since when is /dev/sda1 etc used for pata disks? just upgraded another fileserver from feisty to gutsy
[17:05] <jetole> _ruben: for a while now
[17:06] <jetole> I had a feisty box with a jmicron sata controller and HDD hooked up to both sata and pata and a sata cdrom, all disks appeared as sdX
[17:06] <_ruben> hmm .. hadnt noticed before .. then again, havent been playing with ubuntu much, yet
[17:07] <ScottK> _ruben: Since the kernel migrated to the new PATA code that's in the same module as the SATA/SCSI code.
[17:08] <ScottK> It's a general kernel change, not Ubuntu specific.
[17:08] <jetole> that sounds about right, I remember reading up on it some time ago
[17:08] <jetole> anyways, hd = sd;
[17:09] <_ruben> ScottK: figured as much .. suse being quite behind on the kernels, makes it a new feature for me on ubuntu ;)
[17:09] <jetole> what is the package I need to install to provide server kernel headers?
[17:09] <_ruben> hmm .. 50 euros for external dvd writer .. not too bad
[17:10] <_ruben> jetole: the source is the same for server and desktop
[17:10] <jetole> I never said it wasn't
[17:10] <jetole> I asked what is the package I have to install to provide server kernel headers
[17:11] <jetole> since the two use different kernels and there is a header specific package
[17:11] <_ruben> hmm .. actually .. i might be wrong
[17:11] <_ruben> indeed .. never looked at it this closely .. the source package is identical from what i gathered .. so i guess it'd be linux-headers-server
[17:11] <jetole> _ruben: I can type apt-get source <package> to install source for any package on either version of the distro
[17:12] <jetole> I am trying to install vmware-server atm and it is looking for /usr/src/linux/include
[17:13] <jetole> now I know that is the default spot for the raw kernel source headers but like I have done this a while ago and there is another package that provides this I beleive
[17:13] <jetole> unless...
[17:14]  * jetole tries sym linking /usr/include/linux to /usr/src/linux/include
[17:14] <_ruben> that usualy doesnt work .. tho that's gathered from the few times i tried to get away easily that way .. havent tried on ubuntu tho
[17:16] <_ruben> linux-headers-server it seems to be .. would require a symlink to /usr/src/linux tho .. or tell vmware to use the actual path
[17:17] <jetole> actually neither one has worked so far, I am installing linux-source atm
[17:18] <jetole> back to my initial question, does anyone in here know what tool would work well for finding the fastest mirrir to you?
[17:18] <_ruben> that was actually my first thought, since vmware probably requires more than just the headers
[17:19] <_ruben> i recall a tool from that from my own early debian days, but have no clue about the name .. for me any dutch (me being dutch) mirror gives me full speed
[17:19] <jetole> _ruben: not in this case but the kernel headers that are provided here are different then the ones it needs
[17:19] <_ruben> odd
[17:19] <jdstrand> jetole: netselect (but haven't used it on ubuntu)
[17:20] <jetole> _ruben: apt-spy worked for me in the past and ended at feisty, netselect-apt seems not to work at all with firewall issues being reported when it is not behind a firewall, iptables, or a router
[17:20] <jetole> _ruben: there are actually two sets of kernel headers but I forget the difference
[17:20] <jetole> one is used for the active kernel and one is used to compile programs against it
[17:21] <_ruben> ic
[17:29] <_ruben> hmm .. my gutsy machine just kernel panic'ed on sudo halt
[17:30] <_ruben> most of the backtrace scrolled away .. power down it is
[17:50] <XiXaQ> Where is IMAP mail stored? I've been trying to reset a users mailbox structure, but I can't find out why.
[17:50] <XiXaQ> how. :)
[17:56] <soren> XiXaQ: IMAP servers look wherever you tell them to look. IMAP doesn't dictate the structure.
[17:57] <XiXaQ> well.. I deleted the user on both the server and the client, then recreated it. Still, the folder structure is fubar
[19:05] <ScottK> lamont: Got a moment to discuss Postfix plans?
[19:05] <lamont> ScottK: if it's convenient, about 2.5 hours from now would work better.
[19:06] <ScottK> lamont: Should be fine.
[19:06] <lamont> poke me then pls
[19:06] <ScottK> lamont: Will do.
[19:07] <fishor> i working on Bug 183485 , and found it will be nice to have wiki hovto debug kvm/qemu guest. any ideas about it?
[19:07] <ubotu> Launchpad bug 183485 in linux-source-2.6.22 "kvm can not boot Ubuntu guest" [Undecided,Confirmed] https://launchpad.net/bugs/183485
[19:11] <fishor> ubuntu-bugs team think it will be better organice it with ubuntu-server
[19:13] <fishor> dendrobates: any thouts?
[19:14] <dendrobates> fishor: we do handle kvm
[19:15] <dendrobates> fishor: will it not install, or not boot after install.
[19:15] <fishor> see Bug 183485
[19:15] <ubotu> Launchpad bug 183485 in linux-source-2.6.22 "kvm can not boot Ubuntu guest" [Undecided,Confirmed] https://launchpad.net/bugs/183485
[19:16] <fishor> i mean it will be usefoul to have wike: debugging kvm/qemu guest
[19:17] <fishor> dendrobates: wiki..
[19:19] <soren> fishor: It's not much different than debugging a real machine. Do you think so?
[19:21] <fishor> olmost... jast explaine: "kvm -serial file:debug.log" and in grub "earlycon=ttyS0 console=ttyS0" and any other usefoul info if guest can't start
[19:22] <fishor> espessially for kvm. kvm on intel will give mach more not complete reports
[19:22] <soren> I usually don't find that any easier than just using the console that kvm usually pops up.
[19:24] <soren> fishor: Feel free to start a wiki page though. If you find it useful, there's a good chance someone else will, too.
[19:26] <fishor> ok. i'll try
[20:29] <ScottK> Server team meeting is in ~30 minutes, right?
[20:29] <soren> That's the idea, yes.
[20:29] <ScottK> It doesn't appear to be on the schedule for #ubuntu-meeting.
[20:30] <ScottK> Nothing conflicts, so I guess we can just be squatters, but thought I'd mention it.
[20:33] <soren> I think mathiaz has already told the relevant people to update the schedule?
[20:44] <mathiaz> ScottK, soren: I've sent an email to fridge-devel about the new schedule
[20:45] <ScottK> OK.  I just wanted to make sure we could have a peaceful meeting in ~15 minutes or so...
[20:46] <soren> ScottK: Oh, sure. We sorted out any conflicts before we proposed the new time.
[20:46] <fishor> soren: please can ypu check it, https://wiki.ubuntu.com/DebuggingKVM
[20:46] <ScottK> Glad to hear it.
[20:47] <fishor> soren:  any other suggestions ?
[20:47] <soren> fishor: About what?
[20:48] <fishor> any other info, we need from user with crashed gust or kvm host
[20:49] <soren> Than what? I don't know what you have now?
[20:52] <fishor> i initiated wiki about debugging KVM/qemu guest or host
[20:53] <soren> Where?
[20:53] <fishor> wee tolked  about this to   for 1 hour .. https://wiki.ubuntu.com/DebuggingKVM
[20:54] <InSearchOf> PING: Question for anyone working for Canonical (ubuntu) on the server team...
[20:57] <InSearchOf> Is the position for the Server Dev still open?
[20:58] <somerville32> InSearchOf, I believe so, yes.
[20:58] <InSearchOf> somerville32, Alright, thanks!
[20:59] <zul> why not send your resume and see?
[21:00] <ScottK> somerville32: You don't work for Canonical do you?
[21:00] <somerville32> ScottK, unfortunately not
[21:01] <somerville32> ScottK, you're welcome to recommend me for employment though :]
[21:02] <ScottK> somerville32: He specifically asked the question to someone working for Canonical.  That's why I mention it.
[21:05] <nealmcb> ToyKeeper: #ubuntu-meeting....
[21:39] <ScottK> lamont: Ping
[21:39] <lamont> ackage
[21:40] <ScottK> I sent you a patch in Debian BTS today.
[21:40] <ScottK> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345047
[21:40] <ubotu> Debian bug 345047 in postfix "Please add [::1]/128 to the Default mynetworks setting" [Normal,Open]
[21:40] <ScottK> I was thinking about how to handle the Postfix 2.4/5 transition in Ubuntu and I have a proposal for you.
[21:41] <ScottK> On postfix-users, Weitse said today that he's going to release another update to 2.4 right after he releases 2.5.
[21:41] <lamont> ok
[21:41] <ScottK> I was thinking it would be nice to get that last 2.4 bugfix uploaded to Hardy (either directly or via Debian) and then backported to Dapper/Edgy/Feisty/Gutsy and then we upgrade Hardy to 2.5
[21:42] <ScottK> So that the 2.4 backports are as bug fixed as we can get them.
[21:43] <ScottK> Also, about the patch, I think Hardy is going to be around long enough that it'd be really good if it assumed IPv6 exists.
[21:43] <ScottK> I tested that on my test server and I think there's no performance downside to it.
[21:43] <ScottK> What do you think?
[21:43] <lamont> I like that idea
[21:44] <lamont> in the case where v6 doesn't exist (which means you can't install in debian-installer yet...), it already strips v6 - we _should_ make sure that it installs on a machine with no v6
[21:44] <lamont> and yet assuming that v6 is there when it is is certainly the way to go
[21:44] <mitchp> is 8.04 going to be LTS?  I had heard that, but I wasn't sure what the schedule was
[21:45] <ScottK> Yes.  It's planned for LTS
[21:45] <lamont> 8.04 is LTS for ubuntu et al
[21:45] <mitchp> ok that's what i was told, thanks
[21:45] <lamont> kubuntu is planning to not do LTS with 8.04
[21:45]  * ScottK grumbles.
[21:45] <mitchp> kubuntu is jerks
[21:46] <ScottK> lamont: My Ubuntu boxen have IPv6 enabled, but no IPv6 connectivity.  Having the added values in mynetworks seems to cause no hard in that case.
[21:46] <ScottK> mitchp: Please don't make me argue with you.  I'm a Kubuntu developer too.
[21:46] <mitchp> lol sry
[21:46] <ScottK> No problem.
[21:47] <lamont> ScottK: mv ipv6.ko out of lib/modules/$(uname -r) for the acid test
[21:47] <ScottK> OK.  I'll do that.
[21:47] <ScottK> This would be why I have a test server, right?
[21:48] <lamont> and you'll need to reboot...
[21:48] <ScottK> Yah.
[21:48] <ScottK> Only 15 sets of modules on that machine ...
[21:50] <ScottK> Rebooting.
[21:55] <InSearchOf> zul,  I did... a week or so back :-)
[21:59] <ScottK> lamont: If there's a difference it's in milliseconds.
[21:59] <lamont> ScottK: it was more a question of 'does it bitch' :-
[21:59] <lamont> ifconfig or ip addr show lists no v6 addrs?
[21:59]  * ScottK looks
[22:00] <ScottK> lamont: ifconfig shows no ipv6 addresses
[22:00] <lamont> woot!
[22:01]  * ScottK puts the kernel module back now...
[22:01] <ScottK> lamont: Anything else before I reboot again?
[22:01] <lamont> I'll get the change tested again today/tomorrow (I'm assuming we want this in 2.5 certainly, what about 2.4)?
[22:02] <ScottK> I think it matters most for 2.5.
[22:02] <ScottK> Up to you where you drop it in.
[22:02] <lamont> given that we want to backport 2.4 to warty-1, I'm inclined to make the change start with 2.5....
[22:02] <ScottK> From an Ubuntu perspective and future 2.4 work would be very unlikely to see this code in a new install.
[22:03] <ScottK> Dapper actually, but yes.
[22:03] <ScottK> Agreed.
[22:03]  * ScottK reboots again.
[22:04] <ScottK> lamont: Did you see my core-dev application?
[22:04] <lamont> saw the mail, haven't actually gotten that deep in my mailbox today (or was it yesterday...)
[22:04] <ScottK> Please send a nice vote of confidence real soon....
[22:04] <ScottK> It was yesterday.
[22:05] <lamont> will do today.
[22:05] <ScottK> Just think, if I'm approved, I won't need to bug you for the source backport for Dapper
[22:05] <ScottK> Thanks.
[22:05]  * lamont needs to run into town and do a couple things, then will be working through the email glut
[22:06] <ScottK> See you later.
[22:21] <ScottK> lamont: After rebooting, I confirmed that ifconfig does in fact show an IPv6 loopback, so that we for sure had no IPv6 when it said we had no IPv6.
[22:52] <nealmcb> !ebox
[22:52] <ubotu> ebox is a web-based GUI interface for administering a server. It is designed to work with Ubuntu/Debian style configuration management. See the plans for Hardy at https://wiki.ubuntu.com/EboxSpec
[22:52] <nealmcb> !webmin
[22:52] <ubotu> webmin is no longer supported in Debian and Ubuntu. It is not compatible with the way that Ubuntu packages handle configuration files, and is likely to cause unexpected issues with your system. See !ebox instead.
[22:52] <nealmcb> :-)
[23:45] <Nafallo> any issues moving from feisty to gutsy?


[01:14] <davecheney> thumper: ok
[01:14] <davecheney> thumper: FWIW, i think any of theproposed solutions will solve the issue at hand
[01:15] <davecheney> i think there is pleanty of scope for a morally correct fix once 1.14.0 is out
[02:36] <arosales> thumper, happy birthday
[02:36] <thumper> arosales: thanks, but it is tomorrow here :)
[02:36] <arosales> it still today here
[02:36] <arosales> and possibly yesterday somewhere else
[02:37] <arosales> thumper, happy belated birthday ;-)
[02:38] <thumper> :-) thanks
[03:45]  * thumper pulls a sad face
[03:52] <axw> thumper: what's making you sad?
[03:52] <thumper> I was adding an apiserver endpoint
[03:52] <thumper> and instead of using a pointer to a struct
[03:52] <thumper> I wanted to use an interface
[03:52] <thumper> everything worked well
[03:52] <thumper> until you called it
[03:52] <thumper> caused a panic in the reflect library
[03:53] <thumper> had to change it to a struct pointer
[03:53] <thumper> because I didn't want to fix our rpc code
[03:53] <thumper> somewhat out of scope for this change
[03:54] <thumper> axw, wallyworld: I completely missed the reminder about package review
[03:55] <axw> oh yeah
[03:55] <axw> me too :)
[03:56] <axw> nobody's selected anything to review either have they?
[04:01] <thumper> not that I know of
[04:02] <wallyworld> thumper: me too
[04:02] <wallyworld> i've been too busy to notice
[04:02] <wallyworld> next week :-)
[04:05] <axw> thumper: has mramm approved your travel? just wondering if my travel request has shown up at all
[04:06] <thumper> yes he has
[04:06] <thumper> but I've not booked it yet
[04:06] <thumper> should get on it
[04:06] <thumper> axw: poke him ovre email
[04:06] <axw> will do, thanks
[04:49] <davecheney> what are the dates again ?
[04:49] <axw> 21-25 I think
[04:52] <davecheney> ta
[05:13] <thumper> gah
[05:13]  * thumper emails travel people
[05:15] <axw> thumper: I'm going to work on bugs, unless you've got something else you'd rather I do?
[05:16] <thumper> you could add the "SupportsContainers" method to the Environment
[05:16] <thumper> it is pretty trivial
[05:16] <thumper> but then we need the add-machine code to use it
[05:16] <thumper> also container constraints
[05:16]  * thumper is polishing a pipeline of work
[05:16] <axw> container constraints? or environment constraints?
[05:17]  * axw hasn't heard of container constraints before
[05:17] <thumper> well, there is a constraint for putting something in a continer
[05:17]  * thumper thinks
[05:17] <thumper> so a machine constraint
[05:17]  * thumper is trying to work out why the tests blew up
[05:17] <axw> ok
[05:19] <thumper> jam: you around?
[05:24] <thumper> at least it looks like changes I added, so shouldn't be too hard to work out
[05:24] <thumper> jam: https://codereview.appspot.com/13421043/ (not sure why it is a closed issue, because it hasn't landed)
[05:25] <thumper> jam: it is a branch the rest of my stuff depends on
[05:25]  * thumper EODs to make dinner
[05:44] <davecheney> jam: is there a bug for the mgo revert ?
[05:44] <davecheney> i need to add it to the build tagball scripts
[05:44] <jam> davecheney: bug #1221705
[05:44] <_mup_> Bug #1221705: relationunit_test.go: 2 tests fail with mgo >= 241 <juju-core:Fix Released> <mgo:Confirmed> <https://launchpad.net/bugs/1221705>
[05:45] <jam> "Fix Released" in that juju-core has worked around the test suite failing.
[05:45] <davecheney> ta
[05:50] <davecheney> https://codereview.appspot.com/13515045
[05:52] <jam> davecheney: approved
[05:53] <jam> davecheney: I *think* that for 1.15 we'll want to go back to tip, and sort out the problems, but it is prudent to use rev240 for 1.14
[05:56] <davecheney> jam: so, to confirm, you do _not_ want this commited to trunk ?
[05:57] <jam> davecheney: I think we want it committed to trunk until the point that we move the rev of mgo on the bot.
[05:57] <jam> I'd like to say otherwise
[05:57] <jam> but it isn't reasonable to release a version we haven't been testing
[05:58] <davecheney> i think we're about 18 months too late to add that kind of hurdle
[06:01] <davecheney> jam: ignore my previously comment
[06:01] <davecheney> i parsed it incorrectly
[06:29] <davecheney> jam: https://code.launchpad.net/~dave-cheney/juju-core/backport-r1782/+merge/184938
[06:39] <jam> davecheney: approved
[06:44] <davecheney> ta'
[07:32] <rogpeppe1> mornin' all
[07:38] <rogpeppe> this looks very cool indeed; i haven't tried it yet though. https://docs.google.com/document/d/1WmMHBUjQiuy15JfEnT8YBROQmEv-7K6bV-Y_K53oi5Y/edit#
[07:39] <rogpeppe> i've been waiting for something like this ever since oakland, when the author mentioned something about it to me
[07:41] <axw> rogpeppe: it does look pretty cool.
[07:41] <axw> oakland? I thought adonovan was in NY
[07:42] <rogpeppe> axw: he was around in sf for the golang meetup
[07:42] <axw> ah
[07:44] <rogpeppe> a probably dubious thought - i wonder if you could use this instead of explicit tests for some hard-to-test functionality.
[07:52]  * axw waits for someone to write a web UI for it
[07:53] <axw> won't be long now
[08:14] <evilnickveitch> bigjools, you still awake?
[08:18] <TheMue> evilnickveitch: seen my hint regarding the docs change for the local provider?
[08:19] <evilnickveitch> TheMue, hi, yes indeed, sorry it has taken a while to get around to it but have been kept rather busy by the site redesign!
[08:19] <evilnickveitch> There are still a few things queued up
[08:20] <TheMue> evilnickveitch: ah, ok. but i'm happy if it is in this queue too. ;)
[08:20] <bigjools> evilnickveitch: I was eating dinner
[08:20] <evilnickveitch> bigjools, at this time in the morning?
[08:21] <TheMue> rogpeppe, axw, dimitern: who would like to review https://codereview.appspot.com/13522043
[08:21] <dimitern> TheMue: it seems you already have an lgtm on it
[08:22] <axw> I can look, but yeah, you only need 1 LGTM now
[08:23] <TheMue> i know, but still feling better with two :D
[08:23] <TheMue> but it's ok so too
[08:34] <fwereade_> evilnickveitch, so, I'm sorry, I got very behind on the actual changes, and my docs are conflicty as anything
[08:34] <fwereade_> evilnickveitch, can you briefly run down what's changed so I can most simply eliminate the structural changes and focus on the actual doc changes?
[08:35] <fwereade_> evilnickveitch, eg, is there some way I can just blat a matching pre/postamble onto the pages I've written and go from there? there didn't seem to be an obvious way to do that
[08:36] <jam> fwereade_: one of the big problems with pure html. no #include directive :)
[08:36] <fwereade_> jam, quite so
[08:37] <fwereade_> (grumble grumble generate from simple source format grumble)
[08:37] <evilnickveitch> fwereade_, don't worry about that, i will fix up the styles - the redesign changed a lot of stuff
[08:37] <jam> fwereade_: it was one of the things I never quite understood how to fix. You end up having to do "dynamic" content just to get consistent headers and footers.
[08:37] <fwereade_> evilnickveitch, well, OK, I just WIPped the branch, but there should be some useful content in there
[08:37] <evilnickveitch> jam, there is! Sort of - you can use the <embed> tag, but it screws up the css
[08:38] <axw> TheMue: reviewed
[08:38] <evilnickveitch> fwereade_, that's fine. There will be a new tool to generate a new page. soon :)
[08:38] <fwereade_> evilnickveitch, it's https://code.launchpad.net/~fwereade/juju-core/docs-splurge/+merge/184833 -- can I leave it in your hands to either fix it up or tell me what I have to do to help you?
[08:39] <evilnickveitch> fwereade_, yup, I already saw it. Just fixing some design tweaks and then I will look over it properly
[08:39] <fwereade_> evilnickveitch, <3
[08:39] <TheMue> axw: thx
[08:41] <fwereade_> evilnickveitch, I sort of feel that there are probably other underdocumented bits that I might be in a position to help with
[08:42] <fwereade_> evilnickveitch, is there anywhere you can think of where I should look in particular?
[08:42] <evilnickveitch> fwereade_, there is still the outstanding task list
[08:43] <evilnickveitch> hang on, i'll get you the link
[08:44] <evilnickveitch> fwereade_,  here:https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AluxMMubLozZdEVhald5bFN0U3RFbjdqNW96RWx5Snc#gid=0
[08:44] <evilnickveitch> feel free to add anything :)
[08:44] <fwereade_> evilnickveitch, found it, thanks
[08:44] <fwereade_> evilnickveitch, just looking at m_3's interfaces stuff, seeing how badly I collided with him
[08:45] <evilnickveitch> fwereade_, it's okay, i will make sense of it all. It is easier for me to edit things together.
[08:46]  * TheMue seems to have problems with the compatibility - so many typos *sigh*
[08:47] <axw> TheMue: I think it's not so bad when all a review turns up is typos :)
[08:47] <axw> ... in comments anyway!
[08:48] <fwereade_> evilnickveitch, fwiw I think m_3's interfaces stuff is missing some subtleties -- he seems to be depending on relation-get in a -joined hook, and that's unwise (if perhaps somewhat instructive)
[08:48] <fwereade_> evilnickveitch, I'm afraid I haven't done a broad pass over the docs to see what recommends things contradicted elsewhere :(
[08:48] <TheMue> axw: yeah. but already dimitern found several misspellings of this word before. it seems it has burned in my brain in a wrong way.
[08:49] <axw> heh :)
[08:50] <evilnickveitch> fwereade_, okay, I will watch out for that. Maybe the best thing is for me to take a pass over it all and then let you look over the results? It would be very helpful.
[08:51] <axw> what's the policy for US/UK spelling in Ubuntu technical docs?
[08:51] <fwereade_> evilnickveitch, absolutely, no problem
[08:51] <evilnickveitch> fwereade_, thanks!
[09:00] <rogpeppe> fwereade_: any chance of a quick chat about https://codereview.appspot.com/13640043/ ?
[09:00] <fwereade_> rogpeppe, sure
[09:00] <rogpeppe> fwereade_: https://plus.google.com/hangouts/_/fe0782db82ad005f124b51fd3035bf811cb05e5d?authuser=1
[09:26] <jam> wallyworld: poke if you're around
[09:27] <dimitern> fwereade_: ping
[09:28] <fwereade_> dimitern, pon
[09:29] <dimitern> fwereade_: in worker/uniter/context_test.go there's a test called TestUnitCaching() which relies on PrivateAddress and PublicAddress being on the unit doc (like Life) and basically test what TestRefresh does
[09:30] <dimitern> fwereade_: but once we switch to the API context.unit.PrivateAddress() will always return the up-to-date value, so there's no caching - i'm thinking of dropping that test altogether
[09:30] <dimitern> fwereade_: unless you think that caching has some significance
[09:31] <fwereade_> dimitern, ehh, that's interesting
[09:31] <fwereade_> dimitern, take a quick look at uniter/context.go
[09:32] <fwereade_> dimitern, it feels like it would in general be goofd to maintain the usual guarantees
[09:32] <fwereade_> dimitern, that values from hook tools will not change over the course of a hook
[09:32] <dimitern> fwereade_: how can I do that with the API?
[09:32] <fwereade_> dimitern, in which case, lazily getting the value when requested and caching it for the lifetime of the context does sound smart
[09:33] <fwereade_> dimitern, just how it does for config settings, relation settings, whatever
[09:33] <dimitern> fwereade_: you mean each value is read only once?
[09:33] <dimitern> fwereade_: from the api, and cached
[09:33] <fwereade_> dimitern, get if missing, otherwise use cache, make sure cache is invalidated properly
[09:33] <fwereade_> dimitern, but do this at context granularilty
[09:34] <fwereade_> dimitern, so we get it once per RunHook
[09:34] <dimitern> fwereade_: when should cache invalidation happen?
[09:34] <fwereade_> dimitern, it may be that the precise test you're worried about is actually orthogonal
[09:35] <fwereade_> dimitern, for private/public address, it should be trivial, in that it happens automatically when the context is trashed at the end of the hook run
[09:35] <dimitern> fwereade_: so at RunHook invalidate the cache?
[09:35] <fwereade_> dimitern, the cache is the context
[09:35] <fwereade_> dimitern, the context is created in runHook
[09:35] <fwereade_> dimitern, isn't it?
[09:35] <dimitern> fwereade_: yeah, seems so
[09:35] <fwereade_> dimitern, look what we do for service config settings
[09:35] <fwereade_> dimitern, should be analogous
[09:35] <dimitern> fwereade_: right, thanks
[09:41] <jam> wallyworld: bug #1223752
[09:41] <_mup_> Bug #1223752: environs/simplestreams/simplestreams.go leaks test:// and file:// URLs into the http.DefaultClient <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1223752>
[09:42] <jam> fwereade_: I'm starting to actually like the idea of an "httpps://" protocol that gets registered with the default http.DefaultTransport.
[09:43] <jam> fwereade_: or even be verbose about "insecure-https://" or something like that.
[09:43] <jam> nonvalidating-https:// is a bit long
[09:44] <jam> It has the very nice property that all clients get access to it.
[09:44] <jam> And it allows all other https:// requests to still be validated.
[09:44] <jam> I came across it because of bug #1223752
[09:44] <_mup_> Bug #1223752: environs/simplestreams/simplestreams.go leaks test:// and file:// URLs into the http.DefaultClient <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1223752>
[09:44] <jam> which is exposing test URLs to the DefaultClient accidentally.
[09:47] <jam> It has the downside that mutating DefaultTransport can't actually be undone
[09:47] <jam> (There is RegisterProtocol but I don't see an UnregisterProtocol)
[10:14] <wallyworld> jam: i just got back from a school debate. oh the joy
[10:18] <wallyworld> file:// is intended to be registered since image metadata and tools urls can use that and httpClient.Get() works just fine with file:// so long as it is registered
[10:19] <jam> wallyworld: except you end up globally registering it which means net/http.Get() will also grab file:// urls
[10:19] <wallyworld> sure
[10:19] <wallyworld> is that an issue?
[10:20] <wallyworld> simplestreams uses net/http.Get() from memory, not sure, will have to check the code
[10:20] <wallyworld> the tools-url can be either file:// or http://
[10:21] <wallyworld> so both need to be registered/supported
[10:21] <jam> wallyworld: you have "environs/simplestreams/simplestreams.go" which has its own "httpClient" variable
[10:21] <jam> it seems like you were trying to isolate it for some reason
[10:21] <jam> but then you pass the DefaultTransport to that object
[10:21] <jam> and then register the "file" protocol with the client.Transport
[10:21] <fwereade_> jam, sorry, was meeting, reading scrollback
[10:21] <jam> which... .is the DefaultTransport
[10:22] <jam> wallyworld: so the code *looks* like you were taking pains to not expose this protocol
[10:22] <jam> but ended up using the global objects anyway
[10:22] <fwereade_> jam, I think I may be coming round to that idea
[10:23] <dimitern> small review anyone? https://codereview.appspot.com/13490045/
[10:23] <wallyworld> there was some issue with lack of ability to override some aspect of constructing an gttp client, i can't recall now. but the stdlib was limited somehow. i'd have tp re-read the code
[10:24] <jam> wallyworld: so there is a problem that there is no way to "Unregister" a protocol
[10:24] <wallyworld> yes, that is sad
[10:24] <jam> so you can't just set one up for a test suite and then tear it down
[10:24] <wallyworld> yep :-(
[10:24] <jam> which means you end up needing to shim it in there if you want proper cleanup
[10:25] <jam> like by having your own Transport and its associated registry of protocols
[10:25] <jam> which then means you need a custom Client to point at that Transport
[10:25] <wallyworld> not sure why they designed it like that
[10:25] <jam> you did the custom Client, but not the Transport
[10:25] <fwereade_> dimitern, on it
[10:25] <wallyworld> there may have been a reason, i'd have to re-look
[10:25] <wallyworld> i seem to recall something but can't remember now
[10:26] <jam> wallyworld: on the flip-side, I may be (ab)using the DefaultTransport as well, to allow us to register "nonvalidating-https://"
[10:26] <jam> to allow some URLs to be insecure.
[10:26] <wallyworld> ok
[10:26] <dimitern> fwereade_: thanks
[10:26] <jam> It has the *really* nice property that only some URLs end up insecure
[10:26] <jam> instead of pretty much everything.
[10:27] <jam> and allows us to support it, without having to rewrite every possible http client that might want access to these things.
[10:28] <fwereade_> dimitern, reviewed with questions
[10:29] <dimitern> fwereade_: cheers
[10:29] <dimitern> fwereade_: yes, it does impact tags - they're constructed by transforming the key
[10:30] <fwereade_> dimitern, ok, are there any necessary changes to tag validation functions and the like? assumptions that there's a # in there or something?
[10:30] <dimitern> fwereade_: and i cannot remember whether there were numbers in relation names, but it doesn't hurt to have them imo
[10:30] <dimitern> fwereade_: I made all the changes I think
[10:31] <dimitern> fwereade_: there was # in there originally, now it's optional for peer rels
[10:31] <fwereade_> dimitern, I didn't see any tests for the tag behaviour is all
[10:32] <dimitern> fwereade_: i'm sorry I don't seem to get you, expand please
[10:32] <fwereade_> dimitern, the set of valid relation tags has now changed too, right? and all the changes and tests are purely in terms of name
[10:33] <dimitern> fwereade_: take a closer look at the test - it's both about names and tag formats
[10:35] <fwereade_> dimitern, TestRelationKeyFormats? you'll have to enlighten me
[10:35] <fwereade_> dimitern, fwiw its test numbering is screwy
[10:35] <dimitern> fwereade_: so, like the unit name formats tests
[10:35] <fwereade_> dimitern, (i * len(js))+j, surely?
[10:36] <dimitern> fwereade_: this one combines valid and invalid relation names and valid and invalid service names to form a key and test its validity
[10:36] <dimitern> fwereade_: oh, that's right :) will fix it
[10:37] <dimitern> fwereade_: tag formats are tests in tag_test.go
[10:37] <dimitern> fwereade_: I'll add a peer relation tag there as well, good point
[10:37] <fwereade_> dimitern, yeah, that's all I think
[10:38] <jam> fwereade_: so it isn't "just" that simple. The URLs we use for queries in Openstack are read back from keystone as part of the Authentication process. So goose would still need to know that "for the URLs you get back on this connection, rewrite them to "nonvalidating-https""
[10:40] <fwereade_> jam, sure, understood, I wasn't imagining it was a fix for the whole problem, but the need for nonvalidating-https crosses several boundaries, right?
[10:41] <jam> fwereade_: so before Ian's simplestreams work, we only really accessed HTTP behind the Provider interface. Now we do some bits directly. I'm trying to figure out if registering the new protocol, and then teaching goose to use it is easier/better than just teaching simplestreams at the low level about it.
[10:41] <jam> the *nice* bit is that if we have it registered
[10:41] <jam> then goose can say "the public-bucket URL is actually: nonvalidating-https://"
[10:43] <fwereade_> jam, yeah, the big problem is that it cuts across whole projects
[10:43] <fwereade_> jam, and so it's not quite clear where to put it except in its own project
[10:44] <fwereade_> jam, which feels mildly nasty
[10:44] <jam> fwereade_: right
[10:44] <jam> and then goose imports it, and juju-core imports it, etc
[10:44] <jam> and it is already registered so both just use it
[10:44] <jam> standup time: https://plus.google.com/hangouts/_/fe0782db82ad005f124b51fd3035bf811cb05e5d
[10:45] <jam> mgz fwereade_ dimitern TheMue wallyworld natefinch ^^
[10:45] <fwereade_> btw, guys, I'm not even going to try the standup today, drilling has just started and it will be unpleasant for all concerned
[10:46] <dimitern> fwereade_: updated https://codereview.appspot.com/13490045/
[10:46] <fwereade_> I will be here on irc though
[10:46] <fwereade_> and will hopefully be signing an actual contract tonight, soon after which I will be out of this building site
[10:47] <dimitern> fwereade_: \o/
[10:47] <jam> fwereade_: np, what have you actually gotten done today?
[10:48] <jam> mgz: ^^
[10:48] <mgz> ta
[10:48] <jam> rogpeppe: standup? ^
[10:48] <fwereade_> jam, nothing apart from talking to people I'm afraid, and I have emails to write for much of the afternoon
[11:03] <dimitern> fwereade_: ping
[11:04] <davechen1y> fwereade_: welcome to my world
[11:08] <wallyworld> fwereade_: since you're ocr, if you have time, there's a couple of merge proposals which are lonely and need some lovin' , see +activereviews
[11:49] <fwereade_> dimitern, sorry, went for lunch, couldn't stand it
[11:49] <fwereade_> wallyworld, ack
[11:49] <wallyworld> thanks :-)
[11:53] <rogpeppe> lunch
[11:58] <dimitern> fwereade_: np, have a look when you can https://codereview.appspot.com/13490045/
[11:59] <fwereade_> dimitern, that LGTM, thanks
[11:59] <dimitern> fwereade_: cheers
[12:06] <jam> natefinch: https://code.launchpad.net/~natefinch/juju-core/008-windows/+merge/181916 It looks like you tried to land it, but had a file conflict.
[12:06] <jam> Can you look at it again?
[12:06] <jam> I thought we actually wanted that to land for 1.14
[12:12] <natefinch> jam: ahh, thanks, I missed the fact that it didn't actually land
[12:50] <rogpeppe> fwereade_: slight hitch with the plan to introspect directly what workers are being run by the machine agent
[12:51] <fwereade_> rogpeppe, oh yes
[12:51] <rogpeppe> fwereade_: it's not easy to tell which worker is actually being run
[12:51] <rogpeppe> fwereade_: i'd thought we could do it by looking at the type of the worker
[12:51] <rogpeppe> fwereade_: but several workers share the same type
[12:52] <rogpeppe> fwereade_: i could just look at the runner worker id, but that doesn't actually tell us if we're actually running the correct worker
[12:53] <rogpeppe> fwereade_: i suppose i could mock out all the worker New functions
[12:55] <rogpeppe> fwereade_: for the specific case of the api server, this isn't an issue because the worker is of type *apiserver.Server, but i'd really hoped to use the same test style for the existing tests too (and hopefully be able to reenable some of the flaky ones too)
[12:56] <fwereade_> rogpeppe, yeah, indeed
[12:57] <fwereade_> rogpeppe, patching new-worker funcs sounds somewhat interesting me, because it's most in line with what stm to be a sensible end state
[12:57] <rogpeppe> fwereade_: in the end, even if i mock out the worker New* functions, i'm still not convinced that we get sufficient test coverage though
[12:57] <fwereade_> rogpeppe, but the variety of such funcs is in itself somewhat flaky
[12:58] <rogpeppe> fwereade_: you think all workers should be able to start with no input except the state?
[12:59] <fwereade_> rogpeppe, and probably the agent conf
[13:00] <fwereade_> rogpeppe, because that's got DataDir from which all good things flow, not to mention the actual tag etc
[13:00] <fwereade_> rogpeppe, however, I'm concerned it's too much of a leap from where we are to get done any time soon
[13:00] <rogpeppe> fwereade_: i'm not sure. i like seeing exactly what a worker needs, rather than just passing everything in.
[13:02] <rogpeppe> fwereade_: yeah, i think agree it may be too big a leap
[13:02] <rogpeppe> fwereade_: for example, the current machine id isn't in the agent conf
[13:02] <rogpeppe> fwereade_: but we need to pass it to provisioner.NewProvisioner
[13:04]  * fwereade_ raises an eyebrow...
[13:04] <fwereade_> rogpeppe, the id is needed to create the conf in the first place
[13:04] <fwereade_> rogpeppe, even if there is not currently a Tag method on conf I don't see it as forbidden knowledge in that context
[13:05] <rogpeppe> fwereade_: hmm, yes, we can infer it from the data dir, i guess
[13:05] <rogpeppe> fwereade_: or APIInfo.Tag
[13:06] <fwereade_> rogpeppe, anyway, not one for today, but I think thumper has also had thoughts in that direction
[13:08] <rogpeppe> fwereade_: even if we mock out the worker New functions, i'm not sure that it's totally convincing that they're being used in the right way inside the guts of the machiner.
[13:09] <fwereade_> rogpeppe, surely you get to see exactly what gets started, and when they each get stopped
[13:10] <rogpeppe> fwereade_: you get to see that they're started, but you don't necessarily know if they're actually wired up correctly
[13:10] <fwereade_> rogpeppe, by triggering various errors from inside and out
[13:10] <fwereade_> rogpeppe, if you've mocker out the new worker funcs, you can check the args and know what was created surely
[13:11] <fwereade_> rogpeppe, the wiring of those args within the real workers will be tested in the worker-specific tests
[13:11] <rogpeppe> fwereade_: that joined-upness is something that could easily come apart AFAICS
[13:13] <rogpeppe> fwereade_: in the end, i think we really do want some integration tests here, even if we do some other checks too.
[13:13] <fwereade_> rogpeppe, function signature changes are generally spotted when things fail to compile
[13:13] <rogpeppe> fwereade_: i wasn't thinking of sig changes, but semantic changes
[13:14] <rogpeppe> fwereade_: in the end, we really do want to check that there's actually a given worker running that actually does the right stuff.
[13:14] <fwereade_> rogpeppe, hence my preference for configuring workers with a conf and a state directly
[13:14] <fwereade_> rogpeppe, well
[13:14] <fwereade_> rogpeppe, no
[13:15] <fwereade_> rogpeppe, we actually don't, quite often
[13:15] <fwereade_> rogpeppe, we want to check, like, *one* -- the simplest one with the fewest and fewest-reaching bizarre side effects
[13:16] <fwereade_> rogpeppe, each of the workers must indeed be independently tested
[13:16]  * rogpeppe tries to convince himself that that's sufficient
[13:17] <fwereade_> rogpeppe, and the mechanism for creating workers must itself also be tested
[13:17] <fwereade_> rogpeppe, there are more things in play, and they require more testing, but each of the mechanisms can be tested in isolation
[13:18] <fwereade_> rogpeppe, rather than carrying all the context for the N other attached mechanisms every time you want to test just one feature
[13:19] <rogpeppe> fwereade_: the difficulty i have is that working out whether this actually tests that it works is a bit like working out whether two halves of an inductive proof meet in the middle
[13:20] <rogpeppe> fwereade_: it's easy to *think* you're testing that the whole thing works, but actually you're not testing what you think. end-to-end tests avoid that issue.
[13:20] <rogpeppe> fwereade_: although i totally agree they're heavyweight
[13:21] <fwereade_> rogpeppe, but the bigger the test, the flakier, and the harder to fix, and the harder-still to fix correctly
[13:21] <fwereade_> rogpeppe, a few big tests are a necessary evil
[13:22] <fwereade_> rogpeppe, and a lot of small tests are a necessary good ;p
[13:23] <rogpeppe> fwereade_: the other p.o.v. is that we end up with tests so reliant on internal implementation details that we can't change things without rewriting the tests, which loses one big point of having the tests in the first place.
[13:24] <fwereade_> rogpeppe, lots of packages with a few small types each usually only come about when you've actually figured out the separation of responsibilities in the system pretty well
[13:25] <fwereade_> rogpeppe, yes, you're still vulnerable to semantic changes; the big tests *are* a necessary evil
[13:26] <fwereade_> rogpeppe, but if you can't write the small tests, your system is likely to be suboptimally factored ;)
[14:45] <m_3> fwereade_: hey, just read backchannel and had to do a double-take
[14:45] <fwereade_> m_3, the relation-get thing?
[14:46] <m_3> fwereade_: yeah, that needs to be cleared up
[14:46] <fwereade_> m_3, I maintain that it cannot be relied upon in -joined
[14:46] <m_3> fwereade_: it's just getting the service name
[14:47] <m_3> so it's more pseudo-code at that point in the docs
[14:47] <fwereade_> m_3, ah!
[14:47] <m_3> but needs to be rewritten to make that clear
[14:47] <fwereade_> m_3, ok, I am an idiot, I misunderstood completely
[14:47] <fwereade_> m_3, I thought it was getting an actual relation setting
[14:47] <m_3> i.e., "mysql creates a new db based on the related service's name"
[14:48] <fwereade_> m_3, so that'd just be derived from $JUJU_REMOTE_UNIT, I guess?
[14:48] <m_3> so I'll give nick a MP... that's an important point to clear up
[14:48] <fwereade_> m_3, cool, thanks
[14:49] <m_3> right...  want a way to describe that in pseudocode without bogging down in env
[14:49] <m_3> thanks for catching that
[15:32] <dimitern> fwereade_: woohoo!!! all the uniter tests pass with the api!!
[15:32] <natefinch> dimitern: awesome :)
[15:33] <fwereade_> dimitern, sweeeet!!
[15:33] <dimitern> natefinch: yep, these were some long 3 days of struggling
[15:33]  * fwereade_ flings confetti
[15:33] <fwereade_> dimitern, does it work in practice as well? ;p
[15:33] <dimitern> fwereade_: haven't tried yet
[15:33] <natefinch> dimitern: I feel your pain.  I'm pretty keen to read it.
[15:35] <mgz> doh, I missed it, damn email filters
[15:35]  * mgz goes back and pours through
[15:35] <fwereade_> dimitern, how about checking whether a subordinate gets cleaned up properly in response to a destroy-unit of its princpal?
[15:36] <fwereade_> mgz, the conflicts are terrifying, everything htmly changed while I was doing it
[15:36] <fwereade_> mgz, but there should be some useful content
[15:36] <mgz> yeah, it's not a great format for version control currently, alas
[15:36] <fwereade_> mgz, I should also fix up the subordinates and implicit relations docs
[15:36] <dimitern> fwereade_: just that?
[15:37] <fwereade_> dimitern, it feels like a decently risky start
[15:37] <dimitern> fwereade_: ok, so I'll do 2 tests: classic wordpress + mysql stuff and another with subs (nrpe)
[15:37] <fwereade_> dimitern, cool
[15:38] <fwereade_> dimitern, maybe one specific one that deals with relation settings changing, and checking the caching stays sane
[15:39] <mgz> fwereade_: I'll branch and look at resolving while I read
[15:39] <mgz> will poke you to pull later
[15:39] <fwereade_> mgz, don't worry about that
[15:39] <fwereade_> mgz, evilnickveitch has said he knows what to do with it
[15:39] <mgz> I think a re-run of the template thing and some bzr commands should do it
[15:39] <fwereade_> mgz, he just announced a new way of creating pages
[15:40] <fwereade_> mgz, my first attempts in that direction were less fruitful than I had hoped they might be
[15:40] <mgz> yeah, saw that, was what reminded me about your docs
[15:40] <dimitern> fwereade_: luckily I already have that prepared from last time
[15:40] <fwereade_> dimitern, nice
[15:41] <evilnickveitch> mgz, fwereade_ sorry for spoiling everyone's day by making things easier :)
[15:42] <fwereade_> evilnickveitch, cheers dude ;)
[15:43] <mgz> evilnickveitch: yell if you need a hand resolving that branch
[15:47] <dimitern> fwereade_: but first this https://codereview.appspot.com/13324052
[15:49] <fwereade_> dimitern, LGTM, lovely small branch :)
[15:49] <dimitern> fwereade_: cheers :)
[15:51] <dimitern> fwereade_: just proposing the big branch as WIP for discussion first
[15:51] <dimitern> fwereade_: and to see how big it actually is
[15:51] <fwereade_> dimitern, cool, I have to head off and sign the contract in a few minutes
[15:52] <dimitern> fwereade_: ah, cool, good luck then :)
[15:52] <fwereade_> ...which means, jcastro, that I'm afraid I'll be missing the charm call again :(
[15:52] <dimitern> fwereade_: it's not that bad actually 2188 lines (+556/-285) https://codereview.appspot.com/13355046
[15:53] <jcastro> fwereade_: that's cool
[15:56] <dimitern> now on to live testing
[16:16] <TheMue> rogpeppe, dimitern: a small review https://codereview.appspot.com/13656044
[16:19] <rogpeppe> TheMue: reviewed
[16:21] <TheMue> rogpeppe: thx, though of that flag too but then decided to go the save way ;)
[16:21] <TheMue> thought
[16:24] <natefinch> dimitern, rogpeppe , mgz, TheMue, fwereade_: Anyone have an opinion on where to put the logrotate config file? is next to the log file acceptable, or should it go in the .juju folder, or somewhere else?
[16:24] <dimitern> natefinch: shouldn't it be in /etc/logrotate.d/ ?
[16:24] <mgz> in /etc somewhere I'd assume
[16:24] <TheMue> dimitern: +1
[16:25] <rogpeppe> natefinch: i think putting it in /var/log/juju would seem ok to me
[16:25] <rogpeppe> natefinch: but /var/lib/juju would be ok too
[16:25] <dimitern> rogpeppe: why there?
[16:25] <rogpeppe> natefinch: but if there's some other standard, it might be best to use that
[16:25] <dimitern> rogpeppe: there is - /etc/logrotate.d/ is the usual place
[16:25] <rogpeppe> dimitern: just to limit the amount of config we spray around the system
[16:25] <rogpeppe> dimitern: ok, fair enough
[16:26] <dimitern> rogpeppe: hmm.. well, I suppose we can put it in /var/lib/juju/, but logrotated should be notified somehow to search it there
[16:26] <natefinch> I wish linux man files would just say that
[16:27] <rogpeppe> dimitern: /etc/logrotate.d sounds fine if that's standard
[16:27] <dimitern> rogpeppe: at least that's where I put logrotate conf files before on ubuntu and it always worked
[16:32] <natefinch> dimitern: it looks like there are several in there, so definitely seems like a standard
[16:34] <natefinch> anyone have opinions on rotation poiicy?
[16:40] <mgz> natefinch: policy is the sort of thing where you just have to pick an option, then review it later if needed I think
[16:41] <mgz> daily seems fine
[16:41] <natefinch> mgz: that's fine.  I was thinking of something like ,roll at 50 megs, keep 4 backups, compress all but the most recent backup
[16:41] <natefinch> mgz: hmm.. you think time is better than size?
[16:41] <mgz> not really, just what I'm used to
[16:42] <natefinch> mgz: pros and cons to both I guess
[16:43] <rogpeppe> anyone else seen this error when testing state? ... value *errors.errorString = &errors.errorString{s:"cannot create log collection: read tcp <IP_ADDRESS>:54392: i/o timeout"} ("cannot create log collection: read tcp <IP_ADDRESS>:54392: i/o timeout")
[16:43] <mgz> hm, no, new one to me
[16:44] <rogpeppe> mgz: when i run the tests individually, they pass
[16:44] <rogpeppe> mgz: but i'm seeing that issue consistently currently
[16:45] <mgz> I;m mostly running just one module tests at the moment, which doesnt help noticing those kinds of issues...
[16:45] <rogpeppe> mgz: it's worth running whole-suite tests too, at least once a day, i reckon
[16:46] <natefinch> mgz: this sounds promising, minsize, used with daily, means "roll over daily, but only if the log is at least N bytes"  It doesn't stop you from getting 2 gigs of logs in a day, but it means you won't end up with 5 logs of 2 lines each
[16:46] <mgz> natefinch: that does sound good
[16:47] <rogpeppe> mgz: ah! i know the problem. i think it must be reason jam rolled back the mongo version
[16:48] <dimitern> rogpeppe: there's something wrong with worker/runner
[16:48] <rogpeppe> dimitern: in trunk?
[16:48] <dimitern> rogpeppe: yes
[16:49] <rogpeppe> dimitern: hmm, a recent change?
[16:49] <dimitern> rogpeppe: it seems it restarts workers even after a fatal error in some cases
[16:49] <rogpeppe> dimitern: oh really? have you got a way of reproducing the behaviour?
[16:50] <dimitern> rogpeppe: still looking - so far I can only reproduce it once I migrated the uniter to the api and it happens in TestWithDeadUnit
[16:51] <dimitern> rogpeppe: the first time Login succeeds, then we return ErrTerminateAgent because the entity is dead, that gets the task killed with "fatal", but after that it's immediately restarted
[16:51] <rogpeppe> dimitern: i can see a way that it can happen, but only a very small time window, and i'm not sure that's the issue you're seeing
[16:52] <rogpeppe> dimitern: can you paste a log from when it happened?
[16:53] <dimitern> rogpeppe: http://paste.ubuntu.com/6093304/ here's a snippet
[16:53] <dimitern> rogpeppe: as you can see the first time it's ok, then it gets into a loop restarting it
[16:55] <rogpeppe> dimitern: ah! i think i see what might be the problem.
[16:55] <dimitern> rogpeppe: oh?
[16:55] <rogpeppe> dimitern: i don't *think* it's a problem in worker/runner, although, hmm
[16:56] <dimitern> rogpeppe: perhaps it's in the common agent code
[16:56] <dimitern> rogpeppe: but can't figure out what
[16:56] <rogpeppe> dimitern: oh, this is the unit agent, isn't it?
[16:56] <dimitern> rogpeppe: yeah
[16:58] <rogpeppe> dimitern: that scuppers that thought. thinking again.
[17:00] <rogpeppe> dimitern: the weird thing is line 22 of that log
[17:00] <rogpeppe> dimitern: why is the unit agent being restarted?
[17:01] <dimitern> rogpeppe: exactly my question
[17:01] <rogpeppe> dimitern: i mean the unit agent itself, not the uniter worker
[17:01] <rogpeppe> dimitern: that's nothing to do with worker.Runner
[17:02] <dimitern> rogpeppe: ah, ha!
[17:03] <rogpeppe> dimitern: BTW I think openAPIState should return ErrTerminateAgent if it gets a permission-denied error
[17:03] <rogpeppe> dimitern: i think if you fix that, this problem might go away
[17:03] <dimitern> rogpeppe: I was thinking the same
[17:11] <rogpeppe> dimitern: which actual test was running in the log you posted?
[17:11] <rogpeppe> dimitern: let me guess - it was TestWithDeadUnit, right?
[17:12] <rogpeppe> dimitern: if so, everything's working as expected, except the permission-denied problem
[17:12] <dimitern> rogpeppe: yep
[17:13] <dimitern> rogpeppe: still can't make it exit, even after returning errTerminateAgent on CodeUnauthorized
[17:13] <rogpeppe> dimitern: hmm. could you paste the (complete) log again?
[17:14] <rogpeppe> dimitern: (of running just TestWithDeadUnit)
[17:14] <dimitern> rogpeppe: one moment
[17:14] <jam> rogpeppe: the "timeout" test failure you saw was, indeed, why I rolled back to rev 240 on the bot
[17:15] <rogpeppe> jam: yeah, tests passed again when i reverted to that rev
[17:15] <dimitern> rogpeppe: does this look ok http://paste.ubuntu.com/6093367/
[17:15] <dimitern> rogpeppe: that's inside agent/openAPIState now
[17:15] <rogpeppe> dimitern: doesn't look quite right
[17:15] <dimitern> rogpeppe: and still I get *exactly* the same log output
[17:15] <dimitern> rogpeppe: why?
[17:15] <rogpeppe> dimitern: don't you want to return ErrTerminateAgent on not-found?
[17:16] <rogpeppe> dimitern: are you thinking you've got a C-style switch statement?
[17:16] <dimitern> rogpeppe: oh..
[17:16] <rogpeppe> dimitern: i think you want a ","
[17:16] <rogpeppe> dimitern: or just an if statement...
[17:18] <dimitern> rogpeppe: changed to an if
[17:18] <dimitern> rogpeppe: and still the same result - here's the complete log http://paste.ubuntu.com/6093388/
[17:21] <rogpeppe> dimitern: what does your openAPIState function look like now?
[17:22] <dimitern> rogpeppe: http://paste.ubuntu.com/6093402/
[17:22] <rogpeppe> dimitern: ah, i see the problem
[17:23] <dimitern> rogpeppe: good! where it is?
[17:23] <rogpeppe> dimitern: the OpenAPI call is failing, not the Entity call
[17:23] <rogpeppe> dimitern: you need to do a similar thing for the error result of agentConfig.OpenAPI
[17:23] <rogpeppe> dimitern: it never gets as far as calling Agent().Entity()
[17:24] <dimitern> rogpeppe: I see
[17:31] <dimitern> rogpeppe: sweet! so it looks like this now and it passes: http://paste.ubuntu.com/6093428/
[17:32] <rogpeppe> dimitern: cool!
[17:33] <dimitern> rogpeppe: and due to that change now tests pass slightly faster :)
[17:38] <natefinch> man, these cloudinit tests are gnarly
[17:38] <dimitern> natefinch: everybody hates them :)
[17:38] <natefinch> dimitern: well, glad I'm in good company at least
[17:39] <rogpeppe> natefinch: they're better than they were :-)
[17:39] <natefinch> rogpeppe: that's scary :)
[17:39] <rogpeppe> natefinch: if you can think of a better way, feel free :-)
[17:40] <natefinch> rogpeppe: I knew you'd say that :)  Not saying I know a better way.... just... gnarly :)
[17:41] <rogpeppe> natefinch: the original tests just probed random bits of shell script. at least here we get to vet the shell script when it changes
[17:41] <rogpeppe> natefinch: (i agree BTW)
[17:41] <rogpeppe> natefinch: (even though i am responsible for them...)
[17:41] <rogpeppe> dimitern: can the Entity call ever return NotFound?
[17:42] <dimitern> rogpeppe: i think not
[17:42] <natefinch> rogpeppe: seems like, if we're going to test it as one giant script, why not just write it as one giant script?  Might be more clear that way.
[17:44] <rogpeppe> natefinch: and just test the entire cloudinit output in each test?
[17:46] <rogpeppe> dimitern: i'm not sure about the shouldTerminate helper function. i wonder if openAPIState is a bit clearer something like this: http://paste.ubuntu.com/6093489/
[17:47] <natefinch> rogpeppe: so, I'm just basically looking at expectScripts.... and... well, it seems like it's testing that we're calling the code we expect to call, not that the result of the call is what we expect.  Like we test that mkdir -p '/var/lib/juju/agents/machine-0'  is in the scripts, but we don't test that /var/lib/juju/agents/machine-0 exists.
[17:47] <rogpeppe> natefinch: how can we check that?
[17:47] <rogpeppe> natefinch: (without actually running the scripts, which is problematic)
[17:48] <rogpeppe> natefinch: if it was trivial and cheap to spin up an LXC environment, we might do that in the tests, but i don't see a good alternative otherwise
[17:49] <rogpeppe> natefinch: i would *love* to be able to test that those scripts worked without actually testing them live
[17:49] <natefinch> rogpeppe: maybe we need a separate suite marked as slow tests that actually does spin up an LXC container
[17:52] <dimitern> rogpeppe: lgtm, will change as you suggested
[17:52] <natefinch> rogpeppe: it might also be easier to test if the script and the inputs to the script were separated. So, like, have the script as a template, and then fill it in with the values based on the environment, similar to the way it is now... but that way you could test that the values are correctly derived from the environment, independently of testing the script itself.
[17:52] <natefinch> rogpeppe: er, that is, similar to the way it is in the tests
[17:53] <rogpeppe> natefinch: script-as-template is perhaps an interesting idea, but i fear it would be even harder to maintain
[17:53] <rogpeppe> natefinch: currently at least you can pretty much paste the output into the tests
[17:57] <natefinch> rogpeppe: yeah, that's true
[17:59]  * rogpeppe has reached eod
[18:00] <rogpeppe> g'night all
[18:00] <natefinch> night!
[18:03] <TheMue> night
[18:05]  * TheMue will step out too
[18:05] <TheMue> bye
[20:28] <thumper> fwereade_: around per chance?
[20:45] <thumper> natefinch: hey there
[20:45] <natefinch> thumper: howdy
[20:45] <thumper> natefinch: that branch that just merged seemed to have more than the comment mentinoed
[20:46] <natefinch> thumper: the windows one?
[20:46] <thumper> yeah
[20:46] <thumper> I see logrotate in it
[20:46] <natefinch> thumper: crap, I thought I'd backed that out... I accidentally committed that code to the wrong branch
[20:47] <thumper> natefinch: how about you take a look at the last revision
[20:47] <thumper> and we can do a post merge review if necessary
[20:47] <thumper> let me know what else is there that shouldn't be
[20:47] <thumper> if it is too much, we can revert
[20:47] <thumper> but I'd prefer not to
[20:47] <natefinch> thumper: I think that should be it, but I'll double check
[20:47] <thumper> kk
[20:50] <natefinch> thumper: yeah, just the logrotate stuff... luckily not very many lines of code
[20:51] <thumper> had it been reviewed?
[20:52] <natefinch> thumper: no :/
[20:52]  * thumper takes a look
[20:52] <natefinch> thumper: evidently i misunderstood how bzr uncommit works.... and then foolishly didn't think to double check that it did what I expected
[20:53] <thumper> ah, uncommit doesn't remove the change
[20:53] <thumper> just removes the commit
[20:53] <thumper> the code stays there
[20:53] <thumper> to kill it you need to:
[20:53] <thumper> bzr uncommit && bzr revert
[20:54] <natefinch> thumper: hmm... though I did that, but obviously missed a step.
[20:55] <thumper> natefinch: well you get a +1 from me on the logrotate stuff, assuming it works :)
[20:56] <natefinch> thumper: I double checked the logrotate stuff by actually running it with actual files.  I almost wrote a test explicitly to do that, but it feels more like testing logrotate than testing our code
[20:57] <natefinch> thumper: especially since the configuration is so simple
[21:09] <natefinch> thumper:   EOD for me.  Thanks for notifying me about that, btw.
[23:06] <bigjools> morning all
[23:14]  * thumper headdesks
[23:19] <fwereade_> thumper, hey, around briefly
[23:20] <thumper> fwereade_: hey
[23:20] <thumper> fwereade_: nothing urgent, just hadn't talked in a while
[23:20] <thumper> I keep finding shit not done when I thought it was
[23:20] <thumper> makes me sad
[23:20] <thumper> worse when it is my own TODO
[23:21] <fwereade_> thumper, likewise :(
[23:21] <fwereade_> thumper, I am largely spared that by virtue of writing little code
[23:21] <thumper> heh
[23:21] <fwereade_> thumper, dimitern's got the uniter api working live, though
[23:21] <thumper> we can catch up later, I'm well aware of how late it is there
[23:21] <thumper> cool
[23:23] <thumper> wallyworld: ping
[23:23] <fwereade_> thumper, yeah, I might go to bed in a mo
[23:23] <wallyworld> yo
[23:23] <thumper> wallyworld: I need another set of eyes on something
[23:23] <fwereade_> thumper, I just have a vague recollection I told some people I'd pass by tonight
[23:23] <thumper> wallyworld: jam was reviewing about a week ago, but has left it
[23:23] <wallyworld> ok
[23:23] <thumper> wallyworld: and it is rapidly becoming a blocker
[23:24] <thumper> fwereade_: it is the 1.16 format branch
[23:24] <thumper> oh ffs, where did it go
[23:24] <fwereade_> thumper, ok, I thought I posted some vague questions on that a while ago
[23:25] <fwereade_> thumper, I thought I checked it today and saw no movement
[23:25] <thumper> I didn't realise there were outstanding questions
[23:26] <fwereade_> thumper, let me look again, perhaps I have been hallucinating
[23:26] <thumper> ah...
[23:26] <thumper> there were two reviews
[23:26]  * thumper will look at this
[23:27] <fwereade_> thumper, I did https://codereview.appspot.com/13481043/ and jam did the previous
[23:28]  * thumper nods
[23:28] <thumper> I'll respond today
[23:30] <wallyworld> thumper: did you need me to look at something?
[23:31] <thumper> wallyworld: not any more
[23:31] <thumper> but thanks
[23:31] <wallyworld> \o/
[23:43] <thumper> fwereade_: FWIW, I have a reasonably reasonable answer formulating in my head, will write it down after the gym
[23:43] <thumper> as opposed to a reasonably unreasonable answer


[10:17] <devtouch_> Hi ... followed ubuntu-touch build image generation for nexus 4 device as per porting guide. After flashing images using "project-rootstock-ng" script, device struck at google logo screen.Any idea/help to overcome this issue?


[01:52] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 714 @ https://fridge.ubuntu.com/2021/12/20/ubuntu-weekly-newsletter-issue-714/ (by guiverc)


[01:51] <waltman> JonathanD: I know the guys at http://www.bombingbrain.com/
[01:52] <waltman> I also know the guy who's doing the iOS app for Duck Duck Go.
[01:53] <waltman> another idea is to run the web service in safari.
[02:28] <jedijf> iDropper
[02:49] <JonathanD> ok.
[02:52] <rmg51>  iSleep
[02:52] <waltman> iTea
[02:53] <waltman> Lapsang Souchong, to be exact.
[05:01] <waltman> Happy New Year!
[07:03] <InHisName> Happy New Year to you waltman and anyone else still awake
[07:19] <andrew> morning
[07:40] <InHisName> slept thru the new year's activities, andrew ?
[07:40] <InHisName> morning to u 2
[11:40] <JonathanD> Happy New Year.
[12:13] <waltman> Morning.
[12:16] <waltman> '17
[12:40] <rmg51> morning
[15:39] <ChinnoDog> morning--
[17:29] <InHisName> year


[00:04] <anastasiamac> wallyworld: thumper:axw:babbageclunk: PTAL https://github.com/juju/juju/pull/7143, fixes a bug :D
[00:04] <anastasiamac> more like a gap than a broken functionaility...
[00:06] <babbageclunk> anastasiamac: just having lunch, but I'll take a look afterwards (if someone else doesn't!)
[00:07] <anastasiamac> babbageclunk: \o/
[00:17] <wallyworld> anastasiamac: babbageclunk: i'm not sure we've agreed to the approach yet. it's under discussion via email
[00:18] <wallyworld> we need to get agreement what they want to do is supported and correct first
[00:18] <anastasiamac> wallyworld: obviously not parties are on this email trail.... maybe discussing it in the bug will be better/more effective means as communication
[00:19] <axw> anastasiamac: reviewing
[00:19] <wallyworld> anastasiamac: agreed in principal. but we don't want to polluate the bug with lots of back and forth. the summarised outcomes can be added though
[00:19] <axw> wallyworld: this change is unintrusive, I don't think we need to have any more discussion before landing this particular change
[00:20] <axw> wallyworld: this is an alternative to what was being proposed, which was adding pre-populated relation settings
[00:21] <wallyworld> axw: that is true. but i was concerned it is a solution to a problem they didn't need to have if things were deployed the recommended way. i'd have to re-read the email trail
[00:23] <axw> wallyworld: ehh except there's some weirdness in the PR, so maybe I'm still misunderstanding the issue.
[00:23] <wallyworld> right
[00:23] <wallyworld> i'm hesitant because i'm not sure w'ere all on the same page
[00:26] <axw> wallyworld: yeah I'll continue discussions.
[00:28] <anastasiamac> wallyworld: sure but now that the PR is up, email communication is not best, especially if it excludes ppl that r blocked byy the bug and r proposing solutions
[00:31] <wallyworld> anastasiamac: the bug is not the place to have detail design discussions. status updates etc sure
[00:32] <wallyworld> or steps to repro etc etc
[00:41] <axw> anastasiamac wallyworld: I'm taking the discussion to the PR.
[00:41] <wallyworld> yup, +1
[00:41] <axw> and will take it back to email if that becomes unwieldy
[02:44] <wallyworld> axw: FYI, as discussed, this is the CDO vsphere bug https://bugs.launchpad.net/juju/+bug/1669483
[02:44] <mup> Bug #1669483: [2.1] juju bootstrap fails when there is no VM in vsphere datacenter or all VMs are in folders <cdo-qa-blocker> <oil> <oil-2.0> <vsphere> <juju:Triaged> <https://launchpad.net/bugs/1669483>
[02:45] <axw> wallyworld: okey dokey
[02:46] <axw> wallyworld: might be hard to test, since larry is away
[02:46] <axw> I don't think I should be deleting existing VMs
[02:46] <wallyworld> yeah, best effort and all that
[03:52] <cmars> hi, i have a fix for LP:#1675214. can i get a review? https://github.com/juju/juju/pull/7147
[03:52] <mup> Bug #1675214: destroy-model failed because could not determine model SLA level <ci> <destroy-model> <regression> <juju:In Progress by cmars> <https://launchpad.net/bugs/1675214>
[03:56] <thumper> jam: to be honest, I think we don't care for the use case you mentioned
[03:56] <thumper> not really, not now
[03:57] <thumper> however, if you think we do, I could add a txn-revno assert back in
[03:57] <thumper> jam: we do do a txn-revno assert in 2.x
[04:07] <wallyworld> cmars: looking
[04:07] <cmars> wallyworld, thanks!
[04:09] <wallyworld> cmars: yeah, or account for the facade version for each model - won't be too hard to do that
[04:09] <wallyworld> lgtm for the temp fix - just code deletion really
[04:10] <cmars> wallyworld, ok thanks!
[04:11] <wallyworld> babbageclunk: not sure if you are able to squeeze in a review before your EOD https://github.com/juju/juju/pull/7144
[04:13] <stokachu> first cut of conjure-up on macOS done \o/
[04:13] <babbageclunk> wallyworld: that's a tiny one! looking now
[04:13] <wallyworld> babbageclunk: that's what all the girls say too :-)
[04:14] <wallyworld> stokachu: well done!
[04:14] <stokachu> wallyworld: hopefully that'll increase our userbase by a lot
[04:15] <stokachu> i need to look into xhyve though for localhost deployments
[04:15] <stokachu> like docker does
[04:15] <wallyworld> stokachu: maybe? how many of our target audience  ueses macs? i personally hate them
[04:15] <stokachu> wallyworld: good question, im not sure
[04:15] <stokachu> word is though all the conferences people use macs
[04:15] <stokachu> kubecon etc
[04:15] <wallyworld> interesting
[04:16] <wallyworld> we should collect stats on that
[04:16] <stokachu> we do
[04:16] <babbageclunk> definitely true at Python conferences I've been to
[04:16] <stokachu> nice, yea i think having a localhost deployment mechanism will be handy
[04:16] <stokachu> basically xhyve to boot ubuntu
[04:17] <stokachu> then do some magic there to wire it up
[04:18] <stokachu> or vsphere would be nice here too i think
[04:37] <babbageclunk> wallyworld: reviewed
[04:38] <jam> babbageclunk: so I think we do need to have a better primary key than CIDR for subnets, but probably not worth you fixing right now. (you can't fix all the bugs in networking on your own :)
[04:41] <babbageclunk> jam: :) fair enough!
[04:44] <wallyworld> jam: that's exactly what i sid too :-)
[04:44] <wallyworld> babbageclunk: thanks for review
[04:45] <jam> babbageclunk: and my other point was "we won't really know if we have the right data until we actually go to *use* the data", (we're only recording it with your patch)
[04:45] <jam> but rough glance looks like its the right thing, and we can iterate from here.
[04:46]  * jam takes the dog out
[04:50] <wallyworld> babbageclunk: i replied to one of you comments, see if if makes sense?
[05:02] <axw> jam: 1:1? wallyworld is here too
[07:36] <mup> Bug #1468752 changed: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode <ssh> <windows> <juju:Fix Released by
[07:36] <mup> gz> <juju 2.0:Fix Released by gz> <juju 2.1:Fix Released by gz> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1468752>
[07:36] <mup> Bug #1616149 changed: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1616149>
[07:36] <mup> Bug #1637267 changed: Juju fails to restore state-server on xenial <ci> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1637267>
[07:48] <mup> Bug #1616832 changed: stuck rsyslogd causes mongodb to block <eda> <needs-ci-test> <sts> <juju:Triaged> <juju-ci-tools:Triaged> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1616832>
[09:07] <wallyworld> axw: you happy to go with "not supported" initially for nova networks and subnets in heather's PR ?
[09:11]  * axw looks
[09:13] <axw> wallyworld: hm. not sure, I'll need to check the behaviour of the code that calls Subnets
[09:13] <wallyworld> axw: yeah, if the interface claims support and then the other methods error, might not be good
[09:26] <axw> wallyworld: have the changes to discover subnets already been made
[09:26] <axw> ?
[09:27] <wallyworld> axw: in the worker, yeah
[09:27] <axw> oh yeah
[09:29] <axw> wallyworld: we at least need to look for NotSupported in the discoverspaces worker, in discoverSubnetsOnly
[09:29] <wallyworld> axw: yeah, i'd rather the provider not lie to the worker though
[09:31] <axw> wallyworld: welp, the only other option I guess is to return separate Environ implementations when nova and neutron are supported. I'm not sure if that's feasible though, because opening an an Environ is not supposed to make any API calls
[09:32] <wallyworld> yeah, also true. maybe handle not supported in the worker with a todo to fix the openstack provider to return subnets for nova
[09:32] <axw> wallyworld: yep
[09:33] <axw> wallyworld: FWIW, I'd prefer if we had an Environ.Networker method, which every Environ was required to implement. it would return an Environ or a NotSupported error
[09:33] <wallyworld> no argument from me there
[09:33] <axw> wallyworld: and then Networker would have methods for checking support for subnets, spaces, etc.
[09:33] <wallyworld> yep
[09:33] <wallyworld> i don't like the current implementation
[12:30] <jam> wpk: ping
[12:32] <wpk> jam: pong
[12:39] <jam> hi wpk, I wanted to go over some of the key bugs, though if you want it can wait until standup I suppose
[12:39] <jam> I'm going to be gone over the weekend, so I was hoping to chat with you about some next steps
[12:43] <wpk> I'm ready, should we talk here or maybe just join standup hangout now?
[12:46] <jam> sure, brt
[12:47] <jam> wpk: i'm there now
[13:21] <jam> wpk: https://github.com/juju/juju/pull/7119 reviewed
[13:38] <jam> sinzui: what triggers someone to get an "affiliated" icon in Launchpad?
[13:39] <jam> I'd like to get WPK a Juju sticker so that I don't accidentally pick some other Witold
[13:39] <sinzui> wow you challenge me
[13:40] <sinzui> jam: I think it is show when the user is a member of the owner or driver teams.
[13:40] <jam> well, he's in '~juju-core' afaict
[13:41] <sinzui> jam, we forgot to add him to ~juju
[13:41] <jam> but it looks like there is ~juju-hackers he wasn't part of
[13:41] <jam> I just did
[13:41] <jam> "Juju Hackers" aka ~juju
[13:41] <jam> sinzui: thanks for the pointer
[13:42] <jam> sinzui: btw wpk's current branch https://github.com/juju/juju/pull/7119 is likely to want a feature tests
[13:42] <jam> or an update to whatever we currently have that 'apt-proxy' works
[13:42] <jam> anyway I'm out for a bit
[13:43] <sinzui> jam, yep, that was the one I was curious about. I reported bug 1635633 and am eager to close it
[13:43] <mup> Bug #1635633: assess_proxy does not test apt proxies <gap> <proxy> <juju-ci-tools:Triaged> <https://launchpad.net/bugs/1635633>
[20:51] <wallyworld> babbageclunk: did you see bug 1675546?
[20:51] <mup> Bug #1675546: container networking broken in GCE <ci> <gce-provider> <lxd> <network> <regression> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1675546>
[22:02] <rick_h> wallyworld: anything to chat on today?
[22:02] <wallyworld> rick_h: not as such. very happy about the latest memory profile
[22:16] <rick_h> wallyworld: +1
[22:17] <babbageclunk> wallyworld: yup, chasing it, but had to rush off to the doctor - back now.
[22:17] <wallyworld> ty
[22:18] <wallyworld> we will release beta1 regardless
[22:25] <wpk> I'm having problems with bootstraping on maas, I'm constantly getting
[22:25] <wpk> /var/lib/juju/nonce.txt does not exist
[22:25] <wpk> 23:23:13 DEBUG juju.utils.ssh ssh.go:292 using OpenSSH ssh client
[22:25] <wpk> packet_write_wait: Connection to <IP_ADDRESS> port 22: Broken pipe
[22:28] <wpk> any ideas on what might I be doing wrong?
[22:41] <menn0> wpk: can you give a bit more context? is this with real hardware or vmaas?
[22:41] <babbageclunk> wallyworld: the bug is because the juju-qa env is a legacy network, so network interfaces are returned with no subnet. It looks like I can get everything I need off the network in that case - doing that.
[22:44] <sinzui> babbageclunk: interesting. We/me also has an ancient aws account
[22:45] <wpk> menn0: real hardware, PC + 2 NUCs with AMT as nodes. I'm doing juju bootstrap maastiff, and as I understand it SSHs to the node, installs all the stuff, reboots it, and then SSHs to it again just to fail on the above, then decomissions it
[22:45] <babbageclunk> sinzui: yeah, that's part of the problem - new accounts wouldn't have this kind of network as the default
[22:46] <babbageclunk> wpk: can you deploy a node in maas without juju?
[22:46] <menn0> wpk: seems something is up with SSH on the host causing it to drop the SSH connection attempt. is it possible to get the sshd logs on that host?
[22:47] <wpk> babbageclunk: yes, no problem with that
[22:47] <wpk> menn0: it gets decomissioned before I have a chance to get to it :/
[22:48] <menn0> wpk: try adding --keep-broken to the juju bootstrap command
[22:48] <menn0> wpk: that should keep the system around
[22:48] <wpk> menn0: ok
[22:48] <wpk> https://pastebin.canonical.com/183603/ that's the whole log
[22:52] <sinzui> wpk: your localhost cannot ssh to that address. As menn0 says try --keep-broken to keep it up
[22:53] <sinzui> wpk: while juju is bootstrapping, you *should* be able to ssh in as ubuntu@<ip>
[22:54] <wpk> I am
[22:54] <sinzui> wpk: you are sshed in?
[22:54] <sinzui> if so, use -v to see what key works.
[22:55] <sinzui> you can force the juju key using -i $JUJU_DATA/ssh/juju_id_rsa
[23:26] <wallyworld> wpk: there's a bug or 2 where this issue is discussed; usually the cause is a set up issue, see last comment or 2 on https://bugs.launchpad.net/juju-core/+bug/1314682
[23:26] <mup> Bug #1314682: Bootstrap fails, missing /var/lib/juju/nonce.txt (containing 'user-admin:bootstrap') <bootstrap> <juju> <maas-provider> <juju:Expired> <juju-core:Won't Fix> <https://launchpad.net/bugs/1314682>
[23:27] <wallyworld> wpk: also https://ask.openstack.org/en/question/59760/juju-bootstrap-failed/
[23:29] <wpk> sinzui: I was able to ssh in, using /home/wpk/.local/share/juju/ssh/juju_id_rsa key, and /var/lib/juju/nonce.txt exists on this node
[23:31] <wpk> sinzui: the nide has Internet access and dns resolution working
[23:43] <wpk> wallyworld: nothing worrying in cloud-init.log
[23:44] <wpk> hm, except for this:
[23:44] <wpk> 2017-03-23 23:28:12,171 - util.py[DEBUG]: Running module apt-configure (<module 'cloudinit.config.cc_apt_configure' from '/usr/lib/python3/dist-packages/cloudinit/config/
[23:44] <wpk> cc_apt_configure.py'>) failed
[23:44] <wpk> (...)
[23:44] <wpk> ValueError: Old and New apt format defined with unequal values True vs False @ apt_preserve_sources_list
[23:45] <wallyworld> that would do it
[23:48] <wpk> wallyworld: and what's the cause and how to fix it?
[23:49] <wallyworld> wpk: i have no idea off hand - it's an issue outside of juju and maas from whay i can see. you'd need to google the error and fix your apt config
[23:50] <wallyworld> but if cloud init doesn't complete, you'll see the nonce error
[23:50] <wallyworld> so you need to fix whatever is stopping cloud init from running properly
[23:53] <wpk> wallyworld: but why there's the nonce error if the file is there?
[23:53] <wpk> https://bugs.launchpad.net/cloud-init/+bug/1646571
[23:53] <mup> Bug #1646571: apt failures non fatal, but cloud the log <landscape> <cloud-init:Incomplete> <MAAS:Confirmed> <https://launchpad.net/bugs/1646571>
[23:54] <wpk> (and as it says - it's not fatal, cloud-init continues after that)
[23:55] <wallyworld> without digging into the code and analysing logs etc, there's no way to tell. we'll need to devote time to looking into it
[23:55] <wallyworld> the bug you link above indicates a maas issue
[23:56] <wallyworld> can you add extra info from your sitution to the bug?
[23:57] <wpk> wallyworld: I will, tomorrow (1AM here)
[23:57] <wallyworld> thanks


[15:58]  * slangasek waves
[15:58] <mdeslaur> \o
[16:00]  * stgraber waves
[16:01] <mdeslaur> hrm, no kees, no infinity
[16:02] <mdeslaur> ok, let's get this started anyway
[16:02] <mdeslaur> #startmeeting
[16:02] <meetingology> Meeting started Tue May 24 16:02:23 2016 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: action commands idea info link nick
[16:02] <mdeslaur> [topic] Action review
[16:02] <mdeslaur> slangasek to chase the juju team about creating https://wiki.ubuntu.com/JujuUpdates
[16:03] <slangasek> that wiki page exists now :)
[16:03] <slangasek> needs some iteration, which I'll take up with the Juju QA team by email
[16:03] <slangasek> but maybe can come off the nag list now
[16:03] <mdeslaur> ok, cool
[16:04] <mdeslaur> I'll carry forward infinity's actions
[16:04] <mdeslaur> mdeslaur to look into flavour CVE tracking
[16:04] <mdeslaur> haven't had time to poke at that, carry forward
[16:04] <mdeslaur> hi kees!
[16:04] <kees> hola!
[16:04] <slangasek> shoot, we didn't go fast enough to give kees all the action items before he got here
[16:04] <mdeslaur> we've started already
[16:05] <mdeslaur> hehe
[16:05] <mdeslaur> [topic] Mailing list archive
[16:06] <mdeslaur> doesn't look like there's anything on the list
[16:06] <mdeslaur> besides the last post, which I'll respond to
[16:06] <mdeslaur> [topic] Community bugs
[16:06] <mdeslaur> no community bugs
[16:07] <mdeslaur> does anyone have AOB?
[16:08] <slangasek> I do not
[16:08] <stgraber> nothing here
[16:08] <mdeslaur> [topic] Next chair
[16:08] <mdeslaur> slangasek, with stgraber as backup
[16:08]  * slangasek nods
[16:08] <mdeslaur> ok, looks like we're done
[16:08] <mdeslaur> #endmeeting
[16:08] <meetingology> Meeting ended Tue May 24 16:08:45 2016 UTC.
[16:08] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-05-24-16.02.moin.txt
[16:08] <mdeslaur> thanks everyone
[16:08] <slangasek> short and sweet
[16:08] <slangasek> thanks, mdeslaur
[16:09] <stgraber> thanks


 https://notes.kde.org/p/Kubuntu%7CAkademy2019 if you want to contribute thoughts, questions
[12:22] <BluesKaj> Howdy all
 Hello folks, I just did a draft of a story for kubuntu.org news and left the link to a photo to include. Can someone edit it and add the photo and publish it? Photo is courtesy of Myriam. photo link is https://photos.app.goo.gl/QzGyFASpjkWEchbUA in case it doesn't work in the website.
 thanks
 @Valoriez, done :)
 FYI to all,  plasma 5.12.9 LP: #1843613 packages are in bionic-proposed for testing
 there were only 6 sources with bugfixes we want, so kept it to just those this time


[10:10] <mup> Bug #1867812 changed: maas 2.7 regression: creates partition when trying to use entire disk as bcache cache device <cdo-qa> <cpe-onsite> <foundations-engine> <MAAS:Invalid> <https://launchpad.net/bugs/1867812>
[10:10] <mup> Bug #1995397 changed: Sentry blocked by CORS  <MAAS:Invalid> <https://launchpad.net/bugs/1995397>
[10:13] <mup> Bug #1867812 opened: maas 2.7 regression: creates partition when trying to use entire disk as bcache cache device <cdo-qa> <cpe-onsite> <foundations-engine> <MAAS:Invalid> <https://launchpad.net/bugs/1867812>
[10:13] <mup> Bug #1995397 opened: Sentry blocked by CORS  <MAAS:Invalid> <https://launchpad.net/bugs/1995397>
[10:16] <mup> Bug #1867812 changed: maas 2.7 regression: creates partition when trying to use entire disk as bcache cache device <cdo-qa> <cpe-onsite> <foundations-engine> <MAAS:Invalid> <https://launchpad.net/bugs/1867812>
[10:16] <mup> Bug #1995397 changed: Sentry blocked by CORS  <MAAS:Invalid> <https://launchpad.net/bugs/1995397>
[15:50] <mup> Bug #1996204 opened: failing metrics cause 500 error <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1996204>
[15:56] <mup> Bug #1996204 changed: failing metrics cause 500 error <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1996204>
[16:05] <mup> Bug #1996204 opened: failing metrics cause 500 error <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1996204>