Earlier  
Posted Nick Remark
#openstack-nova - 2017-09-11
19:42:37 openstackgerrit Markus Zoeller (markus_z) proposed openstack/nova master: docs: Explain the flow of the "serial console" feature https://review.openstack.org/476188
19:44:13 dansmith mriedem: you wanna look at that ironic online migration thing?
19:44:26 dansmith mriedem: I promised the skip level people we were fixing this
19:46:38 mriedem which ironic people? i want names and addresses.
19:48:08 openstackgerrit Michael Still proposed openstack/nova master: Move nbd commands to privsep. https://review.openstack.org/500351
19:48:08 openstackgerrit Michael Still proposed openstack/nova master: Move lvm handling to privsep. https://review.openstack.org/495516
19:48:09 openstackgerrit Michael Still proposed openstack/nova master: Move xend existence probes to privsep. https://review.openstack.org/495538
19:48:09 openstackgerrit Michael Still proposed openstack/nova master: Move shred to privsep. https://review.openstack.org/495537
19:48:10 openstackgerrit Michael Still proposed openstack/nova master: Cleanup mount / umount and associated rmdir calls https://review.openstack.org/494423
19:48:12 openstackgerrit Michael Still proposed openstack/nova master: WIP / Aspirational: we don't need rootwrap any more. https://review.openstack.org/495542
19:48:13 openstackgerrit Michael Still proposed openstack/nova master: Don't shell out to mkdir, use ensure_tree() https://review.openstack.org/492326
19:48:14 openstackgerrit Michael Still proposed openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664
19:48:14 openstackgerrit Michael Still proposed openstack/nova master: Move ploop commands to privsep. https://review.openstack.org/492325
19:48:24 openstackgerrit Michael Still proposed openstack/nova master: Read from console ptys using privsep. https://review.openstack.org/489486
19:48:24 openstackgerrit Michael Still proposed openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541
19:48:25 openstackgerrit Michael Still proposed openstack/nova master: Move kpartx calls to privsep. https://review.openstack.org/500354
19:48:26 openstackgerrit Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737
19:48:26 openstackgerrit Michael Still proposed openstack/nova master: Move blkid calls to privsep. https://review.openstack.org/500398
19:48:33 openstackgerrit Michael Still proposed openstack/nova master: Move execs of tee to privsep. https://review.openstack.org/489438
19:49:06 openstackgerrit Kaitlin Farr proposed openstack/nova master: Remove deprecated keymgr code https://review.openstack.org/439855
19:50:34 dansmith mriedem: not ironic people, skip level people
19:51:19 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Merge server create schema for availability zone extension https://review.openstack.org/451331
19:51:20 mriedem oh right
19:51:23 mriedem 'those' people
19:53:13 dansmith yeah.
19:53:46 mikal Can't those people just get their upstream teams to take a look?
19:58:48 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Merge server create schema for availability zone extension https://review.openstack.org/451331
19:59:53 efried sean-k-mooney Did you start an etherpad yet for the nova/neutron/placement modeling topic? (or edleafe cdent slaweq?) If not I'll do it.
20:00:33 slaweq efried: I didn't
20:00:36 cdent efried, sean-k-mooney: I don’t know, and I haven’t got time, so if there isn’t one, and you have time...
20:15:59 efried Cueing up a whiteboarding session per sean-k-mooney's note on -dev ML: nova/neutron/placement interaction. Things like: How does port binding get negotiated and scheduled? How are capabilities/capacities modeled in placement and how do they get through to the claim? Thinking to grab the compute/vm/bm room Tuesday after lunch (13:30-?) Does that work for people? Others interested and/or willing to lend their expertise? da
20:15:59 efried nsmith?
20:16:00 openstackgerrit Merged openstack/nova master: Revert "Revert "Fix AZ related API docs"" https://review.openstack.org/502342
20:16:08 efried dansmith -^
20:19:30 james_li Hi nova devs, I am working on Newton. Is the placement api mandatory for newton?
20:20:10 cdent james_li: optional for newton, required for ocata. but when you upgrade to ocata, you ought to turn on placement in newton first.
20:21:49 james_li thanks cdent. so I just leave placement section in nova.conf empty to make it optional?
20:22:16 cdent pretty much. you’ll get some warnings in logs, but they’ll stop
20:22:50 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Merge server create for availability zone extension https://review.openstack.org/502574
20:24:48 openstackgerrit sunku ranganath proposed openstack/nova-specs master: WIP:Specification for using cache as a resource using cache allocation support with resource director technology and resource monitoring daemon. https://review.openstack.org/502575
20:30:38 kevi9132 Is this the correct channel to ask about the Placement API in Nova?
20:31:03 edleafe kevi9132: yes
20:31:45 mriedem fyi if you're going to be in the nova room wed-friday, bring a sweater
20:31:49 mriedem or any of the ballrooms
20:33:38 kevi9132 I'm working with Nova Newton and do not want to use the Placement API at this time to reduce the amount of change I have to work with. I've been told that not including a [placement] section in nova.conf does exactly this. However, the nova compute nodes fail to build servers because they can't find resources.
20:34:40 kevi9132 I've tried to follow the code and it appears to be that the resource tracker is expecting to use the placement api when the compute node is initialized which exceptions.
20:35:24 kevi9132 I'm sure I'm missing something so any guidance would be greatly appreciated.
20:38:40 mriedem kevi9132: do you have a paste bin of the error in the compute logs?
20:38:57 mriedem assuming builds are failing in the scheduler with NoValidHost?
20:39:57 mriedem anything hitting placement APIs should be decorated with this https://github.com/openstack/nova/blob/stable/newton/nova/scheduler/client/report.py#L49 so that we handle failures and just log warnings
20:40:52 kevi9132 Let me try to get the failure generated again since I smoked my VM. IIRC, the failure was NoValidHost because no hosts matched the RAM filter
20:44:03 kevi9132 I believe the decorator is being used. The exception is caused because an auth plugin is not found trying to create/resolve resources which results in no resource available for an instance build.
21:18:47 kevi9132 So, after booting the VM, I see that each row in the compute_nodes table has free ram and disk.
21:19:54 kevi9132 I'm guessing that the exception I was experiencing is expected and is now a red herring to what my instance build issue really is. I'm building an instance now and will capture the failure in the nova logs and post it.
21:25:22 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/502700
21:27:47 openstackgerrit OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/502708
21:28:59 mriedem1 dansmith: so does approving of this ironic flavor migration offline data migration thing mean that we're setting a precedent that now all data migrations will need both online and offline modes supported?
21:29:10 mriedem i'm guessing yes
21:29:30 mriedem unless there is a caveat about when we do a hard drop of something that relies on the data being migrated in the next release
21:30:16 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/502745
21:34:46 dansmith mriedem: we've always had that for the online migrations because of the online_data_migrations command, IMHO
21:35:02 dansmith and the skip level people are definitely asking for always having an offline option for that use case
21:35:07 dansmith which I think is very reasonable
21:35:28 dansmith mriedem: the offline mode is specifically so they can run a thing before a release drops a thing
21:35:41 mriedem "we've always had that for the online migrations because of the online_data_migrations command, IMHO"
21:35:49 mriedem we've always had online data migrations since online_data_migrations, i agree
21:36:07 dansmith mriedem: so we can drop those migrations, we just need to have them in a release so people can run them without services starting
21:36:37 mriedem so in the before times, before online data migrations, we'd just do data migrations in the sqla-migrate scripts right?
21:36:42 dansmith yeah
21:36:58 dansmith and online_data_migrations was somewhat weirdly named, in that it was the way to run the online migrations manually
21:37:01 mriedem and we do'nt want to do these there since lots of people don't want the migration happening during downtime
21:37:08 dansmith yah
21:37:42 mriedem i just wanted to make sure we realize what we're signing up for
21:38:11 dansmith I guess I don't see it as a change from what we've been doing
21:38:33 mriedem we haven't been doing offline migrations
21:38:39 melwitt yeah, this one is the only one we haven't provided a manual run for, right?
21:38:56 melwitt that is, provided a nova-manage way to run it (via online_data_migrations)
21:39:26 dansmith we had one previously for pci stuff that was like the very first one
21:39:51 mriedem we have 3 other online data migrations added in pike, why wouldn't we also be providing offline options for those?
21:39:55 dansmith mriedem: we /have/ been providing them by having this command
21:40:11 melwitt yeah, that's what nova-manage online_data_migrations is
21:40:21 dansmith yeah
21:40:22 dansmith exactly
21:40:36 melwitt what we haven't had the past few times is actual active online data migrations (sorry that's confusing)
21:40:37 dansmith it's the offline way to run online migrations ... always have been
21:41:03 dansmith yeah, some of the ones we've had recently didn't actually do online background stuff and only happened as part of this command, but.. it's the same thing
21:41:10 melwitt right
21:41:24 mriedem huh?
21:41:38 mriedem so we've always required that everything is down when we run online_data_migrations?
21:41:51 melwitt like, the past few data migrations we did, were not done actively in the background automatically while nova runs
21:41:58 mriedem https://docs.openstack.org/nova/latest/user/upgrade.html#rolling-upgrade-process
21:42:08 mriedem "Start all services on the new code, with [upgrade_levels]compute=auto in nova.conf. It is safest to start nova-conductor first and nova-api last."
21:42:29 melwitt no, we don't require that things are down. it's just that we aren't doing it automatically in the background, we provided only the manual nova-manage command to take care of it
21:42:31 mriedem (later step): "This process can put significant extra write load on the database. Complete all online data migrations using: nova-manage db online_data_migrations --max-count <number>. "
21:42:47 dansmith I think we're stuck on terminology here
21:43:07 dansmith mriedem: where are you right now? we're about done here and this might be easier in person
21:43:26 mriedem i'm cranky now and hiding
21:43:29 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/502700
21:43:32 dansmith alright
21:46:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: doc: note that custom resources are not fully supported https://review.openstack.org/501252

Earlier   Later