Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-22
22:37:10 mriedem efried: re admin auth it depends on what we're doing i guess and what the cyborg api policy is
22:37:20 aspiers sean-k-mooney: I need to mock the presence and contents of /sys/module/kvm_amd/parameters/sev
22:37:22 sean-k-mooney right so im not seeing why you would ever fall back to real_open
22:37:35 aspiers because of other things like placement-policy.yaml which live inside the testenv
22:37:46 efried mriedem: It sounds like Sundar has thought it through and has been assuming the operations should be done on behalf of the user so that proper policy and quota can be taken into account. Do you see any problem with that approach?
22:37:50 aspiers or temp files created by the test framework like efried said
22:38:09 efried mriedem: johnthetubaguy and I have advised him on enabling service_user, but otherwise, should be okay yes?
22:38:16 sean-k-mooney if they are withing the tox venv i gues its fine
22:38:23 mriedem efried: i think for most things with external-to-nova resources we try to use the user auth, for things with volumes/images/ports
22:38:41 sean-k-mooney just so long as the files are not form the host system
22:38:57 mriedem but there are certain APIs on those resources that we use admin creds, like port binding is admin-only since it's host-level info
22:39:12 efried mriedem: k, so ironic is the outlier. And then there's a little bit of neutron that does admin, not sure what that's about. And then there's a little edge case in cinder that uses admin as well.
22:39:18 efried yeah
22:40:11 mriedem nova didn't even have config to do admin level stuff with cinder until a few releases ago
22:40:25 mriedem to forcefully detach a volume when we didn't have a token
22:41:23 mriedem so if there is host-level stuff we need to do i'd expect those apis to be admin-only by policy in cyborg
22:41:35 mriedem i don't know enough about their api though
22:41:51 mriedem like, you as a user can create an fpga resource and provide that to nova on server create to wire it up right?
22:42:06 sean-k-mooney mriedem: that was one of the thing in the spec we called out
22:42:35 sean-k-mooney e.g. that cyborgs api whoudl be admin by default
22:42:44 mriedem so ironic
22:43:08 sean-k-mooney since its manaing host level resouces that are potentially damaging if used incorrectly
22:43:23 mriedem there are also nova/cinder interactions we probably should have done differently from the start, because some cinder apis that nova uses leak host level connection information and aren't admin apis
22:43:51 mriedem weee https://bugs.launchpad.net/cinder/+bug/1740950
22:43:52 openstack Launchpad bug 1740950 in Cinder "Volume details shows attached compute host for non-admins" [Undecided,New]
22:44:04 sean-k-mooney lick the conection context or whatever its called that has the iscsi info
22:44:15 sean-k-mooney attachment?
22:44:17 mriedem heh "If it lingers past Queens release day, we can revisit the advisory task."
22:44:34 mriedem yes the attachment has the connection_info dict
22:44:45 sean-k-mooney ya that has come up a few times
22:46:43 sean-k-mooney in the cyborg case that is one of the open items in the spec here https://review.opendev.org/#/c/603955/12/specs/train/approved/nova-cyborg-interaction.rst@301
22:49:51 sean-k-mooney :( https://github.com/openstack/cyborg/blob/master/cyborg/common/policy.py#L76-L122
22:50:23 sean-k-mooney why is the program endpoint using allow ...
22:53:15 efried sean-k-mooney: That (cyborg APIs being admin only) was something you brought up, but it sounds like that's not how they're planning on doing it.
22:54:28 mriedem someone call lbragstad
22:54:29 sean-k-mooney yes well currently anyway can update any fpga recored with there default policy so how they were planning on doing it and what they proably should do are likely not the same thing
22:55:04 efried mriedem: Just this morning someone was asking about a rare failure in the logs where cinder complained of not having admin creds.
22:55:09 mriedem admin-only by default seems smartest and makes the nova interaction strict from the get-go
22:55:29 efried http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-22.log.html#t2019-05-22T12:46:19
22:55:41 mriedem but idk, that might make it hard to allow non-admin stuff later
22:55:43 sean-k-mooney the deployable create/update/delete are adming only
22:56:22 efried mriedem: seems to me like that's worse, because it means we *require* admin creds in the conf, and all operations would be allowable.
22:56:29 sean-k-mooney update and delete on acclertors are admin or own so for those it proably fine
22:57:14 efried cyborg sounds like they have a plan for granular policy (is that the right use of that term?) and if so it makes sense to do user auth from nova.
22:57:37 mriedem efried: without knowing where that users was getting the error i can't really say on that cinder thing,
22:58:09 mriedem it was added b/c there is a periodic in the compute which will shelve offload instances after a period of time, and cleanup soft-deleted instances after a period of time, which means doing things on volumes w/o a user token
22:58:10 sean-k-mooney efried: for some things that makes sense but i think there fpga update should ast least be admin_or_owner
22:58:36 efried mriedem: Well, I wound up concluding that it was probably the thing you just mentioned, the parts of cinder where we need the admin creds for those weird periodic edge cases.
22:59:15 efried they didn't have any admin creds in their conf
22:59:19 mriedem ok on the cyborg policy thing, idk, if only we had like a technical committee in openstack or something with security guidelines
22:59:23 mriedem or an auth/identity team...
22:59:41 mriedem but it's 6pm and i'm not sean-k-mooney so i need to drop off
22:59:46 efried o/
22:59:53 sean-k-mooney o/
23:00:22 sean-k-mooney hay look its thursday ...
23:00:41 sean-k-mooney i should proably go to sleep soon.
23:01:06 sean-k-mooney efried: i didnt get to rework the vidoe-model stuff but i shoudl get that done tomorrow
23:01:11 efried no worries
23:03:08 sean-k-mooney Sundar: is there a reason that anyone can update any fpga recored even if they dont own it or are not admins https://github.com/openstack/cyborg/blob/master/cyborg/common/policy.py#L119-L121
23:03:16 sean-k-mooney becaue ^ seams like a bug
23:04:35 Sundar sean-k-mooney: We got some holdovers from previous releases. We need to scrub all these policies for sure.
23:04:43 sean-k-mooney the same issue is there for the deployable program endpoint.
23:05:06 sean-k-mooney Sundar: ok as long as you are aware but that is something that shoudl be backported
23:05:30 sean-k-mooney normally you would not backport that kind of change but in this case i think its needed
23:05:43 Sundar Backport to v1 API?
23:06:20 sean-k-mooney Sundar: yes that would almost qualify for a revert in my book if you had not already released it
23:06:24 Sundar I need to get my head around how these rules interact with API versions
23:07:08 sean-k-mooney normally it would be a microverion bump
23:08:29 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Support old & new versions of svm and vmx traits https://review.opendev.org/660515
23:32:20 Sundar mriedem, sean-k-mooney: Re. earlier discussion today on https://review.opendev.org/#/c/603955/ , yes, I haven't updated the spec, mainly because I have been trying to understand the implications of moving the bind to compute, etc.
23:32:39 Sundar I will shortly update the spec.
#openstack-nova - 2019-05-23
00:25:33 openstackgerrit Brin Zhang proposed openstack/python-novaclient master: Set the lower limit of api_version for volume_type https://review.opendev.org/660861
01:07:58 openstackgerrit Jake Yip proposed openstack/nova master: refactor nova-manage archive_deleted_rows https://review.opendev.org/643779
01:08:21 openstackgerrit Jake Yip proposed openstack/nova master: Add --before to nova-manage db archive_deleted_rows https://review.opendev.org/556751
02:06:59 openstackgerrit Merged openstack/nova stable/stein: Restore connection_info after live migration rollback https://review.opendev.org/660370
02:48:23 openstackgerrit Merged openstack/nova stable/rocky: xenapi/agent: Change openssl error handling https://review.opendev.org/656307
03:13:35 openstackgerrit Merged openstack/python-novaclient master: Allow passing negative values for the locked search_opt in cs.servers.list https://review.opendev.org/659783
04:28:37 openstackgerrit Merged openstack/nova stable/stein: libvirt: Do not reraise DiskNotFound exceptions during resize https://review.opendev.org/660361
05:49:19 openstackgerrit Arthur Dayne proposed openstack/nova stable/rocky: Add the missing ' in routes.py https://review.opendev.org/660885
06:38:35 ileixe Hi forks.
06:40:08 ileixe I got an simple test using cpu pinning lately, and the result is somewhat unexpected. So if you are experince in the same environment, please let me know what's wrong.
06:41:11 ileixe My test is that VMs with cpu pinning host can interfere affect to each other.
06:42:45 ileixe I assume that VM with CPU pinning can achieve their own workload though, but the fact is If nosiy VM (which is also CPU pinned) is there they affect to each other.
07:09:38 openstackgerrit Merged openstack/nova stable/stein: Log when port resource is leaked during port delete https://review.opendev.org/657581
07:30:42 openstackgerrit Merged openstack/nova stable/stein: Include all network devices in nova diagnostics https://review.opendev.org/657125
07:30:55 openstackgerrit Merged openstack/nova master: Update description of valid whitelist for non-admin user https://review.opendev.org/642403
07:34:07 openstackgerrit Hamdy Khader proposed openstack/os-vif master: OVS DPDK port representors support https://review.opendev.org/658786
07:37:45 openstackgerrit Alexandre arents proposed openstack/nova master: Fix live-migration when glance image deleted https://review.opendev.org/659054
07:43:05 openstackgerrit Merged openstack/nova master: Skip existing VMs when hosts apply force_config_drive https://review.opendev.org/659703
07:44:42 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Skip existing VMs when hosts apply force_config_drive https://review.opendev.org/660914
07:45:08 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Skip existing VMs when hosts apply force_config_drive https://review.opendev.org/660915
07:45:26 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Skip existing VMs when hosts apply force_config_drive https://review.opendev.org/660917
08:05:00 alex_xu ileixe: what kind of nosiy you pointed to?
08:05:13 ileixe CPU load
08:05:24 ileixe alex_xu: I used stress and ssl encryption
08:05:32 ileixe tool called 'stress'
08:08:07 alex_xu ileixe: the vcpu and pcpu is 1:1 pinning, but in the same cpu socket, they still share cpu cache
08:08:50 ileixe I made them to be separated by using cpu_thread_policy
08:08:59 ileixe to 'require'
08:09:17 ileixe so I think no VMs share physical core for the test environment.

Earlier   Later