Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-26
19:38:06 jaypipes melwitt: yeah, I hear ya. definitely not bemoaning your code. it's just a pit of vipers in general.
19:38:35 melwitt I know. not taken that way :)
19:38:44 jaypipes k, cool :)
19:43:00 mriedem jaypipes: ok, replied in https://review.openstack.org/#/c/460281/ as well,
19:43:05 melwitt mriedem: been meaning to tell you about this, I found a bug in the BackOffLoopingCall that was causing that ironic test to timeout intermittently (160s test timeout whereas the backoff timeout should have expired well before that) https://review.openstack.org/#/c/459790/
19:43:22 mriedem jaypipes: also mentioned at a higher level that i don't know that the plan as you describe it in there is actually written down anywhere
19:44:25 mriedem melwitt: heh, nice, i guess that really bugged you
19:45:31 jaypipes mriedem: I got dinged for being too verbose in specs, then dinged for not having everything written down ahead of time...
19:45:38 jaypipes can't win for losin.
19:46:02 melwitt mriedem: yup, I became obsessed with it
19:46:17 mriedem jaypipes: i know
19:46:32 jaypipes mriedem: I'll try to write something up tomorrow.
19:46:46 mriedem jaypipes: i'm +2 on the change after you explained the plan, i just wouldn't have known otherwise
19:46:54 jaypipes understood.
19:52:37 mordred jaypipes: write down more things, but then delete hide them
19:52:47 jaypipes heh
19:59:54 mriedem jaypipes: dansmith: anything off the top of your head that we already know is going to be a focus for queens? besides just anything that doesn't make pike? things that come to mind are volume multiattach, cinder ephemeral / no local disk
19:59:58 mriedem removing caching scheduler isn't really a feature
20:00:08 mriedem but claims in scheduler would be required in queens
20:00:22 jaypipes mriedem: VGPU.
20:00:34 dansmith mriedem: full shared storage, shared network reporting and stuff
20:00:41 dansmith mriedem: hopefully some locality/affinity in placement
20:00:41 jaypipes mriedem: port pair allocations with SR-IOV.
20:00:50 openstackgerrit Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/460293
20:00:50 openstackgerrit Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/455118
20:00:54 dansmith yeah, GPU and SRIOV love in placement
20:00:57 jaypipes dansmith: yeah. ++ on affinity stuff.
20:01:06 jaypipes heh, much love.
20:04:24 cburgess dansmith mriedem Thinking fill shared storage and cinder ephemeral both probably depend on a re-write of the imagebackend interface and creating cleaner seperation and modularization of that area of the code.
20:05:44 dansmith that's at least a cycle of work probably
20:05:47 dansmith unless it's all we do
20:07:13 cburgess dansmith Probably right. Just trying to figure out how we could do shared storage or a cinder backend properly without fixing that dumpster fire induced miasma.
20:07:35 dansmith TIL a new word
20:07:57 cburgess lol
20:08:03 cburgess miasma?
20:08:37 dansmith no "shared"
20:08:39 dansmith yes miasma :P
20:09:00 cburgess I try and educate as well as provide bad ideas, and donuts, to the nova community.
20:09:13 dansmith and we thank you for it
20:09:13 cburgess Its just one of my many redeeming qualities.
20:10:42 sean-k-mooney jaypipes: do you think the user controlled port pair allocations will slip to queens?
20:11:10 jaypipes sean-k-mooney: considering it didn't land for Pike... yes.
20:11:13 sean-k-mooney jaypipes: i have been getting some question lately about doing bonding with sriov for ha and performacne which would need that
20:11:30 sean-k-mooney oh ya we are past spec deadline
20:15:35 openstackgerrit Rafael Folco proposed openstack/nova master: placement: Specific error for inventory in use https://review.openstack.org/460231
20:29:41 mriedem jaypipes: i don't know what "port pair allocations with SR-IOV" means
20:30:44 mriedem dansmith: isn't gpu/sriov love in placement == nested resource providers == pike?
20:31:13 dansmith mriedem: there's virt driver work that needs to be done that I don't think is going to happen in pike
20:31:14 dansmith certainly for gpu
20:33:06 mriedem anything forward looking for cells v2 in queens?
20:33:19 mriedem besides fix all the bugs we introduce in pike? :)
20:33:30 jaypipes mriedem: https://review.openstack.org/#/c/182242/
20:33:34 mriedem oh i suppose integration of limits in keystone
20:33:44 jaypipes ++
20:33:57 mriedem jaypipes: oh right, that spec...
20:34:04 dansmith mriedem: well, yeah, all the bugs, but also presumably we'll have plenty of performance things to work out
20:34:30 mriedem jaypipes: that's the one where the "user" is a single tenant NFV machine right?
20:35:49 mriedem ok here is the list: "VGPU support, full shared storage/network reporting and affinity support in the placement service, volume multi-attach, Cinder as ephemeral backend, integration of limits in Keystone, Cells v2 hardening."
20:35:57 mriedem "+ delete shelve"
20:36:00 mriedem :)
20:36:11 dansmith you have my vote
20:36:29 dansmith HTTP 420: Sorry I dunno where I left that shelve feature.. please try again... uh, never.
20:36:45 mriedem stoner apis
20:36:46 mriedem psh
20:36:52 dansmith heh
20:37:47 jaypipes mriedem: yes.
20:40:05 mriedem (optional) Do you have questions for users that can help inform/guide your development teams?
20:40:10 mriedem oh boy
20:40:21 mriedem i can't remember what i asked about this for pike
20:41:05 mriedem "do you use any microversion > 2.1?"
20:41:09 openstackgerrit Abhishek Sharma M proposed openstack/nova master: Catching OverQuota Exception https://review.openstack.org/460305
20:41:09 mriedem that could be a legit question
20:41:13 dansmith hah
20:41:52 mriedem b/c we're always coding 18 months ahead at least
20:41:54 mriedem and have no idea
20:51:57 mriedem "While the majority of users aren’t currently using Nova cells, about 146 deployments reported using cells, which is substantially more than the 67 users reporting using Nova cells one year ago. "
20:53:36 abhi89 johnthetubaguy: Hi
20:55:07 abhi89 Hi all.. can someone please review https://review.openstack.org/#/c/460305/
20:55:19 mordred mriedem: I fully expect to start consuming microversions in the next 6 months
20:55:57 mriedem oh right this was the question
20:55:58 mriedem "How important is it to be able to customize Nova in your deployment? e.g. classload your own managers/drivers, use hooks, plug in API extensions, etc."
20:56:18 mordred I was very happy to see the low numbers of "we use this extensively"
20:56:23 mriedem 51% not important, 39% somewhat, 10% very
20:56:41 mordred s/low/lowish/
20:57:10 jaypipes dansmith: you're gonna love all this shared resource provider SQL...
20:57:49 mriedem i see that neutron asked about actual feature usage/adoption
20:58:08 mriedem that's something we could breakdown at some point, and have wondered about, i.e. does anyone actually use shelve?
20:58:19 mordred edleafe: I'll try to start with an amuse bouche, but that's probably not too far off
20:58:49 mordred mriedem: I don't
20:59:55 mriedem page 60 https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
21:00:21 mriedem breaking something down like that in nova wouldn't be trivial
21:00:33 mordred no - but it would be worthwhile
21:02:11 dansmith more than twice as many people patch in an unmaintained docker driver than use the in-tree xen support
21:02:21 dansmith I'll remember that next time I have to fix something in there
21:02:52 cfriesen I'm curious...are we expecting that eventually nova-api won't need a connection to the main nova db?
21:03:19 mordred dansmith: that also highlights one of the big disconnects between what users want and what developers are funded to work on/maintain
21:03:35 dansmith mordred: well, might've been a disconnect a couple weeks ago, but yeah
21:05:51 openstackgerrit Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to local_cleanup https://review.openstack.org/456851
21:07:03 mriedem dansmith: heh, and lxc more than both of those
21:07:13 dansmith yeah

Earlier   Later