Earlier  
Posted Nick Remark
#openstack-nova - 2018-11-30
14:37:01 maciejjozefczyk bauzas: I took your logic from https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py to have a marker, thanks btw
14:37:07 bauzas ah ok
14:37:17 bauzas http://goo.gl/MgN7mp is my own dashboard
14:38:23 maciejjozefczyk sean-k-mooney: so how to preserve the order after attaching new interface? if it sorts by VIF.id (that is uuid?)?
14:39:03 sean-k-mooney maciejjozefczyk: actully no you are ok you are build it from the db https://review.openstack.org/#/c/591607/9/nova/network/neutronv2/api.py@2356
14:39:29 maciejjozefczyk sean-k-mooney: about get_vifs_by_instance: ok
14:43:37 sean-k-mooney maciejjozefczyk: so yes _get_ordered_port_list is constuting an orderd port list from the VirtualInterface objects retruned form get_vifs_by_instance and then in _build_network_info_model you are construting a NetworkInfo object containing VIF objects
14:44:00 sean-k-mooney maciejjozefczyk: so ya the logic is correct
14:53:08 maciejjozefczyk thats right :)
14:54:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529
14:54:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
14:54:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
14:56:27 kashyap If someone has time, a refactor that makes your brain less warpy: https://review.openstack.org/#/c/620327/ ("libvirt: Refactor handling of PCIe root ports")
15:07:26 gibi kashyap: +2, thanks!
15:07:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Mention size limit on user data in docs https://review.openstack.org/620700
15:07:39 kashyap gibi: Sweet, thank you, sir.
15:08:14 kashyap That means, then I _really_ need to workout the fix to address the more complex TODO item in the comment.
15:08:54 openstack Launchpad bug 1404867 in OpenStack Compute (nova) queens "Volume remains in-use status, if instance booted from volume is deleted in error state" [Medium,Fix committed] - Assigned to Mohammed Naser (mnaser)
15:08:54 s10 mriedem: We've faced a bug, which is related to https://bugs.launchpad.net/nova/+bug/1404867 . I've written about it in last comment, but I'm not sure, if I should open a new bug about this issue. We can't set quota.recheck_quota=False in our deployments, and some users sometimes ends up with volumes in incorrect status.
15:10:17 mriedem s10: which release? because i'm pretty sure mnaser already fixed that
15:10:33 s10 mriedem: Pike and Queens.
15:11:35 mriedem oh i'm thinking of I64074923fb741fbf5459f66b8ab1a23c16f3303f
15:11:50 mriedem https://review.openstack.org/#/c/544748/
15:12:02 s10 mriedem: this issue is almost fixed, but still can happen, if this exception happens https://github.com/openstack/nova/blob/stable/rocky/nova/conductor/manager.py#L1308
15:12:05 mriedem s10: open a new bug, you can refer to ^ as being related but a different failure
15:12:44 s10 mriedem: because after this exception instance is not being buried in cell0
15:13:06 mriedem lyarwood: bauzas: this upgrade-impacting backport needs review https://review.openstack.org/#/c/610974/
15:13:12 mriedem s10: yeah i get it
15:13:16 mriedem just report a new bug
15:13:22 bauzas mriedem: on a meeting but looking
15:14:18 mriedem bauzas: while you're on the call, you want to ask mdbooth if he'll be around the next two weeks to respond to review comments on https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers if it's in a runway?
15:14:22 s10 mriedem: ok, I will report.
15:14:30 mriedem because it's next in the queue
15:14:32 bauzas mriedem: I can try to ask :)
15:14:49 mriedem i know you can do this!
15:14:53 mriedem be strong!
15:15:16 bauzas I'm a weak guy
15:15:32 mriedem you're a bear
15:15:37 mriedem big ol papa bear
15:15:50 bauzas maybe more a Winnie the Bear one
15:16:24 bauzas on another point, I finally found how to fix my specs dashboard :)
15:16:45 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement perf check https://review.openstack.org/621180
15:18:59 mdbooth mriedem bauzas: I'm not working Mondays for the next few weeks, but Tuesday->Friday I can prioritise responding to reviews.
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 leakypipes bauzas: there can be only one Winnie the Bear... https://twitter.com/jaypipes/status/1012713615097335809
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 s10 mriedem: I've written https://bugs.launchpad.net/nova/+bug/1806064
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 cdent vast mental resources are being spent on this. it's so weird to me
15:32:33 mdbooth leakypipes: Yeah, or moving stuff from (non-openstack) VMware to Openstack.
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 mdbooth And 50 are powered off.
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: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 mriedem there was a lot of chatter in wechat one night about how openstack didn't have this import feature
15:38:46 leakypipes mdbooth: oh, we have a whole friggin zoo of pandas.
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.

Earlier   Later