Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-22
18:16:19 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
18:16:19 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282
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: Modify nova-manage cell_v2 list_cells to display "disabled" column https://review.openstack.org/555415
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: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 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: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: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
18:43:00 kmalloc ok, thanks!
18:43:21 kmalloc (again, forward looking things)
18:43:23 mriedem https://review.openstack.org/#/c/525772/
18:43:34 kmalloc yeah
18:43:36 kmalloc ty!
18:45:33 kmalloc jaypipes: sortof, system-scope is designed to not let you do things like make resources (create a VM) - but still do actions like [for example] disable a hypervisor (clearly not a project-scoped action, very much infrastructure admin) [these are examples, not meaning that api would exist]
18:45:45 jaypipes kmalloc: not sure how forward looking it is, considering the bug report is from 2012-03-29.
18:45:48 jaypipes ;)
18:46:45 kmalloc jaypipes: forward looking in keystone-and-ks-middleware support vs "when the bug was filed and we suck at fixing that across openstack's history" ;)
18:47:44 sean-k-mooney kmalloc: ah so a system-scoped token could set the datapath_down field on a neutorn port or admin_state but not delete or create a neutron port
18:48:02 kmalloc sean-k-mooney: right. that would be the kindof idea
18:48:21 sean-k-mooney kmalloc: would you also envision it allowing migrate actions also or jsut service level apis
18:49:00 kmalloc sean-k-mooney: the plan is really for things that are meant to be done administratively vs by an end user. Migrate is a bit gray
18:49:24 kmalloc i've seen it used in non-administrative ways.
18:49:38 sean-k-mooney kmalloc: im just trying to tink of why a full could admin token would not be correct in this case
18:49:40 kmalloc though haven't looked at common cases lately (my knowledge there is out dated)
18:49:58 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
18:49:59 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282
18:50:23 kmalloc sean-k-mooney: trying to break the "manage infrastructure" and "admin can do things for an account/domain/project"
18:50:44 sean-k-mooney kmalloc: ah ok makes sense.
18:51:03 kmalloc yeah, it's something we've needed for a long time
18:51:14 kmalloc because admin via a magic project scope is ... kindof awful
18:51:46 kmalloc it leads to a lot of potential "oopse, this scope bled through and let something happen" making the concept of say "domain admin" hard.
18:51:53 jaypipes kmalloc: kinda awful that is the same as it was >6 years ago...
18:52:21 kmalloc jaypipes: yes, and through many many many many iterations... we have successfully moved the needle to "yeah we still need to fix it"
18:52:29 kmalloc jaypipes: which makes me a bit more than sad.
18:52:31 jaypipes kmalloc: not saying it's not a good idea, just that clearly everyone has worked around it or lived with admin-ness for time eternal at this point.
18:52:41 sean-k-mooney kmalloc: https://review.openstack.org/#/c/525772 will result in a api microversion change also right
18:52:59 kmalloc sean-k-mooney: hm.
18:53:28 kmalloc sure? but how are old microversions managed in policy... wait wait, going to stop going down this rabbithole for now
18:53:33 mlavalle rybridges, melwitt: Neutron creates the aggragates for you: https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L216
18:54:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Always deallocate networking before reschedule if using Neutron https://review.openstack.org/520248
18:54:02 mriedem oomichi: can you re-approve this? ^ it sat so long that the test needed to be updated.
18:54:04 kmalloc jaypipes: right, but i think it's time to provide a real fix rather than relying on "everyone has their own workaround"
18:54:20 sean-k-mooney kmalloc: do unscoped tokens work for all scoped apis. if so then you proable dont need on but it might be nice to have a microverion
18:54:22 kmalloc jaypipes: and with policy-in-code, and scope-types we're really moving the right way
18:54:35 kmalloc sean-k-mooney: no, unscoped tokens don't work anywhere
18:54:42 kmalloc excpet to get a scoped token in keystone.
18:54:47 jaypipes kmalloc: ok
18:55:14 kmalloc sean-k-mooney: we're trying to allow RBAC for system-scope actions, unscoped tokens are explicitly no-roles.
18:55:25 sean-k-mooney kmalloc: ok so ya that would be a micro version bump then for backwards compatiblity.
18:55:28 melwitt mlavalle: right, but what about compute hosts that go into those aggregates? is that something neutron can do automatically or is it left up to the admin to have to do that?
18:55:48 melwitt thanks for chiming in, btw :)
18:55:53 kmalloc sean-k-mooney: yeah i'm not sure how a microversion affects policy enforcement -- it becomes weird.
18:55:58 jaypipes kmalloc: I struggle to have confidence in the firmness of the ideas after seeing keystone v3 domains, federation, PKI and other things go back and forth.
18:56:29 kmalloc jaypipes: well, please chime in on the scope types stuff.
18:56:37 mlavalle melwitt, rybridges: Neutron adds the hosts to the aggregate: https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L223
18:57:04 sean-k-mooney mlavalle: that is for routed networks correct
18:57:21 mlavalle sean-k-mooney: yes it is
18:57:56 kmalloc jaypipes: there are a number of things we have not changed once other services lean on it. [also not sure what you mean firmness of federation, that's stayed the same and been built on, it hasn't been taken out]
18:58:16 melwitt mlavalle: a-ha, okay. so rybridges is seeing behavior where no hosts get added to the aggregate
18:58:18 kmalloc jaypipes: but i'd rather have more eyes/comments than less on the scope-types work.
18:58:28 rybridges Hey mlavalle! Thanks so much for the reply. We just checked the segmenthostmappings table in the DB and we see that the host mappings are in the table and our compute hosts are listed. But they are not added in the outpute of aggregate show
18:58:56 kmalloc sean-k-mooney: i'll have to see how the policy stuff shakes out with microversions, i'm sure it'll be 100% ok, just not clicking right this moment.
18:59:14 kmalloc sean-k-mooney: which means, i need to poke at things more. hehe :)
18:59:58 kmalloc sean-k-mooney: thanks for your time!
19:00:25 cfriesen jaypipes: cpu thread isolation is actually a valid issue for resource accounting, because the amount of resources consumed is variable depending on whether the host has enabled HT or not.
19:00:53 sean-k-mooney kmalloc: ya no worres i just didnot notice any microversion bumps in https://review.openstack.org/#/c/525772/4 and sice it has 1+2 already i taught i would ask since it proably should not merge until that is checked
19:01:09 jaypipes cfriesen: I don't doubt that. I'm saying that the cpu_threads_policy has nothing to do with resource accounting.
19:01:23 kmalloc sean-k-mooney: yeah, it might also not require a microversion, because it doesn't actually change anything yet, the change might need a microversion.
19:01:41 cfriesen jaypipes: but it does, since it determines whether we need to allocate additional resources on some compute nodes
19:01:58 kmalloc sean-k-mooney: i'll make sure to get some time to ensure we aren't introducing any breaking changes there (i don't think we are) that would require microversion bumps and if we are... make sure it's added
19:02:01 sean-k-mooney kmalloc: oh adding the scope_types=['project'] does not change the behavior
19:02:11 kmalloc sean-k-mooney: yeah it shouldn't.
19:02:18 jaypipes cfriesen: whether the host has HT enable impacts the reporting of CPU inventory for the host (or its NUMA nodes), but cpu_threads_policy only affects which host processors the guest is willing to be pinned to.
19:02:48 jaypipes cfriesen: are you referring to cpu_allocation_policy?
19:02:56 jaypipes or cpu_threads_policy?
19:02:57 kmalloc sean-k-mooney: yeah it's meant to just allow for richer policy allowing for defining the scope-types in policy as well
19:03:04 cfriesen jaypipes: no. If I ask for 1 PCPU and set cpu_thread_policy=ISOLATE then it will actually consume two host CPUs (the main one and the HT sibling)

Earlier   Later