Thursday, 2018-08-02

*** dave-mccowan has quit IRC00:02
*** dr_gogeta86 has quit IRC00:04
*** namnh has joined #openstack-nova00:04
*** edmondsw has joined #openstack-nova00:07
*** dr_gogeta86 has joined #openstack-nova00:07
*** ivve has quit IRC00:08
*** clarkb has quit IRC00:09
*** namnh has quit IRC00:10
*** gyee has quit IRC00:11
*** edmondsw has quit IRC00:12
*** _ix has joined #openstack-nova00:15
*** hongbin has joined #openstack-nova00:22
*** dave-mccowan has joined #openstack-nova00:22
*** mriedem has quit IRC00:29
*** _ix has quit IRC00:36
*** dave-mccowan has quit IRC00:55
*** EmilienM has quit IRC01:02
*** jangutter has quit IRC01:03
*** EmilienM has joined #openstack-nova01:04
*** namnh has joined #openstack-nova01:08
*** trozet has quit IRC01:08
*** jangutter has joined #openstack-nova01:09
*** mrsoul has quit IRC01:10
*** namnh has quit IRC01:13
*** links has joined #openstack-nova01:15
*** itlinux_ has quit IRC01:26
*** edmondsw has joined #openstack-nova01:29
*** namnh has joined #openstack-nova01:35
*** liuzz_ has quit IRC01:35
openstackgerritTetsuro Nakamura proposed openstack/nova master: Use common functions in granular fixture  https://review.openstack.org/58811301:39
*** liuzz has joined #openstack-nova01:41
*** dave-mccowan has joined #openstack-nova01:47
*** Kevin_Zheng has quit IRC01:49
*** edmondsw has quit IRC01:50
*** edmondsw has joined #openstack-nova01:51
*** edmondsw has quit IRC01:55
*** namnh has quit IRC01:59
openstackgerritTetsuro Nakamura proposed openstack/nova master: Use common functions in NonSharedStorageFixture  https://review.openstack.org/58811402:01
*** namnh has joined #openstack-nova02:08
*** Dinesh_Bhor has joined #openstack-nova02:19
*** psachin has joined #openstack-nova02:21
openstackgerritMerged openstack/nova master: Make ResourceTracker.stats node-specific  https://review.openstack.org/58763602:30
*** links has quit IRC02:37
*** Dinesh_Bhor has quit IRC02:39
*** yikun_ has quit IRC02:57
*** vivsoni_ has quit IRC02:59
*** gcb has quit IRC03:07
*** Guest43757 has quit IRC03:08
openstackgerritVishakha Agarwal proposed openstack/nova master: 'Updated_at' is NULL when show aggregate info  https://review.openstack.org/58027103:13
*** edmondsw has joined #openstack-nova03:19
*** edmondsw has quit IRC03:24
*** fanzhang_ is now known as fanzhang03:25
*** Dinesh_Bhor has joined #openstack-nova03:28
*** dave-mccowan has quit IRC03:33
*** namnh has quit IRC03:44
*** udesale has joined #openstack-nova03:46
*** hongbin has quit IRC03:46
*** Dinesh_Bhor has quit IRC04:08
*** artom has quit IRC04:33
*** Bhujay has joined #openstack-nova04:38
*** janki has joined #openstack-nova04:56
*** fnordahl has joined #openstack-nova05:05
*** Dinesh_Bhor has joined #openstack-nova05:05
*** ratailor has joined #openstack-nova05:31
*** Luzi has joined #openstack-nova06:12
*** ccamacho has joined #openstack-nova06:16
*** udesale has quit IRC06:23
openstackgerritZhenyu Zheng proposed openstack/nova master: Fix a typo in comment in resource_provider.py  https://review.openstack.org/58814506:26
*** adrianc_ has joined #openstack-nova06:37
*** Dinesh_Bhor has quit IRC06:37
*** hoonetorg has quit IRC06:42
*** Kevin_Zheng has joined #openstack-nova06:45
*** cfriesen__ has quit IRC06:46
*** liuyulong has joined #openstack-nova06:52
*** hoonetorg has joined #openstack-nova06:54
openstackgerrithuanhongda proposed openstack/nova master: Destroy evacuated instance while unset nova-compute forced_down  https://review.openstack.org/58780706:58
*** Dinesh_Bhor has joined #openstack-nova07:02
*** rcernin has quit IRC07:03
openstackgerritTetsuro Nakamura proposed openstack/nova master: Increase max_unit in placement test fixture  https://review.openstack.org/58815807:14
openstackgerritTetsuro Nakamura proposed openstack/nova master: Refactor AllocationFixture in placement test  https://review.openstack.org/58815907:14
*** kashyap has quit IRC07:18
*** adrianc_ has quit IRC07:22
*** adrianc__ has joined #openstack-nova07:23
*** gouthamr has quit IRC07:36
*** liuzz has quit IRC07:36
*** ekhugen has quit IRC07:45
*** Tahvok has quit IRC07:45
*** strigazi has quit IRC07:45
*** mvk_ has quit IRC07:46
*** eandersson has quit IRC07:46
*** Tahvok has joined #openstack-nova07:46
jaosoriorgibi: do unversioned notifications still work to date? or are they already being deprecated?07:58
*** jpena|off is now known as jpena08:12
*** avolkov has joined #openstack-nova08:18
jaosorioror anybody that knows about notifications ^^08:20
*** tssurya has joined #openstack-nova08:26
gibijaosorior: hi! unversioned still works, not even deprecated yet08:36
gibijaosorior: we still have couple of unversioned notificatons that does not have versioned pair                          https://review.openstack.org/58809708:37
gibijaosorior: I mean http://burndown.peermore.com/nova-notification/08:37
*** rabel has joined #openstack-nova08:37
rabelhi there. i have a question regarding https://docs.openstack.org/nova/latest/_images/architecture.svg : is the api really communicating to neutron, glance and cinder? or is this done directly by the conductor?08:38
*** derekh has joined #openstack-nova08:42
*** udesale has joined #openstack-nova08:46
*** joxyuki___ has joined #openstack-nova08:48
*** cdent has joined #openstack-nova08:49
*** joxyuki___ has left #openstack-nova08:50
*** tetsuro_ has joined #openstack-nova08:56
*** tetsuro_ is now known as tetsuro08:57
*** tetsuro is now known as tetsuro_08:57
*** tetsuro_ has left #openstack-nova08:57
*** tetsuro__ has joined #openstack-nova08:59
*** tetsuro__ has quit IRC08:59
*** tetsuro_ has joined #openstack-nova08:59
*** pcaruana has joined #openstack-nova09:00
*** tetsuro_ has quit IRC09:02
*** tetsuro_ has joined #openstack-nova09:04
*** tetsuro_ has quit IRC09:04
*** Bhujay has quit IRC09:11
*** maciejjozefczyk has quit IRC09:13
*** maciejjozefczyk has joined #openstack-nova09:19
*** ejat has joined #openstack-nova09:22
*** mschuppert has joined #openstack-nova09:25
*** adrianc__ has quit IRC09:42
*** edmondsw has joined #openstack-nova09:48
*** hoonetorg has quit IRC09:54
*** maciejjozefczyk has quit IRC10:07
*** hoonetorg has joined #openstack-nova10:09
*** adrianc__ has joined #openstack-nova10:11
*** aloga has quit IRC10:12
*** maciejjozefczyk has joined #openstack-nova10:25
*** maciejjozefczyk has quit IRC10:26
*** dtantsur|afk is now known as dtantsur10:32
sean-k-mooneyrabel: nova used to have proxy apis for the other serveice. im not sure how many are still left but i think the proxy apis went direct to the other sevices10:32
sean-k-mooneyrabel: the conductor and compute agents also talk direct to neutron,glance cinder... as far as i know10:33
stephenfinsean-k-mooney: You work the weirdest hours10:36
stephenfin:)10:36
openstackgerritMerged openstack/nova master: Add note about reschedules and num_attempts in filter_properties  https://review.openstack.org/58241210:36
openstackgerritStephen Finucane proposed openstack/nova master: tox: Ensure reused envdirs share the same deps  https://review.openstack.org/58820710:37
stephenfingibi: Fancy taking a look at that ^ I made a silly mistake :(10:37
*** vivsoni has joined #openstack-nova10:39
sean-k-mooneystephenfin: yes i do10:39
*** crazik has joined #openstack-nova10:40
sean-k-mooneystephenfin: anything in particalar more weird then usual10:40
*** crazik has left #openstack-nova10:40
stephenfinsean-k-mooney: Nope. Just a general observation :)10:40
sean-k-mooneystephenfin: what time zone am i in lol http://stackalytics.com/report/users/sean-k-mooney10:41
sean-k-mooneystephenfin: our activity reporst are totally different http://stackalytics.com/report/users/stephenfinucane10:42
stephenfinHahaha10:43
stephenfin9-5, baby10:43
cdentstephenfin: we should all be a bit more like you10:44
sean-k-mooneystephenfin: 9 pm to 5 am i could do that :)10:44
*** maciejjozefczyk has joined #openstack-nova10:46
sean-k-mooneycdent: yours is much more like mine http://stackalytics.com/report/users/cdent10:46
* cdent nods10:46
* cdent must try harder10:46
cdentit's a job, not an adventure10:46
openstackgerritChen proposed openstack/nova master: Make nova-manage db archive_delete_rows take --all-cells  https://review.openstack.org/58785810:48
sean-k-mooneythe problem  is when tech is also a hobby. at least you seam to front load most of you work between 11-5 and trail off when you should be home relaxing10:49
stephenfincdent, sean-k-mooney: I've no idea how people work any differently. It's only way I can make sure I consistently go to the gym, eat decent food, socialize etc.10:49
*** Dinesh_Bhor has quit IRC10:49
stephenfinIt's doubly impressive when those people have families that surely take a good chunk of their time/attention10:49
* stephenfin casts an eye towards mriedem, bauzas, alex_xu et al10:50
sean-k-mooneystephenfin: hehe you assume i go to a gym and socialize. silly person :P10:50
cdentstephenfin: well there ya go: I don't go to the gym, eat decent food, or socialize10:50
cdentwhich is why I need to do better, I really need to do all those things10:50
stephenfinsean-k-mooney: Heh, fair enough10:51
cdentluckily my kids are all old, so they don't suffer my failings (at least not these)10:51
stephenfincdent: I think efried does it best. Not only does he go to a gym (of sorts) but he manages to run one10:51
stephenfincdent: Aye, I should have clarified with young families10:52
openstackgerrithuanhongda proposed openstack/nova master: Destroy evacuated instance while unset nova-compute forced_down  https://review.openstack.org/58780710:52
stephenfincdent: Totally unrelated but maybe of note for you: it looks like Paste might be entering unmaintained territory https://bitbucket.org/ianb/paste/ Wonder if that's a concern?10:53
stephenfinIn particular, https://bitbucket.org/ianb/paste/pull-requests/41/10:54
cdenthmmm. yeah.10:54
cdentIdeally we'd stop using paste and manage middleware differently, but that's not a change we could make overnight10:54
sean-k-mooneyi was going to ask what do we use it for?10:55
stephenfinIndeed. I imagine we'll need to support Python 3.7 long before we could even think about dropping that.10:56
*** Dinesh_Bhor has joined #openstack-nova10:56
sean-k-mooneyis this what the api-past.ini files are for?10:56
cdentsean-k-mooney: that's what paste (the lib) reads10:57
sean-k-mooneyoh we use it in the wsgi scripts.10:57
cdentit configured the middlware stack in noav-api10:57
*** Dinesh_Bhor has quit IRC10:58
cdentother projects use it too. placement intentionally chose not to use it because it intentionally doesn't have configurable middleware: you get what you're given10:58
sean-k-mooneycdent: do we test reconfiguring the middelware in nova?10:59
cdentI don't know10:59
stephenfincdent: I wonder if that risk should be mentioned to anyone, given that Python 3.7 is going to be a thing soon enough?11:00
stephenfinI'm pretty sure someone could reach out to the author and offer to help maintain it (bugfixes and future Python support vs. actual new features), but I'm likely spread too thin to actually do it myself right now11:01
* stephenfin drafts mail to openstack-dev11:01
sean-k-mooneystephenfin: well will it. i have not heard anyone seriously suggesting more the 3.6 support11:02
cdentI'll bring it up with the TC crowd this afternoon. I also vaguely know Ian from way way back, so might be able to find something out from him11:02
sean-k-mooneyubuntu 18.04 will be sticking with 3.6 as far as i know11:02
stephenfincdent: ack11:02
cdent(when I say TC crowd I mostly mean doug)11:02
stephenfinack ack :)11:02
*** jpena is now known as jpena|lunch11:04
*** wolsen has quit IRC11:04
*** jamespage has quit IRC11:04
*** fmccarthy has quit IRC11:04
*** rajinir has quit IRC11:04
*** lamt has quit IRC11:04
*** auggy has quit IRC11:04
*** sergek_ has quit IRC11:04
*** simondodsley_ has quit IRC11:04
*** simondodsley_ has joined #openstack-nova11:05
*** zzzeek has quit IRC11:07
rabelsean-k-mooney: thanks!11:11
*** maciejjozefczyk has joined #openstack-nova11:12
*** zzzeek has joined #openstack-nova11:13
gibistephenfin: +2 on the tox.ini fix11:16
*** priteau has joined #openstack-nova11:19
*** jangutter has quit IRC11:24
*** udesale has quit IRC11:27
*** dave-mccowan has joined #openstack-nova11:27
*** tbachman has quit IRC11:31
*** mdbooth has quit IRC11:32
*** kuzko_ has quit IRC11:41
*** mdbooth has joined #openstack-nova11:46
*** ragiman has joined #openstack-nova11:49
*** cdent has quit IRC11:59
*** adrianc__ has quit IRC12:03
*** vivsoni_ has joined #openstack-nova12:06
*** vivsoni has quit IRC12:07
*** tbachman has joined #openstack-nova12:14
maciejjozefczykkosamara: hey, I can confirm that bug: https://bugs.launchpad.net/nova/+bug/177984512:19
openstackLaunchpad bug 1779845 in OpenStack Compute (nova) "hide_hypervisor_id doesn't hide hyperv signature for Windows VMs" [Undecided,In progress] - Assigned to Konstantinos Samaras-Tsakiris (kosamara)12:19
maciejjozefczykkosamara: and in fact I just started to working on that point, but you were first ;)12:19
*** EmilienM has left #openstack-nova12:21
*** mvenesio has quit IRC12:25
openstackgerritMerged openstack/nova master: Hook resource_tracker to remove stale node information  https://review.openstack.org/58792212:34
*** jmlowe has quit IRC12:35
bauzasnetwork issues at home, folks12:37
bauzasjust in case you need me12:37
sean-k-mooneymaciejjozefczyk: glad to hear. that said strictly speaking it not a bug as you are using hardwar in a way the hardwar vendor explictly does not support and has taken measures to prevent12:37
sean-k-mooneymaciejjozefczyk: but i do think we should allow it12:37
*** ragiman has quit IRC12:37
bauzasgiven we're in August and in France, can I hope my network issues to be fixed around Aug 29th ?12:38
sean-k-mooneymaciejjozefczyk: so really this is an RFE(request for enhancement)12:38
*** ratailor has quit IRC12:39
*** s10 has joined #openstack-nova12:44
sean-k-mooneywhy dos our suspend fucntion in the libvirt diriver not suspend the instance ...12:45
*** sahid has joined #openstack-nova12:46
maciejjozefczyksean-k-mooney: yes, thats not a bug, but RFE. Anyway if we have support for spoofing hypervisor identification inside VM, we should be consistent in that point12:50
stephenfinbauzas: Fancy sending this on its way? https://review.openstack.org/58820712:50
*** rabel has left #openstack-nova12:51
*** tssurya has quit IRC12:51
*** udesale has joined #openstack-nova12:51
stephenfingibi: ta!12:52
sean-k-mooneymaciejjozefczyk: we add that capablity sole to work for the usecase of running nvidia gpus in a guest via pci passthrough. it is not support on any other virt driver, but sure12:52
openstackgerritEric Fried proposed openstack/nova master: doc: fix resize user guide link  https://review.openstack.org/58809712:52
gibistephenfin: there are two relatively small refactor that https://review.openstack.org/#/c/586968/ and https://review.openstack.org/#/c/587412/ if you have some time12:52
stephenfingibi: I'll hit those right now12:53
sean-k-mooneymaciejjozefczyk: that said if we were being consitent we would hide every feature observable withing the guest that implies you are in a vm not just the hypervior id.12:53
openstackgerritStephen Finucane proposed openstack/nova master: Remove unused stubbing function from test  https://review.openstack.org/58696812:53
*** tssurya has joined #openstack-nova12:54
* sean-k-mooney im going to delete some code in nova. and everything is going to work first time with no bugs.12:57
*** mriedem has joined #openstack-nova12:57
stephenfingibi: Could you expand on your comment here? https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py12:58
gibistephenfin: looking...12:58
stephenfini.e. why do we need to re-stub?12:58
maciejjozefczyksean-k-mooney: yes, anyway if we have usecase we should do this :) nvidia is good example12:59
gibistephenfin: _IntegratedTestBase base class already set up the generic NeutronFixture which means that nova.network.neutronv2.api.get_client is already stubbed by the NeutronFixture12:59
sean-k-mooneymaciejjozefczyk: not nessicarialy. but in this case it is not that invasive a cchange12:59
*** eharney has quit IRC12:59
gibistephenfin: then L350 sets up another fixture NUMAAffinityNeutronFixture that will also stub nova.network.neutronv2.api.get_client13:00
gibistephenfin: this is OK as the second stub overrides what the first stub did13:00
stephenfingibi: ahhh, of course. I missed that we were using the other fixture13:00
stephenfinNot like I wrote that code or anything :)13:00
gibistephenfin: I guess you had a good vacation at properly reset your brain :)13:00
gibis/at/that/13:01
sean-k-mooneymaciejjozefczyk: for there binary direver it may or may not be complient with there EULA. for the linux opensource Nouveau driver its probaly fine13:01
stephenfingibi: Currently trying to remember what "Python" is13:01
stephenfin:)13:01
gibi:)13:01
*** cdent has joined #openstack-nova13:02
*** jaypipes has joined #openstack-nova13:02
stephenfingibi: One other comment (the second one here) https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py13:03
stephenfinsean-k-mooney: Off the top of your head, would calling os_vif.initialize() twice have any bad side effects?13:04
sean-k-mooneystephenfin: no we specificaly check for that13:04
gibistephenfin: I can remove that os_vif.initialize() as that is already in the fake libivirt now13:04
sean-k-mooneycall it a 1000 times in a loop if you like it will only initalise once13:04
stephenfingibi: Meh, unless you want to, I'm happy to just +W as is. It's a nit13:05
sean-k-mooneystephenfin: unless you pass reset=true13:05
stephenfinsean-k-mooney: Excellent. It's just a clean up so13:05
gibistephenfin: I will respin it quickly13:05
stephenfingibi: ack13:05
sean-k-mooneystephenfin: by the way if your remove os_vif.initialize from setup and dont call it at all your test will fail13:06
sean-k-mooneystephenfin: i added it becuse your tests were failing because nova assumes (correctly) that os-vif is initalised when its using it and the code is written in such a way that it fails if its not13:08
sean-k-mooneystephenfin: i put it in setup beacuse i dont know what order the test will be run in13:09
stephenfinsean-k-mooney: Yup, I think is was you that pointed that out to me. It should be good now though because of https://review.openstack.org/#/c/587412/3/nova/tests/unit/virt/libvirt/fakelibvirt.py13:09
stephenfinSo it'll get initialized the same time the fake nova-compute service starts13:09
sean-k-mooneyoh sweet then ya you can remove it from setup13:10
mriedemlyarwood: before i get too far into https://bugs.launchpad.net/nova/+bug/1784353 - we don't reschedule on a boot from volume failure13:11
openstackLaunchpad bug 1784353 in OpenStack Compute (nova) "Rescheduled boot from volume instances fail due to the premature removal of their attachments" [Medium,In progress] - Assigned to Lee Yarwood (lyarwood)13:11
sean-k-mooneyor not its a nit as you said. its not needed anymore but not enough for a respin on its own13:11
mriedemlyarwood: or is this non-volume backed, so not really boot from volume,13:11
mriedemjust boot with volumes attached, but the root disk is on local storage13:12
openstackgerritBalazs Gibizer proposed openstack/nova master: Improve NeutronFixture and remove unncessary stubbing  https://review.openstack.org/58741213:15
gibistephenfin: ^^13:15
stephenfingibi: and done13:17
gibistephenfin: thanks13:17
mriedemlyarwood: do you have some extra changes that make us reschedule on volume attach failures during boot? because we should abort here on any failure to attach volumes https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/compute/manager.py#L232013:17
lyarwoodmriedem: I've used BFV instances in the regression tests and just mocked out spawn to fail, not the volume attachments etc13:18
mriedemlyarwood: that's not your bug though13:18
mriedemyour bug is not that spawn fails, but volume attach fails13:18
mriedemoh wait,13:19
mriedemi think i get it,13:19
lyarwoodmriedem: that's for the following attempt13:19
mriedemfirst boot spawn() fails,13:19
mriedemreschedule,13:19
lyarwoodmriedem: yeah13:19
mriedem2nd host fails b/c volume attachments are wrong13:19
mriedemok13:19
mriedemb/c bug 148811113:19
openstackbug 1488111 in OpenStack Compute (nova) "Boot from volumes that fail in initialize_connection are not rescheduled" [Wishlist,Confirmed] https://launchpad.net/bugs/148811113:19
mriedemi was like, whatchutalkinboutyarwood13:19
lyarwood^_^13:19
*** tetsuro_ has joined #openstack-nova13:20
*** jaosorior has quit IRC13:20
*** janki has quit IRC13:24
*** tetsuro_ has quit IRC13:24
*** cdent has quit IRC13:27
sean-k-mooneymriedem: lyarwood stephenfin. Quick Question can you think of any reason why i shoulds not replace calls to suspend in cold shapshot case with calles to pause given suspend does not actully suspend the instance regardless of the name or comemnt and its break sriov/pcipasshtough in some cases?13:30
*** awaugama has joined #openstack-nova13:31
sean-k-mooneyim going to try it in any case and see what happens but do ye know why the current bevhaior is to detach all pci devices then save guest ram and not suspend13:31
mriedemdon't ask me13:32
mriedemi always have to lookup the difference in libvirt between pause and suspend13:32
lyarwoodsean-k-mooney: hmmm iirc we need to detach PCI devices as we can't save or restore their state13:33
*** artom has joined #openstack-nova13:33
*** jpena|lunch is now known as jpena13:33
sean-k-mooneylyarwood: to stop dma transfer or somthing?13:33
*** jaosorior has joined #openstack-nova13:33
sean-k-mooneyin any case the current state seams broken.13:34
lyarwoodsahid: ^ do you know?13:35
lyarwoodsean-k-mooney: I'm not sure tbh13:35
*** Luzi has quit IRC13:35
lyarwoodsean-k-mooney: and yeah suspend just saves the domain state to disk right? So that wouldn't help during a cold snapshot.13:35
lyarwoodwait that isn't right, it does pause the domain13:37
sean-k-mooneylyarwood: no it doesnt13:37
sean-k-mooneyhttps://github.com/openstack/nova/blame/77ece76a70aa251e6f06e073b28c2ca978caf8f8/nova/virt/libvirt/driver.py#L2639-L264613:38
mriedemlyarwood: your bug says we call _shutdown_instance before reschedule but i don't think that's the case if driver.spawn() fails13:39
sean-k-mooneywe call it in _prepare_domain_for_snapshot https://github.com/openstack/nova/blob/77ece76a70aa251e6f06e073b28c2ca978caf8f8/nova/virt/libvirt/driver.py#L174013:39
mriedemlyarwood: wouldn't we only call _shutdown_instance here prior to rescheduling https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/compute/manager.py#L2364 but only if network or bdm setup failed?13:40
*** pcarver_ is now known as pcarver13:40
*** _ix has joined #openstack-nova13:41
lyarwoodsean-k-mooney: ack, so ManagedSave doesn't pause the domain, fun.13:41
mriedemoh nvm,13:41
mriedemi guess that's the exception handling from the yield on the context manager,13:41
mriedemhere https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/compute/manager.py#L209213:41
mriedemwhich is what calls driver.spawn()13:41
mriedemgod this flow is confusing13:41
lyarwoodmriedem: yeah indeed, it's awkward.13:42
mriedemok and the bdm.attachment_id in this flow is created in the API right?13:43
lyarwoodmriedem: yes13:43
sean-k-mooneylyarwood: i have to go into the libvirt python binding to check but no code in nova does. anyway ill keep digging and see what i find13:43
mriedemso api creates the attachment record, we hit hostA, fail to spawn, delete the attachment, reshcedule to hostB, try to attach and the attachment is gone13:43
lyarwoodmriedem: yup that's it13:44
*** eharney has joined #openstack-nova13:45
*** burt has joined #openstack-nova13:48
*** _ix has quit IRC13:49
mdboothmriedem: spent a bunch of time thinking about your rollback failed evacuated guest patch. TL;DR I think we need to clean that up in the driver, and if we get out of the driver with a running instance we shouldn't be talking about rollbacks any more.13:57
mdboothmriedem: Detail in review.13:57
mriedemmdbooth: thanks; i asked in the bug report if they had details on what the actual failure was after the guest was spawned on the dest - like if it was a db error updating the instance status or something14:00
mriedemi'm not in love with this patch as noted in the commit message14:00
mdboothmriedem: ack. I got that.14:00
openstackgerritMerged openstack/nova stable/queens: Call generate_image_url only for legacy notification  https://review.openstack.org/58496914:00
*** cdent has joined #openstack-nova14:02
*** tbachman has quit IRC14:02
*** erlon has quit IRC14:04
*** tbachman has joined #openstack-nova14:05
mriedemthe bug reporter replied with what they failed on the first time they hit the dest host,14:06
mriedemand apparently it was driver.spawn()14:06
mriedem"libvirtError: Did not receive a reply. Possible causes include: the remote application did not send a reply, the14:06
mriedemmessage bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."14:06
*** janki has joined #openstack-nova14:07
*** ccamacho has quit IRC14:07
*** ccamacho has joined #openstack-nova14:07
*** ccamacho has quit IRC14:08
*** ccamacho has joined #openstack-nova14:08
stephenfingibi: If I run 'tox -e api-samples', I see three new files in doc/api_samples/. Is that expected?14:13
stephenfingibi: http://paste.openstack.org/show/727146/14:13
gibistephenfin: actually I don't know14:15
gibithe notification sample handling is pretty different from the api sample handling14:15
*** hongbin_ has joined #openstack-nova14:16
gibifor example the test run never generates notificaton samples14:16
*** erlon has joined #openstack-nova14:16
gibion the file system14:16
stephenfingibi: Hmm, I wonder who would know? gmann?14:16
gibisdauge was the mastermind but alex_xu or gmann could know14:16
* gibi needs to catch a bus and use a spotty connection for the rest of the work day14:17
mdboothmriedem: That sounds like a bug in the libvirt driver and/or libvirt to me.14:18
mriedemmdbooth: agree14:21
mriedemthis was also mitaka so shrug14:21
*** tbachman has quit IRC14:23
mriedemlyarwood: hmm, am i just not seeing it, but with the old style attach flow during bfv, if we failed to attach the volume, i don't see that we ever unreserve the volume from the instance14:23
mriedemthe api reserves the volume, but compute never unreserves it on failure14:23
mriedemunlike if attach_volume fails14:23
mriedemmaybe that's just always been the way it is and expected b/c you can delete the instance in ERROR state which should unreserve the volume then14:24
mriedemi guess _shutdown_instance calls the os-detach api in cinder but i don't know if that rolls back the reserved status14:25
lyarwoodmriedem: yeah I don't think we did unreserve in the old flow when we hit this error14:26
lyarwoodmriedem: I thought we had talked about updating attachments in the new flow with a None connector in this case14:26
lyarwoodmriedem: so the new compute only has to come along and update again with the correct connector14:27
mriedemi think the os-detach call to cinder for the old flow in _shutdown_instance will make the volume available again14:27
lyarwoodkk then our removal of the attachment is fine14:27
mriedemhere is i think we're we'd get in the old flow prior to reschedule https://github.com/openstack/cinder/blob/b0e9ee1d501fb83b7ebbc59584aa6255dbaec086/cinder/volume/manager.py#L131414:28
mriedem*where we'd14:28
openstackgerritJay Pipes proposed openstack/nova master: DNM - example  https://review.openstack.org/58829514:31
openstackgerritKonstantinos Samaras-Tsakiris proposed openstack/nova master: Hide hypervisor id on windows guests  https://review.openstack.org/57989714:32
mriedemlyarwood: ok comments in your series14:32
mriedemlyarwood: lots of internal debate on this one, but i think what you're doing is likely the best14:32
lyarwoodmriedem: ack thanks14:33
openstackgerritEric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures  https://review.openstack.org/58459314:34
gmannstephenfin: gibi api-samples tox run sample file with GENERATE_SAMPLES=True14:41
gmannstephenfin: there can be chance that few file missing in doc/api_samples let me check those14:42
mriedemlyarwood: looks like we've probably always created another volume on a reschedule if the source_type!='volume', i don't see anything that deletes a volume that nova created prior to rescheduling - unrelated to your issue really, but a super latent bug14:45
mriedemmost likely another reason we should move volume creation to api or conductor so that compute doesn't have to manage that14:46
mriedemcompute would just get a bdm and assume the volume already was created14:46
lyarwoodmriedem: wonderful, happy to look at that as well if you wouldn't mind writing that up in a bug?14:49
*** cfriesen has joined #openstack-nova14:50
mriedemi'd need to recreate it first, and don't have a 2 node system handy14:50
mriedemi just know we do a better job of tracking ports to know which we've created ourselves and which we haven't, and cleaning those up properly before reschedule (delete the ports we created, unbind the ports we didn't)14:51
mriedemwe don't really do anything like that for volumes14:51
*** efried is now known as efried_afk14:55
*** tomtom002 has quit IRC14:56
openstackgerritMerged openstack/nova master: tox: Ensure reused envdirs share the same deps  https://review.openstack.org/58820714:59
*** gouthamr has joined #openstack-nova15:02
*** ccamacho has quit IRC15:05
*** alexpilotti has quit IRC15:06
*** gbarros has joined #openstack-nova15:06
*** maciejjozefczyk has quit IRC15:07
*** gbarros_ has joined #openstack-nova15:10
*** gbarros has quit IRC15:12
*** udesale has quit IRC15:15
cfriesenthis is kind of a basic question but I'm having a hard time finding an answer.  the nova docs suggest we default to using durable AMQP queues with persistent messages.  The oslo.messaging code suggests the default is non-durable queues.  which is it?15:16
openstackgerritMerged openstack/nova master: Fix a typo in comment in resource_provider.py  https://review.openstack.org/58814515:18
mriedemcfriesen: where do the nova docs say that?15:20
mriedemit's clearly not durable by default https://docs.openstack.org/nova/latest/configuration/config.html#oslo_messaging_rabbit.amqp_durable_queues15:21
mriedemanything in the nova docs is likely way out of date15:21
*** psachin has quit IRC15:21
mriedemhttps://docs.openstack.org/nova/latest/reference/rpc.html?highlight=durable15:21
cfriesendoc/source/reference/rpc.rst:15:21
mriedemthat? ^15:21
mriedemyeah that's all super duper old15:22
mriedemprobably predates oslo.messaging15:22
mriedemopen a bug15:22
cfriesenokay. what about message persistance?   are we always transient?15:23
*** gbarros_ has quit IRC15:24
mriedemlet the code be your guide young chris15:24
*** gbarros has joined #openstack-nova15:25
mriedemi thought durable == persistent15:26
cfriesenjust to make things interesting, rabbitmq can have durable or transient exchanges and queues, and then the message itself can be persistent or transient.15:28
mriedemidk then, ask kgiusti in #openstack-oslo?15:29
mriedemor sileht?15:29
cfriesenyeah, will do.  I suspect we're just always transient.15:30
tssuryamriedem: probably this has come up zillion times, but I couldn't find the right reasoning on why the power synchronization is asymmetric in nova.. why does nova not acknowledge that the vm is back up again ?15:30
tssuryaisnt' the driver the state of truth ?15:31
mriedemtssurya: what thing are you specifically talking about? the sync_instance_power_states periodic in compute15:32
mriedem?15:32
tssuryayes15:32
mriedemthat shuts down your server if the db says it's down but the driver says it's up?15:32
tssuryaexactly15:32
mriedembecause you could be getting charged for one when you told nova to shut it down15:32
tssuryaah okay..15:32
mriedemit's been years since i've had to load that thing into memory15:33
mriedemand it's always a disaster when i do15:33
tssuryaand for the ironic cases where the users may interact through the ipmi interface..15:33
tssuryathe only solution we have is to switch the power sync off ?15:33
mriedemnova doesn't support monkeying with the guests out of band15:34
tssuryais there is a way we could make this behaviour configurable (a choice for deployments)15:34
tssuryahmm15:34
mriedemi'm sure vmware and powervc have had this same argument because the user started up the vm in vcenter or the hmc15:34
mriedemand then nova shut it down15:34
tssuryayes, we have the same stuff15:35
*** gbarros has quit IRC15:35
stephenfinmriedem: Remind me: can I +W code? We've branched and everything, right?15:35
tssuryawe were just thinking if we could make this configurable.. as in tell nova not to shut it back down15:35
mriedemstephenfin: we have not branched15:35
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: guest: introduce blockStats instead of domain.blockStats  https://review.openstack.org/52683315:35
tssuryathe default could be what nova does today of course15:35
stephenfinWell then :)15:35
mriedemstephenfin: +W depends on the change15:35
mriedemif it's a bug fix, then yeah maybe15:35
mriedemif it's docs, sure15:36
stephenfinIt's a refactor so nope, it should wait15:36
mriedemif it's a big ass refactor or something risky, likely not a great idea right now15:36
stephenfinYup, I'll just leave it til branch. No panic on it15:36
* stephenfin is working down through the "needs another reviewer" list15:36
*** sambetts|afk is now known as sambetts15:36
mriedemtssurya: likely a better question for the ML to get wider input, from both -dev and ops lists15:37
mriedemi'm able to devote about 5% brain to your question atm15:37
tssuryamriedem: ack, sorry for the bad timing then :)15:37
mriedemnp15:37
gmannstephenfin: yes, these were missed and they would not fail as they all are req files which are not verified on sample tests. let me know if you can or want me to add them and good to ref those in api-ref also.15:43
*** hamzy has quit IRC15:49
stephenfingmann: I don't mind. Is it a big issue? I guess it just means the api-ref will be incomplete?15:51
stephenfingmann: If you _do_ have time to work on them, I'll happily review it15:52
*** janki has quit IRC15:58
mriedemtssurya: note you can disable that sync power state task15:59
mriedemhttps://github.com/openstack/nova/blob/master/nova/compute/manager.py#L743916:00
melwittdangit, was just pulling that up16:00
melwittyou win...again16:01
melwitthttps://github.com/openstack/nova/blob/master/nova/conf/compute.py#L753-L77716:04
*** eandersson has joined #openstack-nova16:10
*** rdiggz has joined #openstack-nova16:11
*** gbarros has joined #openstack-nova16:14
*** tssurya has quit IRC16:16
*** gbarros_ has joined #openstack-nova16:17
rdiggzgood day everyone. Could someone help me understand what this means? "A sys-admin privsep daemon has been added and needs to be included in your16:17
rdiggz    rootwrap configuration.16:17
*** spotz has quit IRC16:18
rdiggzIts from the release notes of pike and queens. Im seeing an issue deploying a snapshot of a CentOS7 instance that points to sys-admin and im thinking they are related.16:18
*** gbarros has quit IRC16:19
*** rdiggz has left #openstack-nova16:20
mriedemcfriesen: is this a bug that should be upstreamed or at least reported to nova? https://github.com/starlingx-staging/stx-nova/commit/fe0c0617be857161b6bb66d632b2b35887c0877216:26
mriedemoh nvm it's already in nova16:27
mriedemhttps://github.com/openstack/nova/commit/ce8bf6734e554b116e82e924cbe81a596844192616:27
cfriesenthey should've pointed to upstream if it was a backport.  grr.16:29
mriedemit's not a backport16:30
*** jpena is now known as jpena|off16:30
*** janki has joined #openstack-nova16:31
*** jpena|off is now known as jpena16:31
*** jpena is now known as jpena|off16:32
*** s10 has quit IRC16:33
*** Kevin_Zheng has quit IRC16:34
*** gyee has joined #openstack-nova16:35
*** imacdonn has quit IRC16:36
*** imacdonn has joined #openstack-nova16:37
mriedemdansmith: looks like one of your earlier is_bfv attempts made it in https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-b839034e35c154b8c3a1c65bf7791eefR11416:42
mriedemcfriesen: what are offline_cpus?16:43
dansmithmriedem: lol16:43
melwittI think that's part of the second iteration of my famous root_gb=0 workaround patches16:43
cfriesenmriedem: that's part of our cpu scaling code.  you can boot with X cpus and then scale down to fewer.  offline_cpus tracks which guest vCPUs are supposed to be offline.16:44
cfriesenmriedem: (the cpu scaling stuff requires guest cooperation to do properly)16:44
cfriesenmelwitt: I think that's correct16:45
melwittdansmith had started with the request spec part but I found that the claims and reporting on the compute side didn't yet support is_bfv so had to add that to it too in another patch stacked on top. and in the end it looked exactly like the original workaround patch that got nack'd by everyone16:45
*** dtantsur is now known as dtantsur|afk16:46
melwittso it lay abandoned again16:46
mriedemcfriesen: how is that different from just resizing down?16:46
mriedemthe offline CPUs are reserved?16:47
cfriesenmriedem: it's similar to the "live-resize" proposed recently16:47
mriedemi.e. so you can scale up and down w/o worrying about claim failures?16:47
cfriesenmriedem: the server stays running16:47
cfriesenmriedem: the resource tracking is adjusted, but the quota isn't16:48
cfriesenso you could fail to scale up if there are no free cpus on the host16:48
mriedemright that's what i was saying,16:49
mriedemyou essentially boot with like 4 vcpu,16:49
mriedemresize down to 2,16:49
mriedembut the other 2 are "offline" so you can resize back up?16:49
mriedembut you're still paying for 4 VCPU of quota?16:50
cfriesenremember this is private cloud so "paying for quota" is a bit iffy.  but yes.16:50
dansmithI'm not sure people usually charge for quota either16:51
dansmiththey pay for usage, which would be based on the stuff they're updating I imagine16:51
mriedemand this is needed why? so edge nodes can automatically scale down during down times and scale up during peak hours?16:51
dansmithit's needed because someone wanted it one time16:51
dansmithbecause there was a knob they couldn't twiddle16:52
cfriesendansmith: :)16:52
* dansmith knows he's not being helpful16:52
*** janki has quit IRC16:52
cfriesenI think the idea is that there are pets with unpredictable load that don't scale well horizontally16:52
cfriesensimilar rationale as https://blueprints.launchpad.net/nova/+spec/instance-live-resize16:53
mriedemsure16:53
mriedemok, feature 1 of 130 sorted out in my spreadsheet,16:54
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor NeutronFixture  https://review.openstack.org/58833816:54
mriedemtime for lunch!16:54
melwittfound it https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-afb9c0c0ca5276c7eacd987bbf51d8e6R37016:54
cfriesenmriedem: having done that spreadsheet multiple times with the benefit of commit history, I feel for you.   I apologize for our legal guys.16:54
mriedemi'll take your pity and just remind you of it when you get tired of me asking questions16:55
*** gbarros_ has quit IRC16:58
mriedemooo server group metadata16:59
mriedemgood thing we just nuked that from the api in rocky16:59
mriedemanyone know of a way to make github just load all diffs? because it simply gave up here17:00
cfriesenmriedem: heh.  the only thing we use it for is "max number of servers in group", and a "best effort" flag that pre-existed the "soft" affinity policies.17:00
mriedemi guess rather than crawl through github it's probably easiest to just clone this repo and look for "WRS" ?17:01
*** derekh has quit IRC17:02
cfriesenlooking for WRS will get you a lot of stuff.  also look for files with wrs in the name17:03
sean-k-mooneymriedem: all the changes are squashed into one big commit on top of what was master when it was created17:04
mriedemsean-k-mooney: yes, i'm intimately familiar17:04
*** tbachman has joined #openstack-nova17:04
sean-k-mooneyi made a list of randome stuff to look at later in that repo but left it at intel when i left17:05
*** gbarros has joined #openstack-nova17:05
cfriesenmriedem: technically speaking one of the things I liked was the ability to dynamically shift host CPUs between being used for "pinned" instances and "shared" instances on the same node.  That was also the rationale for the floating-point representation of "used cpus" on the host.17:07
*** gbarros has quit IRC17:09
*** gbarros has joined #openstack-nova17:11
*** hamzy has joined #openstack-nova17:11
*** efried_afk is now known as efried17:14
*** gbarros has quit IRC17:14
sean-k-mooneycfriesen: yes... that is interesting17:20
sean-k-mooneycfriesen: yes re pinned all the floating instances on the host to make that work if i recall17:21
mriedemtoday ops just use host aggregates to separate hosts/flavors that do cpu pinning and hosts with cpu overcommit yeah?17:22
sean-k-mooneycfriesen: im not sure liked is the workd i would have chosen but the capablit is certenly interesting.17:22
sean-k-mooneymriedem: mostly yes17:22
sean-k-mooneythat is more of a cludge to workaround the fact nova does not do it magically for them rather then they like it17:23
cfriesenmriedem: the issue was that we have demand for small installs (down to one or two nodes in some cases) and so it's not practical to have to devote entire nodes to either shared or dedicated instances17:24
sean-k-mooneythere were some specs covering having pininned and shared cores on the same host this cycle. tesro and jay were talking about them in dublin.17:24
cfriesensean-k-mooney: with the new specs you still have to specify up-front which cpus are for which purpose17:25
sean-k-mooneycfriesen: right so you level them float but repin the floating vms wheever you spawn a new pinned vm17:25
sean-k-mooney*let them float17:26
cfriesensean-k-mooney: sort of.  the floating tasks are in a cpuset on the host, and we re-pin the cpuset (to avoid looping over all floating instances)17:27
cfriesenbut logically it's equivalent17:27
sean-k-mooneyany yes i realise you have to specify up front. with the approch ye took ye still set a minium amount of cores that could be used for the non pinned host right? or did you calulate it based on the oversubsction ratio17:27
cfriesensean-k-mooney: allocation ratio17:27
*** sahid has quit IRC17:27
jaypipessean-k-mooney: what's pininned cores? :P17:28
mriedemcfriesen: yeah i figured that was the reason17:28
mriedem2 node edge site17:28
mriedemor whatever 'grouse' is17:28
sean-k-mooneyjaypipes: its my getting used to my keyboard :)17:28
jaypipes:)17:28
jaypipesswitched to dvorak?17:28
mriedemcfriesen: grouse install is what, single node?17:28
sean-k-mooneyha no i have a corsair mechanical keyboard that i bought like a year ago but i used to the crappy membrane keyboard i used to use at work17:29
sean-k-mooneyi can type way faster now but also im makeing some mistakes i didnt before so hopefully in a week or so i will be used to it17:30
cfriesenmriedem: those names are all newly-invented, have to go look17:31
cfriesenbut we support single-node, duplex single-node, and multi-node with two controller nodes17:31
mriedemit goes grouse, something something, and then something with an R in the name17:32
mriedemcanadian mountain ranges17:32
cfriesenrobson, I think.   Pretty much invented right before the summit. :)17:32
mriedemhttps://youtu.be/Z1DN41WnRkc?t=56017:33
mriedemgrouse, whistler, robson17:33
cfriesenthere we go.  the two-controller case uses replicated storage for improved availability17:34
openstackgerritMatt Riedemann proposed openstack/nova master: Remove old check_attach version check in API  https://review.openstack.org/58834817:36
openstackgerritEric Fried proposed openstack/nova master: [placement] Debug log per granular request group  https://review.openstack.org/58835017:38
sean-k-mooneycfriesen: ya 3 dedicated contoler nodes is major overkill in many cases but alot of people still default to it17:43
openstackgerritMerged openstack/nova master: Remove unused stubbing function from test  https://review.openstack.org/58696817:44
openstackgerritMerged openstack/nova master: Improve NeutronFixture and remove unncessary stubbing  https://review.openstack.org/58741217:44
openstackgerritEric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures  https://review.openstack.org/58459317:57
*** itlinux has joined #openstack-nova18:04
*** sambetts is now known as sambetts|afk18:16
mnaserso i noticed that18:20
mnaserhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/volume.py#L62-L7918:20
mnaserand18:20
mnaserhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L168-L17618:20
mnaseris pretty much the same thing repeated18:21
mnaserone does it for volumes, the other does it for 'imagebackend' aka nova "images"18:21
mnaserwould moving the method to nova.virt.libvirt.utils make sense?18:22
mnaseror maybe moving it into a function inside LibvirtConfigGuestDisk ?18:23
melwittmaybe. if you think there's a common utility method both could use18:27
melwittthey look similar but not sure if they're doing the exact same thing18:27
mnasermelwitt: they're pretty much both setting quotas, one handles the quotas that are extra_specs in flavor, the other one handles setting quotas that are from nova volumes18:28
*** artom has quit IRC18:32
melwittmnaser: I see. yeah, I dunno where the common method should go. utils seems like the place, as for LibvirtConfigGuestDisk I'd ask lyarwood or mdbooth (they are EU time zone)18:39
mriedemcfriesen: there wasn't any upstream equivalent for this per-instance live migration max downtime feature was there? i know about https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/live-migration-per-instance-timeout.html but that's for per-instance live migration timeout which is different.18:45
openstackgerritEric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST  https://review.openstack.org/57692718:53
openstackgerritEric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories  https://review.openstack.org/58503318:53
openstackgerritEric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane  https://review.openstack.org/58459818:53
openstackgerritEric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer  https://review.openstack.org/58459918:53
openstackgerritEric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree  https://review.openstack.org/58464818:53
openstackgerritEric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump  https://review.openstack.org/58503418:53
openstackgerritEric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape  https://review.openstack.org/58504918:53
openstackgerritEric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees  https://review.openstack.org/57623618:53
openstackgerritEric Fried proposed openstack/nova master: WIP: only _init_compute_node on startup  https://review.openstack.org/58809418:53
openstackgerritEric Fried proposed openstack/nova master: WIP: Remove redundant _update()s  https://review.openstack.org/58809118:54
openstackgerritMerged openstack/nova master: Wait for vif plugging during live migration job  https://review.openstack.org/57855119:03
openstackgerritMerged openstack/nova master: Stop setting glance_api_version in cinder.conf in nova-live-migration  https://review.openstack.org/57987119:03
openstackgerritMerged openstack/nova master: doc: fix resize user guide link  https://review.openstack.org/58809719:03
openstackgerritMerged openstack/nova master: Hyper-V + OVS: plug vifs before starting VMs  https://review.openstack.org/58566119:06
openstackgerritMerged openstack/nova master: Complete the api-ref of security group rule  https://review.openstack.org/58010919:06
*** mgariepy has quit IRC19:14
*** artom has joined #openstack-nova19:30
openstackgerritEric Fried proposed openstack/nova master: Grease test_try_deallocate_network_retry_direct  https://review.openstack.org/58836419:31
*** awaugama has quit IRC19:35
*** cdent has quit IRC19:35
*** avolkov has quit IRC19:35
*** artom has quit IRC19:38
*** eharney has quit IRC19:44
cfriesenmriedem: was having lunch.  I don't think there's any upstream equivalent.  I think that was added for existing pets that were created using flavor with too small of a max-downtime.  I seem to recall discussing it upstream, but the concensus was that it would make more sense to add it as a parameter to the live-migration call.19:51
mriedemcfriesen: that was exactly my question - why put it on the flavor/image rather than just directly in the live migration api19:52
mriedemi guess because bigger flavors/images could need more downtime?19:52
cfriesenmriedem: it was less code to do it this way, and no on-the-wire API change19:53
cfriesenmriedem: it'd be cleaner as part of the migration request19:54
mriedemwell, there are plenty of "if wrs-header: do extra stuff"19:54
mriedembut yeah, input validation on the api schema i guess19:54
mriedemnixes that19:54
mriedemalso, all of this cpu cache stuff...19:54
mriedemi can't wrap my head around this19:54
openstackgerritMerged openstack/nova master: Fix all invalid obj_make_compatible test case  https://review.openstack.org/57424019:55
cfriesenmriedem: the live migration stuff came out of a live customer issue, as I recall they wanted a quick fix that was backportable to an earlier release.19:55
cfriesenThe CPU cache stuff...I think that's the Intel CAT stuff.19:56
cfriesenequivalent to this: https://blueprints.launchpad.net/nova/+spec/cat-support19:56
*** maciejjozefczyk has joined #openstack-nova19:58
mriedemok, not much in there - no spec proposed it looks like19:59
openstackgerritMatt Riedemann proposed openstack/nova master: Scrub hw:cpu_model from API samples  https://review.openstack.org/58837120:02
mriedemsw:wrs:srv_grp_messaging huh20:03
cfriesenyou can probably ignore the server group messaging stuff...it's probably getting removed20:06
mriedemjesus, ok, so servers within the same group can send messages to each other through a channel on the host?20:06
cfriesenyeah, the idea was to have a low-bandwidth really easy way to message other serves in the group20:07
*** maciejjozefczyk has quit IRC20:07
openstackgerritEric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures  https://review.openstack.org/58459320:07
cfriesenended up being more hassle than it was worth20:07
mriedemwho. would. have. thought.20:07
cfriesenbut we use the same host/guest backchannel for the cpu scaling code20:07
cfriesen:)20:07
mriedemi see that20:07
cfriesendoing it now, cpu scaling would use virtio-vsock20:08
mriedemwas that server group thing only for affinity groups?20:08
mriedemit would have to be right?20:08
mriedemon the same host20:08
cfriesenno, it would send the message back to the controller to redistribute to other compute nodes20:09
mriedemoh right,20:09
mriedemforgot the rpc cast20:09
*** masayukig has quit IRC20:18
*** sambetts|afk has quit IRC20:28
*** sambetts_ has joined #openstack-nova20:29
mriedemcfriesen: where does upstream nova actually support live migration with macvtap pci devices? i don't see anything specific about hat20:33
mriedem*that20:33
mriedemhttps://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-6c3b14d3964eb808ade9d3e7c5d4676dR10420:34
*** hamzy has quit IRC20:40
cfriesenmriedem: https://docs.openstack.org/neutron/pike/admin/config-macvtap.html and https://bugs.launchpad.net/neutron/+bug/155040020:45
openstackLaunchpad bug 1550400 in neutron "Macvtap driver/agent migrates instances on an invalid physical network" [Medium,In progress] - Assigned to Andreas Scheuring (andreas-scheuring)20:45
*** takashin has joined #openstack-nova20:48
mriedemhmm, that's marked in progress20:48
mriedemdoes it actually work?20:48
mriedemoh i see,20:49
cfriesenAccording to the first link, "Instance migration requires the same values for the physical_interface_mapping configuration option on each compute node."20:49
mriedemhuh does that rely on the migrating_to attribute we set in the port binding dict during live migration?20:49
cfriesenno clue...you'll see our code comment says macvtap isn't supported in Titanium Cloud20:50
cfriesenI haven't played with it20:50
mriedemyup i saw that20:50
mriedemthat limit on servers per group is also a bit strange,20:50
mriedemgiven we have the server_group_members quota20:51
mriedemwhich is global unless you override it per tenant i think?20:51
mriedemoh i guess server_group_members is per user20:51
cfriesenper group20:51
cfriesenoh, you mean the quota20:52
mriedemyeah20:52
cfriesenwe're getting rid of the server group size I think, trying to align with upstream20:52
mriedemwell i was just thinking of alternatives there,20:53
mriedemi.e. you could limit the max members per group using quota which can be overridden20:53
mriedemso your high $$ users get higher quota20:53
melwittnova meeting in 7 minutes20:53
openstackgerritEric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator  https://review.openstack.org/58839120:53
cfriesenoriginally we implemented it when server group metadata was still a thing, or looked like it would be a thing.20:54
mriedemyeah, which was probably forever ago20:54
mriedemso server groups are per-tenant, and then you can override the quota to say like user A in group 1 can have 4 members in a group and user B in group 1 can have 220:54
openstackgerritEric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator  https://review.openstack.org/58839120:55
mriedemuser A in tenant 1 i meant20:55
efriedmelwitt: Since you expressed interest, I tracked down a couple more --^20:55
melwittthanks20:55
cfriesenmriedem: I thought we were getting rid of user quotas20:55
mriedemthat's news to me20:56
mriedemoh, with moving to unified limits?20:56
melwittwe've talked about it several times but people keep getting confused, I think20:56
melwittI think even unified limits added 'user' to their stuff because they thought we needed it20:56
mriedem:/20:57
melwittwe "need" user only if we want to keep the legacy stuff the way it has been, going forward20:57
cfriesenI mean, servers are owned by projects so it seems weird that some users would be able to make new ones and others in the same project wouldn't.20:57
mriedemcern needed user-level quota for working around nova not having hierarchical quota support, iirc20:57
melwittyeah, that is my understanding as well20:58
mriedemdoes unified limits give us hierarchical quota support?20:58
melwittit was a hack to get two level hierarchical20:58
mriedemi thought it was just part of the puzzle20:58
melwittyes, that's what the keystone team is working on20:58
*** gbarros has joined #openstack-nova20:58
sean-k-mooneycfriesen: users can have multiple project however so you may want to have per project limits and a limit for the user in general20:58
mriedemw/o lbragstad or someone from keystone actually working on the nova changes, i don't know if/when that will ever get done in nova20:58
*** priteau has quit IRC20:59
melwittI'm interested in working on it. I've been attending the unified limits and hierarchical sessions at PTG/summits. I added an item for the Stein PTG etherpad about unified limits, if we think we're ready to move to them for the limit piece21:00
* lbragstad lingers21:00
mriedemmelwitt: you'd probably be best to lead that given your work on the quota stuff21:01
sean-k-mooneymelwitt: its been a topic for a few releases on and off right? do you see any obvious blockers?21:01
lbragstadfwiw - the implementation for strict-two-level landed in keystone this release, so that's done21:01
lbragstadwe're still working on some changes for the oslo.limit library though (we need to implement support for querying keystone for limits and doing the math)21:02
lbragstad^ that's really the last bit before people can start incorporating it into their services21:02
sean-k-mooneylbragstad: i would guess nova will have some requirement that other project wont have related to cells21:02
lbragstadyeah - i would agree21:03
lbragstadand i'm curious to flush those out as we go21:03
lbragstadi assume that's going to have an impact on implementing unified limit support for instances, yeah?21:04
sean-k-mooneylbragstad: ya there are some edge case to knowing if you are at or below quota if connect to a cell goes down21:05
lbragstadhuh - interesting21:05
sean-k-mooneyit would be similar to the problem you would have with keysone federattion if you lost the connection to a remote cloud and contiued to consume resoces on the local cloud and then it came back21:05
lbragstadoh - sure21:06
sean-k-mooneywhile the connect is broken you could exceed the gloabl limt. then the question is how to hanelit when you get the full view again21:06
lbragstadright...21:06
sean-k-mooneymost other project dont shard there resocue view teh same way nova can with cells so ya im sure nova will find edgecases21:07
lbragstadi guess the way we've been thinking about that (originally something sdague thought of)21:07
lbragstadwas to just keep things as they are, reject new claims, and give the user an opportunity to clean things up or escalate to an administrator21:07
* melwitt in the nova meeting atm21:08
sean-k-mooneyya that seams like the sane think to do atleast at first until operator start telling us to do something else21:08
mriedemcfriesen: heh https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-1aca090de4ab90afbc1c8d84b13a56f7R478 - i think that is one condition too late :)21:15
mriedemby the time that runs, i think we've already dos'ed neutron21:16
*** tbachman has quit IRC21:23
sean-k-mooneymelwitt: quick question regardign os-vif stable releases. do you make them when you make sable release of nova?21:26
melwittsean-k-mooney: usually yes. around and after the third milestone is different because of the release freezes21:27
melwittIIUC, we are frozen from doing stable/rocky releases until stein opens21:28
sean-k-mooneymelwitt: ok there are a few test/tox fixes that would be nice to backport but nothing functional21:28
*** mriedem is now known as mriedem_afk21:28
melwittsean-k-mooney: I see. I actually requested a FFE for the noop plugin loading bug that got approved, so I released 1.11.1 from the stable/rocky branch recently21:29
sean-k-mooneylike https://review.openstack.org/#/c/567942/ to run all of the py27 unit test instead of only a subset.21:29
sean-k-mooneyoh cool21:29
melwittI see. we can release stable/queens at any time, but I'm not sure how releasing the tox fix will help anyone? just needs to make it into the stable/queens branch right? for developers to benefit21:30
melwittoh, because it runs in a CI job21:31
sean-k-mooneyya21:31
sean-k-mooneyits to make sure we dont backport stuff that breakes py2721:31
sean-k-mooneythat said all the unit tests are running under by 3521:31
sean-k-mooney*py3521:31
melwittokay, since that's queens I think that's okay. if you want to do a release for an older stable branch, you can just propose it and let me know so I can ack it21:32
melwittsmcginnis: can you sanity check me on that? ^21:33
melwittis it okay to release stable/queens for non-client libraries during freeze? is freeze only for rocky or for all branches?21:33
sean-k-mooneywell in this case its more to highlight the fact that there are some pendign stable/X backports and that im not sure if the nova stable team reguraly checks os-vif21:34
melwittpending as in, not merged?21:34
sean-k-mooneyyes21:34
melwittokay. just have to let people (stable cores) know to take a look if there's something important there21:35
sean-k-mooneysuch as this one for pike from december that i proosed back in january and got a +2 from mriedem_afk  4 months ago https://review.openstack.org/#/c/531465/21:35
smcginnismelwitt: Yep, that looks right. Freeze just applies to rocky work.21:37
melwittsmcginnis++21:37
sean-k-mooneyi have core rights on master not the sable/branches so while i do flag pending backports to the nova sable  team every now and then there is not much more i can do if they dont get reviewed21:37
sean-k-mooneyanyway there is nothing breakign the gate or that customer are screaming about that im aware of so just an FYI21:38
melwittsean-k-mooney: okay, thanks for letting me know. I'll see if I can find someone for the second +2s21:39
*** gbarros has quit IRC21:41
openstackgerritMerged openstack/os-vif stable/pike: Check if interface belongs to a Linux Bridge before removing  https://review.openstack.org/53146521:46
melwitttonyb: fancy reviewing a os-vif backport to fix their tox py27 job? https://review.openstack.org/56794221:46
tonybmelwitt: done21:47
melwittthank you sir21:47
tonybmelwitt: no problem at all21:47
*** itlinux has quit IRC21:54
sean-k-mooneytonyb: thanks.21:54
tonybsean-k-mooney: np.  It's my very minor super power ;P21:55
sean-k-mooneyby the way looking at http://ci-watch.tintri.com/project?project=nova&time=7+days i do not see teh intel nfv ci. https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI has not been updated since febuary. anyone rememebr the last time they saw it comment on something?21:56
openstackgerritMerged openstack/os-vif stable/queens: fix tox py27 job  https://review.openstack.org/56794221:56
melwittsean-k-mooney: can't remember. it's been awhile21:57
sean-k-mooneyi have been waiting for it to comment on some change i was doing to networking-ovs-dpdk... i guess ill jsut do the testing myself.21:58
tonybsean-k-mooney: If you really cared to find out you could add the notes ref to you nova repo and then grep the notes for a comment from that CI21:59
tonybit *might* work21:59
sean-k-mooneytonyb: oh? im not sure i follow22:00
tonybsean-k-mooney: gimme 5 to find a link22:00
sean-k-mooneyas in a gerrit query for a reviewer?22:00
tonybsean-k-mooney: Oh you could do that as well22:01
melwittoh yeah, good idea22:01
tonybsean-k-mooney: So looking at https://git.openstack.org/cgit/openstack/nova/commit/?id=2499f616094f63ed0a1a3c201789d14cc61a62c422:02
tonyb'notes' get added to each review based on code-reviews.  they're in a seperate ref22:02
*** mchlumsky has quit IRC22:02
tonybso you can just add that ref to your nova repo and then when you do git show on a SHA you'll get to see the reviewers22:03
tonybso the CI votes (but not comments) would be included.22:03
tonybhttps://review.openstack.org/#/q/reviewedby%3Aintel-nfv-ci22:04
tonyblook slike it's still voting22:04
sean-k-mooneymaybe what does exception meen next to a ci comment https://review.openstack.org/#/c/584829/22:05
tonybsean-k-mooney: Oh it means it's voting but not doign anythign helpful ;P22:06
sean-k-mooneyah it makes perfect sense lol22:07
tonyb;p22:07
tonybsean-k-mooney: Let me see if I can find the last time it voted +122:08
tonybsean-k-mooney: Nope my gerrit fu is weak right now.  I'll grab some coffee and try again22:10
sean-k-mooneywell looking at the log server it has not uploaded anything sice the 18th http://52.27.155.124/portland/2018-07-1822:11
sean-k-mooneytonyb: thanks for trying in anycase. i might reach out and ask what the status is.22:13
openstackgerritTakashi NATSUME proposed openstack/nova master: Reno for notification-transformation-rocky  https://review.openstack.org/58840322:20
*** rcernin has joined #openstack-nova22:32
melwittlbragstad: sorry for the delayed reply, but yeah what I was thinking was to look at migrating to keystone limits in stein, not yet going for the enforce part. johnthetubaguy had also mentioned that a two-stage approach to the migration might make migration easier from an operator perspective but I didn't understand that bit22:35
melwittwe have other work we'd like to do like be able to set quota limits for custom resource classes and where we're at right now, we could do that via our existing quota classes API, but then that will leave more to have to migrate to keystone limits when we move. so I was thinking maybe we should move to keystone limits first, then let the limits piece of custom resource class quotas be covered by unified limits, and all we do on our22:38
melwitt side is the enforce with what we already have. then next stage will be to move to oslo.limit for enforcement22:38
*** hongbin_ has quit IRC22:39
lbragstadinteresting melwitt22:43
lbragstadso - you'd query keystone directly for limit information as opposed to using oslo.limit?22:43
melwittyeah. I actually didn't know the limit query was supposed to go through oslo.limit. if it does, we could do that, I just missed it or forgot22:44
melwittor are you saying limit + enforce are coupled?22:44
melwittin oslo.limit22:45
lbragstadtechnically - it probably doesn't _have_ to go through oslo.limit, but that's where we were going to hide all the logic that understands the project tree22:45
melwittright okay22:45
tonybsean-k-mooney: Ahh when it votes it doens't actually 'vote' it just leaves a comment so it's back to groveling in the review metadata :(22:45
lbragstadmelwitt: i'm trying to map terms, but i was under the assumption that enforcement would be a requirement?22:45
openstackgerritEric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST  https://review.openstack.org/57692722:45
openstackgerritEric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories  https://review.openstack.org/58503322:45
openstackgerritEric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane  https://review.openstack.org/58459822:45
openstackgerritEric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer  https://review.openstack.org/58459922:45
openstackgerritEric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree  https://review.openstack.org/58464822:45
openstackgerritEric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump  https://review.openstack.org/58503422:45
openstackgerritEric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape  https://review.openstack.org/58504922:45
openstackgerritEric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees  https://review.openstack.org/57623622:45
openstackgerritEric Fried proposed openstack/nova master: WIP: Remove redundant _update()s  https://review.openstack.org/58809122:45
lbragstadif not - then it sounds like something we can build into oslo.limit or consider supporting (since it's the thing raise exceptions to the service)22:46
melwittlbragstad: it is, sorry. I mean whether it's one call or two calls in oslo.limit to do limits vs enforce22:46
lbragstadoh - the thing that protects against race conditions?22:46
melwittsorry, I think I'm confusing things and I haven't looked at the POC code in awhile22:47
lbragstadthe skeleton of oslo.limit has that implemented in the context manager https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L60-L6222:47
melwittah, yeah I remember now22:48
lbragstadhttps://github.com/openstack/oslo.limit/blob/master/oslo_limit/tests/test_limit.py#L96 probably helps visualize things a bit, too22:48
lbragstadfrom a usage perspective anyway22:48
melwittthanks22:49
lbragstadthis stuff will get implemented soon, since this is where the code the calculates the limits wrt the tree https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L81-L8522:49
lbragstad(implementation detail of the context manager though)22:49
melwittand that will also pull the limits from keystone?22:49
lbragstadyep - exactly22:50
lbragstadwhen you enter the context manager, it should query keystone for the limits and do calculations based on the claims your making22:50
melwittah, I see. I think I jumped the gun then. for some reason I was thinking we could move to using keystone limits only, as a first step, and then start doing the oslo.enforcement in a second separate step22:50
lbragstadthen __exit__ will do error handling in the event there was a race condition and verify = True22:50
melwittfrom a project perspective22:51
lbragstadaha - sure22:51
lbragstadhopefully it's only one step for you22:51
lbragstad(unless there is a good reason to break things up a bit?)22:51
melwittno, I don't think there is. just ignorance on my part22:51
lbragstadit's a lot of moving pieces =/22:51
melwittyeah, for sure22:52
lbragstadwe were waiting on an APi to return the project heirarchy with limit data associated to it (landed in rocky)22:52
lbragstadnow that's in, we can start working on finishing up the implementation of that context manager22:52
lbragstad(i'm hoping to start that soon)22:52
melwitton our side we have to decide whether to go ahead with the custom resource classes quotas by using our own quota classes API or wait for oslo.limit22:53
lbragstadi can bump the oslo.limit impl up on my priority list if it helps give you all a definitive direction22:54
lbragstad(if support in oslo.limit is the question)22:54
melwitthave to dig in more on what's the cost of that. might not be much actually because we can leverage our own old API for doing it. it's just then we'd have to migrate whatever quota classes people have created over to keystone limits. but we have to do that regardless so maybe it's not much extra cost22:55
lbragstadsure22:55
lbragstadi think i see what you mean22:55
melwittlbragstad: re: the comments on our PTG etherpad, there is already support for user_id right? as shown on this doc? https://docs.openstack.org/keystone/queens/admin/identity-unified-limits.html23:00
melwittwe've had discussions with operators in the past and there was consensus that user_id isn't useful if hierarchy is possible, but I don't know if/how we could change the semantics of our existing quotas. so I'm thinking of what's possible if we *don't* change semantics23:02
*** takashin has left #openstack-nova23:02
*** mschuppert has quit IRC23:04
*** tbachman_ has joined #openstack-nova23:05
*** tbachman_ is now known as tbachman23:06
*** edmondsw has quit IRC23:08
*** jaypipes has quit IRC23:14
*** jaypipes has joined #openstack-nova23:16

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