Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-26
11:09:56 kashyap johnthetubaguy: I ask because, a QEMU dev was just mentioning an OOM bug for a Windows guest w/ multiqueue enabled
11:10:04 kashyap (Recently fixed, /me goes to check)
11:10:20 johnthetubaguy heh, thank goodness they doing run windows then :)
11:10:26 johnthetubaguy oops
11:10:28 kashyap :D
11:10:30 johnthetubaguy don't^
11:10:39 johnthetubaguy I forget the negative :)
11:11:52 kashyap johnthetubaguy: Yeah, it's a guest-crash ... trying to find the upstream commit/release, if you're curious
12:04:59 openstackgerrit Merged openstack/nova master: Reset instance to current vm_state if rolling back in resize_instance https://review.opendev.org/691908
12:08:24 openstackgerrit Merged openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Ussuri" https://review.opendev.org/695056
12:08:29 openstackgerrit Merged openstack/nova master: doc: remove admin/manage-users https://review.opendev.org/695779
12:23:21 openstackgerrit Merged openstack/nova master: Drop neutron-grenade-multinode job https://review.opendev.org/694789
12:39:20 tssurya @nova-api experts like alex_xu, gmann: Is this a bug or a feature ? : https://github.com/openstack/nova/blob/d621914442855ce67ce0b99003f7e69e8ee515e6/nova/api/openstack/identity.py#L61
12:39:37 tssurya shouldn't we be blocking this action if we know its wrong ?
13:38:30 mriedem gibi: if you have some time, https://review.opendev.org/#/c/643451/46 and the one after it are negative functional tests for cross-cell resize and have +2s already
13:38:46 gibi mriedem: ack. I will try.
13:39:04 mriedem thanks
13:39:21 mriedem aarents: were you going to propose backports for this? https://review.opendev.org/#/c/670000/
13:40:44 aarents yes why not
13:40:44 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Join migration_context and flavor in Migration.instance https://review.opendev.org/696083
13:41:52 openstackgerrit Alexandre arents proposed openstack/nova master: Flatten qcow2 images when unshelving an instance https://review.opendev.org/696084
13:42:09 openstackgerrit Matt Riedemann proposed openstack/nova stable/train: Reset instance to current vm_state if rolling back in resize_instance https://review.opendev.org/696085
13:44:35 aarents mriedem: thanks about you reply on ml about "unshelved bug", when you will have time can you review https://review.opendev.org/696084 it is about flatten also qcow2 disk during unshelve
13:45:35 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Enforce unified limits using oslo.limit https://review.opendev.org/615180
13:51:37 mriedem aarents: i've added mdbooth to that since he's going to be more of an authority on that change than me
13:52:15 aarents mriedem: ok thks
13:52:36 mriedem though it should be pretty easy to recreate in tempest right? make sure devstack is configured to use the qcow2 image backend (it might be by default?) and write a tempest test that shelve/unshelves an instance and then resizes it - without your fix that should fail correct?
13:58:14 openstackgerrit Matt Riedemann proposed openstack/nova stable/train: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/696088
14:03:35 aarents mriedem: Hum, I'm not sure this bug can be always detected during a resize, for exemple issue is typically detected when instance is unbootable, it shoud depends of the data diff between shelved image and original image, but we can imagine in tempest scenario something reproducible 100% by checking generated data or something like that.
14:23:21 dpawlik stephenfin: can I add nova-core group for this review? https://review.opendev.org/#/c/687909/
14:23:59 stephenfin dpawlik: you can, but I don't know how much it'll help
14:24:14 stephenfin is there a rush on merging it?
15:00:20 dpawlik stephenfin: not so big :)
15:19:30 mriedem dpawlik: adding the entire core team to a review is generally discouraged as bad behavior
15:21:51 efried that's perhaps a culture we should seek to amend in light of falling numbers.
15:22:56 efried What's your alternative? Hang out in IRC and pounce on someone? Or just wait and pray?
15:23:08 mriedem adding the entire core team to lots of reviews isn't going to make people start reviewing things
15:23:19 efried I've always thought that was kind of a crappy expectation for casual contributors.
15:23:20 mriedem if it's important, yes, ask in irc or in the meeting
15:23:32 mriedem you can post things on the meeting for awareness without actually attending
15:23:57 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Enforce unified limits using oslo.limit https://review.opendev.org/615180
15:24:00 mriedem we've said multiple times that most if not all cores are ok with people asking for reviews in here (within reason)
15:24:01 efried "lots of reviews" principle applies regardless of the method
15:24:24 efried anyway, sorry, /me crawls back into hole
15:31:40 mriedem stephenfin: another way to get eyes on that series is putting it in runways - which has basically been empty all of ussuri
15:31:47 mriedem so i'm not sure why we're even doing runways anymore
15:32:20 artom mriedem, playing devil's advocate for a bit, a new contributor might now even know runways are a thing
15:32:25 artom *not even
15:32:38 mriedem i was going to tell dpawlik but they left
15:32:52 mriedem is dpawlik red hat?
15:33:16 artom mriedem, not to my knowledge
15:33:53 artom If they are, they're not Nova
15:34:02 mriedem at least they are documented https://docs.openstack.org/nova/latest/contributor/process.html#runways
15:36:16 mriedem ok dpawlik is ovh https://www.stackalytics.com/?user_id=daniel-pawlik
15:36:25 mriedem ovh devs aren't new to openstack or nova
15:36:26 artom mriedem, so, putting myself in the shoes of a new contributor, that link doesn't tell me "put your series in this etherpad and monitor it. When it hits a runway, be available to respond to feedback quickly and iterate fast."
15:36:33 mriedem so i'd hope that within their dev team they can explain how things work
15:36:47 mriedem artom: so write up some contributor docs
15:36:48 sean-k-mooney i added https://review.opendev.org/#/c/674072/ to the runway queue for what its worth. i thought i already had but i guess not
15:36:55 artom mriedem, can't argue with that :)
15:37:14 mriedem writing up stuff like this is near impossible, because it's either too much or not enough content
15:37:27 mriedem i'm pretty sure there are summit videos on this topic but people would have to find and watch them
15:37:40 mriedem within an organization of decent size with multiple developers there should also be mentoring
15:37:46 mriedem that's what we had at ibm when i was new to openstack
15:37:47 sean-k-mooney speaking of which are there any from china?
15:37:47 artom I know there are no magic bullets
15:37:48 efried mdbooth: it looks like mriedem was expecting you to weigh in on https://review.opendev.org/#/c/693537/ before it goes. Might you have a chance to hit that soon?
15:38:17 mriedem sean-k-mooney: any what from china?
15:38:24 artom mriedem, it's been a while since we've had someone entirely new to openstack join RH, but we did try to help francoisp get up to speed when he came in
15:38:26 sean-k-mooney ya it looks liek they start going up last week
15:38:31 sean-k-mooney mriedem: summit videos
15:38:32 artom That was really the only example I can think of
15:38:40 artom Everyone else we hired from upstream, so to speak
15:38:47 mriedem sean-k-mooney: the vidoes i saw posted were sparse - mostly keynotes and some vendor things
15:39:43 mriedem i'm pretty sure there is also a welcome wagon sig or something in openstack
15:39:49 mriedem so there are resources, but people need to do some work to find them
15:43:38 artom stephenfin, hey, so https://review.opendev.org/#/c/672595/ is still around. Can I help in any way to get another round of review from you on that?
15:43:49 artom Split it? Take over something of yours?
15:44:37 stephenfin nah, I just need to do it, but I have my head stuck into the removal of the nova-network security group driver. Could I look at it tomorrow?
15:44:54 artom stephenfin, sure - no huge rush, at this point.
15:45:09 artom I wanted to backport it to Train, but I probably missed the train (zing!) on that
15:45:19 artom I'll try anyways when it merges, see how it goes
15:58:47 openstackgerrit John Garbutt proposed openstack/nova master: WIP: Enforce unified limits using oslo.limit https://review.opendev.org/615180
16:20:24 gmann tssurya: but we do not know whether it is wrong or right. if keystone permissions to GET project is more strict than nova user, then project might exist but not shown to nova
16:22:58 tssurya gmann: sure but the problem with the current implementation is that it treats everything as "right". Even if the project is invalid, we end up giving the user the right to feed anything into the flavor_projects table
16:28:14 gmann tssurya: but it is 403, in case of invalid it will hit 404 condition. not 404 means project is there
16:34:49 openstackgerrit Merged openstack/nova master: api-guide: remove empty sections about inter-service interactions https://review.opendev.org/695774
16:35:19 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Test openstacksdk weakrefs https://review.opendev.org/695934
16:35:32 tssurya gmann: not really there can be a 403 on a case where the project doesn't exist right ?
16:35:52 tssurya because tenant doesn't have permission to verify if the project exists ?
16:39:19 gmann tssurya: not sure keystone does that and return 404 instead of 403. I know neutron return otherway- any PUT/DELETE request first call the GET and return 404 even resource exist and no permissions to GET(they do not return 403 because that is somehow telling resource exit).
16:40:23 tssurya gmann: yea I guess keystone is returning 403 which nova is silently ignoring
16:40:28 gmann i think keystone return 403 for permissions denied on GET project not 404. lbragstad ?
16:40:44 gmann lbragstad can confirm this for us.
16:40:47 lbragstad gmann it depends
16:41:09 lbragstad if you're technically authorized to get a project (e.g., you're a system administrator) you'll get a 404
16:41:30 lbragstad if you don't have the right authorization - then you get a 403
16:41:58 gmann yeah that is what nova assume- https://github.com/openstack/nova/blob/fd67f69cfdaf04620f2e8a5f1fbf5737096965d8/nova/api/openstack/identity.py#L26
16:42:22 lbragstad gmann ok - yeah, that looks right
16:42:24 gmann 403 means project is valid and exist and its only permission issue

Earlier   Later