Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-24
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
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
06:06:22 brinzhang__ cf__: If it's a root disk, you can see the delete_on_termination from 'nova show server_id'
06:06:39 brinzhang__ [root@localhost ~]# nova show ec939a46-9e1e-4126-8214-6ceb3b95676a |grep volume
06:06:39 brinzhang__ | image | Attempt to boot from volume - no image supplied |
06:06:39 brinzhang__ | os-extended-volumes:volumes_attached | [{"id": "df191675-0ac1-4101-a590-7ad2f7607e89", "delete_on_termination": true}] |

Earlier   Later