| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-01 | |||
| 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 | |
| 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 | |