Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-28
12:01:10 HagunKim gibi: Thanks for your reply. But I found nothing with request_id. I will change log level to debug and see it again.
12:05:18 gibi not even in other nova services like nova api?
12:15:42 bauzas HagunKim: just use the os-instance-actions API
12:16:31 bauzas HagunKim: https://docs.openstack.org/api-ref/compute/#servers-actions-servers-os-instance-actions
12:19:07 HagunKim bauzas: Can I use that api for removed instances?
12:19:22 bauzas "Action information of deleted instances can be returned for requests starting with microversion 2.21."
12:19:26 bauzas :)
12:20:07 bauzas then you'll get the req-ids
12:20:24 bauzas so you can either ask again the same API for a specific req-id or just look at logs
12:20:47 HagunKim Oh I will check. Thank you!
12:33:40 stephenfin yo, sean-k-mooney, you probably want to weigh in on https://review.opendev.org/668656 since I _think_ you're of the same mindset as me RE: not forcing people to use placement constructs in nova land
12:34:15 sean-k-mooney i have in the irc discussions and yes
12:35:12 sean-k-mooney i would be oke with the placement syntax but only if we remove support for placement groups syntax form the flavor and stop doing a direct passthough to the api query effectivly
12:36:00 sean-k-mooney e.g. resouce:* would be ok if and only if we have a layer that parses that and then generate a different query based on the other extraspecs but i prefer the hw:* syntax
12:36:08 openstackgerrit Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247
12:40:23 stephenfin my arguments slightly different to that. I'm okay with the placement syntax but I don't want it mixed with the legacy stuff. It's too confusing to reason about
12:43:46 alex_xu sean-k-mooney: stephenfin, if we are going to the vision about placement syntax in the future, will it be hard to deprecated those extra specs we added?
12:45:42 alex_xu I'm just thinking, it is vision, agreed by some people, but it is vision, we don't know when it happend, but people afarid we add more stuff which aren't existing in that vision. just thinking of if we have road to transfer to that vision, then we continue add extra specs, then it won't be a problem
12:47:18 sean-k-mooney alex_xu: i guess the only way i can see moving to placement syntax workin is if we remove the group syntax form the flavor
12:47:42 sean-k-mooney so i for won dont ever see use moving to placemnt syntax unless that happens
12:48:26 sean-k-mooney if the resouces:* requests are coupled to the placemetn toplogy directly that is an upgrade issue
12:49:01 sean-k-mooney that said with an indirection laywer between the placment query and the flavor it would be managable
12:49:11 alex_xu I see
12:49:46 sean-k-mooney but to your question i dont think doing hw:* is a blocker to doing resouces:* in the future
12:50:23 alex_xu but at that time, we need to deprecated some extra sepcs like 'hw:cpu_policy', any problem we deprecated one more more extra spec for 'hw:dedicated_cpu_set'(I forget the name)?
12:50:43 sean-k-mooney we can support that for cpu pinning today but i would continue to recommend using hw:cpu_policy=dedicated over resocues:PCPU=x
12:50:44 alex_xu yea, that is what i'm thinking
12:51:34 alex_xu huaqiang: efried dansmith stephenfin ^
12:51:41 sean-k-mooney ya we would have to deprecate both toghter but 1 vs 2 extra specs is not really a big differece
12:51:45 alex_xu it is time pull everybody togetther again :)
12:52:15 sean-k-mooney we would still have to do an online data migration to update the embeded flavor or force the operator to resize every vm in either case
12:53:02 sean-k-mooney that is when we remove support for hw:cpu_policy if we ever do
12:53:12 alex_xu ah, resize, that is terrible
12:53:48 sean-k-mooney ya its the only way to update the embeded flavor today
12:54:23 sean-k-mooney which is why i dont like the idea of useing the placement syntax direcly as it is copled to the placement toplogy and if that chagne we need to either do a resize or an online data migration
12:55:13 alex_xu yea, i see
12:56:01 sean-k-mooney given we want to move pcpus under numa nodes in the next release or two i worry about relying on the placment syntax currently as that will be a toplogy change
12:58:59 alex_xu and we don't know it will happen in next release
13:00:11 sean-k-mooney ya we dont bauzas has reporposed it for this release https://review.opendev.org/#/c/552924/ but we have not really been reviewing it this cycle
13:01:13 sean-k-mooney so i think its unlikly to happen until next cycle at the earliest
13:04:11 openstackgerrit Kobi Samoray proposed openstack/nova master: Support large network queries towards neutron https://review.opendev.org/704520
13:13:05 openstackgerrit Kobi Samoray proposed openstack/nova master: Support large network queries towards neutron https://review.opendev.org/704520
13:13:19 openstackgerrit Kobi Samoray proposed openstack/nova master: Support large network queries towards neutron https://review.opendev.org/704520
13:31:03 openstackgerrit Vladyslav Drok proposed openstack/nova master: Make RBD imagebackend flatten method idempotent https://review.opendev.org/704330
13:32:37 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176
13:36:15 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176
13:40:33 bauzas sean-k-mooney: alex_xu: comments are welcome on the spec
13:40:46 bauzas and I can provide a new revision given gibi's comments
13:41:02 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Faults from cell DB missing in GET /servers/detail https://review.opendev.org/699176
14:08:05 sean-k-mooney bauzas: you spec mainly look at the queries sent to placement not how that is expressed in the flavor but i have conserns with how resouce request are represent in the flavor and i dont really think you should proceed untill hugepage/mempages are supported
14:08:33 sean-k-mooney im somewhat flexible on the last point but im not a fan of moving memory_mb to the numa node as it stands
14:17:22 bauzas sean-k-mooney: yeah I need to think about the group_policy issue
14:23:41 sean-k-mooney its not just group_policy although that is a major issue i dont think the group syntax shoudl be used in the flavor at all
14:24:18 sean-k-mooney using it between nova and placment im more ok with
14:24:19 bauzas sean-k-mooney: in the spec, I say that we should hide the placement queries
14:24:32 bauzas that's the consensus said so far at least
14:26:54 sean-k-mooney yes that is a saving grace of the current proposal in that it is advocatign for doing translation form the existing extra specs
14:27:16 sean-k-mooney that said its in conflict with the mix pinned and unpind cpus in one instnace work
14:55:30 efried stephenfin: whoops, we crossed in the mail, let me go back and respond to your comments before you respin please...
15:09:23 efried stephenfin: done
15:09:36 efried I don't think anything changed :)
16:14:19 Sundar Hello dansmith
16:15:14 dansmith Sundar: hi, I'm on a call right now
17:49:44 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643
17:49:49 stephenfin efried: ^
17:50:23 efried ack. You removing the prototype stuff from the spec?
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 IMO that's going to inform whether we set things up for strict validation out of the gate.
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 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).
#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] Assign instance dedicated CPU set through `cpu_pinning` field https://review.opendev.org/688933
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: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:57 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] Introduce a new instance CPU allocation policy: mixed https://review.opendev.org/688934
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
04:57:58 openstackgerrit Huachang Wang proposed openstack/nova master: [WIP] Create 'mixed' instance from PCPU and VCPU resources https://review.opendev.org/696009
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

Earlier   Later