Tuesday, 2017-08-08

*** harlowja has quit IRC00:25
*** wanghao has joined #openstack-mogan00:41
*** wanghao has quit IRC00:58
*** wanghao has joined #openstack-mogan01:13
*** litao__ has joined #openstack-mogan01:15
zhenguomorning mogan!01:38
zhenguolitao__: this https://bugs.launchpad.net/ironic/+bug/1701991 is accepted, but changed to RFE/BP, you need to provide a spec01:42
openstackLaunchpad bug 1701991 in Ironic "[RFE] Provide attachment hints for VIF attach" [Wishlist,Confirmed] - Assigned to Tao Li (eric-litao)01:42
Xinranzhenguo,  Hi, pls review the rebuild patch when you have time https://review.openstack.org/#/c/490421/   :)01:43
zhenguoXinran: ok01:44
Xinranzhenguo,  thanks :)01:44
zhenguoXinran: np :D01:44
openstackgerritliusheng proposed openstack/python-moganclient master: Add support for node list command  https://review.openstack.org/49164402:10
zhenguowanghao: I left some comments here https://blueprints.launchpad.net/mogan/+spec/introduce-cinderclient-into-mogan03:25
wanghaozhenguo: sure, np,  I will update the title.03:26
zhenguowanghao: I think it's not worth a bp for just client importing03:26
wanghaoemm, okay, we can have one bp across Pike and Queens.03:27
zhenguowanghao: yes, hah03:33
zhenguoliusheng: the server groups patches are ready for review?03:46
liushengzhenguo: yes03:46
zhenguoliusheng: cool03:46
liushengzhenguo: :D03:46
zhenguoliusheng: do we need further work to make it supported when claiming a server03:46
liushengzhenguo: yes, we need03:47
liushengzhenguo: we may need to change our scheduler can work with aggregate, server group03:47
zhenguoliusheng: sure, I will make it done today03:48
liushengzhenguo: cool03:48
liushengzhenguo: may need to add some interfaces for server group in db and object layer for scheduling usage, it is better to be done after your aggregate change03:51
zhenguoliusheng: yes, I'm also adding new interfaces now :D03:51
liushengzhenguo: ok, so I can work on aggregate paches in client now :D03:52
zhenguoliusheng: yes, thanks03:52
liushengzhenguo: np :)03:52
zhenguowanghao, litao__: the managing running servers functionality is really cool, I just found someone else request it :D03:54
wanghaozhenguo: haha,  that's very great!04:21
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1  https://review.openstack.org/47966004:23
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1  https://review.openstack.org/47966004:24
openstackgerritwanghao proposed openstack/mogan master: Introduce Cinder client into Mogan  https://review.openstack.org/48945504:25
*** harlowja has joined #openstack-mogan04:35
*** harlowja has quit IRC05:14
openstackgerritwanghao proposed openstack/mogan-specs master: Change adopt to manage in managing-existing-node spec  https://review.openstack.org/49031005:43
wanghaoliusheng: ping05:54
wanghaoliusheng: I saw your comments in managing-existing-node,  do you think we have to introduce the object of managable_nodes?05:55
wanghaoliusheng: at first, I just want to show the information we got from driver directly to user,  no need to covernt it to object since we didn't use the object elsewhere in Mogan.05:56
wanghaoliusheng: I think it's a little complex overcode to must be same as other objects, like servers or flavors. wdyt?05:57
litao__wanghao: Currently , we can use Server Object06:03
wanghaoit is a little werid if we use server object06:04
litao__zhenguo: hah, very cool06:04
liushengwanghao: not object, we need a api layer object06:06
liushengwanghao: like: mogan.api.controllers.v1.servers.Server06:06
wanghaoliusheng: I know,  but we use for 'field in objects.Server.fields:' in api layer object.06:11
liushengwanghao: where to use ? I didn't found in https://review.openstack.org/#/c/479660/19/mogan/api/controllers/v1/manageable_servers.py06:13
liushengwanghao: only a nodes you defined for the api return06:13
liushengwanghao: "nodes = [wtypes.text]"06:13
wanghaoliusheng: no,  I mean if we want to use a api object like servers.Server06:13
liushengwanghao: sure, it is based on the API frame, make the fields of your return clearly, and pecan will do some checks06:14
wanghaoliusheng: then we need to define a object  in objects, right?06:15
liushengwanghao: we also don't user the other objects in Mogan, but we difined them06:15
wanghaoliusheng: or just define a api layer object ?06:15
liushengwanghao: as I memtioned, just like mogan.api.controllers.v1.servers.Server and mogan.api.controllers.v1.servers.ServerCollection06:16
wanghaoliusheng: so you mean we need to fine a api layer object and objects object like other resources, right?06:16
liushengwanghao: yes06:17
wanghaoliusheng: but TBH,  I didn't like this way.06:17
wanghaoliusheng: it's too complex and over code.06:18
liushengwanghao: I don't think so, it is the common usage of pecan api frame, why do you think it is complex ?06:18
liushengwanghao: pecan will do some checks based on the api object definition06:19
wanghaoliusheng: but you have define the object in internal of Mogan,  you can handle what you want to show to users by using a simple covernt, no need to turn the object to another object and let pecan to check it.06:21
liushengwanghao: ... so why we need pecan.06:22
liushengwanghao: and so why we difine other resources like they are06:23
wanghaoliusheng: I'm not familiar with pecan, maybe it has a lot of benefits, but just feel it's a little complex here.  just some thoughts in personal. :)06:24
wanghaoliusheng: I agree we should define the resources object like they are,  but no need to define twice.  I know the pecan to use the api object to control view of showing.06:26
wanghaoliusheng: well, I can follow this....06:27
liushengwanghao: I can keep my opinion and you can wait other's review, hah. just think it is weird we return a reponse body and don't check it in api layer, it make the return unclear. and is not according to common usages of pecan frame06:27
liushengwanghao: thanks, may we can listen zhenguo's opinion also06:28
liushengping zhenguo ^^06:28
zhenguoliusheng: pong06:29
wanghaoliusheng: sure06:29
zhenguoliusheng, wanghao: hah, what are you arguing about ?06:29
wanghaozhenguo: we are talking about if we should use api object  and objects.object in get_manageable_servers API.06:30
liushengzhenguo: hah, in wanghao's patch, he defined a AdoptableNodes object which only included a  nodes = [wtypes.text], I don't think is is a good way, wdyt ?06:31
liushengzhenguo: fyi: https://review.openstack.org/#/c/479660/17/mogan/api/controllers/v1/manageable_servers.py06:31
wanghaozhenguo: it's not good way,  since I prefer to just return wtypes.text.  No api object here.06:31
zhenguowanghao, liusheng: seems we also need a AdoptNode API object, right?06:32
wanghaoAdoptNode API object  and AdoptNode object in objects too.06:32
liushengzhenguo: I think so, maybe you can give some advices. hah06:32
zhenguowanghao, liusheng: so it just return a list of node uuid?06:32
zhenguowanghao, liusheng: or a node object/dict here06:32
liushengzhenguo: no, it seems not only a list of uuid06:33
wanghaoand Adoptnodes API object too.06:33
zhenguoliusheng, wanghao: why not just a uuid? as I understand the manageable node should contain many infromations06:33
zhenguo* why just06:33
wanghaozhenguo: no no,  I just want to return a list of dict.06:33
wanghaozhenguo: not just node uuid.06:34
liushengzhenguo: manage API interface need other info of node06:34
zhenguowanghao: so if it's a list of dict, it's not [text] right?06:34
wanghaozhenguo: I want to show more information to operators not just a uuid/06:34
liushengzhenguo, wanghao I think wanghao want to regard the return dict as a "text"06:34
zhenguowanghao, liusheng: I understand, so we need to define an object to describe the details of the dict06:35
wanghaozhenguo: of course he also can get those information from ironic,  but with our API,  he can save his work.06:35
liushengzhenguo: that is my suggestion, like ServerCollection and Server object in servers.py06:36
zhenguowanghao: yes, I mean why just return node uuid previously, not 'why not just' :D06:36
zhenguoliusheng, wanghao: yes,  I also think we need to define an API object to check the return value/type06:37
wanghaozhenguo: okay  I see06:38
zhenguowanghao: if it's just uuid, the object is not needed06:38
wanghaozhenguo:  'just return node uuid' is a doc string mistake,  haha.06:38
zhenguowanghao: hah06:38
wanghaozhenguo: en  I see06:39
wanghaookay, you have me here,  I will update the code.06:39
zhenguowanghao: thanks06:39
liushengaccoding to the agent layer implementation, it doesn't only return the node uuds.06:39
zhenguoliusheng: yes, and it shouldn't just return uuid06:40
wanghaoBut,   we didn't need the link, right?06:40
wanghaosince we didn't have get single one method in API.06:40
zhenguowanghao: do we support to get one node details?06:40
zhenguowanghao: do we need a get API?06:41
wanghaosince you have got all manageable nodes in one time.06:41
zhenguowanghao: and make list API just return simple things06:41
wanghaoI don't think we need a get API.06:41
liushengwanghao zhenguo seems only twe APIs, right ?06:41
zhenguoI find cinder provider such APi06:41
zhenguolist get and post06:42
liushengnot sure in Cinder, the return of get_one is same with one items of the return of get_all06:42
zhenguoseems not06:43
zhenguoget_one return more details06:43
wanghaojust index, detail and post06:43
wanghaonot get single one API06:43
zhenguoyou mean detail is also index?06:43
zhenguook, I see06:44
zhenguoif we don't need get_one, we can't provide links :D06:44
wanghaoin Cinder,  bascally just index, detail,  get_one,   one items of detail is same as return of get_one.06:46
wanghaofor manageable volumes api,  there is no get_one api.06:46
wanghaojust index, and detail.    detail will show some more information of manageable volumes.06:47
zhenguowe can follow cinder :D06:47
liushengyes, seem, the details is also a list api06:47
zhenguoone summary and one detail list API :D06:47
wanghaoin mogan,  I just want to use one api to show all information,  it's get_all.06:47
liushengI agree one API is enough06:47
zhenguoit's fine with me06:48
zhenguoso one API with details06:48
wanghaookay, I will change the code ASAP.06:48
wanghaoseems we didn't need another object define in Objects.06:54
wanghaoI will covernt the dict to API object directly.06:54
wanghaothat's enough.06:54
zhenguoliusheng: is this https://github.com/openstack/mogan/blob/master/mogan/scheduler/filter_scheduler.py#L99-L100 needed?07:02
liushengzhenguo: seems, the return of get_filtered_resource_providers could be a None07:12
zhenguoliusheng: ok07:13
zhenguoliusheng: a bad API, hah07:13
liushengzhenguo: hah, yes07:13
openstackgerritZhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheuling  https://review.openstack.org/49169507:13
openstackgerritZhenguo Niu proposed openstack/mogan master: Add checks for aggregate availability_zone  https://review.openstack.org/48987607:21
zhenguoliusheng: seems we need nested resource providers to support raid as we need disk informations07:25
liushengzhenguo: we need to know the amount and capacity of disks, right ?07:27
zhenguoliusheng: yes, and users may also want to know the type of the disks like ssd or hdd07:27
openstackgerritTao Li proposed openstack/mogan master: Manage existing BMs: Part-2  https://review.openstack.org/48154407:28
liushengzhenguo: hmm, that seems need more disk info for scheduling07:29
zhenguoliusheng: so I would like to wait for nested resource providers07:30
liushengzhenguo: not sure how long placement guy can finish that07:30
zhenguoliusheng: it will be soon :D07:30
zhenguoliusheng: so before Pike we don't add new tasks07:31
zhenguoliusheng: maybe I can make some time to work with wanghao for the boot from volume one07:31
liushengzhenguo: ok, sounds good07:31
wanghaozhenguo: thanks, that will be greate.07:33
zhenguowanghao: let's try to get that done07:33
wanghaozhenguo: sure07:35
zhenguoliusheng, wanghao, litao__: for server groups, do you like affinity_zone or affinity_group07:38
wanghaosounds a little werid in server groups with affinity_group.07:40
liushengzhenguo: affinity_group may make user confused with server_group07:40
litao__zhenguo:  Does any project use affinity_zone?07:40
zhenguohah, ok, so we will keep affinity zone07:40
zhenguolitao__: no, it's invented by us :D07:40
litao__zhenguo: what is the difference between server_group and affinity_group, I remember it is a same thing in nova07:42
zhenguolitao__: nova's server group is on the same host or different host, but we don't have host notion07:43
zhenguolitao__: so we need a logical affinity_zone to achieve such affinity or anti-affinity07:43
litao__zhenguo: OK, I see07:44
litao__zhenguo: it's ok07:44
zhenguolitao__: ok07:45
zhenguolitao__: btw, please condier the ironic bug we reporeted when got time, they marked it as RFE07:46
litao__zhenguo: yes , I see. I will do it later07:49
zhenguolitao__: thanks, it's a bp in ironic, so need to provide a spec there07:49
litao__zhenguo: ok, btw, why do they use bugs system with RFE flag rather than  blueprint system   to trace a feature .07:52
zhenguolitao__: they find bp is hard to use :D07:54
zhenguolitao__: as we introduced specs, bp is really not needed07:54
zhenguolitao__: so a light bp system make things easy to use07:55
litao__zhenguo:  yes, but i think bp system is clear to learn all the features07:56
zhenguolitao__: release notes aim to provide that07:56
litao__zhenguo: hah, I will learn more.07:58
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1  https://review.openstack.org/47966007:58
zhenguolitao__: hah07:58
wanghaoguys, I updated the manage existing bms patch according our reviews,  it's more beautiful now.08:01
zhenguowanghao: cool08:04
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1  https://review.openstack.org/47966008:05
wanghaohi guys,  when you reinstall the devstack env,  did you use the ./unstack.sh,  it's enough, right?08:13
wanghaoand then just use ./stack.sh again.08:14
zhenguowanghao: yes08:18
zhenguowanghao: you can use our new local.conf in dev-quickstart08:19
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1  https://review.openstack.org/47966008:54
openstackgerritZhenguo Niu proposed openstack/mogan master: Add checks for aggregate availability_zone  https://review.openstack.org/48987608:58
openstackgerritwanghao proposed openstack/mogan master: Remove unused function in Mogan  https://review.openstack.org/49172509:00
wanghaozhenguo: sure09:03
openstackgerritZhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling  https://review.openstack.org/49169509:26
*** wanghao has quit IRC09:28
zhenguoliusheng: if we don't specify aggregates when claiming servers, it will use all nodes satisfied with resource_class?09:42
liushengzhenguo: I think so09:43
zhenguoliusheng: ok09:43
openstackgerritZhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling  https://review.openstack.org/49169509:48
openstackgerritliusheng proposed openstack/mogan master: Fix the config sample generation  https://review.openstack.org/49174210:03
zhenguoliusheng: need your review on this https://review.openstack.org/#/c/470927/ , the node aggregates task is almost done :D10:18
openstackgerritMerged openstack/mogan-specs master: Update new-flavor specs  https://review.openstack.org/48916710:22
openstackgerritZhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling  https://review.openstack.org/49169511:37
openstackgerritShangXiao proposed openstack/mogan master: [Trivialfix]Fix typos in mogan  https://review.openstack.org/49177012:03
*** litao__ has quit IRC12:04
openstackgerritMerged openstack/mogan master: Remove unused function in Mogan  https://review.openstack.org/49172513:37

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