| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-29 | |||
| 15:13:01 | openstackgerrit | melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636 | |
| 15:13:01 | openstack | bug 1731668 in OpenStack Compute (nova) queens "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [Low,In progress] https://launchpad.net/bugs/1731668 - Assigned to melanie witt (melwitt) | |
| 15:13:02 | openstackgerrit | melanie witt proposed openstack/nova stable/queens: [stable-only] Use a separate transaction for reading after race https://review.opendev.org/756637 | |
| 15:17:05 | lyarwood | melwitt: ack I'll look shortly | |
| 15:18:17 | melwitt | thanks | |
| 15:39:56 | sean-k-mooney | johnthetubaguy: so i would need to find it again but there is a fuse module that allows you to mount http directoes as a local file system | |
| 15:40:25 | sean-k-mooney | so the config drive alternitve was basically mounting metadata on the host and exposing it via cephfs | |
| 15:40:51 | sean-k-mooney | allow a config driver style approch without a config drive for guests without networking or whatever | |
| 15:42:06 | sean-k-mooney | the other cyborg like storage usecause weas using cyborg or something else to manage local storage on the host that can be exposed as fast epmeral storage withoug using the falvor epmeral option | |
| 15:42:37 | sean-k-mooney | that would only be useful if we had the ablity to have multiple device profiles or have a --device attach/detach | |
| 15:43:07 | sean-k-mooney | so right now im not proposing the cyborg approch since you cant contole it outside the flavor | |
| 15:43:17 | sean-k-mooney | also i have other more important things | |
| 15:51:01 | sean-k-mooney | but ya i have wanted to have a cyborg lvm driver for a while that we could use for local storage and testing in the gate since we can test programablity by just downloading the glance image to the volume. | |
| 16:03:11 | openstackgerrit | Merged openstack/os-vif stable/victoria: Update TOX_CONSTRAINTS_FILE for stable/victoria https://review.opendev.org/750925 | |
| 16:21:19 | bauzas | lyarwood: (14:58:48) lyarwood: anyone having issues pushing new patchsets to nova-specs? | |
| 16:21:37 | bauzas | lyarwood: oh, are you sure you use SSH over gerrit and not HTTPS ? | |
| 17:01:00 | legochen | hi nova experts, I’d like to understand why nova doesn’t provide provide access control for AZ like what network RBAC does :) | |
| 17:01:34 | lyarwood | bauzas: ssh://lyarwood@review.opendev.org:29418/openstack/nova-specs.git that's the remote it's trying to push to | |
| 17:01:38 | sean-k-mooney | legochen: AZ are just tags on aggreates | |
| 17:01:52 | sean-k-mooney | legochen: you can restrict aggeates to tenatns seperatly | |
| 17:02:23 | sean-k-mooney | legochen: so you kindo of can do this but no one has really asked for it before | |
| 17:02:25 | bauzas | legochen: you have policies on AZs.... | |
| 17:02:39 | sean-k-mooney | bauzas: not to filter the list of azs | |
| 17:02:56 | sean-k-mooney | bauzas: e.g. you cant just retrun the list of azs you can boot too | |
| 17:03:24 | sean-k-mooney | you can restict who can list them or pass them but that it with policy | |
| 17:03:24 | bauzas | sean-k-mooney: really? https://docs.openstack.org/api-ref/compute/?expanded=get-availability-zone-information-detail#availability-zones-os-availability-zone | |
| 17:03:28 | legochen | For example, we use AZ to group hypervisors for multiple different environments. And we only allow A users to use environment A, B users to use environment B. | |
| 17:03:45 | bauzas | legochen: then use aggregate metadata | |
| 17:03:54 | bauzas | lyarwood: looks legit | |
| 17:04:10 | bauzas | lyarwood: I was planning to bump on F33 tonight, will let you know | |
| 17:04:40 | sean-k-mooney | legochen you can do that with https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.limit_tenants_to_placement_aggregate | |
| 17:04:56 | sean-k-mooney | and https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.placement_aggregate_required_for_tenants | |
| 17:04:56 | legochen | yes, but the user experience is not so good for that case as they still can see that AZ listed. And when they specify that AZ to create VM, no errors will promot immediately. | |
| 17:05:05 | legochen | the error happens in scheduling step. | |
| 17:05:24 | legochen | users hard to aware of that. | |
| 17:05:37 | bauzas | anyway, bailing out, wanting to live the 3 last hours before the lockdown out of home | |
| 17:05:59 | sean-k-mooney | legochen: yes that is true we could maybe filter based on the other meatadata | |
| 17:06:10 | sean-k-mooney | the only way to do that today is to add custom midelware | |
| 17:06:29 | sean-k-mooney | but you could propose a new feature for it. its not a bug that it does not do it today however | |
| 17:07:34 | sean-k-mooney | legochen: filtering az by availablity would be an api change and would need a spec | |
| 17:07:58 | sean-k-mooney | legochen: normally you would do it via host aggreates and then tell your users to not specify an az | |
| 17:08:08 | sean-k-mooney | legochen: with aggreates you can make it transparent | |
| 17:08:33 | sean-k-mooney | az are really ment to be useable by all users | |
| 17:10:13 | legochen | As OpenStack has the ability to provide multi-tenancy use case. But, seems hard to do access-control for resources when we use only one control plane. | |
| 17:11:09 | sean-k-mooney | legochen: well the point is you shoudl not be doing access contol via AZs | |
| 17:11:20 | sean-k-mooney | you shoudl be doing that with host aggreates | |
| 17:11:23 | legochen | thanks sean for the information. I’m still new to openstack, this is my first week to join openstack IRC. not that sure the process to discuss the requirements or features. | |
| 17:12:08 | sean-k-mooney | AZs in openstack are very different the AZs in aws or other cloud plathforms | |
| 17:12:33 | sean-k-mooney | they are really just a host aggreate with a metadta key set to give them an az name | |
| 17:12:56 | melwitt | yeah, AZ are a user-facing grouping mechanism | |
| 17:12:56 | sean-k-mooney | as a result we dont really have a way to eaislly add rbac style filtering on them | |
| 17:13:45 | sean-k-mooney | it could be done but partioning of the cloud is ment to be somethign the operator know about rather then the user | |
| 17:13:49 | melwitt | "host aggregates" are the access-control-based counterparts that nova uses underneath. and an AZ can be composed of one or more host aggregates | |
| 17:13:58 | legochen | I have came up with this doc - I’m going to use domain to manage differet kind of users. I’m looking for a feature support that can do access control by “domain” level instead of only by “project” level. https://docs.google.com/document/d/1Cv3FB3HLc70o4EcFh9aLxzPVszRgulkADnmJxmT65a8/edit# | |
| 17:14:28 | sean-k-mooney | legochen: this has come up before | |
| 17:14:33 | sean-k-mooney | last cycle | |
| 17:14:49 | sean-k-mooney | i can recal exactly what we discussed but nova has no concept of a domain | |
| 17:15:01 | sean-k-mooney | legochen: domain exist only in keystone not other services | |
| 17:15:12 | melwitt | legochen: here is a helpful doc that explains AZ vs host aggregate https://docs.openstack.org/nova/latest/admin/aggregates.html | |
| 17:16:11 | legochen | sean-k-mooney: legochen: domain exist only in keystone not other services. <= but, have future plan for other services for supporting that? | |
| 17:16:32 | sean-k-mooney | legochen: no | |
| 17:16:41 | sean-k-mooney | not that im aware of | |
| 17:18:12 | legochen | oh no…….hmm, just thinking if OpenStack could support both doamin/project based access control, it really add more flexibility for OpenStack admin to manage multiple organizations :) | |
| 17:18:27 | sean-k-mooney | the best solution i can think off quickly would be to use https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html | |
| 17:18:58 | sean-k-mooney | and then add a prefilter to translate a users domain into a CUSTOM_DOMAIN_<domain> trait | |
| 17:19:41 | sean-k-mooney | legochen: it would be a lot of work to do and it might cause issue with keystone federation if all service had to support domain directly | |
| 17:20:11 | sean-k-mooney | using isolated aggreate with a prefilter to do the domain to trait traslation would be a very small change | |
| 17:20:26 | sean-k-mooney | and it would work i think in most cases | |
| 17:21:40 | sean-k-mooney | its basically what https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement does | |
| 17:21:48 | sean-k-mooney | but based on domains not project ids | |
| 17:21:59 | legochen | thanks, … keystone brings up the domain feature, but, only for authentication stuff, not actually use it for management services. seems not that logical :( | |
| 17:22:01 | sean-k-mooney | im prettysure that is what we said to do at the last ptg | |
| 17:22:50 | sean-k-mooney | legochen: domains are really a way of providing limit admin to people so they can manage flavor/quotas within that domain | |
| 17:24:23 | sean-k-mooney | legochen: if you were to do it the way im proposing you would basicaly copy paste https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L91-L132 | |
| 17:24:35 | sean-k-mooney | and replace the project id with the domain | |
| 17:25:14 | sean-k-mooney | well really the TENANT_METADATA_KEY with a DOMAIN_METADATA_KEY | |
| 17:26:15 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Modify glance's copy_image permission for nova-ceph-multistore https://review.opendev.org/760422 | |
| 17:26:48 | sean-k-mooney | so in https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L107-L114 just swap project_id for the domain and TENANT_METADATA_KEY for DOMAIN_METADATA_KEY and the rest is more or less the same | |
| 17:27:04 | sean-k-mooney | legochen: its less then 100 lines fo code + tests and docs | |
| 17:27:31 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: DNM: testing copy private image with admin https://review.opendev.org/760128 | |
| 17:27:40 | sean-k-mooney | but the important thing is you woudl be useing aggreate not AZs to map domains to hosts | |
| 17:28:39 | sean-k-mooney | legochen: if this is something you really need i woudl suggest addign it to https://etherpad.opendev.org/p/nova-wallaby-ptg so we can discuss it tommorow in the ptg | |
| 17:28:48 | legochen | yeah, but is it possible to let error promot could happen when users specify to a AZ that they don’t have permission to access? | |
| 17:29:16 | legochen | thank you sean :) | |
| 17:29:20 | sean-k-mooney | well they will get a novalid host error today | |
| 17:29:56 | sean-k-mooney | we could add an api check maybe it would have too check the aggreate metadata but that is proably ok | |
| 17:30:09 | legochen | hmm, no valid host could be caused by multiple reasons. | |
| 17:30:20 | sean-k-mooney | :) yes | |
| 17:30:54 | sean-k-mooney | gmann: do we need a microverion to convert no valid host into something else basically a 400 or 403 | |
| 17:31:27 | sean-k-mooney | legochen: i think if we added the api check we coudl only do it with a new microversion so request with teh old microversion would not be checked | |
| 17:32:21 | gmann | sean-k-mooney: no as long as it return any existing error code (like 400 and 403). | |
| 17:32:23 | sean-k-mooney | based on https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion | |
| 17:32:34 | gmann | we convert it to 200 or new error code then yes | |
| 17:32:38 | legochen | that would be great to clearly explain what’s going on in the error message :) do you think it is worth to do | |
| 17:33:01 | sean-k-mooney | gmann: today it would be a 200 but then later it will fail with no valid host | |
| 17:33:08 | sean-k-mooney | the az filter would block it | |
| 17:33:18 | sean-k-mooney | so it would be a 200 to 400 or 403 | |
| 17:33:23 | sean-k-mooney | on server create | |
| 17:34:11 | sean-k-mooney | legochen: gmann lets talk about this in the ptg tomorow if we have time | |
| 17:34:55 | gmann | sean-k-mooney: i see then we need microversion bump hoping server creation happening successfully previously | |