[01:54] <roaksoax> win 4
[05:00] <caliculk> I have a ubuntu machine, that whenever the primary router restarts, the network interface never comes back up on the ubuntu server. I have a crash log, but am unable to switch kernels (mainly due to lack of out of band management/ipmi). I have the crash log here: http://pastebin.com/0jb8VxJN but was wondering if anyone had any other suggestions.
[05:36] <sarnold> caliculk: you could also try linux-lts-wily or linux-lts-xenial kernels, too; it might have been fixed upstream in the meantime, too
[08:01] <jamespage> coreycb, pushed microversion-parse to git, uploaded to unstable  - I see you shoved it in the PPA already
[08:01] <jamespage> coreycb, so pushed relevant changes to nova master packaging branch as well
[08:24] <sivir> sudo dnf install p7zip
[08:46] <EmilienM> jamespage: hi, we'll need this backport in ceilometer: https://review.openstack.org/#/c/318503/ otherwise it's impossible to run tempest against Ceilometer Mitaka (see commit message)
[08:50] <EmilienM> jamespage: do you think it's possible?
[08:51] <jamespage> EmilienM, is there an associated bug for that?
[08:52] <jamespage> EmilienM, and do the ceilometer team plan a point release anytime soon?
[08:52] <EmilienM> jamespage: I don't know
[08:53] <EmilienM> maybe we can ask on #openstack-telemetry
[08:59] <jamespage> EmilienM, I'd not put that through the SRU process individually, so really it would be nice to get a ceilometer point release made including other things
[08:59]  * jamespage looks to see what's been added since mitaka release.
[09:01] <jamespage> hmm only two fixes so far - one for a gate break and the other is some re-alignment only
[09:05] <EmilienM> jamespage: in the meantime, I'm trying to revert https://review.openstack.org/#/c/318519/
[09:05] <EmilienM> jamespage: because the problem is also in Liberty
[09:21] <sobersabre> hi. I want to add a machine to AD domain. I've tried using SSSD instructions: https://help.ubuntu.com/lts/serverguide/sssd-ad.html
[09:22] <sobersabre> And I think this one is a bit too simplistic. even though my setup is not complicated.
[09:31] <cpaelzer> nacc: is the section sobersabre reports here part of what you rewrote for the updated serverguide?
[09:32] <cpaelzer> nacc: is this even the new content already?
[09:33] <cpaelzer> sobersabre: while he (nacc) isn't here yet could you describe a bit what more or less compelx steps would be missing?
[09:33] <cpaelzer> sobersabre: or was that just a general statement of it being too simplistic?
[10:00] <halvors1> Where could i add a network script?
[10:00] <halvors1> I need to add a VTI interface, but because ifupdown is massivly lacking support for stuff like that, i need to do this using iproute2.
[10:02] <halvors1> Is there a ny good way to add a persistent iproute2 interface in Ubuntu?
[10:15] <sobersabre> cpaelzer: the problem is that sssd is hiding (naturally) most of subsystems of AD, so it would be very helpful to have tests for those subsystems, namely - ntpd, nmbd, smbd, krb and their integrations
[10:16] <sobersabre> I mean, I did all, and after joining the domain users don't show in getent passwd or getent group
[10:17] <sobersabre> There is a lot that could've gone wrong, and I'm now digging the logs.
[10:17] <sobersabre> I did similar flow with centos/fedora and it worked well. I don't know what goes wrong here exactly.
[10:17] <sobersabre> cpaelzer: ^^^ you here, aye?
[10:25] <cpaelzer> sobersabre: yes, still here
[10:25] <sobersabre> well, cpaelzer the howto didn't work :-]
[10:25] <cpaelzer> sobersabre: was at lunch for a few :-)
[10:25] <sobersabre> yep, people eat.
[10:26] <cpaelzer> sobersabre: I get with tests you mean kind of verification steps for each of those things so that one can track down if/where things fail
[10:38] <rbasak> jamespage: bug 1331630 is one for you I think? jgrimm: did this get missed from your subscription rearrangement?
[11:45] <Black-Ridder> hi :)
[11:46] <Black-Ridder> i'm a student and i've to make a server with bind9 an apache2, so i made it, but there is a little think that i don't understand
[11:47] <Black-Ridder> can someone help me please?
[11:47] <hateball> !help | Black-Ridder
[11:47] <hateball> mhm.
[11:49] <Black-Ridder> hateball : it's about virtual hosts
[11:49] <Black-Ridder> i've a server with differents website hosted
[11:49] <Black-Ridder> toto.com, tata.com (for example lol)
[11:50] <Black-Ridder> so in my bind9 server i've made a "zone" named ServerTestEcole.com.
[11:51] <Black-Ridder> but i can't link toto.com, tata.com etc
[11:52] <Black-Ridder> when i wrote www.toto.com i go to the default site of apache :'(
[11:54] <Black-Ridder> hateball : can you help me?
[11:54] <hateball> Black-Ridder: Not quite sure I understand it all, but perhaps someone else does
[11:54] <hateball> Be patient :)
[11:55] <Black-Ridder> okay thanks
[11:55] <Black-Ridder> is it my sentenses?
[11:56] <Black-Ridder> i'm from belgium so i probably make some error in my sentenses, sorry :p
[11:56] <hateball> well you need to configure apaches various sites to show you different things depending on what url used to reach it
[11:58] <Black-Ridder> yes
[12:00] <Black-Ridder> with apache's virtual host you can had many website on the same server (1website = 1 address; www.toto.com, www.tata.com,.. etc)
[12:01] <Black-Ridder> so in my link they explain how to do it with apache2 but they don't explain the bind9'part of the configuration :/
[12:39] <jgrimm> rbasak, i'll add suds to the list of things that should move to openstack.  i'm not done auditing the full server list yet for places where openstack isn't yet subscribed.
[12:40] <rbasak> jgrimm: OK
[12:55] <jamespage> EmilienM, hey - not sure what the puppet module for ceph does but https://review.openstack.org/#/c/318612/ is something to be aware of
[12:55] <jamespage> that changed between final rc and release of ceph jewel
[12:57] <EmilienM> jamespage: oh nice! we have some troubles to make it work, I'm sure this link will help
[12:57] <EmilienM> jamespage: thanks a lot for that
[12:58] <jamespage> EmilienM, np - it only effect use of OSD's on things other than xfs
[12:58] <jamespage> so we saw impact on zfs and ext4
[12:58] <EmilienM> jamespage: yeah OpenStack Infra is providing nodes with ext4 and we have issues
[12:58] <EmilienM> cool
[12:58] <EmilienM> thx for sharing that
[12:58] <jamespage> EmilienM, you are welcome
[13:00] <jamespage> coreycb, one patch away from newton/nova being functional  https://review.openstack.org/#/c/318568/
[13:01] <coreycb> jamespage, \o/
[13:02] <rbasak> nacc: o/
[13:04] <frickler> can anyone successfully run an yakkety cloud image? I'm stuck without networking even after 20 minutes: http://paste.ubuntu.com/16506150/
[13:04] <EmilienM> jamespage: did you see the logs yesterday about SSL?
[13:05] <jamespage> EmilienM, I did but I don't have an answer as to why its not working
[13:06] <jamespage> EmilienM, all I can think is that the nature of the cert you add to the ca-certifacates file means that its still not trusted - but I'm not 100% sure
[13:06] <EmilienM> jamespage: http://logs.openstack.org/30/308530/18/experimental/gate-puppet-openstack-integration-3-scenario002-tempest-ubuntu-xenial/e17a5b4/console.html#_2016-05-18_15_26_13_161
[13:06] <EmilienM> ok
[13:06] <jamespage> EmilienM, Replacing debian:puppet_openstack.pem
[13:06] <jamespage> yeah got that
[13:06] <EmilienM> ok I'll try with another cert
[13:06] <jamespage> so we can see it being added, but for some reason the clients are still not trusting it
[13:06] <EmilienM> thx
[13:07] <jamespage> EmilienM, the testing I did was a little different - I installed the cert for the private CA we setup, not the cert for each of the services...
[13:07] <rbasak> Odd_Bloke: see frickler's question above
[13:07] <jamespage> EmilienM, it would be handy to run something over that to see why - maybe openssl has a 'figure out trusted-ness' type thing?
[13:08] <jamespage> as I think that's what python actually uses for the verfication
[13:08] <EmilienM> jamespage: yeah, I would investigate that
[13:09] <jamespage> EmilienM, openssl s_client -connect <IP_ADDRESS>:5000 might tell you more
[13:10] <EmilienM> I need to reproduce all of that in a VM
[13:10] <EmilienM> degorenko: ^ FYI
[13:10] <degorenko> EmilienM, i have VM with my 15 patch set, without ssl, but i'll deploy latest for you :)
[13:12] <jamespage> EmilienM, yup
[13:12] <jamespage> tested against my deploy - verified OK with the CA cert installed for me
[13:13] <Odd_Bloke> frickler: I have run one, but it did take ~7 minutes to get networking; I expect you're seeing https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844.
[13:13] <Odd_Bloke> rbasak: (Thanks!)
[13:14] <jamespage> EmilienM, for example http://paste.ubuntu.com/16506393/
[13:14] <EmilienM> ok
[13:14] <Odd_Bloke> frickler: Does xenial work for you?
[13:15] <jamespage> EmilienM, that will at least give you more information about what's not working properly
[13:16] <halvors1> Hi.
[13:17] <halvors1> I want to add a tunnel using the "ip -6 tunnel add" command of iproute2, but i want it to be persistent so that it is loaded at boottime.
[13:17] <halvors1> How can i do this in ubuntu?
[13:21] <EmilienM> jamespage: ok we'll investigate, thanks again for your help
[13:21] <jgrimm> rbasak, billard can possibly be demoted?  i think it had been drug in as dependency for celeryd & friends at some point, but they've been demoted since.  for consideration.
[13:22] <jgrimm> rbasak, noticed this while doing my package audit
[13:22] <rbasak> jgrimm: billard?
[13:23] <jgrimm> rbasak, https://launchpad.net/ubuntu/+source/billiard
[13:26] <rbasak> jgrimm: looks like it's seeded only by the development seed now: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety/view/head:/development#L62
[13:27] <rbasak> jgrimm: so up to Foundations I guess? They should have the bug subscription or demote it I think.
[13:38] <frickler> Odd_Bloke: xenial runs fine, yes
[13:46] <halvors1> Is network interfaces handled by systemd or ifupdown in ubuntu 16.04?
[13:49] <frickler> halvors1: should still be ifupdown by default, but you can enable systemd-networkd.service if you want to have that
[13:50] <frickler> Odd_Bloke: well, there is one issue for Xenial, the ensX names are non-predictable and may get changed after a reboot
[13:50] <Odd_Bloke> frickler: Hmm, that's definitely a bug.
[13:50] <Odd_Bloke> smoser: rharper: ^
[13:52] <frickler> start with one interface: ens3, add a second via "nova interface-attach": ens7, do a "nova reboot": get ens3+ens4 instead
[13:54] <jamespage> coreycb, added manila to mitaka and newton ci
[13:55] <coreycb> jamespage, thanks.  I'm taking a look at the neutron liberty failure.
[13:55] <jamespage> coreycb, okies
[13:55] <jamespage> coreycb, ostestr might be a good first change
[13:55] <jamespage> the wily failure looks like bad mocking to me
[13:55] <jamespage> chance that it passed on trusty...
[13:55] <coreycb> jamespage, yep!
[14:01] <halvors1> Um. Someone said something but my IRC client crashed.
[14:02] <halvors1> Can you please repeat? :)
[14:02] <frickler> halvors1: should still be ifupdown by default, but you can enable systemd-networkd.service if you want to have that
[14:09] <halvors1> Ah ok.
[14:09] <halvors1> frickler: Is it possible to use both?
[14:13] <frickler> halvors1: maybe it is, but I don't think that that would be really stable
[14:29] <smoser> frickler, that is very odd.  cloud-init is trying (which needs improvements) to make sure that ens3 good, but the second attached nic should also be stable in name.
[14:36] <jamespage> frickler, hey - thanks for the quality of your bug reports btw - much appreciated...
[14:38] <frickler> smoser: it isn't, when nova recreates the libvirt.xml, the order of pci slots may change. it even gets fancier if you also attach and detach volumes
[14:41] <frickler> smoser: I would think going back to using ethX for cloud instances would be much more sensible. Like special case this for Virtio network devices maybe
[14:43] <degorenko> jamespage, hey, about checking ssl, my output on vm for openssl s_client command:http://paste.openstack.org/show/497729/ i have not experience with ssl. May be it can help you somehow
[14:44] <degorenko> and also i see this error: 2016-05-19 14:43:45.106 30584 ERROR oslo.messaging._drivers.impl_rabbit [req-2198cd2f-e791-47c9-ad41-d064f25750cb - - - - -] AMQP server on <IP_ADDRESS>:5671 is unreachable: [SSL: TLSV1_ALERT_INSUFFICIENT_SECURITY] tlsv1 alert insufficient security (_ssl.c:590).
[14:44] <sdeziel> frickler: special casing virtio NICs only would miss the SR-IOV one
[14:44] <jamespage> degorenko, that's something quite different...
[14:45] <degorenko> EmilienM, fyi ^
[14:45] <jamespage> degorenko, but your first paste lgtm - the cert verified ok
[14:45] <degorenko> jamespage, any ideas? :)
[14:45] <sdeziel> frickler: but PCI ordering is really annoying I must admit
[14:45] <jamespage> Verify return code: 0 (ok)
[14:45] <jamespage> degorenko, second is probably rmq is not configured to support tlsv1.2
[14:45] <jamespage> v1 has some issues I think
[14:45] <EmilienM> weird all of this worked on trusty
[14:45] <EmilienM> maybe a dep in python or?
[14:46] <degorenko> jamespage, same error from rabbit log =ERROR REPORT[14:46] <jamespage> EmilienM, I think it all worked on trusty because python 2.7 ignores certificate validate chains in trusty
[14:46] <degorenko> SSL: hello: tls_handshake.erl:167:Fatal error: insufficient security
[14:47] <degorenko> for the recored - rabbitmq is running
[14:47] <jamespage> degorenko, I've not seen that problem before - I'd have to google it but I would suspect its something related to tls version level negiotiation
[14:48] <degorenko> jamespage, i will try also to find out the problem, thanks in advance, ping me, if you will have something
[14:48] <jamespage> degorenko, https://www.rabbitmq.com/ssl.html good reference for checking
[14:49] <degorenko> thanks, going to read article :)
[15:00] <smoser> frickler, thats an openstack bug honestly.
[15:01] <smoser> using eth0 and eth1 was only randomly better if it was
[15:01] <smoser> if openstack arbitrarily moves nics around on a bus on reboot or shutdown / startup, then it really needs to stop doing that.
[15:02] <smoser> really, even in the old 'eth0' and 'eth1' world, it could brea
[15:02] <smoser> break.
[15:03] <smoser> i'm sure that they keep the mac, so it seems that the solution would be to really have to "pin" nics to a given name based on mac.
[15:12] <nacc> rbasak: hey, would you be free after the team hangout today?
[15:12] <rbasak> nacc: yeas
[15:12] <nacc> rbasak: great, thanks!
[15:34] <coreycb> ddellav, hey, ping me your package for review in #ubuntu-server if it's ready
[15:34]  * coreycb thought he was in another channel
[15:38] <ddellav> will do, one sec coreycb
[15:46] <frickler> smoser: well, they keep the ordering stable (at least I hope, will have to check), so if eth0 is the first virtio-nic and eth1 the second one (as it is with e.g. Trusty IIUC), everything should be fine
[15:46] <frickler> smoser: the trouble comes from systemd-udev assuming that PCI slot ids are stable, which is pretty fine for real hardware, but less so for virtual environments
[15:49] <smoser> yes. thats absolutely it, but for a vm, why is it *not* stable ?
[15:50] <smoser> why does openstack arbitrarily move nic devices around. that is silly.
[15:52] <nacc> is this a hotplug case? looking above, i see a nova-attach invocation. And maybe something ensures that the new device comes "after" the current one? But on reboot, it gets normally detected and the order can be whatever hte bus order is?
[15:52] <frickler> nacc: yeah, that is about what I gather happens
[15:53] <frickler> or rather, on reboot/recreate the default ordering happens, which is network interfaces first, then console/vga, then block devices
[15:54] <nacc> smoser: i don't know about the first part (what nova attach does), tbh, but i do recall seeing (in other contexts) a device being added, and then the order can be different on a normal boot with the same config
[15:55] <smoser> i really think the thing we have to do is to make the names based on nic
[15:55] <smoser> er... based on mac address
[15:55] <nacc> smoser: ack, that's the only "stable" thing
[15:56] <nacc> smoser: and also means if you hotplug in, hotplug out, hotplug in a second, and then reboot, you'll get the right config for the second, not just happen to share the config from the prior (if you went off device naming and happened to get the same name)
[15:56] <nacc> smoser: with newer setups, i guess the "stable naming" implies mac address? (it's in the suffix), but i'm not savvy with how that all works and where it exists
[16:04] <smoser> fyi, ubuntu-server and such do get logged at
[16:04] <smoser>  http://irclogs.ubuntu.com/2016/05/19/%23ubuntu-server.html
[16:04] <smoser> and i quite often link to those things from bugs.
[16:20] <smoser> sdeziel, is https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1573192 a regression ?
[16:20] <smoser> from 15.10 or 14.04 ?
[16:21] <sdeziel> smoser: I never tried on anything before 16.04
[16:21] <smoser> sdeziel, ah. ok. thanks.
[16:21] <sdeziel> smoser: I could check that out since I have some trusty laying around
[16:25] <smoser> sdeziel, youd ont have to just jump and do it right now. would be good to know as that would raise my feeling of priority on nit.
[16:25] <sdeziel> smoser: OK, thanks
[16:30] <coreycb> jamespage, I'm surprised the midonet plugin was removed by upstream in a stable branch - https://github.com/openstack/neutron/commit/f5d1a42ee252605e51694352b8521c78201603e5
[16:34] <degorenko> jamespage, hey, i've also checked rabbit port for openssl s_client, there are no any tls session tickets, is it ok? http://paste.openstack.org/show/497736/
[16:58] <sdeziel> smoser: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1573192 is reproducible on Trusty
[17:16] <smoser> sdeziel, thanks
[18:35] <ddellav> coreycb here the heat repo, lp:~ddellav/ubuntu/+source/heat, it builds successfully and i believe the config file matches yours
[18:35] <ddellav> sorry for the delay, i got wrapped up with this backport reading docs and forgot to paste that to you
[18:39] <coreycb> ddellav, can you fix that on the master branch instead?  we have to fix the current release first.
[18:39] <ddellav> coreycb ah ok, sure
[18:40] <coreycb> ddellav, also does it work?  I would think the PYTHONPATH=.  would need to be on the same line as oslo-config-generator
[18:40] <ddellav> coreycb i copied it from the barbican package and when I installed the produced heat deb it looked right but i'll double check
[18:42] <fermulator> Hey all, I've recently been trialling landscape for personal server/desktop admin/management, it's pretty sweet! saves me oodles of time on system maintenance, (especially pkg upgrades atm).  My unfortunate situation though is that all (~7-8) desktops+servers are Ubuntu, except ONE (1), which is Fedora. Has anyone any information/refs on if it's possible to hook a non-Ubuntu Linux distro into landscape
[18:42] <fermulator> ? (obviously not all features would be available, but I'm interested in at least the ability to monitor the system via landscape web UI)
[19:03] <Sebastien> ok, so. i want to manage emails on my box, and also subdomains. Is it possible to do this with webmin ?
[19:05] <rharper> nacc: smoser: frickler: re the MAC; that is probably the only uniq thing that won't change;  the MAC in nic name however, presents a challenge w.r.t stacking devices since en+strlen($MAC)+\n is like 15, to a 16 char limit for ifname; so things like bridges, aliased interaces, vlans, all become problematic due to existing mechanism to assume appending extra stuff , eth0.123;
[19:06] <nacc> rharper: ah yeah i remember talking about that at the sprint
[19:07] <nacc> rharper: yep, so makes sense to somehow keep a mapping of MAC -> data about interface somewhere?
[19:07] <fermulator> Sebastien, your question may be better asked in #webmin
[19:07] <rharper> yeah; aka udev-rule/systemd.link file; which is eactly this MAC -> NAME mapping;
[19:08] <rharper> openstack has a network_data.json which can export this information (and could update it upon nic hotplug);  cloud-init is parsing that and can emit the mapping;  the remaining on-hotplug trigger cloud-init to regenerate netconf and name nics as the remaining todo here;
[19:09] <rharper> I agree with smoser though that there is little reason for openstack/libvirt to reorder the devices on the bus;
[19:09] <rharper> mapping that to a real hotplug of a nic; one usually don't move all of the boards around when adding one new one
[19:10] <rharper> that's causing churn for no reason;
[19:10] <nacc> rharper: does hotplug have some special cases for adding the bus? like it puts it "after" existing busses when live-hotplug?
[19:11] <rharper> libvirt has code for walking the existing topology in the case that the libvirt hotplug xml doesn't include an explicit bus address
[19:12] <rharper> it's possible that they've got some code that collects them all and then writes out a new xml file;  so you can see a nic get plugged into slot 3 at hotplug time, but when rebooting, the on-disk xml has it in a different slot
[19:12] <nacc> i'm just wondering if somehow the non-xml state (live) isn't matched up to the xmls tate
[19:12] <nacc> yeah
[19:12] <rharper> yes
[19:12] <rharper> happens quite often
[19:12] <rharper> with disks as well
[19:12] <nacc> right, makes sense
[19:12] <nacc> hence why UUIDs are important :)
[19:12] <rharper> but disks have fancy things like /dev/disk/by-id which map to disk serial
[19:13] <rharper> however, oddly; qemu doesn't provide default serial number (unlike default mac addrs) except for HDA types.
[19:13] <nacc> yeah, wasn't there a request at some point to have a /dev/net/by-id by-mac etc
[19:13] <rharper> we never fixed that  silliness
[19:13] <rharper> yeah; but the kernel interface doesn't allow for filesystem ops
[19:13] <nacc> oh right
[19:13] <smoser> rharper, but tha trequirees the serial :). which they're not providing.
[19:13] <rharper> my current reading of the code is that the only real thing is the ifindex
[19:14] <rharper> then ifname is field of a structure indexed
[19:14] <nacc> right
[19:14] <rharper> smoser: yeah, uuidgen[:20]
[19:14] <nacc> so is the issue in the above queries that the device got renamed or that hte libvirt busses got reordered on reboot?
[19:14] <rharper> that's good enough and can be "persisted" in the xml
[19:16] <rharper> nacc: it's the classic nic hotplug case where a nic shows up, it's been hotplugged into slot 7; but libvirt wrote out an xml on disk that didn;t put the hotplug nic in slot7; so upon reboot the hotplug nic is now in slot4
[19:16] <nacc> ah ok, now i get it
[19:16] <rharper> since we're using systemd "persistent" naming, we don't trigger a udev-write-net-persist script which could have recorded MAC -> name (ens7) mapping
[19:16] <nacc> so a "fix" would also be to write to the XML the live state?
[19:16] <rharper> but slots aren't as persistent as MAC->NAME mapping
[19:16] <rharper> yeah, or figure out why libvirt persistent of hotplug devices changes slots
[19:16] <nacc> i guess s/"fix"/"hack"/
[19:17] <nacc> and i'm sure from a data-structure, cleanliness perspective, there are advantages to compressing the bus namespace down
[19:17] <rharper>  s/hack/return-to-previous-mostly-sane-behavior
[19:17] <nacc> :)
[19:17] <rharper> nacc: I doubt it's that level of sanity
[19:18] <nacc> rharper: this is libvirt? probably not, you're right
[19:18] <rharper> my guess is that no one noticed the movement due to persistent rules being written in the past
[19:18] <rharper> libvirt
[19:19] <rharper> now that everyone is 'persistent'; the OS is taking the "hardware" at it's word; turns out the machine builder (nova/libvirt/qemu) aren't actually providing a persistent hardware machine
[19:19] <rharper> sorta moving the bubble around
[19:19] <nacc> right
[19:20] <rharper> I thought about playing around if the ifalias structure in the kernel (it supports up to 256 chars) per interface
[19:20] <rharper> there are some existing users of that though (snmp MOBs use those for tagging)
[19:21] <rharper> but it'd be nice to have 256 char space per device for naming and such; though I don't think anyone really wants to type in: ifconfig enx8cae4cfdb971
[19:21] <rharper> maybe if we add tab-completion for ifconfig and ip with the netdev names
[19:21] <nacc> people already don't want to type eth<anything other than 0> it feels like :)
[19:21] <rharper> that's probably a really nice thing to do  now
[19:21] <sdeziel> rharper: in your previous example, if you persisted the name ens7 to map to your hotplugged NIC that later gets moved to slot4, what will happen when you hotplug another NIC that lands in slot7?
[19:22] <rharper> sdeziel: it'll fall back to the kname (like eth3)
[19:22] <sdeziel> rharper: OK. This is going to be confusing at some point
[19:22] <rharper> the systemd.network manpage on NamingPolicy talks about the order in which it attempts to get a name
[19:22] <rharper> sdeziel: at some point? =)
[19:23] <nacc> i think the notion should be that if it's consistent over reboot, and there is a way to go from the name to the 'physical' location, then the name is just a handle
[19:23] <sdeziel> ens7 sets some expectations on the location of the said NIC.
[19:23] <nacc> sdeziel: if it's explicit that the name isn't hte location, but there is a mapping somewhere, then we just break that expectation from the get-go
[19:24] <rharper> sdeziel: right, which is why we don't currently write out a persistent rule
[19:24] <rharper> the name is supposed to reflect where it is
[19:24] <rharper> sdeziel: and in this example, the admin (libvirt/nova) did move it (ens7 -> ens4)
[19:24] <rharper> that's like someone in the lab pulling the card and putting it somewhere else
[19:25] <rharper> one probably wants to know that;  though we had large discussion about the location of the interface not mattering as much as what the nic is connected to
[19:25] <rharper> which is opposite of say disks which are more concerned with the data _in_ them
[19:25] <nacc> right, you want subnet information, roughly (connectivity like you said)
[19:26] <rharper> nacc: right; in the case of openstack which _can_ tell us about the nics; there's no reason to use the "location" mapping at all
[19:26] <nacc> yep
[19:26] <nacc> it only leads to confusion :)
[19:26] <rharper> the oracle, as we say, can then name it whatever  red, blue, management, private
[19:26] <TJ-> we need a /dev/net/by-route/ like /dev/disk/by-uuid/
[19:26] <rharper> TJ-: yeah
[19:26] <rharper> that'd be super cool
[19:26] <nacc> yeah i guess that'd just the gateway(s)
[19:26] <rharper> by-mac, by-ip, etc
[19:27] <rharper> but that's, I think, a rather large endeavor
[19:27] <TJ-> I always wondered why that wasn't the systemd solution seeing as it absorbed udev, which love symlinks
[19:27] <nacc> yep, and one most people have just avoided :)
[19:27] <rharper> where's 9P
[19:27] <sdeziel> what I'm saying is persisting a name that embeds slot location is confusing at best
[19:27] <rharper> sdeziel: how so?
[19:27] <rharper> for a real server in the lab
[19:27] <rharper> it's useful information;  which card do I pull out ?
[19:27] <rharper> the one in slot 7
[19:28] <rharper> ens9 doesn't have a link (go plug in a cable)
[19:28] <TJ-> it could just be a tag though, it doesn't need to be the if name, which should be something that means something to the network admin
[19:28] <rharper> TJ-: yeah; so the ifalias field has 256
[19:28] <sdeziel> in the ens7 -> ens4 case, if you persisted the name ens7 and the card actually moved to slot4 you can not longer figure out where it is hooked by the name
[19:28] <rharper> one could come up with some tooling to apply info to that field and then assemble symlinks
[19:28] <rharper> but all of the ip tools work on ioctls
[19:29] <rharper> so a lot of effort to revamp tooling to look at symlinks to figure out which ifindex to use to query more info and set values
[19:29] <rharper> sdeziel: correct; we'rre not suggesting to persist the nic name based on slot location into the OS;  rather in libvirt which is like the machine definition
[19:30] <rharper> sdeziel: instead, the cloud should provide a name -> mac mapping in the config (openstack can do this) and cloud-init will generate mappings between name and mac via systemd.link files
[19:30] <sdeziel> rharper: ah OK, I had missunderstood
[19:32] <rharper> we're in a unstable time now that cloud-init can do this for some clouds (openstack has a network_data.json source);  other clouds may have theres too, and we need those clouds to start providing that level of netconf
[20:29] <sirhumpalot> anyone have experience expanding an ext4 fs while online with TB of data and connected users?
[22:35] <hallyn> drat.  my qemu 2.6.0 merge fails a guest scsi test.
[23:45] <hallyn> well this is maddening.  my yakkety vms won't boot
[23:47] <hallyn> all right purging cloud init helped
[23:58] <HappySomethingSo> hi
[23:58] <HappySomethingSo> I'm having problems setting up a static ip on ubuntu 16
[23:59] <HappySomethingSo> I used to edit /etc/network/interfaces on ubuntu 14 to set it up, but that no longer works
[23:59] <HappySomethingSo> and everything I do in /etc/network/interfaces.d gets erased on system boot


