*** dave-mccowan has quit IRC | 00:02 | |
*** dr_gogeta86 has quit IRC | 00:04 | |
*** namnh has joined #openstack-nova | 00:04 | |
*** edmondsw has joined #openstack-nova | 00:07 | |
*** dr_gogeta86 has joined #openstack-nova | 00:07 | |
*** ivve has quit IRC | 00:08 | |
*** clarkb has quit IRC | 00:09 | |
*** namnh has quit IRC | 00:10 | |
*** gyee has quit IRC | 00:11 | |
*** edmondsw has quit IRC | 00:12 | |
*** _ix has joined #openstack-nova | 00:15 | |
*** hongbin has joined #openstack-nova | 00:22 | |
*** dave-mccowan has joined #openstack-nova | 00:22 | |
*** mriedem has quit IRC | 00:29 | |
*** _ix has quit IRC | 00:36 | |
*** dave-mccowan has quit IRC | 00:55 | |
*** EmilienM has quit IRC | 01:02 | |
*** jangutter has quit IRC | 01:03 | |
*** EmilienM has joined #openstack-nova | 01:04 | |
*** namnh has joined #openstack-nova | 01:08 | |
*** trozet has quit IRC | 01:08 | |
*** jangutter has joined #openstack-nova | 01:09 | |
*** mrsoul has quit IRC | 01:10 | |
*** namnh has quit IRC | 01:13 | |
*** links has joined #openstack-nova | 01:15 | |
*** itlinux_ has quit IRC | 01:26 | |
*** edmondsw has joined #openstack-nova | 01:29 | |
*** namnh has joined #openstack-nova | 01:35 | |
*** liuzz_ has quit IRC | 01:35 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Use common functions in granular fixture https://review.openstack.org/588113 | 01:39 |
---|---|---|
*** liuzz has joined #openstack-nova | 01:41 | |
*** dave-mccowan has joined #openstack-nova | 01:47 | |
*** Kevin_Zheng has quit IRC | 01:49 | |
*** edmondsw has quit IRC | 01:50 | |
*** edmondsw has joined #openstack-nova | 01:51 | |
*** edmondsw has quit IRC | 01:55 | |
*** namnh has quit IRC | 01:59 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Use common functions in NonSharedStorageFixture https://review.openstack.org/588114 | 02:01 |
*** namnh has joined #openstack-nova | 02:08 | |
*** Dinesh_Bhor has joined #openstack-nova | 02:19 | |
*** psachin has joined #openstack-nova | 02:21 | |
openstackgerrit | Merged openstack/nova master: Make ResourceTracker.stats node-specific https://review.openstack.org/587636 | 02:30 |
*** links has quit IRC | 02:37 | |
*** Dinesh_Bhor has quit IRC | 02:39 | |
*** yikun_ has quit IRC | 02:57 | |
*** vivsoni_ has quit IRC | 02:59 | |
*** gcb has quit IRC | 03:07 | |
*** Guest43757 has quit IRC | 03:08 | |
openstackgerrit | Vishakha Agarwal proposed openstack/nova master: 'Updated_at' is NULL when show aggregate info https://review.openstack.org/580271 | 03:13 |
*** edmondsw has joined #openstack-nova | 03:19 | |
*** edmondsw has quit IRC | 03:24 | |
*** fanzhang_ is now known as fanzhang | 03:25 | |
*** Dinesh_Bhor has joined #openstack-nova | 03:28 | |
*** dave-mccowan has quit IRC | 03:33 | |
*** namnh has quit IRC | 03:44 | |
*** udesale has joined #openstack-nova | 03:46 | |
*** hongbin has quit IRC | 03:46 | |
*** Dinesh_Bhor has quit IRC | 04:08 | |
*** artom has quit IRC | 04:33 | |
*** Bhujay has joined #openstack-nova | 04:38 | |
*** janki has joined #openstack-nova | 04:56 | |
*** fnordahl has joined #openstack-nova | 05:05 | |
*** Dinesh_Bhor has joined #openstack-nova | 05:05 | |
*** ratailor has joined #openstack-nova | 05:31 | |
*** Luzi has joined #openstack-nova | 06:12 | |
*** ccamacho has joined #openstack-nova | 06:16 | |
*** udesale has quit IRC | 06:23 | |
openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Fix a typo in comment in resource_provider.py https://review.openstack.org/588145 | 06:26 |
*** adrianc_ has joined #openstack-nova | 06:37 | |
*** Dinesh_Bhor has quit IRC | 06:37 | |
*** hoonetorg has quit IRC | 06:42 | |
*** Kevin_Zheng has joined #openstack-nova | 06:45 | |
*** cfriesen__ has quit IRC | 06:46 | |
*** liuyulong has joined #openstack-nova | 06:52 | |
*** hoonetorg has joined #openstack-nova | 06:54 | |
openstackgerrit | huanhongda proposed openstack/nova master: Destroy evacuated instance while unset nova-compute forced_down https://review.openstack.org/587807 | 06:58 |
*** Dinesh_Bhor has joined #openstack-nova | 07:02 | |
*** rcernin has quit IRC | 07:03 | |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Increase max_unit in placement test fixture https://review.openstack.org/588158 | 07:14 |
openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Refactor AllocationFixture in placement test https://review.openstack.org/588159 | 07:14 |
*** kashyap has quit IRC | 07:18 | |
*** adrianc_ has quit IRC | 07:22 | |
*** adrianc__ has joined #openstack-nova | 07:23 | |
*** gouthamr has quit IRC | 07:36 | |
*** liuzz has quit IRC | 07:36 | |
*** ekhugen has quit IRC | 07:45 | |
*** Tahvok has quit IRC | 07:45 | |
*** strigazi has quit IRC | 07:45 | |
*** mvk_ has quit IRC | 07:46 | |
*** eandersson has quit IRC | 07:46 | |
*** Tahvok has joined #openstack-nova | 07:46 | |
jaosorior | gibi: do unversioned notifications still work to date? or are they already being deprecated? | 07:58 |
*** jpena|off is now known as jpena | 08:12 | |
*** avolkov has joined #openstack-nova | 08:18 | |
jaosorior | or anybody that knows about notifications ^^ | 08:20 |
*** tssurya has joined #openstack-nova | 08:26 | |
gibi | jaosorior: hi! unversioned still works, not even deprecated yet | 08:36 |
gibi | jaosorior: we still have couple of unversioned notificatons that does not have versioned pair https://review.openstack.org/588097 | 08:37 |
gibi | jaosorior: I mean http://burndown.peermore.com/nova-notification/ | 08:37 |
*** rabel has joined #openstack-nova | 08:37 | |
rabel | hi 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-nova | 08:42 | |
*** udesale has joined #openstack-nova | 08:46 | |
*** joxyuki___ has joined #openstack-nova | 08:48 | |
*** cdent has joined #openstack-nova | 08:49 | |
*** joxyuki___ has left #openstack-nova | 08:50 | |
*** tetsuro_ has joined #openstack-nova | 08:56 | |
*** tetsuro_ is now known as tetsuro | 08:57 | |
*** tetsuro is now known as tetsuro_ | 08:57 | |
*** tetsuro_ has left #openstack-nova | 08:57 | |
*** tetsuro__ has joined #openstack-nova | 08:59 | |
*** tetsuro__ has quit IRC | 08:59 | |
*** tetsuro_ has joined #openstack-nova | 08:59 | |
*** pcaruana has joined #openstack-nova | 09:00 | |
*** tetsuro_ has quit IRC | 09:02 | |
*** tetsuro_ has joined #openstack-nova | 09:04 | |
*** tetsuro_ has quit IRC | 09:04 | |
*** Bhujay has quit IRC | 09:11 | |
*** maciejjozefczyk has quit IRC | 09:13 | |
*** maciejjozefczyk has joined #openstack-nova | 09:19 | |
*** ejat has joined #openstack-nova | 09:22 | |
*** mschuppert has joined #openstack-nova | 09:25 | |
*** adrianc__ has quit IRC | 09:42 | |
*** edmondsw has joined #openstack-nova | 09:48 | |
*** hoonetorg has quit IRC | 09:54 | |
*** maciejjozefczyk has quit IRC | 10:07 | |
*** hoonetorg has joined #openstack-nova | 10:09 | |
*** adrianc__ has joined #openstack-nova | 10:11 | |
*** aloga has quit IRC | 10:12 | |
*** maciejjozefczyk has joined #openstack-nova | 10:25 | |
*** maciejjozefczyk has quit IRC | 10:26 | |
*** dtantsur|afk is now known as dtantsur | 10:32 | |
sean-k-mooney | rabel: 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 sevices | 10:32 |
sean-k-mooney | rabel: the conductor and compute agents also talk direct to neutron,glance cinder... as far as i know | 10:33 |
stephenfin | sean-k-mooney: You work the weirdest hours | 10:36 |
stephenfin | :) | 10:36 |
openstackgerrit | Merged openstack/nova master: Add note about reschedules and num_attempts in filter_properties https://review.openstack.org/582412 | 10:36 |
openstackgerrit | Stephen Finucane proposed openstack/nova master: tox: Ensure reused envdirs share the same deps https://review.openstack.org/588207 | 10:37 |
stephenfin | gibi: Fancy taking a look at that ^ I made a silly mistake :( | 10:37 |
*** vivsoni has joined #openstack-nova | 10:39 | |
sean-k-mooney | stephenfin: yes i do | 10:39 |
*** crazik has joined #openstack-nova | 10:40 | |
sean-k-mooney | stephenfin: anything in particalar more weird then usual | 10:40 |
*** crazik has left #openstack-nova | 10:40 | |
stephenfin | sean-k-mooney: Nope. Just a general observation :) | 10:40 |
sean-k-mooney | stephenfin: what time zone am i in lol http://stackalytics.com/report/users/sean-k-mooney | 10:41 |
sean-k-mooney | stephenfin: our activity reporst are totally different http://stackalytics.com/report/users/stephenfinucane | 10:42 |
stephenfin | Hahaha | 10:43 |
stephenfin | 9-5, baby | 10:43 |
cdent | stephenfin: we should all be a bit more like you | 10:44 |
sean-k-mooney | stephenfin: 9 pm to 5 am i could do that :) | 10:44 |
*** maciejjozefczyk has joined #openstack-nova | 10:46 | |
sean-k-mooney | cdent: yours is much more like mine http://stackalytics.com/report/users/cdent | 10:46 |
* cdent nods | 10:46 | |
* cdent must try harder | 10:46 | |
cdent | it's a job, not an adventure | 10:46 |
openstackgerrit | Chen proposed openstack/nova master: Make nova-manage db archive_delete_rows take --all-cells https://review.openstack.org/587858 | 10:48 |
sean-k-mooney | the 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 relaxing | 10:49 |
stephenfin | cdent, 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 IRC | 10:49 | |
stephenfin | It's doubly impressive when those people have families that surely take a good chunk of their time/attention | 10:49 |
* stephenfin casts an eye towards mriedem, bauzas, alex_xu et al | 10:50 | |
sean-k-mooney | stephenfin: hehe you assume i go to a gym and socialize. silly person :P | 10:50 |
cdent | stephenfin: well there ya go: I don't go to the gym, eat decent food, or socialize | 10:50 |
cdent | which is why I need to do better, I really need to do all those things | 10:50 |
stephenfin | sean-k-mooney: Heh, fair enough | 10:51 |
cdent | luckily my kids are all old, so they don't suffer my failings (at least not these) | 10:51 |
stephenfin | cdent: I think efried does it best. Not only does he go to a gym (of sorts) but he manages to run one | 10:51 |
stephenfin | cdent: Aye, I should have clarified with young families | 10:52 |
openstackgerrit | huanhongda proposed openstack/nova master: Destroy evacuated instance while unset nova-compute forced_down https://review.openstack.org/587807 | 10:52 |
stephenfin | cdent: 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 |
stephenfin | In particular, https://bitbucket.org/ianb/paste/pull-requests/41/ | 10:54 |
cdent | hmmm. yeah. | 10:54 |
cdent | Ideally we'd stop using paste and manage middleware differently, but that's not a change we could make overnight | 10:54 |
sean-k-mooney | i was going to ask what do we use it for? | 10:55 |
stephenfin | Indeed. 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-nova | 10:56 | |
sean-k-mooney | is this what the api-past.ini files are for? | 10:56 |
cdent | sean-k-mooney: that's what paste (the lib) reads | 10:57 |
sean-k-mooney | oh we use it in the wsgi scripts. | 10:57 |
cdent | it configured the middlware stack in noav-api | 10:57 |
*** Dinesh_Bhor has quit IRC | 10:58 | |
cdent | other projects use it too. placement intentionally chose not to use it because it intentionally doesn't have configurable middleware: you get what you're given | 10:58 |
sean-k-mooney | cdent: do we test reconfiguring the middelware in nova? | 10:59 |
cdent | I don't know | 10:59 |
stephenfin | cdent: 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 |
stephenfin | I'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 now | 11:01 |
* stephenfin drafts mail to openstack-dev | 11:01 | |
sean-k-mooney | stephenfin: well will it. i have not heard anyone seriously suggesting more the 3.6 support | 11:02 |
cdent | I'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 him | 11:02 |
sean-k-mooney | ubuntu 18.04 will be sticking with 3.6 as far as i know | 11:02 |
stephenfin | cdent: ack | 11:02 |
cdent | (when I say TC crowd I mostly mean doug) | 11:02 |
stephenfin | ack ack :) | 11:02 |
*** jpena is now known as jpena|lunch | 11:04 | |
*** wolsen has quit IRC | 11:04 | |
*** jamespage has quit IRC | 11:04 | |
*** fmccarthy has quit IRC | 11:04 | |
*** rajinir has quit IRC | 11:04 | |
*** lamt has quit IRC | 11:04 | |
*** auggy has quit IRC | 11:04 | |
*** sergek_ has quit IRC | 11:04 | |
*** simondodsley_ has quit IRC | 11:04 | |
*** simondodsley_ has joined #openstack-nova | 11:05 | |
*** zzzeek has quit IRC | 11:07 | |
rabel | sean-k-mooney: thanks! | 11:11 |
*** maciejjozefczyk has joined #openstack-nova | 11:12 | |
*** zzzeek has joined #openstack-nova | 11:13 | |
gibi | stephenfin: +2 on the tox.ini fix | 11:16 |
*** priteau has joined #openstack-nova | 11:19 | |
*** jangutter has quit IRC | 11:24 | |
*** udesale has quit IRC | 11:27 | |
*** dave-mccowan has joined #openstack-nova | 11:27 | |
*** tbachman has quit IRC | 11:31 | |
*** mdbooth has quit IRC | 11:32 | |
*** kuzko_ has quit IRC | 11:41 | |
*** mdbooth has joined #openstack-nova | 11:46 | |
*** ragiman has joined #openstack-nova | 11:49 | |
*** cdent has quit IRC | 11:59 | |
*** adrianc__ has quit IRC | 12:03 | |
*** vivsoni_ has joined #openstack-nova | 12:06 | |
*** vivsoni has quit IRC | 12:07 | |
*** tbachman has joined #openstack-nova | 12:14 | |
maciejjozefczyk | kosamara: hey, I can confirm that bug: https://bugs.launchpad.net/nova/+bug/1779845 | 12:19 |
openstack | Launchpad 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 |
maciejjozefczyk | kosamara: and in fact I just started to working on that point, but you were first ;) | 12:19 |
*** EmilienM has left #openstack-nova | 12:21 | |
*** mvenesio has quit IRC | 12:25 | |
openstackgerrit | Merged openstack/nova master: Hook resource_tracker to remove stale node information https://review.openstack.org/587922 | 12:34 |
*** jmlowe has quit IRC | 12:35 | |
bauzas | network issues at home, folks | 12:37 |
bauzas | just in case you need me | 12:37 |
sean-k-mooney | maciejjozefczyk: 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 prevent | 12:37 |
sean-k-mooney | maciejjozefczyk: but i do think we should allow it | 12:37 |
*** ragiman has quit IRC | 12:37 | |
bauzas | given we're in August and in France, can I hope my network issues to be fixed around Aug 29th ? | 12:38 |
sean-k-mooney | maciejjozefczyk: so really this is an RFE(request for enhancement) | 12:38 |
*** ratailor has quit IRC | 12:39 | |
*** s10 has joined #openstack-nova | 12:44 | |
sean-k-mooney | why dos our suspend fucntion in the libvirt diriver not suspend the instance ... | 12:45 |
*** sahid has joined #openstack-nova | 12:46 | |
maciejjozefczyk | sean-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 point | 12:50 |
stephenfin | bauzas: Fancy sending this on its way? https://review.openstack.org/588207 | 12:50 |
*** rabel has left #openstack-nova | 12:51 | |
*** tssurya has quit IRC | 12:51 | |
*** udesale has joined #openstack-nova | 12:51 | |
stephenfin | gibi: ta! | 12:52 |
sean-k-mooney | maciejjozefczyk: 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 sure | 12:52 |
openstackgerrit | Eric Fried proposed openstack/nova master: doc: fix resize user guide link https://review.openstack.org/588097 | 12:52 |
gibi | stephenfin: there are two relatively small refactor that https://review.openstack.org/#/c/586968/ and https://review.openstack.org/#/c/587412/ if you have some time | 12:52 |
stephenfin | gibi: I'll hit those right now | 12:53 |
sean-k-mooney | maciejjozefczyk: 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 |
openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove unused stubbing function from test https://review.openstack.org/586968 | 12:53 |
*** tssurya has joined #openstack-nova | 12: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-nova | 12:57 | |
stephenfin | gibi: Could you expand on your comment here? https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py | 12:58 |
gibi | stephenfin: looking... | 12:58 |
stephenfin | i.e. why do we need to re-stub? | 12:58 |
maciejjozefczyk | sean-k-mooney: yes, anyway if we have usecase we should do this :) nvidia is good example | 12:59 |
gibi | stephenfin: _IntegratedTestBase base class already set up the generic NeutronFixture which means that nova.network.neutronv2.api.get_client is already stubbed by the NeutronFixture | 12:59 |
sean-k-mooney | maciejjozefczyk: not nessicarialy. but in this case it is not that invasive a cchange | 12:59 |
*** eharney has quit IRC | 12:59 | |
gibi | stephenfin: then L350 sets up another fixture NUMAAffinityNeutronFixture that will also stub nova.network.neutronv2.api.get_client | 13:00 |
gibi | stephenfin: this is OK as the second stub overrides what the first stub did | 13:00 |
stephenfin | gibi: ahhh, of course. I missed that we were using the other fixture | 13:00 |
stephenfin | Not like I wrote that code or anything :) | 13:00 |
gibi | stephenfin: I guess you had a good vacation at properly reset your brain :) | 13:00 |
gibi | s/at/that/ | 13:01 |
sean-k-mooney | maciejjozefczyk: for there binary direver it may or may not be complient with there EULA. for the linux opensource Nouveau driver its probaly fine | 13:01 |
stephenfin | gibi: Currently trying to remember what "Python" is | 13:01 |
stephenfin | :) | 13:01 |
gibi | :) | 13:01 |
*** cdent has joined #openstack-nova | 13:02 | |
*** jaypipes has joined #openstack-nova | 13:02 | |
stephenfin | gibi: One other comment (the second one here) https://review.openstack.org/#/c/587412/3/nova/tests/functional/libvirt/test_numa_servers.py | 13:03 |
stephenfin | sean-k-mooney: Off the top of your head, would calling os_vif.initialize() twice have any bad side effects? | 13:04 |
sean-k-mooney | stephenfin: no we specificaly check for that | 13:04 |
gibi | stephenfin: I can remove that os_vif.initialize() as that is already in the fake libivirt now | 13:04 |
sean-k-mooney | call it a 1000 times in a loop if you like it will only initalise once | 13:04 |
stephenfin | gibi: Meh, unless you want to, I'm happy to just +W as is. It's a nit | 13:05 |
sean-k-mooney | stephenfin: unless you pass reset=true | 13:05 |
stephenfin | sean-k-mooney: Excellent. It's just a clean up so | 13:05 |
gibi | stephenfin: I will respin it quickly | 13:05 |
stephenfin | gibi: ack | 13:05 |
sean-k-mooney | stephenfin: by the way if your remove os_vif.initialize from setup and dont call it at all your test will fail | 13:06 |
sean-k-mooney | stephenfin: 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 not | 13:08 |
sean-k-mooney | stephenfin: i put it in setup beacuse i dont know what order the test will be run in | 13:09 |
stephenfin | sean-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.py | 13:09 |
stephenfin | So it'll get initialized the same time the fake nova-compute service starts | 13:09 |
sean-k-mooney | oh sweet then ya you can remove it from setup | 13:10 |
mriedem | lyarwood: before i get too far into https://bugs.launchpad.net/nova/+bug/1784353 - we don't reschedule on a boot from volume failure | 13:11 |
openstack | Launchpad 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-mooney | or not its a nit as you said. its not needed anymore but not enough for a respin on its own | 13:11 |
mriedem | lyarwood: or is this non-volume backed, so not really boot from volume, | 13:11 |
mriedem | just boot with volumes attached, but the root disk is on local storage | 13:12 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Improve NeutronFixture and remove unncessary stubbing https://review.openstack.org/587412 | 13:15 |
gibi | stephenfin: ^^ | 13:15 |
stephenfin | gibi: and done | 13:17 |
gibi | stephenfin: thanks | 13:17 |
mriedem | lyarwood: 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#L2320 | 13:17 |
lyarwood | mriedem: I've used BFV instances in the regression tests and just mocked out spawn to fail, not the volume attachments etc | 13:18 |
mriedem | lyarwood: that's not your bug though | 13:18 |
mriedem | your bug is not that spawn fails, but volume attach fails | 13:18 |
mriedem | oh wait, | 13:19 |
mriedem | i think i get it, | 13:19 |
lyarwood | mriedem: that's for the following attempt | 13:19 |
mriedem | first boot spawn() fails, | 13:19 |
mriedem | reschedule, | 13:19 |
lyarwood | mriedem: yeah | 13:19 |
mriedem | 2nd host fails b/c volume attachments are wrong | 13:19 |
mriedem | ok | 13:19 |
mriedem | b/c bug 1488111 | 13:19 |
openstack | bug 1488111 in OpenStack Compute (nova) "Boot from volumes that fail in initialize_connection are not rescheduled" [Wishlist,Confirmed] https://launchpad.net/bugs/1488111 | 13:19 |
mriedem | i was like, whatchutalkinboutyarwood | 13:19 |
lyarwood | ^_^ | 13:19 |
*** tetsuro_ has joined #openstack-nova | 13:20 | |
*** jaosorior has quit IRC | 13:20 | |
*** janki has quit IRC | 13:24 | |
*** tetsuro_ has quit IRC | 13:24 | |
*** cdent has quit IRC | 13:27 | |
sean-k-mooney | mriedem: 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-nova | 13:31 | |
sean-k-mooney | im 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 suspend | 13:31 |
mriedem | don't ask me | 13:32 |
mriedem | i always have to lookup the difference in libvirt between pause and suspend | 13:32 |
lyarwood | sean-k-mooney: hmmm iirc we need to detach PCI devices as we can't save or restore their state | 13:33 |
*** artom has joined #openstack-nova | 13:33 | |
*** jpena|lunch is now known as jpena | 13:33 | |
sean-k-mooney | lyarwood: to stop dma transfer or somthing? | 13:33 |
*** jaosorior has joined #openstack-nova | 13:33 | |
sean-k-mooney | in any case the current state seams broken. | 13:34 |
lyarwood | sahid: ^ do you know? | 13:35 |
lyarwood | sean-k-mooney: I'm not sure tbh | 13:35 |
*** Luzi has quit IRC | 13:35 | |
lyarwood | sean-k-mooney: and yeah suspend just saves the domain state to disk right? So that wouldn't help during a cold snapshot. | 13:35 |
lyarwood | wait that isn't right, it does pause the domain | 13:37 |
sean-k-mooney | lyarwood: no it doesnt | 13:37 |
sean-k-mooney | https://github.com/openstack/nova/blame/77ece76a70aa251e6f06e073b28c2ca978caf8f8/nova/virt/libvirt/driver.py#L2639-L2646 | 13:38 |
mriedem | lyarwood: your bug says we call _shutdown_instance before reschedule but i don't think that's the case if driver.spawn() fails | 13:39 |
sean-k-mooney | we call it in _prepare_domain_for_snapshot https://github.com/openstack/nova/blob/77ece76a70aa251e6f06e073b28c2ca978caf8f8/nova/virt/libvirt/driver.py#L1740 | 13:39 |
mriedem | lyarwood: 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 pcarver | 13:40 | |
*** _ix has joined #openstack-nova | 13:41 | |
lyarwood | sean-k-mooney: ack, so ManagedSave doesn't pause the domain, fun. | 13:41 |
mriedem | oh nvm, | 13:41 |
mriedem | i guess that's the exception handling from the yield on the context manager, | 13:41 |
mriedem | here https://github.com/openstack/nova/blob/7125dcb9cb821faf3c68526ac34365a28141e480/nova/compute/manager.py#L2092 | 13:41 |
mriedem | which is what calls driver.spawn() | 13:41 |
mriedem | god this flow is confusing | 13:41 |
lyarwood | mriedem: yeah indeed, it's awkward. | 13:42 |
mriedem | ok and the bdm.attachment_id in this flow is created in the API right? | 13:43 |
lyarwood | mriedem: yes | 13:43 |
sean-k-mooney | lyarwood: 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 find | 13:43 |
mriedem | so api creates the attachment record, we hit hostA, fail to spawn, delete the attachment, reshcedule to hostB, try to attach and the attachment is gone | 13:43 |
lyarwood | mriedem: yup that's it | 13:44 |
*** eharney has joined #openstack-nova | 13:45 | |
*** burt has joined #openstack-nova | 13:48 | |
*** _ix has quit IRC | 13:49 | |
mdbooth | mriedem: 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 |
mdbooth | mriedem: Detail in review. | 13:57 |
mriedem | mdbooth: 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 something | 14:00 |
mriedem | i'm not in love with this patch as noted in the commit message | 14:00 |
mdbooth | mriedem: ack. I got that. | 14:00 |
openstackgerrit | Merged openstack/nova stable/queens: Call generate_image_url only for legacy notification https://review.openstack.org/584969 | 14:00 |
*** cdent has joined #openstack-nova | 14:02 | |
*** tbachman has quit IRC | 14:02 | |
*** erlon has quit IRC | 14:04 | |
*** tbachman has joined #openstack-nova | 14:05 | |
mriedem | the bug reporter replied with what they failed on the first time they hit the dest host, | 14:06 |
mriedem | and 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, the | 14:06 |
mriedem | message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." | 14:06 |
*** janki has joined #openstack-nova | 14:07 | |
*** ccamacho has quit IRC | 14:07 | |
*** ccamacho has joined #openstack-nova | 14:07 | |
*** ccamacho has quit IRC | 14:08 | |
*** ccamacho has joined #openstack-nova | 14:08 | |
stephenfin | gibi: If I run 'tox -e api-samples', I see three new files in doc/api_samples/. Is that expected? | 14:13 |
stephenfin | gibi: http://paste.openstack.org/show/727146/ | 14:13 |
gibi | stephenfin: actually I don't know | 14:15 |
gibi | the notification sample handling is pretty different from the api sample handling | 14:15 |
*** hongbin_ has joined #openstack-nova | 14:16 | |
gibi | for example the test run never generates notificaton samples | 14:16 |
*** erlon has joined #openstack-nova | 14:16 | |
gibi | on the file system | 14:16 |
stephenfin | gibi: Hmm, I wonder who would know? gmann? | 14:16 |
gibi | sdauge was the mastermind but alex_xu or gmann could know | 14:16 |
* gibi needs to catch a bus and use a spotty connection for the rest of the work day | 14:17 | |
mdbooth | mriedem: That sounds like a bug in the libvirt driver and/or libvirt to me. | 14:18 |
mriedem | mdbooth: agree | 14:21 |
mriedem | this was also mitaka so shrug | 14:21 |
*** tbachman has quit IRC | 14:23 | |
mriedem | lyarwood: 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 instance | 14:23 |
mriedem | the api reserves the volume, but compute never unreserves it on failure | 14:23 |
mriedem | unlike if attach_volume fails | 14:23 |
mriedem | maybe 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 then | 14:24 |
mriedem | i guess _shutdown_instance calls the os-detach api in cinder but i don't know if that rolls back the reserved status | 14:25 |
lyarwood | mriedem: yeah I don't think we did unreserve in the old flow when we hit this error | 14:26 |
lyarwood | mriedem: I thought we had talked about updating attachments in the new flow with a None connector in this case | 14:26 |
lyarwood | mriedem: so the new compute only has to come along and update again with the correct connector | 14:27 |
mriedem | i think the os-detach call to cinder for the old flow in _shutdown_instance will make the volume available again | 14:27 |
lyarwood | kk then our removal of the attachment is fine | 14:27 |
mriedem | here 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#L1314 | 14:28 |
mriedem | *where we'd | 14:28 |
openstackgerrit | Jay Pipes proposed openstack/nova master: DNM - example https://review.openstack.org/588295 | 14:31 |
openstackgerrit | Konstantinos Samaras-Tsakiris proposed openstack/nova master: Hide hypervisor id on windows guests https://review.openstack.org/579897 | 14:32 |
mriedem | lyarwood: ok comments in your series | 14:32 |
mriedem | lyarwood: lots of internal debate on this one, but i think what you're doing is likely the best | 14:32 |
lyarwood | mriedem: ack thanks | 14:33 |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures https://review.openstack.org/584593 | 14:34 |
gmann | stephenfin: gibi api-samples tox run sample file with GENERATE_SAMPLES=True | 14:41 |
gmann | stephenfin: there can be chance that few file missing in doc/api_samples let me check those | 14:42 |
mriedem | lyarwood: 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 bug | 14:45 |
mriedem | most likely another reason we should move volume creation to api or conductor so that compute doesn't have to manage that | 14:46 |
mriedem | compute would just get a bdm and assume the volume already was created | 14:46 |
lyarwood | mriedem: 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-nova | 14:50 | |
mriedem | i'd need to recreate it first, and don't have a 2 node system handy | 14:50 |
mriedem | i 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 |
mriedem | we don't really do anything like that for volumes | 14:51 |
*** efried is now known as efried_afk | 14:55 | |
*** tomtom002 has quit IRC | 14:56 | |
openstackgerrit | Merged openstack/nova master: tox: Ensure reused envdirs share the same deps https://review.openstack.org/588207 | 14:59 |
*** gouthamr has joined #openstack-nova | 15:02 | |
*** ccamacho has quit IRC | 15:05 | |
*** alexpilotti has quit IRC | 15:06 | |
*** gbarros has joined #openstack-nova | 15:06 | |
*** maciejjozefczyk has quit IRC | 15:07 | |
*** gbarros_ has joined #openstack-nova | 15:10 | |
*** gbarros has quit IRC | 15:12 | |
*** udesale has quit IRC | 15:15 | |
cfriesen | this 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 |
openstackgerrit | Merged openstack/nova master: Fix a typo in comment in resource_provider.py https://review.openstack.org/588145 | 15:18 |
mriedem | cfriesen: where do the nova docs say that? | 15:20 |
mriedem | it's clearly not durable by default https://docs.openstack.org/nova/latest/configuration/config.html#oslo_messaging_rabbit.amqp_durable_queues | 15:21 |
mriedem | anything in the nova docs is likely way out of date | 15:21 |
*** psachin has quit IRC | 15:21 | |
mriedem | https://docs.openstack.org/nova/latest/reference/rpc.html?highlight=durable | 15:21 |
cfriesen | doc/source/reference/rpc.rst: | 15:21 |
mriedem | that? ^ | 15:21 |
mriedem | yeah that's all super duper old | 15:22 |
mriedem | probably predates oslo.messaging | 15:22 |
mriedem | open a bug | 15:22 |
cfriesen | okay. what about message persistance? are we always transient? | 15:23 |
*** gbarros_ has quit IRC | 15:24 | |
mriedem | let the code be your guide young chris | 15:24 |
*** gbarros has joined #openstack-nova | 15:25 | |
mriedem | i thought durable == persistent | 15:26 |
cfriesen | just 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 |
mriedem | idk then, ask kgiusti in #openstack-oslo? | 15:29 |
mriedem | or sileht? | 15:29 |
cfriesen | yeah, will do. I suspect we're just always transient. | 15:30 |
tssurya | mriedem: 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 |
tssurya | isnt' the driver the state of truth ? | 15:31 |
mriedem | tssurya: what thing are you specifically talking about? the sync_instance_power_states periodic in compute | 15:32 |
mriedem | ? | 15:32 |
tssurya | yes | 15:32 |
mriedem | that shuts down your server if the db says it's down but the driver says it's up? | 15:32 |
tssurya | exactly | 15:32 |
mriedem | because you could be getting charged for one when you told nova to shut it down | 15:32 |
tssurya | ah okay.. | 15:32 |
mriedem | it's been years since i've had to load that thing into memory | 15:33 |
mriedem | and it's always a disaster when i do | 15:33 |
tssurya | and for the ironic cases where the users may interact through the ipmi interface.. | 15:33 |
tssurya | the only solution we have is to switch the power sync off ? | 15:33 |
mriedem | nova doesn't support monkeying with the guests out of band | 15:34 |
tssurya | is there is a way we could make this behaviour configurable (a choice for deployments) | 15:34 |
tssurya | hmm | 15:34 |
mriedem | i'm sure vmware and powervc have had this same argument because the user started up the vm in vcenter or the hmc | 15:34 |
mriedem | and then nova shut it down | 15:34 |
tssurya | yes, we have the same stuff | 15:35 |
*** gbarros has quit IRC | 15:35 | |
stephenfin | mriedem: Remind me: can I +W code? We've branched and everything, right? | 15:35 |
tssurya | we were just thinking if we could make this configurable.. as in tell nova not to shut it back down | 15:35 |
mriedem | stephenfin: we have not branched | 15:35 |
openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: guest: introduce blockStats instead of domain.blockStats https://review.openstack.org/526833 | 15:35 |
tssurya | the default could be what nova does today of course | 15:35 |
stephenfin | Well then :) | 15:35 |
mriedem | stephenfin: +W depends on the change | 15:35 |
mriedem | if it's a bug fix, then yeah maybe | 15:35 |
mriedem | if it's docs, sure | 15:36 |
stephenfin | It's a refactor so nope, it should wait | 15:36 |
mriedem | if it's a big ass refactor or something risky, likely not a great idea right now | 15:36 |
stephenfin | Yup, I'll just leave it til branch. No panic on it | 15:36 |
* stephenfin is working down through the "needs another reviewer" list | 15:36 | |
*** sambetts|afk is now known as sambetts | 15:36 | |
mriedem | tssurya: likely a better question for the ML to get wider input, from both -dev and ops lists | 15:37 |
mriedem | i'm able to devote about 5% brain to your question atm | 15:37 |
tssurya | mriedem: ack, sorry for the bad timing then :) | 15:37 |
mriedem | np | 15:37 |
gmann | stephenfin: 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 IRC | 15:49 | |
stephenfin | gmann: I don't mind. Is it a big issue? I guess it just means the api-ref will be incomplete? | 15:51 |
stephenfin | gmann: If you _do_ have time to work on them, I'll happily review it | 15:52 |
*** janki has quit IRC | 15:58 | |
mriedem | tssurya: note you can disable that sync power state task | 15:59 |
mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L7439 | 16:00 |
melwitt | dangit, was just pulling that up | 16:00 |
melwitt | you win...again | 16:01 |
melwitt | https://github.com/openstack/nova/blob/master/nova/conf/compute.py#L753-L777 | 16:04 |
*** eandersson has joined #openstack-nova | 16:10 | |
*** rdiggz has joined #openstack-nova | 16:11 | |
*** gbarros has joined #openstack-nova | 16:14 | |
*** tssurya has quit IRC | 16:16 | |
*** gbarros_ has joined #openstack-nova | 16:17 | |
rdiggz | good day everyone. Could someone help me understand what this means? "A sys-admin privsep daemon has been added and needs to be included in your | 16:17 |
rdiggz | rootwrap configuration. | 16:17 |
*** spotz has quit IRC | 16:18 | |
rdiggz | Its 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 IRC | 16:19 | |
*** rdiggz has left #openstack-nova | 16:20 | |
mriedem | cfriesen: is this a bug that should be upstreamed or at least reported to nova? https://github.com/starlingx-staging/stx-nova/commit/fe0c0617be857161b6bb66d632b2b35887c08772 | 16:26 |
mriedem | oh nvm it's already in nova | 16:27 |
mriedem | https://github.com/openstack/nova/commit/ce8bf6734e554b116e82e924cbe81a5968441926 | 16:27 |
cfriesen | they should've pointed to upstream if it was a backport. grr. | 16:29 |
mriedem | it's not a backport | 16:30 |
*** jpena is now known as jpena|off | 16:30 | |
*** janki has joined #openstack-nova | 16:31 | |
*** jpena|off is now known as jpena | 16:31 | |
*** jpena is now known as jpena|off | 16:32 | |
*** s10 has quit IRC | 16:33 | |
*** Kevin_Zheng has quit IRC | 16:34 | |
*** gyee has joined #openstack-nova | 16:35 | |
*** imacdonn has quit IRC | 16:36 | |
*** imacdonn has joined #openstack-nova | 16:37 | |
mriedem | dansmith: looks like one of your earlier is_bfv attempts made it in https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-b839034e35c154b8c3a1c65bf7791eefR114 | 16:42 |
mriedem | cfriesen: what are offline_cpus? | 16:43 |
dansmith | mriedem: lol | 16:43 |
melwitt | I think that's part of the second iteration of my famous root_gb=0 workaround patches | 16:43 |
cfriesen | mriedem: 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 |
cfriesen | mriedem: (the cpu scaling stuff requires guest cooperation to do properly) | 16:44 |
cfriesen | melwitt: I think that's correct | 16:45 |
melwitt | dansmith 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 everyone | 16:45 |
*** dtantsur is now known as dtantsur|afk | 16:46 | |
melwitt | so it lay abandoned again | 16:46 |
mriedem | cfriesen: how is that different from just resizing down? | 16:46 |
mriedem | the offline CPUs are reserved? | 16:47 |
cfriesen | mriedem: it's similar to the "live-resize" proposed recently | 16:47 |
mriedem | i.e. so you can scale up and down w/o worrying about claim failures? | 16:47 |
cfriesen | mriedem: the server stays running | 16:47 |
cfriesen | mriedem: the resource tracking is adjusted, but the quota isn't | 16:48 |
cfriesen | so you could fail to scale up if there are no free cpus on the host | 16:48 |
mriedem | right that's what i was saying, | 16:49 |
mriedem | you essentially boot with like 4 vcpu, | 16:49 |
mriedem | resize down to 2, | 16:49 |
mriedem | but the other 2 are "offline" so you can resize back up? | 16:49 |
mriedem | but you're still paying for 4 VCPU of quota? | 16:50 |
cfriesen | remember this is private cloud so "paying for quota" is a bit iffy. but yes. | 16:50 |
dansmith | I'm not sure people usually charge for quota either | 16:51 |
dansmith | they pay for usage, which would be based on the stuff they're updating I imagine | 16:51 |
mriedem | and this is needed why? so edge nodes can automatically scale down during down times and scale up during peak hours? | 16:51 |
dansmith | it's needed because someone wanted it one time | 16:51 |
dansmith | because there was a knob they couldn't twiddle | 16:52 |
cfriesen | dansmith: :) | 16:52 |
* dansmith knows he's not being helpful | 16:52 | |
*** janki has quit IRC | 16:52 | |
cfriesen | I think the idea is that there are pets with unpredictable load that don't scale well horizontally | 16:52 |
cfriesen | similar rationale as https://blueprints.launchpad.net/nova/+spec/instance-live-resize | 16:53 |
mriedem | sure | 16:53 |
mriedem | ok, feature 1 of 130 sorted out in my spreadsheet, | 16:54 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor NeutronFixture https://review.openstack.org/588338 | 16:54 |
mriedem | time for lunch! | 16:54 |
melwitt | found it https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-afb9c0c0ca5276c7eacd987bbf51d8e6R370 | 16:54 |
cfriesen | mriedem: having done that spreadsheet multiple times with the benefit of commit history, I feel for you. I apologize for our legal guys. | 16:54 |
mriedem | i'll take your pity and just remind you of it when you get tired of me asking questions | 16:55 |
*** gbarros_ has quit IRC | 16:58 | |
mriedem | ooo server group metadata | 16:59 |
mriedem | good thing we just nuked that from the api in rocky | 16:59 |
mriedem | anyone know of a way to make github just load all diffs? because it simply gave up here | 17:00 |
cfriesen | mriedem: 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 |
mriedem | i guess rather than crawl through github it's probably easiest to just clone this repo and look for "WRS" ? | 17:01 |
*** derekh has quit IRC | 17:02 | |
cfriesen | looking for WRS will get you a lot of stuff. also look for files with wrs in the name | 17:03 |
sean-k-mooney | mriedem: all the changes are squashed into one big commit on top of what was master when it was created | 17:04 |
mriedem | sean-k-mooney: yes, i'm intimately familiar | 17:04 |
*** tbachman has joined #openstack-nova | 17:04 | |
sean-k-mooney | i made a list of randome stuff to look at later in that repo but left it at intel when i left | 17:05 |
*** gbarros has joined #openstack-nova | 17:05 | |
cfriesen | mriedem: 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 IRC | 17:09 | |
*** gbarros has joined #openstack-nova | 17:11 | |
*** hamzy has joined #openstack-nova | 17:11 | |
*** efried_afk is now known as efried | 17:14 | |
*** gbarros has quit IRC | 17:14 | |
sean-k-mooney | cfriesen: yes... that is interesting | 17:20 |
sean-k-mooney | cfriesen: yes re pinned all the floating instances on the host to make that work if i recall | 17:21 |
mriedem | today ops just use host aggregates to separate hosts/flavors that do cpu pinning and hosts with cpu overcommit yeah? | 17:22 |
sean-k-mooney | cfriesen: im not sure liked is the workd i would have chosen but the capablit is certenly interesting. | 17:22 |
sean-k-mooney | mriedem: mostly yes | 17:22 |
sean-k-mooney | that is more of a cludge to workaround the fact nova does not do it magically for them rather then they like it | 17:23 |
cfriesen | mriedem: 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 instances | 17:24 |
sean-k-mooney | there 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 |
cfriesen | sean-k-mooney: with the new specs you still have to specify up-front which cpus are for which purpose | 17:25 |
sean-k-mooney | cfriesen: right so you level them float but repin the floating vms wheever you spawn a new pinned vm | 17:25 |
sean-k-mooney | *let them float | 17:26 |
cfriesen | sean-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 |
cfriesen | but logically it's equivalent | 17:27 |
sean-k-mooney | any 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 ratio | 17:27 |
cfriesen | sean-k-mooney: allocation ratio | 17:27 |
*** sahid has quit IRC | 17:27 | |
jaypipes | sean-k-mooney: what's pininned cores? :P | 17:28 |
mriedem | cfriesen: yeah i figured that was the reason | 17:28 |
mriedem | 2 node edge site | 17:28 |
mriedem | or whatever 'grouse' is | 17:28 |
sean-k-mooney | jaypipes: its my getting used to my keyboard :) | 17:28 |
jaypipes | :) | 17:28 |
jaypipes | switched to dvorak? | 17:28 |
mriedem | cfriesen: grouse install is what, single node? | 17:28 |
sean-k-mooney | ha 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 work | 17:29 |
sean-k-mooney | i 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 it | 17:30 |
cfriesen | mriedem: those names are all newly-invented, have to go look | 17:31 |
cfriesen | but we support single-node, duplex single-node, and multi-node with two controller nodes | 17:31 |
mriedem | it goes grouse, something something, and then something with an R in the name | 17:32 |
mriedem | canadian mountain ranges | 17:32 |
cfriesen | robson, I think. Pretty much invented right before the summit. :) | 17:32 |
mriedem | https://youtu.be/Z1DN41WnRkc?t=560 | 17:33 |
mriedem | grouse, whistler, robson | 17:33 |
cfriesen | there we go. the two-controller case uses replicated storage for improved availability | 17:34 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove old check_attach version check in API https://review.openstack.org/588348 | 17:36 |
openstackgerrit | Eric Fried proposed openstack/nova master: [placement] Debug log per granular request group https://review.openstack.org/588350 | 17:38 |
sean-k-mooney | cfriesen: ya 3 dedicated contoler nodes is major overkill in many cases but alot of people still default to it | 17:43 |
openstackgerrit | Merged openstack/nova master: Remove unused stubbing function from test https://review.openstack.org/586968 | 17:44 |
openstackgerrit | Merged openstack/nova master: Improve NeutronFixture and remove unncessary stubbing https://review.openstack.org/587412 | 17:44 |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures https://review.openstack.org/584593 | 17:57 |
*** itlinux has joined #openstack-nova | 18:04 | |
*** sambetts is now known as sambetts|afk | 18:16 | |
mnaser | so i noticed that | 18:20 |
mnaser | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/volume.py#L62-L79 | 18:20 |
mnaser | and | 18:20 |
mnaser | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L168-L176 | 18:20 |
mnaser | is pretty much the same thing repeated | 18:21 |
mnaser | one does it for volumes, the other does it for 'imagebackend' aka nova "images" | 18:21 |
mnaser | would moving the method to nova.virt.libvirt.utils make sense? | 18:22 |
mnaser | or maybe moving it into a function inside LibvirtConfigGuestDisk ? | 18:23 |
melwitt | maybe. if you think there's a common utility method both could use | 18:27 |
melwitt | they look similar but not sure if they're doing the exact same thing | 18:27 |
mnaser | melwitt: 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 volumes | 18:28 |
*** artom has quit IRC | 18:32 | |
melwitt | mnaser: 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 |
mriedem | cfriesen: 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 |
openstackgerrit | Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP: only _init_compute_node on startup https://review.openstack.org/588094 | 18:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Remove redundant _update()s https://review.openstack.org/588091 | 18:54 |
openstackgerrit | Merged openstack/nova master: Wait for vif plugging during live migration job https://review.openstack.org/578551 | 19:03 |
openstackgerrit | Merged openstack/nova master: Stop setting glance_api_version in cinder.conf in nova-live-migration https://review.openstack.org/579871 | 19:03 |
openstackgerrit | Merged openstack/nova master: doc: fix resize user guide link https://review.openstack.org/588097 | 19:03 |
openstackgerrit | Merged openstack/nova master: Hyper-V + OVS: plug vifs before starting VMs https://review.openstack.org/585661 | 19:06 |
openstackgerrit | Merged openstack/nova master: Complete the api-ref of security group rule https://review.openstack.org/580109 | 19:06 |
*** mgariepy has quit IRC | 19:14 | |
*** artom has joined #openstack-nova | 19:30 | |
openstackgerrit | Eric Fried proposed openstack/nova master: Grease test_try_deallocate_network_retry_direct https://review.openstack.org/588364 | 19:31 |
*** awaugama has quit IRC | 19:35 | |
*** cdent has quit IRC | 19:35 | |
*** avolkov has quit IRC | 19:35 | |
*** artom has quit IRC | 19:38 | |
*** eharney has quit IRC | 19:44 | |
cfriesen | mriedem: 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 |
mriedem | cfriesen: that was exactly my question - why put it on the flavor/image rather than just directly in the live migration api | 19:52 |
mriedem | i guess because bigger flavors/images could need more downtime? | 19:52 |
cfriesen | mriedem: it was less code to do it this way, and no on-the-wire API change | 19:53 |
cfriesen | mriedem: it'd be cleaner as part of the migration request | 19:54 |
mriedem | well, there are plenty of "if wrs-header: do extra stuff" | 19:54 |
mriedem | but yeah, input validation on the api schema i guess | 19:54 |
mriedem | nixes that | 19:54 |
mriedem | also, all of this cpu cache stuff... | 19:54 |
mriedem | i can't wrap my head around this | 19:54 |
openstackgerrit | Merged openstack/nova master: Fix all invalid obj_make_compatible test case https://review.openstack.org/574240 | 19:55 |
cfriesen | mriedem: 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 |
cfriesen | The CPU cache stuff...I think that's the Intel CAT stuff. | 19:56 |
cfriesen | equivalent to this: https://blueprints.launchpad.net/nova/+spec/cat-support | 19:56 |
*** maciejjozefczyk has joined #openstack-nova | 19:58 | |
mriedem | ok, not much in there - no spec proposed it looks like | 19:59 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Scrub hw:cpu_model from API samples https://review.openstack.org/588371 | 20:02 |
mriedem | sw:wrs:srv_grp_messaging huh | 20:03 |
cfriesen | you can probably ignore the server group messaging stuff...it's probably getting removed | 20:06 |
mriedem | jesus, ok, so servers within the same group can send messages to each other through a channel on the host? | 20:06 |
cfriesen | yeah, the idea was to have a low-bandwidth really easy way to message other serves in the group | 20:07 |
*** maciejjozefczyk has quit IRC | 20:07 | |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: safe_connect shouldn't hide failures https://review.openstack.org/584593 | 20:07 |
cfriesen | ended up being more hassle than it was worth | 20:07 |
mriedem | who. would. have. thought. | 20:07 |
cfriesen | but we use the same host/guest backchannel for the cpu scaling code | 20:07 |
cfriesen | :) | 20:07 |
mriedem | i see that | 20:07 |
cfriesen | doing it now, cpu scaling would use virtio-vsock | 20:08 |
mriedem | was that server group thing only for affinity groups? | 20:08 |
mriedem | it would have to be right? | 20:08 |
mriedem | on the same host | 20:08 |
cfriesen | no, it would send the message back to the controller to redistribute to other compute nodes | 20:09 |
mriedem | oh right, | 20:09 |
mriedem | forgot the rpc cast | 20:09 |
*** masayukig has quit IRC | 20:18 | |
*** sambetts|afk has quit IRC | 20:28 | |
*** sambetts_ has joined #openstack-nova | 20:29 | |
mriedem | cfriesen: where does upstream nova actually support live migration with macvtap pci devices? i don't see anything specific about hat | 20:33 |
mriedem | *that | 20:33 |
mriedem | https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-6c3b14d3964eb808ade9d3e7c5d4676dR104 | 20:34 |
*** hamzy has quit IRC | 20:40 | |
cfriesen | mriedem: https://docs.openstack.org/neutron/pike/admin/config-macvtap.html and https://bugs.launchpad.net/neutron/+bug/1550400 | 20:45 |
openstack | Launchpad 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-nova | 20:48 | |
mriedem | hmm, that's marked in progress | 20:48 |
mriedem | does it actually work? | 20:48 |
mriedem | oh i see, | 20:49 |
cfriesen | According to the first link, "Instance migration requires the same values for the physical_interface_mapping configuration option on each compute node." | 20:49 |
mriedem | huh does that rely on the migrating_to attribute we set in the port binding dict during live migration? | 20:49 |
cfriesen | no clue...you'll see our code comment says macvtap isn't supported in Titanium Cloud | 20:50 |
cfriesen | I haven't played with it | 20:50 |
mriedem | yup i saw that | 20:50 |
mriedem | that limit on servers per group is also a bit strange, | 20:50 |
mriedem | given we have the server_group_members quota | 20:51 |
mriedem | which is global unless you override it per tenant i think? | 20:51 |
mriedem | oh i guess server_group_members is per user | 20:51 |
cfriesen | per group | 20:51 |
cfriesen | oh, you mean the quota | 20:52 |
mriedem | yeah | 20:52 |
cfriesen | we're getting rid of the server group size I think, trying to align with upstream | 20:52 |
mriedem | well i was just thinking of alternatives there, | 20:53 |
mriedem | i.e. you could limit the max members per group using quota which can be overridden | 20:53 |
mriedem | so your high $$ users get higher quota | 20:53 |
melwitt | nova meeting in 7 minutes | 20:53 |
openstackgerrit | Eric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator https://review.openstack.org/588391 | 20:53 |
cfriesen | originally we implemented it when server group metadata was still a thing, or looked like it would be a thing. | 20:54 |
mriedem | yeah, which was probably forever ago | 20:54 |
mriedem | so 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 2 | 20:54 |
openstackgerrit | Eric Fried proposed openstack/nova master: Grease some more tests hitting RetryDecorator https://review.openstack.org/588391 | 20:55 |
mriedem | user A in tenant 1 i meant | 20:55 |
efried | melwitt: Since you expressed interest, I tracked down a couple more --^ | 20:55 |
melwitt | thanks | 20:55 |
cfriesen | mriedem: I thought we were getting rid of user quotas | 20:55 |
mriedem | that's news to me | 20:56 |
mriedem | oh, with moving to unified limits? | 20:56 |
melwitt | we've talked about it several times but people keep getting confused, I think | 20:56 |
melwitt | I think even unified limits added 'user' to their stuff because they thought we needed it | 20:56 |
mriedem | :/ | 20:57 |
melwitt | we "need" user only if we want to keep the legacy stuff the way it has been, going forward | 20:57 |
cfriesen | I 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 |
mriedem | cern needed user-level quota for working around nova not having hierarchical quota support, iirc | 20:57 |
melwitt | yeah, that is my understanding as well | 20:58 |
mriedem | does unified limits give us hierarchical quota support? | 20:58 |
melwitt | it was a hack to get two level hierarchical | 20:58 |
mriedem | i thought it was just part of the puzzle | 20:58 |
melwitt | yes, that's what the keystone team is working on | 20:58 |
*** gbarros has joined #openstack-nova | 20:58 | |
sean-k-mooney | cfriesen: users can have multiple project however so you may want to have per project limits and a limit for the user in general | 20:58 |
mriedem | w/o lbragstad or someone from keystone actually working on the nova changes, i don't know if/when that will ever get done in nova | 20:58 |
*** priteau has quit IRC | 20:59 | |
melwitt | I'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 piece | 21:00 |
* lbragstad lingers | 21:00 | |
mriedem | melwitt: you'd probably be best to lead that given your work on the quota stuff | 21:01 |
sean-k-mooney | melwitt: its been a topic for a few releases on and off right? do you see any obvious blockers? | 21:01 |
lbragstad | fwiw - the implementation for strict-two-level landed in keystone this release, so that's done | 21:01 |
lbragstad | we'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 services | 21:02 |
sean-k-mooney | lbragstad: i would guess nova will have some requirement that other project wont have related to cells | 21:02 |
lbragstad | yeah - i would agree | 21:03 |
lbragstad | and i'm curious to flush those out as we go | 21:03 |
lbragstad | i assume that's going to have an impact on implementing unified limit support for instances, yeah? | 21:04 |
sean-k-mooney | lbragstad: ya there are some edge case to knowing if you are at or below quota if connect to a cell goes down | 21:05 |
lbragstad | huh - interesting | 21:05 |
sean-k-mooney | it 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 back | 21:05 |
lbragstad | oh - sure | 21:06 |
sean-k-mooney | while the connect is broken you could exceed the gloabl limt. then the question is how to hanelit when you get the full view again | 21:06 |
lbragstad | right... | 21:06 |
sean-k-mooney | most other project dont shard there resocue view teh same way nova can with cells so ya im sure nova will find edgecases | 21:07 |
lbragstad | i guess the way we've been thinking about that (originally something sdague thought of) | 21:07 |
lbragstad | was to just keep things as they are, reject new claims, and give the user an opportunity to clean things up or escalate to an administrator | 21:07 |
* melwitt in the nova meeting atm | 21:08 | |
sean-k-mooney | ya that seams like the sane think to do atleast at first until operator start telling us to do something else | 21:08 |
mriedem | cfriesen: heh https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-1aca090de4ab90afbc1c8d84b13a56f7R478 - i think that is one condition too late :) | 21:15 |
mriedem | by the time that runs, i think we've already dos'ed neutron | 21:16 |
*** tbachman has quit IRC | 21:23 | |
sean-k-mooney | melwitt: quick question regardign os-vif stable releases. do you make them when you make sable release of nova? | 21:26 |
melwitt | sean-k-mooney: usually yes. around and after the third milestone is different because of the release freezes | 21:27 |
melwitt | IIUC, we are frozen from doing stable/rocky releases until stein opens | 21:28 |
sean-k-mooney | melwitt: ok there are a few test/tox fixes that would be nice to backport but nothing functional | 21:28 |
*** mriedem is now known as mriedem_afk | 21:28 | |
melwitt | sean-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 recently | 21:29 |
sean-k-mooney | like https://review.openstack.org/#/c/567942/ to run all of the py27 unit test instead of only a subset. | 21:29 |
sean-k-mooney | oh cool | 21:29 |
melwitt | I 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 benefit | 21:30 |
melwitt | oh, because it runs in a CI job | 21:31 |
sean-k-mooney | ya | 21:31 |
sean-k-mooney | its to make sure we dont backport stuff that breakes py27 | 21:31 |
sean-k-mooney | that said all the unit tests are running under by 35 | 21:31 |
sean-k-mooney | *py35 | 21:31 |
melwitt | okay, 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 it | 21:32 |
melwitt | smcginnis: can you sanity check me on that? ^ | 21:33 |
melwitt | is 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-mooney | well 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-vif | 21:34 |
melwitt | pending as in, not merged? | 21:34 |
sean-k-mooney | yes | 21:34 |
melwitt | okay. just have to let people (stable cores) know to take a look if there's something important there | 21:35 |
sean-k-mooney | such 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 |
smcginnis | melwitt: Yep, that looks right. Freeze just applies to rocky work. | 21:37 |
melwitt | smcginnis++ | 21:37 |
sean-k-mooney | i 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 reviewed | 21:37 |
sean-k-mooney | anyway there is nothing breakign the gate or that customer are screaming about that im aware of so just an FYI | 21:38 |
melwitt | sean-k-mooney: okay, thanks for letting me know. I'll see if I can find someone for the second +2s | 21:39 |
*** gbarros has quit IRC | 21:41 | |
openstackgerrit | Merged openstack/os-vif stable/pike: Check if interface belongs to a Linux Bridge before removing https://review.openstack.org/531465 | 21:46 |
melwitt | tonyb: fancy reviewing a os-vif backport to fix their tox py27 job? https://review.openstack.org/567942 | 21:46 |
tonyb | melwitt: done | 21:47 |
melwitt | thank you sir | 21:47 |
tonyb | melwitt: no problem at all | 21:47 |
*** itlinux has quit IRC | 21:54 | |
sean-k-mooney | tonyb: thanks. | 21:54 |
tonyb | sean-k-mooney: np. It's my very minor super power ;P | 21:55 |
sean-k-mooney | by 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 |
openstackgerrit | Merged openstack/os-vif stable/queens: fix tox py27 job https://review.openstack.org/567942 | 21:56 |
melwitt | sean-k-mooney: can't remember. it's been awhile | 21:57 |
sean-k-mooney | i 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 |
tonyb | sean-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 CI | 21:59 |
tonyb | it *might* work | 21:59 |
sean-k-mooney | tonyb: oh? im not sure i follow | 22:00 |
tonyb | sean-k-mooney: gimme 5 to find a link | 22:00 |
sean-k-mooney | as in a gerrit query for a reviewer? | 22:00 |
tonyb | sean-k-mooney: Oh you could do that as well | 22:01 |
melwitt | oh yeah, good idea | 22:01 |
tonyb | sean-k-mooney: So looking at https://git.openstack.org/cgit/openstack/nova/commit/?id=2499f616094f63ed0a1a3c201789d14cc61a62c4 | 22:02 |
tonyb | 'notes' get added to each review based on code-reviews. they're in a seperate ref | 22:02 |
*** mchlumsky has quit IRC | 22:02 | |
tonyb | so 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 reviewers | 22:03 |
tonyb | so the CI votes (but not comments) would be included. | 22:03 |
tonyb | https://review.openstack.org/#/q/reviewedby%3Aintel-nfv-ci | 22:04 |
tonyb | look slike it's still voting | 22:04 |
sean-k-mooney | maybe what does exception meen next to a ci comment https://review.openstack.org/#/c/584829/ | 22:05 |
tonyb | sean-k-mooney: Oh it means it's voting but not doign anythign helpful ;P | 22:06 |
sean-k-mooney | ah it makes perfect sense lol | 22:07 |
tonyb | ;p | 22:07 |
tonyb | sean-k-mooney: Let me see if I can find the last time it voted +1 | 22:08 |
tonyb | sean-k-mooney: Nope my gerrit fu is weak right now. I'll grab some coffee and try again | 22:10 |
sean-k-mooney | well looking at the log server it has not uploaded anything sice the 18th http://52.27.155.124/portland/2018-07-18 | 22:11 |
sean-k-mooney | tonyb: thanks for trying in anycase. i might reach out and ask what the status is. | 22:13 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Reno for notification-transformation-rocky https://review.openstack.org/588403 | 22:20 |
*** rcernin has joined #openstack-nova | 22:32 | |
melwitt | lbragstad: 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 bit | 22:35 |
melwitt | we 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 our | 22:38 |
melwitt | side is the enforce with what we already have. then next stage will be to move to oslo.limit for enforcement | 22:38 |
*** hongbin_ has quit IRC | 22:39 | |
lbragstad | interesting melwitt | 22:43 |
lbragstad | so - you'd query keystone directly for limit information as opposed to using oslo.limit? | 22:43 |
melwitt | yeah. 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 forgot | 22:44 |
melwitt | or are you saying limit + enforce are coupled? | 22:44 |
melwitt | in oslo.limit | 22:45 |
lbragstad | technically - 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 tree | 22:45 |
melwitt | right okay | 22:45 |
tonyb | sean-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 |
lbragstad | melwitt: i'm trying to map terms, but i was under the assumption that enforcement would be a requirement? | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: [placement] Add /reshaper handler for POST https://review.openstack.org/576927 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider sane https://review.openstack.org/584598 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | 22:45 |
openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Remove redundant _update()s https://review.openstack.org/588091 | 22:45 |
lbragstad | if 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 |
melwitt | lbragstad: it is, sorry. I mean whether it's one call or two calls in oslo.limit to do limits vs enforce | 22:46 |
lbragstad | oh - the thing that protects against race conditions? | 22:46 |
melwitt | sorry, I think I'm confusing things and I haven't looked at the POC code in awhile | 22:47 |
lbragstad | the skeleton of oslo.limit has that implemented in the context manager https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L60-L62 | 22:47 |
melwitt | ah, yeah I remember now | 22:48 |
lbragstad | https://github.com/openstack/oslo.limit/blob/master/oslo_limit/tests/test_limit.py#L96 probably helps visualize things a bit, too | 22:48 |
lbragstad | from a usage perspective anyway | 22:48 |
melwitt | thanks | 22:49 |
lbragstad | this 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-L85 | 22:49 |
lbragstad | (implementation detail of the context manager though) | 22:49 |
melwitt | and that will also pull the limits from keystone? | 22:49 |
lbragstad | yep - exactly | 22:50 |
lbragstad | when you enter the context manager, it should query keystone for the limits and do calculations based on the claims your making | 22:50 |
melwitt | ah, 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 step | 22:50 |
lbragstad | then __exit__ will do error handling in the event there was a race condition and verify = True | 22:50 |
melwitt | from a project perspective | 22:51 |
lbragstad | aha - sure | 22:51 |
lbragstad | hopefully it's only one step for you | 22:51 |
lbragstad | (unless there is a good reason to break things up a bit?) | 22:51 |
melwitt | no, I don't think there is. just ignorance on my part | 22:51 |
lbragstad | it's a lot of moving pieces =/ | 22:51 |
melwitt | yeah, for sure | 22:52 |
lbragstad | we were waiting on an APi to return the project heirarchy with limit data associated to it (landed in rocky) | 22:52 |
lbragstad | now that's in, we can start working on finishing up the implementation of that context manager | 22:52 |
lbragstad | (i'm hoping to start that soon) | 22:52 |
melwitt | on 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.limit | 22:53 |
lbragstad | i can bump the oslo.limit impl up on my priority list if it helps give you all a definitive direction | 22:54 |
lbragstad | (if support in oslo.limit is the question) | 22:54 |
melwitt | have 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 cost | 22:55 |
lbragstad | sure | 22:55 |
lbragstad | i think i see what you mean | 22:55 |
melwitt | lbragstad: 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.html | 23:00 |
melwitt | we'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 semantics | 23:02 |
*** takashin has left #openstack-nova | 23:02 | |
*** mschuppert has quit IRC | 23:04 | |
*** tbachman_ has joined #openstack-nova | 23:05 | |
*** tbachman_ is now known as tbachman | 23:06 | |
*** edmondsw has quit IRC | 23:08 | |
*** jaypipes has quit IRC | 23:14 | |
*** jaypipes has joined #openstack-nova | 23:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!