Tuesday, 2016-01-05

*** Qiming has joined #senlin00:25
*** pratikmallya has joined #senlin00:43
*** pratikmallya has quit IRC00:48
*** Liuqing has joined #senlin01:37
*** pratikmallya has joined #senlin01:41
openstackgerritMerged openstack/senlin-dashboard: Use the defined INDEX_URL in clusters forms and views  https://review.openstack.org/26199501:50
*** elynn has joined #senlin01:59
*** elynn has quit IRC02:03
*** elynn has joined #senlin02:04
*** pratikmallya has quit IRC02:06
elynnJust saw my patch for opensdk got an -2 from Brian...02:12
openstackgerritCindia-blue proposed openstack/senlin: Add DB API to Help Health Check in Scaling Policy  https://review.openstack.org/26270902:12
*** Yanyanhu has joined #senlin02:17
Yanyanhuhi, Qiming, will check those patches and bugs about policy and lb02:19
QimingYanyanhu, pls check the trust id patch02:22
QimingI'm not quite sure whether trust id should be a list02:23
Yanyanhuyes, me too, I'm checking it now02:23
Yanyanhuhi, junxu, are you around?02:39
Yanyanhujust tried to reproduce this bug you reported https://bugs.launchpad.net/senlin/+bug/153050402:39
openstackLaunchpad bug 1530504 in senlin "Class Policy's _build_conn_params method return wrong value" [Undecided,New]02:39
Yanyanhubut didn't see error happen02:39
YanyanhuI think trust_id list is accepetable for openstacksdk02:40
junxuMaybe it has problem for kilo keystone02:46
Yanyanhuanother possibility is the error will happen when the length of trust_id list is larger than one02:48
Yanyanhucan you print the params that generated by build_conn_param to check it?02:49
junxujust one trust_id02:49
Yanyanhuhmm, maybe the env issue02:50
Yanyanhumaybe you can update your keystone version and test it again02:51
Yanyanhuanyway, the bahvior of _build_conn_param in profile/base.py and policy/base.py are different, we may need a fix here02:53
Yanyanhuafter we find the exact reason of bug153050402:54
junxuok thanks02:59
Yanyanhujunxu, so I think you can keep patch 262941 and use it for this fix after completing the test of trust_id param03:02
*** Qiming has quit IRC03:21
*** Qiming has joined #senlin03:41
*** elynn has quit IRC04:15
openstackgerritzhangguoqing proposed openstack/senlin: doc: fix cluster  https://review.openstack.org/26355504:28
openstackgerritxu-haiwei proposed openstack/senlin: Fix KeyError caused by getting 'security_groups' from server_data  https://review.openstack.org/26355805:04
*** Liuqing has quit IRC05:05
*** Liuqing has joined #senlin05:06
*** elynn has joined #senlin05:12
openstackgerritMerged openstack/senlin: Remove some useless db apis  https://review.openstack.org/26316305:44
*** Liuqing has quit IRC05:51
junxuHi all, to get all cluster, which request is correct, Get /v1/d3d2f1bc367c493fa5649fd377440c8b/clusters or GET /v1/dclusters? When I uses the latest python-senlinclient which request is like /v1/d3d2f1bc367c493fa5649fd377440c8b/clusters, then return a 404.06:07
openstackgerritCindia-blue proposed openstack/senlin: Add DB API to Help Health Check in Scaling Policy  https://review.openstack.org/26270906:12
xuhaiweijunxu, i think the latter one is right06:13
junxuno need project_id ?06:15
openstackgerritCindia-blue proposed openstack/senlin: Add DB API to Help Health Check in Scaling Policy  https://review.openstack.org/26270906:21
junxuThanks xuhaiwei!06:21
xuhaiweiyou are welcome06:24
Qimingjunxu, we may release a new version of python-senlinclient soon06:38
Qimingif you are downloading the "latest" version from Pypi, there will be some compatibility problems06:38
openstackgerritMerged openstack/python-senlinclient: Deprecated tox -downloadcache option removed  https://review.openstack.org/25671406:48
openstackgerritMerged openstack/senlin: Add DB API to Help Health Check in Scaling Policy  https://review.openstack.org/26270906:50
openstackgerritMerged openstack/senlin: doc: fix cluster  https://review.openstack.org/26355506:50
openstackgerritYanyan Hu proposed openstack/senlin: Add metadata updating support for os.nova.server profile  https://review.openstack.org/26265806:55
openstackgerritYanyan Hu proposed openstack/senlin: Remove webhook functional test  https://review.openstack.org/26359707:10
openstackgerritxu-haiwei proposed openstack/senlin: Add zones property to deletion policy template  https://review.openstack.org/26360807:36
openstackgerritMerged openstack/senlin: Remove webhook functional test  https://review.openstack.org/26359707:37
Qimingxuhaiwei, there?07:43
Qiminghi, we need a discussion about the deletion regarding cross-az and regions07:44
Qiminglixinhui, online?07:45
xuhaiweiI have thought this for a while07:45
Qimingyes, thanks for working on this thread07:45
Qiminglixinhui, since you were involved in cross-az/region placement policy07:46
Qimingwant to hear your opinions as well07:46
Qimingthe problem is that we have placement policy for cross-az and cross-region07:46
lixinhuiokay, Qiming and Haiwei. I would like to join this discussion07:47
xuhaiweiby the way I have tested placement policy for zones, it works fine07:47
xuhaiweicurrently I have no idea for cross-region07:47
Qimingthey can be treated as some builtin policies, users can replace them whenever they want07:47
Qiminghowever, we still need to make the policies work in an elegant manner07:48
xuhaiweiyou mean that will be a new policy?07:48
xuhaiweior part of deletion policy?07:48
Qimingxuhaiwei, that is something we need to investigate07:48
lixinhuican we resue the logic in placement07:49
xuhaiweiwhat about sharing my idea firstly?07:49
QimingI can see that you are trying to make cross-az factors part of deletion policy07:49
Qimingwe need to think about how placement policy and deletion policy work together07:49
xuhaiweiyes, indeed, I found a problem about them07:50
lixinhuiI aggree07:50
Qimingcurrently, placement policy is only about node creation07:50
Qimingso ... it is incomplete07:50
lixinhuiyes, Qiming07:50
Qimingit cannot guarantee nodes are always spread as expected07:50
xuhaiweiI dont understand you07:50
lixinhuiWe need logic to node deletion07:51
Qimingwe need to consider node delete cases as well07:51
lixinhuiI mean to consider ranking nodes to find which one to remove for better balance07:51
Qimingsay ... we have a placement policy {'az1': 100, 'az2': 50}07:51
Qimingwe are doing/enforcing this when creating nodes07:52
xuhaiweibecause we inpurt 'placement' into node data, it seems ok to get information needed to do node deletion07:52
Qimingbu when deleting nodes, we are not considering this distribution07:52
xuhaiweiI am considering this, Qiming07:52
Qimingbut if we have a deletion policy which says {'az1': 100, 'az2': 100}07:53
xuhaiweiit seems not difficult to solve this problem07:53
xuhaiweiok, go on07:53
xuhaiweiI'd better to listen to you first07:53
lixinhuiQiming, go on07:53
Qimingso ... I'm considering whether we should extend the placement policy to be a policy that is checked both before node creation and node deletion07:54
Qimingno one said that placement can be only checked before node creation07:54
Qimingit is a half-baked solution, though it works fine for node creation (a million thanks for testing this btw)07:55
lixinhuiI think it is reasonable to provide recommendation based on placment ranks07:56
xuhaiweibut checking after node deletion is deletion policy's work, isn't  it?07:56
Qimingjust some gut feeling07:56
Qimingdeletion policy will have its opinion too, that is for sure07:56
lixinhuixuhaiwei, I think deletion can not know what is right ranks07:56
Qimingso ... if you only have a placement policy attached to a cluster07:57
xuhaiweiwe can set the weight in deletion policy template, lixinhui07:57
lixinhuiplacement policy is the place for users to define the rank criteria07:57
Qimingyou can always guarantee that nodes are spreaded among AZs as expected07:57
xuhaiweithat is not enough?07:57
Qimingif you have deletion policy as well, it can further refine the list of candidates, but from a different perspective07:58
Qimingmy primary intent is to first make each policy self-contained08:00
Qimingeach policy should achieve its goal without having to consider other policies08:00
Qimingthen we handle conflicts between policies, define rules that are easy for users to understand08:01
xuhaiweiabout deletion policy for cross-zones, my idea is: we check deletion policy template first to see if 'zones' are provided, it not, do as usual, if it is, then we divide nodes into different zones, and then get a dict like {'az1': ['node1', 'node3'], 'az2': ['node2']}, then we get the weight of each zone and calculate delete how many node from each zones, and finally use other rules like 'old_first' to delete the nodes08:02
Qimingyes, xuhaiwei, that is the logic08:03
QimingI agree08:03
xuhaiweiif we do like this, there seems no conflict with other policies08:03
Qimingmy question is whether we should move the generation of dict to placement policy08:03
xuhaiweiI think we should do it in deletion policy08:04
xuhaiweithere is a problem that is not every node containing the 'placement' data08:05
Qimingif we put it in deletion policy, there are two drawbacks08:05
lixinhuicurrently, the target for placmenet to bond is only scale-out08:05
xuhaiweiif the node is not created by placement policy, it does not have that data08:05
lixinhuiwe can extend it with scale-in08:05
Qimingyes, xuhaiwei, that is why we should consider cross-az distribution in placement policy08:06
Qimingif you don't have a placment policy, you don't have placement data08:06
xuhaiweiit makes sense to me08:06
xuhaiweibut it seems difficult to do it in placement policy08:07
xuhaiweiwe can't manage all the nodes while just placing some of them08:08
Qimingif we consider scale-in (and/or resize) in placement policy, we can always ensure how nodes are distributed, no matter we have a deletion policy or not08:08
Qimingxuhaiwei, that is a problem for users to consider08:09
Qimingsay you have a cluster of 10 nodes already created08:09
Qimingnow you attach a placement policy to it08:09
Qimingwe won't move your nodes around08:09
Qimingif you want a full control of your nodes inside a cluster08:10
Qimingcreate an empty one, attach a placement policy08:10
Qimingthen resize/scale it08:10
xuhaiweiI am afraid some people may only use deletion policy without using placement policy08:11
Qimingthat is fine08:11
Qimingif you are using deletion policy only08:11
Qimingyou are not worrying about node placement08:11
Qimingyou cannot guarantee node distribution by only attach a deletion policy08:12
lixinhuii think we would need explaination in doc about these differences08:13
xuhaiweiplacement policy will be used by 'scale-out' and 'resize'?08:14
Qimingwe will need a section about using senlin with policies08:14
Qimingwe need to guide users through how auto-scaling can be achieved, auto-healing, and cross-az/region distribution etc.08:15
Qimingxuhaiwei, ideally, yes08:15
openstackgerritQiming Teng proposed openstack/senlin: Add 'wait_for_delete' call for functional tests  https://review.openstack.org/26303808:16
xuhaiweiso if user use 'node-join' and 'node-leave' or other actions to change the cluster size, placement policy can still handle it?08:16
QimingI'm expecting that node-join and node-leave won't be used in that scenario08:17
Qimingif you are expecting senlin to do a placement for you, why you are manually add/remove some specific nodes?08:17
Qimingif you do that, no one will stop you, :) it is one of the power you get from senlin08:18
QimingI mean, you can do whatever you want, :)08:18
xuhaiweiI am just thinking about some cases people will do, in my opinion, we should make senlin used as easy as possiple08:19
Qimingtotally agree08:19
xuhaiweiif we let placement policy do all the jobs, there are so many limits08:20
Qimingthen you don't attach placement policy08:21
Qimingsay you have 10 nodes in AZ1 and 4 nodes in AZ2, and the distribution you designed is 'AZ1': 100, 'AZ2': 5008:22
Qimingthe current distribution is acceptable08:22
Qimingyou can have 9 nodes in AZ1 and 5 in AZ2, it is also acceptable08:23
Qimingnow you, as an operator, do a node-join, adding a node from AZ108:23
Qimingwe cannot reject that08:23
Qimingwe don't know what the operator wants08:24
Qimingyou are getting a 11:4 distribution after the node-join08:24
Qimingbut it is fine08:24
Qimingnext time you do a resize or scale, the placement policy still works08:24
xuhaiweibut deletion policy will get wrong information in this case08:25
Qimingokay, got what you mean08:25
Qimingthat is a bug we need to fix08:25
Qimingwhen we add a new node to a cluster, we should assign a 'placement' node data automatically?08:26
xuhaiweithat is one solution08:26
xuhaiweibut if we want to do so much jobs, why not just leave them all to deletion policy?08:29
Qimingdeletion policy itself cannot guarantee placement08:30
Qimingjust like the current version of placement policy, which is a half-baked solution as well08:30
xuhaiweiit does not need to08:30
elynnHi Qiming08:35
elynnCluster_update can not work for now?08:35
Qimingelynn, don't know08:35
Qimingit is a big question08:36
Qimingit depends on what you are updating08:36
elynnIn my env, cluster create works well08:36
elynnjust update cluster name08:36
elynnAnd I got a not found error08:36
openstackgerritYanyan Hu proposed openstack/senlin: Set cluster to correct status when scaling failed  https://review.openstack.org/26363108:37
elynnCan you update cluster in latest codes?08:37
Qimingit works for me08:37
xuhaiweiyou are not using the latest source I think08:37
xuhaiweithe same to me08:37
elynnI think I'm using the latest codes... but openstacksdk is not latest08:38
Qiminghow old is your sdk code?08:39
Qimingthe recent change to sdk regarding keystoneauth must be there, or else everything breaks08:39
elynnLet me upgrade to 0.7.3 and have a try08:41
Qiming0.7.1 was created on 2015-11-2408:41
elynnok, now it works...08:42
Qimingkeystoneauth change was merged on 2015-11-2008:42
elynnNow I got a new error AttributeError: "'Proxy' object has no attribute 'cluster_resize'" ... I might install openstacksdk from codes...08:47
xuhaiweiQiming, about the topic we discussed, if make placement policy do zone information collection, the data will be stored where? in cluster property?08:47
lixinhuiin action.data08:51
lixinhuithe action should be mapped to one kind of cluster_actions08:52
Qimingelynn, please do08:52
Qimingcluster_resize was recently proposed and merged08:53
Yanyanhuelynn, me too, that's a bug I think08:54
xuhaiweilixihui, if put the data in action.data, how to get it when deleting nodes08:54
Yanyanhuoh, looks I need latest sdk code08:54
lixinhuixuhaiwei, which kind of action will be targeted by deletion policty08:55
lixinhuishould be what kinds of actions08:55
lixinhuito target08:55
lixinhuicluster_scale_in? cluster_node_del08:56
lixinhuior somethings like this08:56
elynnHi Qiming, Yanyanhu, Is it ok to seperate cluster profile update from cluster update?08:56
elynnAnd return action in response.08:57
elynnI see that now we only return cluster id from cluster update.08:57
Yanyanhuelynn, currently action will be returned when doing cluster update operation?08:57
Yanyanhulet me check the code08:58
xuhaiweiI think there is nothing related to action types, when we deleting nodes using cluster-scale-in, we may want to get the nodes' zone infor, so that infor should be in cluster.data I think08:58
Qimingelynn, we'd better make the response consistent08:58
Yanyanhumaybe action is not returned in all cases08:58
Qimingfeel free to propose patches to make them consistent08:58
openstackgerritQiming Teng proposed openstack/senlin: Remove some example policies  https://review.openstack.org/26364008:59
Yanyanhuyes, that's true, elynn, a dict will be returned08:59
elynnI can't find the action id for cluster profile id.08:59
xuhaiweilixinhui, because we don't know placement policy is triggered by which action, we just want the result08:59
Yanyanhuyou mena for cluster profile update?09:00
elynnfor cluster profile update09:00
elynnsorry typo09:00
Yanyanhuline 621 in service.py09:00
Yanyanhuthe action is there and you can get the action.id directly I think09:00
lixinhuixuhaiwei, I think that is just a problem brought by your solution09:01
elynnyes, I see it, but where should I return the action.id?09:01
lixinhuiof corse, you can do a complete contained the implments in deletion policy :)09:02
elynnI directly return cluster.to_dict() in L63109:02
Yanyanhuline 631 should be changed I think09:02
lixinhuixuhaiwei, what I am thinking is to composite all the fucntions togetehr - different policy focus on differnet logic09:02
Yanyanhuto include both cluster attr dict and action_id fields into the return value?09:03
openstackgerritQiming Teng proposed openstack/senlin: Move some policies into WIP directory  https://review.openstack.org/26364109:03
lixinhuixuhaiwei, and no logic dunplication09:03
elynnresp = cluster.to_dict(); resp.update({'action': action.id})?09:03
xuhaiweilixinhui, yes?09:03
elynnYanyanhu: That sounds good, and openstacksdk needs to modify too.09:03
elynnAdd a action_id for cluster resource in openstacksdk? or directly return dict back?09:04
Yanyanhuelynn, I think we need to check how sdk expects updating API to work09:04
elynnYanyanhu: It return a cluster class in opensdk.09:05
Yanyanhuwhether we have to return the resource attr dict within the resp body09:05
elynnBut cluster class won't handle 'action_id' return from senlin.09:05
Qimingelynn, have you read the comments to https://review.openstack.org/261970 ?09:06
Qimingit is not expected by sdk developers09:07
lixinhuixuhaiwei, I am just thinking, either way can realize the goal: placemnet to handle scale out/in and placment for scale-out / deletion for scale-in09:07
Qimingthey are still discussing that09:07
YanyanhuYes. Just feel we should make Senlin's update API behaves consistently with other services as much as possible?09:07
elynnQiming: Yes, That's my headcache...09:07
Qimingelynn, we have to wait09:07
lixinhuixuhaiwei but think if one persion want to revise the zone based weight09:07
Qimingwe have to try convince them that your patch is not disruptive09:07
Qimingit is the right thing to do09:07
lixinhuixuhaiwei, then the person will need to take care different places09:08
Qimingone thing we can do to straighten things from our side is to make cluster-update always return results in the same way09:09
YanyanhuQiming, I'm thinking elynn's suggestion, maybe we can seperate cluster profile update from cluster update?09:09
Qimingcurrently, we are returning very fast if the request is not about profile change09:09
Qimingso we may be returning results in different format09:10
Yanyanhuit looks like a 'version update'?09:10
elynnQiming: Even after patch #261970 merged, we still can't get action id.09:10
YanyanhuQiming, that is feasible09:11
Yanyanhuin senlin side. But could confuse sdk?09:11
Qimingwe should first make ourselves consistent09:11
Yanyanhuyes, agree09:12
Qimingthen we try convince sdk guys to accept the header return things09:12
elynnyes, you are right.09:12
Yanyanhuyes, actually cluster create also return a dict09:12
Qimingcluster update is about a PATCH request09:13
elynnLet me see if we can find some way both senlin and openstacksdk can accept.09:13
Yanyanhuyea, they are different09:13
Qimingfor an asynchronous update request, there is no guidelines, the above rules are only about async create09:15
Qiminganyway, we are referencing the guideline about async create when doing async update (PATCH)09:16
Qimingline 204 above says that a PATCH request should have a response body09:17
Yanyanhumaybe returning results in different format is right way to follow09:17
Qimingso we are returning the body (cluster.to_dict())09:17
Qimingline 105 says we should return a header, okay, we SHOULD return a 'location' header09:17
Yanyanhuat least before api-wg gives more guide09:17
Qimingso ...09:18
Qimingfor cluster-update09:18
Yanyanhuso we need a judgement there09:18
Yanyanhuin cluster_update service interface09:18
Qimingwe should always return a cluster in dict in body09:18
Qimingbecause it is a PATCH request09:18
Yanyanhuif action is created09:19
Yanyanhuwe return action_id with it09:19
Qimingwe are alwayus returning a 202 status_code09:19
Qimingthat means we should always return a 'location' header09:19
elynnYanyanhu: I agree, that's the first step. we include action_id in body and location point to cluster09:20
Qimingwhat we should do was actually recording there: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/service.py#n62609:20
YanyanhuQiming, yes, just currently, cluster rather than action 's location ref will be returned...09:21
Qimingwe should move all property update into the action body, we need to lock the cluster for such an update09:21
YanyanhuQiming, right09:22
Qimingin that way, we will be consistent about cluster-update operation, always return a cluster.to_dict() and always return an action id in 'location' header09:22
Yanyanhuwe should avoid this returning http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/service.py#n58809:22
elynnI'm a little confused.09:23
Yanyanhuhi, elynn, I think after fixing this issue, we can resolve this problem from senlin side09:23
elynnaction id should be in header?09:23
Qimingelynn, let me try restate what we need to do, step by step09:24
Qimingaccording to  http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/http.rst#n20409:24
Qimingwe should return a cluster dict in response body, okay, we are already doing that09:25
Qimingaccording to  http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/http.rst#n10509:25
Qimingwe should return a 'location' header when doing asynchronous update, though the guideline didn't explict say that09:26
Qimingfor async operations that return a 202 as status code, we should always return a 'location' header, I believe that is the right thing to do09:26
Qimingthe problems we have in senlin engine:09:27
Qiming1. we are doing a SYNC call sometimes, e.g. http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/service.py#n58809:27
Qimingif we are not updating profile, we are returning too fast, without even creating an action09:28
Qimingthis has been causing other problems noticed by haiwei before, so we have a comment left on line 62509:28
Qimingthis has to be changed09:28
Qimingwe should move all update operations into the action CLUSTER_UPDATE, instead of returning too early09:29
Qiming2. we are not returning action IDs no matter what fields you want to update09:29
Qimingsee line 63109:29
Qimingthis should be changed as well, we should add 'action' into the dict, then rewrite the response at API layer, move the action link to header09:30
elynnSo you mean we should create an action for cluster update?09:30
QimingALWAYS create an action09:30
Qimingthat is the consistency I'm talking about09:30
elynnno matter with or without profile09:31
elynnThen we return action id in location?09:31
elynnOh, I finally got what you mean T_T09:31
Qimingdon't cry09:32
elynnseems we don't need patch #26197009:32
elynnLet me thing through it again...09:33
elynnHave you notice what image resource do in openstacksdk?09:34
QimingI think I know what you want09:34
Qimingyou want to skip moving 'action' into header and back09:34
elynnthey directly add a location property09:34
Qimingthat works09:34
Qimingbut that is NOT the right thing to do09:35
Qimingyou will pay your debt eventually09:35
elynnok, I stick with you.09:36
QimingI believe sdk guys are reasonable people too09:37
Qimingwe can persuade them on this09:37
elynnyes, I think you can :)09:38
Qimingwe can09:38
elynnI can persuade them in chinese :P09:38
elynnI can work on update_action first if no one do it.09:42
Qimingokay, it is yours09:42
Qimingone suggestion for this patch09:43
Qimingyou may want to do it in two steps09:43
Qimingfirst augmenting the existing CLUSTER_UPDATE handling logic, where you will check if any properties other than 'profile_id' is specified09:44
Qimingmake the update works there09:44
Qimingthen you will remove the current properties update logic from engine service09:45
Qimingor else I can imagine how big a patch it would be09:45
Qimingif you consider the test cases you will need to add09:45
elynnThanks for the suggestion, I will keep in mind.09:46
Qimingyou may even further split it into smaller patches for easier review09:47
xuhaiweiok, the discussion is over?09:48
xuhaiweican we go on with the topic just now?09:48
Qimingplacement thing?09:49
Qimingor node distribution thing?09:49
xuhaiweiI have discussed with lixinhui privately just now, I found our ideas are totally different09:49
xuhaiweiin your opinion, Qiming, placement should collect the zone datas after placement is done?09:50
xuhaiweiand then store the data into somewhere?09:50
xuhaiweithen when deleting nodes, get that zone data and decide which node to delete09:51
*** elynn has quit IRC09:52
xuhaiweistore the data into cluster property?09:53
Qimingread the code here:09:53
Qimingwe create a placement plan and temporarily store the data into the current action09:54
Qimingthen we retrieve that plan here: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/cluster_action.py#n11409:54
Qimingstore the placement data into node data: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/cluster_action.py#n12709:54
xuhaiweiyes, I got this09:55
xuhaiweiand this is just the zone data of one node09:55
Qimingevery node created through _create_nodes()09:56
xuhaiweiwhat we need is the zone info of all the nodes of one cluster09:56
xuhaiweiso we finally should collect all the info of every node?09:56
Qimingwell, it is not done properly I guess09:57
Qimingwe are always checking the REAL distribution regarding AZs09:58
Qimingmaybe we can optimize that logic09:58
*** Yanyanhu has quit IRC09:58
Qimingfor cross region placement, we have this logic: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/region_placement.py#n16009:59
lixinhuiQiming, in this way, do you mean using placement to handle zone based ranking for scale_in/resize or deletion total handling solution10:00
Qimingplacement policy, in my opinion, should be the sole location to enforce node distribution10:01
Qimingonly considering node creation as we do today is not a complete solution10:01
lixinhuiyes, I think so. there is only place to handle zone10:01
xuhaiweiso placement policy will do part of deletion job?10:02
Qimingimproving it using a deletion policy is doable, but we are possibly introducing a lot duplicated logics, and possibly some conflicts not easy to detect10:02
Qimingplacement policy can be enforced when you are deleting nodes10:02
Qimingmerely for the purpose of ensuring that a node distribution plan is respected10:03
Qimingneed some fresh air10:04
xuhaiweiI can't understand this10:05
Qimingdrank 4 grande today10:05
Qimingxuhaiwei, think about this10:05
Qimingif I want to enforce a node distribution plan10:05
Qimingcan I use deletion policy alone?10:05
xuhaiweidistribution is not only placement?10:06
Qimingdistribution means {'AZ1': 100, 'AZ2': 50}, for example10:06
xuhaiweiwe may need placement and deletion policy10:06
Qimingwhy we need two policies to achieve a simple goal?10:07
Qimingis it easier to do it in one policy or two?10:07
xuhaiweifirst you need to place some nodes10:07
xuhaiweiyou mean just create some nodes?10:07
xuhaiweithen just need placement policy10:08
Qimingthat is what we have today, the placement policy is only about node creation10:08
Qimingyes, that is what we have today10:08
Qimingwe should improve that10:08
Qimingwe should make the placement policy capable of handling node deletion events10:08
xuhaiweito cope with deletion policy?10:09
Qimingcome up a plan, i.e. a list of candidates to remove, in order to maintain the node distribution10:09
Qimingwhen we are talking about node distributions10:09
Qimingyou may and may not have a deletion policy attached to a cluster10:09
Qiminga placement policy itself should be capable of doing a good job maintaining node distributions10:10
Qimingjust like the LB policy10:10
Qimingwhen you add nodes to a cluster, you attach them to a LB10:10
Qimingwhen you remove nodes, you detach them from a LB10:10
xuhaiweiwill you add the same rules of deletion policy to placement? like OLD_FIRST10:11
Qimingdeletion policy should be able to be used by itself10:11
xuhaiweibut if I want to use it, how to do it10:11
Qimingjust as placement policy10:11
*** yuanying has quit IRC10:11
*** yuanying has joined #senlin10:11
Qimingyou can still use deletion policy10:11
xuhaiweiwhat if I want both rules?10:12
Qimingwhy we have to bring deletion policy into the same picture?10:12
xuhaiweiI want to delete the oldest nodes from az110:12
Qimingwhy ?10:14
xuhaiweithat is a common need i think10:14
Qimingdo you still want to maintain node distribution rule?10:14
xuhaiweifirst I want to delete some nodes from az1, and which one to choose? Ok, from the oldest10:14
Qimingseems you are thinking of a complicated algorithm10:15
Qimingwrite it out10:16
Qimingsee if it makes sense10:16
xuhaiweiI think the distribution rule may conflict with the use case I said10:16
Qimingthat would be users concern10:16
Qimingif you have a complicated algorithm, you can develop a new policy10:17
Qimingdon't use the existing deletion policy10:17
Qimingdon't use the placement policy10:17
Qimingwhen you say oldest node10:17
Qimingthere are always questions about: oldest globally? or oldest in a az? or oldest in a region?10:18
Qimingsorry, guys, my eyes are blurring10:18
Qiminghave to get some fresh air10:19
xuhaiweiI will manage this in the blueprint10:19
*** Qiming has quit IRC10:23
*** yuanying has quit IRC10:28
*** yuanying has joined #senlin10:29
*** xuhaiwei has quit IRC10:48
*** yuanying has quit IRC11:15
*** Qiming has joined #senlin11:31
*** elynn has joined #senlin12:34
*** yanyanhu has joined #senlin12:49
*** elynn has quit IRC12:50
*** elynn has joined #senlin12:58
*** cschulz has joined #senlin13:21
openstackgerritMerged openstack/senlin: Backlog of release notes  https://review.openstack.org/26308313:26
*** elynn has quit IRC14:10
*** yanyanhu has quit IRC14:11
*** Qiming has quit IRC14:48
*** bdrich has joined #senlin15:38
*** bdrich has quit IRC15:52
*** bdrich has joined #senlin15:56
*** bdrich_ has joined #senlin19:49
*** bdrich has quit IRC19:51
*** pratikmallya has joined #senlin21:57
*** pratikmallya has quit IRC22:14
*** Qiming has joined #senlin22:51
*** yuanying has joined #senlin23:03
*** xuhaiwei has joined #senlin23:31
openstackgerritMerged openstack/senlin: Remove MANIFEST.in  https://review.openstack.org/26324423:46
openstackgerritMerged openstack/senlin: Remove some example policies  https://review.openstack.org/26364023:47
openstackgerritMerged openstack/senlin: Move some policies into WIP directory  https://review.openstack.org/26364123:47
*** bdrich_ has quit IRC23:51

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!