Wednesday, 2017-08-23

*** wanghao has quit IRC00:14
*** wanghao has joined #openstack-mogan00:14
wanghaomorning mogan!00:43
openstackgerritMerged openstack/python-moganclient master: Updated from global requirements
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1
*** wanghao_ has joined #openstack-mogan01:23
*** wanghao has quit IRC01:26
*** litao__ has joined #openstack-mogan01:29
*** wanghao_ has quit IRC01:37
*** wanghao has joined #openstack-mogan01:38
zhenguomorning all!01:58
openstackgerritZhenguo Niu proposed openstack/mogan master: Clean up server node uuid on task revert
zhenguoliusheng: please look at the above patch, seems I got the reason why placement refresh failed02:08
liushengzhenguo: ok02:10
* zhenguo brb02:37
liushengzhenguo: why change to allow all the bulding exceptions will be revert ?02:44
zhenguoliusheng: it's hard to check all expections there, and we have a check in the destroy method, if the provision_state is in not in unprovision state we just remove the instance_uuid/instance_info02:50
zhenguoliusheng: I find in some situations, we have the node uuid associated with the server, but the backend node is available02:51
liushengzhenguo: it that a bug for Ironic ?02:51
zhenguoliusheng: no02:51
zhenguoliusheng: it's a bug for mogan02:51
liushengzhenguo: if a node is available, why it should has a instance associated with it02:52
zhenguoliusheng: because on our revert method, we don't clean it02:52
liushengzhenguo: you mean Ironic allow that situation and don't care about that ?02:53
zhenguoliusheng: it's not related to ironic02:53
liushengzhenguo: why ? the state or provision state defined Ironic02:53
zhenguoliusheng: liusheng: yes, but instance_uuid, instance_info is set by us02:54
liushengzhenguo: so we can also set the instance info on a available state node ?02:55
zhenguoliusheng: sure02:55
liushengzhenguo: oh...02:55
zhenguoliusheng: it's just a property of the node object02:55
liushengzhenguo: so should we skip this situation when reporting resources to placement02:56
zhenguoliusheng: yes02:56
zhenguoliusheng: when will we set allocations02:57
zhenguoliusheng: if there's allocation, it should be ok02:57
liushengzhenguo: after scheduling02:57
zhenguoliusheng: so, it seems ok02:57
zhenguoliusheng: my problem is that, the server assocaited with a node uuid, then that rp will not get deleted as the allocations is there02:58
zhenguoliusheng: then I deleted the node in ironic and registered it again02:58
openstackgerritMerged openstack/mogan master: Updated from global requirements
zhenguoliusheng: which causes refresh placement error02:59
zhenguoliusheng: as the node uuid changed but the node name not02:59
zhenguoliusheng: when register a rp, it failed as name collisions02:59
zhenguoliusheng: if the old rp can got deleted it would be ok,02:59
zhenguoliusheng: so I tried to clean up the server node_uuid03:00
liushengzhenguo: if a rebuilding was reverted, the server will be in error state, right ?03:00
zhenguoliusheng: rebuilding?03:01
liushengzhenguo: building ,sorry03:01
zhenguoliusheng: that wil cause rescheduling03:01
zhenguoliusheng: if max attempts exceeds, it will fail03:01
liushengzhenguo: oh, seems it will be rescheduled and destroy in driver layer03:02
zhenguoliusheng: not in driver layer03:02
zhenguoliusheng: in our workflow03:02
liushengzhenguo: yes, our workflow will destroy call the driver.destroy(), right03:03
zhenguoliusheng: yes03:03
zhenguoliusheng: I changed the revert conditions, to make it always happen03:03
zhenguoliusheng: if spawn failed03:04
liushengzhenguo: as we disscussed last time, the periodic reporting task will irgnore this situation until the node cleaned complete and turn to available state, the reporting task will delete the allocation03:05
zhenguoliusheng: my situation is that the node is available, not get deleted at all03:08
zhenguoliusheng: it's avaialble03:08
zhenguoliusheng: I manullay deleted it in ironic then enrolled again03:09
liushengzhenguo: just checked, yes, in this situation the rp will be skipped to delete03:16
zhenguoliusheng: just as the error server still associated with the node03:16
zhenguoliusheng: with the already deleted node03:16
liushengzhenguo: just because in Mogan, there is a server associated with that ndoe03:16
zhenguoliusheng: yes03:16
liushengzhenguo: yes, so why don't delete the error server to release03:17
liushengzhenguo: ?03:17
liushengzhenguo: I remember in Nova, a error server may also occupy a node resource03:17
zhenguoliusheng: as the node is available, I don't know why we need to assicate it with the error server03:18
zhenguoliusheng: if the node is really related with the error server, of course we should not delete the rp03:18
liushengzhenguo: if we release the node, how to hanld the quota computing ?03:19
liushengzhenguo: error state server also occupy quota03:20
zhenguoliusheng: quota is for server instead of node03:20
zhenguoliusheng: why do you think is related to the backend node03:21
zhenguoliusheng: currently enve if you build network failed, the server will associated the scheduled node03:21
liushengzhenguo: not very sure, but maybe we cannot all the reason of a error state server, maybe in some cases, we can recovery the server, so it is better don't release the node03:22
liushengzhenguo: may we need to ping zhenyu why Nova does that03:22
zhenguoliusheng: how can you recover it03:23
zhenguoliusheng: we are talking, the node is available03:23
liushengzhenguo: cannot be rebuild ?03:23
liushengzhenguo: same situation in Nova03:24
zhenguoliusheng: I think it can not be03:24
liushengzhenguo: the compute node can also be normal state03:24
zhenguoliusheng: there's no reason to occupy the node just in case you may rebuild it03:24
zhenguoliusheng: you spawn a server failed, you can just spawn a new one, why rebuild it03:25
liushengzhenguo: ...03:25
liushengzhenguo: I can keep my opinion...03:25
zhenguoliusheng: it's really not like nova03:26
zhenguoliusheng: in our situation, we really occupied resources, but nova don't03:27
liushengzhenguo: why Nova don't ?03:27
zhenguoliusheng: why nova does03:27
zhenguoliusheng: the vm didn't created at all03:28
liushengzhenguo: nova scheduler will accurate the resource occupied by the error server03:28
liushengzhenguo: no03:28
zhenguoliusheng: I mean in the same situation with us03:29
zhenguoliusheng: the backend node is avaialbe for us, which means it doesn't get deployed03:29
liushengzhenguo: I am saying the similar situation03:29
zhenguoliusheng: I can call you in person with espace03:30
liushengzhenguo: Nova may also didn't create the server in libvirt03:30
*** wanghao_ has joined #openstack-mogan03:37
*** wanghao has quit IRC03:39
*** zhenguo has quit IRC05:02
*** Jeffrey4l has quit IRC05:02
*** dims has quit IRC05:02
*** zhangyang has quit IRC05:02
*** zhangyang has joined #openstack-mogan05:02
*** zhenguo has joined #openstack-mogan05:02
*** Jeffrey4l has joined #openstack-mogan05:03
*** dims has joined #openstack-mogan05:04
*** wanghao_ has quit IRC05:24
*** wanghao has joined #openstack-mogan05:26
openstackgerritZhenguo Niu proposed openstack/mogan master: Only set/update RPs when the node is available
openstackgerritXinran WANG proposed openstack/mogan master: Get rid of flavor access
zhenguoliusheng: I find some problems with the current resource update logic06:24
zhenguoliusheng: when I enrolled some nodes with 'enroll' state, it will report to placement, and mogan will use it like normal node06:25
zhenguoliusheng: which will cause error06:25
liushengzhenguo: there is a unavailable "enroll" state ? if so, that should be one of the obnormal nodes list06:27
zhenguoliusheng: I don't find there's a abnormal list06:27
liushengzhenguo: mogan/baremetal/ironic/  no, here we will skip nodes we don't want to report06:28
zhenguoliusheng: you can check the conditions06:29
zhenguoliusheng: which only check bad power state, resource class, and associated with server but in available state06:30
liushengzhenguo:yes, I mean we should add "enroll" state :)06:30
zhenguoliusheng: which means node in all provision state will report to the placement if power_state is good and not associated with server06:30
zhenguoliusheng: no only enroll state, what about other failed/error state06:31
*** wanghao_ has joined #openstack-mogan06:32
liushengzhenguo: seems yes06:35
*** wanghao has quit IRC06:35
zhenguoliusheng: we can keep obnormal node to placement only if there's a error server associate it, and now we can ensure that06:36
zhenguoliusheng: and for *ing state node, should be normal as well06:37
zhenguoliusheng: or only 'available' node should be normal?06:37
zhenguoliusheng: also seems using ironic_states in mogan/engine is not proper, as ironic is only one driver06:40
liushengzhenguo: seems, NOSTATE is also an obnormal state06:43
liushengzhenguo: I don't know why I didn't include that...06:44
zhenguoliusheng: I would like to change to only get 'available' nodes06:44
liushengzhenguo: oh, ironic_states.AVAILABLE, ironic_states.NOSTATE is normal state06:44
liushengzhenguo: sorry06:44
zhenguoliusheng: and check bad_power_state and associated06:44
zhenguoliusheng: that's for compatibility with old ironic06:44
liushengzhenguo: nova.virt.ironic.driver.IronicDriver#_node_resources_unavailable06:44
zhenguoliusheng: I don't want to copy nova here06:44
zhenguoliusheng: we can just think  our use case06:45
zhenguoliusheng: let's considering what's the side effect of only get 'available' nodes06:46
liushengzhenguo: we need to also update the in-use nodes06:46
zhenguoliusheng: why we need to update it06:46
liushengzhenguo: node resource maybe updated06:47
zhenguoliusheng: then update it will bring what benefit to us06:47
zhenguoliusheng: node resource here is just resource_class right?06:47
zhenguoliusheng: we are not like nova's cpu/mem/...06:47
liushengzhenguo: no, I mean a node maybe update by admins, yes we don't have cpu/mem... but may be add different resource traits, or attaching a special interfaces by admins06:48
liushengzhenguo: right ?06:48
zhenguoliusheng: traits should be retrieved from ironic?06:49
zhenguoliusheng: interfaces is a possible use cases, but we don't save it for now06:50
zhenguoliusheng: so only for 'available' and 'active' node06:50
zhenguoliusheng: we can get only nodes in that two provision_state06:50
liushengzhenguo: sorry, I am not sure, does provision state includes other states that a node in-use ?06:51
liushengzhenguo: deploying, wait call-back06:52
zhenguoliusheng: if the node in-use, it will not get deleted from placement as there's allocations06:52
liushengzhenguo: yes06:52
zhenguoliusheng: so for properties update, it's ok to just wait for a moment that the node get active06:53
liushengzhenguo: from our use cases, it looks reasonable, but as my understanding, placement if used for manage the normal resource, and don't care about its status or power state, only except the resource in obnormal states06:58
liushengzhenguo: my personal view06:58
zhenguoliusheng: that depends what state is obnormal state06:59
zhenguoliusheng: things in placement means mogan can  consume it, only condition is there's no allocations06:59
liushengzhenguo: yes07:00
zhenguoliusheng: but there maybe some problems if we only get 'available' state node, if node gone and come back, I don't know what will happen with the aggregates relationship07:01
zhenguoliusheng: I never test that07:01
liushengzhenguo: not sure, maybe the members of aggregates won't be changes, so if the uuid of node didnt changed, maybe it still can work07:03
zhenguoliusheng: seems collisions will happen if we use node name for RP name07:05
zhenguoliusheng: like I may remove the node then add the same name node in future07:05
liushengzhenguo: how about treat it as a new node, and delete the aggregate relationship when removing the node07:07
zhenguoliusheng: it seems like nova host07:07
zhenguoliusheng: they also use name07:07
liushengzhenguo: we don't have a way to update the resource immediately after removing the node from driver07:08
zhenguoliusheng: yes07:08
zhenguoliusheng: need to think more about the resources update logic with placement07:08
zhenguoliusheng: but seems we don't have time left for PIke :(07:09
zhenguoliusheng: do you have another way to not import ironic_state in mogan/engine/manager?07:09
zhenguoliusheng: it should only appear in ironic driver07:09
liushengzhenguo: I have considered about that, I propose to add a driver motthod maybe named "is_node_resource_normal"07:10
zhenguoliusheng: sounds good07:10
liushengzhenguo: since the normal states in different may have different meanings07:11
liushengzhenguo: in different drivers07:11
zhenguoliusheng: yes07:11
*** wanghao_ has quit IRC07:12
liushengzhenguo: will add that :)07:12
zhenguoliusheng: thanks07:12
*** wanghao has joined #openstack-mogan07:13
zhenguoliusheng: for get_available_nodes, I can keep the currently logic and just add a 'enroll' state check for now07:13
liushengzhenguo: ok07:14
*** wanghao has quit IRC07:23
openstackgerritZhenguo Niu proposed openstack/mogan master: Add bad provision states check for nodes
zhenguoliusheng: btw, please make a backup for the scripts in our physical env to avoid getting lost some day :D07:27
liushengzhenguo: ok, will do that07:27
liushengzhenguo: seems I catched a cold and not in a good state :D07:28
zhenguoliusheng: hah, feels better now :D07:28
zhenguoliusheng: seems this will make the server always not associated with a node uuid
zhenguoliusheng: if our revert process works well07:35
liushengzhenguo: once it enter the rescheduling entry, the node uuid will be None, right /07:36
zhenguoliusheng: yes07:36
liushengzhenguo: it that reasonable ? hah07:37
zhenguoliusheng: our revert is just designed for this, lol07:37
zhenguoliusheng: we clean up the node, entworks,.. during the revert process07:37
liushengzhenguo: ok, make sense07:38
zhenguoliusheng: I'm testing it now, at least it seems better then before with this07:38
liushengzhenguo: ok07:39
zhenguoliusheng: seems everytime we setup the physical env, we can find a lot of mogan bugs, lol07:39
*** wanghao has joined #openstack-mogan07:39
liushengzhenguo: hah, it is ok, even Nova now have many bugs07:40
zhenguoliusheng: sure, hah07:40
*** openstackgerrit has quit IRC08:03
*** openstackgerrit has joined #openstack-mogan08:07
openstackgerritliusheng proposed openstack/mogan master: Add affinity_zone field for server object
openstackgerritliusheng proposed openstack/mogan master: Add support for scheduler_hints
openstackgerritliusheng proposed openstack/mogan master: Use server group in scheduler
openstackgerritliusheng proposed openstack/mogan master: Use server group in scheduler
litao__ping zhenguo08:27
zhenguolitao__: pong08:27
litao__zhenguo: I want to talk about the managing bare metal node API08:28
litao__zhenguo: I think we can update the neutron port profile in managing it08:29
zhenguolitao__: not currently08:30
zhenguolitao__: it's hard to control08:30
litao__zhenguo: If all tasks are left to admin,  it is a complexity work08:30
zhenguolitao__: not all tasks left to admins08:30
litao__zhenguo: you mean we do this work later?08:30
zhenguolitao__: even if you don't have neutron port connected, we can manage it08:30
zhenguolitao__: we can just make things simple for now, or at least before Pike08:31
*** wanghao has quit IRC08:35
litao__zhenguo: if so, we can simple it, and after pike ,we can add these functions08:36
*** wanghao has joined #openstack-mogan08:36
litao__zhenguo: because it is a huge work for managing a bare metal node08:38
litao__zhenguo: especially for network configration08:39
zhenguolitao__: yes, that part is too complex as my understanding08:43
zhenguolitao__: we can keep it simple in mogan, at least we can work, but if you want to continue to make it more smart, you can continue in next cycle :D08:43
litao__zhenguo: so mogan should do more to reduce the work for admins08:43
litao__zhenguo: ok08:44
zhenguolitao__: hah08:44
*** litao__ has quit IRC08:51
*** zhuli has quit IRC08:51
*** zhuli has joined #openstack-mogan08:51
*** litao__ has joined #openstack-mogan08:51
*** zhenguo has quit IRC08:52
*** zhenguo has joined #openstack-mogan08:52
openstackgerritZhenguo Niu proposed openstack/mogan master: Add unplug_vif to network task revert
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1
zhenguowanghao: seems my comments on the previous patch set get lost for the above patch :D09:28
zhenguowanghao: it looks mostly good, please add the detail api response parameters as well, thanks!09:28
wanghaozhenguo: yeah, I miss the api-ref doc09:29
wanghaozhenguo: okay, I will update the doc.09:29
zhenguowanghao: ok, thansk !09:30
wanghaozhenguo: np :)09:30
*** wanghao has quit IRC09:31
*** wanghao has joined #openstack-mogan09:31
*** wanghao has quit IRC09:31
*** wanghao has joined #openstack-mogan09:32
*** wanghao has quit IRC09:32
*** wanghao has joined #openstack-mogan09:32
*** wanghao has quit IRC09:33
*** wanghao has joined #openstack-mogan09:33
*** wanghao has quit IRC09:34
*** wanghao has joined #openstack-mogan09:34
*** wanghao has quit IRC09:35
*** wanghao has joined #openstack-mogan09:35
*** wanghao has quit IRC09:35
*** wanghao has joined #openstack-mogan09:36
*** wanghao has quit IRC09:36
*** wanghao has joined #openstack-mogan09:37
openstackgerritXinran WANG proposed openstack/mogan master: support specifying port_id when attaching interface
openstackgerritliusheng proposed openstack/mogan master: Use server group in scheduler
openstackgerritZhenguo Niu proposed openstack/mogan master: Add unplug_vif to network task revert
openstackgerritZhenguo Niu proposed openstack/mogan master: Leverage _detach_interface for destroying networks
*** litao__ has quit IRC11:57
*** liusheng has quit IRC17:37
*** liusheng has joined #openstack-mogan17:38

Generated by 2.15.3 by Marius Gedminas - find it at!