Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-01
16:19:26 mriedem lyarwood: :(
16:19:35 mriedem i guess that's why it's a stacktrace at debug rather than error?
16:19:44 mriedem which is i think a thing i've seen with privsep before
16:20:12 lyarwood https://github.com/openstack/os-brick/blob/master/os_brick/encryptors/luks.py#L150-L161
16:20:35 lyarwood mriedem: yeah I think so
16:22:58 openstackgerrit Edward Hope-Morley proposed openstack/nova-specs master: Add spec for extending Aggregate scheduling capabilties. https://review.openstack.org/524664
16:25:40 cdent fried_rice: next time you make a bug like https://bugs.launchpad.net/nova/+bug/1735430 please feel free to add the placement and/or resource-tracker tags to it, for sake of search visibility (I’ve done it for that one)
16:25:41 openstack Launchpad bug 1735430 in OpenStack Compute (nova) pike "Report client doesn't handle RP create conflict (409) properly" [Medium,In progress] - Assigned to Eric Fried (efried)
16:28:02 fried_rice cdent Okay, I did ask mriedem about that yesterday and he didn't seem to think it mattered. The question specifically was: do we need the `placement` tag on stuff like this or just on things that are server-side?
16:29:07 cdent “need” is a big word that probably doesn’t fit here, but “nice” is handy from the visibility side. I tend to think it’s a useful tag for anything that’s interacting with the placement service (or is the service) and I use it for finding stuff for the report (which is why it came up just now)
16:31:02 mriedem this is kind of funny https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/attach_interfaces.py#L150
16:31:13 mriedem here, let me convert this 500 to a 500 for you
16:31:24 cdent sigh
16:31:26 mriedem @extensions.expected_errors((400, 404, 409, 500, 501))
16:32:32 cdent well that was 5 years ago, we’ve gotten a lot more verbose about what’s right since then
16:35:44 mriedem oh i think i might know why it's doing this,
16:36:12 mriedem because we don't "expect" this exception over rpc, so what you get back is the InstanceAttachFailed_Remote error, which hides the original error message
16:44:50 fried_rice Quick poll: CI logs closer to the coloration you would see from the console: http://184.172.12.213/16/524316/1/check/nova-out-of-tree-pvm/f0d1b76/logs/n-cpu.txt.gz
16:45:00 cdent no
16:45:32 fried_rice cdent Care to elaborate?
16:46:06 cdent a) I don’t like black backgrounds, b) neon colors against black backgrounds are scary, I (for real) flinched when that page loaded
16:46:16 superdan fried_rice: that's fairly hard to read, IMHO
16:48:36 cdent fried_rice: if you’re after changing the colors, then perhaps something in the solarized pallette might be nice, but a) I don’t reckon the existing norm is far off from okay, b) I turn off colorization wherever possible so I’m not the target audience so ignore most of what I say on this topic because I’m an old grape in the path of the steamroller
16:49:21 fried_rice Okay, thanks cdent and superdan. FYI, where I'm actually going with this is the ability to interpret ANSI color codes in the HTMLification. The idea was so they would look exactly the same as they do on the console. I ought to have a sample of that by this afternoon.
16:49:39 superdan fried_rice: not everyone has their console configured the same, you know
16:49:45 superdan I don't use a dark background for example
16:49:57 cdent yeah, personally I’d prefer that the logs never have ansi codes in them
16:50:14 cdent but I think systemd’s journalctl doesn’t want me to feel that way
16:50:14 superdan I also use the solarized theme for all of this kind of ting, which is super low impact, especially compared to what you've got here
16:50:15 fried_rice cdent You can make that happen by leaving -a off of journalctl
16:50:30 fried_rice superdan What is this "solarized" theme?
16:50:44 superdan fried_rice: http://ethanschoonover.com/solarized
16:50:48 cdent fried_rice: right, but my point is that if I download a log from CI, it should _not_ be doctored
16:51:05 cdent if the CI is including ansi, then I end up with a mess
16:51:33 fried_rice cdent Hum, right. See, to me that's what I *do* want, which is why I started this whole thing.
16:51:50 cdent (see b) abve)
16:52:29 fried_rice I only know how to make code-included logs show up colorized. But there must be a way to just strip out the color codes.
16:52:30 cdent ansi escape sequences in log strings strikes me as some kind of weird punishment
16:52:42 cdent probably
16:52:44 fried_rice Oh, jeez, I feel they make it WAY more readable.
16:53:23 superdan they do sometimes, but other times they get in the way depending on how you're looking at it
16:53:34 superdan if I need to open it in an editor or something to apply a macro or something,
16:53:37 superdan then it's a total mess
16:53:58 superdan if I can have the option, then cool. if I have no option, I'd lean towards clean logs
17:03:52 openstackgerrit Matthew Booth proposed openstack/nova master: Fix disk size during live migration with disk over-commit https://review.openstack.org/524681
17:06:30 figleaf mriedem: just got back from having my teeth scraped. Reading back, yeah, 409 seems like the best choice
17:09:01 cdent when you say it like that, it gives me the fingernails chalkboard sensation, or the styrofoam on cardboard things. thank you very little
17:09:30 mriedem i had that done on tuesday
17:09:33 mriedem so refreshing
17:25:15 mriedem oh shelve http://lists.openstack.org/pipermail/openstack-dev/2017-December/125124.html
17:25:19 mriedem you'll be the death of me
17:25:23 mriedem alaski: ^ maybe you have ideas
17:25:26 mriedem from 2013
17:27:06 cdent shelve-tastic
17:31:41 mriedem fried_rolls: failure here looks real
17:31:42 mriedem https://review.openstack.org/#/c/524618/
17:31:45 mriedem http://logs.openstack.org/18/524618/1/check/openstack-tox-functional/81f3dd8/testr_results.html.gz
17:31:51 mriedem cur_rp_gen = self._resource_providers[rp_uuid]['generation'] TypeError: 'NoneType' object has no attribute '__getitem__'
17:32:44 mriedem superdan: want to push this through stable? else i will https://review.openstack.org/#/c/509961
17:33:29 superdan not really, but I will
17:33:49 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix incorrect known vcpuset when CPUPinningUnknown raised https://review.openstack.org/523644
17:39:10 mriedem johnthetubaguy: bauzas: lyarwood: if you're still around, we should get these in https://review.openstack.org/#/q/I1a46ef1503be2febcd20f4594f44344d05525446
17:39:24 mriedem fixes a regression introduced in a cve fix from a week or two ago
17:45:34 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix TypeError of _get_project_id when project_id is None https://review.openstack.org/524687
17:46:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Vzstorage: synchronize volume connect https://review.openstack.org/524688
17:50:50 johnthetubaguy mriedem: seems important, +2
17:51:20 mriedem thanks
17:54:43 alaski mriedem: so the idea with unshelving was that it should look like nothing had happened. So you boot instance from image A, image_ref points at A. Resize/migration should work. You shelve/offload/unshelve and have an instance running again, with image_ref A. It's supposed to be like nothing happened so resize/migration should still work. What's unclear to me, since I've been out of the loop for a bit,
17:54:45 alaski is why resize/migration fails specifically after an unshelve.
17:57:04 alaski I think the argument against updating image_ref was that something like a rebuild should use the original image, not the snapshot. But outside of that I don't recall any reasons not to update the image_ref
17:58:16 mriedem ok so create with image A, shelve to create image B, unshelve with image B, rebuild with image A again
17:58:58 alaski yeah. image B is an artifact of shelving but from a user point of view it never really exists.
17:59:25 mriedem hmm, except it does, until we delete it
17:59:43 alaski shelve/unshelve ideally has the vm exactly as it was before shelving, no updates to the vm at all.
17:59:46 mriedem anywho, thanks, didn't think about the rebuild thing, but this all seems very slight of hand and confusing
18:00:01 mriedem well,
18:00:11 mriedem we still don't do that properly with volumes and ports completely i don't think
18:00:17 alaski yes, that whole feature is very much slight of hand and confusing
18:00:29 mriedem i will think on those over a 1000 calorie burrito
18:01:59 alaski "ideally" that's how shelve works, in practice it clearly does not. I won't claim that the ideal is achievable, so it may be better to be pragmatic and just document it well.
18:02:43 alaski maybe you'll come out of your food coma with an epiphany
18:08:39 openstackgerrit Peter Penchev proposed openstack/nova master: Add the Nova libvirt StorPool attachment driver. https://review.openstack.org/140733
18:22:38 rabel hi there. i need your thoughts on my last comment to https://review.openstack.org/#/c/402632/12 :) . it is about the datastore selection in vmware driver.
18:27:17 cdent rabel: I suspect rgerganov is going to be best placed to answer that and he won’t be back around until Monday, but I can try to make sure he sees it
18:29:31 rabel cdent: that would be great. thank you
18:29:43 cdent ✔
19:15:28 openstackgerrit Merged openstack/nova stable/pike: Log consumer uuid when retrying claims in the scheduler https://review.openstack.org/509961
19:16:55 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
19:16:55 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
19:23:21 sdaniel_ Hi, I need some help about nova services :(
19:29:23 openstackgerrit Jackie Truong proposed openstack/python-novaclient master: Microversion 2.57 - Add trusted_image_certificates https://review.openstack.org/500396
19:29:59 openstackgerrit Chris Dent proposed openstack/nova master: [placement] re-use existing conf with auth token middleware https://review.openstack.org/523403
19:30:39 cdent mriedem: I came up with a somewhat different approach for the test of that ^ because the middleware is very kwargy instead of a attrtibutey
19:34:09 sdaniel_ I had to reconfigurate the network type from provider to self-service
19:34:30 sdaniel_ and after that know of my nova services won't come up
19:34:44 sdaniel_ (after i restarted them manually)
19:35:28 sdaniel_ I re-created the whole nova DBs and re-installed the nova packages, but nothing helped
19:36:42 sdaniel_ I cant restart the services
19:36:50 sdaniel_ I got this error in syslog: TypeError: __init__() got an unexpected keyword argument 'retry_on_request'
19:37:17 sdaniel_ Only just nova cant restart, neutron can

Earlier   Later