| *** wanghao has quit IRC | 00:34 | |
| *** wanghao has joined #openstack-mogan | 00:34 | |
| *** wanghao has quit IRC | 00:50 | |
| *** wanghao has joined #openstack-mogan | 00:52 | |
| zhenguo | dims: seems nobody will go there :( | 00:55 |
|---|---|---|
| zhenguo | dims: all contributors are from china, hah | 00:55 |
| dims | zhenguo : no worries. if you give me a presentation/slides, i can share it with them | 00:56 |
| zhenguo | dims: bit thanks, I will prepare one :D | 00:56 |
| zhenguo | dims: s/bit/big | 00:57 |
| dims | zhenguo : in the process, i'll learn too :) | 00:57 |
| dims | haha | 00:57 |
| zhenguo | dims: hah | 00:57 |
| *** openstackgerrit has joined #openstack-mogan | 01:54 | |
| openstackgerrit | wanghao proposed openstack/mogan master: Add some missing logs in Mogan https://review.openstack.org/492917 | 01:54 |
| *** litao__ has joined #openstack-mogan | 02:10 | |
| litao__ | test | 02:10 |
| zhenguo | sup litao__ | 02:11 |
| litao__ | zhenguo, liusheng : Pls see my comments in my patch | 02:11 |
| litao__ | zhenguo: hah | 02:11 |
| zhenguo | litao__: ok | 02:11 |
| liusheng | litao__: just replied in patch | 02:21 |
| litao__ | liusheng: thanks | 02:21 |
| liusheng | litao__: np :) | 02:22 |
| litao__ | liusheng: The NetworkError exception don't record the stack information | 02:24 |
| liusheng | litao__: will it be catched in top layer ? | 02:26 |
| zhenguo | litao__: I will clean up the flavor disabled check on engine/api side | 02:26 |
| litao__ | zhenguo: ok, i will add it in controller function | 02:27 |
| zhenguo | litao__: ok, thanks! | 02:27 |
| litao__ | liusheng: no | 02:27 |
| litao__ | liusheng: It doesnât save and reraise the exception | 02:28 |
| wanghao | zhenguo: ping | 02:28 |
| zhenguo | wanghao: pong | 02:28 |
| wanghao | zhenguo: in manage existing patch, you mean we also need to return the portgroup_uuid of a port, right? | 02:28 |
| wanghao | or detail information of this portgroup? | 02:29 |
| zhenguo | wanghao: seems we don't need to return port or portgroup uuids | 02:29 |
| zhenguo | wanghao: we need to check whether it's associated with a neutron network | 02:29 |
| zhenguo | wanghao: return the network info is enough? | 02:30 |
| wanghao | zhenguo: this check will be in manage server api. | 02:30 |
| wanghao | zhenguo: I mean the get manageable server api. | 02:30 |
| zhenguo | wanghao: your patch? | 02:30 |
| wanghao | zhenguo: yeah, : ) | 02:30 |
| zhenguo | wanghao: oh, I didn't find that | 02:31 |
| wanghao | zhenguo: I saw your review, you suggest we should get portgroup as well as port. | 02:31 |
| liusheng | litao__: so why raise an exception won't record the traceback ? | 02:32 |
| zhenguo | wanghao: yes, should alos consider portgroup | 02:32 |
| zhenguo | wanghao: but I don't find where you check the existing of neutron network association | 02:32 |
| wanghao | zhenguo: do you think we need to check the neutron network association in this patch? | 02:34 |
| zhenguo | wanghao: yes I think so | 02:34 |
| litao__ | liusheng: we catch all exceptions and reraised another exception 'NetworkError', so the stack of original exception was not recorded | 02:34 |
| wanghao | zhenguo: I mean, maybe operators didn't create neutron ports yet when he got the manageable servers. | 02:34 |
| zhenguo | wanghao: so that's not manageable | 02:34 |
| litao__ | liusheng: Use 'exception' will log the stack of original exception | 02:35 |
| zhenguo | wanghao: we will not create the port at all | 02:35 |
| wanghao | zhenguo: no no, I tought the case is : the operator should get the managable servers first, and then he need to do some prepare work, like create neturon port. | 02:36 |
| litao__ | zhenguo: It is not necessary to associate a neutron port when adopting a bare metal server in ironic | 02:36 |
| zhenguo | wanghao: who's the operator | 02:36 |
| zhenguo | wanghao: our api is for admins, which means every tenant admin can get the manageable servers | 02:37 |
| wanghao | zhenguo: and ? | 02:37 |
| zhenguo | wanghao: we don't have a api for them to associate neutron port with the server | 02:38 |
| zhenguo | wanghao: but not sure if we allow to manage a serve without any netowrk connection | 02:38 |
| zhenguo | wanghao: as we provide attach interface api | 02:38 |
| liusheng | litao__: it is not like what you said, I just tested in my env | 02:39 |
| wanghao | zhenguo: I'm a little confuse, when mogan create server, it will create neutron port and associate it with the node, right?> | 02:40 |
| liusheng | litao__: it will record the exception traceback | 02:40 |
| litao__ | liusheng: ok, i will check | 02:40 |
| zhenguo | wanghao: yes | 02:40 |
| zhenguo | wanghao: but for managing runing servers, we will not go though the workflow | 02:40 |
| zhenguo | wanghao: manage is not create | 02:41 |
| liusheng | litao__: oh, if you want the traceback of original exception, the log.exception is better | 02:43 |
| liusheng | litao__: but that will flush many exception tracebacks in log file, I think it is a bit redundant, but if you stick on you chang, I am ok | 02:45 |
| liusheng | litao__: s/you chang/your change | 02:46 |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Remove the duplicate flavor disable check https://review.openstack.org/494771 | 02:47 |
| liusheng | zhenguo: do you think will we add a "affinity_zone" field to server object ? | 02:52 |
| zhenguo | liusheng: not sure, used for scheduling? | 02:53 |
| zhenguo | liusheng: seems a bit strange to add that to server abject | 02:53 |
| zhenguo | liusheng: you mentioned you will add affinity_zones in the server group object, | 02:53 |
| liusheng | zhenguo: yes, I agree, In Nova, the affinity is related with a host, and it is easy to get the host list from server group's members, since it is easy to get the host list form a server list | 02:54 |
| liusheng | zhenguo: but in Mogan, it is not easy to get the affinity zone list from a server list | 02:54 |
| zhenguo | liusheng: it's not the same with nova host, hah | 02:55 |
| zhenguo | liusheng: affinity zone is just a logical thing | 02:55 |
| liusheng | zhenguo: but similar when we talking affinity, hah | 02:55 |
| liusheng | zhenguo: yes | 02:55 |
| zhenguo | liusheng: hah | 02:55 |
| liusheng | zhenguo: so just need to disscuss if we will add a "affinity_zone" field in server object, if so, things will become simple, if not things become complex | 02:56 |
| zhenguo | liusheng: why | 02:57 |
| zhenguo | liusheng: if you added the affinity zones to server group seems it's not complex | 02:57 |
| liusheng | zhenguo: in scheduling for affinity or anti-affinity, we need to get a affinity zone list firstly from the affinity members | 02:57 |
| liusheng | zhenguo: s/ from the affinity members/from the server group members | 02:58 |
| zhenguo | liusheng: you can get it from the server group, right? | 02:58 |
| liusheng | zhenguo: yes, that is a way | 02:58 |
| zhenguo | liusheng: you mentioned nova server group also have a hosts field, right? | 02:59 |
| liusheng | zhenguo: in Nova the server group object has a host field, but the host field is only existed in server group object, not in db table | 02:59 |
| liusheng | zhenguo: yes | 02:59 |
| liusheng | zhenguo: when get the server_group.hosts, it will traverse the server_group.members to get the host list | 02:59 |
| zhenguo | liusheng: you mean they will get it from members when construct the server group object? | 02:59 |
| liusheng | zhenguo: yes | 02:59 |
| zhenguo | liusheng: hah, sounds bad | 03:00 |
| zhenguo | liusheng: we can just save it to db, we are not same with nova | 03:00 |
| liusheng | zhenguo: yes, but comparing with nova implementation, we'd better to maintain the affinity_zones of a server group, joining in when create a server, leaving when delete a server | 03:01 |
| liusheng | zhenguo: s/we'd better t/we have to | 03:02 |
| zhenguo | liusheng: aha, yes | 03:02 |
| liusheng | zhenguo: so things is a bit complex, hah | 03:02 |
| zhenguo | liusheng: seems yes | 03:03 |
| zhenguo | liusheng: that means when a server leave the server group, you need to list the aggregates of and do many things :( | 03:04 |
| liusheng | zhenguo: yes, | 03:05 |
| zhenguo | liusheng: seems not that complex | 03:07 |
| zhenguo | liusheng: it just happen when it's anti affinity | 03:07 |
| liusheng | zhenguo: for affinity, when the last server deleted, we need to remove the affinity zone from server_group.affinity_zones | 03:08 |
| zhenguo | liusheng: yes, so the question is how we get the affinity zone from server, right | 03:08 |
| liusheng | zhenguo: yes, we can get it, but it is more complex than we getting host from a instance in Nova, hah | 03:09 |
| zhenguo | liusheng: you can add a new db api to provide list aggregate by node and metadata key, then got the value | 03:09 |
| zhenguo | liusheng: not that more | 03:10 |
| zhenguo | liusheng: just a sql | 03:10 |
| zhenguo | liusheng: and in db, they also need one more sql when construct the server group object | 03:10 |
| zhenguo | liusheng: I mean in nova | 03:10 |
| liusheng | zhenguo: hmm, sounds reasonable | 03:10 |
| zhenguo | liusheng: ah, seems we don't save nodes with aggregate, haha | 03:11 |
| liusheng | zhenguo: ... we need to call placement api ? | 03:12 |
| zhenguo | liusheng: we have a cache | 03:12 |
| liusheng | zhenguo: oh, yes | 03:12 |
| zhenguo | liusheng: and support list aggregate by node | 03:12 |
| liusheng | zhenguo: yes, if we aggree that won't add the affinity_zone field to server object, I will follow this way | 03:14 |
| zhenguo | liusheng: you can try, but then if you find it's complex, it's ok for me to add an affinity zone to server object | 03:14 |
| liusheng | zhenguo: ok, thanks for disscussion | 03:14 |
| zhenguo | liusheng: we can not expose it to users | 03:14 |
| liusheng | zhenguo: yes | 03:14 |
| zhenguo | liusheng: maybe that's a good way | 03:15 |
| liusheng | zhenguo: will try without that | 03:15 |
| liusheng | zhenguo: hah | 03:15 |
| zhenguo | liusheng: as admins maybe need to know which affinity zone it's in | 03:15 |
| zhenguo | lol | 03:15 |
| liusheng | zhenguo: so ? | 03:15 |
| liusheng | lol | 03:15 |
| zhenguo | liusheng: so maybe follow you first proposal, lol | 03:15 |
| liusheng | zhenguo: but a bit concern, that metadata of aggreaget may be updated by admins | 03:16 |
| zhenguo | liusheng: tha's ok | 03:16 |
| zhenguo | liusheng: just like availability zone can update the admins | 03:16 |
| liusheng | zhenguo: it is need to keep consistent of aggregate with the server's affinity group | 03:16 |
| zhenguo | liusheng: we dont' ensure that, if admins do want to make it happen | 03:17 |
| liusheng | zhenguo: that need the admins be well trained.. | 03:17 |
| zhenguo | liusheng: we can do some extra limitations for aggregate operations with affinity zone later | 03:18 |
| liusheng | zhenguo: ok | 03:18 |
| zhenguo | liusheng: like when there are nodes in the affinity zone aggregate, it's not allowed to be update or remove | 03:18 |
| liusheng | zhenguo: so if a server in a affinity zone, the affinity zone metadata in aggregate cannot be update ? | 03:19 |
| zhenguo | liusheng: mean affinity zone key/value pair | 03:20 |
| liusheng | zhenguo: yes | 03:20 |
| wanghao | zhenguo: yes, manage is not create, admin need to specify the port to manage the server, so we can check the port in manage process. | 03:20 |
| zhenguo | liusheng: you can add such following up patches later | 03:20 |
| liusheng | zhenguo: ok | 03:20 |
| wanghao | zhenguo: I just think we need to check the port in get manageable server phase. | 03:21 |
| wanghao | we didn't need/we need | 03:21 |
| zhenguo | wanghao: seems we don't need admins to specify the port | 03:21 |
| zhenguo | wanghao: at first, I think admins don't need to specify anything when managing a server ,lol | 03:22 |
| zhenguo | wanghao: maybe we just don't need to specify anything | 03:23 |
| zhenguo | wanghao: we just add it to our db | 03:23 |
| wanghao | zhenguo: you mean admins should create the neutron port and associate it with node's port at prepare phase? | 03:23 |
| zhenguo | wanghao: yes, if operators want to make it manageable, they need to prepare everything for us | 03:24 |
| wanghao | zhenguo: and then mogan just query them and add it to db? | 03:24 |
| zhenguo | wanghao: yes, just like cinder | 03:24 |
| wanghao | zhenguo: cinder is not only adding it to db, it also need to change the volume's name in driver or mapping it. | 03:25 |
| litao__ | zhenguo: will we cal plun_vif api to associate a neutron port before managing it? | 03:26 |
| zhenguo | wanghao: we dont' need that, hah | 03:26 |
| wanghao | zhenguo: I saw your point, but I just think Mogan can relax some work from admins. | 03:26 |
| zhenguo | litao__: I think we don't need | 03:26 |
| zhenguo | wanghao: but that's hard and complex | 03:26 |
| wanghao | zhenguo: okay, I see, I will think it more and talked with litao__. | 03:27 |
| zhenguo | wanghao: ok, | 03:27 |
| wanghao | zhenguo: as you said, we need to check the neutron port when we got the manageable servers. | 03:27 |
| zhenguo | wanghao: maybe need to discuss more, | 03:28 |
| wanghao | zhenguo: yeah, thanks for discuusing this | 03:28 |
| zhenguo | wanghao: whether we allow to manage a server with no neutron port assocaite | 03:28 |
| zhenguo | wanghao: like it's running in another private network maybe | 03:28 |
| zhenguo | wanghao: it's still running, and we don't want to make it down to be managed by us | 03:29 |
| * zhenguo brb | 03:30 | |
| wanghao | zhenguo: I think we should allow this case, that cloud be happened. | 05:40 |
| zhenguo | wanghao: yes | 05:40 |
| wanghao | zhenguo: so my idea is admin can specify the neutron port or not, if there are neutron port, mogan will plugin vif in node. | 05:42 |
| wanghao | zhenguo: if not, mogan will do nothing. | 05:42 |
| zhenguo | wanghao: you mean only call ironic attach_vif like mogan attaching interfaces? | 05:44 |
| wanghao | zhenguo: yes, if admin specify the port in manage api, mogan will call ironic attch_vif. | 05:45 |
| wanghao | attach_vif. | 05:45 |
| wanghao | zhenguo: mogan didn't need to create port, that is admin's prepare work. Mogan just attach it with node. | 05:46 |
| zhenguo | wanghao: so if the node already got a network connected, it will fail or be replaced? | 05:48 |
| wanghao | zhenguo: if node has already got neutron ports, then admin need to specify them, mogan just check the if the port is matching, no need to attach vif. and it will success. | 05:51 |
| zhenguo | wanghao: if it alrady got neutron ports, why admin need to specify them | 05:51 |
| wanghao | zhenguo: it's just for simple our process in Mogan, of course, mogan also can check them by itself. | 05:52 |
| wanghao | zhenguo: I think both way is ok. | 05:52 |
| zhenguo | wanghao: I think in get magageable phase, we should check it | 05:53 |
| zhenguo | wanghao: I would like to keep our API clean and simple, manage is not like create, we don't create anyting | 05:53 |
| zhenguo | wanghao: just manage the existing resources | 05:54 |
| wanghao | zhenguo: we didn't create anything, we just attach vif. | 05:54 |
| zhenguo | wanghao: if users want to add neutron network connections, they can attach interfaces later | 05:54 |
| zhenguo | wanghao: it's not that easy to make attach vif happen | 05:54 |
| wanghao | zhenguo: so we also should not to check the network connection in get managable servers. | 05:55 |
| zhenguo | wanghao: like they may connect to a private network. | 05:55 |
| zhenguo | wanghao: seems yes | 05:55 |
| zhenguo | wanghao: so, get manageable servers seems simple now | 05:56 |
| wanghao | zhenguo: en yes, we just need to return the internal_info about the port, if the node has the network connection, it is it. | 05:56 |
| zhenguo | wanghao: and manage api only checks network, image... if they are openstack resources, we set them to server | 05:56 |
| wanghao | zhenguo: if node didn't have neutron port, mogan also didn't set port to server db, right? | 05:57 |
| zhenguo | wanghao: some old deployment may also use extra | 05:57 |
| zhenguo | wanghao: yes, just like image | 05:57 |
| wanghao | zhenguo: en , yes, will return both. | 05:57 |
| zhenguo | wanghao: anyway the server can keep running | 05:58 |
| wanghao | zhenguo: okay, that's clear much. | 05:58 |
| zhenguo | wanghao: maybe need to update the spec first to get more suggestiosn from others | 05:58 |
| zhenguo | wanghao: we can make some time to further discuss this with all mogan guys :D | 05:59 |
| wanghao | zhenguo: okay | 05:59 |
| wanghao | both patch and spec will updated. | 05:59 |
| zhenguo | wanghao: hah, thanks | 05:59 |
| wanghao | but we must be hurry, there is no much time left. | 06:00 |
| zhenguo | wanghao: another thing is about the flavor | 06:00 |
| zhenguo | wanghao: hah, sure | 06:00 |
| zhenguo | wanghao: I would like to refactor the server flavor part, maybe including more details instead of just the flavor uuid. | 06:01 |
| zhenguo | wanghao: so for manging servers, we can just leave flavor empty now | 06:01 |
| wanghao | zhenguo: so after managing server, the flavor of server could be None, right. | 06:02 |
| zhenguo | wanghao: ok, | 06:03 |
| wanghao | zhenguo: but after your refactor done, we still need admin to specify the flavor in manage api. | 06:04 |
| wanghao | zhenguo: maybe in Queens? | 06:04 |
| zhenguo | wanghao: it's strange to let admin to specify a flavor | 06:04 |
| zhenguo | wanghao: as my understanding, flavor is used to choosing a type of server | 06:04 |
| zhenguo | wanghao: for managing servers, we can just leave it empty | 06:05 |
| wanghao | zhenguo: I remember flavor could have some hardware arguments, like cpu, memory, etc. and resource_class. | 06:06 |
| zhenguo | wanghao: we already get raid of them, only resource class left | 06:07 |
| zhenguo | wanghao: flavor can't give us anything now, | 06:07 |
| wanghao | zhenguo: okay, it's not like nova's flavor now. | 06:07 |
| zhenguo | wanghao: it just used to schedule a node | 06:08 |
| zhenguo | wanghao: yes | 06:08 |
| wanghao | zhenguo: it seems to change many times, I was confused little haha | 06:08 |
| zhenguo | wanghao: lol | 06:09 |
| wanghao | zhenguo: so there is no need for flavor in manage api, but we still need the node has the resource class, right. | 06:09 |
| zhenguo | wanghao: yes, | 06:09 |
| wanghao | zhenguo: we will set the resource class to our db. | 06:09 |
| zhenguo | wanghao: otherwise it will not go to placement after we delete it | 06:10 |
| zhenguo | wanghao: to placement :D | 06:10 |
| wanghao | zhenguo: okay | 06:10 |
| wanghao | flavor: no need, port: no need. | 06:11 |
| * zhenguo brb | 06:15 | |
| openstackgerrit | wanghao proposed openstack/mogan master: Manage existing BMs: Part-1 https://review.openstack.org/479660 | 06:32 |
| *** wanghao_ has joined #openstack-mogan | 06:33 | |
| zhenguo | liusheng: can we get rid of flavor_uuid from server | 06:34 |
| liusheng | zhenguo: why do that ? | 06:35 |
| zhenguo | liusheng: why we need to associate a flavor | 06:36 |
| zhenguo | liusheng: seems flavor is used for scheduling, after scheduling, why we still need it | 06:36 |
| *** wanghao has quit IRC | 06:36 | |
| liusheng | zhenguo: but seems flavor can indicates the size info(or resource class) of a server | 06:37 |
| zhenguo | liusheng: yes, we can save that there | 06:38 |
| zhenguo | liusheng: save the flavor description to server | 06:38 |
| zhenguo | liusheng: but maybe admins want to know the resource class, traits, aggregates info | 06:39 |
| liusheng | zhenguo: yes, may that are usful info | 06:39 |
| liusheng | zhenguo: and users may want to classify the servers by resource class | 06:39 |
| zhenguo | liusheng: seems yes | 06:40 |
| liusheng | zhenguo: hah | 06:40 |
| zhenguo | liusheng: still think we should return some details with the server | 06:41 |
| liusheng | zhenguo: we disscussed that the flavor more like a human class of a server, e.g. gold, silver | 06:44 |
| zhenguo | liusheng: yes | 06:44 |
| zhenguo | liusheng: do you like nova's way to return addresses with instance | 06:46 |
| zhenguo | liusheng: "addresses": { | 06:46 |
| zhenguo | "private": [ | 06:46 |
| zhenguo | { | 06:46 |
| zhenguo | "OS-EXT-IPS-MAC:mac_addr": "aa:bb:cc:dd:ee:ff", | 06:46 |
| zhenguo | "OS-EXT-IPS:type": "fixed", | 06:46 |
| zhenguo | "addr": "192.168.0.3", | 06:46 |
| zhenguo | "version": 4 | 06:46 |
| zhenguo | } | 06:46 |
| zhenguo | ] | 06:46 |
| zhenguo | }, | 06:46 |
| liusheng | zhenguo: yes, but not sure if it is too redundant | 06:48 |
| *** wanghao_ has quit IRC | 06:48 | |
| liusheng | zhenguo: at least, the ip address are required | 06:48 |
| zhenguo | liusheng: replace server nics with this? | 06:49 |
| liusheng | zhenguo: it is ok, but may we can return a more simple info ? | 06:49 |
| liusheng | zhenguo: since we have a sapareted network API | 06:49 |
| zhenguo | liusheng: get rid of version? | 06:49 |
| liusheng | zhenguo: how aobut only ip address ? | 06:50 |
| liusheng | zhenguo: and network name | 06:50 |
| zhenguo | liusheng: do you know when present the instance in dashbord, what will presence | 06:50 |
| liusheng | zhenguo: not sure.. | 06:51 |
| zhenguo | liusheng: who has a dashboard to see.... | 06:51 |
| liusheng | zhenguo: let ask | 06:51 |
| zhenguo | liusheng: ok | 06:52 |
| zhenguo | liusheng: I remember only network name and ip | 06:52 |
| liusheng | zhenguo: hah | 06:52 |
| zhenguo | liusheng: we can keep consistent with the dashbaord I think | 06:52 |
| liusheng | zhenguo: yes, aggree, it can only be a net info overview | 06:53 |
| zhenguo | liusheng: yes | 06:53 |
| liusheng | zhenguo: just confirmed, only network name and ip address | 06:58 |
| zhenguo | liusheng: hah, that's cool | 06:58 |
| *** wanghao has joined #openstack-mogan | 07:00 | |
| zhenguo | liusheng: also need to return the ip type to indicate whether it's a floating ip or not | 07:14 |
| liusheng | zhenguo: seems the network name can indicate that in some cases | 07:16 |
| zhenguo | liusheng: how? | 07:17 |
| zhenguo | liusheng: I find on dashboard, they also check the type and display floating ip with 'Floating IP' | 07:17 |
| liusheng | zhenguo: oh, I didn't found floating ip field, may because the instance don't have floatingip | 07:18 |
| zhenguo | liusheng: hah, yes, I just went though the code on horizon :D | 07:18 |
| zhenguo | *through | 07:18 |
| liusheng | zhenguo: cool | 07:18 |
| zhenguo | liusheng: I will work on that, as there's nothing to do now :D | 07:20 |
| liusheng | zhenguo: hah | 07:20 |
| openstackgerrit | wanghao proposed openstack/mogan-specs master: No need flavor and network in managing server https://review.openstack.org/494980 | 07:22 |
| liusheng | zhenguo: keystone of our env is ok | 07:38 |
| zhenguo | liusheng: cool | 07:46 |
| *** wanghao has quit IRC | 07:51 | |
| *** wanghao has joined #openstack-mogan | 07:52 | |
| *** wanghao_ has joined #openstack-mogan | 07:53 | |
| *** wanghao has quit IRC | 07:56 | |
| *** liusheng has quit IRC | 07:58 | |
| openstackgerrit | Xinran WANG proposed openstack/mogan master: Specify image when do rebuilding https://review.openstack.org/490421 | 07:59 |
| *** liusheng has joined #openstack-mogan | 08:04 | |
| openstackgerrit | Xinran WANG proposed openstack/mogan master: support specifying port_id when attaching interface https://review.openstack.org/494121 | 08:33 |
| *** wanghao_ has quit IRC | 08:54 | |
| *** wanghao has joined #openstack-mogan | 09:23 | |
| *** wanghao has quit IRC | 09:26 | |
| openstackgerrit | Zhenguo Niu proposed openstack/mogan master: Replace server fault_info with fault https://review.openstack.org/495138 | 09:35 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-moganclient master: Updated from global requirements https://review.openstack.org/494902 | 11:41 |
| *** litao__ has quit IRC | 11:49 | |
| openstackgerrit | ShaoHe Feng proposed openstack/mogan master: Do not allow to remove flavor which is still in use. https://review.openstack.org/493412 | 12:54 |
| openstackgerrit | Merged openstack/mogan master: Trivial-Fix: Remove unused codes https://review.openstack.org/493424 | 13:01 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/mogan master: Updated from global requirements https://review.openstack.org/494831 | 13:34 |
| *** XueFeng has joined #openstack-mogan | 14:00 | |
| *** shaohe_feng has quit IRC | 15:12 | |
| *** shaohe_feng has joined #openstack-mogan | 15:13 | |
| *** XueFeng has quit IRC | 17:37 | |
| *** XueFeng has joined #openstack-mogan | 17:37 | |
| *** Xinran has quit IRC | 20:00 | |
| *** Xinran has joined #openstack-mogan | 20:01 | |
| *** XueFeng has quit IRC | 21:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!