Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-14
16:28:13 jaypipes dansmith: is this metadata value?
16:28:24 dansmith jaypipes: request_specs.spec
16:28:29 jaypipes hmm.
16:28:40 dansmith jaypipes: it's a text we serialize the object into, and because we store instance_group.members, which can be huge,
16:28:41 artom Err, instance_group surely?
16:28:46 dansmith we can generate more than 64kb of data
16:28:59 dansmith artom: instance_group is in the spec
16:29:07 bauzas we serialize all at a whole
16:29:11 artom Ah, doh
16:29:15 jaypipes dansmith: k. then I'd recommend changing it to MEDIUMTEXT from TEXT.
16:29:23 dansmith jaypipes: that's what we're doing :)
16:29:34 jaypipes dansmith: ok, sorry for interrupting then :)
16:29:35 dansmith jaypipes: waaaaayyyy ahead of you bro
16:29:49 dansmith jaypipes: and when I say "we" I mean "artom"
16:29:52 jaypipes k
16:30:22 artom I, wha?
16:30:32 jaypipes yet another reason why storing denormalized data in a TEXT-y field is a bad idea...
16:30:39 artom I've barely had breakfast and it's 11:30, I'm not ahead of anything
16:30:47 openstackgerrit Merged openstack/nova master: Fix the bug report link of API Guide https://review.openstack.org/527660
16:32:17 dansmith jaypipes: well, it has its place, IMHO, and the complexity required to store a reqspec normalized is not worth it since it's a snapshot
16:32:33 bauzas I remember we had a thought on that with alaski
16:33:18 dansmith reqspec is an archive snapshot really, which is fine for this, we just need to not snapshot an infinite amount of stale data into it ;)
16:33:35 bauzas and we said it was better to just store the whole object so we would totally decouple what we store from what we expose
16:33:48 bauzas dansmith: yeah, I still agree on it tbc
16:34:10 jaypipes dansmith: +W'd that patch
16:34:25 bauzas we just expose the instance UUID for querying reasons that's it
16:34:28 dansmith jaypipes: thanks
16:34:43 bauzas dansmith: is there another patch related to that about a DB schema modification ?
16:34:48 dansmith jaypipes: and thanks for being my fleshy mysql manual :P
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

Earlier   Later