| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 16:37:21 | edleafe | cdent: ok, thanks. I assumed that there must be some internal documentation that would be helpful | |
| 16:38:12 | cdent | edleafe: could very well be, but if there are pretty pictures I haven't seen them. That doesn't mean it doesn't exist. I interact _very_ little on that side of things. | |
| 16:38:55 | Spazmotic | Anyone know any of the cores familiar with XenAPI drivers? Besides Garbutt that is, I got his attention on but was curious if any others were familiar that I could poke :D | |
| 16:39:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add 'types' module https://review.openstack.org/538225 | |
| 16:39:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.openstack.org/538224 | |
| 16:39:17 | edleafe | cdent: ok, cool. If you come across something, post it so we can all better understand what is needed | |
| 16:41:07 | efried | Spazmotic Maybe bauzas ? | |
| 16:41:36 | artom | Wasn't Bob Ball xenapi? Is he still around? | |
| 16:41:37 | Spazmotic | I know the driver isn't looked at too frequently by folks, so just didn't want to bark up the wrong trees wwhen I had questions or was looking for some eyeballs. | |
| 16:41:42 | Spazmotic | Yeah bob's still around but he's no longer core | |
| 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 | |