[04:04] hey guys, help me to understand: one of my friends told me that he was running some experiments on a one server containing 256 CPU cores. Is he lying to me or can it be "relatively" easily achieved ? [04:06] Mava: for *only* $13.34 per hour you can use an AWS server with 128 cores and 2TB of RAM [04:07] nicolas17: is the processing then spanned somehow over several hardwares ? [04:09] on the other hand you might have quad socket with xeon platinum 8180 (56 threads): that means 224 threads in a single server [04:10] apparently that particular AWS server uses multi-socket Xeon E7-8880 v3 (Haswell) [04:10] thats an old server [04:10] or a cpu [04:10] and obviously it's NUMA [04:12] must be [04:39] good morning === cpaelzer_ is now known as cpaelzer [06:06] Good morning === chmurifree is now known as chmuri [12:17] jamespage: do you have any opinions on keeping/dropping uwsgi support for openstack merges? [12:19] jamespage: for example, sahara-api uses uwsgi for py3. seems we might want to drop it and get apache2/eventlet working. [12:20] coreycb: just switch it over to mod-wsgi - if we place all of the binaries in python in python{3}- then if someone wants to use uwsgi they can do so without packaging bits [12:20] i.e. apt install python3-sahara + uwsgi [12:20] avoiding any mod-wsgi stuff we default to for more automated installs via pkging [12:22] jamespage: ok, similar to what we have for gnocchi then [12:25] jamespage: i debated moving libapache2-mod-wsgi-(py3) to python(3)- but decided not to. suppose i could be convinced otherwise though for ease of switch to py3. [12:26] but it's not a python module. maybe tehre should be some consistency in what is python3-*, as in actual python modules (those you can 'import'). [12:31] blackflow: yes, seems that should be the case. for openstack it just might be simpler for users to have a consistent way to move to python 3, where all you'd have to do is install the python3- across all projects, rather than having to know to install libapache2-mod-wsgi-py3 or perhaps other deps. (where python3- and libapache2-mod-wsgi-py3 are alternative dependencies) [12:32] yea but mod-wsgi is an apache module not a python module, that's my point. [12:32] blackflow: agreed [12:33] blackflow: thanks for the input [12:33] yw [12:44] coreycb: I think we need to not have that dependency [12:44] python*- will work with either [12:45] so our '-api' package can be opinionated and install python3-sahara + libmod-wsgi-py3 [12:45] leaving others to use uwsgi + python3-sahara if they want without pulling in apache [12:45] but I think you got to that point anyway! [12:46] jamespage: ok right, that's where i am now. so sahara-api depends on libapache2-mod-wsgi-py | libapache2-mod-wsgi-py3. but installing the sahara-api is optional if someone wants to use uwsgi. [12:46] and sahara-api depends on python-sahara | python3-sahara [12:47] jamespage: thanks for the input [12:50] coreycb: I think the quicker we can get through the 'alternatives' stage the better - we can have an opinionated default of py3 + mod-wsgi - but if someone wants to use py2 + mod-wsgi or py2/3 + uwsgi that's also doable, but not via dependencies - i.e. explicit install of components [12:53] jamespage: true but if we don't have a simple py2 api path then we're going to get a lot of bugs incoming like the gnocchi one. it's not that much work to have libapache2-mod-wsgi-py | libapache2-mod-wsgi-py3. [12:54] ok [12:54] jamespage: the apache config is the same. i think? [12:54] I think we reduce the risk of people getting things wrong with reference to alternative dependencies if we do one thing i.e. py3 + mod-wsgi [12:54] but I also appreciate that's not working everywhere yet [12:55] so hence 'quicker through the alternatives phase' rather than 'just don't do it' [12:55] if that makes sense [12:56] part of the problem is that upstream is not fully py3 supported [12:57] jamespage: ^ i'm picturing just dropping libapache2-mod-wsgi-py and python- with a breaks/replaces on all projects at once when py3 is fully supported [13:53] Hi. are anyone good @ pxe servers? Ive followed thos manuals that I can find and I cant get it work.. so my question is, is there anyone here that can help me? [13:55] jrewing: please ask your question. People who can help usually don't volunteer themselves without knowing what the question is first. [13:57] rbasak: sorry.. I need help to install an PXE- server === shubjer0 is now known as shubjero [13:58] jrewing: start by reading https://wiki.ubuntu.com/IRC/Guidelines and http://www.sabi.co.uk/Notes/linuxHelpAsk.html please - that'll help you ask the right questions here to get the most useful help. === shubjero is now known as Jared === zul is now known as zul_ [14:12] rbasak: thanks, i did read some of it...i will resend my question :) === freyes__ is now known as freyes === zul_ is now known as zul [14:15] Im trying to install an PXE server and I cant get it work... it wont start ftpboot. ive tryed to reinstall all as the manuals said byt i still get the same problem and i wonder if there is anyone here that can help med to install through some remoteprogram? === caribou_ is now known as caribo === caribo is now known as caribou === jrewing2 is now known as jrewing === ashleyd is now known as ashd === miguel is now known as Guest38578 === ashleyd is now known as ashd === giraffe is now known as Guest9306 [20:41] Hi, I've got a question re .htaccess redirect problem I'm having, I thought someone here might be able to help maybe? I'm trying to redirect all files in directory from (domain.com/other)/transfer/ to (domain.com/other)/files/, but the rules that I'm entering redirect me to (domain.com)/var/www/html/other/files/. I haven't found anything useful after searching for a while so I thought I'd try here. Thanks! [21:29] what could be wrong here? [21:29] man: error while loading shared libraries: libmandb-2.8.3.so: cannot open shared object file: Permission denied [21:29] I get this error whenever I try to read a manpage [21:29] as root! [21:31] Aison: check your dmesg or audit logs, there's a possibility your apparmor profiles are too tight [21:32] oh, strange: [ 572.147660] audit: type=1400 audit(1528752452.004:86): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2220 comm="man" laddr=10.0.0.14 lport=899 faddr=10.0.0.2 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" [21:34] okay that's curious [21:34] why exactly is your man process using the network? [21:35] NFS mounts maybe? [21:35] yes, exactly, nfs mounts [21:36] it used to work over an year now. strange things are happening now ;) [21:36] Aison: man is apparently contained by apparmor now [21:38] this is one of the annoying thing with Apparmor and NFS [21:38] going to remove apparmor [21:39] it is a complete closed box anyway [21:39] sdeziel: dude, nice crystal ball :) [21:39] sdeziel: I guess the 2049 should have said it all [21:39] sarnold: TCP/2049 ;) [21:39] still :D [21:45] Aison: you can update /etc/apparmor.d/local/usr.bin.man to have: 'network inet,' then do: 'sudo apparmor_parser -r /etc/apparmor.d/usr.bin.man' and it should start to work [21:45] Aison: if you could file a bug at https://bugs.launchpad.net/ubuntu/+source/manpages/+filebug, then a dev can get it fixed for everyone [21:50] jdstrand: if the NFS server is referenced by a DNS name, would it need ? [21:51] sdeziel: yes, to get nsswitch.conf [21:52] jdstrand: OK, thanks [21:52] it may not need all of abstractions/nameservice. I've not tried it