=== tanuki_ is now known as tanuki
[04:20] <wbill> is ssh installed/open by default?
[04:23] <cncr04s> don't think so
[04:23] <cncr04s> there is an option while installing
=== Thorn__ is now known as Thorn
[07:36] <PCdude> I am installing openstack and during the install on a Ubuntu machine I get the following error log
[07:36] <PCdude> http://pastebin.com/raw/A7qtJm4v
[07:36] <PCdude> there is apparently an deployment timeout, but where can I see more information on why it did that or how can I solve it?
[07:43] <lordievader> Good morning.
[07:45] <jamespage> coreycb, ddellav: yakkety branch builds functional again - I had to backport sbuild from yakkety for trusty, and then in-place patch it for compat with dpkg
[09:12] <cpaelzer> stgraber: jamespage: did you also have success with that in regard to a precise kvm running in the container?
[09:12] <cpaelzer> that seems to need "more"
[09:12]  * cpaelzer is trying to unvocer what from that all to silent libvirt/qemu/kvm team
[09:16] <sarthor> Hi, There is no "/etc/network/interfaces and /etc/udev/rules.d/70-persistent-net.rules" . how to create that file, Using ubuntu-server 16.04
[09:17] <cpaelzer> sarthor: maybe all you have is in /etc/network/interfaces.d ?
[09:17] <cpaelzer> sarthor: otherwise "man interfaces" gets you a starting point to write your own file if that is what you want
[09:18] <cpaelzer> sarthor: networkctl might also be a tool to find where your stuff currently is, as on desktop that is responsible for most things
[09:19] <cpaelzer> sarthor: the multitude of network backends ifupdown, networkd, NetworkManager can be a apain - that is what https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html is for
[09:21] <sarthor> cpaelzer: there is not networkctl command or package
[09:23] <sarthor> no*
[09:35] <cpaelzer> sarthor: networkctl is part of systemd
[09:35] <cpaelzer> sarthor: are you running 16.04 server installed from the iso or an upgrade from an older version?
[09:46] <cpaelzer> stgraber: jamespage: step1 a pure qemu works in precise as well, must be libvirt who doesn't want me to like it
=== patsToms_ is now known as patsToms
=== AcuBcn1 is now known as AcuBcn
=== JanC_ is now known as JanC
[10:26] <cpaelzer> stgraber: jamespage: I even got a basic libvirt/virsh based guest to start now - must be some delta between this and the uvt used template
[10:41] <cpaelzer> na not true, was type qemu - type kvm failed
[10:51] <cpaelzer> stgraber: jamespage: it really points to libvirt now, I get the same qemu commandline running that libvirt reports as failing
[10:51] <cpaelzer> so less lxd more libvirt debugging for now
[11:15] <jamespage> ddellav, coreycb: either of you two looked at the barbcian unit test failures?
[11:15] <jamespage> I can't figure out what's going on
[11:30] <roaksoax> 8
[11:34] <coreycb> jamespage, I didn't make any progres on barbican
[11:35] <coreycb> jamespage, I think I got the horizon xstatic patch working but horizon still needs some work
[11:35] <coreycb> jamespage, can you promote heat 1:5.0.1-0ubuntu3.1~cloud1 and neutron 2:7.1.2-0ubuntu1~cloud0 to liberty-proposed?
[11:36] <jamespage> coreycb, I went and asked in openstack-barbican
[11:36] <jamespage> lets see
[11:38] <coreycb> jamespage, thanks for fixing up the yakkety branch builds
[11:38] <jamespage> coreycb, its ugly but works
=== pavlushka is now known as Guest70016
[12:38] <cpaelzer> stgraber: jamespage: fyi I got it working, qemu-kvm worked right away - the issue with libvirt back in precise was that it runs as a different user and with that it was unable to run. Setting group=root in /etc/libvirt/qemu.conf was enough
[12:39] <cpaelzer> stgraber: jamespage: there might be some lxd magic to do this via the profile as well, but I wanted to let you know in case someone else asks again
[12:52] <jamespage> coreycb, ddellav: newton-staging passes a smoke test - promoting what we have now to -proposed
[12:54] <coreycb> jamespage, sounds good
[12:55] <jamespage> coreycb, I had to wedge fixes into n-gateway and n-api for misc bits
[12:55] <jamespage> but it works ok
[12:57] <coreycb> jamespage, alright I'm going to put some focus on horizon today.  seems a bit busted since b2.
[12:57] <jamespage> coreycb, ok
[13:22] <cpaelzer> rbasak: ever  ran into the issue that uvt creates a "too new" qcow2 image?
[13:23] <cpaelzer> for 12.04
[13:23] <cpaelzer> well ut is only in a ppa for 12.04 so you let me know how much you consider it supported anyway
[13:24] <cpaelzer> it seems that it creates disks with lazy_refcounts when driven by the python interface
[13:24] <cpaelzer> and the qemu in 12.04 isn't new enough to understand that
[13:25] <patdk-wk> 12.04 only has a few months left on it
[13:26] <cpaelzer> consider it passion that I still try to care :-)
[13:30] <coreycb> jamespage, nm horizon looked ok in b2, must just be b3 that's busted.
[13:30] <jamespage> coreycb, ugly?
[13:31] <coreycb> jamespage, slightly :)  it could be an issue with the xstatic patch.  I'll dig some more.
[13:36] <rbasak> cpaelzer: good timing, I'm working on uvtool right now.
[13:37] <rbasak> cpaelzer: sounds like a valid bug, and I'd take a patch to detect 12.04 and supply the right parameter to create an older qcow if you care to write one.
[13:39] <cpaelzer> rbasak: I never worked with the python libvirt interface before - what is the timing you would need that patch?
[13:39] <cpaelzer> I'd know the commandline qemu-img arg right now :-)
[13:39] <cpaelzer> but not how I would have (if I even can) tweak it in the python based image creation
[13:41] <rbasak> cpaelzer: no particular rush. I intend to push my current work to Launchpad (and move from bzr to git) but not upload to Ubuntu until next cycle. But I hope to get build recipes working for all supported Ubuntu releases so the PPA will be a place to get the new stuff in advance of an Ubuntu upload.
[13:41] <rbasak> cpaelzer: one concern might be that I don't inadvertenly break anything for 12.04 in the updates I'm working on right now.
[13:43] <rbasak> cpaelzer: thinking about it, detecting the right versions of qemu would probably be better than trying to detect the right Ubuntu release.
[13:46] <cpaelzer> rbasak: I opened bug 1620633 so we can channel and document our discussion/decision there
[13:46] <ubottu> bug 1620633 in uvtool (Ubuntu) "qcow image created in precise is not usable" [Undecided,New] https://launchpad.net/bugs/1620633
[13:47] <cpaelzer> I'm torn between "let's do it" and "is it still worth"
[13:47] <cpaelzer> If there is a silly fast local workaround that would come to our mind I'd prefer that I thnik
[13:47] <cpaelzer> but then I lack the pytohn libvirt skill to see the workaround clearly
[13:50] <rbasak> cpaelzer: thanks
[13:50] <cpaelzer> rbasak: I'm soon in a series of calls for the next 4 hours so the lp bug is also kind of a mind-fridge for me to not forget it
[13:50] <cpaelzer> oh - only 3 hours - yeah improvment
[13:54] <rbasak> cpaelzer: it looks like it can all be done in the XML - https://libvirt.org/formatstorage.html#StorageVolTarget has the definition, and the compat and feature/lazy_refcounts tags look relevant.
[13:55] <rbasak> cpaelzer: then in uvtool, uvtool/libvirt/kvm.py:create_cow_volume_by_path would be the function to change.
[13:55] <rbasak> I'm not sure how to decide on whether to enable compatiblity mode or not.
[13:56] <cpaelzer> I found the function, thanks for the spec pointer above
[13:57] <cpaelzer> rbasak: I'll hack it in locally to see if it even fixes the issue
[13:57] <cpaelzer> then we can think/decide further
[13:57] <rbasak> OK
[13:57] <cpaelzer> and I take our talk to the bug for now
=== tyhicks` is now known as tyhicks
[14:42] <ddellav> coreycb please review and push the liberty branches of lp:~ddellav/ubuntu/+source/neutron-fwaas lp:~ddellav/ubuntu/+source/neutron-lbaas and lp:~ddellav/ubuntu/+source/neutron-vpnaas, vpnaas didn't have an upgrade but i imported anyway to keep the version number even with the others.
[15:40] <coreycb> ddellav, thanks, neutron-fwaas uploaded.  I think the others aren't needed since they're basically no-ops.
[18:08] <NOVAtechies> hello all
[18:08] <NOVAtechies> i'm in a bit of a pickle
[18:08] <NOVAtechies> I'm running 16.04 with an old R415 and my interfaces are being renamed randomly on reboots to weird names like enps1e0 and stuff like that
[18:09] <NOVAtechies> plus my MACs are being renamed like a4:a4:a4:a4:a4 and the like.
[18:13] <NOVAtechies> I have a feeling that systemd is enjoying messing my system up but I dont' know exactly why this is happening.  my interfaces configs all look good, my rules in /udev/rules.d look good but I can't figure it out.
[18:18] <nacc> NOVAtechies: your MAC is changing? for a physical device?
[18:19] <NOVAtechies> nacc, yep.  I feel like that points to a corrupted file or something.  over in #ubuntu they are suggesting I remap everything in my udev rules and add net.ifnames=0
=== JanC is now known as Guest18007
=== JanC_ is now known as JanC
[18:39] <NOVAtechies> so apparently the net.ifnames=0 fixed what was going on.  black magic wizardy if you ask me...
[18:42] <genii> NOVAtechies: It's a constant interface naming scheme Dell invented. So interfaces always get the same unique identifiers like UUIDS on hard drives
[18:43] <NOVAtechies> ahhh
[18:44] <NOVAtechies> genii, i had no idea that was a Dell problem.  I assumed it was a systemd error again
[18:51] <kbaegis> Hi all.  My openvswitch internal ports get a randomized mac on every reboot
[18:51] <kbaegis> Very annoying problem, as these need to use DHCP
[18:51] <kbaegis> Anyone seen this and come up with a workaround?
[18:52] <kbaegis> Can confirm that this is an issue for anyone running Xenial and openvswitch
[18:59] <seph> http://razorbelle.com/public/HTML/life.html
[18:59] <seph> oops
[18:59] <seph> do you guys use tabs or spaces? i know that python documentation says spaces are "right", but i cant wrap my mind around how someone would prefer spaces to tabs... a space is a space and a tab is an indent, thats what those words mean... to use spaces as tabs violates the meaning of the word "space", uses extra characters and keystrokes, prevents people from customizing the indent size
[18:59] <seph> in their editor to their liking, and is impossible to fuck up and use too many or too few... i dont care what python says, im using tabs lol
[18:59] <Ussat> um....ok
[19:10] <nacc> seph: totally offtopic?
[19:32] <ppetraki> seph, I don't even use tabs in C/C++ anymore, not interested in lining up formatting anymore because there's a mix of tabs & spaces. Form a strong opinion on the subject then tell everyone else they're wrong ;-}
[19:53] <coreycb> jamespage, ddellav: horizon b3 uploaded.  the openstack-dashboard charm needed some templating updates for newton so I'll have reviews incoming for those.
[19:53] <jamespage> coreycb, awesome - thankyou
[19:53] <jamespage> I've been using the newton-b3 topic for reviews
[19:53] <coreycb> jamespage, ok
[20:17] <jerichowasahoax> How do I Kerberize a Postfix server without LDAP?
[20:17] <jerichowasahoax> Because LDAP keeps throwing "invalid credentials" errors at me even though I'm entering my password 100% correctly
[20:20] <kbaegis> Hi all
[20:20] <kbaegis> So what's the appropriate way to set a mac address artificially on boot?
[20:20] <kbaegis> In ubuntu.  Is there an /etc/conf.d/net?
[20:21] <bekks> !info macchanger | kbaegis
[20:21] <ubottu> kbaegis: macchanger (source: macchanger): utility for manipulating the MAC address of network interfaces. In component universe, is extra. Version 1.7.0-5.3 (xenial), package size 186 kB, installed size 677 kB (Only available for linux-any)
[20:21] <kbaegis> bekks: That's not correct.  You can do that with iproute2 as well
[20:21] <kbaegis> I need persistent configuration
[20:21] <kbaegis> Not a 1 off
[20:21] <bekks> kbaegis: I never said that macchanger is the only tool.
[20:21] <kbaegis> bekks: :)
[20:22] <bekks> kbaegis: If you need a persistent configuration, you need to change the PROM of the NIC.
[20:22] <kbaegis> bekks: That's absurd.  You can't run scripts against the interfaces on boot?
[20:22] <bekks> Thats not a persistent configuration.
[20:22] <kbaegis> bekks: There's got to be an init hook
[20:22] <kbaegis> bekks: For our purposes it is :)
[20:23] <bekks> Which isnt persistent, too. Persistent means that you would change the MAC, even when pulling it out of box A and plugin it into box B.
[20:24] <kbaegis> Okay. So you could make it persistent with init scripts, the original mac, and udev rules
[20:24] <kbaegis> I just don't know how this is done on Ubuntu
[20:24] <kbaegis> bekks: semantics of what you mean when you say persistent aside
[20:25] <bekks> kbaegis: If you think so.
[20:25] <kbaegis> So on gentoo we use /etc/conf.d/net
[20:25] <kbaegis> What's the equivalent in Ubuntu?
[20:26] <Sling>  /etc/network/interfaces
[20:26] <kbaegis> I see /etc/network/interfaces.d/, but no templates
[20:26] <kbaegis> Oh, ../interfaces.  k
[20:26] <Sling> (if that's what you mean)
[20:27] <kbaegis> Yeah.  Evidently ovs punts the mac address configuration over to the system, even for internal ports.  That's exactly what I needed
[20:27] <kbaegis> ty
[20:31] <kbaegis> Thanks a lot Sling
[23:09] <Ryan_Lane> hey... did 14.04 switch python to 2.7.12?
[23:09] <Ryan_Lane> because now all of my virtualenvs are complaining that datetime is missing
[23:14] <sarnold> Ryan_Lane: it looks like 14.04 LTS ought to be on 2.7.6-derived python: https://launchpad.net/ubuntu/+source/python2.7
[23:15] <Ryan_Lane> hm. it looks like some package install caused python to somehow upgrade to 2.7.12
[23:33] <Ryan_Lane> bah. someone did an upgrade to 16.04
[23:33] <Ryan_Lane> sorry for the stupid questions :)
[23:34] <sarnold> ha :) that'd be a confusing jump indeed :)