Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-10
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
17:30:32 sean-k-mooney on top of artom change
17:30:38 sean-k-mooney then go back to vdpa
17:31:32 sean-k-mooney gibi: o/ enjoy your evening
17:32:02 stephenfin cool, mind if I take a quick swing at it?
17:32:12 stephenfin I think I know what you're going for
17:32:21 sean-k-mooney if you want go for it
17:33:23 sean-k-mooney i tried to break it out at first to be logicly split but then i found later when i got the real hardware i need to fix some thing and some of those fixed end in the last patch
17:33:37 sean-k-mooney i would like to bring those fix to the correct patch
17:38:06 bauzas dansmith: okay, I looked at all your comments and thanks for them
17:38:31 bauzas dansmith: you made a great point, which is I made extra work for free when trying to continue to support 5.0
17:38:35 bauzas instead of 5.12
17:38:58 dansmith bauzas: well, not "for free", it clearly cost you something :D
17:39:14 bauzas dansmith: I probably misunderstood that we were pinning to the least supported version from all computes, which is *not* 5.0
17:39:16 dansmith (but I know what you mean)
17:39:43 dansmith bauzas: well, I think you aren't able to faithfully support 5.0 anyway, was my point
17:39:56 bauzas yeah
17:40:22 bauzas the point is, we're entering the RC period and touching my change for removing stuff could require me some further work
17:40:52 bauzas so maybe let's just pretend we can support 5.0, which is impossible anyway
17:41:01 dansmith yes, although this is pretty much the time to be doing that
17:41:04 dansmith but as you wish
17:41:28 bauzas I'll first reply to the other comments and do a quick respin
17:41:37 dansmith ack
17:41:39 bauzas and if we have time, I can look at removing the unnecessary bits
17:42:01 bauzas which should simplify my change
17:42:09 bauzas but here, baby steps
17:42:17 bauzas to secure the RPC bump anyway
17:42:34 dansmith sounds good
17:43:48 sean-k-mooney dansmith: since your here and talking about this topic
17:44:00 sean-k-mooney dansmith: when can we do ovo major version bumps

Earlier   Later