Earlier  
Posted Nick Remark
#openstack-nova - 2018-07-11
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
06:36:34 gmann yikun: anything else you want to discuss or we cna move next
06:37:20 alex_xu yikun: for "rules": {"max_server_per_host": 3}, do you mean "rules": "{"max_server_per_host": 3}"
06:37:29 alex_xu the value of rules is a string?
06:37:57 alex_xu yikun: sorry, I missed understand that, just ignore me
06:38:46 yikun don't worry, you could take a look on example http://paste.openstack.org/show/725526/
06:39:17 yikun gmann: only these 2 questions for me. :)
06:39:39 gmann flat2 should have policy_rules than rules_name
06:39:48 gmann like you doing in gerrit
06:40:37 yikun ha,yeah, typo
06:40:46 gmann ok
06:41:35 gmann alex_xu: you want to reply on patch. and we move next ?
06:41:40 yikun http://paste.openstack.org/show/725528/
06:41:46 yikun new one
06:41:48 alex_xu gmann: yea, I will try to review the patch first

Earlier   Later