Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-16
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] Enable PUT dict to /allocations/{consumer_uuid} https://review.openstack.org/510625
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:40 openstackgerrit Chris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
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: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
14:53:25 mriedem ildikov: i don't see the problem with splitting them out,
14:53:31 mriedem yo'uve managed things with depends-on up to this point anwyay
14:53:34 mriedem how is this any different?
14:53:56 mriedem ideally i like changes in a series, but as you said that gets hard with multiple owners in that series
14:54:52 ildikov just adds to the timeline which seems somewhat unnecessary
14:55:20 ildikov and still extra work and coordination
14:56:19 ildikov but as I usually don't win in these debates, I will look into splitting that out :)
14:58:21 dansmith efried: I don't think it needs a spec
15:01:32 sahid dansmith: don't you think that could be interesting for the contributors/reviewers to understand the design here?
15:02:03 sahid perhaps a related specs
15:02:22 dansmith sahid: of passing request information into the virt driver? like a port or network? No, I think it's pretty clear
15:03:12 sahid yes that si clear, but it's not the only method to update, and what is the aim, are you going to update all the drivers methods to add that new param
15:03:15 sahid ?
15:03:20 efried In this case I agree the intent can be expressed adequately in the commit message.
15:03:39 efried We're not impacting APIs or objects or configs or anything.
15:03:49 sahid well you are impacting the drivers
15:04:01 dansmith sahid: he's already updating all the drivers' method signatures
15:04:03 efried Yup. And updating them accordingly in the scope of the change.
15:04:22 efried With a nice docstring on the new param.
15:04:34 sahid ok fair, just asking... that change is happening like that without explaining, i was expected some
15:05:13 efried Definitely a reasonable point sahid, thanks for bringing it up.
15:06:36 sahid efried: if you can update the commit message that would be nice so we are all on the same page
15:06:45 efried sahid Will do.
15:08:56 mriedem ildikov: so to recap what i think the changes are, please correct me if i'm wrong: 1. split out the refresh_connection_info change to the bottom of the series. for old style attachments we still call os-initialize_connection, for new style we call attachment_get. 2. you or stvnoyes updates the live migration patch on top of that and do an explicit attachment_update call since refresh_connection_info won't do that for you anym
15:08:57 mriedem 3. the new attach api flow goes on top of those other 2 (maybe not changes needed except splitting that code out)
15:09:36 mriedem ildikov: stvnoyes: once those bottom 2 are done i think they are easy to get merged this week
15:09:40 openstackgerrit Merged openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540
15:09:46 mriedem as i think that's the only hold up on the live migration patch at this point
15:11:49 efried ice_auth.py#L31
15:11:49 efried mriedem sdague This may have happened before you came on, but niraj_singh was testing out the service_user token thing and got a really cryptic exception. Turns out the issue was not having specified auth creds in the conf. I thought we could do a better job by blowing up here if _SERVICE_AUTH comes back None (which is what happens if you don't specify an auth_type): https://github.com/openstack/nova/blob/master/nova/serv
15:12:00 efried Nice. https://github.com/openstack/nova/blob/master/nova/service_auth.py#L31
15:12:30 sdague efried: yeh, that would be cool
15:13:32 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix nova-manage commands that do not exist https://review.openstack.org/512324
15:14:12 efried niraj_singh You open that bug yet? I don't see it.
15:15:04 ildikov mriedem: sorry, on a call
15:15:53 ildikov mriedem: your summary looks good to me
15:23:55 mriedem bauzas: you might find this ML thread about an interesting bug to be very interesting, interestingly enouh http://lists.openstack.org/pipermail/openstack-operators/2017-October/014393.html
15:25:01 dansmith hmm, I'm not seeing things I submitted a few minutes ago in the zuul queue
15:27:48 openstackgerrit Eric Fried proposed openstack/nova master: Service user token requested with no auth https://review.openstack.org/512329
15:27:55 efried sdague ^
15:30:08 openstackgerrit garyk proposed openstack/nova master: Add debug information to metadata requests https://review.openstack.org/511895

Earlier   Later