Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-13
15:29:51 owalsh sfinucan: I assume that's one of the main reasons for deprecating live_migration_uri
15:30:44 owalsh sfinucan: but to use SSH we need to pass user, maybe port too, and almost certainly extraoptions, and there is no way to set this when using live_migration_inbound_addr
15:37:19 sfinucan owalsh: So for 'live_migration_uri', you could conceivably set it to something like 'xen+ssh://rjones@%s/?no_verify=1'. That has both a user and extra_options
15:37:46 sfinucan owalsh: Do we want the same functionality for whatever's using live_migration_inbound_addr?
15:39:49 owalsh sfinucan: yes, currently do set the user via live_migration_uri, but we can't control which network it users. %s is always replaced with the remote hostname
15:42:00 sfinucan owalsh: ...and live_migration_inbound_addr provides an alternative to that, but it doesn't allow you to a username or extra_specs currently, right?
15:43:59 sfinucan owalsh: If we allowed you to _not_ specify '%s' for 'live_migration_uri' and instead set a static destination/IP network, would that achieve what you want?
15:44:20 cdent edleafe: are your resource tracker related functional tests sort of on hold?
15:44:46 owalsh sfinucan: you have to specify %s - it's replaced with the hostname of the live miragation target
15:45:02 sfinucan owalsh: That's what I'm saying. What if I removed that requirement
15:45:26 sfinucan Or are the two complimentary somehow?
15:46:35 owalsh so live_migration_uri = foo://bar@%s/ will tranlate to foo://bar@nova1/ when migrating to nova1, and foo:/bar@nova2/ when migrating to nova2
15:48:07 owalsh when using the new approach when migrating to nova1 we get live_migration_inbound addr etc.. for nova1 to build the url to migrate to it
15:48:15 owalsh IIRC anyway
15:49:35 owalsh it been a while since I looked at it but I think there was consensus that the new options are required
15:49:47 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622
15:49:48 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387
15:49:49 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100
15:49:52 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082
15:49:55 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941
15:49:56 openstackgerrit Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021
15:49:57 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520
15:57:30 edleafe cdent: yeah, more because I got distracted with other stuff while waiting for more feedback
15:58:18 cdent edleafe: yeah, just checking. I had a reminder to look at them but didn't have the current brain to say much in this round.
15:58:44 edleafe cdent: ok, remind me next week if you think of it
15:58:53 cdent ✔
15:59:22 mriedem dansmith: before you change things in https://review.openstack.org/#/c/456227/ i've left some comments
15:59:29 mriedem looks like some were at the same time you were replying to sfinucan
15:59:30 openstackgerrit Dan Smith proposed openstack/nova master: Fix hypervisors api missing HostMappingNotFound handlers https://review.openstack.org/456227
15:59:32 dansmith hah
15:59:33 mriedem doh
15:59:34 mriedem gdi
15:59:41 dansmith was literally just pushing when you said that
16:02:43 ildikov mriedem: johnthetubaguy: are you avaiable for the Cinder-Nova meeting?
16:02:54 mriedem yeah
16:18:16 openstackgerrit Daniel Pawlik proposed openstack/nova master: Changed network_info variable in test_create_configdrive https://review.openstack.org/436953
16:21:11 dtp good morning. can we get a ruling on https://blueprints.launchpad.net/nova/+spec/conf-network-metadata-always-static-ip, please?
16:23:38 kashyap mriedem: That live mig job failure is due to missing `nc` (Netcat), which seems to be resolved by clarkb's -- https://review.openstack.org/#/c/456388/ ("Install netcat for libvirt live migration")
16:23:43 kashyap That merged about 3 hours ago
16:23:58 mriedem kashyap: ok, i had thought that merged last night but forgot about the devstack dependency
16:24:05 mriedem i'll check logstash in a bit to see if it's dropping off
16:24:33 kashyap mriedem: See! You seem to blame libvirt at the drop of a hat :P
16:24:52 kashyap You actually didn't
16:25:17 ngupta Hi everyone, new to this channel. I want to know where does OpenStack stand with supporting encryption for Block Storage using the RBD driver.
16:27:11 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/455960
16:34:34 mriedem dansmith: is it just me, or is it weird that we don't terminate volume connections on the host when we shelve offload?
16:34:41 mriedem since when you unshelve, you can end up on another host
16:36:35 dansmith mriedem: yeah.. I assume that'd be a bug
16:36:49 mriedem like, the most latent bug ever...
16:37:00 dansmith I think there might've been some things that were left in place on the off chance it landed on the same host, but can't imagine that's right
16:37:00 mriedem i keep thinking i'm missing something obvious
16:37:11 dansmith unless we call to the old compute somehow, but we've lost that info I think
16:37:23 dansmith yeah, seems too obviously broken
16:37:52 mriedem conductor manager for unshelve calls out to scheduler to get new hosts
16:37:55 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
16:38:03 mriedem plus, you could have unshelved from a host that is now down or gone
16:38:11 mriedem *shelved
16:38:17 dansmith yeah
16:41:40 mriedem oh btw, pike-1 milestone today
16:41:46 mriedem i had forgotten about the need for the tag
16:42:35 jianghuaw_ jaypipes, sbauza: could you help to look at this VGPU spec?
16:42:36 jianghuaw_ https://review.openstack.org/450122
16:42:37 melwitt_ ngupta: I found this old spec about it https://review.openstack.org/#/c/239798/ and the consensus there mentions the way forward for rbd encrypted volumes should be with qemu native rbd encryption, but I don't think anyone worked on it yet
16:43:11 mriedem dansmith: also looks like we don't unbind ports from the host on shelve offload
16:43:20 mriedem this is all just very odd
16:43:59 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP! conf: Add three new '[libvirt] live_migration_*' options https://review.openstack.org/456571
16:44:00 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Gather 'live_migration_scheme', 'live_migration_inbound_addr' https://review.openstack.org/456572
16:44:00 melwitt mriedem: yeah, that's "intentional"? I noticed it just leaves everything there as-is, network connection, volume connection, etc
16:44:00 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Convert 'live_migration_inbound_addr' to HostAddressOpt https://review.openstack.org/456573
16:44:45 sfinucan owalsh: I've to go to tag, so that's my WIP patches. Lemme know if you think that's the right direction. Will finish them tonight or Tuesday
16:45:37 melwitt it assumes it will go back on the same host, but I don't know if it does or can do anything to guarantee that. with the network part, I could see it wanting to keep the IP allocated so that it can't be given out (and network possibly run out of IPs) when the person comes back to unshelve. same concept as keeping the quota occupied during offload
16:46:59 owalsh sfinucan: cool, thanks
16:47:10 dansmith mriedem: must be missing something
16:50:06 mriedem i honestly hope i am missing something
16:52:03 johnthetubaguy melwitt: oh, interesting, once its offloaded I kinda assumed it wasn't going back there, in all likelylood
16:53:50 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
16:57:11 dansmith melwitt: yeah, once offloaded it's not supposed to (have to) go back to the same host
16:57:15 dansmith that's the whole point
16:57:27 melwitt yeah
16:57:32 melwitt I do see it cleaning up network here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4378
16:57:39 melwitt so maybe someone just forgot about volumes?
16:59:16 openstackgerrit Rajath Agasthya proposed openstack/nova master: Fix Bandit jinja2 warnings https://review.openstack.org/456709
16:59:21 mriedem melwitt: that's a noop for neutron
16:59:36 melwitt I would not have expected that
16:59:49 mriedem https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2332
17:00:03 mriedem melwitt: there are like 5 different methods in the base network api like that
17:00:19 mriedem melwitt: and of course some are only neutron and some are only nova-net
17:00:20 melwitt guh, what the hell
17:00:54 mriedem https://github.com/openstack/nova/blob/master/nova/network/api.py#L529
17:01:52 melwitt sigh
17:10:33 swebster ^ Interesting that the neutron cleanup doesn't start a migration. This actually causes you to be completely screwed when unshelving with PCI devices. I fixed a symptom of that with https://review.openstack.org/#/c/453938
17:14:09 mriedem hmm, yeah, so we don't unbind and we don't terminate volume connections on shelve offload,
17:14:16 mriedem so unshelve is just....
17:14:19 mriedem roll the dice
17:14:40 mriedem plus on unshelve i believe we'll also create a new volume, but would have to check that
17:14:45 mriedem if it's bfv
17:17:28 openstackgerrit Steven Webster proposed openstack/nova master: Fix mitaka online migration for PCI devices https://review.openstack.org/456397
17:18:21 mriedem yeah so on unshelve, we prep block devices but pass do_check_attach=False, because the volume is still in-use b/c it's still attached to the instance, by design,
17:18:29 mriedem we make a new connection on the new host,
17:18:37 mriedem and if volume['attach_status'] == "detached": is False,

Earlier   Later