Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-16
15:06:48 mriedem to say, 'move to this other nova-specific option'
15:07:17 mnaser lyaaaaaaaaaaaaar: thank you very much
15:07:57 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553817
15:08:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553818
15:09:07 cdent mriedem: I'm not sure I'm following? The option (in the config file) stays the same. What will be different is how the process has the code which makes the conf option legit and validates its value?
15:09:44 mriedem cdent: i don't think you can (should) re-define an option in nova.conf that is already in oslo.service,
15:09:51 mriedem because the oslo.service options are imported into nova.conf
15:09:56 mriedem s/imported/registered/
15:10:13 johnthetubaguy superdan: mriedem: do we need the placeholder migrations for queens now?
15:10:16 cdent right, but in placement itself there is no import of oslo_service
15:10:35 mriedem cdent: i understand, but placement is still in nova
15:10:42 mriedem and it's using nova's config
15:10:43 mriedem so..
15:10:52 cdent so I'm wondering about a sort of hack in placement that says "this is a stub for a thing that is normall in olso_service, but since it's in default it's okay"
15:11:03 cdent sure, but it is an indepedent process, so it doesn't really care, does it?
15:11:22 mriedem i defer to melwitt
15:11:40 cdent it's not a big deal, it just seems wasteful to import oslo_service
15:11:49 mriedem and i'm saying you don't have to,
15:11:53 mriedem if we define our own option
15:12:06 mriedem which is what placement would have to do anyway once it's split out
15:12:09 mriedem to keep using this
15:12:21 cdent maybe we are talking about the same thing
15:12:45 cdent when you say "define our own option" do you mean "an option with a different name" or "an option with the same name but defined elsewhere"?
15:12:57 jgwentworth Roamer`: I think you should send email to the dev mailing list with tag [nova] to ask about the possibility of the storpool imagebackend
15:13:25 mriedem different name (or group)
15:14:09 cdent huh, okay. That suggests to me that 'log_options' (which is mighty generic) is in the wrong package, but I guess we're stuck.
15:15:57 mriedem idk, [api]/log_option
15:16:03 mriedem *log_options?
15:16:23 mriedem [DEFAULT]/log_config
15:17:05 Roamer` jgwentworth, thanks, will do
15:18:00 cdent 'log_options' seems like a thing that plenty of process, not just ones using oslo_service might like to do and configure, if they use oslo_config. but s'okay.
15:18:37 mriedem johnthetubaguy: i think that's taken care of before the release
15:19:22 mriedem johnthetubaguy: although i don't see them
15:19:32 johnthetubaguy mriedem: but I don't see them in here: https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo/versions
15:19:43 cdent fried_rice: https://blueprints.launchpad.net/nova/+spec/placement-extract
15:19:50 mriedem johnthetubaguy: nor do i
15:19:55 mriedem johnthetubaguy: i think there is a script to generate them
15:20:09 fried_rice cdent: Cool mon, thanks.
15:20:41 johnthetubaguy mriedem: I think it has to be post release, so they are missing in stable, but present in master? it always confuses me
15:20:53 mriedem yeah in case you backport a db migration,
15:21:08 mriedem it then takes the placeholder spot in master
15:21:37 fried_rice cdent: I guess you'll be going through and tagging all your patches accordingly?
15:21:47 fried_rice I commented on https://review.openstack.org/#/c/553149/
15:22:05 cdent fried_rice: if that's what you really want
15:22:52 mriedem johnthetubaguy: yikes https://review.openstack.org/#/q/file:%255Enova/db/sqlalchemy/api_migrations/migrate_repo/versions.*+status:open
15:23:16 mriedem https://review.openstack.org/#/q/file:%255Enova/db/sqlalchemy/migrate_repo/versions.*+status:open
15:23:27 fried_rice cdent: Do you feel as though that's pointless unnecessary busywork? Me, I'd like to be able to search on the topic and get the list of all the patches associated with the effort. And having the LP bot collate them in the bp whiteboard, also useful.
15:23:59 fried_rice cdent: I can do it if you like. Shouldn't be a big effort, eh?
15:24:20 superdan johnthetubaguy: oh yeah I think we do, hopefully we haven't merged any yet?
15:24:31 superdan johnthetubaguy: I can do it, I usually do
15:24:58 cdent fried_rice: I can see how it useful, so happy to do it, since I need to go in there anyway for something else. But because of the amount of searching I do to create the weekly report, I tend not to be very topic oriented (despite using the urls all the time), so it's not something that immediately leaps to mind for me
15:25:01 superdan mriedem: ^
15:25:27 fried_rice cdent: Gotcha.
15:25:36 mriedem i don't think we've merged any db migrations in rocky yet, but checking
15:26:07 mriedem nope we're good
15:26:18 superdan mriedem: will do it after this call
15:28:40 johnthetubaguy superdan: sweet thanks, just spotted a change doing a migration, and it made me stop and think
15:28:52 superdan johnthetubaguy: yeah, thanks
15:29:56 openstackgerrit Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057
15:30:24 leakypipes superdan, mriedem, bauzas, gibi, alex_xu_, figleaf: ^^ reworked mirroring spec.
15:32:51 kashyap mriedem: Was looking up the scroll this morning; about increasing timeouts due to QEMU / libvirt updates
15:32:57 kashyap https://review.openstack.org/#/c/547676/
15:33:18 kashyap Even clarkb (not on this channel now) also reported at PTG having to increase tests' timeouts
15:33:54 kashyap I think it must probably be the QEMU / libvirt slowdown after the Meltdown / Spectre fixes. /me goes to check w/ the libvirt folks
15:36:39 openstackgerrit Surya Seetharaman proposed openstack/nova stable/pike: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/553829
15:37:46 openstackgerrit Surya Seetharaman proposed openstack/nova stable/pike: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/553829
15:41:27 mriedem kashyap: yes mnaser already confirmed that
15:41:51 kashyap mriedem: I struggle to believe the libvirtd dameon _itself_ taking 1 _whole_ minute!
15:42:00 kashyap mriedem: I'm checking w/ the Red Hat perf team to see if they have any numbers on this
15:42:02 mriedem libvirt/qemu in the ocata UCA got updates and has to great a guest on first start to scan cpu features, which is not something newer libvirt in the pike UCA has to do
15:42:13 mriedem *create
15:42:22 mriedem https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/ocata-staging/+sourcepub/8774271/+listing-archive-extra
15:42:24 kashyap I know, they ship with new CPU models, all ending with "*-IBRS"
15:42:45 openstackgerrit Surya Seetharaman proposed openstack/nova stable/pike: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/553829
15:42:59 kashyap (Yep, very familiar w/ those updates for a couple of months already. As I had to apply to a bunch of Fedora / RHEL machines)
15:45:02 kashyap This additional slow down even bolsters the case for the couple of Cloud Providers to enable nested virt in the Gate.
15:45:23 kashyap Upstream KVM maintainer said he's going to enable it for Intel by default in the upstream kernel.
15:46:19 kashyap ClarkB, myself and a bunch of others participated in a discussion with the Cloud Providers at PTG, some cloud providers (OVH) seemed amenable to that.
15:46:24 kashyap Let's see...
15:47:42 fried_rice figleaf: Reviewed. Nothing blocking :)
15:48:17 fried_rice figleaf: Are you still -1 on https://review.openstack.org/#/c/553476/ for the name of that article, having read my excellent excuses?
15:48:54 mriedem volume test issues in the gate should be flushed once https://review.openstack.org/#/c/553794/ merges
15:49:21 jgwentworth woot, thanks
15:49:25 openstackgerrit Dan Smith proposed openstack/nova master: Add placeholder migrations for Queens backports https://review.openstack.org/553831
15:49:27 superdan mriedem: johnthetubaguy ^
15:49:56 mriedem superdan: aren't there some tests that you need to modify for the placeholder range?
15:50:07 superdan mriedem: um, no, jeez
15:50:08 superdan (yes)
15:51:03 cfriesen kashyap: for what it's worth, I haven't had good experiences with stability of nested KVM with CentOS 7.3.
15:51:21 figleaf fried_rice: yes, 'upt' is much too cryptic
15:51:23 kashyap cfriesen: Got a link to the bugs you've filed? :-)
15:51:41 kashyap cfriesen: More seriously, some Cloud Providers in the room themselves said it was stable in their environments
15:51:52 fried_rice figleaf: Having noticed your # noqa hack, I guess I can make it work with a longer name, eh?
15:51:58 cfriesen kashyap: heh...nothing useful to report, just random intermittent crashes of the first-level guest.
15:52:01 kashyap cfriesen: The cardinal rule here is to try with latest CentOS (stable 7.4)
15:52:20 kashyap cfriesen: I used to track all the bugs I reported for nested virt upstream, a year or so ago: https://kashyapc.fedorapeople.org/kernel-kvm-bugs.txt
15:52:26 kashyap All of them fixed now
15:52:41 cfriesen cool, will have to give it a try with 7.4
15:53:08 kashyap cfriesen: But, one of the blocking points is the migration of the L1 guest (with the mere presence of L2 in it; it doesn't even have to run). And upstream is working on it as we speak
15:53:11 fried_rice mriedem: What am I tracking for these volume failures to be resolved before I clog the gate with more rechecks?

Earlier   Later