| === giraffe is now known as Guest84199 | ||
| === pavlushka is now known as Guest51462 | ||
| === Guest51462 is now known as pavlushka | ||
| ThePentester1 | Hello | 06:39 |
|---|---|---|
| ThePentester1 | can we assign more than one ip on AWS EC2 dedicated server | 06:41 |
| frickler | jamespage: seems neutron rc3 is needed https://bugs.launchpad.net/bugs/1628549 | 06:44 |
| ubottu | Launchpad bug 1628549 in neutron "DB migration is broken with two unassigned floating IPs" [High,Fix released] | 06:44 |
| ThePentester1 | can we assign more than one ip on AWS EC2 dedicated server ? | 06:45 |
| lordievader | Good morning. | 07:56 |
| 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:05 |
| 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:06 |
| thekrynn | is it common for NFS to cause high load averages with minimal cpu? | 08:25 |
| 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:36 |
| lordievader | Check vmstat I'd say, if you see a lot of blocked processes and a high io-wait time, might be the cause. | 08:38 |
| 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:12 |
| lordievader | ;) | 09:15 |
| lordievader | Glad you solved it. | 09:15 |
| === MrBIOS_ is now known as MrBIOS | ||
| === Malediction_ is now known as Malediction | ||
| === _degorenko is now known as degorenko | ||
| frickler | jamespage: coreycb: could you check for working dependencies here, please? https://bugs.launchpad.net/keystone/+bug/1628883 | 11:37 |
| ubottu | Launchpad bug 1628883 in OpenStack Identity (keystone) "Minimum requirements too low on oslo.log for keystone" [Undecided,New] | 11:37 |
| coreycb | frickler, we'll fix that up, thanks for reporting it. | 11:41 |
| frickler | coreycb: thanks, I'll also go and see what upstream thinks about this | 11:43 |
| coreycb | frickler, it seems that global-requirements is too low: https://github.com/openstack/requirements/blob/stable/newton/global-requirements.txt | 11:46 |
| 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:47 |
| coreycb | frickler, nm they are aligned at >= 1.14.0. I was on the wrong keystone branch. | 11:50 |
| coreycb | still a problem obviously | 11:51 |
| === Mobutils_ is now known as Mobutils | ||
| coreycb | frickler, jamespage, ddellav: I just took a pass on all of our core newton packages to bump oslo.log >= 3.16.0 | 12:53 |
| 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:42 |
| 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:43 |
| jgrimm | caribou, that works for me | 14:49 |
| 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:51 |
| 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:52 |
| === lutostag_ is now known as lutostag | ||
| === JanC is now known as Guest12605 | ||
| === JanC_ is now known as JanC | ||
| jgrimm | caribou, I added it here for tracking -> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core | 14:53 |
| jgrimm | thanks | 14:53 |
| coreycb | ddellav, gnocchi ok to sync? | 15:32 |
| coreycb | ddellav, and magnum? | 15:32 |
| 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:33 |
| 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:34 |
| ddellav | coreycb gnocchi needs a python-gabbi sync. gabbi builds in xenial and yakkety without issue. | 15:42 |
| coreycb | ddellav, ok sync initiated for gabbi | 15:44 |
| 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:55 |
| jamespage | coreycb, quick poke | 15:56 |
| jamespage | nova -> os-brick requires privsep | 15:56 |
| 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:57 |
| coreycb | ddellav, eh... wrong queue, still there: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text= | 15:58 |
| 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 | 15:59 |
| 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:02 |
| 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:07 |
| ddellav | coreycb yep | 16:10 |
| coreycb | ddellav, thanks | 16:10 |
| coreycb | rockstar, pylxd 2.1.1 uploaded to yakkety | 16:11 |
| rockstar | coreycb: aces | 16:34 |
| coreycb | ddellav, k8sclient sync initiated | 16:48 |
| === Jare_ is now known as Jare | ||
| === pavlushka is now known as Guest94932 | ||
| === degorenko is now known as _degorenko | ||
| === Guest94932 is now known as pavlushka | ||
| sarnold | jamespage,coreycb, thanks (openstack vmt supporting oslo.privsep) | 18:29 |
| coreycb | sarnold, you're welcome, thanks for the review | 18:30 |
| === blizzow1 is now known as blizzow | ||
| === ddstreet_away is now known as ddstreet | ||
| === andol_ is now known as andol | ||
| coreycb | jamespage, ddellav: I opened bug 1629097 for neutron in newton | 20:19 |
| ubottu | bug 1629097 in neutron "neutron-rootwrap processes not getting cleaned up" [Undecided,New] https://launchpad.net/bugs/1629097 | 20:19 |
| coreycb | seems to be the cause of memory exhaustion in our charm deploys of nova-compute and neutron-gateway | 20:20 |
| coreycb | beisner, ^ | 20:20 |
| jamespage | coreycb, broken dns? | 20:30 |
| coreycb | jamespage, think so? | 20:31 |
| coreycb | jamespage, I deployed mitaka for comparison and there weren't any issues | 20:31 |
| coreycb | jamespage, and reverting that commit seemed to help. let me unrevert to double check. | 20:32 |
| jamespage | maybe not | 20:33 |
| coreycb | jamespage, ok confirmed that reverting that commit fixes it | 20:45 |
| jamespage | coreycb, awesome | 20:57 |
| === nacc_ is now known as nacc | ||
| 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 | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!