Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-08
16:19:56 bauzas stephenfin: yeah sorry this patch is mostly a cleanup prep work
16:28:01 openstackgerrit Merged openstack/nova master: Introduce scope_types in simple tenant usage https://review.opendev.org/717586
16:28:05 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Make 'server list --config-drive' a boolean option https://review.opendev.org/718349
16:28:24 stephenfin gibi: you'll probably want that for 2.85, assuming you like the approach ^
16:28:37 gibi ack
16:33:25 gibi stephenfin: +2
16:33:42 stephenfin \o/
16:37:50 gibi stephenfin: and +2 on both of the extra spec FUPs
16:43:19 bauzas gibi: stephenfin: sorry I dropped my attention from the issue gibi found (thanks btw.!) but can I take a look at it now ?
16:43:28 openstackgerrit Sylvain Bauza proposed openstack/nova master: Functional test with pGPUs https://review.opendev.org/717975
16:43:28 openstackgerrit Sylvain Bauza proposed openstack/nova master: FUP: Support multiple vGPU types https://review.opendev.org/718516
16:43:29 stephenfin yup, I think so
16:43:54 bauzas gibi: stephenfin: FWIW, I worked the func tests for verifying both types and provided a FUP based on lyarwood's comments ^
16:44:24 bauzas I totally understand how vGPU in libvirt is old greek, that's why you can ask me for more functional testing if you want
16:45:27 bauzas gibi: FWIW, your reshape test also simulates a Train compute and I didn't had to change this reshape test (except where to call the config) for making it work, which proves I didn't regress
16:45:48 bauzas stephenfin: and ack, will review your last bits before I go
16:52:00 openstackgerrit Sylvain Bauza proposed openstack/nova master: Functional test with pGPUs https://review.opendev.org/717975
16:52:00 openstackgerrit Sylvain Bauza proposed openstack/nova master: FUP: Support multiple vGPU types https://review.opendev.org/718516
16:52:54 dansmith melwitt: so, I didn't go looking, but where's the entrypoint for the thing when we're running underneath a proper WSGI server like apache or nginx? I'm guessing maybe that won't suffer from the same issue because it's forked from the main process before it gets to any nova/oslo stuff, but.. did you confirm?
16:55:04 melwitt dansmith: oh, no ... I had looked only at the nova/cmd because I was focused on nova-scheduler. hmm
16:55:42 melwitt but I'd guess the same
16:56:28 dansmith melwitt: okay one more comment on the wsgi service if you can look
16:56:39 openstackgerrit Balazs Gibizer proposed openstack/python-novaclient master: Microversion 2.85: Change volume-update CLI https://review.opendev.org/712651
16:56:42 dansmith not related to scheduler of course, but ...
16:57:00 openstackgerrit Merged openstack/nova master: partial support for live migration with specific resources https://review.opendev.org/715362
16:57:04 gibi stephenfin: 2.85 client patch enhanced by following your lead https://review.opendev.org/712651
16:57:33 gibi and that marks the end of my day.
16:58:02 stephenfin I'm knocking off shortly. Will grab that before then (y)
16:58:43 gibi see you folks tomorrow o/
16:58:45 melwitt dansmith: oh, dang, I had meant to add to WSGIService as well but it slipped my mind, likely because WSGIService derives from Service ... but it overrides start() so I need to
16:59:01 dansmith melwitt: yeah
16:59:10 melwitt ok lemme do that. thanks for catching
16:59:46 bauzas gibi: have a good one \o
17:00:02 dansmith melwitt: yeah you'd kinda assume it inherits from Service above, but not so much.. I've been burned by that one before
17:00:31 melwitt oh it doesn't lol ... even THAT burned me
17:00:37 melwitt service.Service vs Service
17:01:32 openstackgerrit Merged openstack/nova master: Pass the actual target in limits policy https://review.opendev.org/715761
17:02:29 stephenfin bauzas: loads of comments on https://review.opendev.org/#/c/715490/ for the morning
17:02:46 bauzas stephenfin: days are long at home
17:04:02 openstackgerrit Merged openstack/nova master: Support live migration with vpmem https://review.opendev.org/687856
17:04:05 bauzas stephenfin: actually, looking at your comments and trying to get the main problems so I could fix them while you sleep
17:04:20 bauzas you said caching
17:04:31 bauzas but we already cache it per se
17:04:31 stephenfin yeah, for the call to '_get_supported_vgpu_types'
17:05:09 bauzas stephenfin: well, we now lookup self.supported_vgpu_types
17:05:15 sean-k-mooney if you need to cache things use functool.lru_cache decorator
17:05:18 bauzas which is instanciated at startup
17:06:06 stephenfin bauzas: you're right. Sorry, I missed that /o\
17:06:44 bauzas stephenfin: no worries I'll address your comments tho
17:07:29 stephenfin cool. Happy to toggle when there's a follow up
17:07:29 bauzas stephenfin: I just provided a mapping table lookup method for getting the vgpu type, that's probably what confused you
17:07:33 sean-k-mooney bauzas: you did comment about not wanting to check the config too many times in a respocnc too lee which confused me a bit as ya its only don on agent start
17:07:56 bauzas sean-k-mooney: the comment was on the previous patch IIRC
17:08:02 bauzas unless I'm wrong
17:08:02 sean-k-mooney yes
17:08:18 sean-k-mooney but i have had that in my mind while reviing the followup
17:08:23 bauzas ok, so, the previous patch calls self._get_supported_types N times
17:08:42 sean-k-mooney e.g. that was something you were were concerned about so i am watching for that
17:08:56 bauzas but this patch introduces some startup call that instanciates an object in the driver
17:09:11 bauzas that's not really a cached object
17:09:18 bauzas ie. we don't need to update it
17:09:29 bauzas we just read it once at startup, that's it
17:09:45 sean-k-mooney yep which is fine
17:09:50 bauzas (and that's how folks I tried to avoid the known issue of cache invalidation)
17:11:21 sean-k-mooney yep but use to reiterate if people feel they need cacheing of functions now that we can depend on being python 3 we shoudl use https://docs.python.org/3/library/functools.html#functools.lru_cache
17:11:50 bauzas sean-k-mooney: gtk
17:12:38 bauzas ah, interesting
17:12:51 sean-k-mooney there is a backport in cachetools which is technically in the requirements repo but i never felt there was a justification for using it in nova as an extra dep
17:12:54 bauzas but I wouldn't use it for simple dicts
17:13:23 bauzas yeah, it's intended for large dicts with high access rate
17:13:35 bauzas hence the name FWIW
17:14:04 bauzas sean-k-mooney: and honestly, maybe just worth it for nova-api
17:14:30 sean-k-mooney there are other places where it makes sense
17:14:53 sean-k-mooney if we ever think maybe we should add a cache and go to add a maunal modle level dict
17:14:59 sean-k-mooney we shoudl see if this can be used instead
17:16:42 sean-k-mooney for example this would be good for caching the pci whitelist parsing
17:17:14 sean-k-mooney we currently parse it over and over again in the periodics but we dont have too
17:17:53 sean-k-mooney its not a muteable config option but the patches to intoduced that were consider too trival to merge for the extra code of doing it manallly
17:18:07 sean-k-mooney jsut adding a decorator however is much lighter weight
17:25:17 bauzas sean-k-mooney: maybe, at least just having some object in memory isn't crazy
17:25:46 bauzas sean-k-mooney: I was more talking about using this lib, which is intended for high frequency rates, which isn't the case
17:26:45 sean-k-mooney bauzas: https://pypi.org/project/cachetools/ that one
17:27:11 bauzas ah ok
17:27:25 sean-k-mooney it would have been perfect for https://review.opendev.org/#/c/599071/
17:27:28 bauzas (like the two other nights)
17:27:38 sean-k-mooney bauzas: o/
17:27:42 bauzas gosh, I missed working upstream...
17:29:23 sean-k-mooney i shoudl really go back and replace that and the other memorize decoratos at some point
17:55:18 openstackgerrit melanie witt proposed openstack/nova master: Reset the cell cache for database access in Service https://review.opendev.org/717662
17:56:22 melwitt dansmith: finally updated ^ I spun around for awhile trying to find a way to restart the func test nova-api service (OSAPIFixture) before concluding that it doesn't leverage the WSGIService in any way. so I instead used the OSMetadataServer fixture
18:49:01 openstackgerrit Merged openstack/nova master: Correct server topology policy check_str https://review.opendev.org/717525
19:32:05 openstackgerrit Merged openstack/nova master: Separate update and swap volume policies https://review.opendev.org/711194
19:32:20 openstackgerrit Merged openstack/nova master: Fix server metadata policy to be admin_or_owner https://review.opendev.org/717189
19:32:27 openstackgerrit Merged openstack/nova master: Add test coverage of existing server metadata policies https://review.opendev.org/717182
19:32:35 openstackgerrit Merged openstack/nova master: Introduce scope_types in server metadata https://review.opendev.org/717215
19:32:43 openstackgerrit Merged openstack/nova master: Add new default roles in server metadata policies https://review.opendev.org/717255
19:50:16 openstackgerrit Merged openstack/nova master: Add release notes for Cyborg-Nova integration. https://review.opendev.org/716185
20:16:57 melwitt gibi: I had to respin https://review.opendev.org/717662 to add a cache clearing to WSGIService, if you could pls re-review when you get a chance
21:57:16 openstackgerrit Sylvain Bauza proposed openstack/nova master: Support different vGPU types per pGPU https://review.opendev.org/715490
21:57:16 openstackgerrit Sylvain Bauza proposed openstack/nova master: Functional test with pGPUs https://review.opendev.org/717975

Earlier   Later