| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-01 | |||
| 15:25:50 | mriedem | not sure how to find out our default http response timeout | |
| 15:26:03 | superdan | mriedem: ^ | |
| 15:26:12 | mriedem | superdan: i know, already -1ed :) | |
| 15:26:56 | mriedem | or is the http response timeout configurable in uwsgi | |
| 15:26:58 | mriedem | ? | |
| 15:27:21 | superdan | mriedem: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L707 | |
| 15:27:36 | mriedem | superdan: that's not what you want | |
| 15:27:39 | mriedem | that's the nodename | |
| 15:27:44 | mriedem | ComputeNode.host is the hostname | |
| 15:28:02 | mriedem | it's totally confusing | |
| 15:28:45 | superdan | um | |
| 15:30:08 | superdan | I thought get_all_by_host was by service hostname | |
| 15:30:17 | superdan | why else would be it a multi-return? | |
| 15:30:25 | superdan | I feel like I've made this mistake like eight times | |
| 15:30:59 | mriedem | let me see what the actual HostMapping.host field is set from | |
| 15:31:07 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 15:31:07 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 15:31:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 15:31:20 | mriedem | cell_mapping=cm) | |
| 15:31:20 | mriedem | ctxt, host=compute.host, | |
| 15:31:20 | mriedem | host_mapping = HostMapping( | |
| 15:31:30 | mriedem | in _check_and_create_host_mappings | |
| 15:36:52 | superdan | oh hypervisor_hostnme is actually the node uuid for ironic isn't it | |
| 15:36:58 | superdan | gawd why can't we call things what they are | |
| 15:38:06 | cdent | superdan++ | |
| 15:41:14 | superdan | well, regardless, hostmapping uses cn.host | |
| 15:41:21 | superdan | so that's what I want anyway | |
| 15:43:44 | mriedem | superdan: ? so you're going to use get_by_hypervisor? | |
| 15:43:54 | superdan | no I mean the .host field | |
| 15:44:02 | superdan | I really thought .host was the service host | |
| 15:44:11 | superdan | because we have get_by_host_and_node | |
| 15:44:48 | superdan | I'm doing this all whilst on a call, which I really shouldn't do | |
| 15:44:49 | mriedem | what gets passed to delete_host is the computenode.host, so you have to use ComputeNodeList.get_all_by_host, yes? | |
| 15:44:52 | mriedem | ok | |
| 15:45:06 | mriedem | the only time this would return more than 1 node is ironic | |
| 15:45:26 | openstackgerrit | Merged openstack/nova stable/pike: Fix ValueError when loading old pci device record https://review.openstack.org/524157 | |
| 15:45:35 | superdan | that's what I mean, what we pass is what is in hostmapping.host, which is populated from computenode.host | |
| 15:46:16 | superdan | which I guess is the service hostname | |
| 15:46:55 | mriedem | yeah, it's what comes from CONF.host | |
| 15:47:12 | superdan | I really didn't think that's what was in hostmapping | |
| 15:53:35 | openstackgerrit | Dan Smith proposed openstack/nova master: Unmap compute nodes when deleting host mapping https://review.openstack.org/524641 | |
| 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 | |