Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-17
13:39:01 sean-k-mooney so even with the cache we are not guareteed to be able to connect
13:39:23 lyarwood sean-k-mooney: really depends on the backend, most could be up still
13:39:40 lyarwood sean-k-mooney: we could at least attempt to refresh tbh
13:41:17 sean-k-mooney ya ceph and other likely are not running on the same hosts as the cinder services
14:01:29 tacco hm.. struggling aroung with aggregates, strange behavior. i tought if i create a aggreagate with a key and attatch that key to a flavor only hosts with the specific flavors are on the aggregate hosts.
14:02:06 sean-k-mooney tacco: only if you use the placement version
14:02:09 tacco or is there anything else to do? For now only a couple of HVs already have the new filter. But i guess only the hosts in the aggregate group needs this filter, or to be aware of.
14:02:18 sean-k-mooney if you use the fitler you need to add key=false to every other flavor
14:02:37 tacco ah.. ok, thanks. that could help for the moment :)
14:02:45 sean-k-mooney https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html
14:03:03 tacco i tought absence of this flavor also implies that it can not be on the hosts.
14:03:12 tacco thanks for pointing me there.
14:03:33 sean-k-mooney tacco: nope that what many assume but its not how it works
14:03:48 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP - Image and flavor defined ephemeral storage encryption https://review.opendev.org/752284
14:04:19 sean-k-mooney tacco: this is basically unmaintained and im not sure if it still works(it should) but https://opendev.org/x/nfv-filters provdes a filter that does what you want
14:04:42 sean-k-mooney https://opendev.org/x/nfv-filters/src/branch/master/nfv_filters/nova/scheduler/filters/aggregate_instance_type_filter.py
14:04:58 sean-k-mooney docs are here https://opendev.org/x/nfv-filters/src/branch/master/doc/source/scheduler_filters/aggregate-instance-type-filter.rst
14:05:13 sean-k-mooney if you dont have placment avaiable with the prefilter then that shoudl bridge the gap
14:05:27 tacco ok, will read first and decide then. :) but.. yeah.. found a bug that was already reported. yay
14:06:08 sean-k-mooney its actully more powerful the what you can do with placemnt or the code in tree but its out of tree and not maintained by me really anymore
14:08:09 tacco yes.. can understand that. I would like to stick as close as i can to upstream and maintained versions.
14:09:21 tacco only if there is no other way out i would think about that.. but our first solution we had was way to full with cherry-picked stuff.. and deployment was only done by manual actions.. i hate it. Now we have a nice fully automated and functional setup i don't want to miss that anymore. :D
14:15:08 lyarwood exit
14:15:10 lyarwood argh
14:16:47 kashyap "You can leave anytime, but you can never exit."
14:50:22 tacco sean-k-mooney: where do i have to set the scheduler.enable_isolated_aggregate_filtering nova.conf on the HVs?
14:50:53 sean-k-mooney no nova.conf on the schduler
14:51:07 sean-k-mooney so on the contollers
14:51:26 openstackgerrit Merged openstack/nova master: Restore retrying the RPC connection to conductor https://review.opendev.org/762633
14:51:37 openstackgerrit Merged openstack/nova master: Fix the vGPU dynamic options race https://review.opendev.org/758470
14:51:50 openstackgerrit Merged openstack/nova master: api-ref: Move 'os-agents' API to obsolete section https://review.opendev.org/755729
14:52:54 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199
14:53:01 lyarwood kashyap: ^ btw you might be interested in this, I've used some text from a former spec of yours
14:53:09 tacco ok i see. thansk will give it a try. :)
14:53:26 kashyap lyarwood: Ack; will queue
14:58:04 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199
15:09:23 sean-k-mooney melwitt:i saw your questions/comments on https://review.opendev.org/#/c/602432/ by the way ill adress them shortly and respin it.
15:10:40 sean-k-mooney melwitt: tl;dr plugin a port for vif_type=ovs and hybrid-plug=false is currently a noop unless you are on windows where they pass crete-port to have os-vif create teh ovs port
15:11:15 sean-k-mooney melwitt: it was a noop because libvirt was previously creating the ovs port which is racy and what im changing in my patch
15:11:53 sean-k-mooney so we now need to pass create-port=true but ill likely remove that in a futre release of os-vif
15:12:20 sean-k-mooney i orginally made it unconditional but it triggered a race in the ovs agent which has sicne been fixed
15:13:05 sean-k-mooney in hignsight i should not have reverted the cahnge and added create-port but it was too late in the cyle to make it unconditonal again
15:13:49 sean-k-mooney ill deprecate it this cycle and likely remove create-port in x
15:14:17 sean-k-mooney since all knwon callers will now be passing true
15:21:42 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: WIP - Image and flavor defined ephemeral storage encryption https://review.opendev.org/752284
15:32:52 tacco whats the best way to figure out which hosts are given back by the API if i request a certain flavor? because try+error could be verry boring over the time :D
15:33:37 tacco --debug to the cli command and see the api result? :)
15:37:06 sean-k-mooney tacco: you cant really
15:37:24 sean-k-mooney tacco: even if you were to ask placment that woudl not take into account features
15:37:30 sean-k-mooney there is no dry run option
15:37:36 tacco i see.
15:37:37 sean-k-mooney or similar to get the list
15:39:17 hemanth_n Hi appreciate any reviews on the following backports https://review.opendev.org/#/q/status:open+project:openstack/nova+topic:bug/1892361 thank you
15:49:15 stephenfin sean-k-mooney: when did we talk about the project_admin behaviour /o\ https://review.opendev.org/#/c/755109/
15:49:30 stephenfin I agree it makes sense but I can't remember discussing it, heh
15:52:30 sean-k-mooney in the post ptg review
15:52:36 sean-k-mooney last week
15:53:00 sean-k-mooney as an alternivie to gmann use system_reader+proejct_admin proposal
15:53:13 sean-k-mooney also in the call with lance
15:53:17 sean-k-mooney on the nova rbac stuff
15:53:59 sean-k-mooney so not upstream unfortunetly but i suggested puting it into your spec on the call
15:54:12 sean-k-mooney we did talk about alot of stuff on that call to be fair
16:00:43 stephenfin sean-k-mooney: fair fair. Let me amend it real quick
16:01:40 sean-k-mooney i was happy with the rest of the spec for what its worth
16:01:50 sean-k-mooney i said it was fine but i ment it looked good
16:12:26 tacco sean-k-mooney: thanks that helped, now i have to see how to get the config part into os_nova for openstack-ansible to persist my change somewhere upstream. :D
16:12:50 sean-k-mooney :)
16:35:19 gmann stephenfin: sean-k-mooney replied on review. are we allowing hypervisor info for projects for use case of boot server on host?
16:35:32 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Update modernize-os-hypervisors-api spec https://review.opendev.org/763043
16:36:42 stephenfin gmann, sean-k-mooney, bauzas, gibi: I've split that potential policy change out so we can debate the merits of it separately ^
16:37:51 gibi stephenfin: ack, thanks
16:37:58 gmann stephenfin: +1,
16:38:15 sean-k-mooney gmann: yes
16:38:33 sean-k-mooney gmann: i dont think we shoudl be using system_read+proejct_admin
16:38:47 gmann what we can do is keep GET /os-hypervisors for ['system' and 'projects'] and only return list of hypervisors for project what all they are access to via aggregate metadata otherwise emtpy
16:39:12 stephenfin sean-k-mooney: You okay to discuss separately, yeah? Can you toggle your -1 if so?
16:39:15 gmann sean-k-mooney: well if we make only project then system would not be able to list hypervisor at all
16:39:29 sean-k-mooney stephenfin: yep if you file a second spec im happy to defer to there
16:39:41 gmann and adding/removing the host are system level operation right
16:39:42 stephenfin See https://review.opendev.org/763043
16:39:46 sean-k-mooney gmann: system would
16:39:53 sean-k-mooney gmann: its an additive change
16:40:09 sean-k-mooney fithe now yould admins can call /os-hyperviors
16:40:16 sean-k-mooney ....
16:40:39 sean-k-mooney right now only admins can call /os-hypervisors
16:40:47 gmann but they need scope as project. so any system scope token would not be able to do 'project'-only scope
16:41:02 sean-k-mooney right
16:41:15 sean-k-mooney system scoped tokens should not be project only
16:41:34 gmann yeah so how they get hyperviors ino
16:41:38 sean-k-mooney im suggesting project_admin shoudl be able to list the host summaries for all hosts tehy can boot too
16:41:38 gmann info
16:42:26 gmann yeah that i agree. but keep scope_type as ['system', 'project'] sop that system can list all hyperviros and project can only list what they have access to
16:42:50 sean-k-mooney with role admin
16:43:02 gmann and default to SYSTEM_READER_OR_PROJECT_ADMIN
16:43:03 sean-k-mooney we dont want project member or reader to have acess
16:43:04 gmann yes
16:43:12 sean-k-mooney ya
16:43:22 sean-k-mooney SYSTEM_READER_OR_PROJECT_ADMIN woudl be correct
16:43:43 sean-k-mooney if we do that we dont need to change the api to pass a proejct id
16:44:03 gmann cool and in code we can check and return only the project accessible hypervisors but in that case we need to check the token's scope in nova code

Earlier   Later