| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 17:33:10 | stephenfin | Yup | |
| 17:33:23 | bauzas | like CPUs | |
| 17:33:42 | bauzas | ie. I have a 2-sockets with 4 cores each, HT | |
| 17:33:43 | stephenfin | But remember, hugepages are essentially normal memory | |
| 17:33:50 | stephenfin | You can have 4k huge pages | |
| 17:34:04 | stephenfin | *"huge pages" | |
| 17:34:13 | stephenfin | We currently have open bugs around not tracking that stuff correctly | |
| 17:34:16 | bauzas | in that case, I'd have 2 NUMA nodes with 8 CPUs each | |
| 17:34:30 | stephenfin | Yup | |
| 17:34:40 | openstackgerrit | Merged openstack/nova master: crypto: Remove unused functions https://review.openstack.org/550772 | |
| 17:34:55 | bauzas | ie. 2 child RPs, with each of those having some memory and a VCPU RC of 8 | |
| 17:35:14 | bauzas | ok, I'm going to model this | |
| 17:35:26 | bauzas | stephenfin: hugepages sound a different resource class, right? | |
| 17:36:02 | bauzas | stephenfin: https://blueprints.launchpad.net/nova/+spec/numa-topology-with-rps is the boilerplate | |
| 17:36:57 | stephenfin | bauzas: Yup, but I don't know if we have any way to identify 4k "huge pages" from normal, non huge-page memory | |
| 17:37:08 | stephenfin | I need to root out those bugs to get the full context again | |
| 17:37:22 | bauzas | right | |
| 17:37:46 | melwitt | mriedem: on https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications, I'm not sure we want to notify about server group member removal upon overquota. the "remove server group member" is not a public API and the overquota in this case would be the one that occurs during a quota recheck, and I didn't think we'd want to expose that to an end user | |
| 17:38:35 | stephenfin | bauzas: Enjoy drafting that. I'm off for a run o/ | |
| 17:38:47 | melwitt | mriedem: guess I'll comment on the bp whiteboard | |
| 17:39:52 | openstackgerrit | Merged openstack/nova master: ca: Remove 'nova/CA' directory https://review.openstack.org/550773 | |
| 17:40:09 | openstackgerrit | Merged openstack/nova master: conf: Remove 'nova.crypto' opts https://review.openstack.org/550774 | |
| 17:43:10 | jaypipes | cdent: done | |
| 17:43:47 | lyarwood | stephenfin: https://docs.openstack.org/nova/latest/configuration/config.html - under passthrough_whitelist - are the quotes all rendering as unicode left “ and right ” quotation marks for you? Have a guess what this does if you copy things into nova.conf ^_^ | |
| 17:45:08 | efried | I have never found smart quotes to be as advertised. | |
| 17:45:17 | cdent | thanks jaypipes | |
| 17:46:27 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 17:54:53 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Make archive_deleted_rows handle a missing CONF.api_database.connection https://review.openstack.org/550967 | |
| 17:59:45 | jaypipes | dansmith: not sure I follow you with "dynamic section like cinder does for backends". could you clue me in on that with a link to what you're referring to? | |
| 18:00:49 | dansmith | jaypipes: do you remember the discussion we had on thursday in the lunch room? | |
| 18:01:19 | dansmith | jaypipes: cinder has a thing where you define backend names, and then it assumes you have created a section in config named "backend_%(name)s", with keys in it | |
| 18:01:24 | jaypipes | dansmith: I don't believe I was there, no. (I don't remember sharing lunch with you on any of the days) | |
| 18:01:34 | dansmith | which is a way to encode dicts in ini format in less nasty form | |
| 18:01:42 | dansmith | jaypipes: I was speaking directly to you, you were there :) | |
| 18:01:56 | jaypipes | dansmith: which soup was it? :) | |
| 18:01:57 | cdent | that was the twin | |
| 18:02:04 | dansmith | this was when we relocated to the lunch room of the hotel on thursday afternoon for the neutron discussion | |
| 18:02:11 | dansmith | jaypipes: no soup, it was not over lunch | |
| 18:03:26 | jaypipes | k. gibi had indeed brought up the option of doing something like physnet_mapping_%(physnetname)s instead of a single config option. I wasn't keen on that. | |
| 18:03:36 | jaypipes | dansmith: sorry, I just don't remember that conversation :( | |
| 18:04:10 | dansmith | I _hate_ encoding json in our config files | |
| 18:04:14 | dansmith | I think it's a pain we should not inflict on humans | |
| 18:04:35 | dansmith | there's prior art for this in at least cinder | |
| 18:05:14 | dansmith | we previously broke operators with the pci whitelist when we accidentally changed the format from a list to a dict, because it was json and thus obscure that anything was changing | |
| 18:05:28 | dansmith | that caused people a lot of pain, on top of the pain required to view/edit it in general | |
| 18:05:30 | jaypipes | dansmith: so we'd have multiple options like this? physnet_mapping_physnet0_name = "tenant_data_0"; physnet_mapping_physnet0_numa_nodes = 0,1; | |
| 18:05:49 | jaypipes | dansmith: personally I find encoded that to be less nice than just putting it in a JSON blob. | |
| 18:06:08 | dansmith | no | |
| 18:06:28 | mriedem | melwitt: notifications are on the rpc queue, so the user wouldn't see them... | |
| 18:07:06 | dansmith | jaypipes: https://pastebin.com/zP7eyAZw | |
| 18:07:06 | jaypipes | dansmith: mind etherpadding up your proposed conf option format? | |
| 18:07:10 | jaypipes | lol | |
| 18:07:12 | jaypipes | jinx | |
| 18:07:15 | mriedem | unless you mean user = admin/operator looking at notifications; as for the actual usefulness of that specific case, i don't think it's really useful either since it's normal during a quota recheck | |
| 18:07:19 | jaypipes | always ten steps ahead of me :) | |
| 18:07:26 | mriedem | i.e. we don't send a versioned notification when server create fails due to overquota on ram/cpu | |
| 18:07:45 | jaypipes | dansmith: heh, ok. sure, I can go for that. | |
| 18:07:58 | jaypipes | dansmith: excellent use of the words "bloopy" and "poopy" | |
| 18:08:23 | dansmith | um, excuse me. | |
| 18:08:26 | dansmith | it's "boopy" | |
| 18:08:34 | jaypipes | oh, my mistake. yes, boopy. | |
| 18:09:37 | mriedem | lyarwood: i don't see the problem, clear as day https://docs.openstack.org/nova/latest/configuration/config.html#pci.passthrough_whitelist | |
| 18:09:44 | jaypipes | dansmith: k. added a link on the spec and mentioned I could go for that. | |
| 18:09:57 | dansmith | ack | |
| 18:14:40 | lyarwood | mriedem: so for me that renders with unicode quotes that when copied into nova.conf makes n-cpu bork | |
| 18:16:02 | mriedem | lyarwood: i was joking, of course it does | |
| 18:17:05 | lyarwood | wunderbar | |
| 18:17:20 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/pci.py#L66 all looks pretty normal to me though | |
| 18:19:13 | edleafe | dansmith: I assume that all microversion changes, placement or not, require a reno | |
| 18:19:47 | dansmith | edleafe: okay I thought just a spec, but I don't really review that many api changes | |
| 18:23:31 | mriedem | arvindn05: comments on https://review.openstack.org/#/c/541507/ | |
| 18:23:49 | mriedem | arvindn05: i don't think we can simply pass through "trait:*" to the ImageMetaProps object, | |
| 18:23:57 | mriedem | if you haven't yet noticed, the fields in that object are strictly defined | |
| 18:24:10 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249 | |
| 18:24:11 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: Return new provider from POST /rps https://review.openstack.org/548934 | |
| 18:24:11 | openstackgerrit | Eric Fried proposed openstack/nova master: Stop assuming initial provider generation is 0 https://review.openstack.org/548975 | |
| 18:24:11 | mriedem | therefore "trait:CUSTOM_FOOBARS" is going to explode if you try to hydrate it into that object | |
| 18:24:44 | mriedem | so traits in flavors is != traits in image properties because of the wild west vs strict nature of the two | |
| 18:27:37 | mriedem | edleafe: this isn't pointing at the correct blueprint https://review.openstack.org/#/c/552098/ | |
| 18:31:07 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Marker reset option for nova-manage map_instances https://review.openstack.org/539501 | |
| 18:34:44 | dansmith | mriedem: it's not? | |
| 18:35:01 | dansmith | oh, I see | |
| 18:35:20 | dansmith | it's for mine, but we did a different spec for it because api | |
| 18:39:07 | edleafe | dansmith: I'm confused. I thought this was on the same BP as yours | |
| 18:39:39 | mriedem | it's a dependency | |
| 18:39:40 | dansmith | edleafe: we did a spec for it specifically because of the api change, which is technically a different blueprint in launchpad | |
| 18:39:56 | dansmith | edleafe: but I know, it seemed right to me as well | |
| 18:42:02 | edleafe | dansmith: ok, found it | |
| 18:42:09 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 18:42:18 | edleafe | pushed a new rev, with correct BP and shiny new reno | |
| 18:54:56 | melwitt | mriedem: yeah, I was thinking the quota recheck stuff is supposed to be transparent, though the more I thought about it I realized I think some behavior changed, for example, with multi-create, where overquota during recheck results in ERROR instances where it didn't before. but agreed we don't send server delete notifications for a server create fail for overquota during a recheck | |
| 18:55:37 | mriedem | melwitt: "with multi-create, where overquota during recheck results in ERROR instances where it didn't before" - Kevin_Zheng brought that up in denver at the queens ptg | |
| 18:55:40 | mriedem | and was mostly written off | |
| 18:56:14 | mriedem | just reno'ed for now https://docs.openstack.org/releasenotes/nova/pike.html#known-issues | |
| 18:56:16 | melwitt | yeah, I remember. I thought it was worth handling (to not change the behavior) but I think I was not in the majority opinion about it | |
| 18:57:34 | melwitt | I was aware of putting the instances in ERROR state but for whatever reason at the time, I didn't realize that meant things used to fail in the API before | |
| 18:57:59 | mriedem | we fail either way, | |
| 18:58:12 | mriedem | the difference is before you didn't have 50 instances in ERROR state that you had to manually clean up | |
| 19:00:37 | melwitt | yeah, that's what I meant, fail in the API without creating instances. and we can't just delete them instead of putting them into ERROR state because we have no other way to signal the create failed after the API returned a 202 | |
| 19:01:51 | melwitt | so then we were talking about counting build requests along with instances with de-duping I think. I think it would be worth it to avoid manual cleanup for users. but I think the other argument was that operators could turn off quota recheck | |