[08:54] <jamespage> rbasak, morning - sage wants to discuss apache in 12.04 (and 14.04) with the proposed mod-proxy-fastcgi switch upstream in ceph tomorrow afternoon
[08:54] <jamespage> are you around?
[10:08] <lordievader> Good morning.
[13:00] <koolhead17> sahara package is not available for ubuntu
[13:00] <koolhead17> is it?
[13:01] <koolhead17> http://docs.openstack.org/juno/install-guide/install/apt/content/sahara-install.html << As per the doc
[13:57] <Kartagis> mkswap: /var/swap.img: warning: don't erase bootbits sectors on whole disk. Use -f to force. <--- should I be concerned?
[13:59] <jamespage> rbasak, https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.23-0ubuntu1
[13:59] <jamespage> that's a big changelog entry :-)
[14:01] <zul> jamespage:  did you have any changes for nova b2?
[14:01] <jamespage> zul, nope - I rebased my power sync patch upstream
[14:16] <rbasak> jamespage: :)
[14:17] <rbasak> jamespage: it fails dep8 though. I still need to look at it.
[14:17] <rbasak> (it passed locally :-/
[14:21] <Kartagis> can you help me please?
[14:22] <jamespage> zul, lets see if we can unstick proposed today
[14:22] <zul> jamespage:  sure
[14:22] <jamespage> zul, I think nova/eventlet is the primary cause
[14:23] <zul> jamespage:  just uploaded a new nova
[14:23] <jamespage> zul, I need something mindless todo so I'll work through some of the oslo. -> oslo- changes as well
[14:23] <jamespage> at least in deps - not in core openstack packafges
[14:51] <hallyn> smb: hey - have you looked in detail at the reply to "[libvirt] [PATCH/RFC] Add missing delta from Ubuntu to apparmor profiles" ?
[14:53] <smb> hallyn, No, not yet. It was so long ago that I need to read up a lot. Which I thought of maybe doing next week when I finished up things I want to get done first
[14:54] <coreycb> arges, just a reminder that horizon is uploaded for juno
[14:55] <arges> coreycb: Thanks. I didn't check when I EODed yesterday
[14:56] <hallyn> smb: ok thx
[15:01] <arges> coreycb: ok done
[15:02] <coreycb> arges, thanks!
[15:28] <smoser> hallyn, around ?
[15:28] <smoser> question on bug 1418221
[15:29] <hallyn> smoser: here
[15:29] <hallyn> i dont' care, you want me to add qemu-kvm link on ppc?
[15:30] <smoser> it seems that a link of 'qemu-kvm' -> qemu-system-ppc64 would reportedly fix this.
[15:30] <smoser> what do you think ?
[15:30] <smoser> i wouldn't do it for ppc64 only. it would make sense for that link to point on all arch to "the default qemu"
[15:30] <smoser> and apparently one such thing exists in fedora
[15:30] <hallyn> ?
[15:31] <hallyn> well qemu-kvm package exists on ppc64 and ppc64el,
[15:32] <smoser> what does it do ?
[15:32] <hallyn> ifneq ($(filter $(DEB_HOST_ARCH),ppc64 ppc64el powerpc),) install -D -m755 debian/kvm.powerpc debian/qemu-kvm/usr/bin/kvm
[15:32] <hallyn> endif
[15:33] <hallyn> what happens when you install qemu-kvm on ppc64el?
[15:33] <hallyn> and who's the asshat who thought it should be ppc64le in some places and ppc64el in others
[15:34] <smoser> dpkg arch is el. kernel arch is le.
[15:34] <smoser> you have to blame debian for selection of that name for dpkg arch.
[15:34] <arges> is it some kind of meta endian joke to have those different arch names?
[15:35] <smoser> it is.
[15:35] <arges> fun times
[15:35] <smoser> "hey lets be funny by making pain for people!"
[15:35] <zul> jamespage:  hey there shouldnt be a nova-compute.upstart.in anymore should there?
[15:35] <arges> haha
[15:38] <smoser> beisner, so how does qemu-system-ppc end up on a nova-compute node ?
[15:38] <smoser> is that the nova-compute charm that installs it? it looks like maybe we might be able to just have it install qemu-kvm also.
[15:38] <smoser> jamespage, ^ is that appropriate?
[15:39] <beisner> smoser, i don't have the ppc64el compute node up atm, but will in a while.  then i can check into when/where it enters the picture.
[15:42] <smoser> ok. thanks.
[15:44] <jamespage> zul, there should be yes
[15:44] <jamespage> conditional start on libvirt
[15:44] <zul> jamespage:  ok just checking
[15:45] <jamespage> smoser, I think its a dep from nova-compute-kvm
[15:45] <jamespage> zul, ^^ - might be another change for you to include
[15:45] <jamespage> but don't hold for it
[15:46] <hallyn> smoser: ok if it turns out kvm is not being installed by qemu-kvm package pls let me know
[15:53] <smoser> looks like the package nova-compute-kvm suggests qemu-kvm
[15:53] <smoser> so it doesnt get installed by default
[15:54] <smoser> hm..
[15:56] <smoser> if we're going to continue to let libvirt depend on a symlink/shell-wrapper rather than more explicitknowledge of ppc64el, then we will need some way to ensure that users dont install libvirt and qemu-system-ppc64 without getting that link.
[15:58] <beisner> smoser, fyi just kicked off ppc64 deploy;  will touch base soon.
[15:59] <smoser> it really seems like just installing qemu-kvm will do it.
[15:59] <smoser> so try that first (instead of symlink)
[16:16] <beisner> ack
[16:27] <jamespage> coreycb, zul: taskflow uploaded
[16:27] <jamespage> 0.7.0
[16:27] <jamespage> coreycb, zul: something in pypi has changed which means uscan and watch files are broken
[16:27] <jamespage> its really annoying
[16:30] <jamespage> zul, I see this as well
[16:30] <jamespage> W: cinder source: virtual-package-depends-without-real-package-depends build-depends-indep: python-oslo-config
[16:30] <jamespage> I thought the last fix I did for oslo-config should resolve that but apparently not
[16:30] <zul> ergh
[16:34] <mfisch> hey zul or jamespage whats the ETA on Juno.2 in UCA?
[16:34] <jamespage> mfisch, we are working through it now
[16:34] <jamespage> mfisch, probably all in by the end of next week
[16:34] <mfisch> thanks
[16:34] <jamespage> mfisch, quite a bit todo still
[16:35] <jamespage> mir's and stuff will block mostly
[16:35] <mfisch> we'll plan on moving to it when it lands
[16:35] <med_> thanks jamespage
[16:35] <mfisch> Openstack was forced to use mir also? ;)
[16:35] <med_> sort of  but also sort of have a Get Out of Jail Free card
[16:36] <med_> I guess if it brought in a dep that really needs to go NOT IN the UCA, that peice would have to be MIRed
[16:37] <med_> not the space station, not the display, the MAIN INCLUSION REQUEST
[16:37]  * mfisch was bringing up memories of being on the desktop side of things at Canonical
[16:39] <jamespage> med_, mfisch - you guys wanted openstackclient in the UCA right?
[16:39] <jamespage> its there now but under the same terms as universe
[16:39] <mfisch> yep thats great
[16:39] <mfisch> we're fine unsupported on it
[16:39] <jamespage> we're about to annotate that archive in the same way as ubuntu as to what's supported by canonical and what's not
[16:40] <jamespage> mfisch, good-oh
[16:40] <mfisch> perfect
[16:40] <med_> jamespage, many thanks!
[16:40] <mfisch> what about labels for the repos?
[16:40] <med_> Label: filterable in pinning
[16:40] <med_> (in the Releases file)
[17:15] <med_> hey jamespage trad511 has some OVS questions
[17:16] <smoser> hallyn, having libvirt call kvm (or qemu-kvm) rather than appropriately named doesnt work.
[17:16] <smoser> http://paste.ubuntu.com/10190884/
[17:16] <smoser> due to apparmor denial
[17:19] <trad511> jamespage: having a need in openstack ovs to set interface mtu, do l3 configs etc and wondering if the ubuntu /etc/network/interfaces ovs support is the "proper" way to do it.  also using puppet vswitch module through puppet-neutron
[17:23] <rbasak> frediz, leitao: http://dep.debian.net/deps/dep8/
[17:23] <rbasak> frediz, leitao: http://dep.debian.net/deps/dep3/
[17:25] <rbasak> frediz: 1.4.0~rc1 < 1.4.0
[17:26] <rbasak> s/-rc/~rc/
[17:30] <hallyn> smoser: oh, interesting.
[17:30] <hallyn> arges: ^
[17:31] <arges> hallyn: whats interesting?
[17:31] <hallyn> arges: the powerpc kvm script can't ever have worked bc of apparmor
[17:31] <hallyn> well, not through libvirt
[17:32] <arges> hallyn: yea i've usually modprobed manually
[17:32] <hallyn> no, i mean /usr/bin/kvm (kvm.powerpc)
[17:32] <hallyn> it calls awk which libvirt doesnt' allow qemu to do
[17:32] <arges> hallyn: wierd. i swear libvirt on power8 was working for me last i tried it
[17:32] <hallyn> trying to think whether we shoul dhave an apparmor sub-profile for kvm or not
[17:33] <hallyn> arges: using libvirt?
[17:33] <arges> hallyn: yea
[17:34] <hallyn> so, we could update kvm.powerpc to use only shell-isms
[17:35] <smoser> i dont even know if that is sufficient, hally.
[17:35] <smoser> hallyn, i
[17:36] <hallyn> or just add /bin/awk rmix, to the libvirt-qemu template
[17:36] <smoser> i tried a while ago, and i think even the exec means loading a executable which wasnt in the profile that is crafted based on the xml.
[17:36] <hallyn> smoser: that can't be, we do that now in /usr/binkvm
[17:36] <smoser> oh?hm..
[17:37] <hallyn> yeah the libvirt-qemu template grants exec permission to /usr/bin/qemu-system-ppc{,64}
[17:38] <arges> hallyn: fwiw this is how I've been doing power8 kvm testing http://pastebin.ubuntu.com/10191161/
[17:38] <smoser> sudo ln -sf qemu-system-ppc64 /usr/bin/qemu-system-ppc64le
[17:39] <smoser> ^ that seems to me to maybe be the best thing at the moment.
[17:39] <beisner> smoser, ok, we have a freshly deployed enviro up, ppc64el compute node w/ trusty hwe-u + kilo-proposed.
[17:39] <beisner> qemu|libvirt|kvm  dpkg info to start:   http://paste.ubuntu.com/10191119/
[17:39] <hallyn> arges: yes but uvt-kvm starts it as /usr/bin/qemu-system-$arch, not as /usr/bin/kvm
[17:39] <arges> hallyn: then that makes sense why i wasn't hitting the issue
[17:40] <smoser> beisner, oh fiddle.
[17:40] <smoser> i forgot you had to use my ppa to get a 1.2.12
[17:40] <smoser> as cloud archive is behind
[17:40] <hallyn> smoser: so if you add /bin/uname rmix and /bin/cat rmix to /etc/apparmor.d/abstractions/libvirt-qemu, does that work?
[17:42] <smoser> maybe. but i wouldnt htink you'd want to add cat.
[17:42] <hallyn> why?
[17:42] <hallyn> oh i meant awk
[17:43] <smoser> i wouldnt want to addeither
[17:43] <hallyn> feel free to update the scrip tinstead :)
[17:43] <hallyn> mr sh
[17:43] <smoser> i guess its nto that bad.
[17:43] <smoser> i wouldn thtink youd want to add them as they're an attack vector
[17:43] <hallyn> awk we could do with IFS< uname i don't know
[17:43] <smoser> awk for sure can arbitrarily execute code
[17:43] <smoser> would seem non-ideal from apparmor perspedtive, no ?
[17:44] <beisner> smoser, shall i install these, should be pre-patch:  https://launchpad.net/ubuntu/+source/libvirt/1.2.12-0ubuntu2/+build/6955199
[17:44] <hallyn> it'll remain confined
[17:44] <smoser> right.
[17:44] <thor77> any recommendations for a cheap hoster, where i can pay by bank transfer (from germany)?
[17:44] <thor77> is there some offtopic-channel where i should ask this question?
[17:45] <smoser> thor77, you mgiht get an answer, you might not. i dont know.
[17:45] <thor77> Smark: k
[17:45] <thor77> smoser: k
[17:45] <smoser> vultr maybe , digital ocean, but i'm sure you cnsidered those.
[17:45] <smoser> (i have no idea on bank payment from germany)
[17:45] <smoser> beisner, well , those are built for vivid.
[17:45] <beisner> sure enough!
[17:46] <smoser> so they're not going to be nice. the value of my ppa was in gettin getting the cloud-archive backport for trusty.
[17:47] <beisner> and kilo-staging in ca has 1.2.12-0ubuntu3 - which has the patch we want to not-try, correct?
[17:48] <thor77> smoser: both doesnt provide pay by bank transfer :(
[17:48] <smoser> beisner, well, that and it doesn't (staging) build ppc64el
[17:48] <smoser> so thats not helpful :)
[17:48] <beisner> oh fiddle indeed then.
[17:48] <smoser> beisner, i'll build some.
[17:49] <beisner> smoser, ok thanks - just holler.  will leave that deployment untouched.
[17:56] <beisner> almost too many cpus for my screen.  http://i.imgur.com/LHeOa3u.png
[18:25] <smoser> hallyn, http://paste.ubuntu.com/10191769/
[18:25] <smoser> that is pure shell, but ditches the uname -m usage. which id ont thikn you want.
[18:26] <Odd_Bloke> beisner: My favourite part of that is the swap; that'll make all the difference. ;)
[18:39] <smoser> beisner, ok. so there are some debs in ~smoser/libvirt-builds on lescina
[18:39] <hallyn> smoser: what does /proc/cpuinfo look like o npower?
[18:40] <hallyn> eh, i won't second-guess you :)
[18:40] <smoser> http://paste.ubuntu.com/10191988/
[18:41] <smoser> oh. and hm..
[18:41] <smoser> that is possibly something you dont want to parse with shell rpeatedly
[18:41] <smoser> oh. but not so bad.
[18:41] <smoser> as we get out early.
[18:42] <smoser> but the uname stuff is lost.
[18:42] <smoser> you were making decision based on kernel uname, an i dont know a good way to do that without using uname
[18:43] <ewook> Gawd... So bored!
[18:43] <hallyn> smoser: ok, i'm going to switch to yours then, thx
[18:43] <smoser> what about uname thoug h?
[18:44] <smoser> oops. and need trilaing ';' on that last case line
[18:44] <hallyn> I see a trailing ;
[18:45] <hallyn> smoser: well, i'm not sure 'uname -m' was the right thing ot use anyway
[18:46] <hallyn> i.e. run uname -m under 'i386'
[18:46] <smoser> it really should have 2 ';';
[18:46] <smoser> er.. 2: ;;
[18:46] <hallyn> oh
[18:46] <smoser> for case
[18:49] <hallyn> arges: http://paste.ubuntu.com/10191769/  does that look ok to you?
[18:50] <hallyn> arges: btw, i've been assuming you came up with th eoriginal kvm.powerpc.  maybe i'm wrong? did infinity do it?
[18:50] <arges> hallyn: i didn't do it
[18:50] <hallyn> sorry then :)
[18:50] <hallyn> mwhudson: \o
[18:51] <arges> hallyn: so why would -ppc be the default instead of -ppc64?
[18:51] <arges> seems like ppc64 hardware is the most common
[18:51] <hallyn> dnno, for safety?
[18:52] <arges> i guess ppc can be run on 64-bit kernel..
[18:52]  * hallyn hops over to ubuntu-devel
[18:53] <arges> hallyn: i guess i would have been lazy and just relied on grep instead of doing the read line loop
[18:54] <hallyn> arges: grep not allowed by apparmor
[18:54] <hallyn> but anyway smoser doesn't whimp out on leg day :)
[18:54] <arges> hallyn: hmm... i might need to modify my virt-detection script then
[18:55] <hallyn> isn't that only for the init script?
[18:55] <hallyn> that doesn't run under apparmor
[18:55] <arges> ah ok
[18:56] <smoser> i dont know about qemu-systme-ppc being default. i
[18:57] <smoser> i'd be fine to have ppc64 the default. unless theres some obvious system thing. that says otherwise.
[18:57] <smoser> i really have no idea what that would be
[18:57] <smoser> hallyn, what would you think about a symlink qemu-system-ppc64le to qemu-system-ppc64
[18:57] <hallyn> smoser i've got some other things to push so for now gihtub.com/hallyn/qemu #ubuntu-dev has your current script.  we can update it there (i'll rebase later) as we ahve better ideas
[18:57] <hallyn> smoser: i have no idea
[18:58] <smoser> that would also fix our problem
[18:58] <hallyn> seems fine
[18:58] <hallyn> will there ever be a separate binary?
[18:58] <smoser> it doens't seem like the direction
[18:58] <smoser> ie, i dont knwo why there'd be a different binary
[18:58] <smoser> when they're emulating the same system.
[18:58] <smoser> ie, there really isnt a "ppc64el" hardware, and qemu is a hardware emulator
[18:58] <hallyn> ok, i'll add the link
[19:03] <smoser> hallyn, just to be clear, the link would be qemu-system-ppc64le -> qemu-system-ppc64
[19:03] <smoser> "le" not "el"
[19:03] <smoser> so we dont fall victim to that funny joke.
[19:05] <hallyn> smoser: I added "usr/bin/qemu-system-ppc usr/bin/qemu-system-ppc64le" to qemu-system-ppc.links
[19:06] <smoser> wait. thats wrong.
[19:06] <hallyn> oh?
[19:06] <smoser> $ ls -l /usr/bin/qemu-system-ppc64le
[19:06] <smoser> lrwxrwxrwx 1 root root 17 Feb 12 19:00 /usr/bin/qemu-system-ppc64le -> qemu-system-ppc64
[19:06] <hallyn> bc that should be 64?
[19:06] <smoser> thats what we want.
[19:08] <hallyn> s oi'm not sure if i ca nhave the .links entry just be "qemu-system-ppc64 usr/bin/qemu-system-ppc64le" or if the first should be prepended by usr/bin anyway
[19:09] <hallyn> but i'll do a test build
[19:09] <hallyn> after i add arges' other fix for 1414153
[19:17] <beisner> Odd_Bloke, you'd be surprised.  I actually made it go swappy with 250-some instances fired up.
[20:18] <Odd_Bloke> beisner: :D
[21:22] <smoser> hallyn, did you drop my hack patch in your upload ?
[21:30] <hallyn> smoser: which upload?
[21:31] <hallyn> oh, no,  i'm still test-building.  should i drop it?
[21:31] <hallyn> em
[21:31] <hallyn> oh that's libvirt
[21:31] <hallyn> no it's still in there.  so do yo uwnat me to do another upload droppin ghtat?
[21:35] <smoser> hallyn, yeah, get rid of that patch. i never really intended for it to be included.
[21:38] <hallyn> ok
[21:38] <hallyn> sorry :)
[21:39] <hallyn> the symlink should fix it?
[21:41] <hallyn> smoser: look ok?  lrwxrwxrwx 1 ubuntu ubuntu      17 Feb 12 21:32 qemu-system-ppc64le -> qemu-system-ppc64
[22:13] <smoser> looks good, hallyn
[22:52] <nch_> hello, do you know any solution for setting up a dns name based ftp reverse proxy?
[22:55] <sarnold> nch_: dns protocol doesn't include any server names, that's why there's no name-based ftp virtual hosting like you see with http
[22:59] <nch_> sarnold: so it is impossible? :(
[22:59] <sarnold> nch_: I've never seen it any done before..
[23:00] <sarnold> nch_: ftp is a terrible protocol anyway; what are you trying to accomplish? there's probably something better out there anyhow
[23:02] <nch_> sarnold: I´m using pfsense for securing my internal environment and I have two webservers (one linux and one windows), and on both my customers can upload their content with ftp, so I want a reverse proxy for different internal ftp targets with one public ip, like a reverse http proxy
[23:04] <sarnold> nch_: sftp over ssh ought ot let you get much the same thing done without using multiple IPs