| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-17 | |||
| 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 :) | |
| 17:02:54 | lyarwood | kashyap / stephenfin ; thinking about the machine type enumeration problem a little more, do we care if an instance is using a versioned machine type? | |
| 17:03:14 | sean-k-mooney | lyarwood: kashyap and i disagree | |
| 17:03:17 | kashyap | lyarwood: Do you mean, should we record that or not? | |
| 17:03:24 | sean-k-mooney | lyarwood: i prefer to use the unversioned ones | |
| 17:03:31 | lyarwood | kashyap / stephenfin ; if we record the verioned machine type and always use it wouldn't that stop users getting security updates for free? | |
| 17:03:38 | sean-k-mooney | there are reason to use the versioned ones | |
| 17:03:46 | sean-k-mooney | livemigration/upgrades mainly | |
| 17:03:47 | lyarwood | sean-k-mooney: right I think I'm with you if the ABI remains the same | |
| 17:04:02 | sean-k-mooney | the machine type partly defines the abi | |
| 17:04:15 | sean-k-mooney | so it wont nessisarly remian the same but its largly the same | |