| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-11 | |||
| 09:11:23 | bauzas | the spec needs another round of rewrites so I'm starting it now | |
| 09:12:40 | openstackgerrit | HYSong proposed openstack/nova master: Update request_specs.availability_zone during live migration https://review.opendev.org/706647 | |
| 09:12:52 | gibi | bauzas: I'm still reading efried's comments, I will get back to you soon | |
| 09:13:05 | bauzas | cool | |
| 09:28:50 | openstackgerrit | HYSong proposed openstack/nova master: Update request_specs.availability_zone during live migration https://review.opendev.org/706647 | |
| 09:33:53 | openstackgerrit | HYSong proposed openstack/nova master: Update request_specs.availability_zone during live migration https://review.opendev.org/706647 | |
| 09:35:44 | openstackgerrit | HYSong proposed openstack/nova master: Update request_specs.availability_zone during live migration https://review.opendev.org/706647 | |
| 09:44:50 | bauzas | gibi: unrelated, see my last comment on https://review.opendev.org/#/c/706647/5 | |
| 09:45:45 | bauzas | I know not a lot of folks know about AZs, so I want to make sure that all of us as cores know about the design consensus :) | |
| 09:45:47 | gibi | bauzas: ack, queued for double check | |
| 09:47:21 | bauzas | no rush, it's more for a knowledge | |
| 09:53:21 | gibi | bauzas: replyied in the NUMA spec. I agree Eric's proposals in his reply. I'm still a bit open in the upgrade check case but that is a low prio issue | |
| 09:53:38 | bauzas | cool, I'm just modifying things as we speak | |
| 09:54:07 | gibi | bauzas: you did a great job pulling the piece together I think I see the light of the end of this tunnel | |
| 10:02:11 | openstackgerrit | jichenjc proposed openstack/nova master: set default value to 0 instead of '' https://review.opendev.org/706730 | |
| 10:04:17 | gibi | bauzas: https://review.opendev.org/#/c/706647 thanks for chiming in I agree with you. I missed the fact that we don't allow moving instance between AZs (in recent microversions) | |
| 10:06:24 | bauzas | gibi: no worries, again, my ping is just for making sure we share our knowledge | |
| 10:06:45 | bauzas | I'm always on and off upstream, so the more people know about AZs, the better it will be | |
| 10:42:58 | bauzas | shit, I lack time for fixing all the comments | |
| 10:45:05 | bauzas | gibi: I think we need efried and sean-k-mooney around this afternoon for discussing the upgrade pre-flight check and the Ussuri condition | |
| 10:45:37 | bauzas | I'm personnally in favor of keeping NUMA workloads in Ussuri as they are | |
| 10:46:06 | bauzas | ie. no migration asked | |
| 10:46:16 | bauzas | and a pre-flight check pre-Victoria | |
| 10:46:35 | bauzas | because if not, that's a chicken-and-egg issue | |
| 10:50:44 | gibi | sure lets see what they think | |
| 12:14:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | |
| 12:24:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support unshelve with qos ports https://review.opendev.org/704759 | |
| 12:25:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable unshelve with qos ports https://review.opendev.org/705475 | |
| 12:27:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Merge qos related renos for Ussuri https://review.opendev.org/706766 | |
| 12:36:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | |
| 12:38:24 | frickler | hello nova, the new alembic==1.4.0 is causing this failure, please have a look https://c264ca14759376f2bea5-6cd49316b9babb1f90743cae9cd67f9e.ssl.cf2.rackcdn.com/705380/10/check/cross-nova-py36/8bcec81/testr_results.html , I'll pin to the previous version for now, see https://review.opendev.org/705380 | |
| 13:14:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: api: Add support for extra spec validation https://review.opendev.org/704643 | |
| 13:23:18 | efried | What's the question? | |
| 13:23:18 | efried | bauzas, gibi: o/ | |
| 13:25:19 | gibi | efried: my remaning open question is https://review.opendev.org/#/c/552924/16/specs/ussuri/approved/numa-topology-with-rps.rst@223 about upgrade checks | |
| 13:25:49 | gibi | but I have to jump on a call for the next 1 and a half hour so talk to you later | |
| 13:36:09 | bauzas | efried: gibi: will ping you later, just updating the spec now | |
| 13:47:27 | alex_xu | bauzas: I leave one also https://review.opendev.org/#/c/552924/16/specs/ussuri/approved/numa-topology-with-rps.rst@421 | |
| 13:50:35 | bauzas | ack | |
| 13:52:31 | bauzas | alex_xu: good point, I was thinking of the upgrade issue when rolling the compute upgrades | |
| 13:53:23 | alex_xu | good news, we can just copy the way of standard-cpu-resource-tracking way | |
| 13:53:55 | alex_xu | probably need another workaround config option for disable the fallback placement query | |
| 13:53:57 | bauzas | I'll sat this | |
| 13:54:06 | bauzas | say* | |
| 14:39:16 | efried | bauzas, gibi: responded. | |
| 14:39:33 | bauzas | dammit, need to Ctrl-R | |
| 14:39:46 | bauzas | I'm litterally writing live | |
| 14:40:00 | efried | bauzas: shouldn't be anything earth-shattering in my response. | |
| 14:40:01 | bauzas | eek, sean-k-mooney did too | |
| 14:42:20 | bauzas | efried: for the placement-ish syntax, I'm all for docs | |
| 14:42:26 | bauzas | and not code | |
| 14:42:27 | bauzas | FWIW | |
| 14:42:36 | bauzas | like, you can do it but you can mess it | |
| 14:42:39 | bauzas | your dog | |
| 14:43:10 | bauzas | anyway, continuing to write | |
| 14:43:49 | efried | IMO the only reason we shouldn't block placement-ish syntax is because we might miss something in our translation utility and have to provide a workaround until we fix it. | |
| 14:44:11 | efried | even there be tygers. | |
| 14:45:20 | LiangFang | gibi: hi gibi, regarding https://review.opendev.org/#/c/689070/ | |
| 14:47:01 | LiangFang | gibi: how do you think to set trait for the host machine, and specify trait in flavor extra spec? | |
| 14:47:59 | LiangFang | gibi: so the guest can be scheduled to the host with cache capability | |
| 15:22:12 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924 | |
| 15:22:38 | bauzas | efried: gibi: sean-k-mooney: alex_xu: thanks for the comments, here is another baking of NUMA topology spec https://review.opendev.org/552924 | |
| 15:23:18 | gibi | LiangFang: if we only care about having a cache configured on the host then it can be a capability represented by a trait. If we also needs to think about the available size of the caches then it is a resource | |
| 15:24:15 | gibi | bauzas, efried: ack, will check back soon | |
| 15:39:49 | stephenfin | dansmith: Any particular reason we don't use entrypoints for custom scheduler filters? Is it something we could/should do? | |
| 15:40:05 | dansmith | don't we already? | |
| 15:40:09 | dansmith | bauzas: | |
| 15:40:27 | stephenfin | Custom scheduler drivers, yes. Not filters for the filter_scheduler though | |
| 15:40:44 | dansmith | I was sure we did | |
| 15:40:53 | stephenfin | You've to configure them via a python path in '[filter_scheduler] enabled_filters' | |
| 15:40:55 | stephenfin | fwict | |
| 16:02:28 | spatel | sean-k-mooney: morning | |
| 16:02:42 | spatel | let me know if you around i want to share my load-test result. | |
| 16:06:31 | gibi | bauzas: thanks for the update on the NUMA spec it looks good to me now | |
| 16:24:39 | sean-k-mooney | bauzas: im skiming through it now but ya im more or less happy with it. ill proably +1 it when i finish this pass | |
| 16:26:55 | bauzas | dansmith: sorry was AFK | |
| 16:27:35 | bauzas | stephenfin: yeah you have to set a specific option | |
| 16:27:38 | dansmith | bauzas: np. I thought our scheduler filter interface was already using entry points, but stephenfin says it's not.. I'm sure he's right I was just poking you in case you were also surprised | |
| 16:28:10 | bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.available_filters | |
| 16:28:15 | bauzas | stephenfin: ^ | |
| 16:28:25 | stephenfin | right, matches up with what I suspected so | |
| 16:28:44 | stephenfin | bauzas: any reason not to deprecate that an ask people to use entrypoints instead? | |
| 16:28:53 | stephenfin | given I'll be asking them to do that for extra spec validators | |
| 16:29:12 | bauzas | well, I don't have any opinion | |
| 16:29:25 | bauzas | we had a lot of entrypoints | |
| 16:29:37 | bauzas | so for sure we could just use another one | |
| 16:30:19 | sean-k-mooney | spatel: did you see an improvement? | |
| 16:32:06 | bauzas | stephenfin: dansmith: that's how Nova knows about filters https://github.com/openstack/nova/blob/master/nova/loadables.py#L78 | |
| 16:33:56 | bauzas | for example you can ask to have a new custom filter by doing something like scheduler_available_filters = myownproject.scheduler.filters.climate_filter.ClimateFilter | |
| 16:35:40 | efried | bauzas, gibi, sean-k-mooney: I don't understand the "fallback" thing. | |
| 16:36:14 | efried | https://review.opendev.org/#/c/552924/17/specs/ussuri/approved/numa-topology-with-rps.rst@516 | |
| 16:36:40 | sean-k-mooney | efried: its mimicing PCPUS | |
| 16:37:57 | sean-k-mooney | basically when procesing a vm request with a numa toplogy if and only if the placement allocation candiates responce is empty we will fall back to the non numa aware query and let the numa toplogy filter elimidate the host if it cant fit | |
| 16:38:14 | bauzas | efried: try: <call placement asking for NUMA-aware instances> except NoValidHosts: <call Placement like in Train> | |
| 16:38:43 | sean-k-mooney | yes but without using excption for control flow :P | |
| 16:38:52 | efried | Sorry, let me clarify | |
| 16:39:03 | bauzas | efried: sean-k-mooney: I could have provided a link to the implementation instead of the spec :) | |
| 16:39:04 | efried | I understand the what/how. I don't understand the why. | |
| 16:39:14 | bauzas | efried: because, | |
| 16:39:24 | bauzas | say a rolling upgrade | |