Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-01
15:53:36 superdan mriedem: try that
15:57:14 bauzas superdan: mriedem: yeah, so the compute service hostname is the host, and the Ironic node UUID is the hypervisor_hostname
15:57:54 bauzas so, when we get all the nodes for a host, we should get all the ironic nodes related to the specific nova compute
15:58:07 superdan yeah, that's not really the confusion,
15:58:12 superdan it's what was in hostmapping.host for me,
15:58:18 superdan and I thought it was the node
15:58:25 bauzas ah no, unfortunatel
15:58:28 bauzas indeed
15:59:43 bauzas and yeah, the main reason why we don't modify the field to be "node" instead of "hypervisor_hostname" is because it would be a huge change
15:59:44 mriedem superdan: want to fix the alignment in the test?
16:00:04 mriedem putting comments next to the fields in the code would probably help
16:00:10 mriedem "THIS IS THE NODENAME!!!:
16:00:25 superdan alignment imported from the code I copied from above, but sure
16:00:37 mriedem two wrongs don't make a right dan
16:01:28 mriedem unless you're feeding bacon to a pig
16:01:39 openstackgerrit Dan Smith proposed openstack/nova master: Unmap compute nodes when deleting host mapping https://review.openstack.org/524641
16:08:03 mriedem lyarwood: https://bugs.launchpad.net/nova/+bug/1735780
16:08:04 openstack Launchpad bug 1735780 in OpenStack Compute (nova) "n-cpu logs error "is not a valid LUKS device"" [Undecided,Confirmed]
16:08:09 mriedem http://logs.openstack.org/26/515426/1/check/legacy-tempest-dsvm-neutron-full/e6ac116/logs/screen-n-cpu.txt.gz#_Dec_01_14_06_49_142977
16:17:17 lyarwood mriedem: looking
16:19:07 lyarwood mriedem: so that's normal, search for cryptsetup below that and you can see we format and then open it correctly
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 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:14 cdent but I think systemd’s journalctl doesn’t want me to feel that way
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

Earlier   Later