Monday, 2018-10-08

*** swamireddy has joined #openstack-nova00:01
*** swamireddy has quit IRC00:01
*** swamireddy has joined #openstack-nova00:01
openstackgerritBrin Zhang proposed openstack/nova master: Add compute version 36 to support ``volume_type``  https://review.openstack.org/57936000:21
*** tbachman has joined #openstack-nova00:23
openstackgerritSam Morrison proposed openstack/nova master: WIP: Allow ability for non admin users to list all flavors.  https://review.openstack.org/60847400:25
*** hoangcx has joined #openstack-nova00:53
*** alex_xu has joined #openstack-nova01:11
*** erlon has joined #openstack-nova01:15
*** yikun has joined #openstack-nova01:16
*** wxy-xiyuan has joined #openstack-nova01:17
*** tommylikehu has joined #openstack-nova01:31
*** jiapei has joined #openstack-nova01:39
*** hongbin has joined #openstack-nova01:48
*** mhen has quit IRC01:58
*** mhen has joined #openstack-nova02:00
*** tiendc has joined #openstack-nova02:22
*** dave-mccowan has quit IRC02:30
openstackgerritTao Li proposed openstack/nova master: Cleanup the instance when MessageDeliveryFailure exception  https://review.openstack.org/60850003:16
*** kaisers has quit IRC03:56
*** kevinbenton has quit IRC04:00
*** kevinbenton has joined #openstack-nova04:00
*** kaisers has joined #openstack-nova04:05
*** kaisers has quit IRC04:12
*** kaisers has joined #openstack-nova04:19
*** tetsuro has joined #openstack-nova04:25
*** hoangcx has quit IRC04:27
*** hongbin has quit IRC04:32
*** pooja_jadhav has joined #openstack-nova04:33
*** tetsuro has quit IRC04:37
*** tetsuro has joined #openstack-nova04:38
*** janki has joined #openstack-nova04:54
*** sheel has joined #openstack-nova05:11
*** tommylikehu has quit IRC05:27
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: Handle missing marker during online data migration  https://review.openstack.org/60857205:38
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: Don't emit warning when ironic properties are zero  https://review.openstack.org/60857305:41
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: Replace usage of get_legacy_facade() with get_engine()  https://review.openstack.org/60857405:41
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: Time how long select_destinations() takes in conductor  https://review.openstack.org/60857505:41
*** ratailor has joined #openstack-nova05:53
*** mikeoschen has joined #openstack-nova06:16
*** tetsuro has quit IRC06:22
*** tetsuro has joined #openstack-nova06:25
*** ratailor has quit IRC06:28
*** mikeoschen has quit IRC06:29
*** mrsoul has joined #openstack-nova06:31
*** ratailor has joined #openstack-nova06:35
*** maciejjozefczyk has quit IRC06:40
*** giblet is now known as gibi06:50
gibigood morning Nova06:50
*** slaweq_ has joined #openstack-nova07:12
openstackgerritMerged openstack/nova stable/rocky: Not set instance to ERROR if set_admin_password failed  https://review.openstack.org/60816507:16
openstackgerritTao Li proposed openstack/nova master: Cleanup the instance when MessageDeliveryFailure exception  https://review.openstack.org/60850007:20
*** rcernin has quit IRC07:21
*** helenafm has joined #openstack-nova07:23
*** ttsiouts has joined #openstack-nova07:23
*** moshele has joined #openstack-nova07:26
*** jangutter has joined #openstack-nova07:29
openstackgerritJan Gutter proposed openstack/os-vif master: Implement generic representor offload port profile  https://review.openstack.org/60844807:30
*** jangutter_ has joined #openstack-nova07:32
*** jangutter_ has quit IRC07:32
*** jangutter_ has joined #openstack-nova07:33
*** ralonsoh has joined #openstack-nova07:34
*** jangutter has quit IRC07:36
*** ttsiouts has quit IRC07:39
bauzasgood morning Nova07:41
openstackgerritJan Gutter proposed openstack/os-vif master: Implement generic representor offload port profile  https://review.openstack.org/60844807:43
*** jpena|off is now known as jpena07:44
*** ttsiouts has joined #openstack-nova07:57
*** owalsh_ is now known as owalsh08:03
*** tssurya has joined #openstack-nova08:15
*** finucannot is now known as stephenfin08:15
*** belmoreira has joined #openstack-nova08:17
*** maciejjozefczyk has joined #openstack-nova08:18
openstackgerritBrin Zhang proposed openstack/nova master: Add compute API version for when a ``volume_type`` is requested  https://review.openstack.org/60557308:23
openstackgerritJan Gutter proposed openstack/os-vif master: Implement generic representor offload port profile  https://review.openstack.org/60844808:24
*** mikeoschen has joined #openstack-nova08:40
*** hoangcx has joined #openstack-nova08:49
openstackgerritMartin Midolesov proposed openstack/nova master: vmware:PropertyCollector for caching instance properties  https://review.openstack.org/60827809:01
openstackgerritMark Goddard proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero  https://review.openstack.org/60861109:02
*** alexchadin has joined #openstack-nova09:04
*** alexchadin has quit IRC09:15
openstackgerritBrin Zhang proposed openstack/nova master: Add compute API version for when a ``volume_type`` is requested  https://review.openstack.org/60557309:19
naichuansbauzas: Hi, Sylvain, do you have the time to review vgpu BP? Matt think it is better to be reviewed by you first. https://blueprints.launchpad.net/nova/+spec/vgpu-stein09:26
*** tetsuro has quit IRC09:29
openstackgerritBrin Zhang proposed openstack/nova master: Add microversion 2.67 to support volume_type  https://review.openstack.org/60639809:32
openstackgerritStephen Finucane proposed openstack/nova master: Make 'plugin' a required argument for '_get_vif_instance'  https://review.openstack.org/60827909:35
*** dtantsur|afk is now known as dtantsur09:49
*** sean-k-mooney has joined #openstack-nova10:01
*** ttsiouts has quit IRC10:01
*** vrobert has joined #openstack-nova10:04
*** jpena is now known as jpena|off10:07
bauzasnaichuans: sure, I'll try10:09
*** janki has quit IRC10:12
*** janki has joined #openstack-nova10:13
*** moshele has quit IRC10:26
*** jaosorior has joined #openstack-nova10:26
vrobertHi, I realized my nova-api-os-compute (17.04.dev1) uwsgi processes are slowing down if I get the console logs from a VM in horizon for example or running tempest test: tempest.api.compute.admin.test_hypervisor.HypervisorAdminTestJSON.test_get_hypervisor_uptime. I found that nova-compute process on my compute nodes just doing epoll: do_poll (eventlet/hubs/epolls.py:62). Is it a normal behavior?10:33
vroberthttp://paste.openstack.org/show/731677/10:33
*** rcernin has joined #openstack-nova10:35
*** dpawlik has joined #openstack-nova10:37
*** gvrangan has joined #openstack-nova10:43
*** slaweq_ is now known as slaweq10:44
*** slaweq is now known as dpawlik_10:45
*** dpawlik_ is now known as slaweq10:45
*** Luzi has joined #openstack-nova10:46
*** tbachman has quit IRC10:47
*** moshele has joined #openstack-nova10:49
*** moshele has quit IRC10:59
*** moshele has joined #openstack-nova11:00
*** erlon has quit IRC11:08
*** gvrangan has quit IRC11:08
openstackgerritMerged openstack/os-traits master: Removed older version of python added 3.5  https://review.openstack.org/60637011:08
openstackgerritsean mooney proposed openstack/os-vif master: Add abstract OVSDB API  https://review.openstack.org/47661211:10
*** psachin has joined #openstack-nova11:12
*** mdbooth_ has joined #openstack-nova11:15
mdbooth_I'm seeing a weird py35 db migrations failure in unit tests. Is everybody else seeing it, too?11:16
*** rcernin has quit IRC11:17
*** ratailor has quit IRC11:20
*** mdbooth_ is now known as mdbooth11:22
*** jamesdenton has quit IRC11:30
openstackgerritMerged openstack/python-novaclient master: Update the contributor guide  https://review.openstack.org/60692611:31
*** adrianc has joined #openstack-nova11:33
*** rpittau has joined #openstack-nova11:35
*** ralonsoh has quit IRC11:35
*** adrianc has quit IRC11:38
sean-k-mooneymdbooth: havnt run them lately. i can try check what tests?11:38
*** mdbooth has quit IRC11:43
*** mdbooth has joined #openstack-nova11:43
*** ralonsoh has joined #openstack-nova11:45
sean-k-mooneydamb moxs is kindof obnoxious when it comes to letting you know its depercated in the tox output.11:47
sean-k-mooneymdbooth: i dont have py35 installed but tox -e py36 -- db passed with master11:47
*** mdbooth has quit IRC11:48
*** belmorei_ has joined #openstack-nova11:48
*** belmoreira has quit IRC11:51
*** vrobert has left #openstack-nova11:53
*** sabomia has joined #openstack-nova11:54
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222611:57
*** maciejjozefczyk has quit IRC12:00
*** mdbooth has joined #openstack-nova12:07
*** mdbooth_ has joined #openstack-nova12:09
*** mdbooth has quit IRC12:09
*** mdbooth_ is now known as mdbooth12:09
mdboothsean-k-mooney: Sorry, disconnected. Failures in CI. I can't reproduce locally.12:09
mdboothMy guess is upstream pip snafu12:09
*** sabomia has quit IRC12:09
sean-k-mooneyah ok12:10
*** ttsiouts has joined #openstack-nova12:14
mdboothSo, 158 hits on that error in the last 2 days12:18
mdboothNothing before Saturday12:18
mdboothsean-k-mooney: I added you to https://review.openstack.org/#/c/608416/1 btw ;)12:19
mdboothAs it was your recommendation12:20
*** jamesdenton has joined #openstack-nova12:20
mdboothOh, ^^^ is not true. Kibana was just being slow. There have been a steady stream of hits on that error.12:21
* bauzas 's home is on power inverter, changing the electrical meter12:21
sean-k-mooneynice to have a backup power supply for your house for such things12:23
mdboothbauzas: Cool12:24
bauzasthe previous meter wasn't counting the electricity :p12:24
mdboothAh, so it seems I can't reproduce that error locally because it's auto skipped if mysql isn't configured12:24
jangutter_is there a way to obtain a permalink to a particular comment in gerrit?12:24
mdboothbauzas: Why would you want to change that?12:24
bauzasmdbooth: because I don't want to pay a lot :p12:25
mdboothjangutter_: I think so, yes.12:25
bauzasmdbooth: now the meter is connected https://www.enedis.fr/linky-communicating-meter12:25
mdboothjangutter_: I believe you can link to a particular line of code in a particular patch, anyway.12:25
mdboothjangutter_: So if the comment is against a line of code then I think you can link to that12:25
bauzasmdbooth: so my electrical provider knew that since 23/08 there were 0 Kwh :p12:25
mdboothbauzas: That's just because you were so thrifty12:26
bauzas:)12:26
bauzasI wanted to run a local DC12:26
bauzasbut meh12:26
bauzasI don't have A/C12:26
jangutter_mdbooth: thanks, that's good enough for now, I'll see if I can find out if there's a way to link to a particular message.12:26
*** jangutter_ has quit IRC12:27
*** jangutter has joined #openstack-nova12:27
sean-k-mooneyjangutter: i dont think there is12:27
stephenfinjangutter: If there is, let us know12:28
*** tbachman has joined #openstack-nova12:28
* stephenfin has never figured out how to link to comments in the base patch12:28
janguttersean-k-mooney, in fact, I wanted to ask you about this: https://review.openstack.org/#/c/567148/7/specs/rocky/approved/vrouter-hw-offloads.rst@127 :-p12:28
*** brinzhang has quit IRC12:28
mdboothSo, it looks to me as though the db sync unit test is just occasionally taking too long and timing out12:28
mdboothSo a non-deterministic unit test failure12:28
sean-k-mooneyjangutter: im reviewing https://review.openstack.org/#/c/607610/1/specs/stein/approved/generic-os-vif-offloads.rst currently but happy to talk about that12:29
janguttersean-k-mooney, no worries, when you're done, we can discuss.12:29
sean-k-mooneyjangutter: im just starting so easy to context switch now12:29
mdboothThe test is taking at least 11 minutes12:30
mdboothAnybody know what the timeout is on a single unit test?12:30
mdboothhttp://logs.openstack.org/17/608417/4/check/openstack-tox-py35/5bffa0f/job-output.txt.gz#_2018-10-07_19_04_19_88016712:30
openstackgerritMerged openstack/python-novaclient master: Follow up "Fix up userdata argument to rebuild"  https://review.openstack.org/60780012:31
openstackgerritMerged openstack/python-novaclient master: Update the CLI reference  https://review.openstack.org/60687112:31
sean-k-mooneyjangutter: so the VIFPortProfileOVSRepresentor port profile you wanted to disucss its future?12:32
stephenfinralonsoh: One nit in https://review.openstack.org/#/c/605422/, if you're working on stuff12:32
janguttersean-k-mooney: yeah, basically the "option 2". I.e. what do you think should the abstraction layer be for offloads.12:33
ralonsohstephenfin: I'll submit the modified patch in 5 mins12:33
sean-k-mooneyjangutter: well for a start VIFPortProfileOVSRepresentor today does not contain any offload metadata at all12:33
janguttersean-k-mooney: the current review might be "option 3" then :-p12:33
janguttersean-k-mooney: it contains the PCI address of the repr?12:34
sean-k-mooneyjangutter: it contins info for how to attach the datapane to ovs but no info about offloads12:34
sean-k-mooneyjangutter: that is not offload metadata as far as im concserned12:34
janguttersean-k-mooney: yeah, "plugging" more than "hey set these TC flows".12:34
sean-k-mooneyjangutter: right so is your intent to enable the later or the former12:35
janguttersean-k-mooney: the former, this is to make plugging more generic.12:35
sean-k-mooneywell tc flows is also wrong12:35
janguttersean-k-mooney: been staring at the words "offload" too long so it kinda lost its meaning in my mind.12:36
sean-k-mooneyenable TSO or LSO is a offload12:36
sean-k-mooney* offload metadata12:36
janguttersean-k-mooney: You can also enable or disable TC offloads (and if you want to be really specific, choosing the TC dataplane for OVS, with the offloaded option and then plugging into the resulting SR-IOV VF).12:36
sean-k-mooneyjangutter: yes but TC offloads are not flows e.g. they do not change where a packet is sent12:37
janguttersean-k-mooney: na-ah, they can.12:37
sean-k-mooneytc flows can but its not an offload if send the packet to new york instad of sydney12:38
sean-k-mooneyjangutter: that is what i ment by choosing where its send not is this done in software or hadware12:39
janguttersean-k-mooney: it is an offload if the packet is encapped in a vxlan tunnel before it goes to NY :-p12:39
mdboothFolks, when running gertty for the first time, how many years should you wait for the UI to become responsive?12:39
* mdbooth is wondering if it has just hung12:40
openstackgerritYikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF  https://review.openstack.org/60280412:40
openstackgerritYikun Jiang proposed openstack/nova master: Remove the allocation ratios adjusting logic  https://review.openstack.org/60280512:40
* mdbooth has never managed to get the point where gertty is responsive to user input12:40
sean-k-mooneyjangutter: no it would have been encapulated in software without the offload and set there in ether case12:40
janguttersean-k-mooney: but yeah, I take your point, my semantics is all wrong.12:40
janguttersean-k-mooney: so, I guess there's at least one action point for me: at least s/offloads/plugging modes/ in many respects on the spec.12:41
* mdbooth has no idea what this thing is doing12:41
sean-k-mooneyjangutter: so back to what you acatully want to achive. im fine with haveing a generic port forifle that carries the data plane info for represntors12:42
janguttersean-k-mooney: and keep the OVS representor profile as is?12:42
sean-k-mooneyif we want to allow offload config the it has to be at the port level only.12:42
sean-k-mooneyjangutter: well that depend on if you want to do offload config12:42
sean-k-mooneyor how12:42
sean-k-mooneythe thing is the generic represtor port profile should not know anything about ovs12:43
sean-k-mooneyso if we have to enable an offload in a ovs specific way then that should not be in the generic profile12:43
janguttersean-k-mooney: yep.... you do realise it's making more of Jay's case for him :-p12:44
sean-k-mooneyif we have some traits like thing we can use as an indirection and have the driver interperate that then thats fine12:44
janguttersean-k-mooney: but I understand what you mean, the distinction between offload metadata and plugging modes should be separate.12:45
sean-k-mooneyjangutter: not really i just said storing backend sepcific metadata in the generic represtor profile would not be ok12:45
sean-k-mooneythat include via compostion12:45
sean-k-mooneyjangutter: ya12:45
janguttersean-k-mooney: cool, so you had in mind "add one more class" not "convert one more class to a random bag of dicts"...12:46
sean-k-mooneyyes12:46
sean-k-mooneyrandom bag of dicts that will some day be sent over api is less then ideal12:47
janguttersean-k-mooney: verily.12:47
janguttersean-k-mooney: thanks very much, will archive this review as a warning to future developers.12:48
sean-k-mooneyim fine with VIFPortProfileOVSRepresentor having no addtional field and inheriting from VIFPortProfileRepresentor by the way12:48
janguttersean-k-mooney: that won't work, unfortunately, will have to be multiple inheritance.12:49
sean-k-mooneythe thing is right now we dont have any offload metadata that we are sending so the pluggins modes info is all that class contains12:49
fried_ricemdbooth: I set up gertty during the PTG and it took like three days before it finished loading everything down.12:49
*** fried_rice is now known as efried12:49
sean-k-mooneyjangutter: oh why?12:49
mdboothefried: Ah, ok. That's when I started, and it took so long I assumed I'd done it wrong and deleted it.12:50
* mdbooth is about to get on a plane again, and was hoping to have offline gerrit :/12:50
efriedmdbooth: That had been my experience the first time I tried it.12:50
janguttersean-k-mooney: with VIFHostDevice or VIFVhostUser we need the bridge name and other thingies too.12:50
efriedmdbooth: Perhaps broadband you could get it to load up faster, though actually I suspect not. I wasn't getting close to maxing out my bw when I was doing it.12:50
janguttersean-k-mooney: so OVSRepresentor would have to have multiple inheritance (OVS and Representor).12:51
sean-k-mooneyefried: ya there are some knonw issue. if its worth anything the pip version works better the package manager12:51
mdboothWell I'm currently on 4G mobile data, so I guess I'd better kill it12:51
efriedI don't remember how I installed it.12:51
sean-k-mooneyjangutter: no it wouldn't12:51
jangutterefried: yeah, apparently ONLY USE THE PIP VERSION.12:51
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222612:51
sean-k-mooneyVIFPortProfileOVSRepresentor is a port profile not a vif12:51
* mdbooth installed it via pip in Ubuntu for WSL ;)12:52
mdboothNo, seriously12:52
janguttersean-k-mooney: ah you're right: interface_id is what's currently used.12:52
sean-k-mooneymdbooth: it takes a while to sync because its cloneing all the git repos you subsribe to12:52
mdboothMy gate is finally open.12:53
sean-k-mooneyjangutter: interface_id is used for what exactly12:53
* mdbooth goes offline with whatever he's currently got12:53
*** ShilpaSD has joined #openstack-nova12:54
janguttersean-k-mooney: when the port gets plugged into OVS, there's an interface_id UUID added to the OVSDB config.12:54
*** lbragstad has joined #openstack-nova12:54
sean-k-mooneyyes that is pulled form the ID field in the base os-vif VIF object12:54
janguttersean-k-mooney: last time I checked, Neutron listens to OVSDB for that interface_id UUID to pop up in order to confirm the plugging.12:54
sean-k-mooneyjangutter: for the ml2 agent yes it check the interface_id in the external_ids colume of the port table12:55
janguttersean-k-mooney: yep, but is that guaranteed to be the same as VIFBase.id ?12:55
sean-k-mooneyjangutter: yes that is where we read if from12:56
janguttersean-k-mooney: why is interface_id then a field in the OVS port profile?12:56
sean-k-mooneylegacy reasons12:57
sean-k-mooneybasically it was used by libvirt12:57
sean-k-mooneyit got copied when we did the import from nova but its the same id12:57
janguttersean-k-mooney: o.m.w. here I was thinking that it's the whole reason behind port profiles!12:57
*** mdbooth has quit IRC12:58
sean-k-mooneyjangutter: nope12:58
janguttersean-k-mooney: so, one VIF can only ever ever have one interface ID, and that's the same as its UUID?12:58
sean-k-mooneylooks like we are using it https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L12412:58
sean-k-mooneyjangutter: yep it should be12:59
sean-k-mooneylet me check nova to confirm but they should never be different as far as i know12:59
janguttersean-k-mooney: yep, that was the line of code that made me thought it could differ from vifbase.id.12:59
sean-k-mooneyi dont think it can but im checking13:00
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Remove IPTools deprecated implementation  https://review.openstack.org/60542213:00
*** psachin has quit IRC13:01
sean-k-mooneyjangutter: so ya the neutron port uuid is stored in the id field https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L248-L26413:02
*** eharney has joined #openstack-nova13:02
janguttersean-k-mooney: interface_id=vif.get('ovs_interfaceid') or vif['id']13:03
sean-k-mooneyjangutter: and here we even default it to the vif[id] if ovs_interfaceid is not set https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L28813:03
sean-k-mooneyyes13:03
janguttersean-k-mooney: yep.... Guess what, I've also wrote code like that.13:03
janguttersean-k-mooney: but my interpretation was that "ovs_interfaceid" is the new hotness and vif['id'] is old-and-busted.13:04
*** tetsuro has joined #openstack-nova13:04
sean-k-mooneyjangutter: nope othere way around ovs_interfaceid i think was a nova networks thing13:05
sean-k-mooneyusing neutron i dont think they can ever be different at least not currently13:05
jangutterhttps://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/test_vif.py#L8413:06
janguttersean-k-mooney: yeah, in the tests, there's a definite difference between uuids.ovs and uuids.vif13:06
sean-k-mooneyjangutter: that does not mean the tests are correct :)13:07
janguttersean-k-mooney: yep! thanks for showing me the error of my ways again! Important safety tip.13:07
sean-k-mooneyjangutter: https://github.com/openstack/nova/blob/a330c9a143dea8095a3d1c3eabd56193ad6f38b1/nova/network/neutronv2/api.py#L2651 so this is where its set :)13:07
janguttersean-k-mooney: makes me think of basic particle physics where time symmetry is a thing.13:08
sean-k-mooneyjangutter: by the way want to open a bug for the incorrect tests?13:09
janguttersean-k-mooney: this is pretty hilarious now that I think of it, I was almost actively undoing the direction that Nova, Neutron and OS-VIF is going.13:10
janguttersean-k-mooney: I'll try to get on it today: that looks like something nice to fix for future Jan's not to step into.13:10
sean-k-mooneyjangutter: ya i was thinking it would make a nice low hanging fruit style bug.13:11
* bauzas is back... well, the power too13:13
*** spatel has joined #openstack-nova13:13
*** tiendc has quit IRC13:15
*** mriedem has joined #openstack-nova13:15
sean-k-mooneyjangutter: this change kind of hurts me to read... https://github.com/openstack/nova/commit/1c07735f8e3b28f64fcd1252372aa9e6e917d96013:15
openstackgerritMatt Riedemann proposed openstack/nova stable/rocky: Handle missing marker during online data migration  https://review.openstack.org/60857213:18
janguttersean-k-mooney: I would literally interpret that as: "the ovs interface-id should be different from the vif id"13:19
sean-k-mooneyjangutter:this code is from 6 years ago when quantum was not the default network backend in nova and nova-networks was still alive and well13:20
sean-k-mooneyit looks like there used to be a mapping table and nova used to generate uuids for the libvirt xml13:21
janguttersean-k-mooney: yep, with neutron and nova sharing the same UUID for the VIF, that's not needed now.13:23
sean-k-mooneyjangutter: i think origianly nova nad nutron used to use the name of the port as the common thing and the uuid only came a little later as more backends stared to appear13:24
*** lbragstad has quit IRC13:24
*** erlon has joined #openstack-nova13:30
*** erlon_ has joined #openstack-nova13:31
*** lbragstad has joined #openstack-nova13:32
*** mrch_ has joined #openstack-nova13:32
mriedemgibi: probably need some help from you on how the refactored functional assertFlavor.... checks should be done in https://review.openstack.org/#/c/606106/13:34
mriedemi've found i still just need a simple assertFlavorMatchesAllocation method13:34
mrch_how to get rid of the "Instance not resizing, skipping migration." WARNINGS Spam, non of the  req-IDs stand in the list: MariaDB [nova]> select * from instance_actions where action = "live-migration" and deleted = "0"13:34
*** erlon has quit IRC13:35
gibimriedem: looking..13:35
mriedemmrch_: i tried removing that here https://review.openstack.org/#/c/560467/13:35
mriedembut that change needs to be rebased13:35
*** awaugama has joined #openstack-nova13:38
*** jaosorior has quit IRC13:39
gibimriedem: I think the solution for that is here https://github.com/openstack/nova/blob/5c0235a579ccb52f7bce5de9bcb3c927c94b23b7/nova/tests/functional/test_servers.py#L487113:40
*** spatel has quit IRC13:41
mrch_mriedem: what does "rebased" mean?13:42
*** sheel has quit IRC13:50
*** janki has quit IRC13:51
mriedemmrch_: i need to rebase it on the current master branch and resolve merge conflicts13:51
mriedemi.e. it's an old patch13:51
*** janki has joined #openstack-nova13:52
mriedemgibi: hmm, ok, so maybe i should move that into the base provider usage test class?13:52
*** jaypipes has joined #openstack-nova13:53
mriedemmrch_: i'll rebase it quick13:53
jaypipesalex_xu: answered your question on https://review.openstack.org/#/c/555081/. Hopefully that explains things a bit better. let me know if you have further questions.13:53
openstackgerritJay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking  https://review.openstack.org/55508113:53
*** takashin has joined #openstack-nova13:53
gibimriedem: sure, you can move _check_allocation_during_evacuate I think it does not depend on anything in the current class13:54
mrch_mriedem: thx, but when the old one is queens im ok with it13:54
*** kukacz has quit IRC13:54
*** kukacz has joined #openstack-nova13:54
mriedemmrch_: if my change is accepted on master then we (or you) would have to backport it to stable/rocky and then stable/queens13:54
mriedemunless you're just going to run with that downstream13:54
openstackgerritMerged openstack/nova master: api-ref: Move the evacuate action to admin action  https://review.openstack.org/60789613:56
openstackgerritMerged openstack/nova master: Update doc  https://review.openstack.org/60564013:56
openstackgerritMerged openstack/nova master: libvirt: remove unused attribute driver for LibvirtConfigNodeDevice  https://review.openstack.org/58324613:56
openstackgerritMerged openstack/nova master: Set defult value of num_nvme_discover_tries=5  https://review.openstack.org/60235113:56
mrch_mriedem: how long does it normally take until stable/queens centos repository has it?13:58
mriedemi have no idea when centos picks up changes from upstream stable branches13:59
openstackgerritMatt Riedemann proposed openstack/nova master: RT: replace _instance_in_resize_state with _is_trackable_migration  https://review.openstack.org/56046714:00
mrch_mriedem: huge THX14:00
efriedn-sch meeting now in #openstack-meeting-alt14:00
bauzasgibi: maybe I misunderstood https://review.openstack.org/#/c/605785/9/nova/compute/api.py@4375 but I provided a comment14:00
mriedemmrch_: the people in #openstack-rpm-packaging might know when changes are picked up14:00
sean-k-mooneymelwitt: did you do a release of os-vif last week?14:00
*** munimeha1 has joined #openstack-nova14:07
openstackgerritHamdy Khader proposed openstack/nova stable/rocky: Set defult value of num_nvme_discover_tries=5  https://review.openstack.org/60868314:08
sean-k-mooneymriedem: can we do stable releaes of os-vif and then use them with nova stable branches? the upperconstraitns appear to cap zstreams also https://github.com/openstack/requirements/blob/stable/pike/upper-constraints.txt#L45814:09
*** awaugama has quit IRC14:09
*** awaugama has joined #openstack-nova14:11
*** SteelyDan is now known as dansmith14:13
openstackgerritLucian Petrut proposed openstack/nova master: Fix os-simple-tenant-usage result order  https://review.openstack.org/60868514:16
sean-k-mooneydansmith: bauzas: got a second to answer a question about stable branch releases?14:17
sean-k-mooneycan we do a release of a lib os-vif in this case for a sable branch and then raise the z stream on stable/X to allow that z stream14:18
sean-k-mooneythe intent being to allow nova on stable/X to consume the zstream release of os-vif for stable/X14:19
dansmithsean-k-mooney: you need to stop saying z-stream up here :)14:19
sean-k-mooneywell thats what tehy are called upstream too14:19
dansmithum, really? I don't think I've heard that from non-redhat people but, whatever :)14:20
dansmithsean-k-mooney: I don't think we bump requirements in stable other than to fix critical bugs,  but mriedem is the right person to ask that14:20
sean-k-mooneydansmith: well we used to call x.y.z releases z streams at intel too14:21
sean-k-mooneyok well its for https://review.openstack.org/#/c/602384/14:21
mriedemmmm s390x stream14:21
dansmithheh14:22
*** beekneemech is now known as bnemec14:22
mriedemso no we don't need to bump minimum required versions in stable for that os-vif change14:23
mriedemupper-constraints can be bumped14:23
sean-k-mooneymriedem: ya i just wanted to bump upper14:23
mriedemotherwise assume stable GA'ed and is frozen with the minimum14:24
*** eharney has quit IRC14:24
*** moshele has quit IRC14:31
*** lpetrut has joined #openstack-nova14:32
*** mrch_ has quit IRC14:32
lpetrutHi, I have a trivial fix for "nova usage-list", which is counting instances twice: https://review.openstack.org/#/c/608685/14:38
*** mlavalle has joined #openstack-nova14:39
mriedemlpetrut: it would be really nice if we could have a functional test to go along with that to show the regression14:48
mriedempaging over simple tenant usage is confusing enough already14:48
lpetrutsure, I'll add a test14:49
*** itlinux has quit IRC14:50
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API  https://review.openstack.org/48222614:52
*** edleafe has joined #openstack-nova14:52
*** gcb_ has joined #openstack-nova14:53
openstackgerritJan Gutter proposed openstack/os-vif master: Add support for generic representors  https://review.openstack.org/60869314:54
*** tetsuro has quit IRC14:56
*** lpetrut has quit IRC14:57
*** takashin has left #openstack-nova15:00
openstackgerritMarkus Hentsch proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption  https://review.openstack.org/60869615:01
*** mriedem has quit IRC15:03
*** dklyle has joined #openstack-nova15:04
*** mriedem has joined #openstack-nova15:04
mriedemjaypipes: email to yikun sent about those allocation ratio specs15:07
jaypipesmriedem: ty15:08
mriedemefried: gibi: fyi since i need to backport https://review.openstack.org/#/c/606106/ i'm not going to try and fit in the newly refactored assertion method usage and just copy the old methods into the test itself, which i will remove from master in a follow up15:08
efriedmriedem: ack, sounds fair.15:09
*** Luzi has quit IRC15:17
*** Sundar has joined #openstack-nova15:19
*** janki has quit IRC15:20
*** panda is now known as panda|off15:23
openstackgerritMartin Midolesov proposed openstack/nova master: Implementing graceful shutdown.  https://review.openstack.org/60870415:24
openstackgerritMatt Riedemann proposed openstack/nova master: Add post-test hook for testing evacuate  https://review.openstack.org/60217415:24
openstackgerritMatt Riedemann proposed openstack/nova master: Add volume-backed evacuate test  https://review.openstack.org/60439715:24
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional regression test for bug 1794996  https://review.openstack.org/60610615:24
openstackbug 1794996 in OpenStack Compute (nova) "_destroy_evacuated_instances fails and kills n-cpu startup if lazy-loading flavor on a deleted instance" [High,In progress] https://launchpad.net/bugs/1794996 - Assigned to Matt Riedemann (mriedem)15:24
openstackgerritMatt Riedemann proposed openstack/nova master: Fix InstanceNotFound during _destroy_evacuated_instances  https://review.openstack.org/60612215:24
openstackgerritMatt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage  https://review.openstack.org/60440015:24
openstackgerritMatt Riedemann proposed openstack/nova master: Refactor TestEvacuateDeleteServerRestartOriginalCompute  https://review.openstack.org/60870515:24
mriedemgibi: on https://review.openstack.org/#/c/605785/ can we just fail fast in the API/conductor if the admin is trying to force a host during live migration and the instance has allocations on non-standard resource classes? where non-standard is anything other than VCPU/MEMORY_MB/DISK_GB?15:31
mriedemgranted, with jay's CPU resource tracking spec, VCPU would eventually be nested too...15:31
jaypipesmriedem: *could* be an inventory on a child provider, yes.15:31
jaypipesmriedem: though it's bauzas' spec that goes into that.15:32
jaypipesmriedem: since he wanted to keep all the NUMA-ness in his spec and out of the cpu-resources spec.15:32
bauzas... and I need to rebase this spec15:33
bauzassince we said to unplug the NUMA affinity from this spec15:33
openstackgerritMerged openstack/os-vif master: Add abstract OVSDB API  https://review.openstack.org/47661215:36
*** k_mouza has joined #openstack-nova15:41
mriedemsure, i just don't want to get too hung up on trying to bend over backward to honor that force parameter15:43
mriedemwhich is a bad idea to use in the first place15:43
*** itlinux has joined #openstack-nova15:43
*** helenafm has quit IRC15:43
openstackgerritMerged openstack/nova master: Fix missing import in test_compute_mgr  https://review.openstack.org/60842615:44
*** k_mouza has quit IRC15:46
*** tssurya has quit IRC15:47
*** gcb_ has quit IRC16:03
mriedemneed another core to look at the vmware live migration patch https://review.openstack.org/#/c/270116/16:04
mriedemit's in a runway, +2 from me16:04
mriedemCI is passing16:04
sean-k-mooneymriedem: i was just talking to fungi about https://review.openstack.org/#/c/602384/ and the related bug16:04
sean-k-mooneygiven its status he indicated we can talk about it here.16:05
fungiyeah, a point-in-time summary of the situation would be helpful to add to that bug16:05
*** moshele has joined #openstack-nova16:05
fungiit's unclear to me how this can be a bug in nova but gets fixed by a patch to os-vif16:05
sean-k-mooneyfungi: i will update the bug today.16:06
fungimuch appreciated16:06
fungiin particular if the vulnerability in the service has to be fixed by updating a dependent library, this is going to be complicated to communicate and may also make backporting harder16:07
sean-k-mooneyfungi: effectivly nova will wait for a notification form nuetron to know the port has been wired up on migration.16:07
*** k_mouza has joined #openstack-nova16:07
sean-k-mooneybut in this edgecase os-vif is not used to plug the port libvirt is16:07
sean-k-mooneyas such we fallback to a time out and migrate without first having neutron wire up the port16:07
sean-k-mooneyneutron then wires up the port when the vm starts but that takes a little tiem to happen16:08
sean-k-mooneythe fix is to delegate to the os-vif lib to plug the interface in this edgecase also16:08
sean-k-mooneythat way the port will be wired up by neutron before we migrate16:09
*** tbachman_ has joined #openstack-nova16:09
fungiand this is effectively a design flaw in nova because it assumes the call won't time out? or a bug in neutron for not treating it consistently using os-vif?16:09
*** tbachman has quit IRC16:09
*** tbachman_ is now known as tbachman16:09
sean-k-mooneyfungi: its legacy behavior form when nova woululd do firewalling for the port instead of neutron16:10
fungiokay, so this will also eventually be solved when nova removes that deprecated behavior?16:10
sean-k-mooneythat said yes its partly a design flaw in nova.16:10
sean-k-mooneyyes if nova always used os-vif to plug the interface it would not happen16:11
*** belmorei_ has quit IRC16:11
fungiand so https://review.openstack.org/602384 is basically a workaround to avoid having to switch nova to calling into os-vif for these?16:12
mriedemumm...we use os-vif with nova-net too, so "yes if nova always used os-vif to plug the interface it would not happen" is kind of confusing16:12
sean-k-mooneymriedem: the ovs plugin in os-vif was designed not to plug the interface in this case because libvirt does that16:13
sean-k-mooneyso we expressly do not create the ovs port and allow libvirt to do that currently. the change makes os-vif create the port which allows neutron to wire it up before we migrate the vm16:14
sean-k-mooneymriedem: fungi so its not that nova does not call os-vif in this case. it does but os-vif was designed not to plug the interface in this case to maintain parity with how nova plugged interface before os-vif was split out16:15
sean-k-mooneydoes that make sense?16:15
*** Sundar has quit IRC16:15
mriedemshrug16:16
fungiso the bug is in nova making assumptions about os-vif's behavior in this circumstance, or that os-vif doesn't fully implement the behavior nova expects?16:16
mriedemsean-k-mooney: is this going to be a weird one off for ovs in os-vif only?16:16
mriedemlike will the behavior be different for all other vif types?16:16
mriedemand when you say libvirt, do you mean the nova libvirt driver or libvirt the service?16:17
sean-k-mooneythat is a good question. i think there are a class of bugs related to this.16:17
sean-k-mooneythis bug predate os-vif16:17
sean-k-mooneythe original behavoir was incorrect16:17
sean-k-mooneyi say that becase anytime libvirt plugs the vif this can happen16:18
sean-k-mooneythis will not happen for vhost-user port as libvirt does not hanel plugin in that case. simplarly for siov libvirt set the vlan tag not neutron so that is safe16:18
sean-k-mooneyfor now this is a one off but i need to look at other backends such as linux bridge to confirm this is a one off16:19
fungiis this going to be backportable at least as far as stable/pike of os-vif? since we'll want a 1.7.1 tagged there for nova stable/pike to consume i guess16:19
sean-k-mooneyfungi: yes it should be16:20
sean-k-mooneyfungi: it requires not code change out side of os-vif and has no dependceis that i can tell to backport the change.16:20
*** dtantsur is now known as dtantsur|afk16:20
*** ttsiouts has quit IRC16:21
fungii'm still a little iffy on how to go about describing this situation if we decide to publish an official advisory, particularly in that we consider it a nova bug but didn't patch nova to fix it. does the bug remain in nova even with newer os-vif? or is it simpler to explain it as a shortcoming of os-vif that we fixed to eliminate this behavior?16:21
*** panda|off has quit IRC16:22
*** ttsiouts has joined #openstack-nova16:22
*** panda has joined #openstack-nova16:23
jaypipesmriedem: did the vmware live migration patch.16:23
sean-k-mooneyfungi: a newer os-vif will resolve the issue. my concern with calling this an os-vif only bug is if we go back to before we split out os-vif the bug i belive would still exist in the nova tree16:23
fungiwell, the advisory will only concern itself with the state of these repositories as of pike or later since we don't claim to provide security support to eol or em branches/releases16:24
sean-k-mooneyfungi: in that case its likely eaiser to discribe it as a os-vif bug given that pike uses os-vif16:25
*** ttsiouts has quit IRC16:26
fungiand when you say "a class of bugs related to this" have any more been reported yet?16:27
sean-k-mooneyfungi: given the above if i add a release not to the os-vif change and propose backports. would it be inline with stable/vulnerablity policy to cut a release and bump the upper consttaint in the stable release16:28
fungimriedem would likely be able to better advise you on whether that particular change is suitable from a stable backport pilicy perspective16:29
sean-k-mooneyfungi: no but its posibly that thrid party plugins that manage ovs interfaces will need the same fix16:29
fungiokay, so similar fixes may need to be applied to third-party ovs interface management plugins but not to any others officially managed by openstack as far as you're aware?16:30
*** efried has quit IRC16:30
sean-k-mooneyi just checked the linux bridge plugin and it does not need a similar fix as far as i can tell. so no none that i am aware of16:31
fungiand what's the situation with https://review.openstack.org/602432 ? is that going to be abandoned as unneeded?16:31
sean-k-mooneythere are two out of tree plugins that i need to follow up on but i will check them and contact there maintianer if they need the same fix16:31
sean-k-mooneyfungi: yes i was going to that said i had planned on following up with the libvirt folks to see why it times out sometimes16:32
sean-k-mooneywe have had the issues using the ethernet iterface type in the past and i would like them to confirm why it does not work correctly in this case. that said its not relevent in to the bug disucssion16:34
fungiokay, once you get a summary of the present state added to the bug and we get some confirmation that https://review.openstack.org/602384 is in line with stable policy, the vmt can write up an impact description, request a cve assignment and get the ball rolling on issuing an advisory16:35
fungiand thanks for taking the time to explain this to me in such detail!16:35
mriedemwe'll want a release note on the os-vif change, we'll bump upper-constraints on stable but not lower-constraints,16:36
sean-k-mooneyfungi: no worries. i probably went into too much detail :)16:36
mriedemit's unclear to me what, if any, side effects we could have on stable with different versions of ovs/libvirt being used16:36
mriedeme.g. will libvirt complain if the port already exists because os-vif created it?16:37
*** efried has joined #openstack-nova16:37
fungiyeah, some input on whether this is deemed safe enough to backport would also be most welcome16:37
mriedemwould libvirt create a duplicate?16:37
sean-k-mooneythis wont be effected by ovs. it may or may not be effected by libvirt version16:37
sean-k-mooneymriedem: that is a good question and why i create https://review.openstack.org/#/c/602432/2 in the first place16:37
sean-k-mooneyi was expecting libvirt to be unhappy but the os-vif change passed tempest16:38
sean-k-mooneymriedem: i think libivrt is doing th right thing here and recognising the port exits but it would be good to validate this espcially when backporting16:39
mriedemyou might want to start getting the backports lined up before we merge anything on master16:40
mriedemi know we at least test different versions of libvirt in the gate between pike/queens and rocky/stein16:41
*** k_mouza has quit IRC16:41
sean-k-mooneymriedem: right ill -w the patch for now and respin with the release note then backport16:42
sean-k-mooneyi would be less comfrotable about backporting the nova change then the os-vif change to be hoenst as i dont really trust the libvirt ethernet type16:43
*** eharney has joined #openstack-nova16:43
*** gyee has joined #openstack-nova16:48
*** ralonsoh has quit IRC16:57
sean-k-mooneymoshele: you mentioned that macvtap livemigration was broken after the multiple port binings change.16:57
sean-k-mooneymoshele: i have fixed part of the issue locally but looking at https://github.com/openstack/nova/blame/fc58addab06134d7e6274a94d1ce456b0328723f/nova/network/neutronv2/api.py#L3054-L3062 live migration should have always been broken as the pci_mappings are only populated on cold migrate16:58
moshelesean-k-mooney: broken if you don't need to update the pci address16:58
moshelesean-k-mooney: it always broken if we need to change the pci_adress but if it the same on src and dest it should work (I think)16:59
sean-k-mooneyso i was able to migate the vm but nothing actully claimed the pci device on the new node17:00
sean-k-mooneyas a result we hit the exception in the else clause in post live migrate dest17:00
openstackgerritJan Gutter proposed openstack/os-vif master: Add support for generic representors  https://review.openstack.org/60869317:00
sean-k-mooneymoshele: cold migrate was definetly broken but i dont think upstream nova ever wroked with livemigation due to that check17:01
*** tbachman_ has joined #openstack-nova17:01
sean-k-mooneyi.e. cold migrate used to work before multilple port binidngs17:02
*** tbachman has quit IRC17:04
*** tbachman_ is now known as tbachman17:04
moshelesean-k-mooney: so live migration with macvtap never worked, but the multiple port binding a new bug to it17:05
sean-k-mooneymoshele: basically yes. so when i apply https://review.openstack.org/#/c/607365/ locally it correct the multiple port binding issue and live migrtion only fails because we dont claim the device on teh destination node17:06
sean-k-mooneyassumeing the pci address does not change. i.e. we also are missing the xml update code.17:07
sean-k-mooneyin anycase im going to lookin to how we do the claim in the cold migrate case and see if i can reuse that for live migration.17:07
moshelesean-k-mooney: we can't be cause it use the migration context (move_claim)17:08
moshelesean-k-mooney: we need just to call the pci resource tracker to claim it (and not call the move_claim)17:09
sean-k-mooneyya i have scked that out also but i want to get migration without the claim working first then ill add the claim17:09
moshelethis is the cold migration and resize claim https://github.com/openstack/nova/blob/b4a3cdbe6e6a139dc11730c3046b728fb13d52e9/nova/compute/resource_tracker.py#L310-L35417:11
sean-k-mooneyim just going to comment out the exception in the else block for now and add a todo/log then once i have migration back and fort working reliable with a singel vm ill add the claim logic and xml update code17:11
moshelewe should sub set of this just for pci17:11
sean-k-mooneycool thanks yes what i really just wanted to grab out of that was how it was calling the resouce tracker to do the claim fo the devices as i was going to do it simlarly17:12
sean-k-mooneyanyway im going to go grab dinner but just wanted to checkin with you on the migration work.17:13
moshelesean-k-mooney: let do a meeting about this thursday when adrianc will be back to sync on everything17:15
*** mdbooth has joined #openstack-nova17:25
*** moshele has quit IRC17:25
*** ralonsoh has joined #openstack-nova17:44
*** ralonsoh has quit IRC17:45
*** mdbooth_ has joined #openstack-nova17:50
*** moshele has joined #openstack-nova17:50
*** moshele has quit IRC17:51
*** mdbooth has quit IRC17:53
*** mdbooth_ is now known as mdbooth_bus18:01
mriedemguh, instance.launched_on, why18:06
*** mdbooth_bus has quit IRC18:12
*** mdbooth has joined #openstack-nova18:13
*** Swami has joined #openstack-nova18:13
mriedemdansmith: true story, resize_claim doesn't handle volume-backed instance disk usage reporting properly yet...18:14
* mriedem opens bug18:15
*** sabomia has joined #openstack-nova18:17
mdboothmriedem: Do we have an etherpad for BFV gaps?18:20
mriedemnot that i know of18:20
* mdbooth should collate one18:20
mriedemhttps://bugs.launchpad.net/nova/+bug/179673718:21
openstackLaunchpad bug 1796737 in OpenStack Compute (nova) "resize: hypervisor local_gb_used still reports usage even with volume-backed instances after fix for bug 1469179" [Undecided,New]18:21
mriedemi only hit this b/c of some functional tests in my cross-cell resize bafoonery18:21
mdboothYou going to see how deep the rabbit hole goes?18:22
mdboothOr move on...18:22
mriedemit's a relatively easy fix,18:22
mriedembut i'll be commenting this out in my cross-cell resize test until fixed18:22
* mdbooth is going to have that engraved on his tombstone18:23
*** imacdonn has quit IRC18:23
*** imacdonn has joined #openstack-nova18:23
*** mdbooth is now known as mdbooth_bus18:23
melwittI wonder if the old func test from my NAKed bug 1469179 interim fix would be helpful. it did things like verify local_gb not reported after resize, shelve etc18:24
openstackbug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,Fix released] https://launchpad.net/bugs/1469179 - Assigned to Dan Smith (danms)18:24
mriedemit's a very easy recreate18:25
mriedemresize a volume-backed instance and check disk usage18:25
mriedemin the hypervisors API18:25
melwittI know, I'm saying I wrote a func test back then that does all of that18:25
melwittit was this one https://review.openstack.org/#/c/428505/19/nova/tests/functional/test_boot_from_volume.py18:25
*** panda has quit IRC18:26
melwittit does resize, shelve, unshelve, rebuild18:27
*** panda has joined #openstack-nova18:28
mriedemdoes it julienne cut?18:30
melwittwell, I thought it might help if you're finding gaps with local_gb not being handled correctly after server actions. those were the other ones I tested18:32
mdbooth_busThe shelve-o-matic18:33
mriedemyeah, i know, thanks. :) i'm just joking about julienne cuts.18:33
melwittat the time that I was trying to fix the bug with the patch that's now part of starlingX18:33
mriedemyeah i can restore that test locally and see what fails still with context on this resize_claim bug18:37
*** slagle has joined #openstack-nova18:52
*** tssurya has joined #openstack-nova18:53
*** _hemna has quit IRC18:54
*** _pewp_ has quit IRC18:54
*** _hemna has joined #openstack-nova18:54
*** _pewp_ has joined #openstack-nova18:55
*** sabomia has quit IRC19:01
mdbooth_busb19:01
mdbooth_busmriedem: Do you happen to remember where the local ephemeral root bdm is defined?19:02
mdbooth_busI'm trying to re-grok the bdm code in compute api, and I'm running out of mental cache19:02
*** eharney has quit IRC19:02
mdbooth_busAlso, it's really late and I'm on a bus19:02
mdbooth_busThere's a comment which suggests that the client does it, but I couldn't find it there, either19:03
mriedemyeah the api creates a thing, sec19:04
*** eharney has joined #openstack-nova19:04
*** sambetts|afk has quit IRC19:07
mriedemnova.block_device.create_image_bdm creates it,19:09
mriedemcalled from nova.block_device.from_legacy_mapping,19:09
mdbooth_busmriedem: Thanks19:09
mriedemcalled from the api19:09
mriedemat some point19:09
mriedemtotally not obvious19:10
*** sambetts_ has joined #openstack-nova19:10
mdbooth_busWow, I'd already found and dismissed the from_legacy_mapping call19:10
mdbooth_busYeah, that's not obvious, thanks19:11
mriedemright b/c even if you use bdm_v2 you end up down that legacy path which is confusin19:11
mriedemsince legacy should mean bdm v119:11
mriedemlegacy_image_defined = not image_properties.get('bdm_v2', False)19:12
mriedem^ is the source of the confusion19:12
mriedemin _get_image_defined_bdms19:12
openstackgerritMerged openstack/nova master: VMware: Live migration of instances  https://review.openstack.org/27011619:12
mdbooth_bus'legacy' there presumably meant you specified --image <imageid> rather than --blockdevice ...image-fu...19:13
mriedemmaybe19:13
mdbooth_busAnyway, that's saved me a bunch of bleary-eyed staring at code, thanks19:13
mriedemmayhap i should throw some comments in that code19:14
mdbooth_busOh, I think I'm about to arrive after that. Night...19:16
*** mlavalle has quit IRC19:19
*** mdbooth_bus has quit IRC19:21
*** mlavalle has joined #openstack-nova19:22
melwittI marked that bp as complete ^ after removing it from the runway19:23
mriedemwe can remove nova-cyborg-interaction from the runways queue right?19:37
melwittyeah, I wasn't sure if we should leave the note on it for whoever put it there, so they know why it's not going to be added to a runway19:37
mriedemi'm assuming sundar added it19:37
mriedemi would probably just remove it19:38
melwittok19:39
*** k_mouza has joined #openstack-nova19:39
*** slagle has quit IRC19:40
efriedI suspect Sundar wanted us to review the spec.19:40
efriedwe should have separate "spec runways".19:40
efriedfor specs that would otherwise get ignored19:40
*** k_mouza has quit IRC19:53
*** k_mouza has joined #openstack-nova20:01
sean-k-mooneyefried: should or could. they could just go into the stuck review or open discustion section20:09
sean-k-mooneyof the nova meeting20:09
efriedI was being (mostly) facetious20:09
sean-k-mooneythat said i do need to go review it again20:09
*** slagle has joined #openstack-nova20:20
*** tssurya has quit IRC20:28
*** eharney has quit IRC20:32
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Cross-cell resize  https://review.openstack.org/60393020:36
*** lbragstad has quit IRC20:37
*** slagle has quit IRC20:37
*** lbragstad has joined #openstack-nova20:37
*** awaugama has quit IRC20:46
*** pcaruana has quit IRC20:49
*** k_mouza has quit IRC20:58
*** k_mouza has joined #openstack-nova20:59
*** k_mouza has quit IRC21:03
*** spatel has joined #openstack-nova21:04
openstackgerritMatt Riedemann proposed openstack/nova master: Add regression test for bug 1796737  https://review.openstack.org/60877121:05
openstackbug 1796737 in OpenStack Compute (nova) rocky "resize: hypervisor local_gb_used still reports usage even with volume-backed instances after fix for bug 1469179" [Medium,Triaged] https://launchpad.net/bugs/179673721:05
mriedemmelwitt: ^21:05
*** itlinux has quit IRC21:08
melwittcoolness. will take a look21:17
*** mdbooth has joined #openstack-nova21:37
openstackgerritMatt Riedemann proposed openstack/nova master: Properly track local root disk usage during moves  https://review.openstack.org/60877721:37
*** k_mouza has joined #openstack-nova21:38
openstackgerritMatt Riedemann proposed openstack/nova master: Remove ServersTestBase.setUp()  https://review.openstack.org/60878021:47
*** k_mouza has quit IRC21:49
*** k_mouza has joined #openstack-nova21:49
*** mdbooth has quit IRC21:50
*** erlon_ has quit IRC21:54
*** slaweq has quit IRC22:01
openstackgerritMatt Riedemann proposed openstack/nova master: Make ResourceTracker.tracked_instances a set  https://review.openstack.org/60878122:08
*** tbachman has quit IRC22:10
*** k_mouza has quit IRC22:13
*** tbachman has joined #openstack-nova22:14
*** mlavalle has quit IRC22:14
openstackgerritMatt Riedemann proposed openstack/nova master: Make ResourceTracker.tracked_instances a set  https://review.openstack.org/60878122:21
*** munimeha1 has quit IRC22:50
*** rcernin has joined #openstack-nova22:50
*** mriedem has quit IRC22:57
alex_xujaypipes: thanks, no futher answer, that is my expect answer, will recheck the spec again today.23:01
alex_xus/futher answer/futher question/23:01
openstackgerritsean mooney proposed openstack/nova master: [DNM] stub out sriov live migration  https://review.openstack.org/60878823:12
*** lbragstad has quit IRC23:16
*** artom has joined #openstack-nova23:34
*** Swami has quit IRC23:37
*** takashin has joined #openstack-nova23:41
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3)  https://review.openstack.org/57410423:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4)  https://review.openstack.org/57410623:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5)  https://review.openstack.org/57411023:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6)  https://review.openstack.org/57411323:43
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497423:43
*** gyee has quit IRC23:57

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!