Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-24
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 2) update the cache
20:53:55 efried 1) retrieve from 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 ?
20:54:53 mriedem or don't get from the cache, get from the API, but update the cache...
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
22:27:09 tonyb sean-k-mooney: we (the requirements team) clearly need better reference docs or a FAQ or something
22:47:14 openstackgerrit Merged openstack/nova master: bdm: store empty object as connection_info by default https://review.opendev.org/645352
#openstack-nova - 2019-06-25
00:04:29 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Add a guide to add a new microversion support https://review.opendev.org/667002
00:07:45 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.opendev.org/580336
00:08:08 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support delete_on_termination in volume attach api https://review.opendev.org/612949
01:12:52 openstackgerrit Alex Xu proposed openstack/nova master: Correct the comment of RequestSpec's network_metadata https://review.opendev.org/667061
03:40:46 openstackgerrit huichen proposed openstack/nova master: Support pagination for sever groups by sql https://review.opendev.org/667259
05:50:52 cf__ Hi! I asked in cinder channel yesterday regarding delete_on_termination and they pointed me towards nova, which make sense, however, when I do nova show <uuid>, I do not receive any information about delete_on_termination, even that I did set it when creating the instance.. What am I doing wrong, to check if the volume is going to be deleted on instance termnination?
05:56:29 cf__ $ nova show 83fcdb58-045a-4475-b4eb-5b9287daebcc |grep volume
05:56:30 cf__ | os-extended-volumes:volumes_attached | [{"id": "f3e192b6-f8b0-4a9b-8512-4e7ffa37756d"}]
06:05:31 brinzhang__ cf__: What about your volume? root disk? or data disk ?
06:06:05 cf__ brinzhang__: it's my root disk

Earlier   Later