| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-16 | |||
| 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 | mriedem1 | yeah, this thursday | |
| 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: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 | |
| 14:06:31 | mriedem | sahid: i don't have an opinion right now | |
| 14:06:44 | mriedem | might be good to involve blair bethwaight (spelling?) and the HPC people | |
| 14:08:01 | mriedem | bethwaite | |
| 14:08:17 | sahid | mriedem: yes this kind of setups are complicated, i don't think there is an ideal solution to avoid that | |
| 14:11:00 | sahid | mriedem: siemens where also interested by this options for the realtime use cases | |
| 14:11:17 | sahid | there is a thread on the ML | |
| 14:11:26 | sean-k-mooney | sahid: mriedem it does not sean that unresonable to me | |
| 14:11:37 | sean-k-mooney | but yes this are is already complcated | |
| 14:11:59 | sean-k-mooney | sahid: yes realtime makes sense for this feature | |
| 14:12:00 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API extensions policy removal https://review.openstack.org/508101 | |
| 14:12:23 | openstackgerrit | Merged openstack/nova-specs master: Support traits in the Ironic driver https://review.openstack.org/507052 | |
| 14:13:44 | gmann | mriedem: separated the api extensions and policy removal BP. this is specless BP for api extensions work for queens - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-queens | |
| 14:13:49 | sahid | sean-k-mooney: yes there also some dpdk usages, they want to isolate the emulthreads to have the full capacity of the pCPUs pinned for the guests | |
| 14:13:54 | sean-k-mooney | by the way on config option i never got around to bringin up at the ptg was the host reserved memory. i mentioned it to a few people but we should really have a numa aware version of that | |
| 14:15:10 | gmann | ll update the policy removal spec tomorrow | |
| 14:15:14 | gibi | mriedem: hi! I fixed your comments in https://review.openstack.org/#/c/510938/ | |
| 14:15:16 | sean-k-mooney | sahid: sure that makes sense for any io sensive application ( not just dpdk) if you have pinned cores you do not want the emulator thread to context switch out your application | |
| 14:15:44 | sahid | sean-k-mooney: yes | |
| 14:16:54 | sean-k-mooney | and since the emulator thread are largly ideal you do not want to spend the cost of allocatng extra cores to hanedl them per vm and would instead want a pool of cpus to use for them instead | |