Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-14
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
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

Earlier   Later