Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-01-10
14:57:27 noonedeadpunk Sorry, I'm trying to come up with some extra comments to it
15:00:24 noonedeadpunk Well, given that indeed it's not "requested" per say, I think it may indeed being confusing
15:01:16 noonedeadpunk Like in our case, where we want to have instances "evenly" distributed across AZs even when clients requested nothing
15:01:32 noonedeadpunk But, they will indeed be pinned to this AZ
15:03:08 noonedeadpunk But I also kinda wonder, if the output from the spec should be shown to everyone. As a user I will be also very confused if for some reasone these 2 will differ
15:03:50 noonedeadpunk While I totally get why I'd love to monitor that without doing DB queries on my own
15:04:28 bauzas noonedeadpunk: we have some customers that wonder why they can't move their instances to something else
15:05:14 bauzas endusers don't really know about that, but they can see that their instance is pinned or not
15:05:49 bauzas but agreed on the fact operators would want to have a specific policy for this parameter
15:05:52 noonedeadpunk Hm, does scheduler hint for specific compute may also result in instance being pinned to it? I guess not?
15:06:01 noonedeadpunk As it's hint after all...
15:06:08 bauzas it shouldn't
15:06:24 bauzas we only pin on three facts :
15:06:32 bauzas - the user requested an AZ
15:06:48 bauzas - the operator defaulted instances to an AZ (per nova-api service)
15:07:13 bauzas - the instance is attached to a volume that *already* uses an AZ
15:07:42 bauzas I don't see any other conditions where we would pin
15:08:04 noonedeadpunk I think `pinned_availablity_zone` makes sense indeed. As "attached" as Sean mentioned can also be slightly confusing
15:08:08 bauzas except of course if some operator changed the RequestSpec value directly :p
15:08:27 bauzas noonedeadpunk: could you then add a comment in the spec ?
15:10:01 bauzas noonedeadpunk: fwiw, /me going to look at your own spec :)
16:12:10 sean-k-mooney ykarel: https://review.opendev.org/c/openstack/tempest/+/905130 is the fix for what i mentioned
16:12:19 sean-k-mooney or at least my first attempt of a fix
16:15:30 bauzas noonedeadpunk: https://review.opendev.org/c/openstack/nova-specs/+/900296 mostly because you haven't written the work items and the spec doesn't have any owner
16:15:46 bauzas will you have time to work on it this cycle ?
16:15:53 bauzas you or someone else you know ?
16:20:40 noonedeadpunk Well. Yes, I was planning to work on that, though I initially also expected to have slightly more time for it...
16:20:55 bauzas shouldn't be a large feature
16:21:12 bauzas add a new weigher should be an easy peasy
16:21:19 noonedeadpunk Yeah, that's true.
16:21:38 bauzas the most large patch would be adding the policy and the rule, with all files to touch due to the new microversion
16:21:48 bauzas most largest*
16:22:07 bauzas but I can help you on that
16:22:10 noonedeadpunk and caching part you wrote concerns me as well a bit
16:22:41 noonedeadpunk as will need get myself aware of how that's done today (never touched this part of code)
16:28:09 noonedeadpunk bauzas: about policies - what policies you have in mind?
16:28:30 noonedeadpunk as I was thinking that existing `os_compute_api:os-server-groups` would cover this?
16:28:38 bauzas noonedeadpunk: well, I wrote "cache it" but actually, it shouldn't be a cache
16:29:09 noonedeadpunk it's jsut get AZs to a var and then iterate over filters kinda?
16:29:16 bauzas yeah exactly
16:29:35 noonedeadpunk gotcha
16:29:35 bauzas but the fact is that the weigher only knows about a few things
16:29:46 bauzas https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py#L39
16:30:03 bauzas so you would need to pass the list of azs into some object-
16:30:55 noonedeadpunk well, request_spec sounds like what is needed?
16:31:03 noonedeadpunk ah, ok, list of available ones
16:31:41 bauzas req_spec is a formal oslo object
16:31:59 bauzas I wouldn't recommend to use it, but that's your choice
16:32:15 bauzas I just want to not have a oslo.versioned field for that
16:32:33 bauzas some internal attribute for this object would work for it
16:32:38 bauzas for me*
16:33:05 bauzas noonedeadpunk: got my concern ? we run filters and weighers once per instance per host
16:33:32 noonedeadpunk yeah, totally
16:33:46 bauzas so if we were calling the list of AZs in the weigher, we would run it N times, N being the number of filtered hosts
16:35:26 bauzas noonedeadpunk: you could stuff the list of AZs somewhere in https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L299
16:40:58 noonedeadpunk will adjust spec with your notes
16:42:59 opendevreview Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134
17:20:54 opendevreview Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296
17:25:56 noonedeadpunk bauzas: I've tried to address your concerns ^
17:26:22 noonedeadpunk but actually now I get a bit more your concerns for getting AZs out of filter itself
17:28:02 noonedeadpunk because eventually, here we should be caring about "aggregates" rather then individual host and also weight based on that
17:30:30 sean-k-mooney noonedeadpunk: i was too hasty with reviewing your spec
17:30:42 sean-k-mooney if forgot there was also a second spec on this topic
17:30:45 sean-k-mooney https://review.opendev.org/c/openstack/nova-specs/+/890779/3/specs/2024.1/approved/availability-zone-affinity-filters.rst
17:30:57 sean-k-mooney and that we have to do some non trivial stuff with the request spec
17:31:08 sean-k-mooney noonedeadpunk: for contiend we need to suport multi create
17:31:18 sean-k-mooney i.e. one reuest that ask for n vms
17:31:26 sean-k-mooney as well as parallal create
17:32:16 sean-k-mooney sorry not parralle serial non overlapping creates of instance one after another waiting for each to go to active before doing the next
17:34:32 noonedeadpunk I probably should jsut abandon mine I guess as it indeed now looks like a duplicate one
17:38:36 noonedeadpunk I guess the one you posted originated from Vacouver PTG, as this discussion was raised there as well....
17:46:07 noonedeadpunk It really slipped my attention, though I was checking for simmilar existing blueprints :(
17:46:56 bauzas noonedeadpunk: you somehow need to flip between hosts
17:47:49 bauzas but ya, looks to me a bit difficult
17:48:03 bauzas anyway, I need to go off
18:11:52 sean-k-mooney so we have example code that we can reuse for this for the normal host based affinity
18:12:15 sean-k-mooney i just dont think i will have time to track that down and provide links to it before sepc freeze
21:29:30 JayF https://review.opendev.org/c/openstack/nova/+/900831 needs an additional core review, it is a bugfix for the Ironic driver. Your reviews would be appreciated o/
#openstack-nova - 2024-01-11
01:12:06 opendevreview Yalei Li proposed openstack/nova master: Implement get_power_state using domain.state https://review.opendev.org/c/openstack/nova/+/904970
03:24:26 opendevreview sean mooney proposed openstack/nova master: add bin dir for non eventlet console_scripts https://review.opendev.org/c/openstack/nova/+/904424
03:24:26 opendevreview sean mooney proposed openstack/nova master: remove use of eventlet.queue.LightQueue https://review.opendev.org/c/openstack/nova/+/900681
03:24:27 opendevreview sean mooney proposed openstack/nova master: set rpc executor based on monkey patch state https://review.opendev.org/c/openstack/nova/+/905284
03:24:27 opendevreview sean mooney proposed openstack/nova master: use futureist for scater_gather https://review.opendev.org/c/openstack/nova/+/905285
04:37:23 opendevreview sean mooney proposed openstack/nova master: move context executor to utils and remove eventlet.tpool https://review.opendev.org/c/openstack/nova/+/905287
05:00:35 opendevreview Merged openstack/nova master: Lower num_pcie_ports to 12 in the nova-next job https://review.opendev.org/c/openstack/nova/+/902175
09:02:40 sahid o/
09:03:11 sahid anychance that you make progress on that one? https://review.opendev.org/c/openstack/nova/+/896512 I think we are good with it, no? something else is needed?
09:03:41 sahid s/you make/we make :-)
10:04:11 noonedeadpunk I actually have question slightly realted to this ^
10:04:42 noonedeadpunk Like right now looking at AggregateMultitenancyIsolation and fail to understand a way to make an aggregate isolated for tenant.
10:05:23 noonedeadpunk Isolated in term - only tenants specified in aggregate can create instances in the aggregate. And not on any other computes - just this aggregate
10:05:57 noonedeadpunk I assumed, that using placement isolation together with AggregateMultitenancyIsolation will do that, but seems it's not...
10:06:31 noonedeadpunk Or well, maybe I have to add all other computes to different aggregate....
10:08:00 noonedeadpunk So I have this: enable_isolated_aggregate_filtering = True, limit_tenants_to_placement_aggregate = True, placement_aggregate_required_for_tenants = False
10:12:12 opendevreview Rajesh Tailor proposed openstack/nova-specs master: List requested availability zones https://review.opendev.org/c/openstack/nova-specs/+/904368
10:13:59 bauzas sahid: unfortunately, we haven't yet accepted https://blueprints.launchpad.net/nova/+spec/aggregatemultitenancyisolation-to-support-unlimited-tenant as a specless bp
10:14:13 bauzas sean-k-mooney was having some concern when we discussed it on a team meeting
10:14:25 bauzas for me I'm OK but we don't have consensus
10:15:39 noonedeadpunk So my assumption was, that if request comes from a tenant that is not in filter_tenant_id, AggregateMultiTenancyIsolation will filter out all hosts that belong to aggregates with filter_tenant_id defined. And if request comes from tenant with filter_tenant_id - placement will return only hosts that have this metadata
10:15:58 noonedeadpunk But in fact, aggregate is not restricted for "outsiders"

Earlier   Later