| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-02 | |||
| 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: Set [quota]count_usage_from_placement = True in nova-next https://review.opendev.org/653146 | |
| 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:12 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.opendev.org/638324 | |
| 21:20:12 | openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.opendev.org/653845 | |
| 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: Fix SynchronousThreadPoolExecutorFixture mock of Future https://review.opendev.org/650171 | |
| 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: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 | |
| 22:39:18 | mriedem | but it was removed | |
| 22:39:21 | mriedem | not tox, our tox.ini | |
| 22:40:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Hey let's support routed networks y'all! https://review.opendev.org/656885 | |
| 22:40:57 | melwitt | yeah, I remember now that you mention it. probably because I switch to stable branches and run tests is how they get generated at all | |
| 22:41:25 | melwitt | because I thought along with that something was done to tell python not to generate the pycs | |
| 22:42:24 | melwitt | (for newer branches) | |
| 22:51:47 | stephenfin | melwitt: I backported that patch to the stable branches. I guess some of them weren't merged | |
| 22:53:13 | melwitt | stephenfin: maybe I'm remembering wrong but I thought in the past there was something about how the value is not always respected? in earlier versions of something | |
| 22:53:43 | stephenfin | melwitt: Earlier versions of tox, yeah. We hardcode the minimum tox version now though so you should have that | |
| 22:53:53 | melwitt | ah ok | |
| 22:54:51 | igordc | hi everyone, any discussion to be had about https://blueprints.launchpad.net/nova/+spec/sriov-bond? can't find anything in ptg etherpad | |
| 22:55:25 | stephenfin | melwitt: Yeah, it goes back to stable/pike. Weird https://review.opendev.org/#/q/I779a17afade78997ab084909a9e6a46b0f91f055 | |
| 22:55:44 | melwitt | stephenfin: ok, I dunno what I did to make pycs happen | |
| 22:55:52 | melwitt | thanks for checking | |
| 22:56:00 | stephenfin | Note that we kept the 'rm -rf' on stable just in case | |
| 22:56:02 | stephenfin | np | |
| 23:00:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove conductor_api and _last_host_check from manager.py https://review.opendev.org/651059 | |
| 23:01:04 | openstackgerrit | Tushar Patil proposed openstack/nova-specs master: Support filtering of allocation_candidates by forbidden aggregates https://review.opendev.org/609960 | |
| 23:24:43 | larsks | It's -f for foreground. | |
| 23:25:00 | larsks | (I'm running a containerized znc, just checked) | |