| *** nweinber has joined #openstack-nova | 00:04 | |
| *** tosky has quit IRC | 00:08 | |
| *** dtruong has quit IRC | 00:12 | |
| *** nweinber has quit IRC | 00:12 | |
| *** dtruong has joined #openstack-nova | 00:12 | |
| *** munimeha1 has quit IRC | 00:21 | |
| *** nweinber has joined #openstack-nova | 00:24 | |
| *** mlavalle has quit IRC | 00:32 | |
| *** nweinber has quit IRC | 00:38 | |
| *** threestrands has joined #openstack-nova | 00:50 | |
| *** TxGirlGeek has quit IRC | 01:06 | |
| *** slaweq has joined #openstack-nova | 01:11 | |
| *** slaweq has quit IRC | 01:16 | |
| *** igordc has quit IRC | 01:23 | |
| *** sapd1_x has joined #openstack-nova | 01:34 | |
| *** spatel has joined #openstack-nova | 01:35 | |
| *** Liang__ has joined #openstack-nova | 01:52 | |
| *** gyee has quit IRC | 01:55 | |
| *** hamzy has quit IRC | 01:56 | |
| *** hamzy has joined #openstack-nova | 01:56 | |
| *** zzzeek has quit IRC | 02:03 | |
| *** TxGirlGeek has joined #openstack-nova | 02:04 | |
| *** damien_r has joined #openstack-nova | 02:05 | |
| *** rnoriega_ has joined #openstack-nova | 02:05 | |
| *** damien_r has quit IRC | 02:06 | |
| *** zzzeek has joined #openstack-nova | 02:08 | |
| *** zul has quit IRC | 02:12 | |
| *** damien_r has joined #openstack-nova | 02:45 | |
| *** tbachman has quit IRC | 02:47 | |
| *** damien_r has quit IRC | 02:57 | |
| *** spatel has quit IRC | 03:06 | |
| *** slaweq has joined #openstack-nova | 03:11 | |
| *** damien_r has joined #openstack-nova | 03:16 | |
| *** slaweq has quit IRC | 03:16 | |
| *** links has joined #openstack-nova | 03:18 | |
| *** damien_r has quit IRC | 03:20 | |
| *** TxGirlGeek has quit IRC | 03:50 | |
| openstackgerrit | Merged openstack/nova master: Handle cell failures in get_compute_nodes_by_host_or_node https://review.opendev.org/700186 | 03:52 |
|---|---|---|
| openstackgerrit | Merged openstack/nova master: doc: define boot from volume in the glossary https://review.opendev.org/699009 | 03:52 |
| *** Liang__ has quit IRC | 04:09 | |
| *** udesale has joined #openstack-nova | 04:13 | |
| *** damien_r has joined #openstack-nova | 04:16 | |
| *** factor has joined #openstack-nova | 04:24 | |
| *** Liang__ has joined #openstack-nova | 04:33 | |
| *** Liang__ has quit IRC | 04:38 | |
| *** abhishekk|away is now known as abhishekk | 04:39 | |
| *** TxGirlGeek has joined #openstack-nova | 04:50 | |
| *** damien_r has quit IRC | 04:56 | |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] More tests for validating CPU policy by 'resources:PCPU' and 'resources:VCPU' https://review.opendev.org/696007 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] Refactor the code path of creating instance with a NUMA topology https://review.opendev.org/688932 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] Assign instance dedicated CPU set through `cpu_pinning` field https://review.opendev.org/688933 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] Introduce a new instance CPU allocation policy: mixed https://review.opendev.org/688934 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] support unbalanced dedicatd CPU distribution on instance NUMA nodes https://review.opendev.org/696008 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] Create 'mixed' instance from PCPU and VCPU resources https://review.opendev.org/696009 | 04:57 |
| openstackgerrit | Huachang Wang proposed openstack/nova master: [WIP] metadata: export the vCPU IDs that are pinning on the host CPUs https://review.opendev.org/688936 | 04:57 |
| *** slaweq has joined #openstack-nova | 05:11 | |
| *** TxGirlGeek has quit IRC | 05:12 | |
| *** TxGirlGeek has joined #openstack-nova | 05:12 | |
| *** slaweq has quit IRC | 05:15 | |
| *** TxGirlGeek has quit IRC | 05:17 | |
| *** HagunKim has quit IRC | 05:32 | |
| *** mmethot_ has joined #openstack-nova | 06:17 | |
| *** sapd1_x has quit IRC | 06:17 | |
| *** mmethot has quit IRC | 06:20 | |
| *** sapd1_x has joined #openstack-nova | 06:30 | |
| *** ratailor has joined #openstack-nova | 06:45 | |
| *** alex_xu has quit IRC | 06:47 | |
| *** slaweq has joined #openstack-nova | 07:11 | |
| *** slaweq has quit IRC | 07:15 | |
| *** dpawlik has joined #openstack-nova | 07:16 | |
| *** luksky has joined #openstack-nova | 07:20 | |
| *** sapd1_x has quit IRC | 07:32 | |
| *** maciejjozefczyk has joined #openstack-nova | 07:54 | |
| *** dtantsur|afk is now known as dtantsur | 07:54 | |
| *** slaweq has joined #openstack-nova | 07:56 | |
| *** tesseract has joined #openstack-nova | 08:03 | |
| *** tkajinam has quit IRC | 08:08 | |
| *** rpittau|afk is now known as rpittau | 08:08 | |
| *** rcernin has quit IRC | 08:20 | |
| *** luksky has quit IRC | 08:28 | |
| *** luksky has joined #openstack-nova | 08:31 | |
| *** tosky has joined #openstack-nova | 08:35 | |
| *** mrch has joined #openstack-nova | 08:41 | |
| *** belmoreira has joined #openstack-nova | 08:57 | |
| *** ralonsoh has joined #openstack-nova | 08:59 | |
| *** martinkennelly has joined #openstack-nova | 09:17 | |
| *** luksky has quit IRC | 09:26 | |
| bauzas | good morning Nova | 09:31 |
| stephenfin | o/ | 09:38 |
| *** iurygregory has joined #openstack-nova | 09:40 | |
| gibi | \o | 09:43 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate https://review.opendev.org/695220 | 09:45 |
| *** threestrands has quit IRC | 09:47 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support unshelve with qos ports https://review.opendev.org/704759 | 09:48 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/662522 | 10:05 |
| *** xek has quit IRC | 10:10 | |
| *** derekh has joined #openstack-nova | 10:13 | |
| *** lifeless has quit IRC | 10:19 | |
| stephenfin | gibi, bauzas: Either of you care to sanity check this and then send it on its way? Just updating to reflect post-merge reality | 10:25 |
| stephenfin | https://review.opendev.org/#/c/666032/ | 10:25 |
| bauzas | stephenfin: sure | 10:25 |
| bauzas | btw. thanks stephenfin and gibi for my multiple GPU types spec reapproval | 10:25 |
| stephenfin | np. Made sense | 10:26 |
| bauzas | I'm more concerned by the NUMA topology in placement spec that's blocked because of good gibi's and sean-k-mooney's finding | 10:26 |
| *** luksky has joined #openstack-nova | 10:29 | |
| *** dviroel has joined #openstack-nova | 10:30 | |
| *** psachin has joined #openstack-nova | 10:36 | |
| *** xek has joined #openstack-nova | 10:55 | |
| *** pcaruana has quit IRC | 10:57 | |
| *** priteau has joined #openstack-nova | 11:00 | |
| *** udesale has quit IRC | 11:01 | |
| sean-k-mooney | bauzas: im conserned about that spec too and the interaction with mix cpus | 11:02 |
| sean-k-mooney | bauzas: can we have a call or something to work on this together | 11:03 |
| sean-k-mooney | bauzas: that said im currently working on the backport. i did not feel great yesterday so did not get it finished :( | 11:04 |
| openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | 11:08 |
| *** xek_ has joined #openstack-nova | 11:10 | |
| *** xek has quit IRC | 11:10 | |
| sean-k-mooney | bauzas: if you have not already done so i think you shoudl review https://review.opendev.org/#/c/668656/ too by the way | 11:15 |
| bauzas | sean-k-mooney: ack, will do later in the afternoon | 11:17 |
| bauzas | and thanks for the reviews | 11:17 |
| *** psachin has quit IRC | 11:18 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | 11:24 |
| gibi | stephenfin: looking | 11:29 |
| gibi | stephenfin: +A | 11:38 |
| stephenfin | gibi: ta | 11:39 |
| *** pcaruana has joined #openstack-nova | 11:40 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | 11:43 |
| openstackgerrit | Merged openstack/nova-specs master: Additional upgrade clarifications for cpu-resources https://review.opendev.org/666032 | 11:49 |
| stephenfin | gibi: I know it's horrible stuff, but could I ask you to revisit https://review.opendev.org/#/c/662522 this week? There's another patch needed to improve how we rollback in a failure, but that should stand by itself all the same | 11:50 |
| gibi | sure I added to my queue | 11:50 |
| stephenfin | thanks | 11:50 |
| *** rpittau is now known as rpittau|bbl | 11:53 | |
| *** ociuhandu has joined #openstack-nova | 11:58 | |
| *** salmankhan has joined #openstack-nova | 12:23 | |
| *** links has quit IRC | 12:24 | |
| huaqiang | stephenfin: Thanks your review for spec https://review.opendev.org/#/c/668656. I haven't responded to your comments in time because I am still in my vacation of the chinese new year, | 12:26 |
| huaqiang | I want to comfirm that you prefer the PCPU mask approach that we have dropped, right? | 12:27 |
| *** ociuhandu has quit IRC | 12:31 | |
| *** mgariepy has joined #openstack-nova | 12:35 | |
| *** ociuhandu has joined #openstack-nova | 12:40 | |
| *** jawad_axd has joined #openstack-nova | 12:54 | |
| stephenfin | huaqiang: No problem. There's no rush. Yes, that's what I'm in favour of. I'll try discuss it with dansmith this week so we can have it resolved for when you're back | 13:04 |
| *** artom has quit IRC | 13:06 | |
| *** alex_xu has joined #openstack-nova | 13:08 | |
| huaqiang | stephenfin: thanks. It's pretty close to the freeze of spec, I planed to work but not work fully these days. | 13:12 |
| huaqiang | I'll keep my eye on the update of gerrit and irc. | 13:13 |
| *** maciejjozefczyk has quit IRC | 13:14 | |
| *** damien_r has joined #openstack-nova | 13:17 | |
| *** ociuhandu has quit IRC | 13:17 | |
| *** ociuhandu has joined #openstack-nova | 13:21 | |
| *** ociuhandu has quit IRC | 13:26 | |
| *** nweinber has joined #openstack-nova | 13:27 | |
| *** rpittau|bbl is now known as rpittau | 13:30 | |
| *** ratailor has quit IRC | 13:32 | |
| *** maciejjozefczyk has joined #openstack-nova | 13:39 | |
| *** ratailor has joined #openstack-nova | 13:44 | |
| *** ratailor has quit IRC | 13:48 | |
| *** ratailor has joined #openstack-nova | 13:50 | |
| *** Liang__ has joined #openstack-nova | 13:53 | |
| *** Liang__ is now known as LiangFang | 13:53 | |
| *** ratailor has quit IRC | 13:59 | |
| *** ociuhandu has joined #openstack-nova | 14:00 | |
| *** shilpasd has joined #openstack-nova | 14:18 | |
| *** KeithMnemonic has joined #openstack-nova | 14:20 | |
| *** zzzeek has quit IRC | 14:22 | |
| *** zzzeek has joined #openstack-nova | 14:23 | |
| *** spatel has joined #openstack-nova | 14:36 | |
| openstackgerrit | Lenny Verkhovsky proposed openstack/os-vif master: WIP: Testing CI https://review.opendev.org/686937 | 14:37 |
| *** jawad_axd has quit IRC | 14:39 | |
| *** jawad_axd has joined #openstack-nova | 14:39 | |
| *** spatel has quit IRC | 14:40 | |
| *** jawad_ax_ has joined #openstack-nova | 14:43 | |
| *** jawad_axd has quit IRC | 14:45 | |
| *** spatel has joined #openstack-nova | 14:48 | |
| *** jawad_ax_ has quit IRC | 14:48 | |
| *** priteau has quit IRC | 14:50 | |
| *** priteau has joined #openstack-nova | 14:51 | |
| *** spatel has quit IRC | 14:54 | |
| stephenfin | gibi: Replied at https://review.opendev.org/#/c/682655/3/specs/ussuri/approved/flavor-extra-spec-validators.rst@194. I'll hold off addressing sean-k-mooney's comments until you've taken another look | 14:55 |
| gibi | stephenfin: ack, looking | 14:56 |
| *** priteau has quit IRC | 14:56 | |
| sean-k-mooney | stephenfin: im reviewing you poc code at the moment | 14:56 |
| sean-k-mooney | almost done | 14:56 |
| *** mrch has quit IRC | 14:58 | |
| efried | stephenfin: just posted another round of comments. Since sean-k-mooney and gibi are here, perhaps we can hash out the granular-control issue realtime. | 14:58 |
| * gibi has 30 minutes before he needs to leave but sure let's do it | 14:59 | |
| sean-k-mooney | we might not need it but if we do add it rather then a config option i think the new microverions shoudl add a &validate=stric|permissive|off option to the post | 14:59 |
| sean-k-mooney | maybe just strict|off based on stephens last comment | 14:59 |
| gibi | stephenfin: do you think people will hack on a the in-tree validator yamls if it is in the python package dir? | 15:00 |
| stephenfin | I've no idea. I just know this would be the first time we'll have used YAML to define something that's core to nova | 15:00 |
| stephenfin | There's no reason we couldn't define our nova.conf "schema" in YAML but we chose not to. I guess if we can figure out why we did that, we'd solve this too | 15:01 |
| efried | nova.conf is ini style | 15:02 |
| stephenfin | but not the definitions for those config options | 15:02 |
| efried | conceived, if I'm not mistaken, before yaml was sexy. | 15:02 |
| *** dklyle has quit IRC | 15:02 | |
| efried | It would be possible to do these validators ini-style and use oslo.conf | 15:02 |
| sean-k-mooney | gibi: so i really hate the idea of only doing this with yaml files but if we do then i think there is no excust to not use the json based metadef format that glance has and share the files as a lib | 15:03 |
| stephenfin | eeew, I'm not writing that much JSON | 15:03 |
| efried | Yeah, definitely don't want the files to be json. yaml exists because json is ugly. | 15:03 |
| *** dklyle has joined #openstack-nova | 15:03 | |
| stephenfin | also, I think I did look at that and it didn't offer everything we'd need | 15:03 |
| sean-k-mooney | but we are needless reinventing the wheel here | 15:04 |
| gibi | I don't want to start a format war, I just wanted to avoid implementing two pieces of code when one piece would be enough technically | 15:04 |
| stephenfin | But glance's stuff wasn't invented here, Sean. | 15:04 |
| stephenfin | :P | 15:04 |
| sean-k-mooney | the have a format for declaring this. they expose it via an api for heat and horizon to consume to generate use | 15:04 |
| bauzas | honestly, what's the problem with stevedore ? | 15:04 |
| efried | Oh, yeah, IMO ini isn't powerful enough for long-term use, even for nova.conf (as demonstrated by the travesty that is passthrough_whitelist). | 15:04 |
| bauzas | nova was built around it | 15:04 |
| bauzas | plugins FTW | 15:04 |
| sean-k-mooney | we could pull the galnce sutff into a lib and share it | 15:04 |
| * bauzas jk | 15:04 | |
| efried | bauzas: to me, just unnecessary complexity and an additional thing we don't need. | 15:05 |
| sean-k-mooney | if we go file based only i think that is what we shoudl do | 15:05 |
| bauzas | efried: entrypoints are complex to manage ? | 15:05 |
| bauzas | honestly, we haven't heard about this since nova exists | 15:05 |
| efried | entrypoints plus python code plus packaging, versus putting a yaml file in a directory? Hell yes. | 15:05 |
| sean-k-mooney | bauzas: there is one complexity with them form a packaging point of view | 15:06 |
| stephenfin | sean-k-mooney: so we'd be using a package to distribute a YAML file? | 15:06 |
| efried | ugh, no, please. | 15:06 |
| bauzas | it's config | 15:06 |
| efried | Can we not boil the ocean? | 15:06 |
| sean-k-mooney | json file and the code to do all the validation which they have laready written as far as i knwo | 15:06 |
| stephenfin | I'd personally rather strip the flavor stuff out of glance | 15:07 |
| stephenfin | Why do they need to care about flavors? They're an image service | 15:07 |
| *** priteau has joined #openstack-nova | 15:07 | |
| efried | how did glance get involved here? | 15:07 |
| sean-k-mooney | they care about it becasue we had this problem years ago and decied that they would be used as the catalog of support meatdata itmes | 15:07 |
| bauzas | I thought the spec was simple enough to just re-accept it | 15:08 |
| efried | (rhetorical question; can we stay on topic?) | 15:08 |
| bauzas | given it was accepted beofre | 15:08 |
| bauzas | but now, looks like we rathole around any possible better way to provide config | 15:08 |
| stephenfin | so I really don't want another os-whatever library to maintain. This should be in-tree, with some kind of mechanism to export to glance if we really care | 15:09 |
| stephenfin | Which I'd be surprised if we do, since sean-k-mooney is the only person that's ever heard of this feature in glance | 15:09 |
| bauzas | that's exactly why we chose plugins before | 15:09 |
| bauzas | but... whatever | 15:09 |
| bauzas | looks like we have consensus around YAML | 15:09 |
| bauzas | the glance issue shouldn't be taken care as of now, until we know whether glance needs it as well or not | 15:10 |
| stephenfin | so the question comes down to Python objects or YAML, and whether we need to make the strict behavior opt-in or not | 15:10 |
| sean-k-mooney | well im going to be out voted so i guess yes | 15:10 |
| dansmith | yaml for what? rules of extra spec validation? | 15:10 |
| stephenfin | yup | 15:10 |
| dansmith | and... why? | 15:10 |
| gibi | I think having a simple api microversion to opt in is enough | 15:10 |
| dansmith | because we can share that file between us and glance? | 15:11 |
| efried | no | 15:11 |
| efried | so we can accommodate extra specs nova doesn't own or know about | 15:11 |
| gibi | dansmith: because we need the yaml for deployer defined extra specs anyhow | 15:11 |
| stephenfin | so we don't have two different ways to represent a rule | 15:11 |
| stephenfin | https://review.opendev.org/#/c/704643/2/nova/api/validation/extra_specs/hw.py | 15:11 |
| bauzas | honestly, I was preferring the python approach thru stevedore plugins | 15:11 |
| stephenfin | we want to provide a way for operators to specify their own custom extra specs for out of tree filters, or whatever | 15:11 |
| sean-k-mooney | dansmith: gibi does not like the python class way of doing it and suggeste that if we are going to support yaml anyway just use it for everything. fair summary? | 15:11 |
| stephenfin | sean-k-mooney: yup, that | 15:12 |
| gibi | I don't want to start a format war, I just wanted to avoid implementing two pieces of code when one piece would be enough technically | 15:12 |
| dansmith | so, this brings the policy problem screaming back from hell? | 15:12 |
| stephenfin | oslo.policy? | 15:12 |
| sean-k-mooney | dansmith: no that was brogh back for a different reason | 15:12 |
| dansmith | i.e. we provide a base yaml, they edit it to add their stuff and tweak their prefs and then when they go to upgrade they're sadface? | 15:12 |
| stephenfin | that was another concern of mine, but I figured we'd just load multiple files | 15:13 |
| sean-k-mooney | e.g. if the new microversion enabled validateion and we extend the flavor update again in the future you cant use the new feautre with validation idsabled | 15:13 |
| stephenfin | I'm almost certain someone will go tweak the YAML file we provide though | 15:13 |
| bauzas | yuuuuup | 15:13 |
| *** mriedem has joined #openstack-nova | 15:13 | |
| dansmith | stephenfin: I would argue that we don't/shouldn't encode our baseline validations into yaml and distribute them that way, as it's just asking for that problem | 15:13 |
| dansmith | right | 15:13 |
| sean-k-mooney | dansmith: so i was suggesting add a &validate query arge to turn off validation in the new microversion | 15:13 |
| efried | If we do in-tree stuff with yaml, we put the nova-owned stuff within the nova package so nobody fs with it. | 15:13 |
| dansmith | efried: riiiight | 15:14 |
| stephenfin | sean-k-mooney: hold up, let's figure the YAML thing out first | 15:14 |
| efried | riiiight they'll still f with it? Let 'em. That's breaking the seal, voiding the warranty, not different than if they go patch the code. | 15:14 |
| sean-k-mooney | efried: distos will modify it every time we backport stuff | 15:14 |
| gibi | we somebody want to tweak what is written in the python DSL for in-tree validation he can do it, it is almos like a yaml file | 15:14 |
| dansmith | surely the yaml to validate something complex like numa whatever is going to be nasty or naive right? | 15:14 |
| sean-k-mooney | it will be an interesting regex | 15:15 |
| gibi | but nothing more than a regex | 15:15 |
| stephenfin | gibi: I don't think it's a DSL, really. It's just an object. I could use dicts if that would be preferable | 15:15 |
| dansmith | an "interesting" regex or some relatively simple python right? | 15:15 |
| bauzas | :) | 15:15 |
| sean-k-mooney | actully its still a regex in stephns code | 15:15 |
| sean-k-mooney | well poc | 15:15 |
| stephenfin | not entirely | 15:15 |
| sean-k-mooney | but it could be simpler | 15:15 |
| stephenfin | I let you specify enums etc. | 15:16 |
| sean-k-mooney | yes | 15:16 |
| stephenfin | granted, all that gets converted into a regex but there's no reason I have to do that for all cases. It's a PoC after all | 15:16 |
| sean-k-mooney | although you convert the enum int an bool filed back to regex form | 15:16 |
| * gibi drops the case for yaml only, but still would like to see an implementation that does not duplicated code for intree and out of tree extra spec validation | 15:16 | |
| dansmith | so I think my feeling on this is: (a) I'm not sure we need an interface for people to be able to specify their own validators, but (b) if we do, that seems like an obvious use case for entrypoints and a dead simple plugin interface with a super-controlled input and output behavior set | 15:17 |
| efried | gibi: it won't be a lot of duplication, really. The parser will construct the same kind of python objects we have in tree and then feed all of them into the validation engine. | 15:17 |
| stephenfin | gibi: yeah, what efried said | 15:18 |
| gibi | OK, I rest my case then | 15:18 |
| stephenfin | it's just a slightly different representation of the exact same data | 15:18 |
| stephenfin | dansmith: So kill the YAML idea entirely? | 15:18 |
| stephenfin | If so, the main issue I'd see with that is that they'd have to write and install a Python package for the custom stuff | 15:19 |
| dansmith | stephenfin: I don't think our validations should be in yaml, and I don't really see why custom ones should be either.. they'd be a lot harder to test than a single python function you can run with a string you would put in your flavor | 15:19 |
| bauzas | stephenfin: I don't see a problem here, we asked for that since a while | 15:20 |
| efried | If we do that, we can't have strict validation. Writing python code and figuring out stevedore for snowflake extra specs is too high a barrier to entry for that to be the only option. | 15:20 |
| dansmith | stephenfin: I think that would be a pretty simple example thing, they have to do that for scheduler filters, and I expect anyone that feels they need this (honestly I don't see it being that important) will be fine with that standard | 15:20 |
| bauzas | (like, Blazar was having a specific nova-ish package for nova plugins he needed) | 15:20 |
| bauzas | yeah, it's very similar to the scheduler filters case | 15:21 |
| stephenfin | I was about to ask what the story with extra scheduler filters was. Those are a package too so | 15:21 |
| bauzas | yup | 15:21 |
| bauzas | or delivered by other means | 15:21 |
| dansmith | efried: stevedore is on the loader side, they don't have to do anything like that.. entry points are a stock python thing | 15:21 |
| stephenfin | efried: Are snowflake extra specs a real thing people use? | 15:21 |
| stephenfin | Far as I knew, extra specs were for scheduler filters and virt drivers | 15:21 |
| sean-k-mooney | they use custom one for filter | 15:21 |
| efried | f man, even if you managed to miss one of the stock ones | 15:21 |
| dansmith | stephenfin: you can in conjunction with the json filter or yeah a custom scheduler filter | 15:22 |
| dansmith | stephenfin: if you're writing a custom scheduler flter, you're doing a package, so throwing a validator in there makes plenty of sense | 15:22 |
| stephenfin | If it's a custom filter, we're saying they're using a package already so no big deal | 15:22 |
| stephenfin | dansmith: yeah | 15:22 |
| gibi | my employer's downstream product has at least two snowflake extra spec | 15:22 |
| gibi | but sure I can implement a python filter for that | 15:22 |
| sean-k-mooney | same with a thrid party virt dirver | 15:22 |
| dansmith | stephenfin: imagine the fame and fortune if you wrote up a nice blog post on how to do this super cleanly :D | 15:22 |
| dansmith | sean-k-mooney: shut yo' mouth! :D | 15:23 |
| sean-k-mooney | :) | 15:23 |
| stephenfin | If I can do one thing well, it's write lots of docs and bug people continuously to review them | 15:23 |
| bauzas | scheduler filters are the exact reasons why we never constrained extra specs | 15:23 |
| stephenfin | no issues there | 15:23 |
| bauzas | so I guess 3rd-parties would *love* to consider filters and validation code to be considered equal | 15:24 |
| sean-k-mooney | so that bring up stict vs permissive vs off | 15:24 |
| bauzas | so they could package this at once | 15:24 |
| stephenfin | efried: I don't think that's as big a deal as you think. Realistically, how often do people create new flavors | 15:24 |
| sean-k-mooney | we could skip all non namespaced extra space or ones in a namespace we dont know about | 15:24 |
| sean-k-mooney | in permisive mode at least | 15:24 |
| *** ociuhandu has quit IRC | 15:24 | |
| stephenfin | They try create one, we fail because we don't recognize the spec, they report and bug and we add/backport the missing validator | 15:24 |
| stephenfin | It's just a bug | 15:24 |
| *** ganso has quit IRC | 15:25 | |
| stephenfin | *report a bug | 15:25 |
| dansmith | are you going to make admins able to create flavors that fail validation | 15:25 |
| dansmith | ? | 15:25 |
| *** ganso has joined #openstack-nova | 15:25 | |
| stephenfin | dansmith: that's the question | 15:25 |
| stephenfin | I want a microversion that starts failing extra specs that don't pass validation | 15:26 |
| dansmith | if there is a &force=yes then that gives them a way past the validation if there's a bug | 15:26 |
| sean-k-mooney | dansmith: that is what is was kind of suggestin with &validate=strict|permissive|off | 15:26 |
| stephenfin | and I'm arguing that ^ is unnecessary since we should be able to audit the extra specs we have in-tree | 15:27 |
| *** jmlowe has joined #openstack-nova | 15:27 | |
| dansmith | sean-k-mooney: oh per-create, I thought you meant global config | 15:27 |
| sean-k-mooney | no per request | 15:27 |
| stephenfin | efried suggested global config. I said no cos config-driven API behavior is bad | 15:27 |
| dansmith | stephenfin: yeah, I dunno.. I think some of them are complex enough that you might not be able to do that as well as you think | 15:27 |
| dansmith | stephenfin: agree | 15:27 |
| dansmith | stephenfin: but I think it's legit to have a validation=no per-request, but that can return 403 either because of policy or config if it's documented when you add it, no? so later we could turn that off or default it off | 15:28 |
| *** jmlowe has quit IRC | 15:28 | |
| stephenfin | hmm, that wouldn't be so bad | 15:29 |
| dansmith | either way, I just think you might not want to assume you can enumerate every crazy way people have abused those extra_specs and having a bunch of angry people calling your home :D | 15:29 |
| sean-k-mooney | the reason we would wont that is if we add this in 2.68 and in 2.69 we add another field to the flavor but we still want to disable validtion it would be nice to be able to turn it off | 15:29 |
| bauzas | honestly, leave them time to change their flavors | 15:30 |
| stephenfin | sean-k-mooney: yeah, I've been suggesting using the older microversion purely as a stop gap to allow us iron out the kinks | 15:30 |
| dansmith | IMHO, and AFAICT, validation is *just* to help make the admin's life easier so they don't have to keep booting instances to test that they completely broke an extra_spec right? | 15:30 |
| bauzas | also, are we proposing to fix existing embedded flavors ? | 15:30 |
| dansmith | so being able to turn it off in an emergency doesn't seem like a bad thing to me | 15:30 |
| sean-k-mooney | but that would not work if the thing i wanted to set was added in 2.69 | 15:30 |
| stephenfin | This also won't break existing flavors. It'll only prevent them creating new broken flavors | 15:30 |
| dansmith | you're not going to periodically fsck your flavors so, what does it matter? | 15:30 |
| bauzas | stephenfin: I mean, instance's embedded flavors | 15:30 |
| *** artom has joined #openstack-nova | 15:31 | |
| sean-k-mooney | stephenfin: creating or updating | 15:31 |
| stephenfin | bauzas: Nope. Out of scope for this. This focuses purely on setting new flavor extra specs | 15:31 |
| sean-k-mooney | you want to be able to do the valiation optionaly on flaovr updates too | 15:31 |
| dansmith | sean-k-mooney: that's true, if you're updating a flavor that currently doesn't pass validation | 15:32 |
| stephenfin | We could look into doing that with a nova-manage command (or nova-audit) command in the future but I'm not even thinking about that at the moment | 15:32 |
| stephenfin | sean-k-mooney: Well, setting or updating a new extra spec | 15:32 |
| sean-k-mooney | bauzas: ya for not if you need to update embeded flavor resize | 15:32 |
| sean-k-mooney | stephenfin: yes | 15:32 |
| dansmith | er, wait, stephenfin are you just doing validation on the one spec you're setting during that operation or on the whole flavor as it would be with the spec set? | 15:33 |
| stephenfin | dansmith: Just the one spec | 15:33 |
| dansmith | ah okay | 15:33 |
| bauzas | I need to reread the spec because I'm unclear of some bits | 15:33 |
| stephenfin | I don't plan to e.g. audit the existing extra specs on a flavor when setting a new one | 15:33 |
| * gibi needs to leave | 15:33 | |
| stephenfin | gibi: o/ | 15:33 |
| sean-k-mooney | dansmith: the spec says that while there is a depency between some spec we wont enforce that | 15:33 |
| dansmith | stephenfin: aren't there some specs that depend on each other, like being able to set something that isn't valid unless some other spec says you have that thing? | 15:33 |
| dansmith | okay gotcha | 15:33 |
| bauzas | OK, flavor set, there is | 15:33 |
| gibi | o/ | 15:34 |
| sean-k-mooney | we could add that in the future | 15:34 |
| stephenfin | dansmith: There are but we can't enforce it at the API level | 15:34 |
| dansmith | stephenfin: because some have co-dependency? | 15:34 |
| efried | we would be able to enforce some interdependencies | 15:34 |
| stephenfin | otherwise you'd have to set e.g. 'hw:cpu_policy' before 'hw:cpu_dedicated_policy' | 15:34 |
| stephenfin | introduces a whole slew of ordering issues | 15:34 |
| efried | but not things like "this extra spec is only relevant to the libvirt driver" | 15:34 |
| sean-k-mooney | stephenfin: in some case we can but often the depency can be fulfiled by the image too | 15:34 |
| dansmith | stephenfin: right, I dunno that that's bad necessarily | 15:34 |
| dansmith | stephenfin: you just couldn't enforce that "X and Y have to be both present or both absent" I think | 15:35 |
| dansmith | anyway, my concern over the update was if you were tweaking a flavor that currently doesn't pass and you can't get yourself out of trouble with single ops | 15:35 |
| dansmith | sounds like that's not a thing | 15:35 |
| sean-k-mooney | ya it should not be an issue in what is proposed for this cycle | 15:36 |
| * dansmith nods | 15:36 | |
| stephenfin | I could do that enforcement but I probably don't need to do it in the API | 15:36 |
| dansmith | well, I'm not sure what the point is if not in the API :) | 15:36 |
| sean-k-mooney | as i said in some cases the co depency can be fulfiled by the image so we often dont know if it will be fuliled until the boot request | 15:37 |
| sean-k-mooney | so that a diffent level of validation | 15:37 |
| dansmith | sean-k-mooney: ah, that is a very good point | 15:37 |
| *** tbachman has joined #openstack-nova | 15:37 | |
| stephenfin | oh, good point | 15:37 |
| sean-k-mooney | if it a co depency that is purly fulfiled in the flavor | 15:37 |
| dansmith | yup | 15:37 |
| sean-k-mooney | maybe but that feels like a ux bug | 15:37 |
| efried | that ship has sailed though | 15:38 |
| sean-k-mooney | yes | 15:38 |
| stephenfin | anyway, I think having the registry to validate extra spec names and the separate validators to handle the values gets us an awful lot over what we have at the moment | 15:38 |
| * sean-k-mooney leaves this there for future reading https://docs.openstack.org/glance/pike/user/glancemetadefcatalogapi.html | 15:39 | |
| sean-k-mooney | stephenfin: but yes i agree with that statemnet | 15:39 |
| stephenfin | and it's the lowest hanging fruit, which is nice :) | 15:39 |
| stephenfin | I'm going to update the spec to drop the YAML idea in favour of entrypoints and also add the escape hatch qparam | 15:40 |
| stephenfin | dansmith, efried, sean-k-mooney, bauzas: That make sense to you folks? | 15:40 |
| sean-k-mooney | ya im fine with that | 15:41 |
| dansmith | yup | 15:41 |
| dansmith | I didn't catch earlier discussion, but was gibi opposed to all that? | 15:41 |
| bauzas | cool | 15:41 |
| efried | grudgingly accept entrypoints over yaml. qparam ++ | 15:41 |
| sean-k-mooney | incidentally if you felt like writhing a blog on it or example plugin you could provide a yaml one | 15:41 |
| stephenfin | he wanted the qparam too, I think, but also suggested we use YAML for everything if we were using it | 15:42 |
| stephenfin | so we didn't have two different representations of the same thing | 15:42 |
| efried | so now we have one representation | 15:42 |
| efried | it's python. | 15:42 |
| sean-k-mooney | yes | 15:42 |
| stephenfin | if everything's an object, that concern's resolved. gibi will let me know if he doesn't agree, I'm sure | 15:42 |
| stephenfin | efried: Don't you love it | 15:43 |
| sean-k-mooney | we can even assume its python 3 at long last | 15:43 |
| dansmith | cool | 15:43 |
| efried | If we're providing the qparam so I can push through my snowflake without writing python code for it, I'm okay. | 15:43 |
| stephenfin | \o/ sweet | 15:43 |
| efried | I still think it would be a good idea to have a 'permissive' mode on that qparam | 15:44 |
| stephenfin | efried: what's the difference vs. enable/disable? | 15:44 |
| efried | If I'm constructing my flavor all at once, rather than one extra spec at a time, it gives me the advantage of validating the known/in-tree things while ignoring the snowflakes. | 15:44 |
| sean-k-mooney | permissive mode i guess would log a warning or let you know it failed validation | 15:45 |
| stephenfin | oh, that's what I was going to do for off | 15:45 |
| efried | using two separate calls is a workaround to that | 15:45 |
| efried | yeah, 'off' is 'warn'. | 15:45 |
| efried | but that's for values too | 15:45 |
| sean-k-mooney | oh i was thing off ment you know off as in dont even check | 15:45 |
| stephenfin | no, I was thinking off means you'll never be able to disable validation for the in-tree stuff | 15:45 |
| stephenfin | sean-k-mooney: nope | 15:45 |
| efried | 'permissive' means don't restrict to known keys. | 15:45 |
| stephenfin | wait, that sentence doesn't make sense | 15:46 |
| * stephenfin retries | 15:46 | |
| stephenfin | no, I was thinking off means don't worry about unrecognised keys but do validate values for the known ones | 15:46 |
| stephenfin | so you'll never be able to disable validation for the in-tree stuff | 15:46 |
| stephenfin | better. | 15:46 |
| sean-k-mooney | in my head 'stirct' = know keys only, 'permissive' mean allow unkonw keys but warn, off mean dont do validation at all | 15:47 |
| stephenfin | would you ever want to turn it off for *everything*? | 15:47 |
| efried | I'm not married to the names, but I thought three modes: | 15:47 |
| efried | - off: we don't 4xx for anything. We can still run the validators, but just warn if we find something awry. | 15:47 |
| efried | - permissive: only validate values, only for keys we recognize. Ignore unrecognized keys. | 15:47 |
| efried | - strict: above, plus fail on unrecognized keys. | 15:47 |
| sean-k-mooney | its what you will get for the old microversion | 15:48 |
| sean-k-mooney | so i thnk it makes sense to represent that code path as an option | 15:48 |
| stephenfin | efried: That mostly makes sense but I'm wondering what off is useful for | 15:48 |
| sean-k-mooney | stephenfin: off is basicaly whatever behavior you get with the old microverison | 15:49 |
| stephenfin | right, but is that behaviour ever desirable though? | 15:49 |
| sean-k-mooney | so if im using a newer micoverion for the flavor endpoint that add something not in the old one i can still turn off the vlidation | 15:49 |
| efried | stephenfin: We forgot or messed up an in-tree one, and don't want to wait for the fix. Could flip to the prior microversion, but the warnings would give me a way to sort of manually make sure everything else is kosher. | 15:49 |
| sean-k-mooney | stephenfin: yes | 15:49 |
| sean-k-mooney | stephenfin: there was a spec for composable flavor recently | 15:50 |
| stephenfin | efried: wdym by "everything else" | 15:50 |
| efried | the remainder of the extra specs in my request. | 15:50 |
| sean-k-mooney | if that was approved and landed after this feature we might want to use that without validation | 15:50 |
| stephenfin | oh, yes, you can set multiple extra specs at once. duh | 15:50 |
| efried | I try with strict/permissive, I get a bounce on extra spec X, I redrive with 'off' and make sure the only warning I get is on X. | 15:50 |
| sean-k-mooney | efried: im more or less ok with your deffintions by the way your off just does a littel more then i expected | 15:51 |
| efried | we can call it 'warn' | 15:51 |
| stephenfin | efried: vs. just retrying one by one? | 15:51 |
| efried | yes | 15:51 |
| efried | or "I want to test drive this feature" | 15:51 |
| sean-k-mooney | i suggested permissive to mirror selinux but warn would be fine | 15:51 |
| efried | "but still create my flavor" | 15:51 |
| sean-k-mooney | although that implice that strict should be error | 15:51 |
| efried | really for completeness | 15:52 |
| *** lbragstad has quit IRC | 15:52 | |
| stephenfin | Okay. You're aware the warnings are only going to be in the logs though, yeah? | 15:52 |
| stephenfin | So I'm not sure how much feedback you're going to be getting | 15:52 |
| efried | It would be nice to find a way to send them back to the CLI, but yeah, I get it. | 15:52 |
| *** ociuhandu has joined #openstack-nova | 15:52 | |
| stephenfin | compared to just trying one by one 'til you find the erroneous extra spec | 15:53 |
| sean-k-mooney | well for errors we can put it in the resonce body | 15:53 |
| stephenfin | sean-k-mooney: right, but not for warnings | 15:53 |
| efried | I think that ^ would be nice for a future microversion, don't need to do it now. | 15:53 |
| sean-k-mooney | for wraning maybe we could alter the respocne to include them too | 15:53 |
| stephenfin | for those we already have a body - the updated flavor (I think) | 15:53 |
| sean-k-mooney | ya it should be the full flavor object | 15:53 |
| sean-k-mooney | but we could extend it from the mircoverion on | 15:54 |
| stephenfin | yup, so no way to get back that warning via the API | 15:54 |
| sean-k-mooney | that said its a nice to have | 15:54 |
| efried | so then yeah, call it 'off' and the warnings are in the logs | 15:54 |
| sean-k-mooney | sure there is we just change the api respoce to also have validtion warning but lets leave that out of scope for now | 15:54 |
| *** jmlowe has joined #openstack-nova | 15:54 | |
| stephenfin | efried: ack | 15:54 |
| * stephenfin goes to rework the spec | 15:55 | |
| efried | (note that we technically wouldn't need 'strict', since that's the default, but again for completeness it would be nice to support it) | 15:55 |
| stephenfin | agreed | 15:55 |
| sean-k-mooney | yep | 15:55 |
| sean-k-mooney | i like the implcit state to be setable explictly even if its the default if you say nothing | 15:56 |
| sean-k-mooney | it makes testing nicer imo | 15:56 |
| sean-k-mooney | and it make documting the behavior simpler since you have a name for each mode | 15:56 |
| efried | could call 'permissive' 'values-only' or something, since 'permissive' isn't particularly descriptive | 15:56 |
| efried | bikeshed away. | 15:57 |
| *** lbragstad has joined #openstack-nova | 15:57 | |
| sean-k-mooney | ya maybe again i just suggeste permissive since selinux in permissve mode doese policy validateion and log any violation but allow whatever the process was doing to continue | 15:57 |
| sean-k-mooney | it seamed like a good analog but not many peopel might make that connection | 15:58 |
| efried | 'ignore-unknown-keys' | 15:59 |
| efried | 'ignore-(well-okay-log-a-warning)-unknown-keys' | 15:59 |
| dansmith | so, | 16:00 |
| dansmith | I had to deal with something and lost track here | 16:00 |
| dansmith | one reason to not allow the client to choose more than strict or not-strict is that if you have permission to create flavors within your tenant, and you can set validation=warn (in the logs), then you can spam the server-side logs with warnings | 16:00 |
| dansmith | which would be considered somewhat of a DoS | 16:00 |
| stephenfin | we're adding a policy for this though, right? | 16:02 |
| dansmith | a policy for what? each of the values of the validation=(on|off|warn) ? | 16:03 |
| stephenfin | <dansmith> stephenfin: but I think it's legit to have a validation=no per-request, but that can return 403 either because of policy or config if it's documented when you add it, no? so later we could turn that off or default it off | 16:03 |
| stephenfin | what did you mean by that? ^ | 16:03 |
| stephenfin | I assumed you meant for the ability to set '?validation=<anything>' | 16:04 |
| dansmith | stephenfin: I meant state that validation=no might be disabled (i.e. always required) in the docs, so that we can allow that to be turned off in config or policy in the future if the op wants to require all flavors be validated | 16:04 |
| dansmith | I'm just arguing against having a client-controlled way to emit WARNING messages in the server-side logs | 16:05 |
| sean-k-mooney | or i guess restircted to a group e.g. admins although it is an admin only api already by default | 16:05 |
| stephenfin | I think WARNING might be a bit much, tbh. INFO seems appropriate if the user has explicitly requested no/limited validation | 16:06 |
| sean-k-mooney | the policy.json seam like a better approch if we were to make it configurable | 16:06 |
| stephenfin | If it was INFO, we'd be okay, right? | 16:06 |
| stephenfin | since no operator will get paged for INFO logs | 16:07 |
| sean-k-mooney | i think dansmith was concerned about ddos risks | 16:07 |
| dansmith | I dunno, I just don't like it in general | 16:07 |
| dansmith | right | 16:07 |
| sean-k-mooney | infor does not really help with hat | 16:07 |
| sean-k-mooney | *that | 16:07 |
| dansmith | but it's not a sticking point | 16:07 |
| dansmith | sean-k-mooney: correct | 16:07 |
| stephenfin | they could already ddos things but just repeatedly hitting the API with working extra specs | 16:07 |
| stephenfin | we log each request iirc | 16:07 |
| stephenfin | *by just | 16:07 |
| stephenfin | that's what API rate limiting is for | 16:08 |
| sean-k-mooney | well i suspect the error could be long if you add a bunch of invalide extra specs so its a larger risk | 16:08 |
| sean-k-mooney | but again its an admin only api by default | 16:08 |
| dansmith | and logging something that is a warning as info doesn't make it info | 16:08 |
| sean-k-mooney | so the request will get rejected by a normal user well before it hit your code | 16:08 |
| dansmith | but anyway, like I say, not a sticking point | 16:09 |
| stephenfin | Is it a warning though? Per above, info does seem appropriate if the user has explicitly requested no/limited validation | 16:09 |
| *** eharney has quit IRC | 16:09 | |
| stephenfin | It's a warning if they didn't, which they'll see in their HTTP 4xx response | 16:09 |
| dansmith | seems like a warning to me :) | 16:10 |
| dansmith | anyway | 16:10 |
| dansmith | we needn't argue about it | 16:10 |
| dansmith | I will just toldjaso if you get CVE paperwork over it :) | 16:10 |
| stephenfin | fine by me :) | 16:10 |
| *** maciejjozefczyk has quit IRC | 16:11 | |
| *** gyee has joined #openstack-nova | 16:14 | |
| bauzas | mmm, what the heck is this ? | 16:16 |
| bauzas | stestr: error: unrecognized arguments: --test-path=./nova/tests/functional run test_nova_manage | 16:16 |
| *** mlavalle has joined #openstack-nova | 16:16 | |
| bauzas | holy shit | 16:16 |
| bauzas | I probably need to upgrade stestr by hand | 16:16 |
| bauzas | but I did recreated my venc | 16:16 |
| bauzas | venv* | 16:17 |
| stephenfin | tox -e function --recreate ? | 16:17 |
| stephenfin | *al | 16:17 |
| stephenfin | unless you're using stestr without tox, which is odd | 16:18 |
| stephenfin | seeing as you can do stuff like 'tox -e functional -- -n path_to_functional_test.py::TestClass.test_method' | 16:18 |
| bauzas | stephenfin: that's what I did | 16:22 |
| bauzas | and I ended up with stestr==2.6.0 | 16:22 |
| bauzas | I always asked to run a subset of tests by doing tox -efunc <my_regex> | 16:23 |
| bauzas | and it worked | 16:23 |
| stephenfin | bauzas: That's what I have too. Working fine here | 16:24 |
| bauzas | checking with stestr==2.5.0 | 16:25 |
| *** TxGirlGeek has joined #openstack-nova | 16:25 | |
| bauzas | functional runtests: commands[0] | stestr --test-path=./nova/tests/functional run test_nova_manage | 16:25 |
| bauzas | mmmmm | 16:25 |
| stephenfin | bauzas: '$ tox -e functional -- test_nova_manage' wfm | 16:26 |
| bauzas | I never had to use the positional markers, but whatever, gonna try | 16:27 |
| bauzas | crazy, still same issue | 16:27 |
| stephenfin | want to dump the complete output to paste.o.o | 16:28 |
| stephenfin | it's something simple, I'd suspect | 16:28 |
| bauzas | yeah me too, but can't see the problem | 16:30 |
| bauzas | it's just stestr which doesn't sound to accept --test-path | 16:30 |
| bauzas | http://paste.openstack.org/show/788935/ | 16:30 |
| bauzas | actually, nope | 16:31 |
| bauzas | well, I'm puzzled | 16:33 |
| stephenfin | ah, wait, have you added additional tests for nova-manage? | 16:34 |
| stephenfin | There's a bug with oslo.config whereby the CLI parser is global'ish | 16:35 |
| stephenfin | Yeah, '--remote_debug-port' is a nova-manage option. You're not mocking stuff properly | 16:35 |
| stephenfin | bauzas: mriedem saw the issue pop up in a unit test at https://review.opendev.org/#/c/694806/2/ and it's currently causing an issue with glance and the latest version of cliff | 16:38 |
| *** lbragstad has quit IRC | 16:38 | |
| bauzas | stephenfin: interesting, if I use the functional-py36 target, it does work | 16:40 |
| stephenfin | even if you rebuild the venv? | 16:40 |
| bauzas | it was created, I never used the target yet | 16:41 |
| stephenfin | gotcha | 16:41 |
| stephenfin | weird | 16:41 |
| stephenfin | then I'm not sure :( | 16:41 |
| bauzas | to make it clear, the functional-py36 target works, but not the standard one | 16:41 |
| bauzas | either way, I know what to do, but I have to look at the target differences in tox.ini | 16:41 |
| *** luksky has quit IRC | 16:42 | |
| efried | bauzas: would it be productive for me to read the current PS of the numa topo spec, or wait til you rev it? | 16:42 |
| bauzas | efried: I'm wraping my head around the group_policy issue, but your thoughts could be helpful | 16:43 |
| bauzas | efried: and we have a disagreement on the memory modeling with NUMA with sean-k-mooney, your opinion could help us finding a consensus | 16:43 |
| bauzas | efried: to answer your question, yeah comments would be appreciated on the current rev | 16:44 |
| efried | okay, I'll give it a read. My view on group_policy is that we should be ignoring it. It doesn't really have a place with granular groups and the other knobs we put in in recent microversions. | 16:44 |
| efried | I at least proposed (though I don't remember if we actually pulled the trigger on this) making it no longer required in a recent microversion. | 16:44 |
| sean-k-mooney | bauzas: sorry can we pick this up after the internal call | 16:45 |
| sean-k-mooney | e.g. in 15 mins | 16:45 |
| bauzas | sean-k-mooney: yeah, and I even wanted to discuss it during the internal call :D | 16:45 |
| bauzas | (but I'm superseded by other topics :) ) | 16:45 |
| sean-k-mooney | ya i saw | 16:45 |
| efried | I won't be much help on the memory modeling, probably, as I really don't understand that level of detail of NUMA itself. But I'll give it a shot. | 16:47 |
| bauzas | tbh, me too | 16:48 |
| bauzas | the big question is should we iteratively model huge pages and have memory split now, or care about the whole now ? | 16:49 |
| efried | I'll have to refresh my memory (heh) on whether we did things to support cross-provider accumulation of resources, e.g. so you could still land on a NUMA-modeled host with 128/128 if you asked for 256. | 16:51 |
| *** eharney has joined #openstack-nova | 16:51 | |
| efried | I seem to recall we tried to KISS by saying you land on a NUMA-modeled host by asking for NUMA-modeled resources, and the converse, but that may have only been a point in time in the discussion, not where we landed. | 16:52 |
| efried | I'll have to swap this all back in. | 16:52 |
| bauzas | efried: yeah that's what I recall too | 16:53 |
| *** dviroel has left #openstack-nova | 16:55 | |
| *** jmlowe has quit IRC | 16:56 | |
| *** ociuhandu has quit IRC | 16:59 | |
| *** bnemec-ooo has quit IRC | 17:00 | |
| openstackgerrit | Vladyslav Drok proposed openstack/nova master: Fix volume attachment rollback https://review.opendev.org/704847 | 17:03 |
| *** jmlowe has joined #openstack-nova | 17:07 | |
| efried | nts: we did abandon "can_split" https://review.opendev.org/#/c/658510/ | 17:07 |
| sean-k-mooney | yes we did | 17:08 |
| * efried is rereading https://docs.openstack.org/placement/train/specs/train/implemented/2005575-nested-magic-1.html | 17:08 | |
| stephenfin | sean-k-mooney: for that memory issue, is there a reason we need to continue to support floating memory when NUMA is used? | 17:09 |
| stephenfin | do we do strict NUMA affinity when using a NUMA topology at the moment? | 17:09 |
| sean-k-mooney | that depends. yes but the question is do we care | 17:09 |
| stephenfin | for memory, that is | 17:10 |
| sean-k-mooney | we would have to pin the memoyy based on the placemetn allocation of all vms | 17:10 |
| stephenfin | I think we don't unless we explicitly request a pagesize, yeah? | 17:10 |
| sean-k-mooney | but for vms with out a numa toplogy we could pin that vm aross host numa nodes | 17:10 |
| stephenfin | okay, so that leads to my question: do we need to support that model? | 17:11 |
| stephenfin | VMs with a NUMA topology alongside those without? | 17:11 |
| efried | Again, I think we decided it was acceptable to enforce a segregated data center | 17:11 |
| sean-k-mooney | if we want to support vms without a numa toplogy yes | 17:11 |
| efried | where some hosts are NUMA-aware and some are not. | 17:11 |
| stephenfin | sean-k-mooney: we could have a knob | 17:11 |
| stephenfin | use_numa_in_placement | 17:11 |
| efried | And if you ask for a NUMA topo, you land on the former, always, exclusively. And the converse. | 17:11 |
| stephenfin | efried: right, thing we're talking about the same thing | 17:11 |
| stephenfin | *think | 17:11 |
| sean-k-mooney | i would prefer to handel it via resouce classes | 17:11 |
| sean-k-mooney | so if you report memory_mb its non numa aware memory | 17:12 |
| efried | Except for the upgrade issue, I think it wouldn't matter. | 17:12 |
| sean-k-mooney | if you reprot mempage_small its numa aware | 17:12 |
| efried | Upgrade is my only concern about doing MEMORY_MB now and pages later. | 17:12 |
| efried | because now you have flavors that straddle both models | 17:12 |
| stephenfin | sean-k-mooney: right, but that's duplication | 17:12 |
| efried | but they are mutually exclusive as to the hosts they work with. | 17:12 |
| sean-k-mooney | same for the cpu if you use VCPU its not numa aware and on the root provider if it SCPU its numa aware shared cpu | 17:12 |
| stephenfin | and instances will have to consume both | 17:13 |
| stephenfin | assuming we report both | 17:13 |
| sean-k-mooney | stephenfin: no the host would only report one or the other | 17:13 |
| efried | We shouldn't have the same resource represented by two different resource classes. We've nacked that idea many times in the past. | 17:13 |
| stephenfin | what determines what type we report? | 17:13 |
| sean-k-mooney | we did it with pcpus and vcpus | 17:13 |
| sean-k-mooney | but if we say that then MEMORY_MB is not the correct baseline for memory | 17:14 |
| efried | eh? No, the PCPU and VCPU counts represent different physical processors. | 17:14 |
| *** martinkennelly has quit IRC | 17:14 | |
| stephenfin | oh, so you're saying instead of having a "turn on NUMA" flag, we have two flags: one for non-NUMA memory and one for NUMA memory? | 17:14 |
| efried | yeah, I think we ought to bite the bullet on memory. If we're ever going to want it to be something other than MEMORY_MB, we should do that now. | 17:14 |
| sean-k-mooney | they represetn different pools of hardware threads | 17:14 |
| sean-k-mooney | but they are both the resouces | 17:14 |
| sean-k-mooney | we just treat them as if they are different | 17:14 |
| efried | my point is, they don't overlap | 17:14 |
| *** jmlowe has quit IRC | 17:15 | |
| sean-k-mooney | right so i think we should be modeling memory as mempages of a specifc size | 17:15 |
| *** lbragstad has joined #openstack-nova | 17:15 | |
| sean-k-mooney | we already do in the resouce tracker in the host numa toplogy blob | 17:15 |
| efried | If we have N pages that total to M mb of ram, we should *either* model PAGES=N *or* MEMORY_MB=M, but *never* both at the same time. | 17:15 |
| efried | I think we're agreeing on that, just want to be clear. | 17:15 |
| stephenfin | Yup | 17:15 |
| sean-k-mooney | yep although its slightly more complicated | 17:16 |
| efried | sean-k-mooney: I also want us to make sure we're not tying ourselves to libvirt unless that's inherently unavoidable. | 17:16 |
| sean-k-mooney | but in pricipal yes always one or the other | 17:16 |
| efried | I.e. are there other drivers that don't think of their NUMA-based memory in terms of pages? | 17:16 |
| sean-k-mooney | yes i want to add an abstration | 17:16 |
| stephenfin | maybe we should make like the 90s and teach placement about OOP | 17:16 |
| efried | Or that think of them as pages of a different size? | 17:16 |
| sean-k-mooney | so mempages_small and mempages_larage | 17:16 |
| stephenfin | 1GB_PAGES is_a PAGES | 17:16 |
| efried | hahaha, you're a funny guy. | 17:17 |
| sean-k-mooney | with 1G or 2MB large ppages modeld as a trait | 17:17 |
| efried | NO | 17:17 |
| sean-k-mooney | yes because we support hw:mem_page_size=large | 17:17 |
| stephenfin | PAGES_1M, surely? | 17:17 |
| efried | I hate that. | 17:17 |
| stephenfin | PAGES_1M, PAGES_2K, PAGES_1G? | 17:17 |
| sean-k-mooney | and that cant be modeld as pages_2M and pages _1G | 17:17 |
| efried | unless 1M is the only size we can ever have. | 17:17 |
| *** jmlowe has joined #openstack-nova | 17:17 | |
| efried | No | 17:18 |
| efried | we ought to be able to do that with MEMORY_MB with appropriate step_size. | 17:18 |
| sean-k-mooney | my point is we cant make mem_page_size=large work if the resouce class has the size info | 17:18 |
| efried | then you can ask for so many MB, and you'll get the right number of pages chopped up according to that step_size. | 17:18 |
| efried | pretty sure that's what step_size exists for. | 17:18 |
| sean-k-mooney | the step_zize and min/max allocation works | 17:18 |
| stephenfin | how does one determine the step size? | 17:19 |
| efried | it's the page size | 17:19 |
| sean-k-mooney | i have talked about that before | 17:19 |
| *** dtantsur is now known as dtantsur|afk | 17:19 | |
| efried | the virt driver knows how big a page is, yah? | 17:19 |
| stephenfin | large isn't a page size | 17:19 |
| sean-k-mooney | but we cant explctly request 1G or 2mb pages in that case | 17:19 |
| efried | no, 'large' isn't a thing. | 17:19 |
| stephenfin | it's anything bigger than 4k | 17:19 |
| sean-k-mooney | efried: yes it is | 17:19 |
| stephenfin | which could be 1G on half the compute nodes | 17:19 |
| sean-k-mooney | hw:mem_page_size=large is the recommend way to enable hugepages | 17:19 |
| efried | wait, so there are flavors that care how many pages they get, but not how much memory that ends up being???? | 17:20 |
| sean-k-mooney | yes | 17:20 |
| stephenfin | no | 17:20 |
| sean-k-mooney | well not pages | 17:20 |
| sean-k-mooney | but page size | 17:20 |
| stephenfin | they care about how much memory they get but not the exact size of the pages | 17:20 |
| stephenfin | just so long as it's != 4k | 17:20 |
| stephenfin | 2M, 1G, 8G (on POWER) - it's all fair game | 17:20 |
| sean-k-mooney | stephenfin: that is not alwasy true | 17:21 |
| sean-k-mooney | many people do care about the page size | 17:21 |
| efried | Did we ever implement required=in:T1,T2,T3? | 17:21 |
| sean-k-mooney | no | 17:21 |
| efried | so | 17:21 |
| sean-k-mooney | if we did we could use that | 17:21 |
| sean-k-mooney | although no it would not work because reqired in was for traits | 17:22 |
| efried | if people care about specific page sizes, we have a trait that says PAGE_SIZES_HERE_ARE_4K. | 17:22 |
| efried | But if people care about 'large', where that's allowed to mean "bigger than X", that doesn't work. | 17:22 |
| stephenfin | right, and those people are probably explicitly saying e.g. 'hw:mem_page_size=2k' | 17:22 |
| sean-k-mooney | yes | 17:22 |
| stephenfin | or know that their datacenter is configured with only 2k or 1G pages | 17:22 |
| efried | (is bauzas still listening btw?) | 17:22 |
| stephenfin | bauzas is on kid duty | 17:22 |
| stephenfin | but has scrollback | 17:22 |
| efried | k | 17:22 |
| efried | yuh | 17:22 |
| stephenfin | efried: Still not sure how we do the step_size determination though | 17:23 |
| sean-k-mooney | https://etherpad.openstack.org/p/mem_page_size_and_placement | 17:23 |
| sean-k-mooney | lets go there too | 17:23 |
| efried | stephenfin: Doesn't the virt driver know how big its pages are? | 17:23 |
| sean-k-mooney | yes | 17:23 |
| *** jmlowe has quit IRC | 17:23 | |
| efried | that's the step_size. | 17:23 |
| sean-k-mooney | and a host can have multiple pages sizes | 17:23 |
| efried | in the same numa cell? | 17:24 |
| sean-k-mooney | a host can have 4k 2mb and 1g in the same cell yes | 17:24 |
| gibi | stephenfin: having a single representation is a positive thing for me. and I accept that it will be python instead of yaml | 17:24 |
| stephenfin | But you don't know what virt driver you're going to use before you query placement | 17:24 |
| efried | stephenfin: step_size is part of the model, not part of the query. | 17:24 |
| sean-k-mooney | yep which is why large is a thing | 17:24 |
| sean-k-mooney | efried: yep that was why step size did not work when i discussed this in the past | 17:24 |
| efried | because you can have different size pages in the same cell. | 17:25 |
| sean-k-mooney | we cant say 10G of ram in 1G increments | 17:25 |
| sean-k-mooney | at least not with just stepsize | 17:25 |
| stephenfin | efried: you can, and not everything the same size | 17:25 |
| efried | okay, then there's no way this works without an abstraction and/or simplification. | 17:25 |
| *** jmlowe has joined #openstack-nova | 17:25 | |
| efried | so we need to decide what to cut | 17:25 |
| stephenfin | How would you say "give me a compute node that can handle an 8GB instance with 1G pages" | 17:26 |
| efried | because we're not going to make resource classes for PAGE_$size | 17:26 |
| stephenfin | I don't see how we can avoid it | 17:26 |
| stephenfin | a 4k page != a 2M page | 17:26 |
| efried | stephenfin: because then you *can't* say "give me an instance with 8GB" | 17:26 |
| efried | which is surely the more common use case? | 17:27 |
| stephenfin | sure you can | 17:27 |
| stephenfin | we just translate the request | 17:27 |
| efried | you would have to translate the request into multiple GET /a_c queries. | 17:27 |
| efried | because you can build 8GB a zillion different ways | 17:27 |
| efried | AND it requires discovery of which page-size-resource-classes exist in your deployment. | 17:27 |
| efried | that's a non-starter, sorry. | 17:27 |
| stephenfin | No, you can't consume hugepages unless you explicitly request them | 17:28 |
| sean-k-mooney | so by default if you dont specify hw:mem_page_size it has to be the smalles page size | 17:28 |
| sean-k-mooney | efried: that is why i want mempage_small and mempage_large to be different resoce classes | 17:28 |
| efried | but "huge" isn't a discrete number? | 17:28 |
| efried | so again, if you do that, you can't ask for 8GB | 17:28 |
| stephenfin | hugepages are offlimits for instances without 'hw:mem_page_size' | 17:28 |
| stephenfin | right, sean-k-mooney? | 17:28 |
| efried | because you have to ask for a number of pages, but you don't know how big those pages are. | 17:28 |
| stephenfin | yeah, that one is a problem | 17:29 |
| stephenfin | because it's intentionally abstract | 17:29 |
| sean-k-mooney | yes | 17:29 |
| sean-k-mooney | if you dont set hw:mem_page_size you will only use 4k memory | 17:29 |
| stephenfin | right | 17:29 |
| stephenfin | so for non-hugepages instances, there will only ever be a single GET /a_c query | 17:29 |
| efried | um | 17:30 |
| stephenfin | for MEMORY_MB or PAGES_4K or whatever we call it | 17:30 |
| sean-k-mooney | efried: its that way because people wanted to change for hugepages and people did not want all instacne to have a numa toplogy by defualt | 17:30 |
| efried | there will only ever be a single GET /a_c query. | 17:30 |
| efried | ever ever | 17:30 |
| stephenfin | not for pinned instances, at the moment | 17:30 |
| stephenfin | but that's a temporary thing | 17:30 |
| stephenfin | agreed | 17:30 |
| sean-k-mooney | so i was proposeing useing MEMORY_MB for non numa small pages | 17:30 |
| sean-k-mooney | e.g. on the root RP | 17:31 |
| efried | sean-k-mooney: we're simplifying the "all instances have a numa topology" aspect by saying that NUMA-aware requests only go to NUMA-modeled hosts and vice versa. | 17:31 |
| stephenfin | sean-k-mooney: agree on the first part. disagree on the second | 17:31 |
| stephenfin | it's on the root RP if that compute node is configured to be NUMA'y | 17:31 |
| sean-k-mooney | well that is all hosts | 17:31 |
| efried | The small pages are still affined, yah? | 17:31 |
| efried | So they should be modeled on the NUMA RPs | 17:31 |
| sean-k-mooney | there are no non numa host for the better part of a decade | 17:31 |
| stephenfin | efried: If you're using guest NUMA, they should be | 17:31 |
| stephenfin | sean-k-mooney: No, but there are people who pretend they don't exist | 17:32 |
| stephenfin | *they exist | 17:32 |
| sean-k-mooney | efried: they have an affinty but they are allocated by the kernel | 17:32 |
| efried | yeah, so given a strict NUMA-or-not split, I don't see a reason to keep any memory on the root | 17:32 |
| sean-k-mooney | and they can move between numa nodes | 17:32 |
| stephenfin | by creating e.g. 128GB instances on a dual socket compute node with only 64GB RAM per node | 17:32 |
| sean-k-mooney | so unless we pinn the memory to a numa node when we creat the vm the kernel manages where the pages are paged form | 17:33 |
| sean-k-mooney | for hugepages we allways pin them to a numa node | 17:33 |
| efried | and why would we not pin the small pages? | 17:33 |
| efried | wait | 17:33 |
| efried | let me turn that around: | 17:33 |
| *** rpittau is now known as rpittau|afk | 17:33 | |
| efried | do we ever want to make sure we *do* pin the small pages? | 17:33 |
| sean-k-mooney | we have an option for that today | 17:34 |
| sean-k-mooney | if you set hw:mem_page_size=small | 17:34 |
| efried | k, then we should model them in the numa cells, and always pin them. | 17:34 |
| sean-k-mooney | if you set hw:mem_page_size it will be pinned | 17:34 |
| stephenfin | If we're modelling NUMA in placement, then yes. We want to make sure that the memory placement allocated came from the actual provider (the host NUMA node) | 17:34 |
| efried | that will mean there are a few cases where you didn't care about that and you don't land on a host whose small pages are sparse and spread across cells. But we've already said we're accepting that. | 17:35 |
| sean-k-mooney | efried: we could but the implciation of that are 1 of the follow two things need to happen | 17:35 |
| stephenfin | otherwise placements says "here's 8GB from <RP mapping to host NUMA node #1>", but on the host that memory comes from node #0 | 17:35 |
| stephenfin | and placement doesn't reflect reality | 17:35 |
| sean-k-mooney | 1 all vms must be numa vms and there fro cannot span host numa nodes unless you set hw:numa_nodes>1 | 17:36 |
| efried | this ^ | 17:36 |
| sean-k-mooney | or we have to allow a singel numa node guest to sapn host numa nodes based on the placement allcoation | 17:36 |
| efried | nope | 17:36 |
| stephenfin | alternative | 17:36 |
| efried | Your VM is a numa VM | 17:36 |
| stephenfin | let people turn off the NUMA reporting | 17:36 |
| stephenfin | make everything flat again | 17:36 |
| efried | If it's not a numa VM, it doesn't land on a NUMA host | 17:36 |
| efried | yes, that ^ | 17:36 |
| sean-k-mooney | ok i have argued for your vm is a numa vm for years | 17:37 |
| stephenfin | Yeah, I also want that | 17:37 |
| efried | sorry, you're misunderstanding. | 17:37 |
| stephenfin | I know what efried is going to say | 17:37 |
| stephenfin | the NUMA reporting has to be turned on? | 17:37 |
| sean-k-mooney | ok no i get what your saying | 17:37 |
| sean-k-mooney | but to not land on a numa host i think we need to have 2 resouce classes | 17:37 |
| stephenfin | defaults to off | 17:37 |
| efried | We force deployers to split their data center. | 17:38 |
| efried | N hosts are NUMA-modeled. All and only VMs with a NUMA topo land on those hosts. | 17:38 |
| efried | M hosts are flat. All and only *non* NUMA topo VMs land on those hosts. | 17:38 |
| sean-k-mooney | so in pricipal you shoudl be doing that partioning alreday | 17:38 |
| sean-k-mooney | for reason i wont go into today | 17:38 |
| efried | exactly. | 17:38 |
| stephenfin | she borked. | 17:38 |
| stephenfin | (if you don't do that partitioning) | 17:38 |
| sean-k-mooney | elequently said | 17:39 |
| efried | there may be a way we can support a small amount of overlap in the future, but for the moment I think it wouldn't be a terrible idea to add (under the covers) a required or forbidden trait that makes sure you land on the right kind of host. | 17:39 |
| efried | like the NUMA_ROOT trait on the provider from which you're requesting $resource. | 17:39 |
| efried | so let's get back to pages. | 17:39 |
| stephenfin | that might be needed to handle the upgrade impact | 17:39 |
| efried | How many "abstract" page sizes are there? | 17:39 |
| efried | small/large/huge? | 17:40 |
| stephenfin | we can't expect users to go set the "this is NUMA node" flag ahead of time | 17:40 |
| stephenfin | efried: small, large | 17:40 |
| stephenfin | hey, I documented that for my validator | 17:40 |
| efried | stephenfin: totally not, that happens under the covers, now and forever, if it happens at all. | 17:40 |
| efried | okay, and how many *discrete* page sizes are there within those buckets? | 17:40 |
| sean-k-mooney | small/large/any or a specifc page size expressed as an integer with an optional suffix | 17:40 |
| stephenfin | https://review.opendev.org/#/c/704643/2/nova/api/validation/extra_specs/hw.py@113 | 17:41 |
| efried | \o/ | 17:41 |
| stephenfin | noting sean-k-mooney's comment | 17:41 |
| sean-k-mooney | the integuer is unbounded but in pratice about 12ish | 17:41 |
| stephenfin | efried: architecture dependent | 17:41 |
| stephenfin | Intel supports 2M and 1G | 17:41 |
| stephenfin | *x86 | 17:41 |
| efried | lovely. Is there overlap on what's considered small and large? | 17:41 |
| stephenfin | POWER supports 8G, iirc | 17:41 |
| sean-k-mooney | efried: jay put up a patch to os resouces for the common ones a while ago | 17:41 |
| stephenfin | Who knows what ARM supports | 17:42 |
| efried | that is, are there discrete values that are considered small on some systems and large on others? | 17:42 |
| stephenfin | ALL the pagesizes | 17:42 |
| sean-k-mooney | efried: in practice not really but technically there can be | 17:42 |
| stephenfin | sean-k-mooney: 4k is a small page _everywhere_, right? | 17:42 |
| sean-k-mooney | small is almost always 4k | 17:42 |
| sean-k-mooney | no | 17:42 |
| efried | those are different statements | 17:42 |
| sean-k-mooney | small is the native pagesize of the host | 17:42 |
| sean-k-mooney | and the smallest in the available set | 17:43 |
| sean-k-mooney | it is almost alwasy 4k and raely 16k or 64k | 17:43 |
| stephenfin | sean-k-mooney: The internet tells me 4k is hardcoded as the default page size in Linux | 17:43 |
| stephenfin | https://unix.stackexchange.com/a/128218 | 17:43 |
| sean-k-mooney | yes on x86, aarch64 and power9 | 17:44 |
| stephenfin | okay, we don't need to care about anything else, realistically | 17:44 |
| sean-k-mooney | that why i said its almost alwasy 4k | 17:44 |
| stephenfin | we can stick a giant TODO in somewhere in case someone wants to run openstack on obscure architecture | 17:45 |
| sean-k-mooney | we can proably treat it as such | 17:45 |
| stephenfin | agreed | 17:45 |
| stephenfin | s/TODO/NOTE/ | 17:45 |
| stephenfin | efried: what are you referring to? | 17:45 |
| *** TxGirlGeek has quit IRC | 17:45 | |
| sean-k-mooney | large is defiend as any pagesize that is not the same as small on the plathform | 17:45 |
| efried | okay, so I'm afraid the compromise we need to make is this: | 17:45 |
| efried | Represent all the memory as MEMORY_MB with a step_size that's the least common denominator of all the page sizes. | 17:45 |
| efried | Supply traits saying things like I_HAVE_$SIZE_PAGES_HERE, where $SIZE can include both discrete and abstract sizes. | 17:45 |
| efried | Use ^ where possible to make the placement pass a bit better | 17:45 |
| efried | but accept that it's not going to be perfect, and that we have to do the rest in the NTF. | 17:45 |
| efried | ...which may entail bouncing a host late. | 17:46 |
| stephenfin | I don't understand how step_size would work | 17:46 |
| sean-k-mooney | efried: if we do that we need to keep the hugepage code in the resouce tracker and numa toplogy filter for ever | 17:46 |
| efried | I'm afraid that may be unavoidable, unless we make big changes in placement, or people agree to stop needing that shit. | 17:47 |
| sean-k-mooney | efried: if we had a placement exteion weree we could pass a step size in the querry that would help | 17:47 |
| stephenfin | I have a host that have 16 1GB hugepages and the rest are normal small pages | 17:47 |
| efried | stephenfin: example, if we have 4K, 1M, and 2G pages, the step_size has to be 4K | 17:47 |
| stephenfin | you will always use 4k so | 17:47 |
| stephenfin | every host is going to report small pages | 17:48 |
| efried | okay, so be it. | 17:48 |
| sean-k-mooney | efried: not all the moroy can be allocated in 4k | 17:48 |
| sean-k-mooney | on that host | 17:48 |
| sean-k-mooney | hugepages are preallcoted | 17:48 |
| sean-k-mooney | with a given page size | 17:48 |
| stephenfin | I don't get how this solves anything | 17:48 |
| efried | yeah, I understand that. We have to do that part via the NTF. I don't see a way around it. | 17:48 |
| efried | "solves" | 17:48 |
| efried | it gives us a way to move forward | 17:48 |
| efried | and support all the variants we need | 17:49 |
| sean-k-mooney | well the thing is if we had different resocue classes hugepage was one of the things we had determin could be fully done by placment | 17:49 |
| stephenfin | this is essentially not modelling different page sizes in placement | 17:49 |
| sean-k-mooney | if we modeld the different pages sizes in placment | 17:49 |
| efried | stephenfin: correct. | 17:49 |
| stephenfin | NUMA is all about memory | 17:49 |
| sean-k-mooney | so thats a lot of work for very littel benifit | 17:49 |
| sean-k-mooney | yep | 17:49 |
| efried | we cannot do that and also support requests for MEMORY_MB=$X that don't care about pages. | 17:49 |
| stephenfin | what's the point in modelling NUMA in placement if we don't do the memory modelling? | 17:50 |
| efried | affinity | 17:50 |
| sean-k-mooney | efried: we can if MEMORY_MB is always for non numa memory | 17:50 |
| stephenfin | we have the NUMA topology filter for that | 17:50 |
| stephenfin | good enough | 17:50 |
| efried | stephenfin: this allows us to move a big swatch of the affinity filtering to the placement query. | 17:50 |
| efried | just not all of it. | 17:50 |
| sean-k-mooney | efried: no it does not | 17:50 |
| efried | and not as much as we would have liked | 17:50 |
| efried | wha? | 17:50 |
| stephenfin | very little of it | 17:50 |
| efried | wha?? | 17:51 |
| sean-k-mooney | we will have to do it all again in the ntf | 17:51 |
| stephenfin | yup | 17:51 |
| efried | um | 17:51 |
| efried | no | 17:51 |
| efried | look | 17:51 |
| sean-k-mooney | we may have less host to check | 17:51 |
| *** salmankhan has quit IRC | 17:51 | |
| stephenfin | what's the objection to modelling different page sizes as different resource types? | 17:51 |
| stephenfin | they're different things | 17:51 |
| sean-k-mooney | but we still need to check all aspecs again | 17:51 |
| stephenfin | something that ask for one can't consume the other | 17:51 |
| efried | Because it makes it impossible to request a certain amount of memory without asking for specific pages. | 17:51 |
| sean-k-mooney | there is another way to do it | 17:51 |
| sean-k-mooney | we can do it in 1 resouce class | 17:52 |
| sean-k-mooney | MEMORY_MB | 17:52 |
| stephenfin | but it doesn't | 17:52 |
| efried | how would you do it stephenfin? | 17:52 |
| sean-k-mooney | but we need 1 RP per page size | 17:52 |
| stephenfin | we report MEMORY_MB for normal 4k pages | 17:52 |
| sean-k-mooney | and each RP would be under a numa node | 17:52 |
| stephenfin | and then PAGES_4M, PAGES_1G, etc. for the various hugepage sizes | 17:52 |
| sean-k-mooney | that wont work | 17:53 |
| stephenfin | if instances aren't requesting page sizes, they get MEMORY_MB | 17:53 |
| sean-k-mooney | because it breaks large | 17:53 |
| stephenfin | it does, and we'll need to figure out a migration plan for that | 17:53 |
| sean-k-mooney | mem_page_size=large is the most common case | 17:53 |
| efried | Okay, so if you don't ask for large pages, you only get small pages, and if the only way to satisfy your memory requirement would be by using the large pages, you just bounce. | 17:53 |
| stephenfin | you can't use the large pages | 17:53 |
| stephenfin | unless you *explicitly* ask for them | 17:53 |
| efried | is that what happens today? | 17:53 |
| stephenfin | yup | 17:53 |
| efried | okay cool. | 17:54 |
| sean-k-mooney | yes | 17:54 |
| stephenfin | given a host with 8GB of RAM, of which 4GB is allocated to 1GB huge pages | 17:54 |
| sean-k-mooney | which is why you have to partion the host today | 17:54 |
| sean-k-mooney | we have 2 memory tracker in nova today | 17:54 |
| efried | is it possible today to ask for both small and large pages in the same request, or is mem_page_size=large all or nothing? | 17:54 |
| stephenfin | only 4GB is actually usable | 17:54 |
| sean-k-mooney | one is numa and page size aware and the other just looks at total memory | 17:54 |
| stephenfin | nope, all or nothing | 17:55 |
| efried | cool | 17:55 |
| efried | then yes, split into two resource classes. | 17:55 |
| sean-k-mooney | efried: there is mempage_size=any | 17:55 |
| efried | ugh | 17:55 |
| sean-k-mooney | but that just means the image gets to choose | 17:55 |
| stephenfin | N resource classes | 17:55 |
| efried | and if the image doesn't specify... bounce? | 17:55 |
| sean-k-mooney | and it will be small if not stated | 17:55 |
| efried | stephenfin: Still can't do N resource classes. Have to have two. | 17:55 |
| stephenfin | Can't do two | 17:55 |
| efried | one for small, one for large. | 17:55 |
| efried | Each one has a step_size that's the least common denominator of the pages in that range. | 17:56 |
| stephenfin | Host has some 1G hugepages and some 2M pages | 17:56 |
| sean-k-mooney | efried: any was ment to give you the smallest pagesize available but we skimed on it and just do 4k pages i think | 17:56 |
| stephenfin | I can't request some of the former and some of the latter | 17:56 |
| stephenfin | It has to be one or the other | 17:56 |
| sean-k-mooney | stephenfin: that is a nova limitation | 17:56 |
| efried | okay, but if you say LARGE, we get to pick | 17:56 |
| stephenfin | So placement could say "oh, I have hugepages", but it turns out they're different sizes | 17:56 |
| sean-k-mooney | not a libvirt one but we should not mix them | 17:56 |
| stephenfin | and it can't actually fulfil that request | 17:56 |
| efried | yeah, the resource class would not indicate number of pages, it's still a number of MB. | 17:57 |
| efried | right, that's the part we would have to defer to the NTF | 17:57 |
| efried | Otherwise you *still* can't say memory=4GB,page_size=large because we would have no way to translate that request. | 17:57 |
| sean-k-mooney | yes | 17:57 |
| efried | ...without doing multiple placement queries, which is a hard no. | 17:57 |
| stephenfin | then find a way to kill page_size=large or convert it at the API level | 17:57 |
| sean-k-mooney | so there is a way to do this with only one resocue class + traits | 17:57 |
| stephenfin | api config option | 17:58 |
| stephenfin | large_mem_page_size = PAGE_2M | 17:58 |
| sean-k-mooney | but to do that it need a 3 level resouce provider tree | 17:58 |
| stephenfin | that's required from N+1 | 17:58 |
| stephenfin | as an interim step in N, we make two requests, one for PAGE_2M, one for PAGE_1G | 17:58 |
| sean-k-mooney | stephenfin: mem_page_size=large is the most comonly used value | 17:58 |
| stephenfin | like we're doing for VCPU and PCPU rn | 17:58 |
| stephenfin | sean-k-mooney: yup, and we can continue supporting it | 17:59 |
| efried | is that not config-driven API behavior? | 17:59 |
| efried | the thing you just told me was a no-no | 17:59 |
| stephenfin | we just have to ask operators to define what large aliases to | 17:59 |
| sean-k-mooney | no | 17:59 |
| efried | but that only works if the deployment only has one large page size? | 17:59 |
| stephenfin | on the assumption that people aren't mixing and matching different page sizes | 17:59 |
| efried | and if that's true, then the whole issue is moot | 17:59 |
| sean-k-mooney | because its not uncommon for the same cloud to have both | 17:59 |
| efried | if we can assume that, we're golden. | 18:00 |
| stephenfin | why would they do that? | 18:00 |
| sean-k-mooney | that is not a safe assumtion | 18:00 |
| sean-k-mooney | because differnt applciation perfrom better | 18:00 |
| * efried ==> bio break | 18:00 | |
| sean-k-mooney | with different page sizes | 18:00 |
| stephenfin | by application you mean something in an instance? | 18:00 |
| stephenfin | if so, are they actually using 'large'? | 18:01 |
| stephenfin | vs. the size that performs better | 18:01 |
| stephenfin | *best | 18:01 |
| sean-k-mooney | also 1G was added a lot later then 2mb | 18:01 |
| sean-k-mooney | it requires specifc cpu support | 18:01 |
| stephenfin | okay, so this will force operators to choose one or the other for their deployment | 18:01 |
| sean-k-mooney | they use large for applciation that can support either and 1G when needed | 18:01 |
| sean-k-mooney | yes which i dont think we need to do | 18:02 |
| sean-k-mooney | im going to skech somthing up for ye to review | 18:02 |
| sean-k-mooney | give me 2 mins | 18:02 |
| stephenfin | yeah, good idea | 18:02 |
| stephenfin | I know what efried's approach is and I don't like it | 18:02 |
| stephenfin | Don't grok yours yet though | 18:02 |
| stephenfin | Also, I'm supposed to be going out for dinner so I should probably scarper for now | 18:03 |
| sean-k-mooney | what is the ascii site we use for specs | 18:03 |
| *** lbragsta_ has joined #openstack-nova | 18:03 | |
| stephenfin | ascii? | 18:03 |
| stephenfin | ascii site? | 18:03 |
| stephenfin | for drawing? | 18:03 |
| sean-k-mooney | http://asciiflow.com/ | 18:03 |
| *** derekh has quit IRC | 18:03 | |
| sean-k-mooney | ya i litrally ment draw since its clearer | 18:03 |
| stephenfin | oh, I was going to say just use https://www.draw.io/ | 18:04 |
| stephenfin | or https://docs.google.com/drawings | 18:04 |
| stephenfin | anyway, let me know what you draft | 18:04 |
| * stephenfin buggers off home | 18:04 | |
| *** TxGirlGeek has joined #openstack-nova | 18:09 | |
| sean-k-mooney | stephenfin: im thinking 3 layers like this | 18:09 |
| sean-k-mooney | https://etherpad.openstack.org/p/mem_page_size_and_placement | 18:09 |
| *** luksky has joined #openstack-nova | 18:09 | |
| sean-k-mooney | efried: bauzas ^ | 18:14 |
| efried | sean-k-mooney: step_size=4 doesn't make sense unless we use MEMORY_KB | 18:14 |
| sean-k-mooney | well actuly i gues it would be 1024 | 18:15 |
| sean-k-mooney | since we limit flavor to 1mb granuarity | 18:15 |
| efried | tbc, it's not really a problem to introduce new RCs for this, since we're doing the translation under the covers and only allowing NUMA-modeled VMs on NUMA-modeled hosts. | 18:15 |
| sean-k-mooney | its only there becasue you can say mem_page_size=4 or 4k today | 18:15 |
| efried | okay, that's fine. | 18:15 |
| efried | The three-tiered approach works IF you always get exactly one page size | 18:16 |
| sean-k-mooney | this will allow all the sentinels to wrok and we can remove the hugepage page tracking from the numa toplogy filter/resouce tracker | 18:16 |
| sean-k-mooney | efried: yes today we only allow 1 page size | 18:16 |
| sean-k-mooney | so if we dont enable more flexiblity then today we can make that assumtion a requirement | 18:17 |
| efried | so if I have three different hugepage sizes on the same numa cell, say 1G, 2G, 4G, then memory=8G,page_size=large will only ever get me one of | 18:18 |
| efried | [2 x 4G] | 18:18 |
| efried | [4 x 2G] | 18:18 |
| efried | [8 x 1G] | 18:18 |
| efried | but never e.g. [1 x 4G] + [4 x 1G] | 18:18 |
| efried | right? | 18:18 |
| sean-k-mooney | yes | 18:19 |
| efried | cool, then this works, I like it. | 18:19 |
| sean-k-mooney | libvirt support mixing and we intentionaly do not | 18:19 |
| sean-k-mooney | i propsoed this in the past and the main push back is an extra layer adds well an extra layer | 18:19 |
| efried | shall I write it up in the spec comments? | 18:19 |
| efried | yeah, the layer doesn't bother me. It's totally abstracted from the user. | 18:20 |
| *** lbragsta_ has quit IRC | 18:20 | |
| sean-k-mooney | sure that would be awsome | 18:20 |
| efried | cool, on it. | 18:20 |
| sean-k-mooney | well when i first propsoed this we did not have the abitiy to query nested rps because i first brough up this design 3-4 releases ago | 18:21 |
| sean-k-mooney | so people were more conserend about 3 level when 2 level did not work | 18:21 |
| efried | with placement today, this totally works. | 18:21 |
| efried | you can represent the affinity using same_subtree | 18:22 |
| efried | so the extra layer doesn't break that. | 18:22 |
| sean-k-mooney | ya | 18:22 |
| *** tosky has quit IRC | 18:22 | |
| sean-k-mooney | if we do it this way we can remove much of the logic form the NTF and numa resouce tracker | 18:22 |
| sean-k-mooney | unlike cpu pinning hugepage just need to know how much of each page type is avaible per numa node | 18:23 |
| sean-k-mooney | so placement with 3 level can model eveything we need to track | 18:23 |
| sean-k-mooney | so we could remvoe all the mempage trackinging in the host numa topology blob and only compute that in memroy to update the palcement inventory | 18:24 |
| melwitt | stephenfin: looks like your update covered most of what was there but looks like you left out the server names the test was filling in before? https://review.opendev.org/695220 | 18:28 |
| *** priteau has quit IRC | 18:33 | |
| *** eharney has quit IRC | 18:38 | |
| *** benj_ has quit IRC | 18:47 | |
| *** benj_ has joined #openstack-nova | 18:47 | |
| *** ralonsoh has quit IRC | 18:47 | |
| *** eharney has joined #openstack-nova | 18:51 | |
| *** iurygregory has quit IRC | 18:52 | |
| sean-k-mooney | efried: fyi the ther node would be for vgpus althoug they would proably go a the bottem level of the tree beside the memory ones | 18:54 |
| sean-k-mooney | * the other nodes below the RP | 18:54 |
| efried | For now we're punting on devices, so we'll leave the VGPUs where they are and not support affinity. Later, I agree, the providers representing PGPUs would be underneath the NUMA nodes, parallel to the memory providers. | 18:54 |
| sean-k-mooney | yep | 18:55 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Repro gen conflict in COMPUTE_STATUS_DISABLED handling https://review.opendev.org/704865 | 18:55 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reduce gen conflict in COMPUTE_STATUS_DISABLED handling https://review.opendev.org/704866 | 18:55 |
| sean-k-mooney | efried: i know we have customer request for numa aware gpus/vgpus but we agreed even internally that that should wait until after the memory/cpu case is done | 18:56 |
| sean-k-mooney | so im fine with that | 18:56 |
| efried | yeah, sure, we're not going to not do it, we're just not going to do it now. | 18:56 |
| sean-k-mooney | yep | 18:57 |
| efried | sean-k-mooney: I'm going to put some examples in the etherpad, but will need you to go through and edit my spelling on the extra specs. | 18:57 |
| sean-k-mooney | hehe i will try | 18:58 |
| * sean-k-mooney editing spelling means breaking it or fixing it ... | 18:58 | |
| efried | I figure if I ask you to edit the spelling of real tokens I have a better chance. | 18:58 |
| efried | vs. English. | 18:58 |
| sean-k-mooney | yes you do | 18:59 |
| efried | ye gods, it just occurred to me: do you speak gaelic? | 18:59 |
| efried | your writing in gaelic must be IMPOSSIBLE to understand, given that gaelic is impossible to read in the first freakin place. | 18:59 |
| *** tesseract has quit IRC | 18:59 | |
| sean-k-mooney | yes and no. i went to an all irish play school and got an irish langage exemption becaue i coudl not write in irish | 19:00 |
| sean-k-mooney | i could speak it and could kind of read it | 19:00 |
| efried | "oh, let me just throw an extra consonant and an extra vowel in each syllable. Half of them will be silent. Which ones? Who knows? It's a surprise!" | 19:00 |
| sean-k-mooney | hehe irish is interesting that way | 19:00 |
| sean-k-mooney | espcially since spelling of a verb chagne with gender pluarlity and something the noun it is used ith | 19:01 |
| *** spatel has joined #openstack-nova | 19:02 | |
| *** igordc has joined #openstack-nova | 19:02 | |
| sean-k-mooney | actully do you want that to be a numa instance example or not | 19:05 |
| sean-k-mooney | i assume a numa one | 19:06 |
| sean-k-mooney | a non numa one would not have hw:mem_page_size set at all and not triat | 19:06 |
| efried | eandersson: can you write me a flavor example with two numa nodes where one has small pages and one has large? | 19:10 |
| efried | whoops, eandersson disregard. ^ was for sean-k-mooney | 19:10 |
| sean-k-mooney | no | 19:10 |
| sean-k-mooney | pagesize is vm wide | 19:10 |
| efried | (my IRC client has been dropping the first char of my messages lately) | 19:10 |
| efried | okay, fine, can you write me a flavor with two numa nodes and an explicit page size? | 19:11 |
| sean-k-mooney | yes ill add 2 | 19:11 |
| efried | (turns out 'sean<tab>' minus the first character is 'ean<tab>') | 19:11 |
| sean-k-mooney | hehe ill remove our disscution on the first example to clean up the description | 19:12 |
| *** jmlowe has quit IRC | 19:14 | |
| sean-k-mooney | you can also split the cpu asemetircly but that is overkill for the exampels i think | 19:16 |
| sean-k-mooney | for the implict splitign its an error if the cpus and ram and not evenly devisable by the number of numa nodes | 19:17 |
| efried | sean-k-mooney: I prefer leaving that third example as it was before, since it shows that we could land on either of the LARGE RPs. | 19:19 |
| efried | ++ | 19:19 |
| sean-k-mooney | ya | 19:19 |
| sean-k-mooney | that is why i reverted it | 19:19 |
| sean-k-mooney | any why i used large in the first place | 19:19 |
| efried | sean-k-mooney: any other examples that we should throw in? | 19:19 |
| sean-k-mooney | am maybe a non numa guests | 19:20 |
| efried | yeah | 19:20 |
| efried | to show that it would not land on the sample host at all. | 19:21 |
| sean-k-mooney | yes | 19:22 |
| sean-k-mooney | i was trying to figure out the not num host | 19:22 |
| sean-k-mooney | *numa | 19:22 |
| sean-k-mooney | if we did not add the forbiden trait | 19:23 |
| sean-k-mooney | then it could actully land on that host | 19:23 |
| sean-k-mooney | but we would have to pin it to a numa node | 19:24 |
| sean-k-mooney | which we could do but we proably dont want too | 19:24 |
| sean-k-mooney | so you can continue to create vms that span numa nodes if you dont care | 19:24 |
| efried | right, that's what I was implying earlier when I said we could probably overlap, but should prevent that for now | 19:24 |
| efried | oh, that wouldn't allow you to span numa nodes. | 19:24 |
| sean-k-mooney | ya | 19:24 |
| sean-k-mooney | ya it would not you are right | 19:24 |
| efried | oh, I see, you mean your proc from one and your mem from another | 19:24 |
| sean-k-mooney | not without can split | 19:24 |
| sean-k-mooney | you could have procs and memory span ya | 19:25 |
| sean-k-mooney | but can_split would be need to have any one resouce span numa nodes | 19:25 |
| efried | yeah, actually, the non-NUMA example can be simplified if we just use a granular group for the proc & mem.... | 19:25 |
| sean-k-mooney | ya | 19:26 |
| sean-k-mooney | that would work | 19:26 |
| efried | simpler, I like. | 19:26 |
| *** eharney has quit IRC | 19:26 | |
| sean-k-mooney | oh we are missign something from all of them | 19:26 |
| sean-k-mooney | we need to add group_policy=none | 19:26 |
| sean-k-mooney | because we are using granular groups | 19:26 |
| sean-k-mooney | we still get the correct affintiy because fo same tree in the multi numa case | 19:27 |
| sean-k-mooney | even with group_policy=none | 19:28 |
| efried | yeah, I was just going to check whether we in fact did remove group_policy in the latest microversions. | 19:28 |
| efried | it's irrelevant in this case. We get the same result with isolate or none | 19:29 |
| sean-k-mooney | looking at the api doces its still there | 19:29 |
| efried | okay, boo. But as noted above, it's irrelevant, so set it to whatever. Do you agree? | 19:29 |
| sean-k-mooney | it can be in this case | 19:29 |
| sean-k-mooney | but isolate breaks eaisly | 19:30 |
| sean-k-mooney | for example 2 port with bandwith requests | 19:30 |
| sean-k-mooney | so i dont like publicising its use | 19:30 |
| efried | Right, so the point is, we can leave it to the user and/or the bandwidth code to decide on group_policy. | 19:30 |
| *** spatel has quit IRC | 19:30 | |
| sean-k-mooney | yes | 19:30 |
| efried | IIRC the bandwidth code is defaulting it rn. | 19:30 |
| efried | or at least we talked about doing that. | 19:31 |
| efried | We can ask gibi to confirm | 19:31 |
| sean-k-mooney | rn as in none? | 19:31 |
| efried | 'right now' | 19:31 |
| sean-k-mooney | oh i think its defaultin to none if it is | 19:31 |
| sean-k-mooney | that should be our default unless you say otherwise | 19:31 |
| sean-k-mooney | ok so it required becasuee we are using groups but the value is not relevent to the spec | 19:32 |
| sean-k-mooney | im fine with that | 19:32 |
| sean-k-mooney | its an implemenation detail | 19:32 |
| efried | yeah. That was a gripe I had during the nested magic design, that group_policy should default (can't remember which way I said) at this point because we can control everything we need using other, more granular (heh) mechanisms. | 19:33 |
| efried | but we didn't actually do that. | 19:33 |
| efried | And, confirmed, we're defaulting to 'none' these days. | 19:33 |
| efried | I found the reno yaml, lemme find where it is in the docs. | 19:33 |
| sean-k-mooney | well really we should not have it be global either | 19:34 |
| sean-k-mooney | it should be per set of groups or per subtreee or something | 19:34 |
| efried | https://docs.openstack.org/releasenotes/nova/train.html#other-notes | 19:34 |
| sean-k-mooney | anyway out of scope | 19:34 |
| efried | right, that was my gripe. We now have same_subtree to dictate which can be shared and which can be spread. Because same_subtree also devolves to same rp in relevant cases. | 19:35 |
| sean-k-mooney | ya | 19:35 |
| sean-k-mooney | provide we model nics with an RP per PF same_subtree or the negation should hanel that too | 19:36 |
| sean-k-mooney | so we might be able to remvoe the group polices thing at some point | 19:36 |
| sean-k-mooney | anyway if this does not require it to make it work it makes me happy | 19:37 |
| *** eharney has joined #openstack-nova | 19:39 | |
| sean-k-mooney | i have saved a copy of that etherpad locally just in case by the way. | 19:40 |
| efried | cool. I've got my comment all composed, will post it when I'm done reviewing the rest. Hopefully bauzas will parlay the etherpad into the doc before the etherpad goes kablooey, as it inevitably will. | 19:41 |
| sean-k-mooney | well we nerver delete them | 19:41 |
| sean-k-mooney | the only go away if the db gets currpted | 19:41 |
| sean-k-mooney | so you would be suprised how long they survie | 19:42 |
| sean-k-mooney | that said we have been bitten enough times at ptgs that i make backups | 19:42 |
| efried | I've seen enough corrupted | 19:42 |
| efried | yeah. | 19:42 |
| *** eharney has quit IRC | 19:48 | |
| *** dklyle has quit IRC | 19:56 | |
| *** gmann is now known as gmann_afk | 19:57 | |
| *** lifeless has joined #openstack-nova | 20:01 | |
| *** dklyle has joined #openstack-nova | 20:03 | |
| *** dklyle has quit IRC | 20:08 | |
| *** dklyle has joined #openstack-nova | 20:14 | |
| artom | dansmith, around? So, are you completely opposed to https://review.opendev.org/#/c/672595/61/nova/tests/unit/virt/libvirt/fakelibvirt.py@489 ? | 20:15 |
| artom | Because I've been trying to write something better, and I'm not sure what I have is worth it. Maybe I just suck, or am overthinking it? | 20:16 |
| dansmith | Why is [1] harder than 1? Aside from all the test change | 20:16 |
| dansmith | or maybe you're stuck on the fact that it really should be named cpu_socket_map or something? | 20:17 |
| dansmith | I do think what you have is pretty ugly and would prefer a mutually exclusive additional arg to what you have It hink | 20:17 |
| artom | dansmith, well, the way I have it now is a full-on separate class | 20:17 |
| artom | Well, classes, because it trickles up and down | 20:18 |
| artom | Now = locally, not pushed yet | 20:18 |
| dansmith | and that's really just for tests? | 20:18 |
| artom | The objective being, allow tests that don't need the sockets maps complexity to use the existing class, and have a new one for the tests that need it | 20:19 |
| artom | Instead of imposing sockets map on all tests | 20:19 |
| *** LiangFang has quit IRC | 20:19 | |
| artom | You mean the HostInfo and NUMATopology classes? Yeah, just for tests | 20:20 |
| dansmith | Right, point is you've created a new class to wrap hostinfo just for tests | 20:20 |
| dansmith | seems kinda smelly since they're not doing what the production code does | 20:20 |
| dansmith | at least make that a fixture or utility thing in tests/ | 20:20 |
| artom | HostInfo already exists just for tests | 20:21 |
| *** slaweq has quit IRC | 20:22 | |
| dansmith | ohhh, sorry I maybe was thinking too fast.. doesn't it mirror something else in the main code? | 20:22 |
| * dansmith notes it has been 12 days and a week of vacay since he last looked at this | 20:23 | |
| *** slaweq has joined #openstack-nova | 20:23 | |
| artom | dansmith, no worries - I've been struggling with this for way too much time, too | 20:24 |
| artom | dansmith, so, the HostInfo is eventually passed down to the fake_connection here: https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/base.py#L111 | 20:25 |
| artom | dansmith, it's essentially our libvirt service stub | 20:25 |
| dansmith | it doesn't inherit from something real, so ignore my previous comments | 20:25 |
| dansmith | a wrapper class for ease makes perfect sense I think | 20:25 |
| dansmith | yup I'm caught up now | 20:25 |
| artom | Ohhhh | 20:27 |
| artom | I think I just got it | 20:27 |
| artom | Make the "internal machinery" use sockets map | 20:27 |
| artom | And leave HostInfo on top as a compatibility shim | 20:27 |
| artom | And for tests that need it, they can use the "internal machinery" class directly | 20:28 |
| dansmith | yeah, i thought that was what you were suggesting | 20:32 |
| artom | No, I had 2 classes in parallel | 20:32 |
| *** jmlowe has joined #openstack-nova | 20:43 | |
| *** jawad_axd has joined #openstack-nova | 20:52 | |
| *** jmlowe has quit IRC | 20:52 | |
| *** slaweq has quit IRC | 20:54 | |
| *** jmlowe has joined #openstack-nova | 20:54 | |
| *** jawad_axd has quit IRC | 20:56 | |
| *** jmlowe has quit IRC | 20:57 | |
| *** lucidguy has quit IRC | 20:59 | |
| *** eharney has joined #openstack-nova | 21:03 | |
| *** slaweq has joined #openstack-nova | 21:04 | |
| *** jmlowe has joined #openstack-nova | 21:04 | |
| *** IvensZambrano has joined #openstack-nova | 21:05 | |
| *** jmlowe has quit IRC | 21:05 | |
| *** jmlowe has joined #openstack-nova | 21:07 | |
| *** artom has quit IRC | 21:08 | |
| *** slaweq has quit IRC | 21:09 | |
| *** jmlowe has quit IRC | 21:09 | |
| *** slaweq has joined #openstack-nova | 21:11 | |
| *** slaweq has quit IRC | 21:16 | |
| *** gmann_afk is now known as gmann | 21:17 | |
| *** jmlowe has joined #openstack-nova | 21:24 | |
| efried | bauzas, sean-k-mooney, stephenfin: Finished that review of the numa topo spec. | 21:24 |
| *** jmlowe has quit IRC | 21:25 | |
| *** jmlowe has joined #openstack-nova | 21:31 | |
| *** rcernin has joined #openstack-nova | 21:32 | |
| sean-k-mooney | efried: cool i will try to catch up with the review tommorow | 21:34 |
| *** jmlowe has quit IRC | 21:37 | |
| *** xek_ has quit IRC | 21:42 | |
| *** jmlowe has joined #openstack-nova | 21:45 | |
| *** jmlowe has quit IRC | 21:46 | |
| *** nweinber has quit IRC | 21:58 | |
| *** ociuhandu has joined #openstack-nova | 22:01 | |
| *** jmlowe has joined #openstack-nova | 22:06 | |
| *** ociuhandu has quit IRC | 22:06 | |
| *** tosky has joined #openstack-nova | 22:10 | |
| *** artom has joined #openstack-nova | 22:19 | |
| *** mriedem has left #openstack-nova | 22:35 | |
| *** damien_r has quit IRC | 22:54 | |
| *** kaisers has quit IRC | 23:06 | |
| *** tkajinam has joined #openstack-nova | 23:07 | |
| *** shilpasd has quit IRC | 23:10 | |
| *** TxGirlGeek has quit IRC | 23:11 | |
| *** slaweq has joined #openstack-nova | 23:11 | |
| *** mlavalle has quit IRC | 23:14 | |
| *** spatel has joined #openstack-nova | 23:14 | |
| *** slaweq has quit IRC | 23:16 | |
| *** TxGirlGeek has joined #openstack-nova | 23:19 | |
| *** spatel has quit IRC | 23:19 | |
| *** damien_r has joined #openstack-nova | 23:20 | |
| *** IvensZambrano has quit IRC | 23:21 | |
| *** kaisers has joined #openstack-nova | 23:23 | |
| *** jmlowe has quit IRC | 23:38 | |
| *** jmlowe has joined #openstack-nova | 23:43 | |
| *** tosky has quit IRC | 23:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!