Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-14
21:10:54 cdent rad
21:11:43 mnaser mriedem: apparently changing the id in change-id: <foo> doesn't do it?
21:12:24 mnaser maybe i need to recommit or rebase (i did edited with the ui)
21:17:25 mriedem i figured you could use the ui
21:21:39 sean-k-mooney jaypipes: just on the nic feature based schduling spec https://review.openstack.org/#/c/545951/
21:22:43 sean-k-mooney i just responed to you comments . i can resping if you want but many of the nits you raised are due to the fact that half of this feature merged in pike since it was feature complete since then
21:23:42 sean-k-mooney moving the nic feature to placement would be cool but they have been stored in the nova db for 2 release now so i would like to finish the use fo them first then port to placement
21:30:03 jaypipes sean-k-mooney: I'm already +2 on that. no need.
21:33:02 arvindn05 jaypipes: quick question on one of your comments
21:33:21 arvindn05 https://review.openstack.org/#/c/541507/ - Don't forget you will need to modify the existing ImageExtraSpecsFilter to ignore keys that start with "trait:", since clearly the placement API will have already filtered out hosts without the required traits...
21:33:53 arvindn05 for the comment mriedem pointed out there is no ImageExtraSpecsFilter. Was there a different filter you had in mind?
21:34:49 jaypipes arvindn05: yeah, it's ImagePropertiesFilter, sorry about that
21:35:04 jaypipes arvindn05: I always forget that it's named differently.
21:35:08 mriedem ImagePropertiesFilter only cares about 3 specific image props
21:35:23 mriedem should probably be renamed
21:35:30 jaypipes orly?
21:35:31 mriedem SuperSpecificImagePropertiesFilter
21:35:34 jaypipes lol
21:35:37 jaypipes TIL...
21:35:39 arvindn05 ^what mriedem said
21:35:52 melwitt ThreeSpecificImagePropertiesFilter
21:35:57 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/filters/image_props_filter.py#L46
21:36:07 arvindn05 actually 4 properties looks like..
21:36:09 jaypipes efried: "bogosity". well played.
21:36:15 arvindn05 if i trust the documentation :)
21:36:17 melwitt FourSpecificImagePropertiesFilter
21:36:25 jaypipes lol
21:36:31 arvindn05 architecture,hypervisor_type,hypervisor_version_requires,vm_mode
21:36:38 efried jaypipes: I calls 'em like I sees 'em
21:38:15 jaypipes arvindn05: don't forget the illustrative "i_am_nfv_and_do_what_want" property.
21:38:29 openstackgerrit Matt Riedemann proposed openstack/nova master: Change TestNewtonCellsCheck to not rely on objects https://review.openstack.org/553082
21:38:30 mriedem the value is a wildcard right?
21:38:52 mriedem dansmith: melwitt: ^ is the thing tssurya needed
21:39:02 jaypipes mriedem: on Tuesdays. on Wednesdays it's a reverse wildcard. On Thursday it's a regex and on Friday it's all whitespace.
21:39:04 melwitt jaypipes: been meaning to ask you, were you gonna update this unit test to do the BFV thing? or I can try to help with that if you want. if possible, I want to backport that all the way to ocata where it broke https://review.openstack.org/#/c/538310/2/nova/tests/unit/virt/libvirt/test_driver.py@3722
21:39:04 arvindn05 lol
21:39:49 jaypipes melwitt: I'd definitely appreciate a hand on that one.
21:40:03 melwitt jaypipes: cool, I'll take a stab at it
21:40:09 jaypipes melwitt: tyvm
21:49:54 jaypipes efried: issue in https://review.openstack.org/#/c/548249/
21:50:05 efried ack
21:50:49 efried jaypipes: Oh - cdent and I discussed this at the ptg
21:50:57 jaypipes efried: oh?
21:51:09 jaypipes heh
21:51:15 efried he assured me the exception wasn't possible anymore
21:51:27 cdent https://review.openstack.org/#/c/548249/2/nova/objects/resource_provider.py@493
21:51:41 mriedem arvindn05: +2 on https://review.openstack.org/#/c/541507/ now, thanks
21:51:44 cdent I did not assure you! I said I couldn't see how it could happen.
21:51:55 cdent Entirely different, sirrah.
21:51:58 cdent I may be blind
21:52:27 jaypipes efried, cdent: pretty sure it's still possible.
21:52:30 efried You totally assured me
21:52:38 efried listen to the tape
21:52:54 jaypipes efried, cdent: plus, defensive coding and all that...
21:53:10 efried shrug, okay
21:53:45 arvindn05 mriedem: thanks for the +2 :)
21:53:54 cdent it was conversation that would have been nice to have jaypipes at because we were both struggling to conceptualize how the transaction was operating
21:54:10 cdent and that without that it was all speculation and we didn't know how/if to even test it
21:54:12 arvindn05 now just need to bother jaypipes for his original +2 :)
21:55:31 jaypipes cdent: it's not necessarily about the transaction itself (or how it operates). it's about the consistent read view. another process could have modified the same resource provider in between the time when we originally began the transaction and when we go to incremenet the generation.
21:55:32 cdent so, jaypipes, if we ever get a clear moment to talk through that, it would be cool. probably wants a whiteboard though, so perhaps vancouver
21:56:15 cdent well that's exactly the part we couldn't conceptualize how/when does the read view change?
21:56:32 jaypipes arvindn05: +W
21:57:31 cdent if we have at some point in our transaction done a select on the resource provider (as is the case here), isn't that going to be "true" for the duration of the transaction?
21:58:02 cdent or does that require additional syntax?
21:59:35 jaypipes re-read our view.
21:59:35 jaypipes cdent: read view == "before I began trying to set these aggregates, the provider generation was 101". we then start the transaction and begin inserting and deleting records from the resource_provider_aggregates table. after our transaction began, another process can modify the resource provider record and update the generation. that is an indication that the state we viewed at the beginning of the transaction has changed and we will need to
22:01:22 jaypipes cdent: when another process calls COMMIT on a transaction, the changes made in that transaction are now viewable by other transactions that are in process. Changes made in another process's transaction *before* the COMMIT are generally *not* viewable by another process' transactions unless the READ UNCOMMITTED transaction isolation level is set.
22:02:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Add disabled column to cell_mappings table. https://review.openstack.org/552505
22:02:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Change TestNewtonCellsCheck to not rely on objects https://review.openstack.org/553082
22:02:28 openstackgerrit Matt Riedemann proposed openstack/nova master: [WIP] Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188
22:02:28 openstackgerrit Matt Riedemann proposed openstack/nova master: [WIP] Add disabled field to CellMapping object https://review.openstack.org/550090
22:02:29 openstackgerrit Matt Riedemann proposed openstack/nova master: [WIP] Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
22:02:46 efried Meaning the operation as a whole is atomic, but non-locking.
22:03:26 efried It's a race: whoever gets to COMMIT first, wins.
22:03:47 efried But the stuff happening within one transaction isn't fuddling the other.
22:04:22 cdent efried: I seem to recall you had concerns that needed to be addressed if this is how things turned out, or is "this" some middle ground between the extremes you were thinking of?
22:04:30 efried the latter
22:04:54 efried Because I was concerned that the state would change between when we read things an when we updated them.
22:06:10 efried I guess that's still true, but the code is set up to raise ConcurrentUpdateException if that happens - assuming whatever operation we're doing is incrementing the generation.
22:06:34 efried though this may actually mean we have holes in things that don't muck with generations...
22:06:50 cdent right, the only reason it's not a problem is becsuse incrementing the generation is an update
22:07:52 efried specifically because we have this code to check for generation mismatch.
22:08:02 cdent yes
22:08:15 efried Though technically there's still a hole - if we check for mismatch riiiight before the other transaction commits.
22:09:01 openstackgerrit Eric Fried proposed openstack/nova master: placement: Return new provider from POST /rps https://review.openstack.org/548934
22:09:01 openstackgerrit Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249
22:09:02 openstackgerrit Eric Fried proposed openstack/nova master: Stop assuming initial provider generation is 0 https://review.openstack.org/548975
22:09:04 efried jaypipes: Howzat? ^
22:09:59 cdent efried: I don't think that's the case, because we're not checking for mismatch. We are doing an update that can fail, which is different (at least as far as I understand things, but as this conversation has demonstrated there are some holes in my understanding)
22:10:01 efried Never mind about the hole, I think I see how it works.
22:10:03 efried yeah.
22:24:18 openstackgerrit Giridhar Jayavelu proposed openstack/nova-specs master: VMware: place instances on resource pool https://review.openstack.org/549067
22:25:41 openstackgerrit Merged openstack/nova-specs master: Support traits in Glance https://review.openstack.org/541507
22:43:35 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
22:43:35 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
22:48:48 melwitt mriedem: here's the nova/cinder session summary, if you have anything to add/correct https://etherpad.openstack.org/p/nova-ptg-rocky-cinder-summary
23:28:04 Spazmotic Morning folks.
23:29:21 mriedem melwitt: do you want to link patches in there for stuff that's in progress now?
23:30:01 melwitt mriedem: sure, why not. I wasn't really thinking about it

Earlier   Later