| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-17 | |||
| 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. | |
| 21:43:02 | jaypipes | mriedem: and yes, I'm around this week. | |
| 21:59:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910 | |
| 22:13:13 | manjeets | Hi folks I have iommu = on and when boot an instance using direct sriov port it ends in error | |
| 22:13:21 | manjeets | from n-cpu logs I see libvirtError: unsupported configuration: host doesn't support passthro | |
| 22:13:21 | manjeets | ugh of host PCI devices | |
| 22:13:21 | manjeets | ERROR nova.compute.manager [instance: cd91ad4f-2a94-483b-818c-740386975f88] | |
| 22:13:21 | manjeets | ||
| 22:14:12 | manjeets | I see VF's on that NIC though, for what other reason this error can happen ? | |
| 22:14:25 | manjeets | nsupported configuration: host doesn't support passthro | |
| 22:14:25 | manjeets | ugh of host PCI devices | |
| 22:48:27 | mriedem | manjeets: you're likely going to need to paste the stacktrace into a paste and link that here for any helpful debug | |
| 22:48:34 | mriedem | http://paste.openstack.org/ | |
| 22:51:41 | manjeets | http://paste.openstack.org/show/737514/ | |
| 22:51:45 | manjeets | mriedem, ^ | |
| 22:52:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Properly log request headers in metadata API https://review.openstack.org/625731 | |
| 22:54:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Properly log request headers in metadata API https://review.openstack.org/625731 | |
| 22:56:36 | mriedem | manjeets: have you gone through https://docs.openstack.org/neutron/latest/admin/config-sriov.html ? | |
| 22:57:05 | mriedem | or https://docs.openstack.org/nova/latest/admin/pci-passthrough.html | |
| 22:57:50 | manjeets | I built devstack using https://docs.openstack.org/neutron/latest/admin/config-sriov.html | |
| 23:23:18 | openstackgerrit | Merged openstack/nova master: Migrate upgrade checks to oslo.upgradecheck https://review.openstack.org/603499 | |
| #openstack-nova - 2018-12-18 | |||
| 00:47:58 | openstackgerrit | Tim Rozet proposed openstack/nova master: [WIP] Fixes race condition with privsep utime https://review.openstack.org/625741 | |
| 01:37:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Body verification for the lock action https://review.openstack.org/622835 | |
| 02:16:33 | openstackgerrit | jiang wei proposed openstack/nova master: Update host_state's limits when specified AZ https://review.openstack.org/625755 | |
| 02:56:41 | openstackgerrit | Merged openstack/nova master: Fail to live migration if instance has a NUMA topology https://review.openstack.org/611088 | |