Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-14
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
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: Test alloc_cands with indirectly sharing RPs https://review.openstack.org/519601
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:01 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: remove not necessary short cut https://review.openstack.org/553122
02:12:01 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Support relay RP for allocation candidates https://review.openstack.org/533437
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!!
05:56:22 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!!
05:56:25 anadahz1BP3JC OctopusZhang claudiub|2 mdnadeem alexchadin ratailor udesale Dinesh_Bhor yamahata abhishekk sridharg bkopilov Tom-Tom links hshiina janki annp sree Spaz-Work psachin naichuans phuongnh mingyu_ r-daneel namnh salv-orl_ lei-zh tianhui tiendc zhaochao jichen stakeda tbachman xinliang odyssey4me tetsuro yamamoto sean-k-m1 hamzy Matias artom owalsh tojuvone rcernin gagehugo gbarros mvk mrjk imacdonn jamesdenton sapd_ arvindn05 jber
05:56:40 Spaz-Work Aigoo..
06:01:15 openstackgerrit jichenjc proposed openstack/nova master: Move test_allocation_candidates.py https://review.openstack.org/553149
06:05:31 openstackgerrit jichenjc proposed openstack/nova master: Move test_allocation_candidates.py https://review.openstack.org/553150
06:08:36 Spaz-Work Spent an hour trying to troubleshoot why my Tox was failing due to an 8 day old commit and was just my Tox ENV being dirty.. sigh.. Monnndayyyyysssssss
06:13:02 openstackgerrit jichenjc proposed openstack/nova master: Move test_resource_provider.py https://review.openstack.org/553150
06:13:03 openstackgerrit jichenjc proposed openstack/nova master: Move test_resource_class_cache.py https://review.openstack.org/553153
06:18:12 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/548772
06:59:54 openstackgerrit jichenjc proposed openstack/nova master: Move test_resource_class_cache.py https://review.openstack.org/553153
06:59:54 openstackgerrit jichenjc proposed openstack/nova master: Move test_resource_provider.py https://review.openstack.org/553150
07:26:30 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/553211
08:01:11 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/553255
08:05:36 Amit82 Hi All
08:05:37 Amit82 Can LXC container orchestration be done using HEAT?
08:23:01 openstackgerrit Jianghua Wang proposed openstack/os-traits master: GPU: define traits for display heads https://review.openstack.org/553277
08:50:40 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared and dedicated VMs in one host https://review.openstack.org/543805
09:20:36 openstackgerrit Brooks Kaminski proposed openstack/nova master: XenAPI/Stops the migration of volume backed VHDS https://review.openstack.org/533168
09:22:49 lennyb Hi, is it possible to clean/updated nova database? I have Orphaned Exception ( master branch ) http://paste.openstack.org/show/701494/
09:24:40 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
09:27:20 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: define a new image handler to use vdi streaming https://review.openstack.org/486475
09:27:20 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: deprecate the config for image handler class path https://review.openstack.org/497201
09:27:30 Spaz-Work OoOo
09:32:05 claudiub|2 jichen: hi. around?
09:32:19 jichen claudiub: yes
09:32:29 jichen claudiub: what's up?
09:32:44 claudiub cool. regarding the live-resize. do you really want to support live-downsize as well?
09:32:58 claudiub there's quite a bit of opposition to that. :)
09:34:38 claudiub or maybe we can add support for upsizing first, and then look into downsizing afterwards
09:34:54 jichen no, actually, I am ok if we only support upsize at first cycle
09:34:59 claudiub the nova cores seems to be fine with upsizing.'
09:35:07 jichen exactly, I agree with you
09:35:16 jichen upsizing should be first priority
09:35:27 claudiub great, then I will amend the spec to mention this fact.
09:35:42 jichen ok, perfect, thank you~
10:20:42 openstackgerrit Claudiu Belu proposed openstack/nova-specs master: Adds spec for instance live resize https://review.openstack.org/141219

Earlier   Later