| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-14 | |||
| 14:42:30 | stephenfin | ShilpaSD: If you fancy making that change to the default, we can see if DevStack is happy. That will ensure we're OK with 0.6 | |
| 14:43:31 | stephenfin | ShilpaSD: I already have a DevStack change up to bump noVNC 1.0. I can make this change 'Depends-on' your one | |
| 14:48:53 | ShilpaSD | stephenfin: that will be great, but still one more query | |
| 14:49:01 | stephenfin | Shoot | |
| 14:49:03 | ShilpaSD | stephenfin: /opt/stack/nova/nova/tests/functional/api_sample_tests/api_samples/os-remote-consoles/get-vnc-console-post-resp.json.tpl....here also need to make that change? since functionaly TC using that | |
| 14:49:19 | ShilpaSD | /opt/stack/nova/doc/api_samples/os-remote-consoles/get-vnc-console-post-resp.json | |
| 14:49:38 | stephenfin | ShilpaSD: Already done https://review.openstack.org/#/c/550173/ | |
| 14:50:00 | stephenfin | Well, those are wrong. You can take that patch and fix it up, if you like | |
| 14:50:21 | stephenfin | Or I'll rebase it onto whatever you do. You just need to modify nova/conf/pci.py and add a release note | |
| 14:51:35 | stephenfin | lyarwood: Regarding https://review.openstack.org/#/c/552874/, I think that's a bug in oslo_config.sphinxext. The rST is correct. | |
| 14:51:46 | stephenfin | If I were to guess, we're not doing a nested parse | |
| 14:53:41 | ShilpaSD | stephenfin: thnak you for clarification, will get back to you on what action i am taking aginst this | |
| 14:54:15 | stephenfin | (y) | |
| 14:54:31 | sean-k-mooney | mriedem: stephenfin just looking at https://review.openstack.org/#/c/548525/1 the few runs of kuryr-kubernetes-tempest-daemon-octavia i have see so far against os-vif seam a little flaky. | |
| 14:55:03 | sean-k-mooney | mriedem: stephenfin we may want to consider makeing it non voting if it contiues. ill keep an eye on it | |
| 14:56:05 | purplerbot | <efried> mriedem: Yes. We talked about it in Dublin. On Wednesday IIRC. And agreed to add a generation field to the allocations table. jaypipes probably has more of it in his head. Not sure who's on the hook to do the spec/work. [2018-03-14 14:33:08.634568] [n 1LbC] | |
| 14:56:05 | cdent | efried: re [t 1LbC] wasn't it to the consumer table? | |
| 14:56:39 | efried | cdent: Could be, sure. I'm not very familiar with the tables related to allocations. | |
| 14:56:53 | efried | and don't remember the conversation exactly | |
| 14:56:56 | efried | but I bet it's in the etherpad. | |
| 14:57:36 | sean-k-mooney | stephenfin: mriedem for example it failed https://review.openstack.org/#/c/476612/ becase the tempest regex elminated all tests http://logs.openstack.org/12/476612/30/check/kuryr-kubernetes-tempest-daemon-octavia/576bfad/job-output.txt.gz#_2018-03-13_07_42_00_900216 and it did not publish results on https://review.openstack.org/#/c/482226/20 at all. | |
| 14:58:02 | stephenfin | sean-k-mooney: Indeed. There was a thing on openstack-dev about it earlier in the week. Apparently some neutron (?) change has broken it | |
| 14:58:17 | stephenfin | sean-k-mooney: Agreed though. Let's keep an eye on it | |
| 14:59:08 | sean-k-mooney | stephenfin: well those two need other work to be mergable first but i would prefer to make it non voteing instead of blocking other changes to os-vif that may be need in the future. | |
| 15:00:32 | sean-k-mooney | stephenfin: its not blocking anything currently hence lets wait and see. legacy-tempest-dsvm-nova-os-vif on the other had we might want to make voteing or rework for zuul v3 | |
| 15:06:24 | Kevin_Zheng | mriedem gibi thanks alot | |
| 15:24:28 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 15:25:07 | bauzas | stephenfin: edleafe: jaypipes: dansmith: efried: you could be interested in https://review.openstack.org/552924 (NUMA topology with RPs) | |
| 15:25:29 | bauzas | I just have a shitty docs problem that I don't see why | |
| 15:26:18 | efried | bauzas: Added to review list. | |
| 15:26:30 | efried | bauzas: You're having trouble getting the doc to build? | |
| 15:26:37 | bauzas | yep | |
| 15:27:25 | bauzas | nvm, found the issue | |
| 15:27:27 | bauzas | PEBKAC | |
| 15:27:56 | efried | yep, indent that graphic | |
| 15:28:06 | bauzas | yeah, missed the code directive | |
| 15:28:19 | efried | ...and the next one. | |
| 15:28:23 | efried | Oh, or that. | |
| 15:28:58 | efried | and an extra newline around L138 | |
| 15:29:14 | efried | and 150 | |
| 15:29:28 | efried | and 178 | |
| 15:29:41 | efried | bauzas: With those fixed, it builds for me. | |
| 15:30:08 | efried | bauzas: btw, not sure how you're building locally, but I use this to cut build time down to a sub-second: | |
| 15:30:18 | efried | set -x; | |
| 15:30:18 | efried | ( . .tox/docs/bin/activate || return; | |
| 15:30:18 | efried | rele=${1:-rocky}; | |
| 15:30:18 | efried | { | |
| 15:30:18 | efried | specs () | |
| 15:30:19 | efried | find doc/build/html -type f -name '*.html' | xargs realpath ) | |
| 15:30:19 | efried | python setup.py build_sphinx -s doc/source/specs/$rele -c doc/source || return; | |
| 15:30:20 | efried | } | |
| 15:30:24 | stephenfin | bauzas: Also, single-backticks aren't really valid rST. They mean default role which just happens to be italics in current Sphinx. No reason that won't change going forward though (they do tend to break stuff often) | |
| 15:30:38 | stephenfin | But that's a big nit :) Also placed on my review queue | |
| 15:32:27 | bauzas | thanks both of you folks | |
| 15:32:54 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Spec for isolating configuration of placement database https://review.openstack.org/552927 | |
| 15:32:58 | bauzas | stephenfin: so, for targeting links, you would recommend double-backticks ? | |
| 15:33:16 | stephenfin | bauzas: What do you mean? | |
| 15:33:24 | bauzas | (16:30:24) stephenfin: bauzas: Also, single-backticks aren't really valid rST. T | |
| 15:33:43 | stephenfin | Something like `xyz`_ or :role:`test` is valid. What's not valid is `xyz` | |
| 15:33:50 | bauzas | I used single backticks for explicit targeting | |
| 15:34:17 | bauzas | stephenfin: yeah, so I thought I did that everywhere, were have you seen a single-backtick without a link ? | |
| 15:35:12 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 15:35:38 | stephenfin | bauzas: Line 131 | |
| 15:35:57 | stephenfin | 257 too | |
| 15:36:10 | dansmith | edleafe: hey, I just noticed this went in and I'm a tad confused by it: https://review.openstack.org/#/c/539323/ | |
| 15:36:23 | stephenfin | that's about it though, actually :) Like I said, it's the nitiest of nits | |
| 15:36:24 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 15:36:35 | edleafe | dansmith: on a call now | |
| 15:36:36 | dansmith | edleafe: the uuid warning from o.vo has been around for a long time now and it seems like this is a bit of a heavy-handed way to resolve a warning | |
| 15:36:39 | dansmith | edleafe: ack | |
| 15:36:50 | dansmith | gibi: stephenfin ^ | |
| 15:37:51 | stephenfin | dansmith: Heavy handed, perhaps, but it did resolve the issue and made sense to me | |
| 15:38:24 | dansmith | stephenfin: it resolves the warning in unit tests by storing an obfuscated uuid in the database which would make it really hard to examine what is going on | |
| 15:38:42 | dansmith | that seems not sensical to me | |
| 15:39:31 | dansmith | and would break anyone who was halfway through a mapping and then walked over this | |
| 15:39:35 | dansmith | like someone doing an FFU | |
| 15:40:11 | dansmith | and.. instance uuid _is_ a uuid, so if there's a warning about the format of it, maybe the warning is wrong or something else needs to change | |
| 15:40:35 | dansmith | but munging the values (which I'm not even sure is legit uuid behavior) seems kinda silly | |
| 15:40:36 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/552774 | |
| 15:42:22 | dansmith | if you're not doing the rotation on all uuids then you're increasing your chances for collision, and since this doesn't (actual instance mappings have unrotated uuids, only the marker is rotated) | |
| 15:43:46 | dansmith | since this is munging data in the database I think I'm going to exercise fast revert | |
| 15:44:12 | stephenfin | dansmith: Gimme a sec. I'm trying to re-review this and see what my reasoning for letting it in was | |
| 15:44:51 | cdent | bauzas: I may have missed some discussion in Dublin, but what's the different between a NUMA_CORE and a VCPU and why keep track of both of them? | |
| 15:46:14 | bauzas | cdent: good question | |
| 15:46:21 | bauzas | cdent: see my alternatives section | |
| 15:47:05 | bauzas | if we shard VCPUs across NUMA nodes, then an instance spreading its cores amongst multilple NUMA nodes could have problems | |
| 15:47:09 | dansmith | mriedem: I forget, in my revert patch should I explain the problems I think there are or just do a straight revert and then discuss on a re-propose | |
| 15:47:10 | dansmith | ? | |
| 15:47:17 | cdent | bauzas: yeah, saw that, but that doesn't really answer the question. If you are counting NUMA_CORES (as a separate thing) why would you record VCPU at all? | |
| 15:47:26 | bauzas | dansmith: fast-revert and discuss later IMO | |
| 15:47:50 | dansmith | bauzas: okay that's what I was thinking too, but it's been a while | |
| 15:47:55 | bauzas | cdent: because operators that wouldn't care about NUMA things wouldn't then need to use a NUMA specific RC | |
| 15:48:55 | bauzas | dansmith: stephenfin: so I need a bit of context in order to chime in | |
| 15:49:07 | cdent | I'll have to think on that some more. Having to track the same thing multiple times doesn't seem simple to me. It may, however, be that simple is not possible. | |
| 15:49:36 | bauzas | cdent: np, I'll be on PTO till thurs starting EOB | |
| 15:49:44 | dansmith | bauzas: after further examination, rotating one uuid out of a set is not a legit thing to do to a uuid and maintain uniqueness, so I think it's flawed just on that basis alone | |
| 15:49:47 | bauzas | cdent: so take your time | |
| 15:49:52 | cdent | roger | |
| 15:50:27 | bauzas | cdent: that spec is maybe a strawman | |
| 15:50:33 | dansmith | i.e. if your key space is 0-4, and you have keys 1, 2, 3, you can't just rotate 2, or you will end up with a conflict | |