[05:01] <seyeongkim> how can I do SRU process with Trusty Icehouse pkg? ( python-glanceclient, cinder) , I checked https://wiki.ubuntu.com/OpenStack/StableReleaseUpdates but link https://wiki.ubuntu.com/ServerTeam/OpenStack is down
[05:05] <sarnold> seyeongkim: probably you can start with a bug first, that's liable to get noticed..
[05:07] <seyeongkim> There are already. https://bugs.launchpad.net/ubuntu/+source/python-glanceclient/+bug/1323660
[05:11] <sarnold> I can't make heads or tails of any of that... ow
[05:12] <sarnold> It looks a bit like an upstream author gave up on the fix
[05:13] <sarnold> is there a fix? any idea how well it works? does it introduce any new regressiosn?
[05:13] <seyeongkim> for kilo yes,
[05:13] <seyeongkim> I'm not sure whether it can be backported to icehouse.
[05:13] <seyeongkim> https://review.openstack.org/gitweb?p=openstack/python-glanceclient.git;a=commit;h=90407d9e473014c24eeab294192f9d3208f58ea7
[05:14] <seyeongkim> hmm.. so far no regressions..
[05:14] <seyeongkim> but need to be checked because this is accepted from liberty or reject backporting
[05:15] <sarnold> the patch is tiny... is that sufficient?
[05:16] <seyeongkim> yes for glanceclient, and for cinder, https://review.openstack.org/gitweb?p=openstack/cinder.git;a=commit;h=7470b1d66491042909e9a191a884cae2fa8a3838
[05:17] <sarnold> hey that looks complicted enogh to match the complicated bug :)
[05:18] <seyeongkim> I downloaded pkg using pull-lp-source and did patch with quilt-import but debuild -S show me error..
[05:18] <sarnold> seyeongkim: so do you need both patches to be applied simultaneously? do either one in isolation break anything?
[05:18] <seyeongkim> both needed for each pkgs... 1 for glanceclient, 1 for cinder.
[05:18] <seyeongkim> it's seprated.
[06:31] <RustyShackleford> i'm going to set up plex server
[06:31] <RustyShackleford> what do you think about sharing /var/lib/plexmediaserver in a samba share as well?
[06:44] <RustyShackleford> to clarify, is it risky to share that folder with two services?
[07:58] <sikun> RustyShackleford, define risky.
[08:37] <cpaelzer> jamespage: since the DPDK configuration for openvswitch changed so much I'd want to propose some changes to the package
[08:37] <cpaelzer> jamespage: I only start to work but wanted to ask what you'd want
[08:37] <cpaelzer> jamespage: commits into the ovs git you have
[08:37] <cpaelzer> jamespage: same thing as LP merge proposal
[08:37] <cpaelzer> jamespage: debdiffs ...
[08:37] <jamespage> cpaelzer, you're ubuntu-server-dev now right?
[08:38] <cpaelzer> yeah I could commit to the git
[08:38] <cpaelzer> at least I assume so, I never checked what the permissions on it actually are
[08:39] <cpaelzer> jamespage: ^^
[08:41] <cpaelzer> yeah the path is under server-dev
[08:41] <cpaelzer> jamespage: I will prep something there - do you have any in flight changes that I should consider?
[08:41] <jamespage> cpaelzer, that's the one
[08:41] <jamespage> cpaelzer, no I'm all done for this release
[08:42] <cpaelzer> jamespage: ok, I'll ping you once I have something ready for review
[08:43] <cpaelzer> jamespage: do I need beisner for testing a potential upload ?
[08:46] <Village> maybe someone try run DC++ server on Ubuntu..?
[08:48] <jamespage> cpaelzer, no
[08:48] <PCdude> Hi all
[08:48] <PCdude> I have some questions about openstack on ubuntu
[08:48] <PCdude> I have put it in an askubuntu question
[08:48] <PCdude> http://askubuntu.com/questions/832736/openstack-with-autopilot-some-networking-clear-up
[09:02] <sikun> PCdude, so the requirements for OpenStack is actually 5 machines with two hard drives, two machines need dual NICs
[09:04] <sikun> meaning two of the 5 need to have two NICs
[09:25] <RoyK> sikun: shouldn't it work well with VLAN?
[09:27] <RoyK> for Linux it's just another NIC, just named eth0.10 or something and if the bandwidth is sufficient and the switch does its job, well, there you go
[09:28] <sikun> yes, but most guest operating systems still need to fill in the blank for the most part driver wise which is ok but as these VMs will boot via PXE that can be a pain in the ass sometimes when using vlan tagging
[09:30] <RoyK> the host does the tagging
[09:30] <RoyK> it's all L2 stuff
[09:36] <sikun> yes, I know that. Yes, it will work, is it best practice? no.
[09:39] <RoyK> sikun: why not?
[09:39] <RoyK> sikun: if the bandwidth is sufficient... why not?
[09:40] <RoyK> sikun: we have 200 VMs or so on vmware and the hosts all use VLAN tagging on 10+ VLANs
[09:40] <sikun> it's best to separate public/private traffic.
[09:42] <sikun> We have over 500 VMs, public traffic goes on specified NICs for public traffic while private does the same. We also backup utilizing private networking, and if we did that while it was all using a single NIC for public/private it'd bottleneck.
[09:42] <sikun> I say single nic in a broad generalization, of course there is NIC teaming in play.
[09:43] <RoyK> sikun: that's really nonsense - VLAN security is good these days, you really can't break out from a VM
[09:44] <sikun> private networking is in use for management purposes not security
[09:47] <gargsms> I am trying to use CustomLog directive for Apache logs. This is what my declaration looks like `CustomLog "| /bin/grep -E --invert-match --line-buffered 'status:(200|206|302|304)' | sed -r 's/status:(\d*)/\1/' | cat >> /var/log/err.log" combined` This is never written to the file err.log
[10:02] <gargsms> I tried replacing the custom log file names to the ${APACHE_LOG_DIR}/access.log but then it outputs the logs when I restart the apache2 service
[11:48] <Ussat> \o/ patch day done
[13:01] <rbasak> smoser: do you have a simple example of real world use of ssh-attach where not using ssh-attach is obviously more painful? I believe that it's useful, but I'm struggling to think of examples.
[13:11] <smoser> rbasak, of course.
[13:11] <smoser> $ ssh-attach brickies.net -- bash -c 'i=0; while [ $# -ne 0 ]; do echo "$i: $1"; shift; i=$(($i+1)); done' -- "one 1" "two 2" "three 3"
[13:11] <smoser> 0: one 1
[13:11] <smoser> 1: two 2
[13:11] <smoser> 2: three 3
[13:13] <smoser> that gives you the same result as if you'd copied and pasted that 'bash -c...' portion on the remote system.
[13:13] <smoser> try to do something like that without ssh-attach.
[13:14] <smoser> or even "real world" like
[13:14] <smoser> https://gist.github.com/smoser/88a5a77ab0debf268b945d46314ea447
[13:14] <smoser> ussh $name sudo sh -c 'echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main" >/etc/apt/sources.list.d/proposed.list && apt-get update -qy'
[13:19] <smoser> or, i guess along those lines...
[13:20] <smoser> ssh-attach foo -- sh -c 'for line in "$@"; do echo "$line"; done > /etc/apt/sources.list.d/my-sources.list' -- "deb http://archive.1/ trusty main" "archive 2 another".
[13:21] <smoser> you can certainly re-write that to fight the quoting that occurs under you by ssh throwing all argumenst into a single string and feeding it to shell. .but it becomes hard when you have quotes or spaces or single-quote in your input.
[13:22] <rbasak> Why would that last example not just work using ssh without ssh-attach?
[13:24] <rbasak> Your first example I don't really follow, as I'd never type that at the CLI in the real world :)
[13:25] <rbasak> Anyway, I'd be happy to stick this into a contrib/ussh/ directory or something in uvtool git, and then ship it in usr/share/doc/uvtool/examples/ or something? Then it can be maintained and available to others in one place.
[13:25] <rbasak> I wanted to understand it better separately to think about how to make "uvt-kvm ssh" better (or provide an alternative differently behaving command or whatever). But I still don't really follow your use case.
[15:25] <frickler> coreycb: jamespage: seems like you didn't package neutron-dynamic-routing for newton, do you intend to do this at a later stage or will it just drop out of UCA after having been split into a new project upstream?
[15:27] <jamespage> frickler, tbh it did not get on the list
[15:27] <jamespage> frickler, will look at it early next cycle and look to backport for newton
[15:27] <jamespage> frickler, but +1 month away as yet should think
[15:28] <frickler> jamespage: hmm, too bad, so we'll have to take a look at building it ourselves. but thx for confirming
[15:29] <jamespage> frickler, apologies
[15:44] <smoser> rbasak, the basic issue with ssh is that its params are: ssh host "command"
[15:44] <smoser> ssh-attach changes that to:
[15:45] <smoser>  ssh host command [arg1 [arg2 ...]]
[15:45] <smoser> from ssh whatever you pass it as the command to run gets shoved into the users shell on the other side and thus is exposed to that shells quoting rules
[15:45] <rbasak> That's not my experience
[15:45] <smoser> in addition to the quoting rules of the shell you are pasting into
[15:45] <smoser> it most certainly is true.
[15:45] <rbasak> ssh foo echo a b c\; echo d
[15:45] <rbasak> a b c
[15:45] <rbasak> d
[15:46] <rbasak> If command were quoted, I'd expect an "echo" in the output.
[15:46] <rbasak> AIUI, ssh hands everything to "sh -c"
[15:46] <smoser> right
[15:46] <smoser> which means it gets interpreted by the shell
[15:46] <smoser> in addition to the shell on the local system
[15:48] <smoser> actually, rbasak your example is good
[15:48] <smoser> if you paste : echo a b c\; echo d
[15:48] <smoser> or type it on your local shell
[15:48] <smoser> you'll get
[15:49] <smoser> a b c; echo d
[15:49] <smoser> but if you feed it to ssh:
[15:49] <smoser> ssh sstack-185 echo a b c\; echo d
[15:49] <smoser> then you get
[15:49] <smoser> a b c
[15:49] <smoser> d
[15:50] <nacc> rbasak: did you want to continue on our converstaion today? not urgent by any means
[15:51] <rbasak> nacc: bit short of time today, sorry.
[15:51] <nacc> rbasak: nothing to apologize for!
[15:51] <nacc> rbasak: i was planning on maybe seeing if we could use clamav as a testbed for the process? caribou has a new MR, which we could tag and i could see if we pick it up properly
[15:51] <smoser> but:
[15:51] <smoser> ssh-attach sstack-185 -- echo a b c\; echo d
[15:51] <nacc> rbasak: locally, before I push it to the git tree
[15:51] <smoser> a b c; echo d
[15:51] <rbasak> nacc: sure, but I think we should discuss further what we're doing with the upload tags.
[15:52] <nacc> rbasak: ack
[15:53] <smoser> rbasak, that make sense? your example is actually perfect.
[15:54] <rbasak> smoser: interesting, thanks. I see what you mean.
[15:54] <rbasak> Interesting because I'm so used to what ssh does, I didn't think it wrong :)
[15:55] <smoser> its the same as 'sg' or 'su' versus 'sudo'
[15:55] <smoser> sudo == ssh-attach == lxc exec
[15:55] <smoser> sg == su == ssh
[16:56] <coreycb> jamespage, was pykmip intended to go under barbican Suggests vs Recommends?
[17:56] <kyle__> Is there official documentation for how to get rc.local to work in 16.04, or a more systemdish approach to something working like that?
[18:02] <trippeh> kyle__: rc.local seems to work on my 16.04 systems
[18:03] <trippeh> but yeah write systemd services/units if you can
[18:04] <trippeh> rc-local.service - /etc/rc.local Compatibility
[18:04] <trippeh>    Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
[18:04] <kyle__> systemctl status rc.local.service is telling me it's loaded, but nothing in it is run.  Nor are there any logs even referencing it.
[18:05] <gargsms> I am filtering my Apache logs by piping the output using grep --line-buffered. I get the output written to the file in chunks of 4KB. Is there a way for it to be written continuously? Writing 4KB at a time causes me to lose at least 2 log lines per chunk as they don't confirm to the standard of my parser, mostly
[18:07] <trippeh> kyle__: does it say it ran at all in status? eg active (exited) or somesuch
[18:08] <trippeh> Active: active (exited) since fr. 2016-09-30 00:14:35 CEST; 4 days ago -- on my system
[18:11] <kyle__> It says status.. err
[18:11] <kyle__> inactive (dead)
[18:12] <trippeh> could try systemctl enable rc-local.service
[18:12] <trippeh> then reboot and see if it works
[18:14] <kyle__> I did that one other time, but OK :) Willing to try it again.
[18:14] <trippeh> pretty sure I never had to do that, tho.
[18:15] <kyle__> Hum.  Same thing.  Didn't run, and status ends witH:
[18:15] <kyle__>   Active: inactive (dead)
[18:17] <trippeh> kyle__: is the rc.local file executable?
[18:18] <trippeh> and has the sh shebang at the top
[18:18] <kyle__> no... no it's ot.  ALthough I didn't know it generally had to be.
[18:18] <kyle__> Yeah, already has the shebang
[18:21] <kyle__> Gahh.  OK.  It was just misstng the execute.  Weird that it didn't even say peep about it in the logs.
[18:21] <kyle__> Thank you.
[18:21] <trippeh> yeah, I think thats new with the systemd wrapping
[18:22] <trippeh> (not checked)
[18:25]  * kyle__ sighs
[18:25] <kyle__> I know sysv init and upstart had their own problems, but this doesn't feel better
[18:27] <trippeh> odd that it is would not flag as failing when ExecStart= is not executable. I need to try that out
[18:27] <trippeh> but now -> work
[18:40] <kyle__> heh.  Same here.  This was for a user who 'just had to' use 16.04 and rc.local.