[00:10] <edenist> hi guys
[00:11] <edenist> getting a really weird error here.... trying to diagnose a Size mismatch error with an apt-get update
[00:11] <sarnold> edenist: are you using apt-cacher-ng?
[00:12] <smoser> bdx, here now.
[00:12] <smoser> whats up?
[00:12] <edenist> oh man, thats right I am.... sigh....... I was wondering why my mds5sums were different, as when doing a wget of the deb manually, it was fine
[00:12] <edenist> I'll clear the apt-cacher-ng cache
[00:53] <edenist> thanks guys! should have realised the apt-cacher problem myself [its happened before..] derp
[00:57] <sarnold> edenist: indeed, it took me hours to figure it out when it first happened to me.. second time, a day later, it was a quick apt-get purge and apt-get install squid-deb-proxy, and I've been happy ever since :) hehe
[04:39] <SG-PXE> would anyone be able to help me with a PXE question? i want to install ubuntu via PXE using a downloaded local CD imagestored on the server running TFTP & Apache, currently the PXE goes out on the internet and pulls from the archive site. Apache is serving up the filesystem.squashfs for gparted
[04:40] <sarnold> SG-PXE: the MAAS server does more or less exactly that; it might have the magic sauce you need in dhcp or something to tell the pxe-booted thing where to find the rest of the installer
[04:40] <sarnold> SG-PXE: I hope this hint's enough, time for me to run
[04:43] <SG-PXE> sarnold: i was hoping i wouldnt have to set up a MAAS server since that adds something extra ontop of everything
[04:43] <lathiat> SG-PXE: you could run a local mirror fairly easily, you can enter the mirror during install
[04:43] <lathiat> SG-PXE: when it asks for your country right at the top is an enter manually option
[04:44] <lathiat> SG-PXE: you could also look at apt-cacher-ng as an alternative to using a downloaded cd
[04:44] <sarnold> SG-PXE: yeah, I don't think you need the full MAAS server, but hopefully you can find the dhcp config its using withot too much hassle
[04:45] <lathiat> that would be through a preseed file
[04:45] <lathiat> but otherwise you can just enter it manually
[04:46] <SG-PXE> lathiat: would a local mirror be hard to set up?
[04:56] <SG-PXE> i was using this guide but since i already had apache serving up files for gparted i didnt want to have to install nfs https://help.ubuntu.com/community/PXEInstallMultiDistro#Ubuntu
[04:58] <lathiat> you dont need nfs you can jus tmount the cd inside the apache root
[05:07] <SG-PXE> would i be able to use fetch=<serverip>/ubuntu if i just put the cd in the apache root?
[05:08] <lathiat> i am unsure which boot flag you need to use you'd have to test that yourself btu what i can tell you is you can choose 'enter information manually' at the top of the mirror country list
[05:10] <SG-PXE> ok so if i understand right if cant find the right flag i would just be able to set the serverip as the mirror when installing ubuntu
[05:11] <lathiat> right
[05:11] <lathiat> there is a falg for it, i just dont know what it is, i would suggest trying otu setting it manually and if that works you can look at figuring out the flag
[05:12] <SG-PXE> id have to keep if as an iso though right?
[05:18] <lathiat> SG-PXE: well no, you could mount it, or copy the files out
[05:18] <lathiat> SG-PXE: or you could create a complete mirror with one of the various tools for doing that, or use apt-cacher-ng to download and then cache the files for re-use in future installations.
[05:21] <SG-PXE> ok i have already started to copy the files out, thanks lathiat
[08:58] <lordievader> Good morning.
[09:44] <farva_> can some one tell me how to locate the logs for connections made to my server machine?
[09:45] <farva_> hopefully they are timestamped and show the number of connections made from each IP such as in netstat -ntu
[09:47] <lordievader> farva_: What type of connections?
[09:48] <farva_> we were ddosd and I got the IP of the person in question but I need to find the log to report them to OVH since it was an OVH machine that they were using
[09:49] <farva_> unfortunately I am not very good with networking so I kinda fly by the seat of my pants trying to figure this stuff out
[09:50] <lordievader> farva_: Individual connections are not logged (thank god), but if they targeted a service, like ssh, you might try their logs. For example ssh does log every login attempt.
[09:50] <farva_> hmmm, well, they hit a game server so I am pretty sure they targeted a port
[09:50] <farva_> and the IP in question
[09:50] <lordievader> You can set iptables to log every connection but then you need HUGE disks to hold just the logs.
[09:52] <farva_> I was afraid of that...
[09:53] <farva_> when you say a huge disk...how big is huge, and can't I write a script to clear the logs every 48-72 hours?
[09:54] <farva_> is there a way for me to pull up the output that I received when I ran netstat -ntu?
[09:54] <lordievader> I've logged my input connections once. It was going fast. Of course it depends on how much of a target the machine is.
[09:54] <lordievader> farva_: Netstat only shows current connections, for as far as I know.
[09:55] <lordievader> What you could do is log the traffic to a specific port though.
[09:55] <farva_> correct, I was not sure however if the system stores the information in a temp file or not
[11:06] <jamespage> coreycb, zul: hey so for kilo-2 please can we update deps for new namespaceless oslo packages
[11:07] <jamespage> we should end up with no reverse-depends on the python-oslo.* ones
[11:49] <jamespage> coreycb, zul: http://paste.ubuntu.com/10172162/
[12:18] <zul> jamespage:  context?
[12:49] <coreycb> zul, do you have the oslo's covered?
[12:52] <zul> coreycb:  yeah they are still in proposed though
[12:53] <coreycb> zul, ok
[13:05] <zul> jamespage:  ack
[13:33] <zul> jamespage:  when you get a sec can you have a look at https://jenkins.qa.ubuntu.com/job/vivid-adt-nova/lastBuild/ARCH=amd64,label=adt/
[13:55] <jamespage> zul, I am
[13:55] <zul> jamespage:  thanks
[13:55] <jamespage> I think its oslo.serialization
[14:00] <jamespage> coreycb, I've picked your nova branch btw
[14:00] <jamespage> dealing with the dep-8 test failure at the same time
[14:00] <coreycb> jamespage, kilo?
[14:00] <jamespage> coreycb, yes
[14:01] <coreycb> jamespage, ok
[14:03] <zul> jamespage:  i have dependency changes for nova as well so Ill wait until your done for nova and merge the branch im working on with yours and coreys
[14:15] <jamespage> zul, nope its oslo.db
[14:15] <jamespage> busted - fixing now
[14:15] <zul> jamespage:  k
[14:21] <jamespage> zul, fix uploaded - that may resolve the nova dep-8 test failure anyway
[14:22] <zul> jamespage:  ack
[14:22] <zul> new python-hacking uploaded
[14:23] <jamespage> zul, meh - did that not need new flake8 + pep8?
[14:23] <zul> jamespage:  nope :)
[14:24] <zul> patched the requirements.txt
[14:25] <jamespage> zul, I'm still not sure why we even need the dependency on hacking tbh
[14:25] <zul> jamespage:  neither do  I really
[14:25] <jamespage> zul, I reckon we can drop it
[14:25] <jamespage> lint checking on build in distro is two steps late and valueless
[14:26] <jamespage> infact we did drop it once - why is it back in?
[14:36] <zul> jamespage: because the unit tests specifically uses it
[14:36] <jamespage> really
[14:37]  * jamespage looks at nova
[14:37] <jamespage> zul, can't see it
[14:37] <zul> jamespage:  nova/tests/unit/test_hacking.py
[14:47] <coreycb> jamespage, I made a few debian/control updates to nova
[14:47] <coreycb> pushed to my branch
[14:53] <LeMike> This will be odd: We have a NRAID5 running with 4 drives, each 500GB (making 2TB in sum). First: RAID5 is about 3 drives... wtf? Second: If I remove 500GB and add 2TB, will it be 3,5TB? Or will it stay 2TB?
[14:54] <LeMike> oh. no.  Raid5 is 4 drives. forget about it. but will the Nraid sum up?
[15:02] <coreycb> zul, here's the list of version bumps needed - http://pastebin.ubuntu.com/10174150/
[15:02] <coreycb> had you done anything for oslo.context?
[15:02] <coreycb> zul ^
[15:02] <zul> coreycb: python-oslo-context :)
[15:04] <coreycb> zul, ah no period
[15:05] <coreycb> zul, was that a mistake?
[15:05] <zul> coreycb:  no its just the new oslo namespace thing
[15:06] <coreycb> zul, all the other oslo's have a period still though
[15:06] <coreycb> probably not an issue, just a name
[15:07] <zul> coreycb:  not an issue
[16:02] <a_ok> limits.conf obviously is just broken I have given up on it. Cgroups seems promising but only redhat and arch seem to have a clue on how to set this up. How can I have my apache processes limited to a certain amount of memory
[16:09] <coreycb> zul, jamespage: hmm, so websockify is in nova/debian/control for juno but never made it to main
[16:10] <zul> coreycb:  its in pydist-overrides remove it from debian/control please
[16:10] <maswan> a_ok: yes, cgroups is the only working mechanism for limiting memory use
[16:11] <coreycb> zul, ok, and do we want to do the same for kilo?
[16:11] <zul> coreycb:  yeah ive already done that
[16:12] <coreycb> zul, ok, ironic depends on it now too
[16:12] <coreycb> I just ran the websockify tox tests and they are still bitrotting
[16:19] <a_ok> maswan: How do I stet it up in 14.04? There is some documentation but they mention cgconfig.conf that seems no longer supporten
[16:19] <coreycb> jamespage, I pushed a new nova again
[16:24] <a_ok> maswan: I do seem to have a cgrulesengd but there isn't even an upstart or init script for it.
[16:24] <maswan> a_ok: Dunno, we only ever use it through slurm and have it set them up, I think.
[17:13] <jamespage> zul, coreycb: the nova dep-8 test failure is due to the eventlet bump required for b2
[17:13] <jamespage> once we get b2 into the archive it should resolve.
[17:14] <zul> jamespage:  ack
[17:14] <coreycb> jamespage, that's good.  b2 == kilo-2?
[17:14] <jamespage> zul, b1 uses eventlet.util which no longer exists
[17:14] <jamespage> coreycb, yes
[17:17] <jamespage> coreycb, whats the status in the juno stable update?
[17:17] <jamespage> coreycb, that should prob be our focus - then we can complete kilo-2
[17:18] <coreycb> jamespage, it's all uploaded so I guess I need to poke the sru team
[17:18] <jamespage> coreycb, arges may be helpful :-)
[17:18] <coreycb> jamespage, yeah :)
[17:26] <arges> jamespage: yea i'm planning on looking at it today
[17:54] <coreycb> arges, thanks
[18:14] <arges> coreycb: should bug 1419117 be targeted against cinder instead of nova?
[18:15] <arges> coreycb: and can you doublecheck my SRU justificationf or that bug
[18:18] <coreycb> arges, well the fix is in python-eventlet but nova, neutron, and cinder need the updated eventlet so I've added those as affected also (if that makes sense)
[18:18] <arges> coreycb: well as long as the uploads reference that bug correctly
[18:18] <coreycb> arges, hmm, they may not
[18:19] <coreycb> arges, looks like I need to reference the bug in cinder, nova, and neutron changelogs
[18:20] <arges> coreycb: if it needs to be verified for all those packages then yes. But if the socket_timeout change only touches python-eventlet and cinder, then you might only need those two
[18:21] <arges> coreycb: all in all, we just want to ensure this change doesn't regress and it fixes a testable bug
[18:22] <coreycb> arges, Ok, updating the packages and will let you know when that's done (shortly)
[18:22] <coreycb> description looks good, thanks for updating it
[18:22] <arges> coreycb: ok let me know
[18:24] <arges> zul: coreycb : so why were control files for packages updated with python-eventlet (>= 0.13.0-1ubuntu3.1~), specifically with the '~'. Is that to make it easier when you update the cloud archive?
[18:25] <arges> since 0.13.0-1ubuntu3.1 will be in the utopic archive, seems like 0.13.0-1ubuntu3.1 would be sufficient
[18:25] <arges> (>= version) that is
[18:25] <coreycb> arges, yes exactly - cloud
[18:25] <arges> coreycb: ok
[18:25] <coreycb> it's for backporting to the cloud archive
[18:33] <zul> coreycb/jamespage: Just about to do a test rebuild and will upload nova b2
[18:36] <coreycb> zul, did james pick up my diffs?
[18:38] <zul> coreycb:  afaik its oslo.db and eventlet fixes
[18:40] <coreycb> zul, I can't find it, do you have a link?
[18:40] <zul> nah
[18:40] <zul> ill just park it after im done
[18:41] <coreycb> zul, ok.  can you take a look when you have a moment?  http://pastebin.ubuntu.com/10176566/
[18:51] <coreycb> arges, can you reject nova, neutron, and cinder and we'll upload the same version with updated changelog?
[18:57] <arges> coreycb: sure
[18:58] <arges> coreycb: ok done
[18:58] <coreycb> arges, thanks
[19:16] <coreycb> arges, neutron, nova, and cinder are uploaded now
[19:16] <arges> coreycb: aye aye
[19:45] <arges> coreycb: can you doublecheck the horizon upload... there is a _lot_ of code removed
[19:45] <arges> coreycb: everything under xstatic is removed
[19:46] <coreycb> arges, something went wrong
[19:46] <coreycb> zul, ^
[19:46] <coreycb> should have Diff: 107 lines (+24/-63) 3 files modified
[19:46] <zul> arges:  can you reject that one then please
[19:46] <arges> zul: will do
[19:47] <arges> done
[20:11] <farva_> so I recently aquired a machine that is far more powerful, and far beyond my scope of experience and I need to set a few things up that I do not understand
[20:11] <farva_> first I need to make sure that I have 2 or my 3 drives raided to create 1 virtual drive, and I need my 3rd drive separate to use as my backup
[20:12] <farva_> when working with OVH, do I install my OS first, or do I RAID my drives first?
[20:12] <farva_> I am not sure how this works at all-I have never even setup a raid before
[20:23] <lazyPower> Do we have PPC64el builds for MariaDB? according to our package matrix i'm not seeing it
[20:23] <lazyPower> http://packages.ubuntu.com/search?keywords=mariadb&searchon=names&suite=utopic&section=all
[20:24] <sarnold> lazyPower: yeah, packages.ubuntu.com is .. not always right
[20:24] <sarnold> lazyPower: see this instead: https://launchpad.net/ubuntu/+source/mariadb-5.5
[20:25] <arges> coreycb: ping me when you upload horizon. thanks
[20:25] <bdx> beisner, coreycb: I am configuring charms for a multi-net OS deployment and have a few questions concerning network configs on neutron-api, quantum-gateway and nova-compute charms, would you mind if I ran a few things by you?
[20:28] <coreycb> zul, can you let arges know when it's uploaded? thanks.
[20:28] <arges> : ) should just ping both of you sorry
[20:28] <arges> but yea that's the last piece of the puzzle
[20:28] <coreycb> bdx, Hi, ask away, out network experts are EOD but we might be able to help
[20:29] <coreycb> arges, np :)
[20:29] <coreycb> arges, and thanks!
[20:32] <bdx> My question is regarding the nova-compute configs bridge-interface, flat-interface, and bridge-ip.....could you.... or anyone really could elaborate on if flat-interface needs to have its own interface, and if bridge-ip needs to be unique per compute node, and in the same subnet?
[20:33] <bdx> same subnet as other compute nodes bridge-ip
[20:37] <coreycb> bdx, I'm not positive but I'd have to assume that you need 2 ports for flat-interface since it's defaulting to eth1
[20:40] <coreycb> bdx, I'd assume the bridge ip should be different and same subnet, but again not positive.
[20:40] <zul> coreycb:  yep
[20:41] <bdx> Ok, that makes sense. It also has a default bridge-ip.....possibly this doesn't need to be unique between compute nodes because only local traffic is communicated here?
[20:42] <bdx> But..NM ... that goes against the purpose of having a bridge.
[20:44] <bdx> What you said makes sense..same subnet, unique ips.
[20:44] <coreycb> bdx, I'd like to get your q's bounced off people who know what they're talking about though.  jamespage or gnuoy: when you are back, mind answering bdx?
[20:45] <bdx> Great. Thank you.
[21:10] <zul> coreycb/agres: re-uploaded
[21:11] <farva_> I have been using Ubuntu 14.04 for the past 6 months, but have a chance to change my OS, does anyone suggest I move to 14.10, or even change it up and go with debian 8?
[21:30] <pmatulis> farva_: what a question
[21:30] <farva_> ikr xD
[21:31] <farva_> I am a linux newb though, and so far what I gather is that I want LTS so ubuntu 14.04 is the way to go
[21:31] <pmatulis> farva_: if you're a newbie then stick with an LTS for a few years.  then you'll be able to answer your above question
[21:32] <farva_> I like that answer =]
[21:32] <JanC> unless you really need 14.10 for some reason, 14.04 is better for a server