[04:04] <Mava> 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] <nicolas17> Mava: for *only* $13.34 per hour you can use an AWS server with 128 cores and 2TB of RAM
[04:07] <Mava> nicolas17: is the processing then spanned somehow over several hardwares ?
[04:09] <Mava> 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] <nicolas17> apparently that particular AWS server uses multi-socket Xeon E7-8880 v3 (Haswell)
[04:10] <Mava> thats an old server
[04:10] <Mava> or a cpu
[04:10] <nicolas17> and obviously it's NUMA
[04:12] <Mava> must be
[04:39] <cpaelzer_> good morning
[06:06] <lordievader> Good morning
[12:17] <coreycb> jamespage: do you have any opinions on keeping/dropping uwsgi support for openstack merges?
[12:19] <coreycb> jamespage: for example, sahara-api uses uwsgi for py3. seems we might want to drop it and get apache2/eventlet working.
[12:20] <jamespage> coreycb: just switch it over to mod-wsgi - if we place all of the binaries in python in python{3}-<module> then if someone wants to use uwsgi they can do so without packaging bits
[12:20] <jamespage> i.e. apt install python3-sahara + uwsgi
[12:20] <jamespage> avoiding any mod-wsgi stuff we default to for more automated installs via pkging
[12:22] <coreycb> jamespage: ok, similar to what we have for gnocchi then
[12:25] <coreycb> jamespage: i debated moving libapache2-mod-wsgi-(py3) to python(3)-<module> but decided not to. suppose i could be convinced otherwise though for ease of switch to py3.
[12:26] <blackflow> 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] <coreycb> 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-<module> across all projects, rather than having to know to install libapache2-mod-wsgi-py3 or perhaps other deps. (where python3-<module> and libapache2-mod-wsgi-py3 are alternative dependencies)
[12:32] <blackflow> yea but mod-wsgi is an apache module not a python module, that's my point.
[12:32] <coreycb> blackflow: agreed
[12:33] <coreycb> blackflow: thanks for the input
[12:33] <blackflow> yw
[12:44] <jamespage> coreycb: I think we need to not have that dependency
[12:44] <jamespage> python*-<component> will work with either
[12:45] <jamespage> so our '<component>-api' package can be opinionated and install python3-sahara + libmod-wsgi-py3
[12:45] <jamespage> leaving others to use uwsgi + python3-sahara if they want without pulling in apache
[12:45] <jamespage> but I think you got to that point anyway!
[12:46] <coreycb> 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] <coreycb> and sahara-api depends on python-sahara | python3-sahara
[12:47] <coreycb> jamespage: thanks for the input
[12:50] <jamespage> 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] <coreycb> 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] <jamespage> ok
[12:54] <coreycb> jamespage: the apache config is the same. i think?
[12:54] <jamespage> 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] <jamespage> but I also appreciate that's not working everywhere yet
[12:55] <jamespage> so hence 'quicker through the alternatives phase' rather than 'just don't do it'
[12:55] <jamespage> if that makes sense
[12:56] <coreycb> part of the problem is that upstream is not fully py3 supported
[12:57] <coreycb> jamespage: ^  i'm picturing just dropping libapache2-mod-wsgi-py and python-<module> with a breaks/replaces on all projects at once when py3 is fully supported
[13:53] <jrewing> 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] <rbasak> jrewing: please ask your question. People who can help usually don't volunteer themselves without knowing what the question is first.
[13:57] <jrewing> rbasak: sorry.. I need help to install an PXE- server
[13:58] <rbasak> 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.
[14:12] <jrewing> rbasak: thanks, i did read some of it...i will  resend my question :)
[14:15] <jrewing> 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?
[20:41] <SliderFish> 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] <Aison> what could be wrong here?
[21:29] <Aison> man: error while loading shared libraries: libmandb-2.8.3.so: cannot open shared object file: Permission denied
[21:29] <Aison> I get this error whenever I try to read a manpage
[21:29] <Aison> as root!
[21:31] <sarnold> Aison: check your dmesg or audit logs, there's a possibility your apparmor profiles are too tight
[21:32] <Aison> 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] <sarnold> okay that's curious
[21:34] <sarnold> why exactly is your man process using the network?
[21:35] <sdeziel> NFS mounts maybe?
[21:35] <Aison> yes, exactly, nfs mounts
[21:36] <Aison> it used to work over an year now. strange things are happening now ;)
[21:36] <sdeziel> Aison: man is apparently contained by apparmor now
[21:38] <sdeziel> this is one of the annoying thing with Apparmor and NFS
[21:38] <Aison> going to remove apparmor
[21:39] <Aison> it is a complete closed box anyway
[21:39] <sarnold> sdeziel: dude, nice crystal ball :)
[21:39] <sarnold> sdeziel: I guess the 2049 should have said it all
[21:39] <sdeziel> sarnold: TCP/2049 ;)
[21:39] <sarnold> still :D
[21:45] <jdstrand> 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] <jdstrand> 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] <sdeziel> jdstrand: if the NFS server is referenced by a DNS name, would it need <abstractions/nameservice>?
[21:51] <jdstrand> sdeziel: yes, to get nsswitch.conf
[21:52] <sdeziel> jdstrand: OK, thanks
[21:52] <jdstrand> it may not need all of abstractions/nameservice. I've not tried it