Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-14
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 arvindn05 lol
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: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 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
21:59:35 jaypipes re-read our view.
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: Change TestNewtonCellsCheck to not rely on objects https://review.openstack.org/553082
22:02:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Add disabled column to cell_mappings table. https://review.openstack.org/552505
22:02:28 openstackgerrit Matt Riedemann proposed openstack/nova master: [WIP] Add disabled field to CellMapping object https://review.openstack.org/550090
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: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: generation in provider aggregate APIs https://review.openstack.org/548249
22:09:01 openstackgerrit Eric Fried proposed openstack/nova master: placement: Return new provider from POST /rps https://review.openstack.org/548934
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: Optional separate database for placement API https://review.openstack.org/362766
22:43:35 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
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
23:33:14 mriedem melwitt: done
23:33:23 melwitt thank ye
23:41:06 openstackgerrit Giridhar Jayavelu proposed openstack/nova-specs master: VMware: place instances on resource pool https://review.openstack.org/549067
#openstack-nova - 2018-03-15
00:02:35 jaypipes efried: +2 from me.
00:06:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Make nova-cells-v1 run with neutron https://review.openstack.org/549789
00:35:30 mriedem jaypipes: that vmware resource pool thing is basically equivalent to AZ:HOST:NODE:CLUSTER:POOL right?
02:12:00 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix allocation_candidates not to ignore shared RPs https://review.openstack.org/533396
02:12:00 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Test alloc_cands with indirectly sharing RPs https://review.openstack.org/519601
02:12:01 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Support relay RP for allocation candidates https://review.openstack.org/533437
02:12:01 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: remove not necessary short cut https://review.openstack.org/553122
02:21:29 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix comments in get_all_with_shared() https://review.openstack.org/533195
02:26:31 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova-specs master: Add host info to instance action events https://review.openstack.org/543277
02:42:31 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies https://review.openstack.org/546925
03:04:15 openstackgerrit melanie witt proposed openstack/nova master: only increment disk address unit for scsi devices https://review.openstack.org/538310
04:19:58 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared and dedicated VMs in one host https://review.openstack.org/543805
04:33:41 openstackgerrit Brooks Kaminski proposed openstack/nova master: XenAPI/Stops the migration of volume backed VHDS https://review.openstack.org/533168
04:33:52 Spaz-Work ^Ignore, just a rebase, will fix tests in a bit
04:59:52 openstackgerrit Giridhar Jayavelu proposed openstack/nova-specs master: VMware: place instances on resource pool https://review.openstack.org/549067
05:56:21 anadahz1BP3JC THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!

Earlier   Later