| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-10 | |||
| 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 | |
| 17:44:11 | dansmith | you guys talking about me being here now makes me sad :/ | |
| 17:44:26 | sean-k-mooney | do they have to align with RPC bumps or not | |
| 17:44:31 | dansmith | they do not | |
| 17:44:40 | sean-k-mooney | well it was actully a time zone reference not avaiablity | |
| 17:44:47 | dansmith | I did an instance bump long ago, let me show you my scars... | |
| 17:45:15 | dansmith | but if you find that it should be a good map of how to do it for the worst case, and the newer backport manifest stuff likely makes it easier nowadays | |
| 17:45:36 | sean-k-mooney | ok that is fine so we have a few comment for some other objects like the compute_node object to do X i 2.0 | |
| 17:45:46 | bauzas | I remember the instance major bump pain | |
| 17:46:05 | dansmith | instance is like the worst case though, compute node is probably easier since we don't pass it around everywhere | |
| 17:46:32 | bauzas | good point, but still something difficult | |
| 17:46:32 | sean-k-mooney | ya i was more wondering what the rules were around it | |
| 17:46:50 | bauzas | sean-k-mooney: the idea is, you have to understand which services are using the object | |
| 17:46:54 | bauzas | and which version of it | |
| 17:47:19 | sean-k-mooney | yep we can check what the max version is supproted on the dest right | |
| 17:47:26 | sean-k-mooney | and then we backlevel before sending | |
| 17:47:27 | bauzas | it's not just the compute | |
| 17:47:34 | dansmith | sean-k-mooney: the rules are similar to the rpc interface, but you have to be able to support both version of the object across the boundary.. compute has to support the 1.x object in case another compute sends it (although likely not the case for compute_node), | |
| 17:47:38 | bauzas | or the object being passed over the wire | |
| 17:47:39 | dansmith | and of course conductor has to be able to support both | |
| 17:48:04 | bauzas | and other services also have to understand the new minimum version | |