Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-22
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 AggregateList.get_by_metadata() query method https://review.openstack.org/544728
18:16:17 openstackgerrit Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729
18:16:18 openstackgerrit Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730
18:16:18 openstackgerrit Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990
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.

Earlier   Later