Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-30
15:30:23 mdbooth P2V == physical to virtual
15:30:28 s10 mriedem: I've written https://bugs.launchpad.net/nova/+bug/1806064
15:30:28 openstack Launchpad bug 1806064 in OpenStack Compute (nova) "Volume remains in attaching/reserved status after TooManyInstances exception in nova-conductor" [Undecided,New]
15:30:28 leakypipes bauzas: there can be only one Winnie the Bear... https://twitter.com/jaypipes/status/1012713615097335809
15:30:37 mdbooth leakypipes: It's pretty much the definition of not cloudy.
15:30:59 mdbooth But people want to do it, so I ask the question...
15:31:24 bauzas leakypipes: I just can't not heart this
15:31:41 leakypipes mdbooth: by "two different hypervisors", you don't mean migration, you mean like VMWare to KVM or something like that?
15:31:42 bauzas <3
15:31:50 leakypipes bauzas: :)
15:31:58 mdbooth leakypipes: E.g. Move a legacy workload from a physical server to an openstack Panda.
15:32:33 mdbooth leakypipes: Yeah, or moving stuff from (non-openstack) VMware to Openstack.
15:32:33 cdent vast mental resources are being spent on this. it's so weird to me
15:32:45 bauzas someday, there will be Dogtivities at Summit
15:32:49 cdent monetary and stuff
15:32:54 cdent dogtivities++
15:33:17 mriedem s10: thanks; should be pretty easy to write a functional regression test for that scenario.
15:33:32 jackding gibi: yes the bp io-semaphore-for-concurrent-disk-ops is done
15:33:54 gibi jackding: thank. meanwhile mriedem already marked the bp completed
15:34:13 gibi jackding: so the administration is also done :)
15:34:30 leakypipes mdbooth: I think what you're describing sounds a little like Ironic's node import functionality.
15:34:33 jackding gibi: mriedem: thanks :)
15:34:53 leakypipes mdbooth: but what mnaser mentioned about just adding the image to glance makes some sense to me.
15:35:37 mnaser also if you use bfv (this might be a bit more of a specific use case scenario)
15:35:39 mnaser you can totally do this too
15:35:43 mdbooth Glance isn't a great fit, because we never want to create 2 of these things. They're volume backed.
15:36:04 mdbooth Thing is when you're mass importing 1000 of these things.
15:36:14 kashyap sean-k-mooney: I'm reading this spec that you reviewed, and the "problem description" is not clear to me at all: https://review.openstack.org/#/c/620959/1/specs/stein/approved/cpu-model-selection.rst
15:36:14 mdbooth And 50 are powered off.
15:36:27 mnaser cinder manage volumes and boot the ones that are running only?
15:36:31 leakypipes mdbooth: we have this awful register/import script that does similar things for non-OpenStack baremetal workloads... basically making OpenStack aware of them, creating records in Nova/Ironic, etc and we have this awful hack called "--no-reimage" that prevents Ironic from cleaning/imaging the imported nodes (and prevents nova from trying to schedule to them)
15:36:40 mdbooth You don't want those 50 to be 'special'. You want them to be exactly the same as all the rest, just not running.
15:36:44 leakypipes mdbooth: so, in short, I'm familiar with the ask at least ;)
15:37:11 kashyap sean-k-mooney: I'll respond on that change once I read through it
15:37:15 mdbooth leakypipes: We're copying the data into a VM so the physical can be retired.
15:37:41 leakypipes mdbooth: understood. I'm saying we have a similar-ish use case that we've got nasty-hacks for :) so I feel your pain.
15:38:15 mdbooth leakypipes: Interesting that we're not the only one creating pandas from legacy workloads.
15:38:31 leakypipes mdbooth: having some sort of "register this thing as a VM but don't do anything with it (yet)" would be useful for getting data/systems into OpenStack I think.
15:38:32 mriedem pretty sure there are lots of products that have something that does something like this,
15:38:46 leakypipes mdbooth: oh, we have a whole friggin zoo of pandas.
15:38:46 mriedem there was a lot of chatter in wechat one night about how openstack didn't have this import feature
15:38:52 mriedem especially for DR scenarios
15:39:18 cdent DR is the context I keep hearing it too
15:39:23 mriedem e.g. operator lost the nova server data, but had the hypervisor/ovs/volume info and just wanted to recreate the records
15:39:52 leakypipes well, that's just... well, ewww. but yeah I can kinda see that.
15:39:59 mnaser i remember that discussion
15:40:03 mnaser it was in the scope of someone's database blowing up
15:40:09 mriedem yes
15:40:10 mnaser and now everything was running but no records for anything
15:40:12 leakypipes (ewww == "guh, you should have a backup of your data")
15:40:26 mdbooth The way our v2v works is we create an ephemeral conversion instance, create a volume, the instance connects out to tools on the legacy hypervisor/physical and copies data to the volume. Then it does unspeakable hacks to it.
15:40:27 mriedem and the majority of replies were either "openstack should totally be able to fix that for you!" to "why don't you backup your database dummy"
15:40:43 leakypipes mriedem: :)
15:40:50 mdbooth Then we throw away the conversion instance and create a new one for the migrated workload, using bfv.
15:40:54 leakypipes mriedem: I think you know where I stand on that. :P
15:41:26 mnaser i mean we can just say keep the volume and boot that when you need it
15:41:33 leakypipes mriedem: then again, there's a reason that the mysql command line client has a --i-am-a-dummy option.
15:41:35 mnaser but i also dont think that is a really trivial way for users
15:41:50 mnaser leakypipes: hah, except only people who are advanced users know about it... :p
15:41:57 leakypipes mnaser: I know right? :)
15:42:22 mdbooth mnaser: Right, but that means you need to keep that metadata around until you want to boot it at some unspecified time. I can understand why they don't like that solution.
15:42:39 mriedem beggars can't be choosers
15:42:43 mnaser mdbooth: yeah, that's the only reason that i feel like this might make value i guess
15:42:47 mriedem well, unless they are beggars with tons of cash
15:43:03 mnaser but i also dont think it's a trivial change given the whole logic of nova boot is to boot an instance
15:43:06 leakypipes (in case people thought I was joking... https://www.percona.com/blog/2017/03/06/mysql-i-am-a-dummy/)
15:43:10 mdbooth mriedem: They have *some* cash :)
15:43:41 mriedem mnaser: +1 to that
15:44:42 mriedem this might be a shocker, but given our current review rate to bp ratio, i won't hold my breath that this is something we're going to seriously consider soon, especially given we're just now getting deployments upgrading to the big changes we've worked on the last 2 years and they are having problems with them that we're trying to solve
15:44:54 mdbooth mnaser: It looked technically simple enough if we pass a flag in to not boot. I think the change in the libvirt driver, at least, would be relatively small.
15:45:11 mdbooth mriedem: ack. That's exactly why I'm not jumping on this.
15:45:38 mriedem you're talking about the power_on flag right? we use that to keep a stopped vm shutoff during cold migration
15:45:43 mnaser would it? dont we have to shortcircuit the whole: plug port, start up paused, wait for notification, resume thing
15:46:02 mriedem we already have plumbing to not wait for the vif plug if we didn't power on the vm
15:46:10 mnaser ah okay
15:46:17 mriedem it was one of my first big bug fixes in nova
15:47:04 mnaser https://github.com/openstack/nova/commit/9e7c7706a76ad76612ba75314d436a8ba419a3eb
15:47:15 mnaser my amazing nova start
15:48:50 leakypipes :)
15:51:39 mnaser btw
15:51:44 mnaser we have 2 more releases to go
15:51:44 mnaser https://review.openstack.org/#/c/619352/
15:52:09 mnaser not that i run pike but it'd be nice to flush it out
15:59:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910
16:00:54 mriedem mnaser: not sure about your thoughts on a nova-status upgrade check for ^
16:01:14 mriedem to see if (1) you have root_gb=0 flavors and (2) your policy checks out for those
16:01:19 mriedem and dump a warning if not
16:01:52 mriedem i posted to the ML, but likely no one has read it, or grokked it, or cares because they aren't upgraded to that point of caring yet
16:02:47 mriedem checking the policy would be kind of tough though if there is a custom rule configured
16:03:08 mnaser mriedem: i saw it and mentally responded, i should write up a reply
16:03:34 mnaser i'd like to warn against it but also i feel like it might break upgrade tooling in a way
16:03:57 mnaser i guess it's about trying to see it as "behavioural change" vs "bug fix"
16:04:39 mnaser i wouldn't want to see a warning because my cloud is operating as expected.. maybe a warning in stable/rocky though?
16:08:09 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Add regression test for bug #1764883 https://review.openstack.org/621199
16:08:09 openstack bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,Fix released] https://launchpad.net/bugs/1764883 - Assigned to Lee Yarwood (lyarwood)
16:08:09 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: compute: Ensure pre-migrating instances are destroyed during init_host https://review.openstack.org/621200
16:12:58 mriedem mnaser: by operating as expected, you mean you have 0 disk flavors but allow non-admins to use them intentionally even if they aren't booting from volume?
16:13:33 mriedem btw, this is another area where https://review.openstack.org/#/c/511965/ would help
16:13:44 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Update docs for _destroy_evacuated_instances https://review.openstack.org/621203
16:13:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Add regression test for bug #1764883 https://review.openstack.org/621204

Earlier   Later