[03:50] <allquixotic> Anyone know of a simple solution for remote desktop into an Ubuntu 16.04 server in a container? (For general desktop usage, web browser, etc.)
[03:56] <Sling> allquixotic: ssh with x11 forwarding
[04:28] <compdoc> allquixotic, x2go
[04:29] <compdoc> but you need a 2d desktop. cant use unity
[04:32] <allquixotic> compdoc: Sounds much better than X11 forwarding; nice efficiency for going over a slower link. And nice clear install steps on their wiki. Thanks!
[04:33] <compdoc> allquixotic, I have ubuntu server, a minimal mate desktop, and x2go server on all my servers. and connect from my windows desktop
[04:33] <compdoc> clipboard and sound work
[06:16] <lordievader> Good morning.
[09:13] <cpaelzer> rbasak: the formerly blocking bug 1286882 is now migrated
[09:13] <cpaelzer> rbasak: that means bug 1495988 would be ready for upload now
[09:13] <cpaelzer> rbasak: I also prepped a valid test environment to verify in proposed
[09:14] <cpaelzer> rbasak: could you (re)take a look at 1495988 to upload?
[09:48] <cpaelzer> magicalChicken: hi, as I currently pass my old ntp bugs I cam by bug 1582767 and wanted to ask if you already looked into it
[09:49] <cpaelzer> magicalChicken: especially if you decided if that should be a Ubuntu delta or if you want (have?) provided a debian fix for it?
[11:20] <jamespage> cpaelzer, hey did you start work on the 2.6 snapshot for ovs yet?
[11:21] <cpaelzer> jamespage: I trained myself in git-buildpackage but was blocked on a kernel bug on friday
[11:21] <cpaelzer> jamespage: not much work done yet other than learning on the git-buildpackage side of things
[11:22] <cpaelzer> jamespage: next step would be trying to isolate your post import-tgz changes, and doing kind of a rebase inside that - but well as I'm not familiar yet I can't make any esimationes
[11:22] <cpaelzer> also this morning a zillion of other bugs seem to attack me
[11:22] <cpaelzer> so it got ont the "postponed" list
[11:22] <jamespage> cpaelzer, I'll take a run at it today
[11:23] <jamespage> cpaelzer, all of that stuff is handled by gbp
[11:23] <cpaelzer> I almost thought on waiting with dpdk/ovs things until DPDK 16.07 was released in two weeks
[11:23] <cpaelzer> jamespage: that would be great
[11:23] <cpaelzer> jamespage: I could then pick up whatever you create and prep modding it for dpdk 16.04
[11:23] <cpaelzer> jamespage: I have a preliminary version in a ppa
[11:23] <cpaelzer> with all the new libs and such
[11:24] <cpaelzer> jamespage: just drop me a note or link of a ppa or wherever you upload things so I can pick it up then
[11:25] <jamespage> cpaelzer, hmm no 2.6 branch as yet - will have to work from master for now
[11:25] <cpaelzer> jamespage: just in case it turns out the recent ovs git "needs" dpdk 16.04 feel free to use my interim ppa at https://launchpad.net/~paelzer/+archive/ubuntu/deb-dpdk-16.04
[11:25] <cpaelzer> jamespage: yeah no early snapshot yet
[11:25] <cpaelzer> jamespage: one question
[11:25] <cpaelzer> jamespage: I've thought a lot about what you "might" do now :-)
[11:26] <cpaelzer> jamespage: if you have no offending content in it afterwards, it would be great if you could just dump the full console log or so of the session where you up to this new version
[11:26] <cpaelzer> jamespage: that way I could quickly verify if you followed more or less the stages I thought should happen
[13:16] <cpaelzer> rbasak: sometimes some subpages hide from me :-) I thought I could get from https://launchpad.net/ubuntu/+source/apache2 to the currently running build for the apache upload you did for me
[13:17] <cpaelzer> rbasak: could you help me navigating by pointing to a better entry point?
[13:18] <cpaelzer> https://launchpad.net/ubuntu/+source/apache2/2.4.7-1ubuntu4.11 is not existing (yet?)
[13:27] <rbasak> cpaelzer: it's in the unapproved queue, so is pending review and won't be built until that is done.
[13:27] <rbasak> cpaelzer: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 is the only place it'll appear until the SRU team accept it.
[13:28] <cpaelzer> rbasak: I thought I'd see a not yet building one before that - thanks for the clarification
[14:01] <cpaelzer> magicalChicken: I passed over all my open ntp bugs, and I need a merge and to add some delta anyway - if you not yet have worked on it do you mind if I "steal" bug 1582767?
[14:02] <jayjo> Is there a way to profile the disk to see if data is being stored somewhere irregular? I have a mongodb instance, and after droping the database, which shows the database has dropped in the console, my startup still shows the disk space occupied and it doesn't go down. Is that normal?
[14:04] <cpaelzer> jayjo: which tool are you using to check it?
[14:04] <cpaelzer> jayjo: there was some stuff like http://sysunconfig.net/aixtips/df_du_diff_out.txt so I'd like to understand "how you check" first
[14:04] <jayjo> In this instance I'm just meaning the startup log
[14:05] <cpaelzer> jayjo: so all your question is "inside" mongodb then - right?
[14:06] <jayjo> And it's less that its inconsistent, its that if there is 1GB/30GB being used normally, I put about 10-15GB into the DB and dropped it and it still shows about 15GB/30GB used of drive spae
[14:06] <jayjo> I guess it's more broadly a 'linux' question. Is there a way to profile the disk to see if that startup log is correct at all?
[14:07] <cpaelzer> jayjo: plenty of tools depending on what exactly we are looking for, but IIRC mongodb doesn't always recalim on drop as well
[14:08] <cpaelzer> jayjo: for some of the most basic "where on my disk is space consumed" you can use "du --max-depth=1 | sort -n"
[14:09] <cpaelzer> jayjo: if it is inside mongodb look at https://docs.mongodb.com/manual/faq/storage/#faq-disk-size
[14:10] <jge_> sarnold: good morning, just in case you're still interested in the output of slabtop on that box I had a problem with on friday with high memory usage with a fresh install of 16.04: http://pastie.org/private/z6fygvppfo8ruop43xzs7w
[14:10] <jge_> :)
[14:10] <cpaelzer> jayjo: http://stackoverflow.com/questions/2966687/reducing-mongodb-database-file-size
[14:11] <coreycb> jamespage, do you what the purpose of this patch is?  https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/keystone/tree/debian/patches/add-version-info.patch
[14:15] <jayjo> cpaelzer: thanks for your help, this is what I was looking for
[14:15] <cpaelzer> jayjo: if you don't like searching where space is with du you could try the ncurse based ncdu if you want
[14:15] <cpaelzer> jayjo: ah nice - good luck with that
[14:21] <smoser> rbasak, if i have uvt-kvm somewhere, and want to get newer images (and i want them from daily) what do i run ?
[14:21] <smoser> sorry if i just didn't rtfm
[14:22] <cpaelzer> smoser: sudo uvt-simplestreams-libvirt sync release=yakkety arch=amd64 label=daily
[14:22] <cpaelzer> you might know the simplestreams syntax :-)
[14:22] <smoser> are you sure ?
[14:23] <smoser> i think somehow i have to tell it to look in the daily strema
[14:23] <cpaelzer> that was it a while ago - let me check (this came from bash history)
[14:23] <cpaelzer> smoser: sudo uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily release=xenial arch=amd6
[14:23] <rbasak> smoser, cpaelzer: you also need --source http://cloud-images.ubuntu.com/daily
[14:23] <cpaelzer> and similar
[14:24] <rbasak> smoser: because we couldn't agree on how to unify that use case with the non-daily one ;-)
[14:24] <smoser> rbasak, cpaelzer thanks.
[14:33] <cpaelzer> magicalChicken: if you are ok with it just reassign it to me
[14:47] <magicalChicken> cpaelzer, just reassigned to you, thanks for taking that
[15:35] <smoser> rbasak, i just filed
[15:35] <smoser>  https://bugs.launchpad.net/ubuntu/+source/uvtool/+bug/1596577
[15:35] <smoser> dont know if that is a dupe of something
[15:35] <smoser> also...
[15:36] <smoser>  http://paste.ubuntu.com/17975188/
[15:36] <smoser> i think it might hvae been luser error (smoser as the luser) that produced the messed up system on digget
[15:38] <smoser> but it seems like a bug that root can't do that.
[15:40] <rbasak> smoser: I don't think I've seen that before. Thanks!
[16:16] <sarnold> jge_: how long had that machine been active? those numbers all seem sane enough.
[16:19] <jge_> sarnold: I ran that slabtop command on friday, box had been up for 8-9 hours
[16:21] <sarnold> jge_: aha; how about now?
[16:26] <jge_> sarnold: turned it off this morning, memory was the same though
[16:27] <jge_> I can turn it back on and let it build up again and run some more commands if you would like
[16:36] <sarnold> jge_: well, I had honestly expected to see something more like an obvious memory leak :/ oh well
[16:40] <jge_> yeah me too, sounds like it needs more digging.. not sure whats up, went back to 14.04 for the time being
[16:56] <smoser> rbasak fyi, 'supported' is now in data (for quite a while) so you can do:
[16:56] <smoser>  uvt-simplestreams-libvirt -vv sync --source http://cloud-images.ubuntu.com/daily 'supported=True' arch=amd64
[16:56] <smoser> and i've added that to ubuntu's crontab
[17:18] <rbasak> smoser: what does 'supported' mean?
[17:21] <smoser> rbasak, that it is currently supported
[17:22] <smoser> as in right now that is precise, trusty, wily, xenial, yakkety
[17:27] <rbasak> Oh, I see. OK, thanks.
[18:23] <jge_> sarnold: so strange, fresh copy of 14.04 lts same problem.. I'm starting to think is me not reading memory usage correctly or something is really screwed up
[18:23] <jge_> I've tripled checked my commands, making sure I understand their output.. nothings adds up!
[18:24] <jge_> what the hell..
[18:24] <jge_> something might be up with the hypervisor
[18:25] <sarnold> jge_: strange. I'n not used to not being able to account for where memory goes :/
[18:26] <jge_> yes, make it very frustrating
[18:26] <jge_> makes*
[18:28] <jge_> jge_: any chance you could just the output of my 'free -h' command just to confirm i'm not crazy
[18:28] <jge_> check
[18:30] <jge_> sarnold: ^ sorry
[18:32] <sarnold> jge_: sure
[18:37] <jge_> sarnold: http://pastie.org/private/lj6evcvl7yrobnpoqamvg
[18:37] <jge_> thank you
[18:40] <sarnold> jge_: and how about the processes? top M output..
[18:45] <jge_> sarnold: http://pastie.org/private/rzqaeykpcaykkj5cyw6shw
[18:46] <jge_> I just noticed the hypervisor ballooning for that vm is very high.. 600MB
[18:46] <jge_> I'm reading more about it now.. not sure that's normal
[18:46] <sarnold> i've got zero expereince with the ballooning things.. is that stable?
[18:47] <jge_> don't know, reading more about it now
[18:48] <jge_> I just checked another vm which doesn't have that problem, balloon values are 0
[18:48]  * nacc lacks context, what's the problem statement?\
[18:49] <nacc> memory being taken away from a VM but not accounted?
[18:49] <jge_> yea
[18:49] <sarnold> nacc: roughly his systems are using more memory than can be accounted for
[18:49] <sky> installed ubuntu 16.04  with postfix. my mail logs are showing up in /var/log/syslog but not /var/log/mail.log (in fact that file doesnt exist)
[18:50] <nacc> jge_: is your host overcommitted?
[18:51] <jge_> nacc: almost but not there yet, resources show I'm using 15.6GB of the 16G
[18:51] <jge_> think that could be it?
[18:52] <nacc> jge_: i know some hypervisors can be (or can be tuned to be) more aggressive at ballooning memory to satisfy VM requests. So if you're getting low in the host, and either the host needs memory, or another VM does, I think it could be 'ballooning' memory in/out accordingly.
[18:52] <nacc> jge_: is this KVM?
[18:52] <sarnold> vmware
[18:52] <jge_> yep vmware esxi
[18:53] <nacc> ah
[18:53] <rharper> one way to be hostile is to launch a userspace process to malloc ram, typically page faults in a guest are a trigger for the hypervisor to ease-up on the balloon; that's not always going to happen; but in general from a hypervisor perspective, it's hard to know the difference in how memory in a guest is used.
[18:55] <rharper> filling /dev/shm/XX with random data also helps defeat any dedup efforts , but if it's your host, it's likely to then trigger action in the other shared VMs (ie, their balloons may be inflated to compensate;
[18:56] <nacc> rharper: yeah, we had a test that did that at IBM, it was ugly
[18:56] <rharper> I'm not 100% sure about vmware, but ballons are guest-cooperative efforts in KVM, likely in vmware as well, in which case if you blacklist the balloon module, you can't give any memory back cooperatively
[18:57] <rharper> nacc: heh, alternatively you could just launch a jvm with a large heap
[18:57] <nacc> rharper: yeah, i think that's what they were trying to simulate
[18:57] <jge_> probably getting out of topic for this channels, since it sounds like that could be the issue... but should I look into tuning how agressive balooning is on this host or add more RAM?
[18:58] <rharper> jge_: depends on your goals;  more memory is always useful if you can afford the cost;  if you're trying to work with what you have and balance it, then you may need to look at some sort of active monitory of esxi and tuning the balloons based on other workload criteria
[18:58] <rharper> this is a *really* hard problem without intimate knowledge of your workload, it's highs and lows and acceptable response (quality of service)
[18:59] <nacc> overcommit in general gets you into racy/tricky situations, IME :)
[18:59] <rharper> even then, the typically available feedback knobs tend to be too late,  ie, seeing swap activity in the guest is likely too late to free up memory
[18:59] <rharper> without taking workload or qos
[18:59] <nacc> yep
[19:00]  * patdk-lap just depends on vmotion :)
[19:00] <jge_> hmm ok
[19:00] <patdk-lap> if a host is running out of memory, move some to another host
[19:00] <jge_> thank you rharper nacc and sarnold
[19:00] <rharper> if it can happen fast enough
[19:00] <rharper> jge_: sure
[19:01] <rharper> there's always a trade off in response time/downtime vs. bandwidth to migrate
[19:01] <patdk-lap> jge_ should be able to, unless every vm you have has 10's of gigs of ram
[19:01] <jge_> some of these vms have been assigned too much memory for what I use it for really..
[19:01] <patdk-lap> vmware should balloon them instantly then
[19:02] <patdk-lap> it will balloon, the os will just drop caches
[19:02] <patdk-lap> shouldn't be an issue
[19:02] <rharper> jge_: it's possible that there is a for-pay addon to esix or upgrade to vsphere or other vmware produces that do active balloon management
[19:02] <rharper> that seems like a typical "Value Add" path for corps to do
[19:02] <rharper> s/esix/esxi
[19:03] <jge_> rharper: and what does this add on do?
[19:03] <jge_> that I can't do manually.. if any
[19:03] <rharper> jge_: I don't know; I'm guessing here; I;m not familiar with vmware offerings
[19:03] <jge_> home lab here, nothing corporate
[19:03] <patdk-lap> I dunno why you would want to get hostile though
[19:03] <patdk-lap> just unload the balloon driver, and esxi will never steal ram from it
[19:04] <jge_> patdk-lap: is that recommended?
[19:04] <patdk-lap> heh?
[19:04] <patdk-lap> define recommended
[19:05] <patdk-lap> that is something that is up to you
[19:05] <patdk-lap> how do they know what your doing
[19:05] <patdk-lap> if you have a vm that should never loose memory (say, mongodb)
[19:05] <jge_> I mean is it an accepted solution
[19:05] <nacc> yeah, i mean if you don't want to balloon, disable ballooning seems like the best recommendation
[19:05] <patdk-lap> you would be insane to run the balloon driver in it
[19:05] <nacc> that seems true regardless of platform even, it's more of a server deployment/design
[19:05] <patdk-lap> but for most vm's, balloon is useful
[19:06] <patdk-lap> could cause issues on a webserver, that has lots of files/inodes cached in ram
[19:06] <patdk-lap> and something balloons, and now that webserver dropped caches, and is slow as crap
[19:06] <patdk-lap> the best system would be don't overcommit, and don't use balloon driver
[19:07] <patdk-lap> but that isn't how people really design things these days, often
[19:07] <jge_> I don't know if it is really, the system is unusable.. if ballloning was working fine and by that I mean manage ballooning in/out as needed it would be transparent
[19:07] <jge_> wouldnt it?
[19:07] <patdk-lap> yes
[19:07] <patdk-lap> but vmware is guessing how much to balloon
[19:07] <patdk-lap> based on how it active it sees the vm memory
[19:08] <patdk-lap> it doesn't know if that memory is really needed, and will cause a huge swap to happen
[19:08] <patdk-lap> or if it is just a simple drop caches, operation and the vm didn't really need that ram
[19:09] <patdk-lap> if the vm has to swap out all that ram, vs just release it, so the balloon can happen, big difference in performance
[19:10] <jge_> hmm
[19:10] <jge_> ok
[19:10] <jge_> could the balloon driver be disable per guest or is a system wide setting
[19:10] <patdk-lap> it must be installed per guest
[19:11] <patdk-lap> the idea is
[19:11] <patdk-lap> the guest os knows if that memory is in use or not
[19:11] <jge_> got it, I never installed anything though.. guessing it comes enabled by default
[19:11] <patdk-lap> if you cannot get enough ram using balloon
[19:11] <patdk-lap> then it will have to swap the vm itself, and it has to assume ALL memory is used, so that is really painful
[19:11] <patdk-lap> it does not come installed by default
[19:11] <patdk-lap> you had to have installed the vm tools
[19:12] <jge_> it does it automatically
[19:13] <jge_> I didnt install anything but I see it running
[19:13] <patdk-lap> no, it has never installed automatically, ever
[19:13] <patdk-lap> if you do a full install everything, it's likely installed
[19:13] <patdk-lap> and then if found, would be used
[19:13] <jge_> hmm let me check if it's installed
[19:14] <jge_> thought I saw it running
[19:14] <jge_> let me see
[19:14] <patdk-lap> ps ax | grep vmw
[19:14] <jge_> if what is found?
[19:14] <patdk-lap> actually, that isn't right
[19:14] <patdk-lap> lsmod | grep vmw
[19:15] <jge_> http://pastie.org/private/64d1zctsgfpkkkxgpfh8q
[19:15] <jge_> I guess it is?
[19:15] <patdk-lap> yep
[19:15] <patdk-lap> you can just blacklist vmw_balloon
[19:15] <jge_> hmm wondering how it got there.. I never installed it
[19:16] <patdk-lap> you even have vmwgfx isntalled
[19:16] <patdk-lap> never seen all that other stuff
[19:16] <patdk-lap> you didn't happen to use vmwares install iso method did you?
[19:16] <patdk-lap> vmware probably installed it for you
[19:17] <jge_> yeah, i mounted the iso on the virtual cd-rom
[19:17] <jge_> and connected on boot
[19:19] <jge_> not a fan of stuff that hides the real picture
[19:19] <jge_> took me 3 days, countless fresh installs and many wtfs
[19:19] <jge_> :(
[19:20] <jge_> vmware should just let people install it
[19:21] <patdk-lap> they do
[19:21] <patdk-lap> atleast I never use the vmware iso installer
[19:21] <patdk-lap> I make the vm
[19:21] <patdk-lap> then afterwards, mount the iso to the cdrom and boot
[19:21] <patdk-lap> never select the iso during vm creation
[19:22] <jge_> not sure we are talking about the same thing.. I downloaded the ISO from ubuntu.com then mounted to virtual rom
[19:22] <patdk-lap> then you should isntall it just fine, manually
[19:22] <patdk-lap> but vmware also has an, install automatically from iso during creation
[19:24] <jge_> so you provision the vm, usually a wizard.. click finish then go back and mount the iSO?
[19:24] <patdk-lap> yes
[19:24] <jge_> not the same as doing it during the wizard?
[19:24] <patdk-lap> depends on the wizard
[19:24] <patdk-lap> the wizards I have in esxi don't let you select an iso at all
[19:24] <patdk-lap> using workstation it does, but that causes the auto-install
[19:24] <jge_> before you click finish, I usually go to let me edit setting before finishing.. some option like that
[19:24] <jge_> then mount iso there
[19:25] <patdk-lap> I never use that, as it always says for years, do not do this :)
[19:26] <jge_> the process is identical, the only difference is clicking edit settings before provisioning
[19:27] <patdk-lap> you could say they are, but vmware claims they are not
[19:27] <jge_> not sure how vmware thought that could be helpful
[19:27] <patdk-lap> I'll perfer to believe them
[19:27] <jge_> yeah i guess
[19:27] <patdk-lap> I do sometimes do the edit, but not often
[19:27] <patdk-lap> I normally end up editing a lot of things
[19:28] <jge_> how would I blacklist ballooning, you don't happen to know do you :D
[19:28] <patdk-lap> edit the blacklist file or make a new one in /etc/modprobe.d
[19:28] <jge_> ok will do, thank you patdk-lap
[19:40] <jge_> patdk-lap: sounds like vmware does not recommend disabling the balloon driver
[19:40] <jge_> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002586
[19:40] <jge_> warning at the top.. :\
[19:41] <patdk-lap> performance issues
[19:41] <patdk-lap> ya, can't share ram
[20:17] <coreycb> ddellav, jamespage: ci should be back to blue shortly.  fixed up cinder for mitaka and the following for newton: heat (fixed by new python-aodhclient 0.5.0), swift, keystone, nova/neutron (fixed by new python-fixtures 3.0.0).
[20:35] <LaserAllan> hmm
[20:35] <LaserAllan> Anyone in here using Python 2.7.11?