gmaan | sean-k-mooney: stephenfin: while adding tempest tests for migrations by project manager, I realized that we need one list migrations API (list all migrations not just in-progress live migrations) to allow for manager. I a m amending it in spec, ptal https://review.opendev.org/c/openstack/nova-specs/+/953722 | 03:24 |
---|---|---|
*** elodilles is now known as elodilles_pto | 06:14 | |
opendevreview | Thomas Goirand proposed openstack/nova master: Add a [libvirt]/force_virtio_cd option https://review.opendev.org/c/openstack/nova/+/953732 | 08:37 |
opendevreview | Thomas Goirand proposed openstack/nova master: Add a [libvirt]/force_virtio_cd option https://review.opendev.org/c/openstack/nova/+/953732 | 08:40 |
zigo | Does the above patch makes sense, and does the team understand my motivation as an operator? | 08:41 |
opendevreview | Thomas Goirand proposed openstack/nova master: Add a [libvirt]/force_virtio_cd option https://review.opendev.org/c/openstack/nova/+/953732 | 08:41 |
opendevreview | Balazs Gibizer proposed openstack/nova stable/2025.1: Fix neutron client dict grabbing https://review.opendev.org/c/openstack/nova/+/953737 | 09:49 |
opendevreview | Merged openstack/nova stable/2024.1: Add repoducer test for bug 2074219 https://review.opendev.org/c/openstack/nova/+/953656 | 10:07 |
sahid | o/ | 10:59 |
sahid | I'm still stuck finding information regarding live migration that are failing | 10:59 |
sahid | it's weird that we don't log anything | 10:59 |
sahid | the ;igration list --server xx show that status is in error but don't explain what the error is | 11:00 |
sean-k-mooney | you shoudl check the source compute node for logs | 11:03 |
sean-k-mooney | or conductor in some cases | 11:03 |
sahid | hum I did not tried on conductor... on source the only error I have is Live Migration failure: 'fa:....' | 11:06 |
sahid | Migration operation has aborted | 11:06 |
sean-k-mooney | aborted is not the same as failing. that likely just hit the timeout | 11:06 |
sahid | sean-k-mooney: I think the Live Migration failure failure is comming frist from libvirt driver | 11:09 |
sahid | then the exception is propagaded | 11:09 |
sean-k-mooney | it can if it failed on the migrate step | 11:10 |
sahid | let me see if I find from where is comming the message Migration operation has aborted | 11:10 |
sahid | the event is mentionning, compute_rollback_live_migration_at_destination and there is no log at destination | 11:14 |
sahid | we are missing to log some important details | 11:14 |
opendevreview | Merged openstack/nova stable/2024.1: Fix detaching devices by alias with mdevs https://review.opendev.org/c/openstack/nova/+/953662 | 11:23 |
sean-k-mooney | just an fyi i repliekd to mikal email just now, neutron broken debian 12 support with https://github.com/openstack/neutron/commit/8990dd598f84b9da976d72672c6fd6037fc0d125 it seams so the nova hybrid plug job is broken until they fix the coalaiton type | 11:24 |
opendevreview | Kamil Sambor proposed openstack/nova master: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/948072 | 11:55 |
opendevreview | Kamil Sambor proposed openstack/nova master: Replace utils.spawn_n with spawn https://review.opendev.org/c/openstack/nova/+/948076 | 11:55 |
opendevreview | Kamil Sambor proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079 | 11:55 |
opendevreview | Kamil Sambor proposed openstack/nova master: Move ComputeManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948186 | 11:55 |
opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754 | 11:55 |
*** bauzas0 is now known as bauzas | 12:43 | |
fungi | [repeating myself from yesterday, sorry] it's come up a few times in debian over recent years that other cloud platforms don't rely on ahci driver access for cdrom devices, and so their minimal "cloud" linux kernel config doesn't include support for it, which means users have to manually override to virtio to make configdrive work with debian's official "genericcloud" images. | 12:47 |
fungi | is there a reason not to switch the default in nova to virtio, as suggested in https://bugs.debian.org/1108403 ? (i see zigo just pushed change 953732 for this too) | 12:47 |
zigo | I didn't push for this, because I was fearing it would be too much of an aggressive change, but I'd basically agree with fungi that it'd be nice to have virtio by default. | 12:48 |
opendevreview | Thomas Goirand proposed openstack/nova master: Add a [libvirt]/force_virtio_cd option https://review.opendev.org/c/openstack/nova/+/953732 | 12:49 |
zigo | fungi: Thanks for spotting the typo btw! :) | 12:50 |
zigo | My patch looks like passing the CI, it just had a POST_FAILURE for nova-ovs-hybrid-plug. | 12:50 |
fungi | it's also obvious to us, but perhaps not to the debian kernel maintainers, that nova changing its default now will only slowly trickle down to public cloud providers, as there are some still running their services on decade-old versions of openstack | 12:53 |
zigo | I just believe that Waldi only cares about his customer in this case (ie: Microsoft and Azure) that's not impacted by the missing AHCI driver. | 12:54 |
zigo | IMO, it's a conflict of interest case. | 12:54 |
zigo | Never the less, virtio-cd is much nicer than ide... | 12:55 |
sean-k-mooney | fungi: so we use sata by default when using q35 machine type or ide for pc | 12:59 |
sean-k-mooney | fungi: we cant use virtio-scis because of window window si belive | 12:59 |
sean-k-mooney | so we dont really have an alternitive choice | 13:00 |
sean-k-mooney | zigo: we only use ide for the pc machien type if you defautl to q35 we use sata as i noted above, virtio-cd either iddnt exist or was not a option when we last chagned the defautl 4+ years ago | 13:02 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Use built-in declarative https://review.opendev.org/c/openstack/nova/+/953751 | 13:02 |
sean-k-mooney | we coudl consider if that is now viablebased on our min libvirt version although we may need to restrict that to only linux machine unless windows ships with it by default | 13:02 |
zigo | sean-k-mooney: Oh, so activating the feature I'm proposing would break windows setup, right? | 13:03 |
sean-k-mooney | maybe we dont supprot virtio-cd at all | 13:03 |
sean-k-mooney | so we woudl first need to supprot that and deterim if it can be the default or contintioal default absed on OS_TYPE on the galnce image | 13:03 |
sean-k-mooney | im late for a meeting but ill be free in an hour and can look into this more | 13:04 |
zigo | We do, it just need a specific metadata. | 13:04 |
zigo | As much as my colleague is telling me, this would *not* break our windows image that has the virtio CD support. | 13:05 |
zigo | the metadata is: | 13:05 |
zigo | hw_cdrom_bus=virtio | 13:05 |
sean-k-mooney | will it break a vanilla windows install iso | 13:05 |
sean-k-mooney | zigo: so you can set that | 13:05 |
zigo | *we* wouldn't care. | 13:05 |
sean-k-mooney | but there used to be problems with useing it | 13:05 |
sean-k-mooney | well nova would | 13:06 |
zigo | sean-k-mooney: Yeah, *we* can, but some idiot customers have no idea about it, will take system image snapshot or backup, attempt to boot, and see it fail because of the CD being ide and the lack of AHCI support in the image. | 13:06 |
zigo | I'd like to avoid this ... | 13:06 |
sean-k-mooney | so we really try to not make things dynmaic based on the image in a lot of cases but its worth a dicussion at least | 13:07 |
opendevreview | Takashi Kajinami proposed openstack/nova master: sqlalchemy: Use built-in declarative https://review.opendev.org/c/openstack/nova/+/953751 | 13:07 |
sean-k-mooney | zigo: i know there was a reason we could not use virtio as the default at the time | 13:07 |
sean-k-mooney | but i dont recall the details | 13:08 |
sean-k-mooney | it may have been our min libnvirt versin at the time | 13:08 |
sean-k-mooney | zigo: i assume you woudl prefer that we use virio by default both for pc and q35 machine type? | 13:09 |
sean-k-mooney | zigo: the last time we chagne defautl was yoga https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device | 13:12 |
sean-k-mooney | so we have precendet for doing this | 13:12 |
opendevreview | Takashi Kajinami proposed openstack/placement master: sqlalchemy: Use built-in declarative https://review.opendev.org/c/openstack/placement/+/953759 | 13:13 |
stephenfin | sean-k-mooney: gibi: ralonsoh: I assume you're aware that nova-ovs-hybrid-plug is permafailing on master since last Friday? https://zuul.opendev.org/t/openstack/builds?job_name=nova-ovs-hybrid-plug&project=openstack/nova | 13:54 |
ralonsoh | let me check | 13:54 |
stephenfin | I took a look at things that merged to neutron and neutron-lib between the last pass and first fail but didn't spot anything obvious | 13:55 |
stephenfin | ralonsoh: neutron-api is failing because there's a name field being set on a model that doesn't have the relevant column | 13:55 |
stephenfin | https://zuul.opendev.org/t/openstack/build/79bd7dae1b954169a77159ca53b85422/log/controller/logs/screen-neutron-api.txt | 13:56 |
stephenfin | (specifically the networksegments table as you'll se) | 13:56 |
stephenfin | *see | 13:56 |
ralonsoh | let me check first the last patches merged | 13:56 |
ralonsoh | stephenfin, this is because a stupid guy merged a patch last friday | 14:02 |
ralonsoh | a very stupid guy and a very stupid patch | 14:02 |
gibi | sean-k-mooney: dansmith: could you add the back the +A to https://review.opendev.org/c/openstack/nova/+/948072/ it was lost in a rebase | 14:02 |
dansmith | done | 14:03 |
ralonsoh | stephenfin, I've pushed the fix: https://review.opendev.org/c/openstack/neutron/+/953768. Check that the Neutron db migration is failing: https://zuul.opendev.org/t/openstack/build/46c6d08486c3461dbc6f3fcb3c2b832d/log/job-output.txt#13491 | 14:03 |
stephenfin | ralonsoh: :D | 14:03 |
gibi | dansmith: thanks | 14:03 |
stephenfin | ahh | 14:04 |
stephenfin | I was looking in the wrong place | 14:04 |
stephenfin | ralonsoh: Looks like a bug in devstack too. init_neutron shouldn't be finishing with result 0 if the db_sync failed, right? https://zuul.opendev.org/t/openstack/build/46c6d08486c3461dbc6f3fcb3c2b832d/log/job-output.txt#13509 | 14:05 |
ralonsoh | right, that should have been stopped the stack process | 14:05 |
opendevreview | ribaudr proposed openstack/nova-specs master: Enable memfd support for shared memory backing https://review.opendev.org/c/openstack/nova-specs/+/951689 | 14:09 |
Uggla | sean-k-mooney, gibi, dansmith if you have time I'll be happy it you can have a look at ^ | 14:11 |
zigo | sean-k-mooney: I'd prefer if it was virtio-cd *always*, yes. | 14:41 |
sean-k-mooney | so if we were to make that change it would only take effect for new vms | 14:41 |
zigo | Yeah, I get that point. | 14:42 |
sean-k-mooney | when we made teh other changes we added code to recored the currnt model in the db | 14:42 |
sean-k-mooney | we did that so we could chagne the default in the future | 14:42 |
zigo | BTW. what is the use of rabbit_qos_prefetch_count? I've set use_queue_manager and rabbit_stream_fanout, but now nova-compute complains I haven't set rabbit_qos_prefetch_count and it is to its default of zero. What is a good value for this then ? | 14:43 |
sean-k-mooney | we bassically pretent the glance image properlty is set and add it in isntance sysmtem metaadat table as if it came form teh glance image when the vm is first created | 14:43 |
sean-k-mooney | zigo: no idea i dont think we sue that in nvoa today so its proably directly coming form oslo.messaging | 14:44 |
sean-k-mooney | zigo: we directly include the oslo.messaging cofnig options in our config because all the parsieng fo those exctra are done by oslo not nova | 14:44 |
zigo | Yeah, like everyone else does! :) | 14:45 |
sean-k-mooney | well excpet swift... | 14:45 |
zigo | Which is a real pain. | 14:45 |
zigo | We tried switching to json log to send all to Elasticsearch, it worked great ... except for swift ! :/ | 14:46 |
sean-k-mooney | so i am not sure what that does but you might get a better answer for the oslo folks | 14:46 |
sean-k-mooney | zigo: i both love and hate that that exists | 14:46 |
sean-k-mooney | its really nice for suecase like that | 14:46 |
sean-k-mooney | but when our custoerm enabel that and i have to ready the raw logs in json format it sucks | 14:47 |
sean-k-mooney | i wish there was a tool to take teh json format and print them normally in human reablae forrmat in oslo | 14:47 |
zigo | It was commited together with the fanout and stream stuff by Arnaud Morin <arnaud.morin@ovhcloud.com> | 14:47 |
zigo | https://review.opendev.org/c/openstack/oslo.messaging/+/890825 | 14:47 |
sean-k-mooney | ya so nova does not supprot any of that offically | 14:48 |
zigo | Though absolutely no doc about it ... :/ | 14:48 |
sean-k-mooney | im vagly aware that stream supprot has been added but no work has been doen to use nova with it | 14:48 |
sean-k-mooney | it might work but no one has done the work to test it | 14:48 |
zigo | https://www.rabbitmq.com/docs/consumer-prefetch | 14:48 |
sean-k-mooney | there has been no cross project work to support it that im aware off | 14:48 |
sean-k-mooney | ok so it sound like itx a limit of how many unacked message a clinet can have at a time | 14:49 |
sean-k-mooney | https://bugs.launchpad.net/oslo.messaging/+bug/2031497 really shoudl have had an oslo spec IMO | 14:51 |
sean-k-mooney | maybe they had one for stream supprot in general | 14:52 |
zigo | Agreed. | 14:52 |
sean-k-mooney | zigo: i hope your not plannig to use that in debian 13 by default | 14:52 |
sean-k-mooney | the stream supprot i mean | 14:53 |
sean-k-mooney | its disabled by default in oslo https://docs.openstack.org/nova/latest/configuration/config.html#oslo_messaging_rabbit.rabbit_stream_fanout | 14:53 |
sean-k-mooney | and we do not ahve any testing with it at all for nova | 14:53 |
sean-k-mooney | we also do not test with rabbit_quorum_queue set to ture either | 14:54 |
sean-k-mooney | it might work but again no work has been doen in nova to offically supprot it | 14:54 |
sean-k-mooney | we could close that gap by enablign testing in nova-next | 14:55 |
zigo | Well, it's time to move to it: rabbitmq does *not* support HA queue starting at version 4.0.x | 14:55 |
zigo | So no choice for operators. | 14:55 |
sean-k-mooney | but we would also need to update the docs before offically supproting it | 14:55 |
sean-k-mooney | im aware although flamingo is the first realee we are usign 4.0.0 i think | 14:55 |
sean-k-mooney | although that may have been epoxy | 14:56 |
sean-k-mooney | it depend on what is in ubuntu 24.04 | 14:56 |
zigo | Ahh... Please everyone: stop that bullshit again. Upstream does not get to choose what's in the distro. :( | 14:56 |
sean-k-mooney | we get to choose what we supprot | 14:56 |
sean-k-mooney | and if we dont have it aviabel in our ci to test with we cant claim supprot | 14:56 |
zigo | Debian Trixie has RabbitMQ 4.0.5, and it has Epoxy. | 14:56 |
sean-k-mooney | ack | 14:57 |
zigo | Just like I have to make Epoxy run on Python 3.13: no choice... :/ | 14:57 |
sean-k-mooney | i think its goign to be imporant to get trixy in our ci as soon as practical | 14:57 |
sean-k-mooney | we offically only supprot debian 12 cuyrrently | 14:57 |
zigo | I need to fix this rabbitmq config first, so I can continue my tests. | 14:57 |
sean-k-mooney | trixy woudl be add next cycle | 14:57 |
zigo | Trixie is out in a few weeks... :) | 14:58 |
sean-k-mooney | ack, i think must of those feature are aviabel in the older release of rabbit too | 14:58 |
sean-k-mooney | so we can try and use them in our existing jobs provide they work | 14:58 |
zigo | It's always the same story anyways, so I'm used to it. :) | 14:58 |
gmaan | sean-k-mooney: you might have noticed but pinging just in case you missed that manager role series is ready for review https://review.opendev.org/q/topic:%22bp/policy-manager-role-default%22+status:open | 16:36 |
sean-k-mooney | gmaan: its proably in my gerrit folder but this week and last i have not been on top of burning that down to 0 each day | 16:42 |
sean-k-mooney | so tanks for the ping ill take a look at the spec today | 16:42 |
gmaan | sean-k-mooney: thanks | 16:42 |
opendevreview | Takashi Kajinami proposed openstack/nova master: sqlalchemy: Use built-in declarative https://review.opendev.org/c/openstack/nova/+/953751 | 16:54 |
sean-k-mooney | tkajinam: so ^ is not nessiarly a bad thign but it need to have a tracker, at the miniume this shoudl be a tech debt but IMO. | 16:56 |
sean-k-mooney | the other thing to condier is while we supprot sqlachemy 2.0 | 16:57 |
sean-k-mooney | we stilll supprot 1.4.13+ | 16:57 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/requirements.txt#L6 | 16:57 |
*** iurygregory__ is now known as iurygregory | 16:58 | |
sean-k-mooney | so to do that we woudl need to bump our min version to 2.0 | 16:58 |
sean-k-mooney | we coudl do that but that will need a release note | 16:58 |
sean-k-mooney | to capture the upgrade impact | 16:58 |
sean-k-mooney | oh actully no | 16:58 |
sean-k-mooney | https://github.com/sqlalchemy/sqlalchemy/commit/450f5c0d6519a439f40 was in 1.4.0 | 16:59 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | 16:59 |
opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC executor selectively using threading https://review.opendev.org/c/openstack/nova/+/953815 | 16:59 |
sean-k-mooney | so so it does nto force min version bump above our current min | 16:59 |
opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | 17:07 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Make nova.utils.pass_context private https://review.opendev.org/c/openstack/nova/+/948188 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Rename DEFAULT_GREEN_POOL to DEFAULT_EXECUTOR https://review.opendev.org/c/openstack/nova/+/948086 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Document threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-api and -metadata in threaded mode https://review.opendev.org/c/openstack/nova/+/951957 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | 17:24 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | 17:27 |
opendevreview | Balazs Gibizer proposed openstack/nova master: FUP: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/953338 | 17:28 |
opendevreview | Balazs Gibizer proposed openstack/nova master: FUP: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/953339 | 17:28 |
sean-k-mooney | as an fyi the nova gate should become unblocked once https://review.opendev.org/c/openstack/neutron/+/953768 lands | 17:56 |
*** iurygregory_ is now known as iurygregory | 18:07 | |
sean-k-mooney | gmaan: im holding +w to make sure you agree with that my interperation of host info alings with yours | 18:10 |
gmaan | sean-k-mooney: checking | 18:11 |
sean-k-mooney | proably shoudl have pinged with the link to the comment https://review.opendev.org/c/openstack/nova-specs/+/953722/comment/a91a7f7a_c8837144/ | 18:14 |
gmaan | sean-k-mooney: replied, yes, host related fields will be 'None' for non-admin | 18:16 |
sean-k-mooney | ok if we are treatign includign the query parma as a error for non admins | 18:17 |
sean-k-mooney | then that ok | 18:17 |
sean-k-mooney | and ack on the rest | 18:17 |
sean-k-mooney | None is fin i guess or empty string | 18:17 |
gmaan | yeah | 18:18 |
sean-k-mooney | which ever is allowed by the schema | 18:18 |
gmaan | for request, you mean to error ? | 18:18 |
gmaan | yeah, there will be no change in request, whatever it is allowed now will be same | 18:18 |
sean-k-mooney | well i dont want to allwo them to probel by sarting a resize and then guessign the source node ectra | 18:18 |
sean-k-mooney | so ok i think im happy we are on the same page | 18:18 |
sean-k-mooney | im ok to move to the impleation review so ill add +w | 18:19 |
gmaan | sean-k-mooney: this is the implementation will looks like with more granular policies https://review.opendev.org/c/openstack/nova/+/953063/7/nova/api/openstack/compute/migrations.py | 18:20 |
gmaan | and next patch in that series change the policy to know what all things will be open/allowed for manager https://review.opendev.org/c/openstack/nova/+/941347 | 18:21 |
sean-k-mooney | ya that looks reasonable | 18:23 |
sean-k-mooney | i left a comment on the asymetry with dest_host and the duplciatvie info that it contains with dest_compute | 18:24 |
sean-k-mooney | but that is just an observation not a request to change anythign | 18:24 |
gmaan | ack | 18:24 |
sean-k-mooney | we are a littel inconssitent with how we fileter on the query side and how we respsent this in the responce | 18:25 |
sean-k-mooney | like host in the query can match the source or dest host but source_compute only mages the soucee but you cant query by only dest compute or node | 18:26 |
sean-k-mooney | i dont feeel like it worth haveing a microversion to fix that right now | 18:26 |
sean-k-mooney | after we finish the openapi serise and we have clollected a bunch of similar odities it might make sense to do another cleanup microversion to normalise things | 18:27 |
sean-k-mooney | gmaan: you have 2 serise this cycle right service role and manger role. do you have a prefered order for those in terms of review | 18:28 |
gmaan | host in query is either one, just checked if we do same in code or not and yes it match either one https://github.com/openstack/nova/blob/43d57ae63d1ecda24d8707b4750d404daadc980f/nova/db/main/api.py#L3425 | 18:29 |
gmaan | sean-k-mooney: yeah, I am targeting to finish manager role first | 18:29 |
sean-k-mooney | ack | 18:30 |
sean-k-mooney | hopeflyy we can do both but i think doing one then the other is more likely to work out | 18:30 |
sean-k-mooney | ill try and do a pass over the manager role then this week | 18:30 |
gmaan | yeah, once I am done with manager role I am going to resume my service role also | 18:30 |
sean-k-mooney | ping me if i havnt by firday | 18:30 |
gmaan | cool, ack | 18:30 |
opendevreview | Merged openstack/nova-specs master: Allow list migrations policy to manager role https://review.opendev.org/c/openstack/nova-specs/+/953722 | 18:30 |
sean-k-mooney | Uggla: i left some comments on your memfd spec https://review.opendev.org/c/openstack/nova-specs/+/951689 i dont see any other reviwe on that so beign realsitc that proably wont land this cycle | 19:40 |
sean-k-mooney | it could but its definetly at risk | 19:40 |
sean-k-mooney | we might want to punt it premtivly so we can discss the upgrade impact with less time pressure | 19:40 |
sean-k-mooney | there are some details i would like to see captured in the spec that are missing and im not sure we should rush it but im +1 on the overall propsoal | 19:41 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!