Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-12-13
16:52:03 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.1: [pwmgmt]ignore missin governor when cpu_state used https://review.opendev.org/c/openstack/nova/+/903553
16:53:06 gibi elodilles, sean-k-mooney: thanks for the review on the backport of the power management fix here is the Antelope backport ^^
16:53:11 gibi still clean cherry-pick
17:00:40 elodilles gibi: will look into it
17:34:11 gibi thanks!
18:01:39 sean-k-mooney looks liek bobcat one already merged. that was fastere then i expected which is nice
18:02:43 sean-k-mooney the feature was added in antelope
18:02:43 sean-k-mooney i rememeber correctly this shoudl be the final backport correct
18:02:43 sean-k-mooney i agree its a clean backport and the commit ectra is all correct so +2w
18:03:10 sean-k-mooney so once that merges the issue will be closed across all affected branches
18:32:20 opendevreview Artom Lifshitz proposed openstack/nova master: POC: glanceclient streaming uploads https://review.opendev.org/c/openstack/nova/+/903611
18:32:54 sean-k-mooney that sound like a new feature
18:33:31 sean-k-mooney hum just enabing an exisitng glance one. i wonder if that needs to be a config option however
18:34:05 sean-k-mooney i think streaming upload/download may have some depenices on how glance or the webserver/loadbalance its deployed behind are configured
18:34:48 sean-k-mooney it was added by https://opendev.org/openstack/glance/commit/7f761e16ce69ec549be1a66bd2797e53d0a1d988?style=unified&whitespace=show-all&show-outdated=
18:36:46 sean-k-mooney application/octet-stream that shoudl work
18:37:05 sean-k-mooney its the same content type as a normal upload
19:53:56 opendevreview Stephen Finucane proposed openstack/nova master: docs: Address nits in new security group doc https://review.opendev.org/c/openstack/nova/+/903590
19:59:15 opendevreview Artom Lifshitz proposed openstack/nova master: POC: glanceclient streaming uploads https://review.opendev.org/c/openstack/nova/+/903611
20:00:42 opendevreview Merged openstack/nova master: Use SDK for remaining ironic driver calls https://review.opendev.org/c/openstack/nova/+/867795
20:03:06 artom sean-k-mooney, so chunked is apparently not the same as streaming
20:04:08 artom Though if I'm honest I'm not sure I understand the difference on the wire. The mechanics appear to be - pass a generator to Python requests = chunked, pass a file handler = streaming
20:04:37 artom Maybe I should check what Nova currently passes... I kinda assumed it just yeeted the entire image in the POST body
20:05:07 artom Hrmp, no mention of 'chunked' anywhere in our git log
20:06:52 opendevreview Jay Faulkner proposed openstack/nova master: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/900831
20:32:17 opendevreview Merged openstack/nova master: docs: Revamp the security groups guide https://review.opendev.org/c/openstack/nova/+/903507
20:37:01 opendevreview Merged openstack/nova master: docs: Address nits in new security group doc https://review.opendev.org/c/openstack/nova/+/903590
20:46:36 JayF gibi: When you get a chance, https://review.opendev.org/c/openstack/nova/+/867797/ and the children below it are almost ready to land in that big Ironic<>Nova openstacksdk migration chain; I've been trying to usher these through the gate so a review and approval there (and on the other patches in the stack, as appropriate) would be appreciated. Thank you!
23:46:10 opendevreview Merged openstack/nova master: [codespell] fix typos in tests https://review.opendev.org/c/openstack/nova/+/897213
#openstack-nova - 2023-12-14
00:07:27 opendevreview Merged openstack/nova master: Use SDK for deprecated baremetal proxy API https://review.opendev.org/c/openstack/nova/+/867796
01:01:36 opendevreview Takashi Kajinami proposed openstack/nova master: Remove deprecated [api] use_forwarded_for https://review.opendev.org/c/openstack/nova/+/903339
02:31:05 opendevreview Nobuhiro MIKI proposed openstack/nova master: scheduler: Request COMPUTE_ADDRESS_SPACE_* traits https://review.opendev.org/c/openstack/nova/+/895761
03:31:55 opendevreview OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/903427
05:41:14 opendevreview Takashi Kajinami proposed openstack/nova master: Remove deprecated [api] use_forwarded_for https://review.opendev.org/c/openstack/nova/+/903339
08:11:44 gibi JayF: Done
08:22:57 bauzas gibi: sean-k-mooney: it would be nice if you could review my bugfix series https://review.opendev.org/q/topic:%22bug/2041519%22
10:10:07 bauzas it would also be nice if cores could look at my mdev live-migration spec https://review.opendev.org/c/openstack/nova-specs/+/900636
10:17:29 bauzas wow
10:37:19 noonedeadpunk hey there! I have quite "trivial" question about limit_tenants_to_placement_aggregate / placement_aggregate_required_for_tenants / AggregateMultiTenancyIsolation things just to confirm I understand that correctly.
10:38:34 noonedeadpunk So basically "user story" is to make set of computes be available only for specific tenant, meaning that it should be able to spawn instances _only_ on that aggregate, while all other tenants should be able to spawn anywhere _except_ this aggregate
10:38:54 bauzas noonedeadpunk: shit, I need to leave in a sec
10:39:01 noonedeadpunk Am I right that I should then use limit_tenants_to_placement_aggregate: true, placement_aggregate_required_for_tenants: false and ignore AggregateMultiTenancyIsolation
10:39:25 bauzas there are multiple ways to support tenancy limitations
10:39:30 noonedeadpunk Or, use AggregateMultiTenancyIsolation but then add another property and set of flavors for this tenant?
10:39:38 bauzas either by the filter or by our pre-filters
10:41:02 bauzas noonedeadpunk: there is another change from sahid related to this https://review.opendev.org/c/openstack/nova/+/896512
10:42:00 noonedeadpunk I need just 1 tenant to be isolated, so it shouldn;t be an issue...
10:42:03 noonedeadpunk sure...
10:42:24 noonedeadpunk will still write a question for the future :)
10:43:30 noonedeadpunk So reading description for placement_aggregate_required_for_tenants it made me think, that using placement will limit tenant to the aggregate, so won't allow to escape these computes, but will allow others to use them
10:44:44 noonedeadpunk Or maybe I need both limit_tenants_to_placement_aggregate and AggregateMultiTenancyIsolation? Then on pre-filter THE tenant will get only suggestion for the aggregate, and then filter will cut down all rest tenants to be able to spawn there?
10:55:29 opendevreview Stephen Finucane proposed openstack/nova master: Resolve mypy error https://review.opendev.org/c/openstack/nova/+/903530
10:55:29 opendevreview Stephen Finucane proposed openstack/nova master: Bump hacking version https://review.opendev.org/c/openstack/nova/+/903529
10:56:03 gibi bauzas: I will try...
10:57:33 opendevreview Stephen Finucane proposed openstack/nova master: pre-commit: Add mypy https://review.opendev.org/c/openstack/nova/+/896228
10:57:33 opendevreview Stephen Finucane proposed openstack/nova master: tox: Use pre-commit for pep8 target https://review.opendev.org/c/openstack/nova/+/896227
11:12:59 bauzas gibi: no worries, as you can
11:18:28 opendevreview Merged openstack/nova master: tests: Use clearer syntax for empty generator https://review.opendev.org/c/openstack/nova/+/903076
12:40:30 dvo-plv sean-k-mooney, thanks, it works with venv, but I can not figure out how it works previously, couple days ago
12:57:52 opendevreview Stephen Finucane proposed openstack/nova master: docs: Further clarifications to the SG doc https://review.opendev.org/c/openstack/nova/+/903675
12:57:57 stephenfin sean-k-mooney: per our discussion ^
13:22:27 bauzas gibi: want to ship your recent backport into Antelope? I was asked to +1 https://review.opendev.org/c/openstack/releases/+/899603
13:24:41 bauzas I think I'll release first the antelope reelase and then we will create another stable release for https://review.opendev.org/c/openstack/nova/+/903553
13:31:28 gibi bauzas: left feedback on the mdev live migration series
13:31:42 bauzas gibi: <3
13:42:17 bauzas gibi: replied https://review.opendev.org/c/openstack/nova-specs/+/900636
13:42:30 bauzas you asked a very good question about the conductor option
13:42:48 bauzas I already thought about all the possibilities but I don't know which one is the better
13:43:20 bauzas and I also tried to explain you why and how we need a libvirtdriver dict
13:44:33 bauzas another possibility instead of an internal dict would be to persist *something* *somewhere* about instances/mdevs
13:44:41 bauzas either in DB or in some file
13:44:58 bauzas I know sean-k-mooney has concerns about the fact we check the usage by looking at the guest XMLs
13:46:29 bauzas (I mean, if we're about persisting anything, I would way prefer to do it in some file like /var/lib/instances rather than with our Nova DB, for multiple reasons, one being I'm afraid of all the possible wrong values we would write in the DB that would mean to be fixed by hand)
14:08:02 sean-k-mooney bauzas: i have a personal goal of not requiring persitent xmls at all in the future
14:08:54 sean-k-mooney i want nova to be able to recreate a vm evne ifn the /etc/libvirt/qemu directiory is deleted
14:09:48 sean-k-mooney i would much prefer to use the db but /var/lib/instances is much better then what we have today
14:10:53 sean-k-mooney bauzas: if we coudl converge the pci tracker and medev code paths into a common device tracker that would be awsome in my view but i dont think that is goign to happen near term
14:18:20 bauzas sean-k-mooney: sorry in a meeting, let's discussing in 10-ish
14:18:25 bauzas discuss*
14:25:14 bauzas sean-k-mooney: back, readinh
14:26:33 bauzas sean-k-mooney: sure, tbc, lemme explain why we're discussing it now : gibi is wondering why we need an internal dict to "persist" which mdevs are taken for live-migration (before the target guest runs with a domain)
14:27:52 bauzas so I was just offering to persist some 'mdevs' file in the related /var/lib/instances/<inst_uuid> directory that would tell 'yo, those are the mdevs I use'
14:28:13 bauzas but there be dragon
14:28:45 bauzas (I'm pretty sure that a domain is created on target's /var/lib/instances as soon as we start the live-migration)
14:28:49 opendevreview Merged openstack/nova master: Remove Ironic client wrapper https://review.opendev.org/c/openstack/nova/+/867797
14:28:59 opendevreview Merged openstack/nova master: Remove unnecessary aliasing https://review.opendev.org/c/openstack/nova/+/867798
14:29:06 opendevreview Merged openstack/nova master: Use real SDK objects in tests https://review.opendev.org/c/openstack/nova/+/867799
14:29:14 bauzas wow the gate sounds definitely better :)
14:31:20 bauzas (tbh, what I said about writing a file in /var/lib/instances per instance dir could be a problem with shared storage, or not, depending on whether we are able to say "look, this mdev doesn't exist, I'm gonna recreate it"
14:38:49 sean-k-mooney we can always nest it in a $hostname folder if needed
14:53:26 bauzas sean-k-mooney: say I have a magical wand, what would be your preference ? using an internal dict like I wrote in the spec or persist some file in /var/lib/instances/<inst> ?
14:53:42 bauzas the latter would require me to update the spec but I can live with that
14:54:38 bauzas (this wouldn't impact the current behaviour which would be to lookup the domain definitions, this is just additive either way)
14:55:12 bauzas if we decide later to use that file too for mdevs we spawn, then we would eventually stop to lookup the domain XMLs
14:55:40 bauzas this is Christmas time, make a wish.
14:55:52 bauzas gibi: sean-k-mooney: ^
14:57:42 bauzas (note : I don't know *yet* how to implement a persistent file but I can arrange that by remembering the service uuid file thing
15:09:01 gibi > we use the internal dict for persisting which mdevs are already used for live-migration for making sure that other instances being created in the target compute wouldn't take them while we live-migrate.
15:09:17 gibi OK so this is basically a lock between the instances
15:09:35 gibi so that again resource tracker territory. But I got it that it is too big of a move

Earlier   Later