| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 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 | melwitt | I don't, but just wanted to ask in case I missed something | |
| 21:02:51 | mriedem | and dan has one more thing for the efficient instance listing weirdness with cell0 | |
| 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 | efried | dansmith "for me"? It's all "for nova"! | |
| 21:09:49 | mriedem | oh, oops | |
| 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 | dansmith | tssurya_: so we remove instances once they're marked as deleted by "archiving" them with the command that mriedem mentioned | |
| 21:10:34 | mriedem | long ago in a land called north carolina lived a boy named dan | |
| 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 | |
| 21:12:56 | mriedem | c'mon | |
| 21:13:08 | dansmith | mriedem: in the object, it's boolean, c'mon | |