[06:39] <ThePentester1> Hello
[06:41] <ThePentester1> can we assign more than one ip on AWS EC2 dedicated server
[06:44] <frickler> jamespage: seems neutron rc3 is needed https://bugs.launchpad.net/bugs/1628549
[06:45] <ThePentester1> can we assign more than one ip on AWS EC2 dedicated server ?
[07:56] <lordievader> Good morning.
[08:05] <Dulcin> Hi, I have a dedicated ubuntu server and I want to run a clean install on it and migrate all data back to it. Would it be easy to request an image and just install that image on a local PC here as backup or would I run into hardware problems then?
[08:06] <Dulcin> I think easiest would be buying a new dedicated server and cancelling this one after migration, but their prices seem to have gone up a lot through the years
[08:25] <thekrynn> is it common for NFS to cause high load averages with minimal cpu?
[08:36] <lordievader> thekrynn: Depends on the usage, I'd say. If a hundreds of clients are hammering the NFS server, yeah expect a high load.
[08:36] <thekrynn> lordievader: basically i have an NFS server, an NFS client, both running on the same hypervisor, and the client is simply grabbing data, awk'ing it, and then writing back small files
[08:36] <thekrynn> at around 500Mbit/s
[08:38] <lordievader> Check vmstat I'd say, if you see a lot of blocked processes and a high io-wait time, might be the cause.
[09:12] <thekrynn> thanks lordievader
[09:12] <thekrynn> seems like cating the data over nfs into a pipe was causing a lot of the issues
[09:12] <thekrynn> i changed that out and the cpu wait in vmstat went down considerably
[09:15] <lordievader> ;)
[09:15] <lordievader> Glad you solved it.
[11:37] <frickler> jamespage: coreycb: could you check for working dependencies here, please? https://bugs.launchpad.net/keystone/+bug/1628883
[11:41] <coreycb> frickler, we'll fix that up, thanks for reporting it.
[11:43] <frickler> coreycb: thanks, I'll also go and see what upstream thinks about this
[11:46] <coreycb> frickler, it seems that global-requirements is too low: https://github.com/openstack/requirements/blob/stable/newton/global-requirements.txt
[11:47] <coreycb> frickler, keystone has a higher min version in their requirements.txt but it should align with g-r
[11:47] <coreycb> frickler, I'll add upstream to the bug
[11:50] <coreycb> frickler, nm they are aligned at >= 1.14.0.  I was on the wrong keystone branch.
[11:51] <coreycb> still a problem obviously
[12:53] <coreycb> frickler, jamespage, ddellav: I just took a pass on all of our core newton packages to bump oslo.log >= 3.16.0
[14:42] <caribou> rbasak: nacc: jgrimm: regarding the current clamav package in Yakkety, I don't think that we should wait on the MIR for tomsfastmath
[14:43] <caribou> mdeslaur has uploaded 0.99-2 in all the stable releases while keeping the old in-package library so I think that Yakkety should to the same
[14:43] <caribou> then we can wait for 17.04 to MIR the library
[14:49] <jgrimm> caribou, that works for me
[14:51] <jgrimm> caribou, though.. its a bit odd that the MIR should take long?? that is, isn't it just a breakout of the previously embedded library which is already in main.
[14:52] <jgrimm> caribou, but, i'm find with that given where we are at in the cycle
[14:52] <caribou> jgrimm: the security team already has a long backlog of MIR reviews
[14:52] <jgrimm> fine
[14:53] <jgrimm> caribou, I added it here for tracking -> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core
[14:53] <jgrimm> thanks
[15:32] <coreycb> ddellav, gnocchi ok to sync?
[15:32] <coreycb> ddellav, and magnum?
[15:33] <ddellav> coreycb those were a bit weird because they aren't RC1, they are full version releases. I wasn't sure if they were applicable. I will run quick builds on them now.
[15:34] <nacc> jamespage: can't recall if i saw, but did you have a test import you wanted us to run for the git workflow?
[15:34] <coreycb> ddellav, they've likely just made it to final release already
[15:42] <ddellav> coreycb gnocchi needs a python-gabbi sync. gabbi builds in xenial and yakkety without issue.
[15:44] <coreycb> ddellav, ok sync initiated for gabbi
[15:55] <ddellav> coreycb how are we doing  with python-os-api-ref? That's needed for magnum as well
[15:55] <ddellav> as is python-k8sclient which builds on both fine and could use a sync
[15:56] <jamespage> coreycb, quick poke
[15:56] <jamespage> nova -> os-brick requires privsep
[15:57] <coreycb> ddellav, looks like os-api-ref is in the archive now
[15:57] <coreycb> ddellav, at least, it's not in the NEW queue anymore https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=
[15:58] <coreycb> ddellav, eh... wrong queue, still there: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=
[15:59] <coreycb> ddellav, I poked the release team this morning about it, I'll poke again
[15:59] <coreycb> jamespage, ok, yeah it looks like we can't get around it
[16:02] <coreycb> jamespage, I'm following up on openstack VMT to ensure it's security supported by upstream
[16:02] <jamespage> coreycb, +1
[16:02] <jamespage> sarnold, ^^
[16:07] <coreycb> ddellav, in the mean time can you just build anything that depends on os-api-ref in a ppa and we'll get the syncs in the queue?
[16:10] <ddellav> coreycb yep
[16:10] <coreycb> ddellav, thanks
[16:11] <coreycb> rockstar, pylxd 2.1.1 uploaded to yakkety
[16:34] <rockstar> coreycb: aces
[16:48] <coreycb> ddellav, k8sclient sync initiated
[18:29] <sarnold> jamespage,coreycb, thanks (openstack vmt supporting oslo.privsep)
[18:30] <coreycb> sarnold, you're welcome, thanks for the review
[20:19] <coreycb> jamespage, ddellav: I opened bug 1629097 for neutron in newton
[20:20] <coreycb> seems to be the cause of memory exhaustion in our charm deploys of nova-compute and neutron-gateway
[20:20] <coreycb> beisner, ^
[20:30] <jamespage> coreycb, broken dns?
[20:31] <coreycb> jamespage, think so?
[20:31] <coreycb> jamespage, I deployed mitaka for comparison and there weren't any issues
[20:32] <coreycb> jamespage, and reverting that commit seemed to help.  let me unrevert to double check.
[20:33] <jamespage> maybe not
[20:45] <coreycb> jamespage, ok confirmed that reverting that commit fixes it
[20:57] <jamespage> coreycb, awesome
[23:16] <jamespage> dannf, hey - I think that arm64 hugepages patch is a little late for newton fwiw
[23:16] <jamespage> esp as its not accepted upstream yet