| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-14 | |||
| 16:34:59 | dansmith | bauzas: young artom will be presenting it forthwith | |
| 16:35:03 | bauzas | cool | |
| 16:35:10 | jaypipes | dansmith: sounds kinky. | |
| 16:35:19 | bauzas | oh man, I wish I could "OK jaypipes" on my phone | |
| 16:35:26 | jaypipes | lol | |
| 16:35:27 | artom | jaypipes, you got off easy, I'm his young turdgoat | |
| 16:35:35 | cdent | "fleshy mysql manual" is way too visual | |
| 16:35:40 | jaypipes | artom: yes, I read that. very flattering indeed. ;) | |
| 16:35:41 | dansmith | cdent: you're welcome | |
| 16:35:56 | cdent | clears my head nicely, thank you dansmith | |
| 16:37:42 | artom | dansmith, so I'll handle the backports - who's proposing the DB migration? | |
| 16:38:01 | dansmith | artom: you are | |
| 16:38:04 | artom | Or are we satisfied that the code alone is enough? | |
| 16:38:52 | dansmith | I mean, I can do the migration if you really don't want to, but.. figured you'd want all the glory and praise that will come with it | |
| 16:39:11 | artom | If I want glory and praise I'll become a murderous dictator | |
| 16:39:17 | mriedem | artom: there is a db migratoin for extending the size of build_requests.instance | |
| 16:39:20 | mriedem | artom: just copy ^ | |
| 16:39:21 | mriedem | super easy | |
| 16:39:26 | mriedem | exact same issue | |
| 16:39:34 | dansmith | artom: an important point on the resume of a murderous dictator is "did a schema migration once" | |
| 16:39:38 | artom | For now I just want to revel turdgoatery | |
| 16:39:42 | mriedem | ffs you should probably give me co-author now because i even told you | |
| 16:40:08 | artom | What's the magic word? | |
| 16:40:27 | mriedem | trump | |
| 16:41:52 | artom | Do we support pgsql as well? | |
| 16:42:05 | artom | I remember there was a whole thing about dropping it from the gate a while back | |
| 16:42:17 | bauzas | I'm a 20% time person this week, funny | |
| 16:43:02 | dansmith | artom: we don't anymore | |
| 16:43:16 | dansmith | artom: and if you could figure out some way to break pgsql in this process, I'd sure appreciate it | |
| 16:43:31 | dansmith | if for no other reason than just to cause pain for that smug cfriesen guy | |
| 16:44:01 | bauzas | artom: we are not gating pgsql, hence not supporting it | |
| 16:44:47 | bauzas | I don't know if other projects still gate pg, but we very made it clear that pg is not supported anyway in nova | |
| 16:57:08 | xnox | Hello! | |
| 16:57:24 | xnox | is there nova quota for CPU cores.... per-arch/per-machinetype? | |
| 16:58:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Document PCI NUMA affinity policy https://review.openstack.org/528011 | |
| 17:00:16 | jaypipes | xnox: no. quota is for VCPU, that's it. | |
| 17:00:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Make request_spec.spec MediumText https://review.openstack.org/528012 | |
| 17:00:59 | artom | mriedem, ^^ there you go | |
| 17:01:02 | mriedem | artom: dansmith: yes we support postgres | |
| 17:01:20 | dansmith | mriedem: we don't test it right? | |
| 17:01:29 | mriedem | we don't actively gate on it, we have an experimental job that runs it, | |
| 17:01:32 | xnox | jaypipes, ack, thanks. | |
| 17:01:40 | mriedem | but i consider support == if we break it and there is a patch, we don't block it | |
| 17:01:40 | dansmith | oh I didn't realize we still had that | |
| 17:01:50 | dansmith | meh | |
| 17:01:51 | mriedem | ffs we don't gate on ceph either | |
| 17:01:54 | dansmith | I call that not supporting it | |
| 17:01:55 | mriedem | so i guess we don't support ceph | |
| 17:02:00 | stephenfin | bauzas: Added the docs promised for the PCI NUMA policy https://review.openstack.org/528011 | |
| 17:02:05 | stephenfin | Going to add user docs shortly | |
| 17:02:21 | stephenfin | Though I really should do the real-time ones first. I've them only in blog form right now | |
| 17:02:53 | artom | And I totally forgot tests, didn't I/ | |
| 17:03:27 | artom | And a lot of other stuff, actually:( | |
| 17:05:02 | bauzas | stephenfin: well, the biggest concern I had was indeed https://review.openstack.org/#/c/527472/3/nova/virt/hardware.py@1198 | |
| 17:05:37 | bauzas | I know we already do this | |
| 17:05:50 | bauzas | but looks like an operator pain | |
| 17:06:11 | bauzas | honestly, I need to look at the spec's comments | |
| 17:06:19 | stephenfin | If we fix that though, isn't it something we should fix in one fell swoop? | |
| 17:06:37 | stephenfin | i.e. all potential conflicts should throw that the same kind of warning | |
| 17:06:43 | stephenfin | *throw the | |
| 17:06:59 | stephenfin | Yeah, spec discussion would probably be best. /me goes to find relevant comments | |
| 17:10:01 | bauzas | stephenfin: I just found those https://review.openstack.org/#/c/361140/6..7/specs/ocata/approved/share-pci-between-numa-nodes.rst | |
| 17:10:27 | bauzas | stephenfin: oops https://review.openstack.org/#/c/361140/6/specs/ocata/approved/share-pci-between-numa-nodes.rst@69 | |
| 17:10:53 | bauzas | honestly, we're late in the cycle so your concern is valid | |
| 17:11:02 | stephenfin | bauzas: That's the one. There's also this discussion on the need for both flavor extra spec and image metadata https://review.openstack.org/#/c/361140/19/specs/pike/approved/share-pci-between-numa-nodes.rst@59 | |
| 17:11:02 | bauzas | but I do feel it's a PITA for operators | |
| 17:11:48 | stephenfin | )note that I mixed up the use of flavors extra specs vs image metadata - it's *operators* that would set the former and not user) | |
| 17:12:13 | stephenfin | bauzas: Would a TODO to resolve that in a future effort be reasonable? I'm pretty sure I can revive the spec I talked about | |
| 17:12:17 | bauzas | stephenfin: well, PS19 convo is strictier than the one I found | |
| 17:12:29 | openstackgerrit | Claudiu Belu proposed openstack/nova master: tests: fixes mock autospec usage https://review.openstack.org/447505 | |
| 17:12:31 | bauzas | stephenfin: it's more about whether we need to use image metadata | |
| 17:12:49 | stephenfin | Indeed. Different argument but in a similar area | |
| 17:12:50 | bauzas | here, I still think it's understandable to do such things because users need a way to ask for a policy | |
| 17:12:58 | stephenfin | Here's the spec I was talking about https://review.openstack.org/#/c/382382/ | |
| 17:13:30 | stephenfin | We can use that determine what we want to do going forward | |
| 17:13:38 | bauzas | stephenfin: documenting the flaws of using flavor metadata for such things is indeed a necessary thing to do | |
| 17:14:03 | bauzas | I'd recommend operators to *not* use flavor metadata if they don't know their users | |
| 17:14:47 | stephenfin | I'd also like to use something like JSONSchema (though maybe not that) to validate flavour extra specs and determine what things can't be used together | |
| 17:15:07 | stephenfin | ...with exceptions for custom flavour properties | |
| 17:15:35 | bauzas | in my mind, flavors take precedence over images | |
| 17:15:44 | bauzas | because they are admin-driven | |
| 17:15:54 | bauzas | so, your call, man | |
| 17:15:56 | stephenfin | bauzas: Aye, that's how I see them too | |
| 17:16:29 | stephenfin | But I don't want a user to think "I've got a strictly-pinned NUMA device" when they actually don't | |
| 17:16:40 | stephenfin | cos the operator set the policy to 'preferred' | |
| 17:16:45 | bauzas | right | |
| 17:16:46 | stephenfin | for resource usage reasons or whatever | |
| 17:16:50 | bauzas | but users won't know anyway | |
| 17:17:02 | stephenfin | They won't? | |
| 17:17:11 | bauzas | how could they ? | |
| 17:17:15 | openstackgerrit | Merged openstack/nova master: Fix disk size during live migration with disk over-commit https://review.openstack.org/524681 | |
| 17:17:21 | openstackgerrit | Merged openstack/nova stable/ocata: Only query BDMs once in API during rebuild https://review.openstack.org/525665 | |
| 17:17:34 | bauzas | do we expose the topology to the users ? hell no, of course | |
| 17:17:47 | bauzas | ah, that | |
| 17:18:04 | bauzas | well, two cases, and that requires looking at code | |
| 17:18:16 | bauzas | #1 either we fail and we reschedule to another host | |
| 17:18:21 | bauzas | which could eventually fail too | |
| 17:18:26 | bauzas | #2 or we make it full stop | |
| 17:18:33 | bauzas | and then we error out | |
| 17:18:45 | bauzas | either way, the user experience isn't terrible | |