Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-18
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/
21:09:49 mriedem oh, oops
21:09:49 efried dansmith "for me"? It's all "for nova"!
21:09:57 efried There is no efried. Only zuulv3
21:10:16 mriedem well gather round children,
21:10:19 mriedem it's uncle dan's story time
21:10:34 mriedem long ago in a land called north carolina lived a boy named dan
21:10:34 dansmith tssurya_: so we remove instances once they're marked as deleted by "archiving" them with the command that mriedem mentioned
21:11:04 dansmith tssurya_: that moves them from the instances table to shadow_instances, where there are no constraints and then they can be deleted or dumped out to an archive log or something
21:11:18 dansmith tssurya_: right now, if you do this, you leave instance mappings for those instances which are no longer there forever, which is bad
21:11:20 tssurya_ mriedem, dansmith : I have seen the review of this nova-manage db archive_deleted_rows
21:11:38 dansmith tssurya_: while they're deleted=yes, they need their mapping, but once they get archived, the mapping should go away
21:11:57 dansmith tssurya_: so that archive command needs to follow up after the archival by deleting instance mappings from the api database
21:12:08 dansmith tssurya_: if you want to fix that since you're familiar with nova-manage now, that would be super awesome
21:12:21 dansmith generations of DBAs will thank you for years to come
21:12:25 tssurya_ dansmith : yes please would love to do it
21:12:33 dansmith woot ;)
21:12:50 mriedem uh, deleted=id
21:12:51 mriedem derp

Earlier   Later