| *** harlowja has quit IRC | 00:25 | |
| *** wanghao has joined #openstack-mogan | 00:41 | |
| *** wanghao has quit IRC | 00:58 | |
| *** wanghao has joined #openstack-mogan | 01:13 | |
| *** litao__ has joined #openstack-mogan | 01:15 | |
| zhenguo | morning mogan! | 01:38 |
|---|---|---|
| zhenguo | litao__: this https://bugs.launchpad.net/ironic/+bug/1701991 is accepted, but changed to RFE/BP, you need to provide a spec | 01:42 |
| openstack | Launchpad bug 1701991 in Ironic "[RFE] Provide attachment hints for VIF attach" [Wishlist,Confirmed] - Assigned to Tao Li (eric-litao) | 01:42 |
| Xinran | zhenguo, Hi, pls review the rebuild patch when you have time https://review.openstack.org/#/c/490421/ :) | 01:43 |
| zhenguo | Xinran: ok | 01:44 |
| Xinran | zhenguo, thanks :) | 01:44 |
| zhenguo | Xinran: np :D | 01:44 |
| openstackgerrit | liusheng proposed openstack/python-moganclient master: Add support for node list command https://review.openstack.org/491644 | 02:10 |
| zhenguo | wanghao: I left some comments here https://blueprints.launchpad.net/mogan/+spec/introduce-cinderclient-into-mogan | 03:25 |
| wanghao | zhenguo: sure, np, I will update the title. | 03:26 |
| zhenguo | wanghao: I think it's not worth a bp for just client importing | 03:26 |
| wanghao | emm, okay, we can have one bp across Pike and Queens. | 03:27 |
| wanghao | https://blueprints.launchpad.net/mogan/+spec/support-boot-from-volume-in-mogan | 03:29 |
| zhenguo | wanghao: yes, hah | 03:33 |
| zhenguo | liusheng: the server groups patches are ready for review? | 03:46 |
| liusheng | zhenguo: yes | 03:46 |
| zhenguo | liusheng: cool | 03:46 |
| liusheng | zhenguo: :D | 03:46 |
| zhenguo | liusheng: do we need further work to make it supported when claiming a server | 03:46 |
| liusheng | zhenguo: yes, we need | 03:47 |
| liusheng | zhenguo: we may need to change our scheduler can work with aggregate, server group | 03:47 |
| zhenguo | liusheng: sure, I will make it done today | 03:48 |
| liusheng | zhenguo: cool | 03:48 |
| liusheng | zhenguo: 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 change | 03:51 |
| zhenguo | liusheng: yes, I'm also adding new interfaces now :D | 03:51 |
| liusheng | zhenguo: ok, so I can work on aggregate paches in client now :D | 03:52 |
| zhenguo | liusheng: yes, thanks | 03:52 |
| liusheng | zhenguo: np :) | 03:52 |
| zhenguo | wanghao, litao__: the managing running servers functionality is really cool, I just found someone else request it :D | 03:54 |
| wanghao | zhenguo: haha, that's very great! | 04:21 |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 04:23 |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 04:24 |
| openstackgerrit | wanghao proposed openstack/mogan master: Introduce Cinder client into Mogan https://review.openstack.org/489455 | 04:25 |
| *** harlowja has joined #openstack-mogan | 04:35 | |
| *** harlowja has quit IRC | 05:14 | |
| openstackgerrit | wanghao proposed openstack/mogan-specs master: Change adopt to manage in managing-existing-node spec https://review.openstack.org/490310 | 05:43 |
| wanghao | liusheng: ping | 05:54 |
| wanghao | liusheng: I saw your comments in managing-existing-node, do you think we have to introduce the object of managable_nodes? | 05:55 |
| wanghao | liusheng: 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 |
| wanghao | liusheng: 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 Object | 06:03 |
| wanghao | it is a little werid if we use server object | 06:04 |
| litao__ | zhenguo: hah, very cool | 06:04 |
| liusheng | wanghao: not object, we need a api layer object | 06:06 |
| liusheng | wanghao: like: mogan.api.controllers.v1.servers.Server | 06:06 |
| wanghao | liusheng: I know, but we use for 'field in objects.Server.fields:' in api layer object. | 06:11 |
| liusheng | wanghao: where to use ? I didn't found in https://review.openstack.org/#/c/479660/19/mogan/api/controllers/v1/manageable_servers.py | 06:13 |
| liusheng | wanghao: only a nodes you defined for the api return | 06:13 |
| liusheng | wanghao: "nodes = [wtypes.text]" | 06:13 |
| wanghao | liusheng: no, I mean if we want to use a api object like servers.Server | 06:13 |
| liusheng | wanghao: sure, it is based on the API frame, make the fields of your return clearly, and pecan will do some checks | 06:14 |
| wanghao | liusheng: then we need to define a object in objects, right? | 06:15 |
| liusheng | wanghao: we also don't user the other objects in Mogan, but we difined them | 06:15 |
| wanghao | liusheng: or just define a api layer object ? | 06:15 |
| liusheng | wanghao: as I memtioned, just like mogan.api.controllers.v1.servers.Server and mogan.api.controllers.v1.servers.ServerCollection | 06:16 |
| wanghao | liusheng: so you mean we need to fine a api layer object and objects object like other resources, right? | 06:16 |
| liusheng | wanghao: yes | 06:17 |
| wanghao | OK | 06:17 |
| wanghao | liusheng: but TBH, I didn't like this way. | 06:17 |
| wanghao | liusheng: it's too complex and over code. | 06:18 |
| liusheng | wanghao: I don't think so, it is the common usage of pecan api frame, why do you think it is complex ? | 06:18 |
| liusheng | wanghao: pecan will do some checks based on the api object definition | 06:19 |
| wanghao | liusheng: 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 |
| liusheng | wanghao: ... so why we need pecan. | 06:22 |
| liusheng | wanghao: and so why we difine other resources like they are | 06:23 |
| wanghao | liusheng: 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 |
| wanghao | liusheng: 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 |
| wanghao | liusheng: well, I can follow this.... | 06:27 |
| liusheng | wanghao: 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 frame | 06:27 |
| liusheng | wanghao: thanks, may we can listen zhenguo's opinion also | 06:28 |
| liusheng | ping zhenguo ^^ | 06:28 |
| zhenguo | liusheng: pong | 06:29 |
| wanghao | liusheng: sure | 06:29 |
| zhenguo | liusheng, wanghao: hah, what are you arguing about ? | 06:29 |
| wanghao | zhenguo: we are talking about if we should use api object and objects.object in get_manageable_servers API. | 06:30 |
| liusheng | zhenguo: 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 |
| liusheng | zhenguo: fyi: https://review.openstack.org/#/c/479660/17/mogan/api/controllers/v1/manageable_servers.py | 06:31 |
| wanghao | zhenguo: it's not good way, since I prefer to just return wtypes.text. No api object here. | 06:31 |
| zhenguo | wanghao, liusheng: seems we also need a AdoptNode API object, right? | 06:32 |
| wanghao | AdoptNode API object and AdoptNode object in objects too. | 06:32 |
| liusheng | zhenguo: I think so, maybe you can give some advices. hah | 06:32 |
| zhenguo | wanghao, liusheng: so it just return a list of node uuid? | 06:32 |
| zhenguo | wanghao, liusheng: or a node object/dict here | 06:32 |
| liusheng | zhenguo: no, it seems not only a list of uuid | 06:33 |
| wanghao | and Adoptnodes API object too. | 06:33 |
| zhenguo | liusheng, wanghao: why not just a uuid? as I understand the manageable node should contain many infromations | 06:33 |
| zhenguo | * why just | 06:33 |
| wanghao | zhenguo: no no, I just want to return a list of dict. | 06:33 |
| wanghao | zhenguo: not just node uuid. | 06:34 |
| liusheng | zhenguo: manage API interface need other info of node | 06:34 |
| zhenguo | wanghao: so if it's a list of dict, it's not [text] right? | 06:34 |
| wanghao | zhenguo: I want to show more information to operators not just a uuid/ | 06:34 |
| liusheng | zhenguo, wanghao I think wanghao want to regard the return dict as a "text" | 06:34 |
| zhenguo | wanghao, liusheng: I understand, so we need to define an object to describe the details of the dict | 06:35 |
| wanghao | zhenguo: of course he also can get those information from ironic, but with our API, he can save his work. | 06:35 |
| liusheng | zhenguo: that is my suggestion, like ServerCollection and Server object in servers.py | 06:36 |
| zhenguo | wanghao: yes, I mean why just return node uuid previously, not 'why not just' :D | 06:36 |
| zhenguo | liusheng, wanghao: yes, I also think we need to define an API object to check the return value/type | 06:37 |
| wanghao | zhenguo: okay I see | 06:38 |
| zhenguo | wanghao: if it's just uuid, the object is not needed | 06:38 |
| wanghao | zhenguo: 'just return node uuid' is a doc string mistake, haha. | 06:38 |
| zhenguo | wanghao: hah | 06:38 |
| wanghao | zhenguo: en I see | 06:39 |
| wanghao | okay, you have me here, I will update the code. | 06:39 |
| zhenguo | wanghao: thanks | 06:39 |
| liusheng | accoding to the agent layer implementation, it doesn't only return the node uuds. | 06:39 |
| zhenguo | liusheng: yes, and it shouldn't just return uuid | 06:40 |
| wanghao | But, we didn't need the link, right? | 06:40 |
| wanghao | since we didn't have get single one method in API. | 06:40 |
| zhenguo | wanghao: do we support to get one node details? | 06:40 |
| wanghao | no | 06:40 |
| zhenguo | wanghao: do we need a get API? | 06:41 |
| wanghao | since you have got all manageable nodes in one time. | 06:41 |
| zhenguo | wanghao: and make list API just return simple things | 06:41 |
| wanghao | I don't think we need a get API. | 06:41 |
| liusheng | wanghao zhenguo seems only twe APIs, right ? | 06:41 |
| zhenguo | I find cinder provider such APi | 06:41 |
| zhenguo | list get and post | 06:42 |
| liusheng | not sure in Cinder, the return of get_one is same with one items of the return of get_all | 06:42 |
| zhenguo | seems not | 06:43 |
| zhenguo | get_one return more details | 06:43 |
| wanghao | just index, detail and post | 06:43 |
| wanghao | not get single one API | 06:43 |
| zhenguo | you mean detail is also index? | 06:43 |
| zhenguo | ok, I see | 06:44 |
| zhenguo | if we don't need get_one, we can't provide links :D | 06:44 |
| wanghao | in Cinder, bascally just index, detail, get_one, one items of detail is same as return of get_one. | 06:46 |
| wanghao | but, | 06:46 |
| wanghao | for manageable volumes api, there is no get_one api. | 06:46 |
| wanghao | just index, and detail. detail will show some more information of manageable volumes. | 06:47 |
| wanghao | so, | 06:47 |
| zhenguo | we can follow cinder :D | 06:47 |
| liusheng | yes, seem, the details is also a list api | 06:47 |
| zhenguo | one summary and one detail list API :D | 06:47 |
| wanghao | in mogan, I just want to use one api to show all information, it's get_all. | 06:47 |
| liusheng | I agree one API is enough | 06:47 |
| zhenguo | ok | 06:48 |
| zhenguo | it's fine with me | 06:48 |
| zhenguo | so one API with details | 06:48 |
| wanghao | okay, I will change the code ASAP. | 06:48 |
| zhenguo | thanks | 06:48 |
| wanghao | okay | 06:53 |
| wanghao | seems we didn't need another object define in Objects. | 06:54 |
| wanghao | I will covernt the dict to API object directly. | 06:54 |
| wanghao | that's enough. | 06:54 |
| zhenguo | liusheng: is this https://github.com/openstack/mogan/blob/master/mogan/scheduler/filter_scheduler.py#L99-L100 needed? | 07:02 |
| liusheng | zhenguo: seems, the return of get_filtered_resource_providers could be a None | 07:12 |
| zhenguo | liusheng: ok | 07:13 |
| zhenguo | liusheng: a bad API, hah | 07:13 |
| liusheng | zhenguo: hah, yes | 07:13 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheuling https://review.openstack.org/491695 | 07:13 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add checks for aggregate availability_zone https://review.openstack.org/489876 | 07:21 |
| zhenguo | liusheng: seems we need nested resource providers to support raid as we need disk informations | 07:25 |
| liusheng | zhenguo: we need to know the amount and capacity of disks, right ? | 07:27 |
| zhenguo | liusheng: yes, and users may also want to know the type of the disks like ssd or hdd | 07:27 |
| openstackgerrit | Tao Li proposed openstack/mogan master: Manage existing BMs: Part-2 https://review.openstack.org/481544 | 07:28 |
| liusheng | zhenguo: hmm, that seems need more disk info for scheduling | 07:29 |
| zhenguo | liusheng: so I would like to wait for nested resource providers | 07:30 |
| liusheng | zhenguo: not sure how long placement guy can finish that | 07:30 |
| zhenguo | liusheng: it will be soon :D | 07:30 |
| zhenguo | liusheng: so before Pike we don't add new tasks | 07:31 |
| zhenguo | liusheng: maybe I can make some time to work with wanghao for the boot from volume one | 07:31 |
| liusheng | zhenguo: ok, sounds good | 07:31 |
| wanghao | zhenguo: thanks, that will be greate. | 07:33 |
| zhenguo | wanghao: let's try to get that done | 07:33 |
| wanghao | zhenguo: sure | 07:35 |
| zhenguo | liusheng, wanghao, litao__: for server groups, do you like affinity_zone or affinity_group | 07:38 |
| wanghao | affinity_zone | 07:39 |
| wanghao | sounds a little werid in server groups with affinity_group. | 07:40 |
| liusheng | zhenguo: affinity_group may make user confused with server_group | 07:40 |
| wanghao | yes | 07:40 |
| litao__ | zhenguo: Does any project use affinity_zone? | 07:40 |
| zhenguo | hah, ok, so we will keep affinity zone | 07:40 |
| zhenguo | litao__: no, it's invented by us :D | 07:40 |
| litao__ | zhenguo: what is the difference between server_group and affinity_group, I remember it is a same thing in nova | 07:42 |
| zhenguo | litao__: nova's server group is on the same host or different host, but we don't have host notion | 07:43 |
| zhenguo | litao__: so we need a logical affinity_zone to achieve such affinity or anti-affinity | 07:43 |
| litao__ | zhenguo: OK, I see | 07:44 |
| litao__ | zhenguo: it's ok | 07:44 |
| zhenguo | litao__: ok | 07:45 |
| zhenguo | litao__: btw, please condier the ironic bug we reporeted when got time, they marked it as RFE | 07:46 |
| litao__ | zhenguo: yes , I see. I will do it later | 07:49 |
| zhenguo | litao__: thanks, it's a bp in ironic, so need to provide a spec there | 07:49 |
| litao__ | zhenguo: ok, btw, why do they use bugs system with RFE flag rather than blueprint system to trace a feature . | 07:52 |
| zhenguo | litao__: they find bp is hard to use :D | 07:54 |
| zhenguo | litao__: as we introduced specs, bp is really not needed | 07:54 |
| zhenguo | litao__: so a light bp system make things easy to use | 07:55 |
| litao__ | zhenguo: yes, but i think bp system is clear to learn all the features | 07:56 |
| zhenguo | litao__: release notes aim to provide that | 07:56 |
| litao__ | zhenguo: hah, I will learn more. | 07:58 |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 07:58 |
| zhenguo | litao__: hah | 07:58 |
| wanghao | guys, I updated the manage existing bms patch according our reviews, it's more beautiful now. | 08:01 |
| zhenguo | wanghao: cool | 08:04 |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 08:05 |
| wanghao | hi guys, when you reinstall the devstack env, did you use the ./unstack.sh, it's enough, right? | 08:13 |
| wanghao | and then just use ./stack.sh again. | 08:14 |
| zhenguo | wanghao: yes | 08:18 |
| zhenguo | wanghao: you can use our new local.conf in dev-quickstart | 08:19 |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 08:54 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add checks for aggregate availability_zone https://review.openstack.org/489876 | 08:58 |
| openstackgerrit | wanghao proposed openstack/mogan master: Remove unused function in Mogan https://review.openstack.org/491725 | 09:00 |
| wanghao | zhenguo: sure | 09:03 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling https://review.openstack.org/491695 | 09:26 |
| *** wanghao has quit IRC | 09:28 | |
| zhenguo | liusheng: if we don't specify aggregates when claiming servers, it will use all nodes satisfied with resource_class? | 09:42 |
| liusheng | zhenguo: I think so | 09:43 |
| zhenguo | liusheng: ok | 09:43 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling https://review.openstack.org/491695 | 09:48 |
| openstackgerrit | liusheng proposed openstack/mogan master: Fix the config sample generation https://review.openstack.org/491742 | 10:03 |
| zhenguo | liusheng: need your review on this https://review.openstack.org/#/c/470927/ , the node aggregates task is almost done :D | 10:18 |
| openstackgerrit | Merged openstack/mogan-specs master: Update new-flavor specs https://review.openstack.org/489167 | 10:22 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Add aggregates filters when do scheduling https://review.openstack.org/491695 | 11:37 |
| openstackgerrit | ShangXiao proposed openstack/mogan master: [Trivialfix]Fix typos in mogan https://review.openstack.org/491770 | 12:03 |
| *** litao__ has quit IRC | 12:04 | |
| openstackgerrit | Merged openstack/mogan master: Remove unused function in Mogan https://review.openstack.org/491725 | 13:37 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!