Posted	Nick	Remark
#openstack-nova - 2018-06-28
09:02:56	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267
09:02:57	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847
09:02:58	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
09:02:59	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459
09:03:00	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
09:18:08	quiquell|rover	Hello, looks like we no longer have the 'certs' attribute at nova client ?
09:18:10	quiquell|rover	https://docs.openstack.org/python-novaclient/pike/reference/api/v2/certs.html
09:18:42	openstackgerrit	Dinesh Bhor proposed openstack/nova master: PCPU: Define numa dedicated CPU resource class https://review.openstack.org/561770
09:18:43	openstackgerrit	Dinesh Bhor proposed openstack/nova master: NUMACell, InstanceNUMACell: Adopt 'PCPU' changes https://review.openstack.org/576021
09:18:44	openstackgerrit	Dinesh Bhor proposed openstack/nova master: Report PCPU to placement https://review.openstack.org/577038
09:18:45	openstackgerrit	Dinesh Bhor proposed openstack/nova master: Virt driver: Build guest xml https://review.openstack.org/577372
09:19:16	quiquell|rover	https://review.openstack.org/#/c/532974/
09:41:14	openstackgerrit	sahid proposed openstack/nova stable/queens: add mtu to libvirt xml for ethernet and bridge types https://review.openstack.org/578010
10:18:50	openstackgerrit	Gaudenz Steinlin proposed openstack/nova master: Ignore some updates from virt driver https://review.openstack.org/523006
10:28:30	openstackgerrit	Merged openstack/nova stable/queens: Make nova list and migration-list ignore down cells https://review.openstack.org/578152
11:31:08	openstackgerrit	Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325
11:53:22	ShilpaSD	lyarwood: Hi
11:55:22	openstackgerrit	Lee Yarwood proposed openstack/nova master: libvirt: Add missing encryption_secret_uuid tests for pre_live_migration https://review.openstack.org/540679
11:55:27	lyarwood	ShilpaSD: hey
11:55:53	ShilpaSD	lyarwood: i was going through your comment on >> https://review.openstack.org/#/c/550172/4/lib/nova
11:57:58	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Use nova.test.TestingException https://review.openstack.org/575012
11:58:22	openstackgerrit	Takashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers.inc https://review.openstack.org/529520
11:58:23	ShilpaSD	lyarwood:vnc v1.0.0 has renamed vnc_auto.html to 'vnc_lite.html'
11:58:46	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in sec group test and functional tests https://review.openstack.org/576751
11:59:13	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Update admin/flavors document https://review.openstack.org/573063
12:00:19	ShilpaSD	lyarwood: so this change is require to
12:00:19	ShilpaSD	Bump noVNC to 1.0.0
12:01:12	lyarwood	ShilpaSD: which change?
12:01:44	lyarwood	ShilpaSD: oh the conditional, yeah we just need to point to vnc_lite.html when building from source
12:02:08	lyarwood	ShilpaSD: packages should hopefully provide a symlink between the two, at least that's my plan for Fedora
12:07:08	ShilpaSD	lyarwood: please elaborate 'packages should hopefully provide a symlink between the two', guide me to understand this
12:23:36	openstackgerrit	Merged openstack/nova master: Make nova-lvm run in check on libvirt changes and compute API tests https://review.openstack.org/569149
12:23:55	openstackgerrit	Merged openstack/nova master: Mention server status in api-ref when rebuild https://review.openstack.org/576438
12:29:35	openstackgerrit	Lee Yarwood proposed openstack/nova master: Add regression test for bug #1764883 https://review.openstack.org/562072
12:29:35	openstack	bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,In progress] https://launchpad.net/bugs/1764883 - Assigned to Lee Yarwood (lyarwood)
12:29:35	openstackgerrit	Lee Yarwood proposed openstack/nova master: compute: Ensure pre-migrating instances are destroyed during init_host https://review.openstack.org/562284
12:30:16	lyarwood	argh whitespace
12:34:58	openstackgerrit	Lee Yarwood proposed openstack/nova master: Add regression test for bug #1764883 https://review.openstack.org/562072
12:34:58	openstack	bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,In progress] https://launchpad.net/bugs/1764883 - Assigned to Lee Yarwood (lyarwood)
12:34:59	openstackgerrit	Lee Yarwood proposed openstack/nova master: compute: Ensure pre-migrating instances are destroyed during init_host https://review.openstack.org/562284
12:37:29	openstackgerrit	wu.chunyang proposed openstack/python-novaclient master: Add release note link in README https://review.openstack.org/578664
12:41:20	andrewbogott	This isn't exactly a dev question, but it's one that only a nova-developer can answer: what records in the nova database constitute the complete state of a VM? I need to copy VMs between regions and I expected that a simple copy of the 'instance' record would do the job, but that's getting me exceptions about my new VM being an orphan. Are there other records in other tables I need to be copying?
12:54:48	openstackgerrit	Yikun Jiang (Kero) proposed openstack/nova master: Add rules column to instance_group_policy table. https://review.openstack.org/560832
12:54:49	openstackgerrit	Yikun Jiang (Kero) proposed openstack/nova master: Add InstanceGroupPolicy object https://review.openstack.org/573628
13:16:08	efried	andrewbogott: I'm not an expert in this space, but attempting to copy an instance by copying just the database info is not likely to work, even if you were able to identify all the various tendrils in all the various tables.
13:17:07	andrewbogott	efried: 'not likely to work' is my prediction as well, but I'm a bit desperate :)
13:17:22	efried	andrewbogott: The data isn't the instance - it's just stuff nova uses to keep track of the real thing, which is an artifact of the hypervisor.
13:18:00	andrewbogott	efried: oh yeah, I'm also copying the VM files as well. I just need to tell nova 'congrats, you have a new VM, here it is'
13:18:11	andrewbogott	which I don't think there's an API call for
13:18:22	efried	andrewbogott: Have you tried snapshot?
13:18:57	efried	Depending how deeply you want to "copy" the VM...
13:19:23	andrewbogott	there are a few problems with snapshot — one issue is that as far as I can tell that will lose any copy-on-write compactness that my existing VMs have
13:19:49	efried	andrewbogott: Can I assume you're using libvirt?
13:20:30	andrewbogott	but, the big picture here is that I'm doing a nova-network -> neutron migration. If I can insert one VM into my new region, then I can swap an entire hypervisor from the nova-network region to the neutron region just by copying database records. That's my ultimate goal.
13:20:38	andrewbogott	yep, libvirt, kvm
13:22:46	efried	andrewbogott: I wonder if the CERN folks might be able to help you here. I want to say they are in the process of transitioning from nova-network, so they may have trodden this ground already. tssurya, you around?
13:23:05	tssurya	efried: yes
13:23:08	tssurya	reading the convo
13:23:12	efried	tssurya: thanks
13:23:16	andrewbogott	thanks efried
13:23:38	efried	andrewbogott: I suspect the CoW thing is going to be a separate headache, though. How did you plan to clone the disk across?
13:24:36	andrewbogott	just rsync
13:24:45	andrewbogott	(plus rsyincing the base image so the backing files are there)
13:25:12	efried	andrewbogott: BTW, the obvious answer is to live migrate your instances; I assume the "different region" thing is what's stopping you there?
13:25:17	andrewbogott	Cloning the files is a solved problem on my end — I already do that to cold migrate instances between hypervisors (within a single region), have a working script for that
13:25:30	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646
13:25:30	andrewbogott	right, different regions
13:25:31	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647
13:25:32	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819
13:25:33	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674
13:25:34	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675
13:25:35	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043
13:25:36	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326
13:25:38	andrewbogott	and I don't have live migration, since, no shared storage
13:26:38	efried	andrewbogott: It sounds like a) you don't mind a bit of downtime, and b) you're not opposed to doing the storage migration manually.
13:27:13	efried	andrewbogott: So can't you just create a new instance at the target, using the same flavor as the original, and then replace its disk?
13:27:48	andrewbogott	yeah — downtime was unavoidable, and doing a cross-region migration of VMs seemed safer than trying to do a big 'upgrade our whole cloud to neutron in one go' in place upgrade because there was no guarantee of what we'd end up with.
13:28:00	andrewbogott	efried: that has certainly crossed my mind :)
13:28:39	tssurya	efried: not in my scope, belmoreira is the guy who did this at CERN :)
13:28:48	tssurya	sorry
13:28:49	efried	tssurya: Okay, thank you for looking.
13:29:54	efried	andrewbogott: I'm a bit rusty on this - do you remember whether you need to specify a flavor when you spawn an instance from a snapshot?
13:30:36	andrewbogott	efried: this is a bit hard to explain… my current test case involves copying a VM. but my future game plan won't actually involve copying any files. Rather, I'll shut down a single hypervisor, change that hypervisor's region, insert all the VMs from that hypervisor into the new region's DB, and then bring up the hypervisor.
13:30:53	andrewbogott	The create-new-VM and then clobber with old-vm will work for the one-off case but it's less obvious how to adapt that to the 'whole hypervisor at once' case
13:31:13	andrewbogott	whereas the transition from the one-VM to batch-VM is obvious in the 'create from scratch' approach
13:31:19	andrewbogott	(hope I'm making sense here)
13:32:25	efried	andrewbogott: You mean the physical host is going to be the same before & after, just brought up in a different region?
13:32:33	andrewbogott	right, that's the idea
13:33:52	andrewbogott	hence, wanting a way to duplicate nova's knowledge of a VM from one region to another
13:34:06	andrewbogott	(and then I'll have to plumb them up with Neutron)
13:34:29	efried	andrewbogott: Then it sounds like what you actually want to do is bring down the service and simply change the region associated with the existing instances in the database...
13:34:42	efried	as opposed to actually moving data.
13:35:06	andrewbogott	'region' = separate nova deploy with a separate DB
13:35:10	efried	I'm not familiar with the structure of the database - is the region represented as a field, or are regions whole groups of tables?
13:35:13	efried	okay, that answers that.
13:35:23	efried	So I gotta ask... why are you needing to change regions?
13:35:36	andrewbogott	(Except for the API which has its own multi-region db)
13:35:45	andrewbogott	the old region uses nova-network, the new one neutron
13:36:55	andrewbogott	the two can't coexist in a single region as far as I can tell
13:38:03	efried	Maybe I still don't get it. Instead of migrating your existing region from nova-network to neutron, you want to create a new region using neutron and then move your instances from the old to the new.

Earlier   Later