Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-28
17:50:32 stephenfin efried: Assuming you're not against the general idea I have in that spec, it might be worth skimming that patch to see if it addresses your concerns (note the TODOs to do microversion stuff)
17:50:53 stephenfin and if it looks good, I'll remove the prototype stuff and make it more handwavey :)
17:51:11 stephenfin well, I'll remove that anyway but the handwavey stuff will reflect what I'm going to actually do
17:51:19 efried cool
20:33:48 openstackgerrit Vladyslav Drok proposed openstack/nova master: Minor improvements to cell commands https://review.opendev.org/698053
21:30:25 openstackgerrit melanie witt proposed openstack/nova master: Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate https://review.opendev.org/695220
22:34:45 efried stephenfin: The prototype code looks fine to me philosophically (I didn't leave any comments yet, though there are several things I noticed) but it really only answers one of the more minor issues (the non-splitting-out of namespace vs extra spec validators).
22:34:45 efried I think we're in agreement on most of the other pieces, but I'd like to close on the discussion of whether there will be something beyond microversion to enable/disable the validation; and if so, whether that thing can be made granular to the point of selecting whether to reject unknown keys.
22:34:45 efried IMO that's going to inform whether we set things up for strict validation out of the gate.
#openstack-nova - 2020-01-29
03:52:44 openstackgerrit Merged openstack/nova master: Handle cell failures in get_compute_nodes_by_host_or_node https://review.opendev.org/700186
03:52:52 openstackgerrit Merged openstack/nova master: doc: define boot from volume in the glossary https://review.opendev.org/699009
04:57:55 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:56 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:56 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] Assign instance dedicated CPU set through `cpu_pinning` field https://review.opendev.org/688933
04:57:57 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] Introduce a new instance CPU allocation policy: mixed https://review.opendev.org/688934
04:57: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:58 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] Create 'mixed' instance from PCPU and VCPU resources https://review.opendev.org/696009
04:57:58 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
09:31:40 bauzas good morning Nova
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

Earlier   Later