| teward | so, stupid question but where are the autopkgtests stored | 00:18 |
|---|---|---|
| Alessandro_ | Hello. I'm having some issues using MariaDB on Ubuntu 16.04. I install it with "apt-get install mariadb-server mariadb-client". When I run "mysql -uroot", however, I get "Access denied for user 'root'@'localhost'". I then run mysql_safe_installation and set a password for the root user, and I still get the same error over and over again when logging in with "mysql -uroot -p" and typing the correct password. any hint? | 00:18 |
| nacc | teward: how do you mean? | 00:19 |
| teward | nacc: well, trying to ID what's going on with nginx | 00:19 |
| nacc | teward: the tests themselves are in d/t/control | 00:19 |
| teward | there's two regressions in diaspora-installer but that's something on their side not nginx | 00:19 |
| teward | ah OK | 00:19 |
| teward | nacc: looks like i never had to touch them before :p | 00:19 |
| teward | i see some nginx fails today, gotta see what that's about :P | 00:19 |
| teward | oh hm, ssl curves | 00:22 |
| teward | *checks Zesty* | 00:22 |
| teward | nacc: any idea how to check what ECDH curves are supported on Zesty? | 00:24 |
| nacc | teward: i have no idea what that acronym is :) | 00:24 |
| teward | i'll ask OpenSSL then | 00:25 |
| Alessandro_ | teward: try "openssl -v" IIRC | 00:26 |
| trippeh_ | for curves, openssl ecparam -list_curves | 00:27 |
| teward | well I know what I have to do. I have to drop a curve... | 00:28 |
| teward | who do i prod to change what is acceptable or not for a given test? | 00:28 |
| teward | autopkgtest* on the migration tracking system? | 00:28 |
| nacc | teward: you update the test | 00:29 |
| nacc | teward: wait, what do you mean 'acceptable'? all tests have to pass | 00:29 |
| teward | nacc: I.E. "always failed" or 'Ignored once" | 00:30 |
| nacc | teward: that's the release team, i believe | 00:30 |
| teward | OK | 00:30 |
| teward | i'm going to have to drop a test since we don't support the curve... or mark "always failed"... might be easier to drop that curve from the test. | 00:31 |
| nacc | teward: always failed is typically not set -- it's something autopkgtest runner recognizes | 00:32 |
| teward | mmm | 00:32 |
| nacc | teward: 'failure ignored' is what gets set | 00:32 |
| teward | nacc: That's probably what's going to have to be set to get nginx out of proposed, but for more than just nginx. I need to check with Debian in the interim | 00:32 |
| nacc | teward: so this is a nginx test? | 00:32 |
| teward | because i think they added a curve we don't support that got in from Experimental | 00:33 |
| teward | nacc: well... | 00:33 |
| teward | nacc: two problems: | 00:33 |
| teward | (1) NGINX tests fail with Regression, I think it's because there's a curve added to the tests | 00:33 |
| nacc | teward: it might be apporpirate to add delta is some test depends ona feature we odn't support | 00:33 |
| teward | (2) a *different* autopkgtest errors out | 00:33 |
| teward | but *not* because of nginx | 00:33 |
| nacc | teward: let me look | 00:33 |
| teward | nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nginx | 00:33 |
| teward | diaspora-installer is the only other one I am not looking into but those errors look like it's a repository problem *not* related ot nginx | 00:34 |
| nacc | teward: ack, so you're saying we should skip the ec-x25519 test on ubuntu? | 00:34 |
| teward | nacc: i'm saying "probably", but I need to figure out its origin | 00:34 |
| teward | first | 00:34 |
| nacc | teward: that should be done via a delta to the src package that either comments out (i prefer this but it's up to you, i think) or deletes it from d/t/control | 00:34 |
| teward | nacc: I want to figure out if it's from Debian Exp. or not first | 00:35 |
| nacc | teward: ack | 00:35 |
| teward | that said I need a Debian image too to test | 00:35 |
| nacc | teward: i'm looking at the other one | 00:35 |
| nacc | teward: lxc launch images:debian/sid/amd64 | 00:35 |
| teward | if it works in Debian but not Ubuntu, then it's a delta that we can comment out for the test | 00:35 |
| teward | nacc: already ahead of you | 00:35 |
| nacc | teward: and/or check ci.debian.net | 00:35 |
| teward | but i'm installing the ubuntu-server image in an lxc container. | 00:35 |
| teward | or rather, installing that metapackage | 00:35 |
| teward | so i have a 'standard' set of crap lol | 00:36 |
| nacc | https://ci.debian.net/packages/n/nginx/unstable/amd64/ | 00:36 |
| nacc | seems rather green | 00:36 |
| teward | nacc: yeah but i want to make sure that this test is 'new' | 00:36 |
| teward | and if it's not 'new' then poke the Security team for a check on OpenSSL in Ubuntu to see if they dropped the curve or something | 00:36 |
| teward | being thorough | 00:37 |
| nacc | teward: http://autopkgtest.ubuntu.com/packages/nginx/zesty/amd64 fwiw as well | 00:37 |
| nacc | teward: that test wasn't present in the last upload to z-p, it seems | 00:38 |
| nacc | teward: it is present in debian | 00:38 |
| teward | nacc: the 'last upload' to z-p was a half-merge | 00:38 |
| teward | it was HTTP/2 fixes ahead of the actual merge from Debian | 00:38 |
| teward | the 'latest' that got run had to wait for Perl to get out first | 00:38 |
| teward | then it ran the autopkgtsts | 00:38 |
| nacc | ack | 00:38 |
| teward | so these are "new" tests that are originated from Debian since.. what, 1.10.0, so the Xenial cycle? | 00:39 |
| teward | yeah I dont' see that curve in the OpenSSL curve lists | 00:39 |
| teward | for Ubuntu anyways | 00:39 |
| teward | gonna check that list vs. Debian and if the list is different then ignroe the check here in ubuntu by commenting out as part of the Delta | 00:39 |
| trippeh_ | our openssl is too old :) | 00:40 |
| teward | :P | 00:40 |
| teward | i'm almost certain it is | 00:41 |
| teward | yay Debain container time to update you :p | 00:41 |
| teward | s/Debain/Debian/ | 00:43 |
| teward | *notes to update his autocorrect* | 00:43 |
| nacc | teward: i retriggered those two diaspora failures, i think they are going further, but we'll see | 00:45 |
| teward | OK | 00:46 |
| teward | nacc: thanks. | 00:46 |
| teward | huh interesting I don't see that SSL curve in Unstable either o.O | 00:46 |
| teward | ECDH* | 00:46 |
| teward | confirmed the core issue | 00:47 |
| teward | # nginx -T | 00:47 |
| teward | nginx: [emerg] Unknown curve name "X25519" (SSL:) | 00:47 |
| teward | nginx: configuration file /etc/nginx/nginx.conf test failed | 00:47 |
| teward | in Zesty | 00:47 |
| teward | but works fine in Unstable | 00:47 |
| teward | so that's just a curve we don't accept. | 00:47 |
| teward | s/accept/have/ | 00:47 |
| trippeh_ | maybe it doesnt list these newfangled non-ECDH curves in ecparam | 00:47 |
| teward | trippeh_: it might not | 00:48 |
| trippeh_ | it is new in openssl 1.1 fwiw | 00:48 |
| teward | ah, that would explain that | 00:48 |
| nacc | teward: yeah, i think those two diaspora failures will clear on their own now | 00:48 |
| teward | we don't roll 1.1 yet I don't think | 00:48 |
| teward | nacc: OK. I'm going to go and say "We don't support this curve, because OpenSSL is older than 1.1.0"; how did you suggest I go about 'dropping' the test? | 00:49 |
| nacc | teward: no, 1.0.2g on zesty | 00:49 |
| nacc | teward: add a delta, each test is a stanza in d/t/control | 00:49 |
| teward | yes but define "delta" as in drop the test or comment out the entire test? | 00:49 |
| nacc | teward: and then i'd say in the changelog entry (so we know for merges) that once we are at openssl 1.1.0 we can drop it | 00:49 |
| nacc | teward: totally up to you | 00:50 |
| nacc | teward: if we did everything with an SCM, then i'd say delete it, but it's a little more self-documenting if commented out | 00:50 |
| teward | nacc: I actually have a copy of the packaging in a GitLab instance of my own, so it's sorta version controlled. | 00:50 |
| nacc | teward: and since you are the maintainer, i think that's ok then to just drop it and you'd know | 00:51 |
| teward | nacc: yep, well I'm just going to remove it from d/t/control but leave the test "in there" | 00:51 |
| nacc | teward: if someone were to come along and do teh team workflow to re-merge it, it'd also be obvious what corresponds to what, i think | 00:51 |
| teward | and comment accordingly. | 00:51 |
| nacc | teward: yeah exactly | 00:51 |
| teward | nacc: indeed. Though the team tends to poke me for testing first lol | 00:51 |
| nacc | teward: :) | 00:51 |
| trippeh_ | "Unknown error executing apt-key" - thanks, apt-get | 00:53 |
| nacc | heh | 00:54 |
| teward | oops i forgot to put bugfix-only in the changelog fff | 00:56 |
| teward | 'accepted' oh cool. | 00:56 |
| teward | nacc: I could probably alter the test to try and test the OpenSSL version first. But I'm lazy :P | 00:58 |
| teward | I'll just yell at Debian for making me increase the delta :P | 00:58 |
| teward | again. | 00:58 |
| teward | nacc: looks like the diaspora-installer tests didn't blow up this time heh | 00:58 |
| teward | since now it's not erroring on the gems xD | 00:59 |
| teward | nacc: what do I need to do if I want to set up autopkgtests for a PPA build before I upload something, say on a local test instance? | 01:00 |
| teward | if you know :) | 01:00 |
| trippeh_ | ah lol, since I was chrooting from a EL7 install, PATH lacked /bin ... | 01:11 |
| trippeh_ | "wait! no grep!??" | 01:11 |
| nacc | teward: you can run an autopkgtest against a specific PPA build, one sec | 01:12 |
| nacc | teward: https://wiki.ubuntu.com/ProposedMigration "Testing aginsta a PPA" | 01:12 |
| teward | nacc: yeah, trying to see where it reports that | 01:16 |
| teward | nacc: apparently I'm "not authorized" to see the report. or it hasn't run yet, I don't see it queued either. | 01:17 |
| nacc | teward: i can run it for you probably | 01:23 |
| nacc | teward: if you have the ppa set up | 01:23 |
| nacc | teward: and diaspora passed now (excuses is still pending an update) | 01:24 |
| teward | nacc: it'll likely rerun and/or explode | 01:26 |
| teward | nacc: i was able to *request* the build against the nginx stable PPA. I can't see if it's pending or not | 01:26 |
| teward | that's all. | 01:26 |
| teward | It didn't say I didn't have privs. to request. | 01:26 |
| teward | probably since i'm the admin for that 'group' PPA :P | 01:26 |
| nacc | teward: oh you'd see it running in the autopkgtest running page | 01:28 |
| nacc | https://autopkgtest.ubuntu.com/running | 01:28 |
| nacc | teward: so you uploaded a new version, anyways, right? | 01:29 |
| nacc | as i see tests running for ubuntu3 | 01:29 |
| teward | nacc: yes. | 01:47 |
| teward | nacc: -1ubuntu3 has a fix for the autopkgtests. | 01:47 |
| teward | and was already accepted somehow. | 01:47 |
| teward | it'll probably *still* need pushed by the release team | 01:47 |
| teward | nacc: can you check if there's nginx tests against 1.10.3-1+zesty0 or similar in a PPA? | 01:49 |
| teward | being run now | 01:49 |
| teward | I expect that to blow up actually lol | 01:49 |
| teward | (in a PPA) | 01:50 |
| teward | 1.10.3-0+zesty0 actually heh | 01:50 |
| teward | blah i'm tired | 01:50 |
| nacc | teward: no, there's only feature freeze on, so it shouldn't need any help in this case | 01:51 |
| teward | OK | 01:51 |
| nacc | teward: and yes, i now see the zesty0 running | 01:51 |
| nacc | against your ppa | 01:51 |
| nacc | http://autopkgtest.ubuntu.com/running#pkg-nginx | 01:51 |
| teward | cool. | 01:52 |
| teward | nacc: yep i see it working thanks | 01:59 |
| nacc | teward: the only annoyance is you can't see the logs fully until the test finishes and copies over | 02:00 |
| nacc | teward: which is quite a bit slower than the normal autopkgtests i've found | 02:00 |
| teward | nacc: Indeed, though my PPA update workflows are not ones I regularly need to poke so :P | 02:15 |
| teward | (nor do I need rapid testing) | 02:15 |
| teward | nacc: looks like commenting out that autopkgtest solved the failures for nginx, let's just hope diaspora doesn't blow up in our face again :P | 02:16 |
| teward | wth 'nova' regression | 02:16 |
| teward | nacc: can you see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/n/nova/20170228_013617_86af9@/log.gz and tell me what's dead here? | 02:17 |
| teward | it *looks* to me like it's an openscsi / erlang issue | 02:17 |
| teward | not even sure *why* nova is triggered by the nginx test though | 02:18 |
| nacc | teward: i'd guess not your issue | 02:44 |
| nacc | teward: i'll retry it | 02:44 |
| nacc | teward: although i agree, i don't know why nova ran | 02:45 |
| nacc | teward: in fact, i don't see anything installed from -proposed at all except | 02:46 |
| teward | nacc: I think you trailed off... | 03:31 |
| teward | [2017-02-27 21:46:23] <nacc> teward: in fact, i don't see anything installed from -proposed at all except ... | 03:31 |
| teward | nacc: ^.^ nginx has finally left -proposed and landed in Zesty | 03:47 |
| teward | I can rest easy! | 03:47 |
| teward | Server Team: I can safely say that the NGINX merge has been completed. Starting with Zesty, we now have ***dynamic module support*** | 04:14 |
| teward | future merges should not be as hellish anymore :) | 04:14 |
| teward | (cc rbasak, jgrimm, sarnold because reasons, anyone else who cares) ^ | 04:15 |
| sarnold | teward: nice :D now to relax! :D | 04:19 |
| teward | sarnold: truth! | 04:20 |
| frickler | jamespage: did you take a look at building kraken yet? (ceph-11.2.0) would it still seem feasible to get it into zesty? | 07:00 |
| === caribou_ is now known as caribou | ||
| jamespage | frickler: I did take a peek but then discussed with sage; we don't normally drop the interim releases into Ubuntu | 08:20 |
| jamespage | frickler: so next drop with be luminous in the spring - probably for 17.10 | 08:20 |
| === disposable3 is now known as disposable2 | ||
| frickler | jamespage: o.k., thx for the info | 09:01 |
| DK2 | after installing a server with 2 TB disks i get "cannot get disk parameters" when booting the hard drive | 09:05 |
| DK2 | the installation seems to be fine when checking via a live cd | 09:06 |
| DK2 | what could be the cause for it? | 09:06 |
| DK2 | does the server does not see the drives? | 09:06 |
| === tinwood_swap is now known as tinwood | ||
| DK2 | figured it out, the bootvolume was not set | 09:17 |
| sarnold | where did you set it? | 09:18 |
| === JanC is now known as Guest13435 | ||
| === JanC_ is now known as JanC | ||
| zioproto | hello there. I would like to make a refresh of the nova package | 09:30 |
| zioproto | this is different from when I just add a patch in debian/patches | 09:30 |
| zioproto | there is a standard procedure to refresh the upstream version ? | 09:30 |
| lordievader | Good morning. | 09:42 |
| sarnold | zioproto: usually along the lines of: download the new tarball, verify sigs; unpack tarball; rm -rf newtarball/debian/; cp -a oldtarball/debian/ newtarball/debian/ ; rename the tarball to have the .orig.tar.gz name; edit the newtarball/debian/changelog file, add a new entry with new version number, description of what patches remain; fiddle quilt patches from debian/patches/ as needed | 09:51 |
| zioproto | sarnold, ok, so I have to wait the nova folks to create the tarball. I though I could import a git commit from the nova repo | 09:54 |
| sarnold | zioproto: well there's a whole 'git build package' thing going with some way to treat upstream gits as tarballs without the tarballs.. all I know is the ancient stuff :) | 09:57 |
| rbasak | teward: thank you! | 10:49 |
| maswan | Hm. Upgrading our storage servers to xenial we saw a large performance degradation on our hp hw raids (hpsa), anyone else with similar observations? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668557 | 11:43 |
| ubottu | Launchpad bug 1668557 in linux (Ubuntu) "Write performance regression severely affecting hpsa controllers" [Undecided,Confirmed] | 11:43 |
| cpaelzer | maswan: from 3.18.18 to 3.18.21 is already a good narrow diff to look for | 12:03 |
| cpaelzer | maswan: you said simple dd test is driving this | 12:03 |
| maswan | yup | 12:03 |
| maswan | or, well, my collegue across the corridor | 12:03 |
| cpaelzer | maswan: could you provide the exact command and (to start) an output of "iostat -xtdk 5" that was running over the time | 12:03 |
| maswan | sure | 12:04 |
| maswan | ok if I limit iostat to just the relevant device? | 12:06 |
| cpaelzer | maswan: sure | 12:06 |
| maswan | (lvm for OS stuff, so lots of dm-*) | 12:06 |
| cpaelzer | it is just a start to get a feeling where we should go to | 12:06 |
| cpaelzer | if you write only to a single device, just that | 12:06 |
| cpaelzer | if you write to an LVM or such just the related devices to your workload | 12:07 |
| cpaelzer | like top lvm, and the PVs that matter | 12:07 |
| maswan | no, we write to xfs on /dev/sdb | 12:07 |
| maswan | for data | 12:07 |
| maswan | lvm for OS on /dev/sda (different slice, hpssacli output is already attached) | 12:08 |
| cpaelzer | I'm still reading through the attachments | 12:08 |
| * maswan nods | 12:08 | |
| maswan | soon you'll get another. :) | 12:08 |
| cpaelzer | perfect would be to get the iostat for just the two god/bad kernels that are close | 12:09 |
| maswan | bad case is in, rebooting for good old kernel. :) | 12:12 |
| maswan | hm. one case we haven't tried so far in pinning the blame is dd:ing directly to the block device. | 12:14 |
| cpaelzer | maswan: raw access and/or an alternative fs (like ext4) can be worth a shot for sure | 12:15 |
| maswan | let me get iostat for the fast case first though | 12:15 |
| cpaelzer | absolutely | 12:15 |
| maswan | hm. do you want iostat for the first-good mainline kernel too? | 12:15 |
| cpaelzer | as I read the bug I thought that comparing 3.18.21-031821.201509020527 vs 3.18.22-031822.201510031227 should be best right? | 12:16 |
| maswan | yes | 12:16 |
| cpaelzer | that is minimal delta in terms of patches | 12:16 |
| maswan | Will do that, just ran it on whatever it was booted on first. | 12:16 |
| cpaelzer | so I'd compare those until we have a reason to look further | 12:16 |
| maswan | and then thought harder of what would be best for comparison. :) | 12:16 |
| cpaelzer | to pick those two will avoid us seeing a lot of "other" noise in logs | 12:16 |
| maswan | ho hum | 12:24 |
| maswan | hp servers are slow to boot | 12:24 |
| patdk-lap | slow is an understatement | 12:24 |
| maswan | I heard quite a bit of grumbling yesterday when Nikke was bisecting kernel versions and had to wait for a reboot between each test | 12:25 |
| maswan | There, iostat and command line output from the last fast and first slow 3.18.2* kernels | 12:29 |
| * cpaelzer reading | 12:30 | |
| maswan | and on the slow kernel, pretty much identical performance for dd if=/dev/zero of=/dev/sdb bs=256k, possibly slightly slower | 12:31 |
| cpaelzer | it seems it no more recognized this as a raid | 12:36 |
| cpaelzer | so the block device layer is holding back requests to merge them | 12:37 |
| cpaelzer | maswan: you see write reqeust merges per sec ~500 | 12:37 |
| cpaelzer | maswan: and due to that ~8x bigger write requests | 12:37 |
| cpaelzer | maswan: which in your case sucks, as the raid below will split it along its stripe size again | 12:37 |
| cpaelzer | or would have handled all of them in cache already | 12:37 |
| maswan | cpaelzer: that could indeed explain the suckage | 12:38 |
| cpaelzer | maswan: you also see that while rq-size is x8 the write await is x60 | 12:38 |
| cpaelzer | so you can be happy that it is "only" 1/2 instead of 1/7.5 speed | 12:38 |
| cpaelzer | now lets start to look for changes | 12:38 |
| * cpaelzer reading diffs | 12:39 | |
| maswan | thanks | 12:39 |
| cpaelzer | maswan: IIRC somewhere in /sys there were attrivutes for the devices that flag such things (spinning, cached, ...) | 12:39 |
| cpaelzer | maswan: while I look for code if you could look in ... | 12:39 |
| * cpaelzer is searching | 12:39 | |
| cpaelzer | maswan: get that for both kernels booted on your device (sdb?) | 12:42 |
| cpaelzer | $ for i in /sys/class/block/sda/queue/iosched/* /sys/class/block/sda/queue/*; do echo $i $(cat $i); done | 12:42 |
| cpaelzer | there should be no diff between stable kernels, if there is that is another indicator where to look | 12:43 |
| maswan | yup, working on it | 12:46 |
| maswan | aka waiting for reboot | 12:46 |
| cpaelzer | maswan: also you go through page cache with your test (intentionally?) - once time permits you could try if all is the same with oflag=direct | 12:48 |
| cpaelzer | yet the request merging is a hotter lead which should be pursued first | 12:48 |
| cpaelzer | OTOH the reboots seems to be what slows you down, so we might collect what we can do each cycle | 12:48 |
| maswan | well, the first test of dd into a file on xfs is very close to the production case | 12:48 |
| maswan | which is taking large files from network onto disk (and then spooling them to tape, or the other way around) | 12:49 |
| maswan | before ingest rate it could handle was line speed 10GE | 12:49 |
| cpaelzer | ok, if close to the real cae lets stick to that for now | 12:50 |
| maswan | well, single file all zeros is already a simplifcation of it. but sure, I can try some oflag=direct while I'm booted anyway. :) | 12:50 |
| maswan | only diff is max_sectors_kb, 4096->512 | 12:52 |
| maswan | attaching fastmode output to the bug now | 12:52 |
| cpaelzer | but well that is it maswan | 12:52 |
| cpaelzer | that is the critical value | 12:53 |
| * maswan nods | 12:53 | |
| cpaelzer | and the size close to 8k is in 512b sectors to 4096 (kb) matches the 8*512 | 12:54 |
| maswan | so probably no need for more narrow dd test cases | 12:54 |
| cpaelzer | maswan: exactly | 12:54 |
| cpaelzer | maswan: I still struggle to see the patch that causes it, but there is a workaround for you to test | 12:54 |
| cpaelzer | maswan: boot the slow kernel and set 512 into that calue | 12:54 |
| cpaelzer | hmm | 12:54 |
| cpaelzer | was that a writable one | 12:54 |
| cpaelzer | uh it might not be | 12:54 |
| maswan | seems to be writeable | 12:55 |
| maswan | lets see | 12:55 |
| cpaelzer | maswan: if you are tuning later for raids you might also consider setting /sys/class/block/sdb/queue/rotational to 0 | 12:56 |
| cpaelzer | locality with so many disks is kind of inexistant | 12:57 |
| cpaelzer | but one change at a time | 12:57 |
| cpaelzer | let me know if setting the smaller max_sectors_kb helped | 12:57 |
| cpaelzer | maswan: I think I found the change http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=20d74bf29cfae86649bf1ec75038c79a9bc5010f | 13:01 |
| cpaelzer | it is correct to "fix" it, yet in your case with the drives very likely not having 4k formatting and the strip-size/offset being different it comes to the need of tuning that now | 13:02 |
| cpaelzer | maswan: let me know how setting 512 worked for you | 13:02 |
| maswan | cpaelzer: yup, that does indeed make stuff fast on the newer kernel | 13:04 |
| cpaelzer | yeah | 13:04 |
| cpaelzer | maswan: for more tuning, have you tried the rotational=0 as well? | 13:05 |
| cpaelzer | maswan: TL;DR IMHO the controller always announces 4k, instead of being smart and on a certain raid setup drop to the stripe or sector size | 13:06 |
| cpaelzer | maswan: newer linux "fixes" now pick these values up correctly which makes it slower for you :-/ | 13:06 |
| cpaelzer | maswan: interested in the rotational flag | 13:06 |
| maswan | rotational=0 makes very little difference | 13:06 |
| cpaelzer | it should save cpu time | 13:07 |
| maswan | maybe 5-10% for kb=512 | 13:07 |
| cpaelzer | I come from mainframes, every cycle is expensive :-) | 13:07 |
| cpaelzer | Or make it green, save energy :-) | 13:07 |
| cpaelzer | maswan: there are other cases where reverting that fix is no option, are you good setting that value as a tuning in your setup? | 13:08 |
| cpaelzer | maswan: if so I'd close the bug report with that stated | 13:08 |
| maswan | We're good with setting that in our setup, maybe hpsa authors should be prodded that they shouldn't advertise larger blocks to the kernel than they can (reasonably) handle? | 13:09 |
| cpaelzer | maswan: as I said they correctly say what they "can" handle, but an option to "advertise what is smart instead of what we can"might be worth | 13:10 |
| cpaelzer | maswan: if you have contacts at least ask them | 13:10 |
| maswan | not really | 13:10 |
| maswan | hm. I guess they might be reading linux-raid though, I'm a long time lurker in there | 13:11 |
| maswan | Please close it with as much info you can think of on the causes etc | 13:11 |
| cpaelzer | maswan: done | 13:13 |
| cpaelzer | maswan: you might use the bug as link in your post | 13:13 |
| maswan | Yeah, that was my intention | 13:14 |
| cpaelzer | maswan: I'd be pleased if you could set my user to cc, email is in the launchpad account I posted to the bug | 13:14 |
| maswan | Sure! | 13:14 |
| * cpaelzer is happy that his 12 year old thesis knowledge still applies to todays real world cases :-) | 13:16 | |
| zioproto | zul, hello there, are you refreshing some nova stuff today ? | 13:16 |
| maswan | hm. cc:ing a googled-up hpsa driver contact address too | 13:25 |
| zioproto | guys, looking at the repo git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova how do you do a commit like 8de3da59a8a8c68f76cea78e5319ad18cf8c2531 ? Do you use a tool like git-dsc-commit ? | 13:32 |
| zioproto | when I refresh the nova tag | 13:33 |
| zioproto | should I git checkout in detached head the current latest tag, then make a new commit, and tag it ? | 13:33 |
| zioproto | then I can merge that new tag into stable/mitaka | 13:33 |
| zioproto | is that the idea ? | 13:33 |
| zioproto | I think basak told me this in the past, where are the logs of this IRC channel ? | 13:36 |
| Slashman | hello, I have "/usr/lib/accountsservice/accounts-daemon" at 100% CPU (on one thread), anyway to understand why? (ubuntu xenial) | 13:38 |
| cpaelzer | Slashman: you might start it with --debug --replace to get a log what it is doing - although I don't know how disruptive that might be | 13:46 |
| cpaelzer | Slashman: eventually it is supposed to implement a dbus service, so maybe some dbus monotoring might do it as well | 13:46 |
| cpaelzer | Slashman: but my dbus-foo isn't good enough to guide you n that | 13:46 |
| Slashman | cpaelzer: this server has only one main service : proftpd, I guess that is somewhat related | 13:47 |
| jamespage | zioproto: the tool you are looking for is gbp import-orig | 13:55 |
| jamespage | that allows you to import a new upstream release | 13:56 |
| zioproto | I managed to do it with git | 13:57 |
| zioproto | I just added the git remote of the upstream | 13:57 |
| zioproto | and I did | 13:57 |
| zioproto | git checkout tagname -- . | 13:57 |
| zioproto | then I had to commit manually | 13:57 |
| zioproto | when you do the merge of the new tag into the stable/mitaka ... I should just discard the changes to the .gitignore and to the .gitreview, right ? | 13:57 |
| zioproto | Basically I am trying to create a commit like this one 6de2684e69b8945042c32d185307f10fcf50b24e | 13:58 |
| maswan | cpaelzer: Btw, Nikke is not quite agreeing that this isn't a hpsa driver bug, giving crappy performance by default. | 14:01 |
| maswan | but I guess that's more useful in a discussion with upstreams | 14:01 |
| zioproto | coreycb, is there already a LP bug for the new nova release ? https://review.openstack.org/#/c/438570/ | 14:04 |
| coreycb | zioproto, hello I would guess so. zul is working on stable point releases this week, so he would know better than me. | 14:06 |
| zioproto | zul, we have a race between ubuntu making the SRU packages and nova pushing his 13.1.3 tag :) | 14:07 |
| zioproto | please make sure ubuntu packages will be at 13.1.3 | 14:07 |
| zioproto | uhm, I am not sure how to update the pristine-tar branch | 14:14 |
| FrEaKmAn_ | hi all.. I have a simple webpage in folder owned by root:www-data... I created new user test and added this user to www-data group | 14:18 |
| FrEaKmAn_ | but that user still cannot write to that folder... any ideas? | 14:18 |
| FrEaKmAn_ | I logged out, restarted everything... | 14:18 |
| zioproto | ok I did something like pristine-tar commit ../nova_13.1.3.orig.tar.gz 13.1.3 | 14:22 |
| zioproto | ahhhhh | 14:57 |
| zioproto | I restarted from scratch | 14:57 |
| zioproto | gbp import-orig --upstream-version=13.1.3 --debian-branch=stable/mitaka --merge --pristine-tar ../nova_13.1.3.orig.tar.gz | 14:57 |
| Slashman | cpaelzer: looks like my issue is the same as https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1316830 | 14:59 |
| ubottu | Launchpad bug 1316830 in accountsservice (Ubuntu) "/usr/lib/accountsservice/accounts-daemon :: memory and CPU time leak" [High,Confirmed] | 14:59 |
| zioproto | guys is this something valid in Xenial ? 'add-apt-repository -s ppa:ubuntu-cloud-archive/tools' | 15:08 |
| zioproto | I dont see any xenial here: http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/ | 15:09 |
| SmOkE_RU | Âñåì ïðâèåò, êòî ìîæåò ïîìî÷ü ñ ïîñòôèêñîì? | 15:14 |
| zioproto | jamespage, http://paste.openstack.org/show/600790/ ? | 15:14 |
| SmOkE_RU | Кто-то с постфиксом может помочь? | 15:20 |
| zioproto | SmOkE_RU, если вы можете говорить по-английски, я могу помочь вам с постфиксе | 15:22 |
| zioproto | (google translate) | 15:22 |
| SmOkE_RU | zioproto i think i can) | 15:22 |
| zioproto | so just ask your question in English, it will be easier to get an answer :) | 15:23 |
| SmOkE_RU | zioproto i am install postfix for forum phpBB, and cant send emails, in terminal postfix sends mails | 15:24 |
| === iliv_ is now known as iliv | ||
| zioproto | are you sure phpBB is using postfix to send the mails ? | 15:26 |
| zioproto | sometimes php programs call their out php mta functions | 15:26 |
| SmOkE_RU | zioproto yes, phpbb use postfix, i see it in logs | 15:27 |
| zioproto | what do you see in the postfix logs ? | 15:28 |
| zioproto | if you do 'mailq' you see messages in the queue ? | 15:28 |
| SmOkE_RU | can we go private? | 15:30 |
| zioproto | better here | 15:32 |
| zioproto | so it is a easy problem | 15:32 |
| zioproto | postfix is running with SSL | 15:32 |
| zioproto | and probably the phpBB is not | 15:32 |
| zioproto | do you need encryption between phpBB and postfix ? | 15:32 |
| zioproto | just configure postfix to work without SSL if they are talking on localhost on the same serer | 15:33 |
| zioproto | server | 15:33 |
| SmOkE_RU | hm | 15:34 |
| SmOkE_RU | zioproto in main.cf i need disable ssl, right? | 15:34 |
| zioproto | yes, I dont know the extact line to change, but should be easy | 15:35 |
| zioproto | anyone that had built a openstack cloud archive package for xenial can look at this build log ? https://www.dropbox.com/s/40ps3wf849z3b2d/nova_13.1.2-0ubuntu2_amd64-20170228-1528.build?dl=0 | 15:36 |
| SmOkE_RU | zioproto, ok i disable ssl, now phpbb in error says: SMTP-server not supported auth | 15:36 |
| zioproto | ok, there is an authentication problem | 15:37 |
| zioproto | just tell postfix to accept mail from localhost | 15:37 |
| zioproto | I think it is in main.cf write mynetworks = 127.0.0.0/8 | 15:38 |
| SmOkE_RU | zioproto mydestination = localhost - already set | 15:38 |
| zioproto | what about mynetworks ? | 15:38 |
| SmOkE_RU | zioproto, mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 | 15:38 |
| zioproto | from the log do you see what is the address that phpBB uses to connect to postfix ? | 15:39 |
| SmOkE_RU | zioproto, Feb 28 18:39:12 truecm postfix/smtpd[8037]: lost connection after EHLO from localhost[127.0.0.1] | 15:40 |
| zioproto | I think phpBB is trying to use a name and password even if it is not needed | 15:41 |
| zioproto | check the config | 15:41 |
| zioproto | make sure is not trying to use a name and passwd | 15:41 |
| SmOkE_RU | zioproto method of auth PLAIN or LOGIN? for phpbb | 15:41 |
| zioproto | I have no idea | 15:42 |
| SmOkE_RU | :LD | 15:42 |
| zioproto | you need to read the docs for phpbb | 15:42 |
| SmOkE_RU | zioproto i dont know how, but it works :D | 15:45 |
| SmOkE_RU | zioproto in phpbb i see error, but i recerve test email :D | 15:46 |
| zioproto | great | 15:48 |
| nacc | teward: err, sorry about that :) -- should have ^W one more time :) | 15:50 |
| SmOkE_RU | zioproto thanks for help :) | 15:50 |
| zioproto | no problem ! | 16:00 |
| zioproto | I have no idea when I try to build nova, the build process tries to do 'add-apt-repository -y ppa:ubuntu-cloud-archive/mitaka-staging' | 16:05 |
| zioproto | coreycb, jamespage I found a problem with sbuild-mitaka | 16:11 |
| zioproto | when buidling from xenial | 16:11 |
| zioproto | --chroot-setup-commands="add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging" | 16:11 |
| zioproto | this repo does not work for mitaka | 16:11 |
| frickler | zul: two more bugs we noticed when upgrading from Mitaka to Newton: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1668676 https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1668578, hope you can integrate that into https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1664306 | 16:18 |
| ubottu | Launchpad bug 1668676 in nova (Ubuntu) "Newton package needs to bump dependency on python-rfc3986" [Undecided,New] | 16:18 |
| ubottu | Launchpad bug 1668578 in neutron (Ubuntu) "Newton package needs to bump dependency on python-pecan" [Undecided,New] | 16:18 |
| ubottu | Launchpad bug 1664306 in nova (Ubuntu Yakkety) "newton stable SRU releases" [Undecided,New] | 16:18 |
| zioproto | coreycb, I dont get how to build mitaka packages for Xenial. Looking at http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/dists/ and http://ppa.launchpad.net/ubuntu-cloud-archive/newton-staging/ubuntu/dists/ looks like there is not a Openstack release supporting both trusty and xenial. This breaks the logic in the scripts sbuild-mitaka | 16:32 |
| coreycb | zioproto, for mitaka you sould just use plain old sbuild | 16:35 |
| coreycb | zioproto, for xenial-mitaka, that is | 16:35 |
| zioproto | coreycb, how I complete this string ? add-apt-repository -y ppa:ubuntu-cloud-archive/${release}-staging" | 16:36 |
| zioproto | what ppa works for xenial mitaka ? | 16:36 |
| zioproto | If I remove it completely I get other build errors | 16:36 |
| zioproto | just give me please a sbuild command string that is known to work to build xenial mitaka, so I can build nova and then go on and test the nova release refresh :) | 16:37 |
| coreycb | zioproto, https://wiki.ubuntu.com/OpenStack/CorePackages | 16:38 |
| coreycb | zioproto, try using gbp | 16:38 |
| coreycb | zioproto, are you using our git repo for nova? | 16:39 |
| zioproto | debcheckout --git-track='*' nova | 16:39 |
| zioproto | clones git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova | 16:40 |
| zioproto | cd nova ; git checkout stable/mitaka | 16:40 |
| zioproto | gbp buildpackage -S -us -uc | 16:40 |
| zioproto | I miss the right sbuild command to point to my dsc file | 16:40 |
| coreycb | zioproto, and what sbuild commands? | 16:40 |
| zioproto | that is in ../build-area | 16:40 |
| zioproto | if I remove adding the ppa | 16:41 |
| zioproto | the build fails | 16:41 |
| zioproto | wanna see the log ? | 16:41 |
| coreycb | zioproto, sure but let me see the sbuild commands first please | 16:41 |
| coreycb | zioproto, you don't need to do anything to the sbuild chroot | 16:41 |
| coreycb | zioproto, so you shouldn't be using a ppa or anything | 16:42 |
| zioproto | so usually I use the sbuild-mitaka | 16:44 |
| zioproto | http://paste.openstack.org/show/600803/ | 16:44 |
| zioproto | I tried removing line 28 | 16:44 |
| coreycb | zioproto, sbuild-mitaka is only for trusty | 16:45 |
| === ashleyd is now known as ashd | ||
| coreycb | zioproto, all you need for xenial is 'sbuild -A -d xenial-amd64 ../build-area/nova*.dsc' | 16:46 |
| zioproto | sbuild -d xenial-amd64 -A ../build-area/nova_13.1.2-0ubuntu2.dsc | 16:46 |
| zioproto | ok I am trying this one | 16:46 |
| teward | nacc: it happens :) | 16:47 |
| teward | nacc: GOOD news is it's out of proposed and into Zesty now so yay. so i can rest nwo xD | 16:47 |
| teward | now* | 16:47 |
| nacc | teward: nice :) | 16:48 |
| zioproto | ok it looks like it is working | 16:48 |
| zioproto | coreycb, thanks ! | 16:48 |
| teward | nacc: turns out that we were right to disable the test - Debian did the same for backports this time round. | 16:48 |
| coreycb | zioproto, yay :) | 16:48 |
| nacc | teward: awesome, that's good | 16:48 |
| teward | nacc: oh how I love the evils of 'merging from scratch' :P | 16:49 |
| teward | though it was necessary due to the severity of how out of sync we were :P | 16:49 |
| zioproto | bye everyone, see you tomorrow ! | 17:00 |
| rbasak | nacc: ping | 17:15 |
| nacc | rbasak: pong | 17:19 |
| rbasak | nacc: IRC? Hangout? | 17:19 |
| nacc | rbasak: IRC is fine | 17:19 |
| rbasak | I'm not sure I understood the context. | 17:19 |
| nacc | rbasak: so for the importer -- i did a quick check | 17:19 |
| nacc | rbasak: of the ones that failed to import, about 3 or 4 do work now, so it could be network issues, etc. | 17:19 |
| nacc | rbasak: not 100% on those (yet) | 17:19 |
| nacc | rbasak: but for the rest that still fail, it's all the FF issue for the -devel branches | 17:20 |
| rbasak | OK | 17:20 |
| nacc | rbasak: are you ok with me implementing the merge idea? | 17:20 |
| nacc | rbasak: that is, the -devel branches stay FF by merging the new commit and the old head? | 17:20 |
| rbasak | Yes, but I think we need to be consistent. So we should bump the -devel branch on every version, not just at the end. | 17:21 |
| rbasak | I don't know if that'd be quite a big refactoring? | 17:21 |
| rbasak | But otherwise the data structure obtained would be dependent on timing of imports, which I think would be bad. | 17:21 |
| nacc | so the -devel branch would become quite a bit 'noisier', but would be be correct | 17:22 |
| nacc | it will also slow it down a bit, if it has to do the check for every pocket on every import | 17:22 |
| rbasak | Yeah | 17:22 |
| rbasak | If refactoring, please take my refactoring branch first. | 17:22 |
| rbasak | nacc: it's just a local and inexpensive check though, no? | 17:24 |
| nacc | it's not entirely inexpensive, it has to look at each head in a given series and decide which is 'latest' | 17:24 |
| nacc | refactored, i might be able to restrict it to the affected series, so it might not be a big deal | 17:25 |
| rbasak | OK | 17:27 |
| nacc | rbasak: the only other concenr is the abvoe chagne means existing imports are 'incorrect' or would differ from from-scratch imports | 17:30 |
| nacc | rbasak: i think that's unavoidable for now, though | 17:31 |
| rbasak | Agreed on both. | 17:31 |
| nacc | rbasak: ack, thanks! | 17:31 |
| rbasak | Incidentally, I had a thought related to this. | 17:31 |
| nacc | sure | 17:31 |
| rbasak | Adopting upload tags (or not) also mutates the commit hashes. | 17:32 |
| rbasak | And upload tags may arrive late, in which case they won't be adopted. | 17:32 |
| rbasak | So perhaps we could use "git notes" to add a note to tell us whether a particular upload tag has been seen or not, and whether it was adopted or not. | 17:32 |
| nacc | yes, i think we discussed this at the sprint | 17:32 |
| nacc | sure | 17:32 |
| rbasak | Then the importer could run in a mode where it only adopts upload tags that were previously adopted. | 17:33 |
| rbasak | And then third parties have the option of not mutating things. | 17:33 |
| nacc | we also discusssed *always* taking the upload tag, but there might be a diff between it an and the import tag (as opposed to ignoring them now) | 17:33 |
| nacc | true | 17:33 |
| teward | rbasak: not sure if you saw my highlight from last night, nginx merge is completed, and now out of zesty-proposed and in zesty proper. | 17:33 |
| teward | after fixing one of the autopkgtests heh | 17:33 |
| rbasak | teward: I did. I thought I replied. But if not, thank you! | 17:34 |
| nacc | rbasak: let's hold off on that for now, if taht's ok with you? we can talk about it next week. I'll file it as a bug if it's not already | 17:34 |
| rbasak | nacc: sure. Not suggesting we have to do that now. | 17:34 |
| teward | rbasak: you may have but it gets buried under the cruft i see here - limited RAM on my system running my boucer | 17:34 |
| rbasak | Just thought I'd mention it while we were talking about mutations. | 17:34 |
| teward | < 128MB, so I have very low scrollback limits :) | 17:34 |
| nacc | rbasak: ack | 17:34 |
| teward | rbasak: I'll update the package page I created for the triage stuff to indicate "New Features as of Zesty:" section. And some "Runtime Notes" about the fPIE/fPIC impact on 32bit systems | 17:35 |
| teward | which is noticeable but not insane | 17:35 |
| nacc | teward: do we want 'new features' in the release notes? | 17:36 |
| teward | nacc: We're going to have a good sized blurb for Zesty about the release notes | 17:37 |
| teward | because we have dynamic module support now | 17:37 |
| teward | and a reorg of the packages because of binary changes, etc. | 17:38 |
| teward | as for "new" features, the big one's dynamic module support, but we can have "More Details" on the ServerTeam/Nginx page. | 17:38 |
| teward | since that's now a thing :P | 17:38 |
| teward | the big one's going to be fPIE/fPIC and "Performance Notes" | 17:38 |
| nacc | teward: sounds good :) | 17:39 |
| teward | because with just fPIE there's not a huge performance hit, with fPIE+fPIC which is needed this time around, we have a higher impact this time around | 17:39 |
| teward | (though we've been rolling fPIE since Trusty I think, so that impact is already known. No, I don't have exact benchmarks unfortunately.) | 17:39 |
| === Poster|y is now known as Poster | ||
| teward | rbasak: nacc: https://wiki.ubuntu.com/ServerTeam/NGINX/ZestyZapus - Thoughts? | 20:22 |
| fullstop | Hi all. Is there something different with 16.04 where it fills up /boot with kernels automatically? I don't have unattended upgrades enabled, but it seems to be doing it anyway. | 20:26 |
| fullstop | it appears that unattended upgrades for security related things was somehow enabled. | 20:28 |
| scottjl | fullstop: look at /etc/apt/apt.conf.d/50unattended-upgrades and see what's been uncommented | 20:36 |
| scottjl | by default kernels aren't upgraded though | 20:36 |
| fullstop | yes, I see why it's doing it.. | 20:36 |
| fullstop | but I have no idea how this was set. | 20:36 |
| scottjl | someone/something changed it. | 20:37 |
| fullstop | and it's enabled on all the 16.04 servers we have here. | 20:37 |
| scottjl | puppet? | 20:37 |
| scottjl | salt? | 20:37 |
| fullstop | but none of the 14.04 or 12.04 (which are slated for retirement) | 20:37 |
| fullstop | salt | 20:37 |
| fullstop | but the same states are used on all. | 20:37 |
| scottjl | none of my 16.04 servers are like that in a fresh setup | 20:37 |
| scottjl | check your salt config then? | 20:38 |
| scottjl | that's not standard 16.04 behavior | 20:38 |
| fullstop | let me find some non-salt ones. | 20:38 |
| sarnold | I thought we made that the default for 16.04? | 20:38 |
| scottjl | kernel upgrades? not automatic. unless it's new with 16.04.02? | 20:38 |
| scottjl | well at least. mine aren't doing it (thank god) | 20:39 |
| fullstop | all of mine are | 20:39 |
| fullstop | even non-salt | 20:39 |
| fullstop | this kind of sucks because /boot has run out of space on many of them. | 20:40 |
| rbasak | unattended-upgrades is enabled by default since 16.04 I think. | 20:43 |
| rbasak | But if it causes /boot to fill up, that's bad and we need to fix that. | 20:43 |
| rbasak | teward: looks good! | 20:43 |
| fullstop | /boot is pretty small with the default settings. It can hold just a few kernels before getting plugged up, which prevents apt from really working at all until you manually get involved and clean it up. | 20:44 |
| fullstop | If the server were restarted before it filled, I'm still not certain that old kernels would be purged. | 20:45 |
| teward | rbasak: thanks, feel free to improve :) | 20:45 |
| scottjl | i gave up making /boot a separate partition years ago. it's just part of / | 20:45 |
| sarnold | /etc/apt/apt.conf.d/01autoremove-kernels and /etc/kernel/postinst.d/apt-auto-removal comments claim it can save upwards of four kernels | 20:45 |
| sarnold | funny enough my laptop appears to have six kernels, ~300 megs of /boot and my server seven, for ~385 megs of /boot | 20:47 |
| fullstop | sarnold: surely your laptop has been rebooted recently. When are the old ones to be removed? | 20:47 |
| sarnold | fullstop: you're right, rebooted 46 days ago | 20:48 |
| fullstop | I'm only at 40. ;-) | 20:48 |
| fullstop | but, shhh, the laptop is arch. | 20:48 |
| nacc | teward: +1 looks good | 20:53 |
| teward | :) | 20:54 |
| sarnold | man I can't figure out when APT::NeverAutoRemove actually works :/ | 20:54 |
| sarnold | C++ is just so alien tome | 20:55 |
| teward | heh | 20:55 |
| fullstop | that makes sense if it's "alien tome" or "alien to me" | 20:55 |
| sarnold | hehe so it does :) | 20:55 |
| === mwsb is now known as chu | ||
| ZoomZoomZoom | Hi! Is anyone running qbittorrent-nox behind reverse proxy? I can't get it to work with lighttpd 1.4.35 | 22:13 |
| compdoc | when I ssh into my servers, they have often say they need a restart. do you think its sets to auto install security updates? how would I disable that? | 22:58 |
| compdoc | -have | 22:58 |
| sarnold | why? | 22:59 |
| sarnold | I think the way to disable it is via editing /etc/apt/apt.conf.d/50unattended-upgrades | 22:59 |
| rbasak | Or remove the unattended-upgrades package. | 23:08 |
| sarnold | there's too many intersecting and interacting pieces :) | 23:09 |
| compdoc | when I log in and see it in that state, it makes me wonder if I forgot to restart it the last upgrade. I upgrade them on a regular basis and just dont like seeing it in that state. and dont like stuff installed until I am there to make sure it goes well | 23:09 |
| sarnold | you can always check uptime output to see how long it's been since the last reboot | 23:10 |
| compdoc | too late | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!