[00:01] <jelmer> mwhudson: how long does it take on average for a branch to be scanned?
[00:03] <mwhudson> jelmer: 30s
[00:03] <mwhudson> jelmer: given the scanner runs every minute
[00:05] <spiv> mwhudson: surely "30s + the average time it takes to do the scanning work"?
[00:05] <mwhudson> yes ok
[00:05] <mwhudson> but that's not very long on the whole
[00:05] <mwhudson> since we un****ed the scanner
[00:05] <spiv> (sorry, I haven't been pedantic for *hours*)
[00:05] <spiv> (because I was asleep)
[00:12] <spm> spiv: perhaps for your directory entry then: coder of bizarre, and pedantical chatter; start python faster
[00:12] <spiv> spm: :)
[00:12] <spm> spiv: feel very free to improve (not hard) ;-)
[00:27] <jelmer> mwhudson: so my lp:~jelmer/git/trunk branch doesn't work again, any chance you can check?
[00:32] <jelmer> it won't use older revisions?
[00:32] <jelmer> I mean, revisions that I pushed using my previous push
[00:34] <Leon_Nardella> Are ARM buildbots planned for the PPAs?
[00:34] <jelmer> it's uploading a 130Mb repo in 50 seconds, that can't be right..
[00:48] <thumper> jelmer: you're right, that is much too fast :)
[00:49]  * thumper looks
[00:49] <thumper> jelmer: what is the new branch you're pushing?
[00:49] <jelmer> thumper: I've just pushed to ~jelmer/git/trunk
[00:50] <thumper> jelmer: have the revision ids changed?
[00:51] <jelmer> thumper: no, the revision ids haven't changed
[00:51]  * thumper ponders
[00:51] <jelmer> (I added a workaround for a bug in bzr's revision serialization mwhudson pointed out)
[00:54] <thumper> jelmer: our OSA has gone walk-about, I'll check and get back to you
[00:54] <thumper> jelmer: mwhudson is at PyCon :)
[00:55] <jelmer> thumper: thanks
[00:55] <jelmer> ahh, I was wondering why he was less responsive than usual :-)
[00:58] <fta> it seems that ppa builders are completely broken
[00:58] <fta> https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[00:58] <fta> 6 hours doing nothing?
[00:59] <fta> https://edge.launchpad.net/builders/bohrium: it's beeing doing that for ~5h
[01:01] <wgrant> Primary is the same too.
[01:01] <wgrant> No jobs have been started for 4 hours or so.
[01:02] <wgrant> spm: ^^
[01:06] <spm> wgrant, fta ta. am fighting some rather nasty fires at the moment. will get back to you asap.
[01:13] <_steven_> anyone know if the upcoming milestone to release conversion on april 1st will include linking bugs to newly created milestones?
[01:15] <jml> _steven_: I don't know off-hand.
[01:15] <jml> _steven_: are you subscribed to the launchpad-users mailing list?
[01:15] <_steven_> no
[01:15] <jml> hmm.
[01:15] <_steven_> was just reading the blog post
[01:17] <jml> _steven_: there's nothing in the announcement to launchpad-users either.
[01:18] <jml> _steven_: sinzui & others likely to know are asleep right now. If you really want to know then I suggest either asking a question on answers.launchpad.net/launchpad-registry, or emailing launchpad-users.
[01:18] <jml> or waiting until US working hours.
[01:19] <cpscotti> hello there, is there any particular reason why all but one PPA i386 building machines are idle even though there are 51 build in the queue? Should I just wait a little time or should I go to bed and check this tomorrow?
[01:19] <_steven_> if they're from US, I doubt they're asleep, just not working
[01:19] <sinzui> _steven_: Bugs are not linked to milestones by the migration script.
[01:19] <jml> sure. I used the word in the figurative sense :)
[01:20]  * sinzui thinks how that could be done
[01:20] <jml> oh. hurrah.
[01:20] <jml> cpscotti: it's a known problem. we're working on it now.
[01:20] <cpscotti> hmmm thanx!
[01:20] <cpscotti> =]
[01:20] <_steven_> sinzui: my project has never used milestones before, but I'd like all my old bugs that I fixed in a certain release to be targeted to the newly created milestones
[01:21] <_steven_> it might not be trivial to do though
[01:21] <sinzui> _steven_: We intend to create a unified milestone/release page what will show the changelog and closed bugs.
[01:21] <_steven_> that would be a nice addition
[01:22] <_steven_> is that part of 2.2.3 or coming later?
[01:23] <sinzui> _steven_: I'm hacking on it right now. I'm going to beg permission to landed it for the 22.3 release.
[01:23] <_steven_> hehe, ok
[01:23] <jml> sinzui: :D
[01:24] <sinzui> _steven_: The act of associating a bug with a milestone is manual. However, there are rules to link (html anchor) a bug in changelog, so I image that if we trust the changelog/release notes, we could mine that to link bugs milestones.
[01:26] <_steven_> ok, any documentation on the correct format?
[01:27] <sinzui> _steven_:  if the text or a changelog contain bug 1234, bug #1234, lp: 1234, we assume that that is a Launchpad bug
[01:27] <sinzui> oops
[01:27] <_steven_> sinzui: would lp#287995 match?
[01:28] <sinzui> _steven_: yes. We have a nicer report for blueprints an bugs that are explicitly targets to milestone
[01:29] <_steven_> sinzui: I always put my changelog in the release description because I can never get the changelog to show on the release page
[01:30] <_steven_> sinzui: for example, this release has the changelog contents in the description and the changelog fields, but only description shows: https://launchpad.net/linuxdcpp/1.0/1.0.3
[01:31] <_steven_> will that be modified with the changes you are working on?
[01:31] <sinzui> _steven_: yeah. most projects do. I am proposing that we include (but hide the changelog). I have no explanation why the change log is hidden.
[01:31] <sinzui> only the RDF published the changelog
[01:33] <sinzui> We wont be modifying. I think putting the changelog in a expanding section is a good way to expose the information while minimising the duplication. beuno will review the design to finalise how we reconcile this historical oversight.
[01:34] <_steven_> ok, so if you guys happen to implement milestone to bug conversion, it should work with my changelog
[01:37] <_steven_> sinzui, jml: thanks for the help
[01:38] <jml> _steven_: np
[01:41] <spm> wgrant: fta: stuff seems to be processing again. leastways, the buildd's are busy again.
[03:03] <thumper> jelmer: you branch is failing to scan with the SyntaxError: not well-formed (invalid token): line 6, column 46 from bzrlib.xml_serializer, line 101, in read_revision_from_string
[03:06] <jelmer> thumper: thanks
[03:07] <thumper> jelmer: I thought you'd be asleep :)
[03:07] <thumper> jelmer: do you want the entire stacktrace for bzrlib?
[03:08] <jelmer> thumper: no, thanks, I think this is an indication the bug I thought was fixed is still around
[03:08] <thumper> ok
[03:08] <thumper> jelmer: can I delete that branch then?
[03:08] <thumper> jelmer: otherwise it is going to try every minute or so
[03:09] <thumper> jml: we need a way to tell the scanner not to try...:-|
[03:10] <jml> thumper: easy easy easy :)
[03:12] <jelmer> thumper: I've already done so
[03:12] <thumper> jelmer: thanks
[03:12] <jelmer> thumper: daylight savings is messing with me
[03:12] <thumper> :)
[03:24] <jml> thumper: is it still DST in NZ?
[03:24] <thumper> jml: until this weekend I think
[03:25] <jml> *nod*
[03:25] <jml> fun and games and 8am start times :(
[03:25] <jelmer> thumper: seems to work ok now: http://bazaar.launchpad.net/~jelmer/git/trunk/changes
[03:25]  * jelmer gets some sleep
[03:34] <mwhudson> jelmer: your git branch got scanned in the end i see
[03:35] <mwhudson> jelmer: it occurred to me that the case like this, when there are lots of revisions new to launchpad being scanned, is still pretty slow
[03:35] <thumper> mwhudson: not entirely scanned :(
[03:36] <thumper> mwhudson: loggerhead says last rev was 3000
[03:36] <thumper> mwhudson: LP says 1000
[03:36] <mwhudson> huh what
[03:36] <mwhudson> oh yes
[03:36] <thumper> mwhudson: I'm guessing that the commits done after chunks has meant that the first 1000 were fine
[03:36] <thumper> mwhudson: but something went wrong in the second 1000
[03:36] <thumper> mwhudson: or it could still be scanning :(
[03:37] <thumper> mwhudson: with new revisions
[03:37] <mwhudson> but it's all one transaction
[03:37] <mwhudson> isn't it?
[03:37] <thumper> nope
[03:37] <thumper> hasn't been for ages
[03:37] <thumper> otherwise it was holding the transaction open for too long
[03:40] <mwhudson> ah
[03:42] <TheMuso> I have recieved an upload failure for the latest revision of pulseaudio for amd64. I retried the build once thinking the failure to upload was a transient error: https://launchpad.net/ubuntu/+source/pulseaudio/0.9.14-0ubuntu15/+build/923086
[03:42] <TheMuso> All other architectures have built and uploaded successfully.
[04:14] <jamesh> TheMuso: you'll probably have better luck asking at the end of the day, given the time zones where the soyuz guys work
[04:15] <jamesh> or file a bug
[04:15] <TheMuso> jamesh: Thanks, will do
[04:17] <spm> TheMuso: can you see the upload log? has a 'duplicate key value' fail. I call bug.
[04:18] <TheMuso> spm: Yes, I can bounce the upload failure to you if you would like.
[04:18] <jamesh> hmm.  I think someone else came up with that one recently
[04:19] <jamesh> https://bugs.edge.launchpad.net/soyuz/+bug/347194
[04:19] <TheMuso> spm: bounced
[04:20] <jamesh> TheMuso: last comment on the above bug is cprov saying he thinks the problem is fixed
[04:20] <TheMuso> jamesh: sounds about right
[04:20] <jamesh> TheMuso: you seem to have proved the opposite
[04:20] <jamesh> so it'd be helpful to tell him
[04:20] <TheMuso> jamesh: seems so
[04:20] <TheMuso> ok
[04:20]  * TheMuso replies to teh bug
[04:20] <TheMuso> but in another twist, it seems the amd64 debs are now on a.u.c.
[04:21] <spm> TheMuso: ta. fwiw I could read the log - I'm just never quite sure how much of what I can see is common to those without super-duck powers :-)
[04:21] <TheMuso> spm: ok
[06:53] <dholbach> hiya
[06:53] <dholbach> somebody aware of OOPSES like OOPS-1185B627 happening?
[06:54] <dholbach> (just tried to open a https://launchpad.net/bugs/123456 URL)
[06:54] <dholbach> ah :)
[06:55] <spm> dholbach: something has *really* broken. :-(
[06:55] <spm> dholbach: i expect to be hairless from excessive hair pulling rsn.
[06:55] <dholbach> oh yeah, openid is broken too
[06:55] <dholbach> launchpad.net too FWIW :-/
[06:55]  * dholbach hugs spm
[06:55] <spm> yah. something has really gone boom in a big way
[06:56] <jfroy> mmm, I'm getting ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem: -1 errors from launchdpad
[06:56]  * wgrant just found the world was broken too.
[06:56] <jfroy> started not too long ago
[06:56] <dholbach> I'm sure the best people possible are working on this.
[06:59] <wgrant> Looks more healthy now.
[06:59] <dholbach> yeah, nice work! :-)
[06:59] <wgrant> Not bad recovery time.
[07:00] <jml> not even 9 minutes.
[07:00] <spm> all seems ok? do yell if you notice any funkies and I'll start bouncing app servers or whatever
[07:00] <jml> spm: looks good to me so far.
[07:13] <jfroy> urg, my branch is locked on launchdpad, and the break-lock command is failing :|
[07:14] <wgrant> jfroy: Make sure you're giving break-lock an lp: URL and not an lp-123456: URL.
[07:14] <jfroy> ahhh
[07:15] <jfroy> that's a lame UI bug >.>
[07:15] <wgrant> It is.
[07:15] <wgrant> Particularly because I was able to guess with good certainty what the problem was.
[07:21] <jml> yes.
[07:53] <AnAnt> Hello, Steve McInerney here ?
[07:54] <spm> AnAnt: that'd be me. what's up?
[07:55] <AnAnt> spm: regarding question 62612
[07:55] <AnAnt> thanks, but the links on https://launchpad.net/~sabily.team/+archive/ppa still won't work
[07:55] <spm> arrgrghhh!
[07:55] <AnAnt> for example: https://launchpad.net/~sabily.team/+archive/ppa/+sourcepub/504630/+files/sabily-keyring_2009.01.20~ppa1_all.deb
[07:56]  * AnAnt hides under the table
[07:57] <spm> AnAnt: heh. No, is not your fault. no need to hide :-)
[07:57]  * AnAnt pops his head to check that everything is clear
[07:57] <spm> :-)
[07:58] <spm> AnAnt: is that link off the PPA pages somewhere? ah yes tehre it is. nm
[08:00] <spm> AnAnt: ahhh. I see the problem. :-( if you use edge, it works. use prod, it doesn't. :-(
[08:01] <spm> AnAnt: eg https://edge.launchpad.net/~sabily.team/+archive/ppa and browse
[08:01] <AnAnt> ok, but for those downloading using, apt-get, no probs ?
[08:01] <spm> I'm not sure tbh....
[08:01] <spm> shouldn't be a problem now I engage brain.
[08:01] <spm> AnAnt: check the sources URL if it's like this: http://ppa.launchpad.net/sabily.team/ppa/ubuntu/ you'll be fine
[08:02] <AnAnt> errm, didn't work with edge btw
[08:02] <wgrant> Drop the +sourcepub/123456
[08:03] <AnAnt> ah, that worked !
[08:04] <spm> AnAnt: sorry to run on you like this, but I'm really afk now. :-( If no joy, drop a new question, reffing the old and we'll sort from there.
[08:04] <AnAnt> ok
[08:05] <AnAnt> thanks
[09:06] <YokoZar> ok I can't link to an upstream bug report because the "also affects distribution" page is giving me an error as though I wanted to add a distribution rather than just link an upstream bug
[10:19] <wgrant> YokoZar: The "Also affects distribution" wil lexpect you to add a distribution task, yes.
[10:19] <YokoZar> wgrant: yeah I was supposed to be clicking also affects project
[10:20] <YokoZar> which didn't have the familiar place to paste the upstream bug link since the bug already had an upstream link (I wanted to add a second)
[10:20] <YokoZar> so I assumed I was on the wrong page since it wasn't familiar
[10:20] <wgrant> Ahh.
[10:23] <slangasek> are there known issues with LP right now?  I've just gotten two oopses in the past 5 minutes, that cleared up on reload
[10:23] <slangasek> the last specifically said it was a timeout
[10:23] <wgrant> slangasek: There was a huge problem a few hours ago.
[10:23] <wgrant> But it was plain OOPSing.
[10:27] <slangasek> wgrant: perhaps related, perhaps not; but this was definitely more recent than a few hours ago
[10:27]  * slangasek keeps an eye out
[11:13] <slangasek> another timeout - OOPS-1185A1418
[12:06] <serola> Question... Ubuntu teams like Ubuntu Netbook Remix seem to use Launchpad as a server for their repositories. Is it okay for other open source projects to do the same?
[12:08] <wgrant> serola: Launchpad is intended to be used by any open source project.
[12:10] <serola> Thanks wgrant :)
[13:15] <SiDi> Hello
[13:15] <SiDi> I've got a question regarding launchpad's bug tracker
[13:16] <intellectronica> SiDi: what's the question?
[13:16] <SiDi> Someone just reported a bug on one of my projects, but the bug obviously doesnt concern my project (i anyways didnt post any code yet), and i'd like to know how to push the bug report out
[13:16] <SiDi> is there a way to say that a bug doesnt affect a project ?
[13:16] <intellectronica> SiDi: url?
[13:17] <intellectronica> SiDi: you can change the target of a bug task
[13:17] <SiDi> https://bugs.launchpad.net/reztorrent/+bug/351489
[13:18] <intellectronica> SiDi: i think azureus has an LP project registered. so you can simply retarget that bug
[13:18] <intellectronica> azureus == vuze iirc
[13:18] <SiDi> alright, gonna check for azureus
[13:19] <intellectronica> SiDi: just expand the form and input 'azureus' into the textbox that currently says 'reztorrent' and save
[13:19] <SiDi> thanks intellectronica
[13:21] <SiDi> When a bug report is obviously wrong / is fake, is there a way to link it to no project btw ?
[13:21] <SiDi> or should i just make it invalid ?
[13:25] <intellectronica> SiDi: you should mark it invalid. we don'y currently have a way to remove bug reports entirely. a common convention is to retarget them to the project 'null'
[13:25] <SiDi> Alright, thanks for the tip
[13:29] <wgrant> bigjools: Is there a good reason that the user's display name is always part of the PPA title?
[13:29] <noodles775> wgrant: I'm guessing it's left over from when users had only one ppa and couldn't change the name...
[13:31] <noodles775> Now that users will be able to rename ppa's, it won't be the case any longer...
[13:31] <wgrant> '“name” PPA for Some User' is better than the current 'PPA named name for Some User', but just showing the display name would be even better.
[13:32] <noodles775> Yep, I agree... although it might give the PPA some sort of context that it wouldn't otherwise have..
[13:32] <noodles775> eg, user creates a ppa 'kde-releases'
[13:32] <wgrant> There's context in the breadcrumbs. But I guess that doesn't help for the OpenPGP keys.
[13:33]  * wgrant notices that the PPA vocab is a bit broken now.
[13:34] <wgrant> Actually, completely broken.
[13:34] <wgrant> Or at least one use of it.
[13:34] <wgrant> (+edit-dependencies' selector)
[13:35] <wgrant> Ah, bug #340457
[13:35] <noodles775> :)
[13:36] <wgrant> Bug #334883 is where the initial naming was decided :(
[13:36] <wgrant> Didn't notice that :(
[13:36] <wgrant> maxb: ^^
[13:37]  * noodles775 is surprised that a bug got through wgrant's filters!
[14:37] <stani> is it possible to delete a branch from launchpad (I've created by one by accident)?
[14:38] <jpds> stani: Go to the branch's page and press the rubbish bin next to the name.
[14:40] <stani> jpds: thanks, that worked! great
[14:41] <jpds> No problem.
[14:52] <dominiks> hey guys... I'm getting error when trying to access my build logs (e.g. https://launchpad.net/~dominik-smatana/+archive/ppa/+build/923742 ) any idea please?
[14:59] <bigjools> dominiks: ugh. please file a bug on "soyuz" about that
[15:00] <dominiks> bigjools: ok
[15:01] <bigjools> thank you
[15:06] <bigjools> dominiks: try it again
[15:06] <dominiks> bigjools: everything looks fine now.. thank you
[15:44] <RainCT> Hey
[15:44] <RainCT> Aren't sponsored uploads displayed under "Related Software" anymore?
[15:47] <thewrath> hello all i am new to launchpad have set it up fo rmy project
[15:47] <thewrath> i have some questions
[15:47] <beuno> thewrath, shoot
[15:48] <thewrath> i did a test bug i want that related to a specific version
[15:48] <thewrath> i have created a series
[15:48] <thewrath> called 2.1 but dont know and didnt see where i can relate the bug to that serial
[15:48] <thewrath> *series
[15:48] <thewrath> and how to change the status and what not for the bug
[15:49] <thewrath> bc i am not suing bazaar adn not using blueprints
[15:49] <thewrath> if that helps at all
[15:49]  * beuno pokes gmb, BjornT and intellectronica and runs off for 10'
[15:49] <thewrath> so my quesiton is how to i related a bug to a series and how do i change the status important, etc
[15:49] <RainCT> thewrath: click on the arrow next to the project name / status / importance
[15:49] <intellectronica> whassup?
[15:50] <thewrath> k
[15:50] <RainCT> thewrath: then you can set Status, Improtance, Milestone and Assignee. Afaik you can't set it to a series, but have to use Milestones instead
[15:50] <thewrath> how do i realted it to a series i created
[15:50] <thewrath> ok
[15:51] <thewrath> hold on let me finsih this survey
[15:51] <RainCT> (a series can contain several releases and milestones, and it's the milestones which you use for bugs)
[15:51] <thewrath> ok
[15:52] <thewrath> how do i create a milestone
[15:52] <thewrath> and remove a series
[15:53] <thewrath> think i found it
[15:54] <thewrath> whats the difference between release and milestone
[15:55] <RainCT> thewrath: a release is for downloads and a milestone for bugs
[15:55] <thewrath> k
[15:55] <RainCT> iirc soon all releases will automatically get a milestone with the same name
[15:56] <thewrath> ok
[15:56] <thewrath> how can you remove a relase
[15:58] <thewrath> RainCT: thank you so much
[15:59] <thewrath> RainCT: how can the bug reporter set up where the bug is like what release or is that always the issue of the person in charge?
[16:01] <RainCT> thewrath: the later. You're welcome :)
[16:02] <RainCT> You can set a text with instructions for bug reporters so you can tell them there "please note what version you're using [in the bug description]" or whatever
[16:04] <thewrath> i mean they wont be able to pick the milestone
[16:16] <MTecknology> kiko: you around?
[16:16] <kiko> no
[16:17] <MTecknology> kiko: can I pm you? absolutely nothing to do with launchpad
[16:17] <kiko> I'm on the phone, that's why
[16:18] <MTecknology> kiko: could you let me know when you're done? I need to talk with a Canonical employee that I trust fully
[16:19] <MTecknology> or - that I trust that will do something
[16:23] <kiko> MTecknology, okay, privmsg me
[18:12] <jsmidt> I have a PPA for Git.  Launchpad keeps saying the i386 build fails but the build log says: "Built successfully"
[18:13] <jsmidt> Does anybody know how this couldbe?
[18:27] <geser> I'm currently looking at the LP API and there on the 'build' object: is it currently possible to get back from the build log to the source package?
[18:27] <geser> and is it possible to get infomations about the current version in e.g. jaunty for a source package?
[18:28] <james_w> build.build_log_url
[18:28] <geser> and parsing that?
[18:28] <james_w> ah, sorry
[18:29] <james_w> no, there's no way back yet by the look of it
[18:29] <geser> I've a 'build' object and want to get the source package name and the version of it the build log applies
[18:29] <james_w> you can do the second thing though
[18:30] <james_w> ubuntu.main_archive.getPublishedSources()
[18:31] <geser> thanks
[18:31] <geser> so I only need to extract the source package name from the build log
[18:32] <cprov> jsmidt: what's the build URL ?
[18:33] <jsmidt> cprov, it's: https://launchpad.net/~git-core/+archive/ppa/+build/922979
[18:35] <james_w> geser: yeah, but file a bug requesting the build->source package link be exposed
[18:36] <cprov> jsmidt: I've updated the build record to 'successfully_built' since it was built correctly. I'm still investigating what is causing this problem.
[18:38] <cprov> jsmidt: the hardy source will fail in the same way, once it settles I will update it as well.
[18:38] <jsmidt> cprov, thank you a lot
[18:50] <bromic94> hey all
[18:51] <thewrath> under where it says milestone, etc how can i add a area that it says what issue it is like waht category?
[19:09] <djsiegel1> Hello, how do I delete a project/team?
[19:10] <cody-somerville> djsiegel1, File a question against launchpad requesting it
[19:10] <djsiegel1> Thank you
[19:25] <bdmurray> In the API documentation participants_collection refers to "IPerson.inTeam()" but I can't find that documented anywhere.  Does it exist?
[19:30] <salgado> bdmurray, not in the API
[19:31] <bdmurray> salgado: did it used to?  I want to find out if a specific person is a participant in a team w/o grabbing all the team's participants
[19:31] <salgado> bdmurray, it's an internal method that was exported at some point but we had to unexport it because of privacy reasons
[19:35] <fta> could you guys not use a red cross (failed) when a package is in depwait mode? (https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa)
[19:36] <fta> please :)
[20:02] <thewrath> where can i learn about the launchpad bug status meanings/
[20:04] <dominiks> https://wiki.ubuntu.com/Bugs/Status
[20:05] <intellectronica> thewrath: https://help.launchpad.net/Bugs/Statuses
[20:10] <thewrath> ty
[20:39] <MTecknology> Ursinha: https://edge.launchpad.net/people/?name=Trefný%2C+Vojtěch&searchfor=all
[20:39] <MTecknology> _Ursinha: OOPS happens when searching for users with certain symbols in their name
[20:41] <Ursinha> MTecknology, a min please
[20:43] <Ursinha> MTecknology, bug 251569
[20:44] <MTecknology> Ursinha: ok - just wanted to make a note of it. I popped over to google for those users to find a link :P
[20:47] <Ursinha> MTecknology, :)
[20:54] <jkakar> Bug team: Ooh, I just got my first glimpse of the activity log work in the bug tracker, "tags changed: added review".  Very awesome, thanks! :)
[20:56] <tux_> hi
[20:56] <tux_> are there any?
[21:11] <vadi2> Why is https://bugs.launchpad.net/bugs/346754 inaccessible?
[21:11] <vadi2> Oh. mk.
[21:12] <vadi2> It's just on https://wiki.ubuntu.com/UbuntuBugDay/20090402
[21:13] <cody-somerville> vadi2, you should be able to see it now
[21:13] <vadi2> yes
[21:20] <vadi2> same with https://bugs.launchpad.net/bugs/349741
[21:36] <vagrantc> i've noticed recently one of the bzr projects stopped sending out commit notifications, but another related project continues to send them. others also stopped receiving commit notifications... https://code.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk
[21:36] <cody-somerville> vadi2, btw, the reason that those bugs are private is because they contain potentially private information. Usually a bug triage team member will mark them as public after they've made sure no private information is in the report.
[21:36] <vadi2> eh, ok
[21:39] <cody-somerville> vagrantc, is ~ltsp-upstream/ltsp/ldm-trunk an example of a branch that no longer sends out commit notifications?
[21:39] <vagrantc> cody-somerville: yes.
[21:39] <cody-somerville> vagrantc, what is your launchpad id?
[21:39] <vagrantc> cody-somerville: vagrantc
[21:40] <vagrantc> cody-somerville: another person, i think ryan52, didn't receive anything after 1140 either.
[21:40] <vagrantc> cody-somerville: https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk works fine. seem to be configured identically.
[21:41] <cody-somerville> What does it say on https://code.edge.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/+edit-subscription ? Can you post a screenshot?
[21:42] <vagrantc> cody-somerville: notification level: branch attribute and revision notifications   generated diff size limit: 500 lines  code review level: status changes only ...
[21:42] <vagrantc> cody-somerville: both are configured identically for me.
[21:42] <cody-somerville> vagrantc, can you try making a commit?
[21:46] <vagrantc> cody-somerville: ok, pushing ...
[21:49] <cody-somerville> vagrantc, I got notified. Did you?
[21:50] <vagrantc> cody-somerville: i'm checking... Ryan52 was also experiencing the problem
[21:51] <vagrantc> cody-somerville: well, i got that one. though nothing between 1140 - 1150 ...
[21:52] <vagrantc> cody-somerville: and 1150 was committed just a short while earlier
[21:52] <cody-somerville> vagrantc, is it possible you simply missed them in your inbox?
[21:52]  * Ryan52 doubts that me and vagrantc would both miss the same exact 10 emails..
[21:52] <vagrantc> cody-somerville: pretty doubtful
[21:53] <vagrantc> cody-somerville: perhaps you subscribing to it somehow corrected the problem?
[21:53] <cody-somerville> Tough to say
[21:53] <vagrantc> cody-somerville: well, thanks for looking at it ... it appears to be working now, in any case. :)
[21:53] <cody-somerville> :)
[21:53] <cody-somerville> np
[21:53] <vagrantc> i've gotta run...
[22:02] <fta> http://launchpadlibrarian.net/24546525/cb1TWHeZAb1ZYclOUas44ivnbEl.txt
[22:03] <wgrant> fta: Known - cprov's working on it.
[22:04] <wgrant> fta: The package built fine, and the binaries will be in the archive already, so you can ignore the error.
[22:04] <fta> wgrant, ok, thanks
[22:05] <cprov> fta: crap-crap-crap! Sorry for this inconvenience, I'm working on it.
[22:05] <fta> cprov, np :)
[22:06] <wgrant> cprov: buildd-manager is racing with itself?
[22:07] <cprov> wgrant: sort of, it's waiting for a db update that never happens.
[22:09] <wgrant> cprov: I don't see how that can cause it to retry the build, but okay.
[22:10] <cprov> wgrant: a collected build is not updated, so it's still pending and is dispatched again.
[22:11] <wgrant> cprov: Oh, ouch.
[22:11] <cprov> wgrant: yes, pretty much it ;)
[23:36] <wgrant> cprov: I just had a thought about multiple PPA key naming - why do they have different keys at all?
[23:37] <cprov> wgrant: different repositories
[23:37] <wgrant> cprov: Controlled by the same set of people, which removes a big reason to have them split.
[23:38] <wgrant> But there's probably another few good reasons to have them split, and it was just a quick thought on how to resolve this issue.
[23:38] <cprov> wgrant: I can see some few cases where sharing signing-keys would be beneficial
[23:39] <cprov> for instance ubuntu primary and partner share a key
[23:39] <wgrant> Erk, I have to run to catch a bus to uni that leaves in 4 minutes.
[23:39]  * wgrant -> gone
[23:39] <cprov> wgrant: but for the vast majority of cases, independent keys is the safest path
[23:40] <cprov> wgrant: talk to you later ;)
[23:45] <maxb> I get the point of using separate keys for separate trust domains.... but when the entity you are trusting is identical in either case... that suggests separate keys are not actually a win
[23:50] <fta> cprov, should i retry my builds or just wait?
[23:51] <cprov> fta: you probably don't have to retry them, they were already successfully built and uploaded the first time they got dispatched
[23:52] <cprov> fta: the second dispatch messes with the build status, only, but the original binaries should be published already
[23:52] <cprov> fta: what's the build URL ?
[23:52] <fta> cprov, the page is still red
[23:53] <fta> here is one https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/924017
[23:55] <cprov> fta: but the resulting binaries are in LP (the second portlet)
[23:56] <cprov> fta: I will fix it, one sec


