| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 17:13:49 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802 | |
| 17:13:53 | sean-k-mooney | so looking at the docs you can only have 1 emulator thread. you can have multiple io thread and multiple vcpu trheads | |
| 17:14:13 | cfriesen | sean-k-mooney: don't we spawn another emulator thread when live migrating? | |
| 17:14:17 | stephenfin | bauzas: We're enraging jaypipes to the point that I fear for his pugs' lives | |
| 17:14:23 | jaypipes | cfriesen: but it's not like that is something dynamically calculated, right? I mean, a guest either has dedicated CPUs or it doesn.t' | |
| 17:14:26 | jaypipes | https://tenor.com/view/angry-panda-mascot-mad-gif-3456638 | |
| 17:14:29 | sean-k-mooney | cfriesen: i dont know but in that case to we care | |
| 17:14:38 | cfriesen | jaypipes: correct. | |
| 17:14:41 | bauzas | stephenfin: hold my beer | |
| 17:14:45 | sean-k-mooney | cfriesen: its live migrating all sla are out the window at that point | |
| 17:14:53 | stephenfin | bauzas: Also, we're trying to figure out how we map things like emulator threads policy and the ISOLATE CPU threads policy features to placement | |
| 17:15:00 | bauzas | k | |
| 17:15:11 | jaypipes | cfriesen: so it would be a request for, say resources:CPU_DEDICATED=4 (the vCPU threads) and resources:CPU_SHARED=1 (the emulator thread) | |
| 17:15:50 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802 | |
| 17:15:51 | cfriesen | jaypipes: if we assume that the emulator thread is doing a non-trivial amount of work then that would be accurate. | |
| 17:15:59 | jaypipes | cfriesen: and no request for resources:VCPU, since there's no "VCPU" resources being consumed by the guest. | |
| 17:16:16 | cfriesen | jaypipes: if we assumed the emulator thread is doing a trivial amount of work then we could avoid allocating resources for the emulator thread entirely | |
| 17:16:33 | jaypipes | cfriesen: it's not about whether the emulator thread is doing a lot of work or not. it's about whether we want to *account* for it -- which obviously would be up to the operator, yes? | |
| 17:17:01 | jaypipes | cfriesen: if the operator didn't care, they wouldn't put resources:CPU_SHARED=1 in the flavor extra spec | |
| 17:17:18 | cfriesen | jaypipes: okay, I get you. | |
| 17:17:46 | cfriesen | keeping resource allocation separate from the nitty-gritty of actually affining things, I think what you say is true | |
| 17:17:56 | jaypipes | ++ | |
| 17:17:57 | stephenfin | I wonder what operators _would_ care about this? It's not exactly a thing you'd use in a bog-standard cloud | |
| 17:18:12 | sean-k-mooney | jaypipes: i dodnt think we should assume resources:CPU_SHARED=1 is the emulator thread though | |
| 17:18:23 | stephenfin | Another idea: we could add sahid's emulator_thread_pin_set option and forget the whole thing accounting thing | |
| 17:18:52 | jaypipes | sean-k-mooney: we're not assuming that. | |
| 17:18:53 | stephenfin | Same way we don't account for things that currently run on the host outside of 'vcpu_pin_set' | |
| 17:19:19 | jaypipes | sean-k-mooney: it could be anything associated with the guest that is consuming some amount of shared CPU resources. | |
| 17:19:36 | stephenfin | That's a variant of the "use the shared pool and ignore the impact idea", but this would ensure our emulator threads wouldn't impact the guests running on said shared pool | |
| 17:19:44 | sean-k-mooney | ok can i sugges we document this here https://etherpad.openstack.org/p/cpu-resource-accounting | |
| 17:19:48 | stephenfin | e.g. during a live migration | |
| 17:19:52 | sean-k-mooney | then we can pull it into the spec | |
| 17:20:02 | jaypipes | sure | |
| 17:20:12 | cfriesen | jaypipes: the thing here though is that "emulator_thread_policy=isolate" is what we currently ask for. I'm not enthusiastic about saying that they *also* need to set CPU_SHARED=1 or similar | |
| 17:20:16 | jaypipes | I need to take a quick walk to screw my head back on, though. | |
| 17:20:34 | cfriesen | I need coffee | |
| 17:20:54 | jaypipes | cfriesen: they wouldn't *need* to. if they didn't, the resource accounting would just continue to be messed up and inaccurate. | |
| 17:20:57 | bauzas | I need to catch up the convo... | |
| 17:21:08 | jaypipes | anyway, I will now take a walk. | |
| 17:21:40 | openstackgerrit | sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605 | |
| 17:21:42 | sean-k-mooney | bauzas: the reason i suggested the etherpad is i think we all need to catch up and get it donw on "paper" | |
| 17:22:24 | bauzas | sean-k-mooney: etherpads are good, but I tend to think hangouts are way better | |
| 17:22:31 | bauzas | for reaching to a conclusion | |
| 17:22:35 | sahid | hum.. I just noticed your comments johnthetubaguy, let me update the spec | |
| 17:22:46 | stephenfin | bauzas: I think we need to get our ideas in order first though | |
| 17:22:58 | sean-k-mooney | bauzas: we can do both | |
| 17:23:00 | stephenfin | Also, it's almost home time for me and I have dinner plans this evening :) | |
| 17:23:17 | bauzas | your fault | |
| 17:23:37 | bauzas | I just spent the whole day between meetings and troubleshooting | |
| 17:23:47 | bauzas | I just feel I need to pass my nerves on something | |
| 17:24:29 | bauzas | ah, and kids-sitting, thanks to our glorifous country that doesn't like work | |
| 17:30:00 | sahid | mikal: sorry to annoy you each time I have CI problem, but our CI is really slow, no? | |
| 17:30:42 | sahid | wrong channel sorry | |
| 17:37:15 | rybridges | Hello. Got a question for you guys. I am trying to setup routed provider networks with Neutron. I created a network with a segment and a subnet associated with that segment. Then the host aggregate for the segment gets created automatically in nova when I do those things. However, when I do openstack aggregate show on the aggregate, I don't see any hosts associated with the aggregate that gets | |
| 17:37:17 | rybridges | created. Is this normal? Or a bug? Or some problem on our end? | |
| 17:37:19 | rybridges | I am running the openvswitch agent on my hypervisors. Dont have any other pre-existing aggregates | |
| 17:43:00 | sean-k-mooney | stephenfin: by the way we should keep https://etherpad.openstack.org/p/cpu-resource-accounting and turn it into docs for this stuff | |
| 17:49:24 | openstackgerrit | Merged openstack/osc-placement master: Resolve nits from I552688b9ee32b719a576a7a9ed5e4d5aa31d7b3f https://review.openstack.org/537971 | |
| 17:51:01 | melwitt | rybridges: I'm not familiar with the details of the feature but at a high level, I would think you (the admin) would have to add hosts to the host aggregates. that is, how would neutron know which hosts to put in which aggregates for you? mlavalle, can you confirm how one is expected to configure on the nova side to use routed provider networks? ^ | |
| 17:53:14 | rybridges | Thanks so much for the response melwitt. I was thinking nova might know because of the bridge_mappings in the openvswitch conf. Since all of the bridge mappings on my hypervisor point to the same physical network, and I created the neutron network with that physical network, I was thinking nova / neutron might be able to pick that up. | |
| 17:53:42 | rybridges | We can add the hosts manuall to the aggregate. I just wanted to make sure that is normal and we aren't expecting them to be added for us | |
| 17:56:19 | melwitt | yeah, understood. hopefully mlavalle can confirm when he's around. there are some docs and summit videos about the feature (https://etherpad.openstack.org/p/nova-ptg-rocky L240) but from skimming them I don't see mention of what to do on the nova side | |
| 17:56:46 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384 | |
| 18:02:15 | openstackgerrit | Merged openstack/nova stable/pike: Revert "Refine waiting for vif plug events during _hard_reboot" https://review.openstack.org/553818 | |
| 18:04:15 | rybridges | Ya we found a talk about it from a summit in 2016 here: https://youtu.be/HwQFmzXdqZM?t=33m5s The guy does a demo and shows that when you create the network and subnet, the aggregate is automatically created and has the compute hosts in there | |
| 18:16:17 | openstackgerrit | Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729 | |
| 18:16:17 | openstackgerrit | Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728 | |
| 18:16:18 | openstackgerrit | Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990 | |
| 18:16:18 | openstackgerrit | Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730 | |
| 18:16:19 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282 | |
| 18:16:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002 | |
| 18:16:22 | sean-k-mooney | bauzas: oh by the way are you around? regarding the nic feature based scheduling. https://review.openstack.org/#/c/545951/ if i was to start it from scratch today i would totally use placement and tratis and model the requests as tratis on the neutron port for a resouce class of type VIF | |
| 18:17:04 | sean-k-mooney | bauzas: that said i was only ment to work on this feature this cycle as it was assume that little to no code change would be needed since it was approved for the last 2 cycles. | |
| 18:17:17 | sean-k-mooney | bauzas: so im not really sure what to do with https://review.openstack.org/#/c/545951/. | |
| 18:18:37 | sean-k-mooney | bauzas: 50% of the feature(all the discovery and stroage fo the nic feature in the nova db) has been merged since pike. the only bit that was missing was using it in the schduler and the change to the pcirequest spec. | |
| 18:21:37 | openstackgerrit | melissaml proposed openstack/nova master: fix a typo in provider_tree.py https://review.openstack.org/555404 | |
| 18:32:31 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Amend the member_of spec for multiple query sets https://review.openstack.org/555413 | |
| 18:32:44 | dansmith | efried: cdent: edleafe: ^ proposal to argue over | |
| 18:34:47 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527 | |
| 18:34:48 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add --enable and --disable options to nova-manage update_cell https://review.openstack.org/555416 | |
| 18:34:48 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Modify nova-manage cell_v2 list_cells to display "disabled" column https://review.openstack.org/555415 | |
| 18:34:49 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add disabled option to create_cell command https://review.openstack.org/555417 | |
| 18:36:00 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Always deallocate networking before reschedule if using Neutron https://review.openstack.org/555418 | |
| 18:38:38 | kmalloc | whatever project, even if it doesn't exist" api, to let folks do that kind of cleanup/iterate over the instances in nova. | |
| 18:38:38 | kmalloc | dansmith: i wanted to ask you a question, would you (as a nova team/core) be opposed to the concept of an API that (say for pure administration purposes) would let you cleanup all resources (notably for the case of "keystone project has been deleted, but i want all instances cleanup) -- letting nova schedule the "cleanup" (/cleanup-all-resources-for-project/<project-id>). Trying to avoid a "let someoen scope to | |
| 18:38:53 | kmalloc | mriedem: ^ cc (same question for you) | |
| 18:39:10 | jroll | rybridges: not sure if this was in ocata, but routed networks should be using placement aggregates for that, might be worth hitting the placement api and checking those. (again that's definitely how it is in queens, idk about ocata though) | |
| 18:39:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 18:40:15 | jaypipes | kmalloc: I would be opposed to that, yes. there are notification event queues that external agents/workers can listen to and do the needful cleanup via the Compute API. | |
| 18:40:21 | mriedem | kmalloc: IMO that is something that can be dealt with in mistral | |
| 18:40:28 | dansmith | kmalloc: you can do that today with a few lines of bash and novaclient right? | |
| 18:40:30 | melwitt | kmalloc: that's not something that's going to be in nova (or any of the other projects themselves) but in I think this openstackclient purge CLI does what you're describing https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/project-purge.html | |
| 18:41:41 | sean-k-mooney | melwitt: there is noting preventing an external service/agent/cli tool with admin previlages from doing that in pricipal however correct. its just not implented | |
| 18:41:43 | kmalloc | melwitt: right, but if you can't get a scoped token for a project anymore... | |
| 18:41:56 | mriedem | admin? | |
| 18:41:57 | jaypipes | kmalloc: and administrative token can be procured, no? | |
| 18:42:12 | kmalloc | i was looking at the forward idea of system-scope (for administrative actions) | |
| 18:42:36 | kmalloc | it is tying to eliminate the concept of an "admin" project you scope to for this kind of thing | |
| 18:42:57 | kmalloc | but if nova can be made aware of system-scope for the "admin" cases, i guess that works just as well | |
| 18:42:59 | sean-k-mooney | kmalloc: e.g. an admin token that only allowed to make requets against a specific host | |