Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-13
14:29:37 mordred I would actually think that just adding a nova-specific openstack-tox-py35 variant with some additional irrelevant-files added would work
14:29:51 mordred I'm assuming y'all have tried that already?
14:30:41 bauzas mriedem: +W'd with a comment asking for a followup
14:32:58 mriedem bauzas: thanks
14:33:03 mriedem i replied to more of the inline stuff too
14:38:51 mriedem mordred: already talked about that above, and the implications of doing so
14:39:01 mriedem mordred: tl;dr is i know it's trivial to do, just time consuming
14:39:07 mriedem given backports to stable and changes to project-config
14:39:40 mriedem it would help e-r to have project-specific tox jobs again http://status.openstack.org/elastic-recheck/data/integrated_gate.html#openstack-tox-py35
14:42:57 Shilpa mriedem: Hi, i was going thorugh https://review.openstack.org/#/c/511965/1 >> Spec for volume-backed flavors, any reason why workflow is -1 here
14:43:17 mordred mriedem: I tink we're collecting enough metadata so that elastic recheck could know job + project - we sohuld probably update it to use the data
14:46:39 mriedem Shilpa: because it's complicated and mostly a brain dump to docs for something we've talked about sporadically when we have meetups (PTG, Forum, etc)
14:46:50 mriedem it's not something i'm actively pursuing for Rocky
14:47:21 leakypipes mriedem, mdbooth, superdan: so, question coming from one of our ops teams... is it possible to (live) migrate from a host using ceph for ephemeral disk storage to a host that uses local disk storage (this is temporarily during an upgrade procedure)
14:47:50 superdan leakypipes: with block migration maybe
14:48:05 superdan I'm not an expert there, I'd ask mdbooth when he gets off a call in 13 mins
14:48:12 leakypipes superdan: cool, thx
14:48:28 superdan leakypipes: also please see channel topic
14:48:34 mriedem it's going from an ephemeral ceph to a non-ceph ephemeral?
14:48:43 Shilpa mriedem: ok, one more thing pl confirm, specs not talikng @ to have root_gb=0 for flavor `volume_backed=True`
14:49:00 mriedem i know our live migration job tests ceph with ephemeral imagebackend and with volume-backed
14:49:11 mriedem but it's ceph on both sides, not changing image types for the ephemeral case
14:49:39 mriedem Shilpa: can you rephrase the question?
14:50:04 melwitt mriedem, superdan, leakypipes: just remembered we need to propose forum topics today (deadline is sunday april 15) https://etherpad.openstack.org/p/YVR-nova-brainstorming
14:50:27 melwitt I see cdent already proposed a couple of placement-related ones
14:50:33 superdan mdbooth: I added a thing in there
14:51:16 leakypipes melwitt: ack. (I won't be at the forum, but will try to add items)
14:51:29 mriedem Shilpa: based on https://review.openstack.org/#/c/511965/1/specs/queens/approved/volume-backed-flavors.rst@74 - you couldn't have volume_backed=True and root_gb=0
14:51:34 mriedem because that would result in creating a 0gb vlume
14:51:36 mriedem *volume
14:51:44 melwitt leakypipes: :( to not being there, k thanks
14:51:48 mriedem which i'm pretty sure cinder doesn't allow, volumes have to be at least size>=1
14:51:58 Shilpa mriedem: actually root_gb should be 0 for volume-backed instances (LP bug https://bugs.launchpad.net/nova/+bug/1469179), so here in specs we are marking ``volume_backed=True` for volume-backed instance
14:51:58 openstack Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to Dan Smith (danms)
14:53:16 leakypipes melwitt: a certain money-lending institution isn't getting their Friday dues.
14:53:32 melwitt lol
14:53:34 mriedem Shilpa: then i think you're looking for https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged)
14:53:44 leakypipes there she is :)
14:54:14 mriedem Shilpa: feel free to comment on the spec as a reminder, but as noted, it's not something i'm actively pursuing
14:56:52 Shilpa mriedem: yes iam looking for https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged) , is spec resolves this?
14:59:41 mriedem Shilpa: no, it's unrelated
15:00:10 mriedem Shilpa: think of that spec basically like the 'get me a network' feature in the 2.37 microversion, but like 'get me a volume-backed instance'
15:00:15 mriedem simply the bdm_v2 stuff the user has to do
15:00:18 mriedem *simplify
15:00:40 mriedem and allow operators to easily define volume-backed flavors globally
15:01:34 mriedem Shilpa: btw, root_gb=0 doesn't mean volume-backed per se, https://developer.openstack.org/api-ref/compute/#create-flavor
15:01:42 mriedem "The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
15:02:16 mriedem root_gb=0 and server.image_id = '' would definitely indicate volume-backed
15:02:29 jgwentworth oh, that reminds me of a bug I wanted to ask people about
15:03:42 mriedem superdan: heh you'll like this https://bugs.launchpad.net/nova/+bug/1763039
15:03:42 openstack Launchpad bug 1763039 in OpenStack Compute (nova) "evacuate instance documentation not mentioning host-evacuate" [Undecided,New]
15:04:25 jgwentworth this one, issues with 0 GB disk flavor + image-based instance https://bugs.launchpad.net/nova/+bug/1758278
15:04:25 openstack Launchpad bug 1758278 in OpenStack Compute (nova) "disk_available_least become a negative value unexpectedly" [Undecided,New]
15:05:06 superdan mriedem: guh
15:05:11 mriedem jgwentworth: i think that might be a duplicate of one that mnaser reported, looking
15:05:26 jgwentworth does anyone understand that? ^ I keep getting confused about what actually happens when you do image-based + 0 GB disk
15:05:49 corvus mriedem: how about you just stop using the template that adds the unit test jobs and just add them to your project stanza in repo with your own irrelevant file matchers. done.
15:06:04 mriedem corvus: that's what i said we could do above
15:06:12 jgwentworth mriedem: I saw that too a second ago and wondered if it's the same thing
15:06:52 corvus mriedem: i missed what's complicated about that
15:07:00 mriedem corvus: it's not complicated,
15:07:10 corvus ok i'm poor at reading scrollback :)
15:07:15 openstackgerrit Merged openstack/nova master: tests: Fix how context managers are mocked https://review.openstack.org/561190
15:07:20 mriedem it's just we also have to backport that to all stable branches before we can remove the openstack-python-jobs template usage from project-config
15:07:31 mriedem again, not complicated, just tedious
15:07:48 openstackgerrit Merged openstack/nova master: Update link of metadata https://review.openstack.org/561114
15:08:45 corvus mriedem: okay, yeah. maybe worth the effort though? :) it's a one-time cost.
15:09:59 Shilpa mriedem: thank you for clarification, earlier thought that volume-backed flavors spec and https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged) has relation.
15:10:24 corvus mriedem: we did come up with some ways of maybe doing something sensible with irrelevant-files and project-templates, but it's probably going to be a while till we can implement them.
15:14:19 mriedem corvus: yeah, i've likely already spent more time complaining about this than what it would take to just fix it
15:18:50 mdbooth leakypipes superdan: re live migration non-ceph->ceph there's no fundamental reason it can't work that I can think of. As was mentioned, though, it's not tested, so it's probably broken for reasons I can't think of, which are probably fixable.
15:19:30 openstackgerrit Merged openstack/nova master: Test case: ResourceClass.normalize_name with ß https://review.openstack.org/560092
15:19:42 superdan I would assume that our driver probably tries to do smart things assuming it is shared, which might defeat other things like block migration if it doesn't account for the possibility
15:20:18 mriedem live migration should try to see if it can talk to the dest host over a shared filesystem though,
15:20:28 mriedem which if you're going ceph to non-ceph, will say you can't do that
15:20:32 mriedem so block migration would be required
15:21:12 mdbooth I think the shared test is only for shared instance directory
15:21:16 superdan right
15:21:30 mdbooth The shared block iirc is in imagebackend at the class level
15:21:33 mdbooth So super-hacky
15:21:39 openstackgerrit Merged openstack/nova master: Make ResourceClass.normalize_name handle sharp S https://review.openstack.org/560093
15:21:45 mdbooth So yeah, that could potentially break it.
15:22:27 mdbooth But fundamentally, if we wired it up correctly there's no reason you can't block migration from non-ceph to ceph, or vice versa.
15:22:39 mriedem right i think it should work,
15:22:43 mriedem but there are probably assumptions in the code
15:22:49 superdan yep and that's what I'm saying
15:22:57 superdan I bet it doesn't work.. for stupid reasons
15:23:17 mriedem this is where i'd look https://github.com/openstack/nova/blob/master/nova/virt/libvirt/migration.py#L80
15:23:27 mriedem that updates the guest xml on the source host, but updates the xml intended for the dest host
15:23:29 leakypipes well, they're going to test it. I'll let you know if/what blows up :)
15:23:40 mriedem nothing in ^ indicates it cares about non-volume disks
15:24:04 mriedem this would be the other place to look https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7562
15:24:14 mriedem run on the dest, get the info to pass back to the source to tell it how to migrate it
15:27:56 mdbooth mriedem: Yeah, that's broken for at least the first reason (disk xml isn't updated)
15:29:47 openstackgerrit Chris Friesen proposed openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690
15:30:31 mriedem corvus: finucannot: mordred: heh now i realize the flaw in my logic - the problem isn't in defining our own py27 job for unit tests,
15:30:40 mdbooth mriedem: This came up today: https://review.openstack.org/#/c/533249/ tl;dr support for ip_allocation='none'. By any chance are you aware of any other existing work on this?
15:30:44 mriedem it's that the tempest-full jobs get run on unit test-only patches in nova
15:30:46 superdan kashyap: finucannot: do you guys understand the vhostuser override stuff in this? https://review.openstack.org/#/c/484997/16/nova/virt/libvirt/vif.py line 171
15:30:52 mriedem so we'd have to write our own tempest-full...

Earlier   Later