| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | 00:07 |
|---|---|---|
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: address minor issues pointed out in the review https://review.opendev.org/c/openstack/nova/+/983278 | 00:07 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | 00:07 |
| opendevreview | Merged openstack/nova stable/2024.2: Fix bug 2114951 https://review.opendev.org/c/openstack/nova/+/959526 | 00:48 |
| *** ykarel_ is now known as ykarel | 04:11 | |
| opendevreview | Esra Ozkan proposed openstack/nova master: Check volume status before live migration https://review.opendev.org/c/openstack/nova/+/973750 | 05:49 |
| gibi | melwitt: re DB: thanks. I will dig forward to understand how we approach parallelism regarding DB interactions. dansmith had valid questions about the problem we see in the func test env (the transaction within transaction issue) if it affects production code as well or not. | 06:39 |
| gibi | melwitt: re vtpm job: Yeah reducing parallelism in the job make sense to me. Unfortunately the patch faild the vtpm job now with a live migration failure, so we still have something fishy there | 06:40 |
| gibi | I rechecked it to see if it is an intermittent network issue between the host during live migration or something deeper | 06:42 |
| opendevreview | ChungWon Lee proposed openstack/nova master: Add regression test for bug #2088066 https://review.opendev.org/c/openstack/nova/+/984900 | 06:48 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | 06:49 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | 06:52 |
| gibi | melwitt: dansmith: re DB parallelism: in parallel (sic) with my manual tracing I try to trigger the transaction within transaction issue in devstack with mysql in my rally fake virt job https://review.opendev.org/c/openstack/nova/+/960130 that has a lot bigger concurrency on conductor operations that the rest of our jobs due to having many (fake virt) computes and may VM boots in parallel. | 06:55 |
| gibi | last time I run that rally the conductor had no native thrading support but we can have result now with native conductor | 06:55 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Enable threading mode for proxy services https://review.opendev.org/c/openstack/nova/+/976089 | 07:13 |
| opendevreview | ChungWon Lee proposed openstack/nova master: Add regression test for bug #2088066 https://review.opendev.org/c/openstack/nova/+/984900 | 07:45 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Test nova CLI commands with native threading https://review.opendev.org/c/openstack/nova/+/984036 | 07:57 |
| opendevreview | ChungWon Lee proposed openstack/nova master: Add regression test for bug #2088066 https://review.opendev.org/c/openstack/nova/+/984900 | 09:31 |
| opendevreview | Ashish Gupta proposed openstack/nova master: Run functional test with threading mode https://review.opendev.org/c/openstack/nova/+/979850 | 10:26 |
| opendevreview | Ashish Gupta proposed openstack/nova master: Add native threading support to functional test (DB, RPC, test case ID) https://review.opendev.org/c/openstack/nova/+/980179 | 10:26 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Enable threading mode for proxy services https://review.opendev.org/c/openstack/nova/+/976089 | 11:14 |
| r-taketn | gibi: bauzas: Hello. Could you please check the remaining two sev refactor patches again? https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22 | 11:17 |
| bauzas | I'll today | 11:17 |
| r-taketn | bauzas: Thank you | 11:18 |
| r-taketn | Regarding the last patch, I've set it to WIP. I've also added it as an PTG item. I'd like to discuss the approach/direction. | 11:18 |
| gibi | r-taketn: looks good to me | 11:20 |
| r-taketn | gibi: Thank you for your quick review. | 11:23 |
| opendevreview | Stephen Finucane proposed openstack/nova master: tox: Remove override of install_command https://review.opendev.org/c/openstack/nova/+/984918 | 11:43 |
| stephenfin | gibi: sean-k-mooney: bauzas: Need to wait on CI, but I'd appreciate if we could get ^ in sooner rather than later. You can't currently run any tox commands in nova if tox-uv is installed (which is that case for me since I installed the python3-tox-uv package) | 11:46 |
| stephenfin | Coincidentally, tox-uv brings a nice little speed increase during package installation, particularly for things like nova with lots of dependencies | 11:46 |
| sean-k-mooney | i have one comment in the commit message that ill push shortly | 12:00 |
| sean-k-mooney | just testign your patch locally | 12:00 |
| gibi | melwitt: dansmith: with native threadig in conductor I does not see any threadpooling for DB. There are 64 RPC threads and couple of other threads, for RPC hearthbeat, cotyledon management, oslo looping call, and our own executor pools. If I configure all our pool to the smallest possible then the list of threads are easy to review https://paste.openstack.org/show/bmpzWGa9YXAjYF4SXxHS/ non of them | 12:20 |
| gibi | seems to be DB related. I will check this with eventlet as well | 12:20 |
| gibi | but I more or less assume that the DB transaction is running in the GreenThread that is used to receive the RPC request | 12:23 |
| gibi | sean-k-mooney: if you wondering why I'm writing the above then: dansmith asked the question if our overlapping transaction issue we see in the functional test effects the production code as well or not. | 12:24 |
| opendevreview | Bartosz Bezak proposed openstack/nova stable/2025.2: fix: device_by_alias should respect config type https://review.opendev.org/c/openstack/nova/+/984920 | 12:25 |
| opendevreview | Bartosz Bezak proposed openstack/nova stable/2025.1: fix: device_by_alias should respect config type https://review.opendev.org/c/openstack/nova/+/984921 | 12:25 |
| sean-k-mooney | gibi: so my understandign is there are mutlipel driver impleaiton in sqlachmey for mariadb | 12:28 |
| sean-k-mooney | and not all fo them use a conenction pool inthe same way | 12:28 |
| sean-k-mooney | so i dont know if that is expected or now with how devstack deploy by defualt | 12:28 |
| sean-k-mooney | gibi: maybe zeeck? can say quickly if we ping them | 12:29 |
| sean-k-mooney | but ya i dont know if that affect productio or not either we would have to dige deeper | 12:30 |
| gibi | I think connection pool and worker pool is different. We can have N connection object and not have any extra worker threads that doing the transaction with those connection objects | 12:31 |
| gibi | I printed the pool of the DB engine before we use QueuePool there in devstack for native threading. I can print it for eventlet too | 12:32 |
| gibi | yepp in eventlet mode it we also use a QueuePool for DB connectons | 12:44 |
| sean-k-mooney | right so conenction pooling shoudl jsut eb reusing tcp conntion not nessiarly requirign sperate threads | 12:44 |
| gibi | yepp | 12:45 |
| gibi | that is what I see | 12:45 |
| sean-k-mooney | yep i think that is the upsteam sqlachemy behvior for mysql | 12:45 |
| sean-k-mooney | so i dont think this is a regression in behvior | 12:46 |
| gibi | so when an RPC GreenThread executes a long transaction it either yields and then other GreenThreads can also start another transaction. Or it does not yield and then the no other RPC can run | 12:46 |
| sean-k-mooney | but when we use in memroy dbs with sqlight i think we are suign the NULLPOOL | 12:46 |
| gibi | yes, in functest we have some static pooling because the in memory DB needs a single connection to keep the DB aliave | 12:46 |
| gibi | so maybe the overlapping transaction happens across that single static connection | 12:47 |
| gibi | OK that is something I can try to trace | 12:47 |
| gibi | if there is one static connection for the in memory DB then that can be the point of the race. And I imagine that it is very different from the DB perspective if one connection starts a transaction within a transaction or two independent connection runs two independent but timewise overlapping transactions | 12:48 |
| gibi | dansmith: ^^ | 12:49 |
| gibi | sqlalchemy.pool.impl.StaticPool this is the pool in the functional test by default | 12:54 |
| gibi | https://github.com/sqlalchemy/sqlalchemy/blob/7dce9fec9d2071351d0c003a607955eca5dcf9ae/lib/sqlalchemy/pool/impl.py#L451 | 12:55 |
| sean-k-mooney | isnt that why oslo.db is overreidng | 12:57 |
| gibi | when the SQLite DB is in memory then we use StaticPool when we switch to file based (for the api DB) then that file based DB uses sqlalchemy.pool.impl.NullPool | 13:05 |
| gibi | this also points to that maybe the source of the race is the StaticPool | 13:05 |
| gibi | null pool basically always opens a new connection | 13:06 |
| gibi | so it cannot race | 13:06 |
| gibi | I'm not sure what oslo_db overrides in this regards | 13:06 |
| bauzas | stephenfin: silly question but I was thinking we were still supporting tox 2.x, am I wrong ? | 13:13 |
| bauzas | hmmm, OK, we were supporting 3.18 | 13:15 |
| stephenfin | bauzas: I assume you mean tox 3.x (2.x hasn't seen a release in nearly a decade). In any case, no. The only reason to have kept tox 3.x around was for Python 2.x support but that's not been an issue for some time | 13:15 |
| stephenfin | That and tempest, which is relying on the shared venv thing that doesn't work in tox 4.x (I've been working on fixing that in the background) but this doesn't affect nova itself | 13:16 |
| gibi | so I do see that with StaticPool we can basically checkout the same connection twice without returning the connection first. So two parallel entity can talk to the same tcp connection object. I guess in eventlet mode in the functional test our yield points was in places where such cross talk did not cause two transaction to overlap inside that single connection. And in production code we don't use | 13:19 |
| gibi | the StaticPool so we never checkout the same tcp connection twice so crosstalk cannot happen < dansmith my current answer to your question | 13:19 |
| bauzas | stephenfin: yeah sorry, typo there, I meant 3.x | 13:19 |
| opendevreview | Takashi Kajinami proposed openstack/os-vif master: Bump min version of pyroute2 https://review.opendev.org/c/openstack/os-vif/+/984934 | 13:19 |
| bauzas | stephenfin: but there is a CLI behavioural change with posargs when upgrading to 4.x, which is pretty impactful for our community, I'd appreciate more than just a file change | 13:20 |
| gibi | (and I have proof that this code is magic. it contains fairys: sqlalchemy.pool.base._ConnectionFairy) | 13:21 |
| gibi | we cannot switch to the null pool with in memory SQLite as the DB is freed as soon as the connection drops and nullpool drops it after use | 13:22 |
| gibi | we cannot really use QueuePool either as two connection cannot address the same in memory SQLite, that will be two different in memory DB for the two connection | 13:23 |
| gibi | so either we use StaticPool with one single never closed connection or we switch away from in memory DB | 13:24 |
| gibi | the former is racy in threading mode when two threads checks out the same connection object and crosstalk | 13:24 |
| stephenfin | bauzas: a CLI change? | 13:31 |
| bauzas | stephenfin: https://tox.wiki/en/4.6.4/upgrading.html isn't quite a short doc | 13:34 |
| bauzas | and my main concern is https://github.com/tox-dev/tox/issues/2183 | 13:35 |
| bauzas | s/<tox site>/ https://tox.wiki/en/4.28.0/upgrading.html / if we want to be clear | 13:38 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Test nova CLI commands with native threading https://review.opendev.org/c/openstack/nova/+/984036 | 13:38 |
| sean-k-mooney | bauzas: we are already likely using 4.28.0 | 13:41 |
| sean-k-mooney | we dont cap tox via upper-constraits | 13:41 |
| bauzas | if you just pip install tox, sure | 13:41 |
| sean-k-mooney | right which is what we do | 13:42 |
| bauzas | like myself | 13:42 |
| dansmith | sean-k-mooney: who is we? :) I don't pip install tox, I brew install it | 13:42 |
| sean-k-mooney | im talkign about the ci jobs | 13:42 |
| dansmith | gibi: sounds like this was an interesting diversion but that led to some understanding about why we're hitting this in tests only and that production should be good yeah? | 13:43 |
| sean-k-mooney | and as i noted in the reivew tox installs a seperve version of tox in a venv and uses htat if the min veriosn is above our current one | 13:43 |
| sean-k-mooney | s/our current one/ the one that is locally installed/ | 13:43 |
| bauzas | I'm doublechecking but I'm almost sure we have somewhere in our docs that says we should use tox 3.x | 13:44 |
| bauzas | of course that's a legacy doc with 4.x but if that's on the nova doc, I'd want to be consistent | 13:44 |
| bauzas | and again, the fact that we bump to 4.x is understandable but I just say we should say it way louder than just a file change to tox.ini | 13:45 |
| sean-k-mooney | devstack does seam to insall na older version but i dont think that is what our tox jobs do but ill doubel check | 13:45 |
| bauzas | thanks | 13:46 |
| sean-k-mooney | https://opendev.org/zuul/zuul-jobs/commit/bda76ac8bb30bb8d8c24552194038db0ff5e6255 | 13:46 |
| sean-k-mooney | ok so it was pinend but that was removed a year ago | 13:46 |
| sean-k-mooney | oh no 4 years ago https://opendev.org/zuul/zuul-jobs/commit/13925d1965aa5658304c9ca88fb0307d6cff2eff | 13:46 |
| bauzas | again, I'm not opposed to the change, I just want us to be careful and explaining about the bump (a reno would be nice) | 13:46 |
| sean-k-mooney | yep | 13:46 |
| sean-k-mooney | i agree on the release note | 13:46 |
| stephenfin | renos are for end-users/operators. This is developer-focused. I don't believe we should document this in release note | 13:47 |
| sean-k-mooney | https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/jobs.yaml#L24 | 13:47 |
| sean-k-mooney | stephenfin: it has an implciation for packageser | 13:47 |
| sean-k-mooney | so the other secion could be approrpate | 13:48 |
| stephenfin | how? | 13:48 |
| sean-k-mooney | i dont think it needs to be in upgrade | 13:48 |
| sean-k-mooney | stephenfin: well i guess it depend on how they run unit test but your probly right that it does not actully | 13:48 |
| sean-k-mooney | they are likely runing them directly | 13:48 |
| bauzas | yeah, that's for an other section IMHO | 13:49 |
| sean-k-mooney | sicne they woudl not want to use deps form pypi in the rpm/deb test execution | 13:49 |
| stephenfin | yeah, I'd be shocked if they were running tox rather than stestr directly (if I recall correctly, RDO spec files were still using os-testr for at least some projects) | 13:50 |
| sean-k-mooney | stephenfin: so you need tox 4.28.0 adn our ci is currently caped at 4.48 | 13:50 |
| sean-k-mooney | so we shoudl be testign with a version that suprot it today | 13:51 |
| stephenfin | so do I need a release note? I don't think it makes sense but if it'll help smooth the path to getting this in I can do so | 13:54 |
| dansmith | TBH, a reno for this seems odd to me | 13:56 |
| sean-k-mooney | im ok without one but im fine if other wnat it | 13:56 |
| sean-k-mooney | as you said its mainly a devleoper chnge so other is the only place that seam reasonable if we have one | 13:57 |
| bauzas | okay, then if no reno, we should then mention that in our contrib docs | 13:57 |
| dansmith | I don't see any other tox or unit test related stuff in our renos (from a dumb grep) | 13:57 |
| sean-k-mooney | i just removed my +2 to allow htat converstaion to happen without it there | 13:57 |
| dansmith | contributor docs makes a lot more sense | 13:57 |
| dansmith | we have development-environment.rst which talks about pip installing tox, so that seems like an appropriate place | 13:58 |
| bauzas | we have https://github.com/openstack/nova/blob/master/doc/source/contributor/development-environment.rst | 13:58 |
| bauzas | ah jinxed | 13:58 |
| bauzas | stephenfin: fancy amending this ? | 13:58 |
| sean-k-mooney | stephenfin: the actual thing i think would be more imporant to fix is figure out why devstack is capped to 3.x when our tox jobs are not. and get those in sync so that folks that use tox provdied by there devstack install have somethign less old... | 13:58 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Enable threading mode for proxy services https://review.opendev.org/c/openstack/nova/+/976089 | 13:59 |
| dansmith | sean-k-mooney: might have been for grenade or testing older distros at some point | 13:59 |
| stephenfin | sean-k-mooney: it's pinned for tempest. From my message earlier: | 13:59 |
| sean-k-mooney | dansmith: ya i suspect its from when we supproted jammy | 13:59 |
| stephenfin | 14:16 stephenfin That and tempest, which is relying on the shared venv thing that doesn't work in tox 4.x (I've been working on fixing that in the background) but this doesn't affect nova itself | 13:59 |
| sean-k-mooney | stephenfin: oh because of the venv thing? | 13:59 |
| sean-k-mooney | ok | 14:00 |
| stephenfin | yeah | 14:00 |
| dansmith | sean-k-mooney: I run 4.4 on jammy, but.. something earlier | 14:00 |
| stephenfin | but that (a) is huge tech debt we really need to fix and (b) doesn't affect nova's use of tox | 14:00 |
| sean-k-mooney | stephenfin: my new thoery is hte hardwrae where i sometimes(often) have the log setup time in tox is just cursed | 14:01 |
| gibi | dansmith: > led to some understanding about why we're hitting this in tests only and that production should be good yeah? | yeah I think I see now why this cannot happen in production | 14:02 |
| sean-k-mooney | nova full unit test sqiute shoudl not exectue in less time then buildign the venv to run it in... py3: OK (508.14=setup[284.11]+cmd[193.47,23.86,6.70] seconds) | 14:02 |
| dansmith | gibi: ack, well, sorry for the goose chase, but I feel better :) | 14:02 |
| stephenfin | bauzas: Can do. What will that look like? I'd rather not duplicate what's in tox.ini in our docs since they're liable to drift, so maybe I can just say you need at least tox 4.x available (since it'll bootstrap itself if it needs a newer version)? | 14:03 |
| gibi | dansmith: don't feel bad about it. Your question actually lead to a deeper understanding of the situation | 14:03 |
| stephenfin | s/will/should/ | 14:03 |
| bauzas | gibi: dansmith: I hadn't yet reviewed, but thanks for the discussion, I'll look at the patch | 14:03 |
| gibi | dansmith: the next similar area I want to understand more is the CellDatabases fixture that implements some weird routing of DB connections via hooking into the target_cell call | 14:04 |
| bauzas | stephenfin: there are two problems to solve here : 1/ documenting the fact that in Hibiscus, we bumped to 4.28.0 (should be easy addition to dev-env.rst), 2/ before merging the patch, making sure that we don't create devstack problems | 14:05 |
| dansmith | gibi: ack, there are some acrobatics in there for sure | 14:05 |
| stephenfin | (2) isn't an issue and will be confirmed by CI and the fact that other projects have already done see (e.g. ironic https://github.com/openstack/ironic/blob/master/tox.ini#L2) | 14:06 |
| stephenfin | I can also walk through how tempest is (wrongly) using tox and why it depends on tox 3.x, but my WIP patches probably explain it better | 14:07 |
| stephenfin | https://review.opendev.org/q/topic:%22rework-tempest-install%22+is:open | 14:08 |
| sean-k-mooney | ~/repos/nova-2$ tox -e py3 -r | 14:08 |
| sean-k-mooney | .tox create: /home/debian/repos/nova-2/.tox/.tox | 14:08 |
| sean-k-mooney | .tox installdeps: tox >= 4.28.0 | 14:08 |
| sean-k-mooney | so that usign the tox provided by devstack | 14:08 |
| sean-k-mooney | on stephenfin's patch | 14:08 |
| sean-k-mooney | so the pone we have pinned it too has the supprot to bootstracp to the requried version if needed | 14:08 |
| sean-k-mooney | im waiting for that to complete | 14:09 |
| bauzas | there are a long list of projects that still have 3.18.0 as minimum https://codesearch.openstack.org/?q=minversion%20%3D&i=nope&literal=nope&files=tox.ini&excludeFiles= | 14:12 |
| bauzas | again, I'm not opposed to the upgrade, I just want us to be careful | 14:12 |
| bauzas | my life didn't change when I upgraded to 4.x apart the fact I stupidely forget every day that I need to add doubledashes on posargs :) | 14:13 |
| dansmith | I've been using 4.x for a long time and I still do that :) | 14:15 |
| stephenfin | bauzas: Hmm, this dev-env doc is pretty old 😅 It references RHEL 6 and easy_install 🙈 | 14:19 |
| sean-k-mooney | ya... | 14:19 |
| stephenfin | I'm happy to rewrite it, but can I stick it in a follow-up since I suspect it'll need a few rounds of review | 14:20 |
| sean-k-mooney | that compelte fien by the way py3: OK (478.49=setup[271.33]+cmd[181.72,18.91,6.54] seconds) | 14:20 |
| sean-k-mooney | so the bootstrap and execution works end ot end with the tox provided by devstack | 14:21 |
| sean-k-mooney | without impact the actul tox version that devstack provides | 14:21 |
| sean-k-mooney | tox --version | 14:21 |
| sean-k-mooney | 3.28.0 imported from /opt/stack/data/venv/lib/python3.13/site-packages/tox/__init__.py | 14:21 |
| stephenfin | sean-k-mooney: the dev-env doc references fake compute. That's not a thing any more, right? | 14:34 |
| sean-k-mooney | yes it is | 14:34 |
| sean-k-mooney | we are using them to test teh eventlet removeal with rally | 14:34 |
| stephenfin | Oh, okay. I thought the fake driver was only used for functional tests | 14:35 |
| sean-k-mooney | nope it can be used as a "real" driver | 14:35 |
| sean-k-mooney | typeicly without networkign but there is technially a fake neturon driver too | 14:35 |
| sean-k-mooney | https://github.com/openstack/devstack/blob/master/lib/nova_plugins/hypervisor-fake still works more or less | 14:36 |
| stephenfin | TIL | 14:41 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Update development-environment guide https://review.opendev.org/c/openstack/nova/+/984956 | 14:58 |
| stephenfin | bauzas: sean-k-mooney: ^ | 14:58 |
| stephenfin | dansmith: you might tell me if the (minimal) macOS instructions are correct (I've no way to verify) | 14:58 |
| dansmith | stephenfin: ack, joining a call but will look async | 14:59 |
| stephenfin | ty 🙏 | 15:00 |
| Uggla | gibi, fyi regarding bug https://bugs.launchpad.net/nova/+bug/2145783 found in the spec : While it would possible to support defining different resource_class names for different VFs under the same parent PF, this is considered bad practice and unnecessary complexity. Such configuration will be rejected. | 16:31 |
| Uggla | https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html | 16:31 |
| gibi | Uggla: that sounds good at least it was outscope due to complexity not due to infeasibility | 16:45 |
| gibi | the bad pratice holds for NICs but it seems it does not hold for GPUs | 16:46 |
| Uggla | gibi, yes we might revisit that as to me it makes sens for GPUs (was not the case at that moment). | 16:46 |
| gibi | so I'm OK to get a new spec that adds this capability | 16:46 |
| Uggla | gibi, I'd like first an answer from the reporter. Maybe he does not need it. | 16:48 |
| gibi | yeah make sense | 16:48 |
| Uggla | gibi, do you think it is something to share at the PTG ? (assuming I'll find a slot) | 16:49 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Update development-environment guide https://review.opendev.org/c/openstack/nova/+/984956 | 16:51 |
| opendevreview | Stephen Finucane proposed openstack/nova master: Fix functional tests and mypy on macOS https://review.opendev.org/c/openstack/nova/+/937727 | 16:53 |
| gibi | Uggla: Why not. Put it at the end of the Agenda like "best effort topic if we have time" | 16:53 |
| gibi | and either we touch it next week or not. If not then we can bring it up on the weekly meeting when the spec is raised | 16:54 |
| Uggla | gibi 👍 | 16:54 |
| dansmith | stephenfin: oh I was just running unit tests anyway, which is why I don't see those | 16:54 |
| stephenfin | Ah, okay. I wonder why the author of the patch didn't see (and fix) those other issues. Anyway, not related as you say | 16:55 |
| dansmith | well, one of mine is because libcrypt is not available (which also fails on oslo).. I assume that should be a skip though, I just haven't cared enough since it's one failure and easy to ignore | 16:56 |
| dansmith | I usually run unit/functional in my fedora vm, I just like to be able to run targeted single-test things natively sometimes so I don't really care or notice that a few tests fail for whatever reason | 16:58 |
| dansmith | stephenfin: the other failure is " AttributeError: module 'socket' has no attribute 'AF_PACKET'" | 17:00 |
| dansmith | which I assume is because AF_PACKET is a linux/netlink thing that isn't portable | 17:00 |
| dansmith | so again a skip seems reasonable | 17:00 |
| dansmith | (not netlink, just not POSIX) | 17:02 |
| stephenfin | looks like it https://github.com/python/typeshed/blob/bd18cc640cba4dadc51ac9a5157b79ff6adf5de3/stdlib/_socket.pyi#L478 | 17:02 |
| dansmith | yah | 17:03 |
| opendevreview | Dan Smith proposed openstack/nova master: Skip some unit tests on macOS https://review.opendev.org/c/openstack/nova/+/985014 | 17:08 |
| dansmith | stephenfin: ^ | 17:08 |
| stephenfin | +2 | 17:08 |
| opendevreview | Merged openstack/nova master: Reproduce bug #2108974: keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981557 | 17:09 |
| sean-k-mooney | Uggla: you can defien diffent resouce class names per VF today | 20:07 |
| sean-k-mooney | you jsut have to use the address to specify it | 20:08 |
| sean-k-mooney | i.e. in the devspec you can match on the vf adress and spcify which resouce class to report | 20:08 |
| sean-k-mooney | you can use the fact that the adress can have bash globs or a regex to apply that to sets of VFs too | 20:09 |
| sean-k-mooney | or at least you shoudl be able to unless we scoped that out when we did the implemeiont | 20:09 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#pci.device_spec | 20:10 |
| sean-k-mooney | the config options were desigend to enabeld that usecase | 20:11 |
| sean-k-mooney | but i dont know if we are properly handling this in rhe resouce tracker | 20:11 |
| sean-k-mooney | we shoudl be but the pci stat pools need to prperly handel that grouping | 20:11 |
| sean-k-mooney | it hilgy likely we never tested it and it broken as a result but its totally expressable today vai our config options | 20:12 |
| sean-k-mooney | Uggla: i have not had time to add pci grouping to the nova ptg but if we wanted to talk about different VF in the same pf having diffent rsouce classes for gpus usecases ti woudl make sense to talk about it toghetehr with nova pci grouping | 20:15 |
| sean-k-mooney | i had ot parly implemnt that for that feature anyway | 20:15 |
| sean-k-mooney | since i want to supprot creating groups fo VFs from teh same or diffent PFs | 20:15 |
| sean-k-mooney | i was mainly testing with takign 64 VF that i was subdeviding into groups | 20:19 |
| sean-k-mooney | a groups of 8 and groups of 4 would have 2 diffent resocues classes even if they are effectivly the same device | 20:19 |
| sean-k-mooney | as long as all host that report CUSTOM_PCI_GROUP_NICX8 provide the same VF type for that i.e. so they are interchangable form the schdluer point of view | 20:21 |
| sean-k-mooney | its ok to report other VF form the same card with a differnt type. | 20:21 |
| sean-k-mooney | *differnt resouce class. | 20:21 |
| sean-k-mooney | if you had a gpu that you partioned into 3 Mig device 1 that used half the card an 2 that used 1/4 each | 20:23 |
| sean-k-mooney | the correct way to model that in placment via nova ro cyborg would be 1 RP for the PF with an inveotyr of 2 of one resocue class and 1 of a diffent one | 20:24 |
| sean-k-mooney | being very hand wavy that is the eventual plan for how to do that in cybrog but not right away. | 20:26 |
| opendevreview | Merged openstack/nova master: Fix keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981558 | 21:22 |
| opendevreview | Merged openstack/nova master: Skip some unit tests on macOS https://review.opendev.org/c/openstack/nova/+/985014 | 21:22 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!