| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-26 | |||
| 18:29:49 | jgwentworth | leakypipes: we've got a scheduler host manager bug fix up at https://review.openstack.org/#/c/533371 which would much appreciate your review | |
| 18:30:29 | leakypipes | jgwentworth: on it. | |
| 18:30:59 | leakypipes | jgwentworth: trade ya for https://review.openstack.org/538310 | |
| 18:31:13 | jgwentworth | leakypipes: sure thing | |
| 18:33:08 | jgwentworth | leakypipes: I'm wondering if there's more to do on that one, see comment 2 on the bug https://bugs.launchpad.net/nova/+bug/1729584 | |
| 18:33:09 | openstack | Launchpad bug 1729584 in OpenStack Compute (nova) "boot from volume + configdrive broken (regression)" [High,In progress] - Assigned to Jay Pipes (jaypipes) | |
| 18:34:34 | jgwentworth | I don't quite understand it yet. saying that the secondary volumes can end up as LUN 0 which results in an unbootable instance. IIUC that's even after applying the patch mentioned in comment 0 | |
| 18:39:08 | jgwentworth | maybe that's just residual from before the patch was applied | |
| 18:39:52 | jgwentworth | logan-: hey, are you around? | |
| 19:05:29 | mriedem | wtf now i'm getting this | |
| 19:05:30 | mriedem | OverflowError: Python int too large to convert to C long | |
| 19:05:30 | mriedem | enum_member = __new__(enum_class, *args) | |
| 19:05:30 | mriedem | File "/home/user/git/nova/.tox/py27/local/lib/python2.7/site-packages/enum/__init__.py", line 230, in __new__ | |
| 19:05:35 | mriedem | with unit tests | |
| 19:05:41 | mriedem | cfriesen: figure out the performance issue? | |
| 19:08:09 | cfriesen | mriedem: not yet. we're going to do a comparison of right before/after the OpenStack version switch to remove as many factors as possible. | |
| 19:08:43 | cfriesen | mriedem: things as basic as nova-compute downloading an image from glance take more than twice as long | |
| 19:09:04 | sean-k-mooney | mriedem: damb you are overflowing a long in a enum that is bizar | |
| 19:09:29 | mriedem | sean-k-mooney: wasn't a problem until i had to install libpcre3-dev | |
| 19:10:43 | sean-k-mooney | maybe they chaged the type form a long long but still why would you ever need an enum that high or with that many values. there must be something else going on | |
| 19:11:01 | mriedem | i haven't done any other apt-get updates either | |
| 19:11:09 | mriedem | so shouldn't be pulling in the new python2.7 for xenial | |
| 19:12:11 | sean-k-mooney | mriedem: you didnt install any new pip pakages or downgrade them did you. pip really does not handel downgrades well so i have seen random issue in the past becase of that | |
| 19:12:25 | mriedem | no, only thing was a tox -r -e py27 | |
| 19:12:35 | mriedem | and then it was trying to install python-pcre | |
| 19:12:54 | mriedem | and i had to install libpcre3-dev for that to work | |
| 19:15:00 | sean-k-mooney | mriedem: were you looking at a partcalar patch. can an try pulling it donw in a vm i dont care too much about and see if i get teh same issue | |
| 19:15:27 | mriedem | Collecting python-pcre===0.7 (from -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt (line 440)) | |
| 19:15:28 | sean-k-mooney | that said ill be heading home in 45 mins to an hour so wont be arround too much longer | |
| 19:15:35 | mriedem | sean-k-mooney: no i'm trying to write unit tests for something | |
| 19:16:57 | sean-k-mooney | hum strange looks like there has not been an u-c bump to that for 2 months | |
| 19:17:06 | mriedem | i don't know what's pulling it in | |
| 19:19:28 | mriedem | aha! | |
| 19:19:36 | mriedem | dhellmann's whereto thing | |
| 19:19:43 | mriedem | http://git.openstack.org/cgit/openstack/whereto/tree/requirements.txt#n6 | |
| 19:20:35 | sean-k-mooney | so it got pulled in form https://github.com/openstack/nova/commit/cec0faa7111ce93b5f99622b8e6174d66b25b6d0 | |
| 19:20:41 | Roamer` | mriedem, yeah, yesterday something started depending on python-pcre and it caused some problems for most third-party CI systems that didn't have libpcre3-dev installed (although it had been in requirements/bindep.txt for quite some time), but now it's really being used | |
| 19:21:23 | mriedem | yes it's that whereto change | |
| 19:21:27 | mriedem | asking doug in -release | |
| 19:21:39 | Roamer` | right, I saw your links, but I'd already started writing that :) sorry | |
| 19:21:58 | Roamer` | but still your problem looks..... very funny | |
| 19:22:41 | sean-k-mooney | well looking at https://pypi.python.org/pypi/python-pcre it has not had a release since 2015 so it looks pretty dead | |
| 19:23:11 | sean-k-mooney | its also not tested with python 3.5 | |
| 19:25:11 | sean-k-mooney | i belived python had pretty good regex support natively does where to really need PCRE | |
| 19:26:50 | jroll | I was wondering that too, but the commit message makes sense: https://github.com/openstack/whereto/commit/797cb67a37d67e41b2caa57aeeb6307b75b66bc8 | |
| 19:27:42 | mriedem | i commented out whereto, rebuilt and still hitting this overflow error... | |
| 19:28:32 | jroll | well, that enum certainly is bigger than a C long (32 bits) https://github.com/openstack/nova/blob/master/nova/console/rfb/auth.py#L40 | |
| 19:28:39 | jroll | but that code is 6 months old | |
| 19:28:57 | sean-k-mooney | jroll: weel a long is not normally 32bit | |
| 19:29:08 | sean-k-mooney | and it is | |
| 19:29:17 | mriedem | jroll: that code just merged within the last 2 weeks, | |
| 19:29:21 | sean-k-mooney | but now a long is typically 128bits | |
| 19:29:25 | mriedem | the commit was written 6 months ago | |
| 19:29:32 | jroll | ah | |
| 19:29:40 | jroll | sean-k-mooney: oh right, 32 bits is the minimum in the spec | |
| 19:30:23 | sean-k-mooney | jroll: on a 32 bit arch yes on 64bit a long is at least the size of an int so minium would be 64bit | |
| 19:31:17 | jroll | nod | |
| 19:32:46 | mriedem | this is a 32 bit vm i guess, so that's my problem | |
| 19:32:55 | jroll | woo | |
| 19:34:00 | jroll | :P | |
| 19:35:08 | Roamer` | sean-k-mooney, actually it depends on the architecture, there are some really crazy ones, like e.g. x86_64, where a long is 64 bits, but an int is still 32 bits :) | |
| 19:36:47 | Roamer` | (this one really caught me off-guard some years ago when I was writing something quite close to the hardware and didn't even think to check sizeof(int) until a coworker pointed it out to me) | |
| 19:41:51 | openstackgerrit | Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/537171 | |
| 20:08:36 | openstackgerrit | Sen Yang proposed openstack/python-novaclient master: Implement hypervisor hostname exact patten match for server cold migrate https://review.openstack.org/520187 | |
| 20:17:53 | chris___ | Hey Guys, does anyone know how to disable non-admin users from taking snapshots via horizon in openstack juno? I'm looking in the /etc/nova/policy.json file, but I don't see anything related to compute:snapshots, only compute:volume_snapshot_create | |
| 20:23:08 | jgwentworth | chris___: I think it's called create_image | |
| 20:25:23 | sean-k-mooney | Roamer`: actully yes but x86_64 even depends on the os i was reading this a while back. https://wiki.osdev.org/X86-64#Data_Types so linux should have a 64 bit long on x86_64. if you are on power or arm totally different. that is why c++ 11 and c 11 standards introduced the fixed with integer types http://en.cppreference.com/w/cpp/types/integer | |
| 20:25:24 | jgwentworth | hm, looks like back in juno it wasn't controllable via policy | |
| 20:26:13 | sean-k-mooney | Roamer`: anyway time to head home enjoy your weekend. | |
| 20:28:21 | chris___ | jgwentworth: Thanks for the response, but i'm not seeing that parameter inside of the nova policy.json file | |
| 20:28:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle network-changed event for a specific port https://review.openstack.org/465787 | |
| 20:28:31 | mriedem | cfriesen: finally added tests for this ^ | |
| 20:28:57 | jgwentworth | chris___: yeah, I posted another message saying back in juno it looks like it wasn't controllable via policy. I see it was possible starting in liberty | |
| 20:30:08 | sean-k-mooney | chris___: since it apprently was not supported. if you run nova's api under appache or have a loadplancer in front of it you might need to add a redirect rule that will block the api endpoint form public ips. | |
| 20:31:10 | sean-k-mooney | chris___: you should be able to match on the url and return a 404 or other message at the webserver level before it hits the openstack api as a workaround | |
| 20:34:16 | chris___ | jgwentworth: sean-k-mooney: Thanks for the replies, i might look into that for the time being | |
| 20:44:45 | jgwentworth | mriedem: I've been noticing frequent timeouts on the functional test job. I was thinking, I wonder if we should split the api samples into their own job? I already feel like they should be removed from a normal 'tox -e functional' run considering they have their own tox target 'api-samples' | |
| 20:45:28 | mriedem | https://review.openstack.org/#/c/537933/ | |
| 20:46:01 | mriedem | ^ increases functional job timeout, but doesn't split them up | |
| 20:47:43 | jgwentworth | mriedem: yeah, we should definitely do that. I was just wondering if it might help to split them up longer term | |
| 20:50:34 | mriedem | yeah maybe, | |
| 20:50:45 | mriedem | i know i don't run the full functional very often b/c of the api-samples tests | |
| 20:53:42 | jgwentworth | same | |
| 20:54:38 | jgwentworth | I was just thinking we could a) reduce developer pain for running non-api-sample functional tests b) keep the timeouts more sane in the future | |
| 22:25:01 | jgwentworth | the 'increase functional test job timeout' change timed out | |
| 22:25:11 | jgwentworth | on the py35 functional test job | |
| 22:28:04 | jgwentworth | and there are about a billion policy deprecated messages in the job output | |
| 22:34:08 | jgwentworth | I wonder if the deprecation messages are related to the timeouts | |
| 22:53:41 | mriedem | superdan has a patch to fix that | |
| 22:53:49 | mriedem | er superlance | |
| 22:53:56 | mriedem | https://review.openstack.org/#/c/537603/ | |
| 22:54:25 | jgwentworth | already sent them toward the gate | |
| 22:55:01 | mriedem | i've been busy getting a new dev vm setup this afternoon... | |
| 22:55:16 | mriedem | after all the 32-bit shame from earlier | |
| 22:55:33 | jgwentworth | haha | |
| 23:07:53 | penick | Someone took my junoman nick, dang | |
| 23:16:08 | mriedem | welp, looks like most of the approved stuff is all happily waiting or chugging through the gate now | |
| #openstack-nova - 2018-01-27 | |||
| 00:02:01 | openstackgerrit | melanie witt proposed openstack/nova master: Reduce policy deprecation warnings in test runs https://review.openstack.org/537603 | |
| 00:02:02 | openstackgerrit | melanie witt proposed openstack/nova master: Remove deprecated policy items from fake_policy https://review.openstack.org/537600 | |
| 00:15:51 | openstackgerrit | Merged openstack/nova master: Deprecate allowed_direct_url_schemes and nova.image.download.modules https://review.openstack.org/510195 | |