| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-29 | |||
| 09:38:43 | stephenfin | o/ | |
| 09:43:16 | gibi | \o | |
| 09:45:45 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate https://review.opendev.org/695220 | |
| 09:48:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support unshelve with qos ports https://review.opendev.org/704759 | |
| 10:05:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/662522 | |
| 10:25:25 | 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:30 | stephenfin | https://review.opendev.org/#/c/666032/ | |
| 10:25:40 | bauzas | stephenfin: sure | |
| 10:25:56 | bauzas | btw. thanks stephenfin and gibi for my multiple GPU types spec reapproval | |
| 10:26:03 | stephenfin | np. Made sense | |
| 10:26:28 | 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 | |
| 11:02:26 | sean-k-mooney | bauzas: im conserned about that spec too and the interaction with mix cpus | |
| 11:03:51 | sean-k-mooney | bauzas: can we have a call or something to work on this together | |
| 11:04:54 | 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:08:08 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | |
| 11:15:41 | 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:17:15 | bauzas | sean-k-mooney: ack, will do later in the afternoon | |
| 11:17:21 | bauzas | and thanks for the reviews | |
| 11:24:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | |
| 11:29:58 | gibi | stephenfin: looking | |
| 11:38:20 | gibi | stephenfin: +A | |
| 11:39:36 | stephenfin | gibi: ta | |
| 11:43:39 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655 | |
| 11:49:34 | openstackgerrit | Merged openstack/nova-specs master: Additional upgrade clarifications for cpu-resources https://review.opendev.org/666032 | |
| 11:50:19 | 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:50 | gibi | sure I added to my queue | |
| 11:50:56 | stephenfin | thanks | |
| 12:26:06 | 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:27:07 | huaqiang | I want to comfirm that you prefer the PCPU mask approach that we have dropped, right? | |
| 13:04:11 | 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:12:06 | huaqiang | stephenfin: thanks. It's pretty close to the freeze of spec, I planed to work but not work fully these days. | |
| 13:13:14 | huaqiang | I'll keep my eye on the update of gerrit and irc. | |
| 14:37:14 | openstackgerrit | Lenny Verkhovsky proposed openstack/os-vif master: WIP: Testing CI https://review.opendev.org/686937 | |
| 14:55:59 | 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:56:12 | gibi | stephenfin: ack, looking | |
| 14:56:37 | sean-k-mooney | stephenfin: im reviewing you poc code at the moment | |
| 14:56:43 | sean-k-mooney | almost done | |
| 14:58:26 | 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:59:31 | 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:49 | sean-k-mooney | maybe just strict|off based on stephens last comment | |
| 15:00:00 | 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:57 | 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:01:35 | 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:02:14 | efried | nova.conf is ini style | |
| 15:02:30 | stephenfin | but not the definitions for those config options | |
| 15:02:31 | efried | conceived, if I'm not mistaken, before yaml was sexy. | |
| 15:02:57 | efried | It would be possible to do these validators ini-style and use oslo.conf | |
| 15:03: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:26 | stephenfin | eeew, I'm not writing that much JSON | |
| 15:03:41 | efried | Yeah, definitely don't want the files to be json. yaml exists because json is ugly. | |
| 15:03:51 | stephenfin | also, I think I did look at that and it didn't offer everything we'd need | |
| 15:04:00 | sean-k-mooney | but we are needless reinventing the wheel here | |
| 15:04:08 | 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:20 | stephenfin | But glance's stuff wasn't invented here, Sean. | |
| 15:04:27 | stephenfin | :P | |
| 15:04:29 | 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:31 | bauzas | honestly, what's the problem with stevedore ? | |
| 15:04:38 | 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:40 | bauzas | nova was built around it | |
| 15:04:48 | bauzas | plugins FTW | |
| 15:04:55 | sean-k-mooney | we could pull the galnce sutff into a lib and share it | |
| 15:05:01 | efried | bauzas: to me, just unnecessary complexity and an additional thing we don't need. | |
| 15:05:10 | sean-k-mooney | if we go file based only i think that is what we shoudl do | |
| 15:05:25 | bauzas | efried: entrypoints are complex to manage ? | |
| 15:05:44 | bauzas | honestly, we haven't heard about this since nova exists | |
| 15:05:59 | efried | entrypoints plus python code plus packaging, versus putting a yaml file in a directory? Hell yes. | |
| 15:06:01 | sean-k-mooney | bauzas: there is one complexity with them form a packaging point of view | |
| 15:06:14 | stephenfin | sean-k-mooney: so we'd be using a package to distribute a YAML file? | |
| 15:06:35 | efried | ugh, no, please. | |
| 15:06:38 | bauzas | it's config | |
| 15:06:39 | efried | Can we not boil the ocean? | |
| 15:06:40 | sean-k-mooney | json file and the code to do all the validation which they have laready written as far as i knwo | |
| 15:07:15 | stephenfin | I'd personally rather strip the flavor stuff out of glance | |
| 15:07:24 | stephenfin | Why do they need to care about flavors? They're an image service | |
| 15:07:53 | efried | how did glance get involved here? | |
| 15:07:55 | 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:08:05 | bauzas | I thought the spec was simple enough to just re-accept it | |
| 15:08:09 | efried | (rhetorical question; can we stay on topic?) | |
| 15:08:12 | bauzas | given it was accepted beofre | |
| 15:08:29 | bauzas | but now, looks like we rathole around any possible better way to provide config | |
| 15:09:09 | 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:28 | 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:30 | bauzas | that's exactly why we chose plugins before | |
| 15:09:38 | bauzas | but... whatever | |
| 15:09:54 | bauzas | looks like we have consensus around YAML | |
| 15:10:14 | 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:19 | sean-k-mooney | well im going to be out voted so i guess yes | |
| 15:10:19 | 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:35 | dansmith | yaml for what? rules of extra spec validation? | |
| 15:10:43 | stephenfin | yup | |
| 15:10:50 | dansmith | and... why? | |
| 15:10:53 | gibi | I think having a simple api microversion to opt in is enough | |
| 15:11:01 | dansmith | because we can share that file between us and glance? | |
| 15:11:05 | efried | no | |
| 15:11:22 | efried | so we can accommodate extra specs nova doesn't own or know about | |
| 15:11:31 | gibi | dansmith: because we need the yaml for deployer defined extra specs anyhow | |
| 15:11:38 | stephenfin | https://review.opendev.org/#/c/704643/2/nova/api/validation/extra_specs/hw.py | |
| 15:11:38 | stephenfin | so we don't have two different ways to represent a rule | |
| 15:11:41 | bauzas | honestly, I was preferring the python approach thru stevedore plugins | |
| 15:11:45 | stephenfin | we want to provide a way for operators to specify their own custom extra specs for out of tree filters, or whatever | |