Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-23
12:50:03 kashyap mdbooth: Yes, that's for network storage (Ceph)
12:50:16 kashyap Which means something else, as you know.
12:50:34 mdbooth Ah, I thought the log you showed me was non-ceph
12:50:49 kashyap It was Ceph, sorry for misinforming. I sit corrected
12:50:51 mdbooth And I'd assumed we'd explicitly configured CI to prefer performance over data integrity
12:51:00 mdbooth Which wouldn't be unreasonable
12:51:04 kashyap Yeah
12:55:12 openstackgerrit Forest Romain proposed openstack/nova master: Fix list servers by hypervisor https://review.openstack.org/518699
12:56:03 kashyap mdbooth: Also - https://review.openstack.org/#/c/522067/1
13:06:20 openstackgerrit Merged openstack/nova master: Fix the usage of instance.snapshot notification sample https://review.openstack.org/520579
13:59:20 bauzas heh, I never saw the gate so empty :p
13:59:31 bauzas eat turkey, folks!
14:00:19 bauzas (at least, the ones wanting to eat turkey are just awakening and preparing the dinner :p )
14:20:57 mdbooth Can't build current requirements, as protobuf 3.5.0 doesn't seem to be a thing
14:21:24 mdbooth Although as it only seems to be in upper-requirement.txt, not entirely sure why it needs to be
14:21:28 mdbooth Anybody else hit this?
14:22:27 mdbooth probuf was bumped in Ie610db5304707e3db9f7025037405a3af79d2ce3, which landed on 17th (last Friday)
14:23:41 tssurya mdbooth : yes
14:24:03 tssurya mdbooth : https://bugs.launchpad.net/openstack-requirements/+bug/1734009
14:24:03 openstack Launchpad bug 1734009 in OpenStack Global Requirements "No matching distribution found for protobuf===3.5.0" [Undecided,New]
14:24:21 mdbooth tssurya: Thanks
14:27:11 kashyap mdbooth: It's not Friday yet, but check out this easter egg here :-)
14:27:16 kashyap https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
14:27:32 kashyap Typing 'man' command after 00:30 prints "gimme gimme gimme"
14:27:39 kashyap An allusion to some pop culture song :P
14:29:06 kashyap The "bug" is fixed, though. The author admits "It was never meant to affect non-error cases."
14:29:21 mdbooth kashyap: lol
14:29:47 kashyap mdbooth: But I like it that they fixed it _while_ retaining the easter egg.
14:52:08 johnthetubaguy mdbooth: +1 what lyarwood said, hoping for connection_info fetched from cinder every time, the current patches don't quite get there yet, but should be possible.
14:52:47 mdbooth johnthetubaguy: Was pretty sure that was where we were heading, but noted that it would regress restart after host reboot
14:53:15 johnthetubaguy mdbooth: you would just pull from cinder I think, or would that break for some reason?
14:53:31 mdbooth johnthetubaguy: This currently works only because we cache it, as we can't fetch it from cinder without an auth context
14:53:53 johnthetubaguy oh right, there are other cases as well I think
14:54:05 johnthetubaguy auto unrescue I think
14:54:14 johnthetubaguy we need an admin token like we do for neutron
14:54:22 johnthetubaguy I had totally forgotten about that mess
14:54:29 johnthetubaguy just as well we don't drop the cache yet
14:54:47 johnthetubaguy ildikov: tl;dr you are correct to keep caching connection_info for now: ^
14:55:04 johnthetubaguy mdbooth: great reminder, complete forgot all that
14:56:24 mdbooth johnthetubaguy: lyarwood Not familiar with the admin token thing. Does that provide Nova with some special admin privs when calling a remote service without requiring user creds?
14:56:40 mdbooth And does it exist already for cinder, or is it currently a neutron only concept?
14:58:17 mdbooth johnthetubaguy: For additional context, btw, encrypted volumes are broken in the above situation because we *don't* cache credentials (and mustn't)
14:58:44 johnthetubaguy ah, right...
14:58:51 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297
14:58:51 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459
14:59:10 mdbooth So we're already not doing this properly for instances with volumes
14:59:17 johnthetubaguy mdbooth: the admin token is really just something that access all projects, so you don't need to use the non-existent user token
14:59:43 johnthetubaguy creds are just in the nova conf
14:59:58 mdbooth johnthetubaguy: Would that allow me to fetch a volume's encryption credentials?
15:00:15 johnthetubaguy I presume it should, for better or worse
15:00:34 mdbooth If it does, we might as well just cache them
15:00:42 mdbooth In which case, we might as well not have them
15:01:21 johnthetubaguy there was a plan to fetch it from nova-conductor, assuming AMQP gets secured, but you can still get the key
15:01:56 johnthetubaguy i.e. nova-conductor has the admin token and does the fetch on behalf of nova-compute
15:02:24 mdbooth That's still not separating the management domains.
15:02:31 johnthetubaguy agreed
15:02:40 mdbooth Unless I've completely misunderstood what volume encryption is for
15:03:00 johnthetubaguy the main use case I heard was when you don't trust the shared storage, rather than securing the hypervisor aas such
15:03:19 johnthetubaguy or rather, the shared storage is more shared than you would like
15:03:51 mdbooth Does cinder have an admin token?
15:04:14 mdbooth Or are we literally just talking about the bit bucket?
15:06:01 johnthetubaguy mdbooth: not sure what you mean, we don't have one in the conf yet, AFAIK
15:13:12 openstackgerrit jiangpf proposed openstack/nova master: Encode libvirt domain XML in UTF-8 https://review.openstack.org/522161
15:23:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Deprecate file injection https://review.openstack.org/522027
15:29:46 openstackgerrit Merged openstack/python-novaclient master: Use utils.prepare_query_string instead of duplicated code https://review.openstack.org/515640
15:35:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured https://review.openstack.org/521947
15:38:04 openstackgerrit Stephen Finucane proposed openstack/nova master: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489
15:43:39 smcginnis mdbooth: Some would argue he is.
15:55:23 openstackgerrit Stephen Finucane proposed openstack/nova master: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489
15:55:46 stephenfin cfriesen: How bored are you today? ^
15:56:49 stephenfin johnthetubaguy: You talked about upgrade issues around https://review.openstack.org/#/c/244489/ at a previous PTG. Any idea you recall what they were?
15:57:29 johnthetubaguy stephenfin: it should be in the review comments, let me take a quick peak
15:59:11 stephenfin johnthetubaguy: Cool. The only open comment I can see is this one, but I'm not sure what you mean https://review.openstack.org/#/c/244489/59/nova/compute/resource_tracker.py@224
15:59:31 stephenfin The other ones here are resolved https://review.openstack.org/#/c/244489/59/nova/compute/manager.py
15:59:44 johnthetubaguy oh, my, that was during the PTG, and I wasn't very helpful there
16:02:59 johnthetubaguy stephenfin: I think the bit I was worried about was the compute manager stuff, making and making sure both nodes are upgraded before expecting the new flow to work
16:03:19 johnthetubaguy stephenfin: looks like you replied done to those now
16:05:03 stephenfin johnthetubaguy: So is https://review.openstack.org/#/c/244489/59/nova/compute/resource_tracker.py@224 still relevant?
16:05:30 johnthetubaguy stephenfin: I am not sure what I mean with that, the thing I remember is the RPC versions and sending extra info
16:06:00 stephenfin Heh
16:06:23 johnthetubaguy the DB logic in rpcapi.py is freaking me out a touch, feels like the wrong level of abstraction
16:06:45 johnthetubaguy I guess we have normally checked the service version to do stuff like that, but checking the compute rpcapi pin is basically the same
16:07:40 stephenfin Aye, that comment has come up before. I'm not sure how to move it out and Pawel had the same issue :/ https://review.openstack.org/#/c/244489/50/nova/compute/rpcapi.py@455
16:08:14 stephenfin This is a really horrible patch to review, heh
16:24:41 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node https://review.openstack.org/516217
16:24:42 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899
16:27:52 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor https://review.openstack.org/512965
16:27:53 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node https://review.openstack.org/516217
16:27:53 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899
16:30:33 jianghuaw_ bauzas, ^these three patches should works for XenAPI vGPU. And have included the restriction which only allows on vGPU type enabled in one compute node.
16:31:14 bauzas jianghuaw_: well, for me I'm testing my inventory patch but for some reasons, I'm not seeing the new inventory :(
16:32:27 jianghuaw_ bauzas, strange. It should have the new inventory per the source code.
16:32:42 bauzas oh man
16:32:56 bauzas I haven't modified the nova.conf
16:33:14 jianghuaw_ aha.
16:33:17 bauzas ooops :
16:38:06 openstackgerrit Claudiu Belu proposed openstack/nova master: POC: tests: fixes mock autospec usage https://review.openstack.org/447505
16:42:04 jianghuaw_ bauzas, I'm also going to add inventory data for VGPU_DISPLAY_HEAD in XenAPI.
16:46:03 openstackgerrit Stephen Finucane proposed openstack/nova master: DNM: Move handling of legacy compute nodes to conductor https://review.openstack.org/522606
16:46:37 stephenfin johnthetubaguy: Does that make any sense at all? I've kept it separate in case it's nonsense (I'm not _at all_ familiar with this code)

Earlier   Later