Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-29
16:42:09 Spazmotic He always gives me good ideas though so.. love me some Bob
16:47:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961
16:47:28 mriedem artom: jaypipes: added a variable for the original image ref and a comment about CastAsCall
16:47:51 mriedem Spazmotic: johnthetubaguy knows the xenapi stuff
16:48:01 mriedem and is still core, but not working as much upstream these days
16:48:09 artom mriedem, and defiantly ignored my grammar nit ;)
16:48:19 Spazmotic Yeah he's been busy with family stuff.. I got in touch with him the other day though, but figured i'd ask since we need 2 cores
16:48:35 johnthetubaguy yeah, I am around for some questions, much of the time
16:48:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961
16:48:48 mriedem artom: there you go
16:48:49 Spazmotic Now look what you did
16:48:52 johnthetubaguy (still trying to juggle back more reviewing time)
16:49:04 mriedem it's is always something i'll think of since school as a possessive
16:49:23 artom mriedem, cheers :)
16:49:40 Spazmotic hehe spend time with your family john, more important than reviews :D
16:49:43 jaypipes mriedem: danke
16:51:35 mriedem johnthetubaguy: if you are around, i'll badger you about https://review.openstack.org/#/c/527541/
16:51:59 johnthetubaguy mriedem: sure thing
16:53:59 johnthetubaguy mriedem: is the TODO about jay's join magic important?
16:54:08 mriedem no
16:54:29 jaypipes quoi?
16:54:45 johnthetubaguy https://review.openstack.org/#/c/527541/4/nova/cmd/status.py@413
16:54:47 mriedem https://review.openstack.org/#/c/527541/4/nova/cmd/status.py@413
16:54:48 mriedem yeah
16:55:01 Spazmotic someone owes someone a coke dependant upon latency and such
16:55:03 mriedem jaypipes: it's a nova-status check for ironic / instance flavor migration
16:55:17 mriedem something we should have done in pike, so i plan on backporting
16:56:56 jaypipes ah, k
16:59:07 mriedem gibi: speaking of things i don't think we want to backport if we can help it https://review.openstack.org/#/c/522112/
16:59:21 mriedem ^ adds the ability to specify service/admin user creds for cinder operations,
16:59:22 mriedem like neutron
16:59:34 mriedem so things like periodic tasks can actually detach/delete volumes once the user token is gone
17:21:22 stephenfin jaypipes: Any chance you could take a look at this today? https://review.openstack.org/#/c/537363/
17:24:43 cfriesen mriedem: is there a reason not to use a service token here? (other than that they're experimental)
17:25:43 melwitt mriedem: I wondered about that too (the eventlet os.open thing). I didn't realize the timing coincided with that update
17:26:05 melwitt *the timing of the constant fails
17:31:20 Spazmotic aigoo.. that's enough computers for today
17:31:24 Spazmotic Have a good night everyone.
17:40:33 mriedem cfriesen: are you conflating the service user thing here?
17:40:39 mriedem cfriesen: different issues
17:40:56 mriedem the service user thing is for re-auth if a user token expires
17:41:16 mriedem this is different, it's just creds to be able to have nova do stuff when there is no user token
17:41:37 mriedem the service user token stuff for re-auth should probably no longer be called experimental
17:41:58 mriedem i don't know of anyone that's done performance testing with it at scale, but haven't heard anyone complain about it either, and it's optional
17:42:34 mriedem cfriesen: speaking of performance, did you ever get any updates on the perf regression you reported last week/
17:42:35 mriedem ?
17:43:23 jaypipes stephenfin: on it.
17:47:33 melwitt mriedem: this looks good, but are we supposed to not approve things yet because of zuul? https://review.openstack.org/#/c/538961
17:48:17 cfriesen mriedem: we've got some additional data, but no smoking guns. the cpu usage just seems higher overall, with the cpu usage of most services looking more spread-out and less spiky.
17:48:25 Spazmotic zuul is all better ap parently
17:48:40 Spazmotic Was restarted and caught up
17:48:59 Spazmotic Was it's zuul so all better is relative.. but yeah anyway
17:49:03 melwitt Spazmotic: ah, thanks. I see the status alert now in the backscroll
17:51:12 Spazmotic np melwitt. johnthetubaguy if you can get a cahhance to review my notes on that commit today i'd appreciate it, but don't stress over it if not. If you decide to +2 it i'll see if some of the other UK guys can take a look tomorrow to finish it off :)
17:51:15 Spazmotic Night folks, have a good rest of your day
17:58:30 cfriesen mriedem: when authenticating a token, is it possible for services to explicitly check whether a valid service token was attached? (This is related to the "glance won't allow update of ceph image location during nova snapshot" issue.)
18:01:45 mriedem cfriesen: that sounds like a question for edmondsw or lbragstad
18:02:16 cfriesen mriedem: cool, will ping them
18:02:23 edmondsw cfriesen not sure I understood the question
18:03:04 cfriesen edmondsw: there's an issue (https://bugs.launchpad.net/openstack-ansible/+bug/1639940) where with ceph-backed instances/images nova tries to make a new image and then update the location later
18:03:05 openstack Launchpad bug 1639940 in openstack-ansible "Snapshots of instances launched from images fails with Ceph as storage." [Medium,Incomplete] - Assigned to Logan V (loganv)
18:03:25 cfriesen edmondsw: this used to work with glance v1, but with v2 it fails because glance doesn't allow updating the image location
18:03:52 cfriesen edmondsw: we were wondering whether we could use service tokens to allow glance to determine that the request is coming from another openstack service rather than a "normal" user
18:04:12 edmondsw ah, I see
18:04:37 edmondsw today, service tokens are only used re: expirations
18:04:59 edmondsw i.e., if the user token has expired, it'll still allow the operation if the service token isn't expired
18:05:56 edmondsw we have talked about going beyond that, and actually checking policy/RBAC based on service token instead of user token, but that has not been implemented
18:07:34 cfriesen do the APIs exist to allow glance to extract/validate the user token separately? or is that something that would need to be added in keystone?
18:07:46 cfriesen bah, service token, not user token
18:08:14 edmondsw cfriesen looking
18:08:18 melwitt cfriesen: it still fails after setting 'show_multiple_locations = True' as mentioned in comment 7?
18:08:40 cfriesen melwitt: presumably it works, but there are big security warnings about not setting that to True
18:09:10 mriedem cfriesen: this sounds very similar to a bug we have with glance v2 and shelve where the shelved snapshot image has a different set of project_id/user_id than the admin token that tries to get the image when unshelving,
18:09:17 mriedem and i thought we could use the member stuff with glancev2
18:09:33 cfriesen melwitt: the current recommendation from the glance people was to have a whole separate glance node with a different config file just for nova to talk to it.
18:09:41 mriedem https://bugs.launchpad.net/nova/+bug/1675791
18:09:43 openstack Launchpad bug 1675791 in OpenStack Compute (nova) "Instance created by demo user(non-admin), shelved by admin and unshelved by demo user --> ends up in error state " [Medium,Triaged] - Assigned to Damini Chopra (damini)
18:09:44 melwitt cfriesen: yeah. from what I understand, the fast clone has the caveat of the security issues
18:11:12 melwitt that is, you have to be in an environment where exposure of the image location urls isn't a problematic in order to use COW clone
18:11:23 mriedem err in the case of shelve, the elevated admin context creates the snapshot, and when the user goes to unshelve the instance, it fails b/c the non-admin user doesn't have access to the image created for them
18:12:55 openstackgerrit Matt Riedemann proposed openstack/nova master: Check for leaked server resource allocations in post_test_hook https://review.openstack.org/538510
18:12:56 mriedem gibi: cdent: ^ hark back to an old conversation about testing for allocation cleanups
18:15:33 mriedem dansmith: ^ we talked about that in denver i think
18:18:07 dansmith I believe you
18:18:54 edmondsw cfriesen looks like the context object should have info about the service_token if one was used
18:19:41 edmondsw though I think you're probably treading on thin ice trying to use those in a way that they were not really intended to be used
18:19:54 edmondsw better run what you are thinking by lbragstad
18:27:47 efried edleafe Be careful what you ask for. See -dev ML.
18:31:54 lbragstad cfriesen: edmondsw summed it up pretty well, the service token work is kind of a long road.. it sounds like you want to use service tokens to validation/determine more than just a "yes, this token is valid" or "no, it isn't"?
18:35:34 edleafe efried: thanks for that. So if I'm understanding things correctly, the "res.pool" is the root RP that placement would return
18:35:59 efried edleafe: Depends which model we're going with.
18:36:47 efried edleafe: That would be model (C)
18:39:15 edleafe efried: (C) makes the most sense to me, based on my limited familiarity
18:39:41 efried edleafe: But it suffers from at least two drawbacks.
18:39:43 edleafe efried: we don't want to fall into the trap of making everything fit the Nova model
18:40:32 efried edleafe: What do you mean? This *is* nova.
18:40:47 efried edleafe: You mean the libvirt model?
18:41:35 edleafe efried: yeah, like we tried to do with ironic
18:42:40 edleafe efried: from a placement POV, all we care about are the things that the consumer wants us to track. For generic libvirt nova, that would be compute nodes. For vmware nova, it would be resource pools
18:44:11 efried Dig. So we should look toward closing those gaps. In general, we should be working to make nova + placement + <virt> work smoothly, for all values of <virt>.

Earlier   Later