Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-17
15:36:36 mriedem yeah and that's used here https://review.openstack.org/#/c/567268/36/nova/scheduler/utils.py
15:36:38 gibi mriedem: yes. and that data ends up in the RequestSpec here https://review.openstack.org/#/c/567268/36/nova/compute/api.py@884 which leads to bandwidth allocations
15:36:44 mriedem to build the resource request to allocation candidates
15:36:59 gibi mriedem: yes
15:37:41 mriedem so if we were to merge the first patch in the series, we'd be allocating these things on server create, but not handling them for moves, or port detach
15:38:20 yan0s if I want to have the same set of flavors in two Regions
15:38:30 mriedem gibi: i kind of see two options, neither of which is probably great for you:
15:38:36 yan0s do I need to duplicate them in both Regions?
15:38:52 yan0s or is there another solution for them to exist in just one place?
15:38:53 mriedem 1. re-order the series so the bottom-up changes (nova-compute) happens first and we build to the top where the api transfers the port request to the scheduler
15:39:31 mriedem 2. we don't merge the bottom changes in the series until we're happy with the whole thing, at which point we approve it all and hope it merges in the same day/week
15:40:20 gibi mriedem: there is one catch. Unitl https://review.openstack.org/#/c/590363/27/neutron/services/qos/qos_plugin.py@128 merges there is no resource_request field in the neutron ports. And after that patch merges there is still a manual step to enable the neutron port extension to turn on the whole feature
15:40:22 mriedem yan0s: does nova-api span regions?
15:41:07 mriedem gibi: is there a nova change which depends on that neutron change?
15:41:20 yan0s I'm still just in theory about it
15:41:21 mriedem i would think https://review.openstack.org/#/c/567268/ should depend on https://review.openstack.org/#/c/590363/
15:41:39 gibi mriedem: no direct dependency as if there is no code that fails if the resource_request is missing
15:41:58 mriedem sure, but it's a functional dependency
15:41:59 yan0s What do you mean by that?
15:42:17 yan0s HA deployment of nova-api?
15:42:22 mriedem yan0s: your question depends on if you have separate nova deployments (separate api endpoints) per region
15:42:25 yan0s over the 2 regions?
15:42:25 gibi mriedem: the neutron api extension that introduces resource_request is lik a feature flag for the whole bandwidth series
15:42:47 gibi mriedem: I can make a depends-on to the neutron patch, that is easy
15:42:51 mriedem if you have separate compute api endpoints per region, using isolated dbs, then yes you'd need to duplicate across regions (i think that's what project kingbird is for)
15:43:08 gibi mriedem: what I'd like to achive is to consider the neutron api extension as a feature flag
15:43:11 mriedem gibi: so what do you think about the 1 or 2 options above?
15:43:53 mriedem personally i'd like to merge some stuff to see it continue moving, but i probably won't do that while the control-plane changes are coming before the backend nova-compute changes to handle cleaning up
15:44:11 mriedem which just means you'd be dealing with merge conflicts longer...
15:44:17 gibi mriedem: I'd like to propose 3.: the neutron api extension is marked experimental till a good set of usecases are covered by the code merges.
15:45:09 yan0s I think, since my regions are going to be in the same DC, the best option will be to have one nova-api
15:45:15 gibi mriedem: if that doesn't work for you, then I can move the reject cases and the detach case to the front of the series
15:45:58 gibi mriedem: detach might not work when moved to the front so I might need to reject detach until some create logic merges
15:46:03 mriedem gibi: it might work. i'll just finish reading the spec again, start going through the nova changes and +1 if i'm cool with a change and we'll see where it goes from there once i have the whole thing in my head
15:46:47 yan0s could you point to me some documentation on same nova-api region deployment?
15:47:00 gibi mriedem: I will run an experiment locally to see how hard is the re-arrange
15:47:23 gibi mriedem: will not push anyting before we sync
15:50:29 mriedem yan0s: i'm aware of https://docs.openstack.org/operations-guide/ops-capacity-planning-scaling.html#segregating-your-cloud but it's old
15:50:42 mriedem https://wiki.openstack.org/wiki/Kingbird
15:51:30 mriedem yan0s: note the cells mention in that ops guide is about cells v1, which is deprecated and replaced with cells v2 in nova which is not experimental nor optional - all nova deployments since ocata are by default a cells v2 cell of 1
15:53:58 yan0s mriedem: thanks!
15:55:03 yan0s so shared nova-api means using cells instead of regions
15:55:05 yan0s correct
15:55:06 yan0s ?
15:55:09 mriedem yes
16:01:20 mriedem https://storyboard.openstack.org/#!/story/2004625 if anyone wants to cleanup the 'cells' reference in the old ops scaling guide
16:01:49 gibi mriedem: if we want to go with good order that means either I cannot allow booting an instance with bandwidth until nova supports migrate, evacuate, unshelve for that instance, or reject migrate, evacuate, unshelve, for that instance
16:02:03 yan0s So choosing in which region to launch a VM is a matter of using this regions API
16:02:11 gibi mriedem: neither looks really good to me :/
16:02:27 yan0s how do I specify in which cell to launch a VM?
16:03:20 mriedem yan0s: cells are not exposed out of the rest api, so if you want a vm to go to a specific cell, you pick a host (or az) that's in that cell
16:04:14 mriedem gibi: realistically we shouldn't be supporting creating servers with qos-enabled ports today anyway right? since we don't honor the actual qos request.
16:04:29 mriedem and that's why it's all disabled in neutron
16:05:19 yan0s ok got it, thanks again!
16:05:24 mriedem i know during the spec review we talked about this sort of like with multiattach volumes, which you could always use before nova actually supported them for attaching to at most 1 server
16:05:27 gibi mriedem: yeah, in nova we cannot really support qos requests unilt we merge a _lot_ of code
16:06:15 mriedem gibi: yeah, which is why i said i guess we could just +1 our way to a point where we think it's ready to merge and then try to merge it all as a big chunk
16:06:31 mriedem rather than try to merge effectively noop pieces from the bottom up
16:06:41 mriedem the former is more like a feature branch
16:06:44 gibi mriedem: that will be at least 20 patches (I have 15 already without any server move)
16:07:28 gibi mriedem: we can consider evey nova patch no-op while the neutron api extension is disabled :)
16:07:43 mriedem gibi: given it's 5pm for you, how about i just continue reviewing this today and you not worry about it for a bit :)
16:07:51 gibi mriedem: sure
16:07:52 gibi :)
16:08:12 mriedem we likely can't merge anything until the first week of january anyway...
16:08:50 gibi mriedem: yeah, but if we can agree on re-arranging the things then I can work on that this week
16:09:10 mriedem ok i'll get a better idea of that when i go through the series
16:09:24 gibi sure
16:09:41 mriedem like you said, maybe we just say it's all on neutron and turning it on there via policy
16:10:42 gibi mriedem: I would like that ^^
16:11:18 mriedem i bet you would :)
16:11:22 mriedem now go have some goulash
16:11:34 gibi yes, sir :)
16:36:05 openstackgerrit Merged openstack/nova master: Add python 3.7 unit and functional tox jobs https://review.openstack.org/624055
16:36:14 openstackgerrit Merged openstack/nova master: api-ref: sort parameters for limits, quotas and quota classes https://review.openstack.org/528786
16:36:22 openstackgerrit Merged openstack/nova master: Mention size limit on user data in docs https://review.openstack.org/620700
16:36:29 openstackgerrit Merged openstack/nova master: Restore nova-consoleauth to install docs https://review.openstack.org/605154
17:14:09 openstackgerrit Merged openstack/nova stable/rocky: Remove GROUP BY clause from CellMapping.get_by_project_id https://review.openstack.org/625377
17:39:08 openstackgerrit Merged openstack/nova master: Add py36/py37 functional jobs to the experimental queue https://review.openstack.org/624826
17:57:08 mriedem gibi: ok comments in https://review.openstack.org/#/c/567268/ when you're up again
17:57:28 mriedem nothing major, just lots of comments for lots of code
19:40:33 mriedem melwitt: did you want to push this into the queens release? https://review.openstack.org/#/c/611945/
20:21:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Drop request spec migration code https://review.openstack.org/614265
20:21:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove legacy request spec compat code from API https://review.openstack.org/614309
20:21:43 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Pass request_spec from compute to cell conductor on reschedule https://review.openstack.org/582417
20:21:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat code from live migrate task https://review.openstack.org/625705
20:21:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor unshelve_instance https://review.openstack.org/625706
20:21:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor rebuild_instance https://review.openstack.org/625707
20:22:21 mriedem bauzas: would be nice to remove this crufty ass old request spec compat code from api/conductor after all these years ^
20:24:22 melwitt mriedem: yeah, sorry need to re-review
20:26:02 mriedem i've got stable release requests up for rocky, queens and pike
20:26:14 mriedem since those likely need to be done today or tomorrow if they are going to be done this week
20:27:01 melwitt k, good call
21:01:56 mriedem easy code motion patch to get nova to use the oslo.upgradecheck library framework https://review.openstack.org/#/c/603499/
21:06:57 openstackgerrit Merged openstack/nova master: Remove utils.execute() from the hyperv driver. https://review.openstack.org/620008
21:07:05 openstackgerrit Merged openstack/nova master: Remove utils.execute() from virt.disk.api. https://review.openstack.org/620009
21:32:07 mriedem jaypipes: are you around this week?
21:33:39 mriedem jaypipes: if you are, you were +2 on the amd sev spec at PS12, I'm +2 now at PS16: https://review.openstack.org/#/c/609779/ - if you can take another pass at it
21:33:43 mriedem uber detailed
21:42:26 jaypipes mriedem: will do.

Earlier   Later