| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-11 | |||
| 06:03:17 | gmann | line 57 | |
| 06:03:33 | gmann | 1. Servers Ips non-unique network names | |
| 06:03:54 | gmann | spec update is merged last week. #link https://review.openstack.org/#/c/558125/ | |
| 06:05:27 | gmann | Maciej Kucia started code also but month back | |
| 06:06:07 | jichen_ | Is there code patch ? I only saw a doc patch | |
| 06:06:17 | gmann | i do not irc nick and changes should be straight forwards. if no updated since week, may be i can update the code for this BP | |
| 06:06:38 | gmann | yea, that patch only. in same patch code needs to be updated. | |
| 06:06:57 | gmann | i will check with Maciej about progress. | |
| 06:07:04 | gmann | 2.Abort live migration in queued state: | |
| 06:07:04 | jichen_ | ok, got it | |
| 06:07:41 | gmann | this is from Kevin_Zheng and i think good to review from us. i have added this in my today list. | |
| 06:08:23 | Kevin_Zheng | I got a question about this one | |
| 06:08:28 | gmann | Kevin_Zheng: anything you want to discuss on this then review | |
| 06:08:28 | Kevin_Zheng | API related | |
| 06:08:37 | gmann | yeah go head | |
| 06:08:49 | Kevin_Zheng | in the patch, I have a rpc version check | |
| 06:09:18 | Kevin_Zheng | like if the compute can do 5.1 then it can abort migration in queued status | |
| 06:09:23 | Kevin_Zheng | if cannot do 5.1 | |
| 06:09:33 | Kevin_Zheng | then I trough an exception | |
| 06:09:50 | Kevin_Zheng | my question is, should I mention that compute is not new enoguh? | |
| 06:09:53 | Kevin_Zheng | enough | |
| 06:10:13 | gmann | you mean this - | |
| 06:10:15 | gmann | #link https://review.openstack.org/#/c/568542 | |
| 06:10:18 | Kevin_Zheng | will that be too much admin details for normal user? | |
| 06:10:57 | Kevin_Zheng | yeah | |
| 06:11:10 | Kevin_Zheng | if it is like what I did in the current patch | |
| 06:11:57 | Kevin_Zheng | it seems a little wierd, as an user I requested 2.64 and then nova replied to me that migration is not in correct status | |
| 06:11:58 | alex_xu | I think we have some example in the before | |
| 06:12:23 | Kevin_Zheng | seems not correct with the mircorversion | |
| 06:12:34 | gmann | yeah i am searching for that | |
| 06:12:50 | Kevin_Zheng | Yeah, we have some, yikun is also working on one with this kind of server version check | |
| 06:13:18 | Kevin_Zheng | just wondering if it is good to let normal user know that some of the node is not new enough | |
| 06:13:39 | yikun | ^ https://review.openstack.org/#/c/567534/30/nova/api/openstack/compute/server_groups.py@190 | |
| 06:13:40 | gmann | this one - | |
| 06:13:42 | gmann | #link https://github.com/openstack/nova/blob/d3fa585f5e2d11a91ee62744a0cf0c78921a47e4/nova/compute/api.py#L1033 | |
| 06:14:24 | gmann | you can add new exception like this - #link https://github.com/openstack/nova/blob/c8b93fa2493dce82ef4c0b1e7a503ba9b81c2e86/nova/exception.py#L2294 | |
| 06:14:55 | Kevin_Zheng | hmm that seems better | |
| 06:15:21 | Kevin_Zheng | Yikun, maybe you should do something similar? | |
| 06:15:23 | yikun | yeah, so we should NOT expose something like "all compute services needs upgrade to Rocky" | |
| 06:15:27 | gmann | Kevin_Zheng: we will tell node is old we will just say this feature not supported so that user will contact admin for details | |
| 06:15:28 | Kevin_Zheng | yeah | |
| 06:15:34 | alex_xu | also this one #link https://github.com/openstack/nova/blob/stable/ocata/nova/compute/rpcapi.py#L1114 | |
| 06:15:53 | Kevin_Zheng | maybe the version thing should be appare in the log? | |
| 06:15:57 | gmann | yeah crash dump one alaos | |
| 06:16:07 | gmann | Kevin_Zheng: i think no. | |
| 06:17:07 | Kevin_Zheng | why not, seems better for operators | |
| 06:17:52 | jichen | yes, logs are only viewable to operators... | |
| 06:17:55 | alex_xu | why we didn't check service version instead of rpc version? | |
| 06:18:09 | Kevin_Zheng | they are different cases | |
| 06:18:17 | gmann | for which case | |
| 06:18:20 | Kevin_Zheng | yikun's case we check service version | |
| 06:18:27 | Kevin_Zheng | my case check for rpc version | |
| 06:18:40 | Kevin_Zheng | for log, I mean both version | |
| 06:18:44 | Kevin_Zheng | both case | |
| 06:19:35 | gmann | but operator knows features support from reno and microversions info. | |
| 06:19:47 | alex_xu | Kevin_Zheng: I mean your case can be done by the service version check also? | |
| 06:21:39 | Kevin_Zheng | yeah, but this way is similar, I also did some negotiation in rpc | |
| 06:21:43 | gmann | alex_xu: you mean in compute.api.py only like thrust certificate | |
| 06:22:02 | alex_xu | gmann: yea | |
| 06:22:34 | gmann | ok, that seems better for me too | |
| 06:22:41 | alex_xu | we can stop the API early, and it is more clear in the code | |
| 06:22:45 | Kevin_Zheng | I don't think so | |
| 06:23:05 | Kevin_Zheng | it is not the same with the certificate one | |
| 06:23:24 | Kevin_Zheng | my patch is depend on the migration status | |
| 06:23:31 | Kevin_Zheng | and it changes | |
| 06:23:53 | Kevin_Zheng | maybe when we check at api, it is not running | |
| 06:24:13 | Kevin_Zheng | but if we check again at rpc, which is the last step before we go to compute | |
| 06:24:22 | Kevin_Zheng | it changed to running | |
| 06:24:34 | Kevin_Zheng | and the API call will be success | |
| 06:25:02 | Kevin_Zheng | it is not like certificate that if it is not supported, it will be always not supported | |
| 06:25:43 | alex_xu | that is very short window... | |
| 06:26:27 | alex_xu | I just feel the rpc version check is very low level. we should have consistent check by the service version in the future. | |
| 06:26:55 | Kevin_Zheng | also | |
| 06:27:06 | Kevin_Zheng | Dan have a comment about this in | |
| 06:27:34 | Kevin_Zheng | https://review.openstack.org/#/c/568542/15/nova/compute/rpcapi.py | |
| 06:28:19 | alex_xu | ah, sounds like similar question, I will read it | |
| 06:28:53 | alex_xu | I think we can move on, continue this discussion on the patch | |
| 06:29:01 | Kevin_Zheng | NP | |
| 06:29:28 | gmann | yeah, let's have discussion on patch and what dansmith is saying. | |
| 06:29:33 | gmann | let's move next | |
| 06:29:48 | gmann | 3. Complex anti-affinity policies: | |
| 06:29:58 | gmann | #link https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged) | |
| 06:30:18 | gmann | this if yikun is working and seems good amount of review | |
| 06:31:06 | gmann | during discussion on falt vs dict representation of policy, REST API response is changing here than what was approved ins epc | |
| 06:31:11 | gmann | which seem better way | |
| 06:31:35 | gmann | #link https://review.openstack.org/#/c/567534/ | |
| 06:31:52 | gmann | my concern is to make the same for reqeust also | |
| 06:32:23 | yikun | yeah, and some question we have: | |
| 06:32:24 | gmann | yikun: any objection on that ^^ and alex_xu what you say about new format of 'policy' in request and response | |
| 06:32:35 | yikun | 1. should we change api response and req to flat policy? | |
| 06:32:38 | yikun | https://review.openstack.org/#/c/546925/18/specs/rocky/approved/complex-anti-affinity-policies.rst@130 | |
| 06:33:30 | yikun | 2. if we change these to flat, should we change to policy_* | |
| 06:33:31 | gmann | i am fine for changing in both. | |
| 06:34:03 | gmann | #link https://review.openstack.org/#/c/563401/28/nova/notifications/objects/server_group.py@41 | |
| 06:34:16 | gmann | ^^ this is original discussion | |
| 06:35:08 | gmann | for me flat representation in both request and response with policy_name as string, policy_rules as dict seems good idea | |
| 06:35:24 | yikun | flat vs nest example in here: http://paste.openstack.org/show/725526/ | |
| 06:35:25 | alex_xu | I need to read those discussion | |
| 06:35:33 | gmann | sure, | |
| 06:36:00 | gmann | plan is once we get agreement on thsoe, then yikun can update the spec also to reflect those changes | |