Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-18
20:18:12 dansmith I mean I dunno what fast rendering would be
20:18:21 dansmith it all seems pretty slow to me :)
20:19:19 mriedem they should rename the setting to "stop fucking up my gd cursor placement fucker"
20:19:20 mriedem i agree
20:20:24 mriedem efried: thanks for helping to review this https://review.openstack.org/#/c/502306/
20:20:27 mriedem it's definitely hairy
20:20:45 efried mriedem phew, thought I was just being dense.
20:21:19 smcginnis mriedem: +1 to that name, it would be much more accurate.
20:21:23 mriedem no man, it's building on like all of the worst things
20:21:43 mriedem port orchestration, nested resource providers, scheduling, neutron agent stuff, etc etc
20:29:02 mriedem sean-k-mooney: in https://review.openstack.org/#/c/502306/ - so when nova binds a port to a selected host, neutron will put some kind of allocation information in the port binding profile, and nova will proxy that allocation information to placement?
20:29:14 mriedem and the suggested flow is:
20:29:22 mriedem 1. conductor asks scheduler for a host
20:29:51 mriedem 2. scheduler filter looks for ports with a qos policy and if found, gets allocatoin candidates for hosts that have a nested bw provider
20:29:59 mriedem 3. scheduler returns host to conductor
20:30:05 mriedem 4. conductor binds the port to the host
20:30:24 mriedem 5. the bound port profile has some allocation juju that nova proxies to placement as an allocation request for the port on the bw provider
20:30:34 mriedem 6. conductor sends to compute to build the instance
20:30:42 mriedem 7. compute activates the bound port
20:30:48 mriedem 8. compute plugs vifs
20:30:53 mriedem 9. profit?!
20:31:43 mriedem why can't the allocation juju happen on the neutron side when the port is bound
20:31:44 mriedem ?
20:33:33 mriedem i seem to remember some discussion at the ptg about it being cool that nova will proxy the allocation creation for neutron, but i'm not sure why
20:33:39 mriedem mlavalle: ^ do you remember?
20:34:16 mriedem ultimately we don't want nova managing resource allocations for network things
20:34:31 mriedem especially out of band things like qos policies in neutron
20:36:19 efried mriedem This may be slightly off topic, but who will be the consumer of the allocations related to the port? The port itself, or the instance?
20:38:56 mriedem i think the port
20:40:22 mriedem it's a bit confusing in the spec
20:40:23 mriedem "A virtual machine port can consume bandwidth from one of these Resources
20:40:24 mriedem Providers."
20:40:35 mriedem and
20:40:38 mriedem "By the time the port is bound, the bandwidth allocated to the instance is already recorded."
20:40:41 sdague mriedem: I looked at the stable stuff, should be good. You still need somone else on the top patch
20:40:59 mriedem sdague: yeah, thanks - i can find someone
20:41:03 mriedem someone named dan
20:41:43 dansmith link m
20:41:44 dansmith e
20:42:27 mriedem can't find it
20:42:37 dansmith offer expires in 3....2...
20:43:05 mriedem dansmith: https://review.openstack.org/#/c/512716/
20:48:42 efried mriedem The port is actually the only thing that makes sense.
20:49:45 efried Otherwise we would either have to a) allocate the network resources and the other instance resources at the same time, i.e. from the scheduler; or b) overwrite the allocation from the scheduler so it goes from [just the port] to [port plus other instance resources]
20:50:03 efried Either one of those things would be pretty weird.
20:50:44 efried mm, maybe a) wouldn't be so weird.
20:52:53 mriedem the spec is proposing that we do (a)
20:53:05 mriedem it's saying the neutron agent populates the bw provider inventory,
20:53:19 mriedem and when nova binds a port to a host, neutron will return information about the allocation in the binding profile,
20:53:29 mriedem and nova will create the allocation in placement for the port on the bw resource class on behalf of neutron
20:53:33 mriedem that's what i don't agree with
20:53:46 mriedem we don't want nova-compute managing port bw allocations
20:54:15 mriedem which also means nova would then be responsible for removing allocatoins when migrating the instance to another host
20:54:30 mriedem i'm suggesting that neutron manage the allocatoins when the port is bound or unbound, which is triggered by nova
20:54:54 mriedem if the allocation on the neutron side fails, the port binding fails and we have to reschedule with another host providing bw resources
20:55:13 mriedem if we do the port binding in the conductor, then that reschedule isn't as expensive as doing it in the compute
20:55:38 mriedem but that also means this depends on picking up johnthetubaguy's network-aware scheduling stuff to move port creation etc to conductor
20:56:23 mriedem so let's recap - deps are nested RPs, port binding API integration in nova, prep for nw aware scheduling, plus some API changes in neutron
20:56:33 mriedem == me telling mlavalle it's probably DOA for queens
21:01:53 melwitt are we having a cells meeting today or no?
21:02:20 mriedem umm
21:02:24 mriedem i forgot
21:02:34 mriedem don't think we have much to talk about do we?
21:02:38 mriedem need reviews on alternate hosts
21:02:51 mriedem and dan has one more thing for the efficient instance listing weirdness with cell0
21:02:51 melwitt I don't, but just wanted to ask in case I missed something
21:03:12 mriedem i think i tipped dan over with one too many stable reviews
21:03:18 melwitt heh
21:03:47 tssurya_ so that means no meeting right ?
21:04:50 melwitt tssurya_: yeah, I guess so. did you have anything you wanted to talk about or bring to attention?
21:05:12 tssurya_ melwitt : nothing in particular
21:05:30 melwitt k, me either
21:05:46 tssurya_ melwitt : just wanted to discuss about this : https://bugs.launchpad.net/nova/+bug/1724621 which we can do in the channel I guess
21:05:47 openstack Launchpad bug 1724621 in OpenStack Compute (nova) "nova-manage cell_v2 verify_instance returns a valid instance mapping even after the instance is deleted" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
21:06:21 dansmith whoa
21:06:35 dansmith sorry I apparently hit dismiss earlier on my cells reminder
21:06:37 dansmith and then got distracted
21:06:43 dansmith mriedem: tssurya_ melwitt sorry about that
21:06:48 tssurya_ melwitt : saw your comment,
21:07:06 tssurya_ dansmith : no problem :)
21:07:29 dansmith I literally did my errands earlier so I'd be around for it,
21:07:35 dansmith and then one click spoiled it all :)
21:07:44 dansmith tssurya_: did your patch merge?
21:07:55 tssurya_ dansmith : yes it did :D
21:07:59 dansmith sweet
21:08:28 efried mriedem Okay, you may want to call out https://review.openstack.org/#/c/502306/13/specs/queens/approved/bandwidth-resource-provider.rst@304 specifically then. It says the conductor is handling the resource classes and allocations.
21:08:29 dansmith tssurya_: so regarding the bug above, melwitt is right, we can't remove those instance mappings until the instance is removed from the cell db
21:08:42 dansmith tssurya_: however, there's a work item that needs to be done if you're looking for another thing to work on
21:09:00 mriedem efried: i did elsewhere above
21:09:02 dansmith tssurya_: (related to this I mean)
21:09:03 efried Oh, dansmith is in stable easy +A mode? https://review.openstack.org/#/c/510957/ you're welcome
21:09:15 mriedem heh
21:09:21 tssurya_ dansmith : sure but is there a way to remove the instances ?
21:09:30 dansmith efried: haven't I approved enough stuff for you lately?
21:09:33 mriedem tssurya_: yeah, nova-manage db archive_deleted_rows
21:09:36 dansmith tssurya_: yes, that's the work item :)
21:09:38 dansmith mriedem: DUDE
21:09:42 dansmith mriedem: let me tell the stoy
21:09:44 dansmith *story
21:09:46 tssurya_ just like we now have a way to remove the hosts https://review.openstack.org/#/c/510324/

Earlier   Later