[04:19] <mup> Bug #1413829 changed: maas created wrong interfaces file <MAAS:Expired> <https://launchpad.net/bugs/1413829>
[09:32] <mup> Bug #1438087 was opened: Inconsistent page headings <ui> <ux> <MAAS:New for ricgard> <https://launchpad.net/bugs/1438087>
[09:32] <mup> Bug #1438090 was opened: interaction on image listing should be in action panel <ui> <ux> <MAAS:Confirmed for carlaberkers> <https://launchpad.net/bugs/1438090>
[09:32] <mup> Bug #1438091 was opened: fix spacing on table on image listing page <MAAS:New for ricgard> <https://launchpad.net/bugs/1438091>
[10:02] <mup> Bug #1438102 was opened: text alignment on dropdown buttons <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1438102>
[10:02] <mup> Bug #1438105 was opened: Vertical divider between tabs missing on node listing <MAAS:New for ricgard> <https://launchpad.net/bugs/1438105>
[10:02] <mup> Bug #1438109 was opened: styling for sort on node listing doesn't yet match designs <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1438109>
[10:39] <mup> Bug #1438119 was opened: node is selected when clicking node name <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1438119>
[12:48] <mup> Bug #1437094 changed: Sorting by mac address on webui causes internal server error <cts> <sts> <MAAS 1.7:In Progress by rvb> <https://launchpad.net/bugs/1437094>
[14:27] <mup> Bug #1438218 was opened: django.db.transaction.TransactionManagementError: raised when deploying multiple nodes in the UI <MAAS:Triaged> <https://launchpad.net/bugs/1438218>
[16:09] <mup> Bug #1438291 was opened: node details: add line numbers to machine output <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1438291>
[16:11] <kiko> wikityler, it can be used to deploy any ubuntu image, really
[18:13] <nocker> hi
[18:14] <nocker> I have extended django web interface to be able to manage tags from the web interface
[18:14] <nocker> create/update/delete tags
[18:14] <nocker> I have thought that could be useful to add in the code
[18:15] <nocker> but I'm bit lost in how to colaborate
[20:24] <jrwren> if I edit the only network defined in maas at http://maas.jujugui.org/MAAS/networks/maas-eth1/edit/  should I see /etc/maas/dhcpd.conf be updated with that information?
[20:48] <roaksoax> jrwren: you need to change the cluster controller page instead
[20:49] <jrwren> roaksoax: thanks.
[20:51] <jrwren> One or more clusters are currently disconnected. Visit the clusters page for more information.
[20:51] <jrwren> but there is no more info.
[20:54] <roaksoax> jrwren: is the maas cluster running?
[20:54] <roaksoax> jrwren: maas-clusterd
[20:55] <jrwren> roaksoax: nope
[20:55] <jrwren> thanks roaksoax now I know where to look.
[20:56] <jrwren> err, well the twisted process is runing.
[20:57] <roaksoax> jrwren: check the logs /var/log/maas/
[20:58] <jrwren> roaksoax: checked. address changed and it is trying the old address. I hope restarting maas-clusterd fixes it.
[20:59] <jrwren> hrm, nope still the wrong address.
[20:59] <roaksoax> jrwren: dpkg-reconfigure maas-cluster-controller
[21:00] <jrwren> oooh, fancy!  :)
[21:00] <jrwren> thank you
[21:01] <jrwren> roaksoax: that fixed it. Thanks again.
[21:04] <roaksoax> jrwren: glad to help
[21:11] <jrwren> hrm... i spoke to soon. that made the cluster connectable, but the log shows something trying siple streams at the old address
[21:13] <mup> Bug #1438428 was opened: [SRU] New upstream Release 1.7.2 <maas (Ubuntu):New> <https://launchpad.net/bugs/1438428>
[21:13] <jrwren> oh for goodness sake. hosts < dns :(
[21:14] <roaksoax> jrwren: dpkg-reconfigure maas-region-controller
[21:16] <jrwren> ah, yup, that is another place the wrong address was.
[21:16] <jrwren> /etc/maas/dhcpd.conf still has wrong  option domain-name-servers
[21:20] <roaksoax> jrwren: save the cluster controller config again
[21:20] <roaksoax> that should fix it
[21:25] <mup> Bug #1438428 changed: [SRU] New upstream Release 1.7.2 <maas (Ubuntu):New> <https://launchpad.net/bugs/1438428>
[21:37] <mup> Bug #1438428 was opened: [SRU] New upstream Release 1.7.2 <maas (Ubuntu):New> <https://launchpad.net/bugs/1438428>
[21:39] <jrwren> I did that and no go, but setting upstream dns http://maas.jujugui.org/MAAS/settings/  triggered it *shrug*
[21:43] <mup> Bug #1438428 changed: [SRU] New upstream Release 1.7.2 <maas (Ubuntu):Fix Released> <maas (Ubuntu Trusty):New> <maas (Ubuntu Utopic):New> <https://launchpad.net/bugs/1438428>
[23:06] <AskUbuntu> Is MasaS, juju, or the charm responsible for ssh-keygen on nodes? | http://askubuntu.com/q/603317


[01:58] <fallenour__> o/
[01:58] <fallenour__> juju didnt build my openstack ceph-osd systems as expected
[01:59] <fallenour__> I ran the juju config ceph-osd=/dev/sdb,/dev/sdc,/dev/sdd , etc command,but I dont see a change yet for application. does it require a reboot, or do I need to rebuild?
[02:22] <fallenour__> changed the config file with juju config ceph-osd osd-devices=/dev/sdb,/dev/sdc,/dev/sdd, etc, but I dont see the changes yet. do I need to reboot something, or am I going to have to rebuild?
[04:03] <burton-aus> wallyworld ping
[04:05] <burton-aus> axw ping
[04:05] <axw> pong
[04:06] <axw> burton-aus: what's up?
[04:06] <burton-aus> axw would you help to take a look at this PR? https://github.com/juju/juju/pull/7949
[04:06] <burton-aus> axw so I can merge it.
[04:06] <axw> burton-aus: LGTM
[04:07] <burton-aus> axw OK, and do I have the green light to proceed the release process, given that the unit test failed again in a re-run, as described in my email sent out?
[04:08] <burton-aus> axw I'm about to launch the release CI job now, so this is the last chance to abort.
[04:09] <axw> burton-aus: yeah, that failure just needs a backport of the fix for go 1.9
[04:09] <axw> burton-aus: it only affects tests
[04:11] <burton-aus> axw OK, release CI job triggered.
[06:01] <Soumaya> Hi , I have a query related to Juju deployment . We are working on integration of EPC bundle on opnfv and we have to run juju client on alpine docker .
[06:02] <Soumaya> Is there any way to run juju client on alpine or any api available to bootstrap a new controller from alpine
[06:03] <Soumaya> I have gone through python juju api but I have not see any bootstrapping api .
[06:32] <junaidali> Hi everyone, is it necessary to set python3 as default for juju-wait to work?
[06:34] <junaidali> I'm facing the following error when `juju wait` is run: AttributeError: 'module' object has no attribute 'which'
[06:35] <junaidali> at this line -> https://git.launchpad.net/juju-wait/tree/juju_wait/__init__.py#n102
[07:40] <stub> junaidali: How are you installing juju-wait? The deb package and snap should not have that problem. juju-wait does require Python3.
[09:36] <junaidali> stub: I'm installing with pip
[09:36] <junaidali> Haven't tried with deb/snap. I will try it now
[09:40] <junaidali> Deb is working fine. Thanks
[09:44] <junaidali> stub: I have installed the package with this ppa -> 'ppa:stub/juju'. Let me know please if there is any other ppa to use.
[10:00] <stub> junaidali: yes, that is the correct PPA. Maybe it should go into one of the Juju ones one day.
[10:01] <stub> junaidali: Pip will work, but you need to use pip3 to install it with the correct Python version. Or into a Python3 virtualenv.
[11:01] <junaidali> Thanks stub:
[13:37] <EnvY> hello, i am working on juju for my application to scale, however, i want new nodes will be deployment depends on coming traffic on my charm. can anybody help please
[13:55] <pmatulis> EnvY, you want to be able to add more units if necessary?
[13:57] <EnvY> while following the documentation i find that using a load balancer we can scale up or down
[13:57] <EnvY> but it mean that those instance are deployed on lxd container and load balancer is balancing those resources
[13:58] <EnvY> haproxy
[14:00] <EnvY> i have followed this link to deploy
[14:00] <EnvY> https://jujucharms.com/docs/1.25/charms-scaling
[14:01] <EnvY> and with add-unit we are adding instances
[14:06] <pmatulis> EnvY, eww, you are using juju 1.25 ?
[14:08] <EnvY> juju add-unit -n5 mediawiki
[14:08] <EnvY> 2.0.2
[14:09] <pmatulis> EnvY, what operating system? if Ubuntu, and you're starting out, best go with 2.3, which will soon be released
[14:10] <EnvY> yeah it ubuntu 16.04
[14:10] <EnvY> is this option is available in juju or we have to use OSM
[14:12] <EnvY> i think i get the answer
[14:13] <magicaltrout> hello lovely jujuers
[14:13] <magicaltrout> k8s stack manual deployment all green but kubectl get nodes is empty
[14:13] <pmatulis> EnvY, what option? 2.3?
[14:14] <magicaltrout> any ideas?
[14:15] <EnvY> pmatulis, i will definitely switch to latest stable release. i get the solution of my question of scaling
[14:16] <pmatulis> EnvY, ok good
[14:16] <pmatulis> EnvY, 2.3 will be stable soon so you might want to start with the beta, at least for testing
[14:17] <EnvY> ok
[14:18] <pmatulis> EnvY, it has improvements in storage (dynamic) and the ability to relate applications across different models/controllers/clouds
[14:18] <EnvY> Oh, thats very good
[18:40] <admcleod_> is there a variable for timeout for machine provisioning?
[19:37] <fallenour> getting an error: backups are not supported for hosted models. havent seen that before. any thoughts/
[19:44] <fallenour> Potential Bug: https://bugs.launchpad.net/juju/+bug/1576184    Is there a status update on this bug other than whats posted here?
[19:44] <mup> Bug #1576184: "juju create-backup" fails if you're not operating on the admin model  <docteam> <ensure-availability> <juju-release-support> <usability> <juju:Triaged> <https://launchpad.net/bugs/1576184>
[19:44] <fallenour> Im operating as admin, with admin on all models