| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-11 | |||
| 19:17:13 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix the ocata config-reference URLs https://review.openstack.org/502017 | |
| 19:25:58 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix the ocata config-reference URLs https://review.openstack.org/502017 | |
| 19:26:58 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec to remove the hide server address config options https://review.openstack.org/502516 | |
| 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 lvm handling to privsep. https://review.openstack.org/495516 | |
| 19:48:08 | openstackgerrit | Michael Still proposed openstack/nova master: Move nbd commands to privsep. https://review.openstack.org/500351 | |
| 19:48:09 | openstackgerrit | Michael Still proposed openstack/nova master: Move shred to privsep. https://review.openstack.org/495537 | |
| 19:48:09 | openstackgerrit | Michael Still proposed openstack/nova master: Move xend existence probes to privsep. https://review.openstack.org/495538 | |
| 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 ploop commands to privsep. https://review.openstack.org/492325 | |
| 19:48:14 | openstackgerrit | Michael Still proposed openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664 | |
| 19:48:24 | openstackgerrit | Michael Still proposed openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541 | |
| 19:48:24 | openstackgerrit | Michael Still proposed openstack/nova master: Read from console ptys using privsep. https://review.openstack.org/489486 | |
| 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 blkid calls to privsep. https://review.openstack.org/500398 | |
| 19:48:26 | openstackgerrit | Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737 | |
| 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 | nsmith? | |
| 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: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 | |