Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-29
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 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:19 sean-k-mooney well im going to be out voted so i guess yes
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 so we don't have two different ways to represent a rule
15:11:38 stephenfin https://review.opendev.org/#/c/704643/2/nova/api/validation/extra_specs/hw.py
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
15:11:49 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?

Earlier   Later