Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-24
20:47:40 mriedem right?
20:48:05 efried I don't see why not.
20:48:30 efried We'd be updating the cache, but not reading from it anywhere.
20:48:42 efried Updating the cache is of negligible cost
20:48:46 mriedem " # NOTE(efried): This will blow up if called for a RP that doesn't # exist in our _provider_tree. "
20:48:49 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add placement request filter for disabled computes https://review.opendev.org/654596
20:50:13 efried mriedem: by that point in _refresh_associations, we're already assured the provider is in our cache.
20:50:28 efried you're saying if it's called from elsewhere where that's not the case
20:50:35 efried so yeah, trap and ignore ValueError
20:50:37 efried done
20:50:55 openstackgerrit Merged openstack/python-novaclient master: Revert "Add irrelevant files in dsvm job" https://review.opendev.org/667151
20:51:26 mriedem blech
20:51:35 efried you could do that from within the new-and-improved get_provider_traits
20:51:37 mriedem but yeah that's what i meant - called from conductor where the rp isn't in the cache
20:51:39 efried or check the cache first.
20:52:13 mriedem i'm going to avoid all of that for now because then you could have questions like, "should the caller say if they want the cache and should fail if the rp isn't in the cache?"
20:52:15 efried if self._provider_tree.exists(rp_uuid):
20:52:37 efried "avoid all of that for now" is going to be harder and introduce more technical debt.
20:52:39 mriedem sure - but if i'm compute and expect it in the cache and it's not, we'd want that to fail, not be swallowed
20:53:05 mriedem that's why i said a use_cache kwarg on get_provider_traits seems easier
20:53:07 mriedem the caller says what it wants
20:53:43 efried but you need two knobs
20:53:45 mriedem the very first thing i want to do is just split this large-ish change up into several pieces so i can test in isolation and reason about it
20:53:55 efried 1) retrieve from the cache
20:53:55 efried 2) update the cache
20:54:02 efried one does not imply the other
20:54:18 mriedem ...
20:54:38 mriedem meaning refresh if it's not in the cache and return the cached results,
20:54:53 mriedem or don't get from the cache, get from the API, but update the cache...
20:54:53 mriedem ?
20:55:51 mriedem i'm just going to work on splitting this all up and put a TODO in my code that uses get_provider_traits to somehow leverage the cache - it can be debated in review at that point i think when i actually have something working end to end (which the change is now - the func test shows that, but i'm going to be splitting up and possibly breaking things)
20:56:10 efried okay
20:57:07 spatel sean-k-mooney: hey
20:58:27 efried nts: http://specs.openstack.org/openstack/nova-specs/specs/train/approved/pre-filter-disabled-computes.html
21:08:00 mriedem heh well i've got a chicken-and-egg so i likely can't use the cache anyway
21:08:27 mriedem rt init needs the driver https://github.com/openstack/nova/blob/914ee91a5caedcaba64472762c9f08d7bb644d11/nova/compute/manager.py#L538
21:08:37 mriedem and the driver init needs the virtapi https://github.com/openstack/nova/blob/914ee91a5caedcaba64472762c9f08d7bb644d11/nova/compute/manager.py#L535
21:09:52 mriedem unless i do something hacky like self.virtapi.reportclient = self.reportclient....
21:14:22 efried that's what we've done all over the place, innit?
21:14:47 efried I guess mostly the other way around, self.reportclient = self.otherthingy.reportclient
21:15:09 efried you could pass the reportclient into the virtapi constructor
21:16:09 mriedem yeah i'm constructing the singleton reportclient in ComputeManager and passing that to RT and ComputeVirtAPI
21:16:36 efried ++
21:42:47 tonyb sean-k-mooney: We needed to do it in requirements in order to *generate* constraints
21:45:04 tonyb sean-k-mooney: You say it's breaking the requirements-check job but I don't see that
21:45:37 tonyb sean-k-mooney: Given our, lack, of TZ overlap might be best to do this via email?
21:45:53 sean-k-mooney im here
21:46:14 sean-k-mooney we do not generate constratis to project anymore
21:46:23 sean-k-mooney at least the lower constratits
21:47:21 sean-k-mooney the reason i say i breaks the requirement check is https://review.opendev.org/#/c/666651/2/doc/requirements.txt
21:47:56 sean-k-mooney simply addint a comment or otherwise modifying the requiremetns file cause the requirements-check job to fail
21:48:42 sean-k-mooney we can see the error here
21:48:45 sean-k-mooney http://logs.openstack.org/51/666651/2/check/requirements-check/c8c82c5/job-output.txt.gz#_2019-06-20_17_39_08_901350
21:48:49 sean-k-mooney tonyb: ^
21:48:52 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add placement request filter for disabled computes https://review.opendev.org/654596
21:49:09 tonyb sean-k-mooney: okay so there are a couple of things
21:49:53 tonyb sean-k-mooney: the requirements team needs to generate constraints (upper) daily and without capping sphinx (and others) in g-r we can't do that
21:50:32 sean-k-mooney ah so when you said generate you ment upper-constraitns not requirement files for projects
21:50:48 tonyb sean-k-mooney: and also the 'fix' to that error is to just merge the chnage that caps sphinx, which is the expected process albeit a little ugly now that we don't auto-sync
21:51:08 tonyb sean-k-mooney: correct
21:51:30 sean-k-mooney yes we have a patch for that but my understdaint is project are not ment to cap any package in ther own reqiuremets file
21:51:57 sean-k-mooney the can balcklis tthing the know do not work but if cap we can break compatiobliy for the intergrated services
21:52:07 tonyb sean-k-mooney: In general we try very hard not to cap in g-r or per project but it isn't "forbidden"
21:52:25 tonyb sean-k-mooney: and with this whole no more py2 support thing we don't have a choice
21:52:53 sean-k-mooney well that is due to useing gloabl-requiremtns for two thing
21:53:13 sean-k-mooney generatihing upper-constratints and capping python2 things
21:53:36 tonyb sean-k-mooney: and listing "approved libraries" so that's 3 things
21:53:42 sean-k-mooney well no it because we use it for generating uppercontratitgs
21:53:48 sean-k-mooney ya
21:54:14 sean-k-mooney so the last point is what i thought its priamary pourpous was
21:54:35 sean-k-mooney listing the appoved libs that wee know are compatiable and are manged by the requiremetns project
21:54:51 tonyb sean-k-mooney: I'm interested in your statement "if cap we can break compatiobliy for the intergrated services" can you elaborate?
21:55:33 sean-k-mooney os-vif say mock < X some other poject requires mock > x
21:55:48 sean-k-mooney os-vif and that service can nolonger be installed together
21:56:10 tonyb sean-k-mooney: ahhh okay .... that's handled in the generate-constraints job so it *shouldn't* be possible
21:56:34 tonyb sean-k-mooney: for *upper* constraints for lower all bets are off
21:56:37 sean-k-mooney can you explain breifly how upper-constratis is generated
21:56:59 sean-k-mooney i.e. how is gr used for uc
21:57:14 tonyb sean-k-mooney: basically we pip install -r global-requirements.txt and "freeze" the output
21:57:18 sean-k-mooney i was not aware uc was generated for gr
21:57:34 sean-k-mooney i though uc was manually updated as needed
21:57:57 sean-k-mooney rathar then auto updating as upstream releases?
21:58:03 sean-k-mooney i guess that is not the case?
21:58:16 tonyb for master it's a daily update and then "fixed" if needed, for stable it's all manual
21:58:39 sean-k-mooney ah ok so master allows latest unless we know somthing is broken
21:58:53 sean-k-mooney is gr used to pin things that are broken in that case ?
21:58:59 tonyb https://review.opendev.org/#/c/666981/ was last night's auto generate
21:59:33 tonyb sean-k-mooney: Yes, if lib $foo has a broken version we add a != in g-r to avoid it
21:59:47 openstackgerrit Eric Fried proposed openstack/nova-specs master: Libvirt: add vPMU spec for train https://review.opendev.org/651269
22:00:22 sean-k-mooney and we are now using sphinx < 2.0 as a shorthad to cover all the non py27 versions
22:01:45 sean-k-mooney ok i can approve https://review.opendev.org/#/c/666387/ but its kind of regretable that we will have to modify requirement every time gr is modifed to reflect a new cap.
22:02:08 sean-k-mooney if the cap was only done via upper-constratits then it would just automaticlly work
22:02:19 tonyb sean-k-mooney: Yes, we've always needed to do that but it's just more obvious now
22:02:35 tonyb sean-k-mooney: I agre it's ugly but we can't think of a better way with the tools we have
22:02:45 sean-k-mooney nova os-vif and other project that generate docs form code need to use uc to pin to compatible verions anyway otherwise they can fail
22:03:13 tonyb sean-k-mooney: correct
22:03:45 tonyb sean-k-mooney: gotta disappear I'll be back in a bit
22:04:27 sean-k-mooney hehe im going to drop too. i was playing games on my desktop but its late enough now that i should praobbly call it a day o/
22:04:40 sean-k-mooney tonyb: thanks for explainin
22:05:33 sean-k-mooney i had taken the view that capping in requiremetn in repo was nolonger allowed but ill adjust to allowing it if it is capped that way in gr going forward

Earlier   Later