Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-10
15:37:17 sean-k-mooney if the host is not in there set
15:37:21 stephenfin right, but it didn't before
15:37:23 sean-k-mooney well assuming your using it
15:37:25 stephenfin so that's a change in behavior
15:37:38 gmann or by bribing the system user :)
15:37:39 stephenfin ergo, what do we respond with and does this need a microversion
15:37:52 sean-k-mooney stephenfin: not the aggreate tenatn isolation fitler or placment version would block the boot if isolatio was configured
15:38:10 stephenfin but not if it wasn't
15:38:18 sean-k-mooney correct
15:38:24 gmann for non isolated cloud, it is change in behavior
15:38:40 sean-k-mooney if it was not then even as a normal user you can guess the host by using the AZ:host syntax
15:39:02 sean-k-mooney i dont think we need to do the check on server create
15:39:14 sean-k-mooney we should leave that up to placment/the schduler fileters
15:39:29 sean-k-mooney for /os-hyperviors we shoudl check
15:39:57 gmann but for non isolated cloud, anyone can boot on host if they know host name?
15:40:09 sean-k-mooney with an az yes
15:40:35 sean-k-mooney you can jsut do --avaiablity-zone $az_name:$hostname
15:40:37 gmann but we are restricting in list hypervisors, do not return if no tenant isolation
15:40:50 sean-k-mooney i think --host is admin only?
15:41:18 sean-k-mooney gmann: i was originally suggeting returning all hyperviors if no isolation for what it worth
15:41:43 gmann yeah but with current discussion it seem that is too much info
15:42:13 sean-k-mooney ya it seams to have pivioted
15:42:22 stephenfin sean-k-mooney: '--hypervisor-hostname' is project-admin scoped https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L217
15:42:31 sean-k-mooney my view on this is its the admins choice to grant project admin to a tenant
15:42:48 gmann IMO, if we restrict hypervisor list then we should do the same for boot instance also otherwise we are opening a loop hole in our API
15:42:53 sean-k-mooney so if they care about restircting the view they shoudl configure isolation
15:42:58 sean-k-mooney if they dont then they dont
15:43:18 sean-k-mooney gmann: we are restricting the hypervior list using the schduler metadta
15:43:37 sean-k-mooney gmann: so if you have isolation configured you get it for free
15:43:45 gmann sean-k-mooney: and what we discussed now is restrict if no tenant isolcation too
15:43:45 stephenfin can we defer this to Xena?
15:44:01 stephenfin this is starting to feel like it warrants its own spec
15:44:09 sean-k-mooney yep so we should keep the consitent
15:44:09 gmann yeah may be we should.
15:44:21 gmann and let discuss in PTG on all cases
15:44:26 stephenfin given the security implications and discussion around API changes
15:44:30 sean-k-mooney either restic both or dont
15:44:32 stephenfin *changes to other APIs
15:44:44 sean-k-mooney when no isolation is configured for the tenant
15:44:56 gmann and we can discuss host info in GET server also for such project admin
15:45:03 stephenfin yeah, I'm in favour of the same behavior for both listing hypervisors and creating servers on a particular hypervisor
15:45:20 gmann yeah, same behavior is needed whatever we agreed to
15:45:24 sean-k-mooney gmann: getting hypervior_hostname is proably valid if you can do the hypervior list
15:46:02 gmann yeah, and i think we return that in PUT/REBUILD server API also which also we can discuss
15:46:48 sean-k-mooney it basicaly come down too this. show project admins be aware of the hypervior that there vms can run on
15:46:53 gmann so 1. we can update the current spec to remove the policy change 2create new spec for Xena and discuss in PTG ?
15:46:55 sean-k-mooney if yes then it should see it on all apis
15:47:05 sean-k-mooney where its relevent
15:48:01 gmann gibi: sean-k-mooney stephenfin ^^ hope it is ok to update spec at this stage as this is to remove the things we agreed to do
15:48:02 sean-k-mooney and then there is the quetion of if it should require tenatn isolation or not
15:48:08 gmann not on adding anything new
15:48:27 sean-k-mooney gmann: we can update specs at any time to reflect reality
15:48:38 stephenfin gmann: Yeah, I'll update the spec and add an item to the PTG to discuss this
15:48:49 gmann +1, thanks
15:48:50 sean-k-mooney gmann: this wont get moved into implemneted anyway
15:49:00 gmann sean-k-mooney: oh why?
15:49:03 gibi gmann: yeah, spec update and a new spec is OK to me
15:49:15 sean-k-mooney gmann: well its not done right
15:49:18 gmann stephenfin:gibi sean-k-mooney i can create the new xena spec for PTG
15:49:24 gibi gmann: thanks
15:49:28 stephenfin thanks
15:49:39 sean-k-mooney or is enough of the spec done to mark the wallby one as implemented?
15:49:55 gibi gmann: and If no discussion happens until the PTG on the spec then I suggest to raise this topic on the PTG too
15:49:59 gmann sean-k-mooney: actually that is some special case we want to handle in that spec otherwise original spec of 'standardize the hypervisor API' is done
15:50:09 gmann gibi: ack, make sense
15:50:14 sean-k-mooney oh its part of that
15:50:17 sean-k-mooney sorry ya
15:50:30 gibi sean-k-mooney: I put the os-hypervisor API moderinzation bp to implemented as I got from stephenfin that the policy part is just a nice to have
15:50:33 sean-k-mooney so that spec can move to implmetned and then xena one for the edgecase
15:50:45 gmann yeah
15:50:49 sean-k-mooney cool
15:51:46 gibi OK, we are in wild agreement
15:52:30 sean-k-mooney it would appear so. its funny how that often looks liek an argument :)
16:00:36 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Remove policy changes from modernize-os-hypervisors-api spec https://review.opendev.org/c/openstack/nova-specs/+/779821
16:00:59 stephenfin gmann, gibi: ^
16:01:04 stephenfin also added to the PTG doc
16:02:27 gibi stephenfin: on it
16:02:30 gibi and thanks
16:18:19 gmann stephenfin: thanks, lgtm
16:38:48 openstackgerrit Merged openstack/nova-specs master: Remove policy changes from modernize-os-hypervisors-api spec https://review.opendev.org/c/openstack/nova-specs/+/779821
16:55:59 dansmith bauzas: I never saw any replies to my comments on the rpc bump patch
16:56:08 dansmith bauzas: did you not notice, or just think they were all stupid? :)
16:56:12 bauzas dansmith: I forgot to look at it, my bad.
16:56:18 dansmith okay
16:56:27 bauzas dansmith: but I quickly saw them
16:56:32 bauzas reviews ftw atm
16:56:39 dansmith okay none of them are critical obviously
16:56:49 bauzas dansmith: I can look at them now while you're on
16:57:06 bauzas (at least once my weekly meeting is done)
16:57:27 dansmith okay
17:09:34 stephenfin gmann: Any chance you could take a look at https://review.opendev.org/c/openstack/nova/+/778550 ?
17:09:56 stephenfin It's pretty late in the day, but it's a fairly simple microversion
17:12:03 gmann stephenfin: sure, I will check, may be tomorrow I have to go out today after noon.
17:12:15 stephenfin sweet, thanks :)
17:22:07 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Rename 'parameter_types.hostname' -> 'fqdn' https://review.opendev.org/c/openstack/nova/+/778549
17:22:09 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add support for 'hostname' parameter https://review.opendev.org/c/openstack/nova/+/778550
17:28:47 stephenfin sean-k-mooney: okay, got to the end of the series. I see what you mean about patch ordering
17:29:01 stephenfin are you working on that series rn?
17:30:14 sean-k-mooney not yet but soon
17:30:25 sean-k-mooney im going to move the neutorn port one now

Earlier   Later