Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-17
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 gmann info
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: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
16:44:17 gmann sean-k-mooney: +1 on that.
16:44:33 sean-k-mooney yes on just that one api where we are adding thei fucntionality
16:44:50 sean-k-mooney if we need to expose something lese to project admins we can do that in a similar way
16:44:59 gmann checking token's cope part is little different and new which we need to check how to do
16:45:01 sean-k-mooney but we dont need full system_reader for project admin usecases
16:45:16 gmann agree.
16:45:24 sean-k-mooney i belive it should be in the context object
16:46:14 gmann yes we can do from context only difference is, it is 'system_scope' in context and 'system' in oslo policy side. but not big deal
16:47:26 sean-k-mooney stephenfin: updated https://review.opendev.org/#/c/755109/4 to a +1 if someone wants to +w
16:53:30 gmann stephenfin: sean-k-mooney replied on this what we disucssed - https://review.opendev.org/#/c/763043/1
16:53:55 stephenfin Ack, will respin shortly. Thanks :)

Earlier   Later