| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-30 | |||
| 15:19:43 | bauzas | so, #1 I fixed my dashboard, #2 I have less downstream tasks to do, #3 there are a huge number of specs left to review | |
| 15:19:52 | bauzas | good news, I'll sharpen my pen | |
| 15:21:59 | mriedem | mdbooth: ok. i had some comments at one point on one of the changes in that blueprint which was merged in rocky (i think) and i don't think i ever heard back. i'll try to dig that up. | |
| 15:22:09 | mriedem | i may or may not be grinding an axe because of it | |
| 15:22:47 | mriedem | anyway, your bp is in the runways queue now | |
| 15:22:48 | mriedem | good luck | |
| 15:23:25 | mdbooth | mriedem: I rebased and addressed all prior feedback a few weeks back, so hopefully all good. | |
| 15:23:55 | mriedem | i meant this i think https://review.openstack.org/#/c/528362/ | |
| 15:27:00 | coreycb | sean-k-mooney: do you recall if the stestr change to stable/pike was supposed get reverted? | |
| 15:29:30 | leakypipes | mdbooth: what is "a V2V workflow"? | |
| 15:29:55 | mdbooth | leakypipes: Oops, jargon. | |
| 15:30:12 | mdbooth | leakypipes: Moving workloads between 2 different hypervisors | |
| 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 | |