| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-16 | |||
| 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 | |
| 14:18:14 | sean-k-mooney | htop | |
| 14:19:27 | sean-k-mooney | mriedem: if you get a chance can you take a look at https://review.openstack.org/#/c/375580/ later | |
| 14:20:37 | sean-k-mooney | any other cores with opions on how to adress the use of multiple port binding for live migrate are also welcome to review :) | |
| 14:21:14 | sean-k-mooney | or non cores but would like to get some nova feedback before sepc freeze | |
| 14:25:37 | openstackgerrit | Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410 | |
| 14:25:38 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Allow _set_allocations to delete allocations https://review.openstack.org/501051 | |
| 14:25:39 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Limit number of attempts to delete allocations https://review.openstack.org/507224 | |
| 14:25:39 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable PUT dict to /allocations/{consumer_uuid} https://review.openstack.org/510625 | |
| 14:25:40 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Document the changes to PUT /allocations/{consumer_uuid} https://review.openstack.org/510626 | |
| 14:25:40 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073 | |
| 14:34:23 | mriedem | sean-k-mooney: johnthetubaguy is the other person that should review those updates, since he started that spec :) | |
| 14:35:32 | johnthetubaguy | mriedem: sean-k-mooney: I will try get to that today | |
| 14:36:16 | sean-k-mooney | mriedem: johnthetubaguy that will make mlavalle happy to here | |
| 14:41:21 | openstackgerrit | Matthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/511466 | |
| 14:41:23 | dansmith | bauzas: you've seen this right? https://review.openstack.org/#/c/511879/3 | |
| 14:41:31 | ildikov | mriedem: johnthetubaguy: hi. would that be possible to merge the live_migrate patch and fix that one issue with refresh_conn_info in the new attach patch? | |
| 14:41:49 | dansmith | bauzas: once it's in, I think it probably makes sense to look at that data structure for "do I have an allocation for a vgpu" | |
| 14:43:18 | mriedem | ildikov: not really.... | |
| 14:43:23 | mriedem | they are separate issues | |
| 14:43:26 | mdbooth | dansmith: I had an epiphany wrt local serial numbers in ironic, btw: we don't need to prescribe the method of assigning serial numbers as long as the interface to them is consistent. Ironic is already consistent, because it uses physical disks which don't have the problem we're trying to solve. | |
| 14:43:55 | mriedem | ildikov: it might be best to actually split the refresh_connection_info handling out before the live migration change | |
| 14:44:07 | mriedem | so it goes refresh_conn_info -> live migratoin new style attachments -> enable new style attachments in api | |
| 14:44:14 | mdbooth | I updated the spec to define a driver contract for stable serial numbers, and a specific implementation for libvirt which is as previously discussed. | |
| 14:44:15 | dansmith | mdbooth: it does if you expose the serial number out of the metadata api, and ironic is one of those places where tagging devices is pretty important | |
| 14:44:26 | mdbooth | Right, I covered that. | |
| 14:44:32 | dansmith | okay | |
| 14:44:47 | mdbooth | The device metadata is always created by the driver anyway, because it's the only place which has that info. | |
| 14:45:00 | mdbooth | So the ironic driver would expose the actual serial numbers it's using. | |
| 14:45:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 14:45:20 | ildikov | mriedem: hmm, for that I will need to make a chain of these patches and I would really love to avoid that | |
| 14:45:41 | mriedem | ildikov: i actually wish they were in a chain | |
| 14:45:44 | mriedem | rather than depends-on | |
| 14:46:07 | mriedem | but you don't need a topic branch if you don't want, | |
| 14:46:16 | mriedem | you can do refresh_connection_info for new style attachments in a separate patch, | |
| 14:46:25 | ildikov | mriedem: working together with someone on a chain is highly painful | |
| 14:46:28 | mriedem | have the live migration patch depends-on that, and have the final api patch depends on the live migration patch, which it already does | |
| 14:47:18 | ildikov | but if we do that changes in the refresh_conn_info I don't know how those will be picked up with only a depends-on | |
| 14:47:33 | mdbooth | Incidentally, I'm also looking for re-approval of lyarwood 's previously approved stable rescue spec: https://review.openstack.org/#/c/510106/ | |
| 14:51:56 | ildikov | mriedem: I get your point, I still think it would really be easier and quicker to merge the live_migrate patch; it works and functional and what we need to do is a refactor only | |