| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-16 | |||
| 11:58:47 | openstackgerrit | Merged openstack/nova master: TrivialFix: Fix the incorrect test case https://review.openstack.org/509758 | |
| 12:24:14 | priya_ | hi , Could somebody review the commit - https://review.openstack.org/#/c/508533/ | |
| 12:25:54 | openstackgerrit | Merged openstack/nova master: Remove system_metadata loading in Instance._load_flavor https://review.openstack.org/508357 | |
| 12:25:59 | openstackgerrit | Merged openstack/nova master: Don't use mock.patch.stopall https://review.openstack.org/507527 | |
| 12:26:40 | openstackgerrit | Merged openstack/nova master: nova-manage map_instances is not using the cells info from the API database https://review.openstack.org/510844 | |
| 12:26:46 | openstackgerrit | Merged openstack/nova master: Filter out stale migrations in resource audit https://review.openstack.org/339715 | |
| 12:26:54 | openstackgerrit | Merged openstack/nova master: Refactor init_instance:resume_guests_state https://review.openstack.org/349582 | |
| 12:27:29 | efried | stephenfin FYI, I'm spinning up another rev of that spec, in case you wanted to, I don't know, make fun of my hair or something. | |
| 12:30:07 | alex_xu | efried: hi, i'm here | |
| 12:30:30 | efried | alex_xu Hi, I was going to ask you something about aggregates wrt the granular RP syntax spec... | |
| 12:30:50 | alex_xu | efried: yea | |
| 12:31:48 | efried | alex_xu It was about dansmith's comment here: https://review.openstack.org/#/c/510244/4/specs/queens/approved/granular-resource-requests.rst@45 | |
| 12:32:50 | efried | IIUC, the way you're implementing it, if I ask for a particular trait, you'll succeed even if the trait isn't on the compute node? | |
| 12:33:04 | efried | alex_xu ...as long as it's on an aggregate? | |
| 12:33:57 | alex_xu | yes, but the compute node and shared storage pool in the same aggregate | |
| 12:34:29 | efried | alex_xu This actually brings up an interesting set of test cases to cover. If I ask for storage-related traits X and Y; and my compute node has storage with trait X but not Y; and my shared storage has trait Y but not X - what happens? | |
| 12:35:01 | efried | I should *not* get that host/storage as a candidate. | |
| 12:35:30 | alex_xu | efried: first, we don't have the case the comput enode have local storage and shared storage at same time | |
| 12:35:32 | efried | But I suspect with the logic you're currently implementing, it might erroneously return that host. | |
| 12:35:44 | efried | alex_xu What do you mean? | |
| 12:36:02 | efried | You mean nobody has done it yet? Or we don't support it at all? | |
| 12:36:04 | alex_xu | efried: yea, that's true, my implementation doesn't work for that | |
| 12:36:16 | alex_xu | efried: we don't support it at all | |
| 12:36:28 | efried | Okay. | |
| 12:36:55 | efried | I mean, I get the impression that we're not trying to get shared RPs "working" in Queens, but I don't really know what that means in terms of what code we're actually going to merge around aggregates and such. | |
| 12:37:30 | efried | Because ultimately it's not just about shared storage. There could be other kinds of shared RPs, and we would probably want that scenario to work properly. | |
| 12:37:45 | alex_xu | efried: yea, but the current implementation of 'GET /allocation_candidates' support a buggy version shared RPs... | |
| 12:37:55 | efried | right, I saw that too :( | |
| 12:38:35 | alex_xu | efried: yea, I'm also think about, but I'm still trying to find a similar case in the real world for that | |
| 12:38:58 | alex_xu | efried: thanks for point that out, I will keep that in mind | |
| 12:39:05 | efried | Sure thing. | |
| 12:39:14 | efried | alex_xu Thanks for the review, as well. I'm addressing your comments now. | |
| 12:39:22 | alex_xu | efried: np | |
| 12:43:14 | alex_xu | efried: for the case you pointed out, I think the code should generate two candidates, 1. node and local storage, 2. node and shared strorage. The current implementation without traits doesn't work for this case also. | |
| 12:44:43 | alex_xu | I guess Jay may say we can't have duplicated resource class in the same aggregate | |
| 12:45:26 | efried | alex_xu I would be very surprised if he said that | |
| 12:45:56 | efried | mm, maybe not. | |
| 12:46:01 | efried | I need to noodle that through. | |
| 12:46:38 | efried | But for the case I pointed out, I would expect *no* candidates. Because neither the local nor the shared storage has *both* X and Y. | |
| 12:47:11 | efried | Unless you're saying that the code as currently written would generate two candidates. I agree. And I think that's not correct. | |
| 12:48:38 | alex_xu | efried: I mean the currently written with the same request but without required traits, there should be two candidates | |
| 12:48:56 | efried | Oh, yeah, without traits involved, sure. | |
| 13:12:29 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 13:13:13 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] manage cache headers for /resource_providers https://review.openstack.org/495380 | |
| 13:13:14 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] manage cache headers for inventories https://review.openstack.org/510954 | |
| 13:18:51 | niraj_singh | i set send_service_user_token= true in nova.conf and tried to boot instance using image. I am getting error ERROR nova.api.openstack.extensions [None req-ff664a2e-3fdb-4cb9-bd02-78c662fdc0c2 admin admin] Unexpected exception in API method: AttributeError: 'NoneType' object has no attribute 'get_token'. is there any clue. | |
| 13:21:41 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Granular Resource Request Syntax https://review.openstack.org/510244 | |
| 13:21:50 | efried | dansmith stephenfin alex_xu ^ | |
| 13:25:42 | efried | niraj_singh Do you have a full stack trace? Can you paste.openstack.org it? | |
| 13:26:09 | niraj_singh | efried: yes | |
| 13:28:13 | efried | To me this sounds like your context doesn't have a good auth in it. | |
| 13:28:37 | niraj_singh | efried: http://paste.openstack.org/show/623721/ | |
| 13:29:55 | efried | niraj_singh What version are we at? | |
| 13:30:38 | niraj_singh | 2 | |
| 13:31:53 | niraj_singh | efried: 2 | |
| 13:32:07 | efried | niraj_singh 2? | |
| 13:32:37 | efried | I mean like, ocata, pike, some devel branch... | |
| 13:32:59 | niraj_singh | efried: ohh sorry... i am new to openstack. | |
| 13:35:22 | efried | niraj_singh Okay, I think I see what's going on. Can you paste.o.o me your nova conf so I can confirm? | |
| 13:36:15 | niraj_singh | yes | |
| 13:36:30 | efried | niraj_singh In short: Do you have a [service_user] section set up with appropriate auth options? | |
| 13:38:57 | niraj_singh | efried:http://paste.openstack.org/show/623723/ | |
| 13:40:21 | efried | niraj_singh Okay, cool. So what you need to do is populate that [service_user] section with auth options. | |
| 13:41:03 | efried | niraj_singh It would wind up looking something like what you've got in the [placement] and [neutron] sections above there, with an auth_type etc. | |
| 13:41:26 | niraj_singh | efried:ok | |
| 13:42:26 | efried | niraj_singh I think we could do better with our error message, though it wouldn't be easy to make it appear in the actual spot of the error. | |
| 13:43:14 | efried | niraj_singh We actually may want to make the compute process blow up if you said "send_service_user_token" but didn't supply appropriate auth opts. | |
| 13:43:36 | efried | niraj_singh Can you please open a bug at http://bugs.launchpad.net/nova/ for this? | |
| 13:43:46 | niraj_singh | efried: yes sure. | |
| 13:44:43 | efried | niraj_singh Thanks. Hit me with the link once you've got it open. | |
| 13:45:24 | niraj_singh | efried: yes thank you for help | |
| 13:45:25 | edleafe | Scheduler subteam meeting in 15 minutes in #openstack-meeting-alt | |
| 13:49:15 | dtantsur | folks, do you have an early specs freeze this cycle? nothing on the official schedule, but johnthetubaguy says that you do :) | |
| 13:49:19 | dtantsur | mriedem1: ^^^ | |
| 13:49:49 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 13:49:49 | mriedem1 | yeah, this thursday | |
| 13:49:50 | mriedem1 | 10/19 | |
| 13:49:57 | mriedem | dtantsur: ^ | |
| 13:50:30 | mriedem | dtantsur: not really early - we've done spec freeze on the first milestone the last 2 releases too | |
| 13:51:02 | dtantsur | mriedem: ugh. I'd appreciate making it visible for outsider folks, like glance and manila did | |
| 13:51:08 | dtantsur | (i.e. https://releases.openstack.org/queens/schedule.html ) | |
| 13:51:10 | mriedem | i can update the main schedule | |
| 13:51:53 | dtantsur | next time, I guess :) now it's too late | |
| 13:52:17 | mriedem | is there something specific i can help you with regarding a nova spec? | |
| 13:52:24 | mriedem | i'm assuming you're talking about john's ironic traits one? | |
| 13:52:29 | dtantsur | mriedem: yep, that one | |
| 13:52:41 | mriedem | the nova spec is already approved, it's just dependent on changes in ironic | |
| 13:52:44 | dtantsur | I don't think we're ready to finish the ironic part this week | |
| 13:52:53 | dtantsur | maybe we could, but that's not something I'd rush in | |
| 13:52:54 | mriedem | that's fine, i told john to remove the depends-on for the spec, | |
| 13:53:02 | mriedem | we can track the dependency via launchpad | |
| 13:53:32 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Support traits in the Ironic driver https://review.openstack.org/507052 | |
| 13:53:53 | dtantsur | mriedem: cool, so it was solved without me in the end :) thanks! | |
| 13:53:55 | mriedem | dtantsur: ^ done | |
| 13:54:00 | dtantsur | :) | |
| 13:55:46 | openstackgerrit | Lajos Katona proposed openstack/nova master: Extend ServerMovingTests with custom resources https://review.openstack.org/497399 | |
| 14:01:33 | sahid | mriedem: when you have a moment i'm wondering if we can consider this for Queen http://lists.openstack.org/pipermail/openstack-dev/2017-October/123432.html ? | |
| 14:01:54 | sahid | no worries it's not vGPUs or mdev things :) | |
| 14:05:29 | johnthetubaguy | dtantsur: mriedem: thanks folks | |
| 14:06:24 | mriedem | sahid: just more config options for already complicated setup | |