Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-29
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
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?
15:12:00 stephenfin sean-k-mooney: yup, that
15:12:11 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:17 dansmith so, this brings the policy problem screaming back from hell?
15:12:38 stephenfin oslo.policy?
15:12:44 sean-k-mooney dansmith: no that was brogh back for a different reason
15:12:48 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:13:12 stephenfin that was another concern of mine, but I figured we'd just load multiple files

Earlier   Later