Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-02
19:59:37 jroll mlavalle: ok, thanks
19:59:48 jroll totally thought that was done already, sigh
20:00:11 mriedem jroll: no, osic laying everyone off working on it kind of ... stalled things out
20:00:34 jroll hasn't osic ruined my life enough already?
20:00:42 mriedem obviously not
20:00:56 jroll :|
20:00:59 mriedem if it makes you feel better, there are plenty of new intel specs to discuss at the ptg today
20:01:11 jroll that does make me feel better about not being there
20:02:10 mriedem i forget what we even need for linking the routed network aggregates
20:02:54 mriedem neutron creates a placement aggregate around the nova compute node resource providers in a given network segment, right?
20:02:59 jroll this is the most recent I could find: https://review.opendev.org/#/q/topic:bp/prep-for-network-aware-scheduling-pike
20:03:01 jroll correct
20:03:40 mriedem and when creating a server with a given network or port, we want to create the server on a host in the aggregate associated with that network
20:04:10 jroll correct
20:04:24 mriedem and placement aggregates don't have ids, so we can't just rely on some aggregate id being in the network meta for nova to use during scheduling
20:04:42 mriedem but the nova host aggregate has a uuid,
20:04:57 mriedem and if we could link the network to that aggregate uuid, then we could ....
20:04:58 mriedem idk
20:05:02 mriedem i'm confusing myself
20:05:02 jroll seems like it would also fit in the get-me-a-network stuff - choose a network that can be used on the selected host
20:05:12 jroll you're confusing me more I suspect
20:05:38 mriedem we have placement request pre-filters in the scheduler now that leverage placement aggregates,
20:05:47 mriedem i'm just trying to think through how we could do something like that for this
20:06:21 jroll I appreciate that :)
20:06:33 jroll I'm happy to talk post-ptg sometime to not distract you
20:07:51 mriedem oh ok,
20:08:12 mriedem so yeah, aggregates in placement are just a grouping concept of resource providers (compute nodes here), and the aggregate in placement is just an id,
20:08:53 mriedem if we had that aggregate id stored on the network resource in neutron, we could just translate that in nova during scheduling to say 'give me all allocation candidates (compute nodes) in that provider aggregate for this network'
20:09:11 mriedem mlavalle: is the provider aggregate in placement stored in the network resource or anywhere related to it?
20:09:25 mriedem *aggregate id
20:09:53 jroll ctrl-f "Verify that inventories were created for each segment " https://docs.openstack.org/neutron/rocky/admin/config-routed-networks.html
20:10:01 jroll looks like the resource provider ID is the network segment
20:10:29 jroll the segment has the network ID but dunno about vice versa
20:10:49 jroll can query segments by network ID, so that could work
20:13:08 mriedem the network resource has a list of segments
20:14:14 jroll hmm, it does, but not with UUIDs :/
20:14:48 mriedem https://developer.openstack.org/api-ref/network/v2/index.html?expanded=show-network-details-detail#response-example-admin-user-multiple-segment-mappings
20:15:11 mriedem right so how to translate that to https://developer.openstack.org/api-ref/network/v2/index.html?expanded=show-network-details-detail#segments
20:15:49 mriedem GET /v2.0/segments?segmentation_id=1,segmentation_id=2,etc
20:15:52 mriedem i think?
20:16:01 mriedem and then from those, you use the uuid id to get the providers
20:16:55 mriedem and then from those, you what? get the provider aggregates that those segments are in?
20:17:28 mriedem and those aggregates are mirrored as nova host aggregates that you, the admin, have to put hosts into...right?
20:18:07 mriedem would need to sit down with mlavalle probably to make sure i'm understanding properly, but it sounds like the pieces are there
20:18:50 mriedem would be much easier to play with if i had a devstack with routed networks setup, but i'm not sure how easy that is
20:19:38 jroll well if we're going to do another API call, we could just do GET /v2.0/segments?network_id=foo
20:19:55 jroll the segment UUID is the UUID for the resource provider aggregate
20:20:09 jroll and yeah, I assume the admin would have to put the hosts in there
20:23:08 mriedem i thought the segment id (uuid) was the provider id,
20:23:09 mriedem not the aggregate id
20:23:21 mriedem but yeah GET /v2.0/segments?network_id=foo is simpler
20:27:27 mriedem a couple of issues with this in nova scheduler right now: 1. we don't have the requested networks in the RequestSpec 2. we don't yet have the ability to put a RequestGroup in the spec that is not filtering on some kind of resource (e.g. filtering on just traits or aggregates), but the good news is i think both of those are in progress
20:28:30 mriedem 1: https://review.opendev.org/#/c/570201/
20:29:45 mriedem gibi_cape: don't you have a patch for supporting an unnumbered request group that doesn't require resources?
20:30:44 mriedem https://review.opendev.org/#/c/647396
20:33:59 bauzas gibi_cape: I'm curious when looking at https://review.opendev.org/#/c/652608/ is that you don't need to pass allocations to finish_resize
20:34:10 bauzas or is it just an implementation concern ?
20:34:16 jroll ah sorry, you're right about the provider id, not aggregate id
20:38:50 gibi_cape mriedem: that patch https://review.opendev.org/#/c/647396 makes sure that the unnumbered group is created based on the flavor _early_ in the RequestSpec so traits or aggregates request can be added to the unnumbered group directly and don't have to be added to the flavor extra spec
20:39:51 gibi_cape bauzas: I think I need to pass the RequestSpect to finish_resize
20:39:58 gibi_cape bauzas: so the spec might miss that
20:40:15 gibi_cape bauzas: here, the PoC code https://review.opendev.org/#/c/655721/4/nova/compute/rpcapi.py
20:40:28 bauzas oh wait
20:40:49 bauzas you were talking of the conductor's finish_resize() method
20:40:51 bauzas gibi_cape: ^
20:40:54 bauzas not the compute one
20:41:09 bauzas of course, then yes you need the ReqSpec
20:41:25 bauzas for once the allocation is made, you also need to pass it to the compute service I guess
20:41:40 bauzas and then you hit https://review.opendev.org/#/c/589085/1/nova/compute/manager.py
20:42:51 gibi_cape bauzas: I don't have to pass the allocation to the virt driver as the virt driver does not do anything about the bandwidth resource
20:43:03 mriedem gibi_cape: ah ok
20:44:07 gibi_cape mriedem: supporting request group without resources is only discussed on the ML so far
20:44:51 cdent gibi_cape, mriedem: the emerging consensus on that is also "yeah, we'll probably need to do that"
20:50:24 mriedem ok so until then i can continue to hitch a ride with the flavor extra specs in the request spec yeehaw
20:54:44 gibi_cape mriedem: sure you can :)
20:57:25 bauzas gibi_cape: oh ok gtk
20:57:34 bauzas and yeah that makes sense, my bad
20:57:46 bauzas you care about neutron, not the virt driver
20:59:06 gibi_cape bauzas: yes
21:20:11 openstackgerrit melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.opendev.org/638073
21:20:11 openstackgerrit melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.opendev.org/653146
21:20:12 openstackgerrit melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.opendev.org/653845
21:20:12 openstackgerrit melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.opendev.org/638324
21:24:45 openstackgerrit melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.opendev.org/653845
21:26:15 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Fix a description for config_drive parameter https://review.opendev.org/653683
21:55:39 openstackgerrit Merged openstack/nova master: Query `in_tree` to placement https://review.opendev.org/649535
21:55:47 openstackgerrit Merged openstack/nova master: Remove 'instance_update_at_top', 'instance_destroy_at_top' https://review.opendev.org/651301
22:11:31 stephenfin jaypipes: Wanna look at this again https://review.opendev.org/#/c/629589/ and close out SR-IOV live migration? IIRC, the only change was a comment but there might be more to say I didn't fast approve it
22:13:06 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Hey let's support routed networks y'all! https://review.opendev.org/656885
22:14:07 mriedem jroll: ^
22:14:35 mriedem the scheduler piece needs to be sorted out since the request filters are processed before we create the request group stuff (where the requested aggregates are going to go)
22:28:38 melwitt is anyone else getting this error running unit tests locally? oslo_config.cfg.NoSuchOptError: no such option transport_url in group [DEFAULT]
22:29:05 openstackgerrit melanie witt proposed openstack/nova master: Revert "Fix target_cell usage for scatter_gather_cells" https://review.opendev.org/653894
22:29:05 openstackgerrit melanie witt proposed openstack/nova master: Fix SynchronousThreadPoolExecutorFixture mock of Future https://review.opendev.org/650171
22:29:06 openstackgerrit melanie witt proposed openstack/nova master: Use futurist.ThreadPoolExecutor in scatter_gather_cells https://review.opendev.org/650172
22:35:58 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Hey let's support routed networks y'all! https://review.opendev.org/656885
22:36:03 mriedem melwitt: nope
22:36:05 mriedem stale pycs?
22:38:23 melwitt mriedem: that was it. thanks for the reminder. I haven't had a stale pyc problem in forever
22:39:15 mriedem tox used to auto remove those

Earlier   Later