Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-26
16:39:04 sean-k-mooney mriedem: oh on that am is it ok to propose the feature bases schduling spec for rocky since its defered or would you like me to hold off until ater the release to re propose the spec
16:39:41 mriedem re-proposing specs for rocky right now is fine
16:46:20 sean-k-mooney mriedem: cool will do i know we need to focus on getting queens out the door so dont want to cause un needed churn. ill upoald the latest version fo the code too and set a -1 on it unill master reopens for rocky after the PTG thanks :)
17:03:50 mriedem python-pcre must be new?
17:06:52 mriedem not sure what's pulling that in, but now i need libpcre3-dev installed
17:10:50 leakypipes mriedem: just noticed that too...
17:12:13 fried_rice Not something I ever thought I would be happy to say, but my patches are now failing in a couple of hours.
17:12:33 figleaf fried_rice: efficient!
17:12:52 fried_rice The gate is officially giving me the finger: build-openstack-sphinx-docs finger://ze05.openstack.org/c5b1d14f3fa944388c1e6d0979203466 : POST_FAILURE in 6m 55s
17:25:11 openstackgerrit Jay Pipes proposed openstack/nova master: only increment disk address unit for scsi devices https://review.openstack.org/538310
17:27:09 cfriesen is anyone doing performance testing release-over-release? We just did a test where launching an instance took over 3x as long on Pike as it did on Newton. Still working to characterize.
17:32:56 leakypipes cfriesen: nope, not that I know of.
17:33:40 leakypipes cfriesen: just make sure you're accounting for all the many things that may have changed, including versions of libvirt/QEMU, operating system, etvc
17:50:36 openstackgerrit James E. Blair proposed openstack/nova master: DNM: test if tempest-full is triggered or not https://review.openstack.org/537936
17:59:30 openstackgerrit Sen Yang proposed openstack/python-novaclient master: Implement hypervisor hostname exact patten match for server cold migrate https://review.openstack.org/520187
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 File "/home/user/git/nova/.tox/py27/local/lib/python2.7/site-packages/enum/__init__.py", line 230, in __new__
19:05:30 mriedem enum_member = __new__(enum_class, *args)
19:05:30 mriedem OverflowError: Python int too large to convert to C long
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

Earlier   Later