Friday, 2017-08-18

*** wanghao has quit IRC00:34
*** wanghao has joined #openstack-mogan00:34
*** wanghao has quit IRC00:50
*** wanghao has joined #openstack-mogan00:52
zhenguodims: seems nobody will go there :(00:55
zhenguodims: all contributors are from china, hah00:55
dimszhenguo : no worries. if you give me a presentation/slides, i can share it with them00:56
zhenguodims: bit thanks, I will prepare one :D00:56
zhenguodims: s/bit/big00:57
dimszhenguo : in the process, i'll learn too :)00:57
zhenguodims: hah00:57
*** openstackgerrit has joined #openstack-mogan01:54
openstackgerritwanghao proposed openstack/mogan master: Add some missing logs in Mogan
*** litao__ has joined #openstack-mogan02:10
zhenguosup litao__02:11
litao__zhenguo,  liusheng : Pls see my comments in my patch02:11
litao__zhenguo: hah02:11
zhenguolitao__: ok02:11
liushenglitao__: just replied in patch02:21
litao__liusheng: thanks02:21
liushenglitao__: np :)02:22
litao__liusheng: The NetworkError exception don't record the stack information02:24
liushenglitao__: will it be catched in top layer ?02:26
zhenguolitao__: I will clean up the flavor disabled check on engine/api side02:26
litao__zhenguo: ok, i will add it in controller function02:27
zhenguolitao__: ok, thanks!02:27
litao__liusheng:  no02:27
litao__liusheng: It doesn‘t save and reraise the exception02:28
wanghaozhenguo: ping02:28
zhenguowanghao: pong02:28
wanghaozhenguo: in manage existing patch,  you mean we also need to return the portgroup_uuid of a port, right?02:28
wanghaoor detail information of this portgroup?02:29
zhenguowanghao: seems we don't need to return port or portgroup uuids02:29
zhenguowanghao: we need to check whether it's associated with a neutron network02:29
zhenguowanghao: return the network info is enough?02:30
wanghaozhenguo: this check will be in manage server api.02:30
wanghaozhenguo: I mean the get manageable server api.02:30
zhenguowanghao: your patch?02:30
wanghaozhenguo: yeah, : )02:30
zhenguowanghao: oh, I didn't find that02:31
wanghaozhenguo: I saw your review,  you suggest we should get portgroup as well as port.02:31
liushenglitao__: so why raise an exception won't record the traceback ?02:32
zhenguowanghao: yes, should alos consider portgroup02:32
zhenguowanghao: but I don't find where you check the existing of neutron network association02:32
wanghaozhenguo: do you think we need to check the neutron network association in this patch?02:34
zhenguowanghao: yes I think so02:34
litao__liusheng: we catch all exceptions and reraised another exception 'NetworkError', so the stack of original exception was not recorded02:34
wanghaozhenguo: I mean, maybe operators didn't create neutron ports yet when he got the manageable servers.02:34
zhenguowanghao: so that's not manageable02:34
litao__liusheng: Use 'exception' will log the stack of original exception02:35
zhenguowanghao: we will not create the port at all02:35
wanghaozhenguo: 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 ironic02:36
zhenguowanghao: who's the operator02:36
zhenguowanghao: our api is for admins, which means every tenant admin can get the manageable servers02:37
wanghaozhenguo: and ?02:37
zhenguowanghao: we don't have a api for them to associate neutron port with the server02:38
zhenguowanghao: but not sure if we allow to manage a serve without any netowrk connection02:38
zhenguowanghao: as we provide attach interface api02:38
liushenglitao__: it is not like what you said, I just tested in my env02:39
wanghaozhenguo: I'm a little confuse,  when mogan create server,  it will create neutron port and associate it with the node, right?>02:40
liushenglitao__: it will record the exception traceback02:40
litao__liusheng: ok, i will check02:40
zhenguowanghao: yes02:40
zhenguowanghao: but for managing runing servers, we will not go though the workflow02:40
zhenguowanghao: manage is not create02:41
liushenglitao__: oh, if you want the traceback of original exception, the log.exception is better02:43
liushenglitao__: 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 ok02:45
liushenglitao__: s/you chang/your change02:46
openstackgerritZhenguo Niu proposed openstack/mogan master: Remove the duplicate flavor disable check
liushengzhenguo: do you think will we add a "affinity_zone" field to server object ?02:52
zhenguoliusheng: not sure, used for scheduling?02:53
zhenguoliusheng: seems a bit strange to add that to server abject02:53
zhenguoliusheng: you mentioned you will add affinity_zones in the server group object,02:53
liushengzhenguo: 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 list02:54
liushengzhenguo: but in Mogan, it is not easy to get the affinity zone list from a server list02:54
zhenguoliusheng: it's not the same with nova host, hah02:55
zhenguoliusheng: affinity zone is just a logical thing02:55
liushengzhenguo: but similar when we talking affinity, hah02:55
liushengzhenguo: yes02:55
zhenguoliusheng: hah02:55
liushengzhenguo: 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 complex02:56
zhenguoliusheng: why02:57
zhenguoliusheng: if you added the affinity zones to server group seems it's not complex02:57
liushengzhenguo: in scheduling for affinity or anti-affinity, we need to get a affinity zone list firstly from the affinity members02:57
liushengzhenguo: s/ from the affinity members/from the server group members02:58
zhenguoliusheng: you can get it from the server group, right?02:58
liushengzhenguo: yes, that is a way02:58
zhenguoliusheng: you mentioned nova server group also have a hosts field, right?02:59
liushengzhenguo: in Nova the server group object has a host field, but the host field is only existed in server group object, not in db table02:59
liushengzhenguo: yes02:59
liushengzhenguo: when get the server_group.hosts, it will traverse the server_group.members to get the host list02:59
zhenguoliusheng: you mean they will get it from members when construct the server group object?02:59
liushengzhenguo: yes02:59
zhenguoliusheng: hah, sounds bad03:00
zhenguoliusheng: we can just save it to db, we are not same with nova03:00
liushengzhenguo: 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 server03:01
liushengzhenguo: s/we'd better t/we have to03:02
zhenguoliusheng: aha, yes03:02
liushengzhenguo: so things is a bit complex, hah03:02
zhenguoliusheng: seems yes03:03
zhenguoliusheng: that means when a server leave the server group, you need to list the aggregates  of and do many  things :(03:04
liushengzhenguo: yes,03:05
zhenguoliusheng: seems not that complex03:07
zhenguoliusheng: it just happen when it's anti affinity03:07
liushengzhenguo: for affinity, when the last server deleted, we need to remove the affinity zone from server_group.affinity_zones03:08
zhenguoliusheng: yes, so the question is how we get the affinity zone from server, right03:08
liushengzhenguo: yes, we can get it, but it is more complex than we getting host from a instance in Nova, hah03:09
zhenguoliusheng: you can add a new db api to provide list aggregate by node and metadata key, then got the value03:09
zhenguoliusheng: not that more03:10
zhenguoliusheng: just a sql03:10
zhenguoliusheng: and in db, they also need one more sql when construct the server group object03:10
zhenguoliusheng: I mean in nova03:10
liushengzhenguo: hmm, sounds reasonable03:10
zhenguoliusheng: ah, seems we don't save nodes with aggregate, haha03:11
liushengzhenguo: ... we need to call placement api ?03:12
zhenguoliusheng: we have a cache03:12
liushengzhenguo: oh, yes03:12
zhenguoliusheng: and support list aggregate by node03:12
liushengzhenguo: yes, if we aggree that won't add the affinity_zone field to server object, I will follow this way03:14
zhenguoliusheng: you can try, but then if you find it's complex, it's ok for me to add an affinity zone to server object03:14
liushengzhenguo: ok, thanks for disscussion03:14
zhenguoliusheng: we can not expose it to users03:14
liushengzhenguo: yes03:14
zhenguoliusheng: maybe that's a good way03:15
liushengzhenguo: will try without that03:15
liushengzhenguo: hah03:15
zhenguoliusheng: as admins maybe need to know which affinity zone it's in03:15
liushengzhenguo: so  ?03:15
zhenguoliusheng: so maybe follow you first proposal, lol03:15
liushengzhenguo: but a bit concern, that metadata of aggreaget may be updated by admins03:16
zhenguoliusheng: tha's ok03:16
zhenguoliusheng: just like availability zone can update the admins03:16
liushengzhenguo: it is need to keep consistent of aggregate with the server's affinity group03:16
zhenguoliusheng: we dont' ensure that, if admins do want to make it happen03:17
liushengzhenguo: that need the admins be well trained..03:17
zhenguoliusheng: we can do some extra limitations for aggregate operations with affinity zone later03:18
liushengzhenguo: ok03:18
zhenguoliusheng: like when there are nodes in the affinity zone aggregate, it's not allowed to be update or remove03:18
liushengzhenguo: so if a server in a affinity zone, the affinity zone metadata  in aggregate cannot be update ?03:19
zhenguoliusheng: mean affinity zone key/value pair03:20
liushengzhenguo: yes03:20
wanghaozhenguo: 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
zhenguoliusheng: you can add such following up patches later03:20
liushengzhenguo: ok03:20
wanghaozhenguo: I just think we need to check the port in get manageable server phase.03:21
wanghaowe didn't need/we need03:21
zhenguowanghao: seems we don't need admins to specify the port03:21
zhenguowanghao: at first, I think admins don't need to specify anything when managing a server ,lol03:22
zhenguowanghao: maybe we just don't need to specify anything03:23
zhenguowanghao: we just add it to our db03:23
wanghaozhenguo: you mean admins should create the neutron port and associate it with node's port at prepare phase?03:23
zhenguowanghao: yes, if operators want to make it manageable, they need to prepare everything for us03:24
wanghaozhenguo: and then mogan just query them and add it to db?03:24
zhenguowanghao: yes, just like cinder03:24
wanghaozhenguo: 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
zhenguowanghao: we dont' need that, hah03:26
wanghaozhenguo: I saw your point,  but I just think Mogan can relax some work from admins.03:26
zhenguolitao__: I think we don't need03:26
zhenguowanghao: but that's hard and complex03:26
wanghaozhenguo: okay, I see, I will think it more and talked with litao__.03:27
zhenguowanghao: ok,03:27
wanghaozhenguo: as you said, we need to check the neutron port  when we got the manageable servers.03:27
zhenguowanghao: maybe need to discuss more,03:28
wanghaozhenguo: yeah, thanks for discuusing this03:28
zhenguowanghao: whether we allow to manage a server with no neutron port assocaite03:28
zhenguowanghao: like it's running in another private network maybe03:28
zhenguowanghao: it's still running, and we don't want to make it down to be managed by us03:29
* zhenguo brb03:30
wanghaozhenguo: I think we should allow this case, that cloud be happened.05:40
zhenguowanghao: yes05:40
wanghaozhenguo: 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
wanghaozhenguo: if not,  mogan will do nothing.05:42
zhenguowanghao: you mean only call ironic attach_vif like mogan attaching interfaces?05:44
wanghaozhenguo: yes, if admin specify the port in manage api,  mogan will call ironic attch_vif.05:45
wanghaozhenguo: mogan didn't need to create port,  that is admin's prepare work.  Mogan just attach it with node.05:46
zhenguowanghao: so if the node already got a network connected, it will fail or be replaced?05:48
wanghaozhenguo: 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
zhenguowanghao: if it alrady got neutron ports, why admin need to specify them05:51
wanghaozhenguo: it's just for simple our process in Mogan,  of course, mogan also can check them by itself.05:52
wanghaozhenguo: I think both way is ok.05:52
zhenguowanghao: I think in get magageable phase, we should check it05:53
zhenguowanghao: I would like to keep our API clean and simple, manage is not like create, we don't create anyting05:53
zhenguowanghao: just manage the existing resources05:54
wanghaozhenguo: we didn't create anything, we just attach vif.05:54
zhenguowanghao: if users want to add neutron network connections, they can attach interfaces later05:54
zhenguowanghao: it's not that easy to make attach vif happen05:54
wanghaozhenguo: so we also should not to check the network connection in get managable servers.05:55
zhenguowanghao: like they may connect to a private network.05:55
zhenguowanghao: seems yes05:55
zhenguowanghao: so, get manageable servers seems simple now05:56
wanghaozhenguo: 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
zhenguowanghao: and manage api only checks network, image... if they are openstack resources, we set them to server05:56
wanghaozhenguo: if node didn't have neutron port,  mogan also didn't set port to server db, right?05:57
zhenguowanghao: some old deployment may also use extra05:57
zhenguowanghao: yes, just like image05:57
wanghaozhenguo: en , yes, will return both.05:57
zhenguowanghao: anyway the server can keep running05:58
wanghaozhenguo: okay, that's clear much.05:58
zhenguowanghao: maybe need to update the spec first to get more suggestiosn from others05:58
zhenguowanghao: we can make some time to further discuss this with all mogan guys :D05:59
wanghaozhenguo: okay05:59
wanghaoboth patch and spec will updated.05:59
zhenguowanghao: hah, thanks05:59
wanghaobut we must be hurry,  there is no much time left.06:00
zhenguowanghao: another thing is about the flavor06:00
zhenguowanghao: hah, sure06:00
zhenguowanghao: I would like to refactor the server flavor part, maybe including more details instead of just the flavor uuid.06:01
zhenguowanghao: so for manging servers, we can just leave flavor empty now06:01
wanghaozhenguo: so after managing server,  the flavor of server could be None, right.06:02
zhenguowanghao: ok,06:03
wanghaozhenguo: but after your refactor done,  we still need admin to specify the flavor in manage api.06:04
wanghaozhenguo: maybe in Queens?06:04
zhenguowanghao: it's strange to let admin to specify a flavor06:04
zhenguowanghao: as my understanding, flavor is used to choosing a type of server06:04
zhenguowanghao: for managing servers, we can just leave it empty06:05
wanghaozhenguo: I remember flavor could have some hardware arguments,  like cpu, memory, etc. and resource_class.06:06
zhenguowanghao: we already get raid of them, only resource class left06:07
zhenguowanghao: flavor can't give us anything now,06:07
wanghaozhenguo: okay, it's not like nova's flavor now.06:07
zhenguowanghao: it just used to schedule a node06:08
zhenguowanghao: yes06:08
wanghaozhenguo: it seems to change many times,  I was confused little haha06:08
zhenguowanghao: lol06:09
wanghaozhenguo: so there is no need for flavor in manage api,   but we still need the node has the resource class, right.06:09
zhenguowanghao: yes,06:09
wanghaozhenguo: we will set the resource class to our db.06:09
zhenguowanghao: otherwise it will not go to placement after we delete it06:10
zhenguowanghao: to placement :D06:10
wanghaozhenguo: okay06:10
wanghaoflavor: no need,   port: no need.06:11
* zhenguo brb06:15
openstackgerritwanghao proposed openstack/mogan master: Manage existing BMs: Part-1
*** wanghao_ has joined #openstack-mogan06:33
zhenguoliusheng: can we get rid of flavor_uuid from server06:34
liushengzhenguo: why do that ?06:35
zhenguoliusheng: why we need to associate a flavor06:36
zhenguoliusheng: seems flavor is used for scheduling, after scheduling, why we still need it06:36
*** wanghao has quit IRC06:36
liushengzhenguo: but seems flavor can indicates the size info(or resource class) of a server06:37
zhenguoliusheng: yes, we can save that there06:38
zhenguoliusheng: save the flavor description to server06:38
zhenguoliusheng: but maybe admins want to know the resource class, traits, aggregates info06:39
liushengzhenguo: yes, may that are usful info06:39
liushengzhenguo: and users may want to classify the servers by resource class06:39
zhenguoliusheng: seems yes06:40
liushengzhenguo: hah06:40
zhenguoliusheng: still think we should return some details with the server06:41
liushengzhenguo: we disscussed that the flavor more like a human class of a server, e.g. gold, silver06:44
zhenguoliusheng: yes06:44
zhenguoliusheng: do you like nova's way to return addresses with instance06:46
zhenguoliusheng:  "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": "",06:46
zhenguo                    "version": 406:46
zhenguo                }06:46
zhenguo            ]06:46
zhenguo        },06:46
liushengzhenguo: yes, but not sure if it is too redundant06:48
*** wanghao_ has quit IRC06:48
liushengzhenguo: at least, the ip address are required06:48
zhenguoliusheng: replace server nics with this?06:49
liushengzhenguo: it is ok, but may we can return a more simple info ?06:49
liushengzhenguo: since we have a sapareted network API06:49
zhenguoliusheng: get rid of version?06:49
liushengzhenguo: how aobut only ip address ?06:50
liushengzhenguo: and network name06:50
zhenguoliusheng: do you know when present  the instance in dashbord, what will presence06:50
liushengzhenguo: not sure..06:51
zhenguoliusheng: who has a dashboard to see....06:51
liushengzhenguo: let ask06:51
zhenguoliusheng: ok06:52
zhenguoliusheng: I remember only network name and ip06:52
liushengzhenguo: hah06:52
zhenguoliusheng: we can keep consistent with the dashbaord I think06:52
liushengzhenguo: yes, aggree, it can only be a net info overview06:53
zhenguoliusheng: yes06:53
liushengzhenguo: just confirmed, only network name and ip address06:58
zhenguoliusheng: hah, that's cool06:58
*** wanghao has joined #openstack-mogan07:00
zhenguoliusheng: also need to return the ip type to indicate whether it's a floating ip or not07:14
liushengzhenguo: seems the network name can indicate that in some cases07:16
zhenguoliusheng: how?07:17
zhenguoliusheng: I find on dashboard, they also check the type and display floating ip with 'Floating IP'07:17
liushengzhenguo: oh, I didn't found floating ip field, may because the instance don't have floatingip07:18
zhenguoliusheng: hah, yes, I just went though the code on horizon :D07:18
liushengzhenguo: cool07:18
zhenguoliusheng: I will work on that, as there's nothing to do now :D07:20
liushengzhenguo: hah07:20
openstackgerritwanghao proposed openstack/mogan-specs master: No need flavor and network in managing server
liushengzhenguo: keystone of our env is ok07:38
zhenguoliusheng: cool07:46
*** wanghao has quit IRC07:51
*** wanghao has joined #openstack-mogan07:52
*** wanghao_ has joined #openstack-mogan07:53
*** wanghao has quit IRC07:56
*** liusheng has quit IRC07:58
openstackgerritXinran WANG proposed openstack/mogan master: Specify image when do rebuilding
*** liusheng has joined #openstack-mogan08:04
openstackgerritXinran WANG proposed openstack/mogan master: support specifying port_id when attaching interface
*** wanghao_ has quit IRC08:54
*** wanghao has joined #openstack-mogan09:23
*** wanghao has quit IRC09:26
openstackgerritZhenguo Niu proposed openstack/mogan master: Replace server fault_info with fault
openstackgerritOpenStack Proposal Bot proposed openstack/python-moganclient master: Updated from global requirements
*** litao__ has quit IRC11:49
openstackgerritShaoHe Feng proposed openstack/mogan master: Do not allow to remove flavor which is still in use.
openstackgerritMerged openstack/mogan master: Trivial-Fix: Remove unused codes
openstackgerritOpenStack Proposal Bot proposed openstack/mogan master: Updated from global requirements
*** XueFeng has joined #openstack-mogan14:00
*** shaohe_feng has quit IRC15:12
*** shaohe_feng has joined #openstack-mogan15:13
*** XueFeng has quit IRC17:37
*** XueFeng has joined #openstack-mogan17:37
*** Xinran has quit IRC20:00
*** Xinran has joined #openstack-mogan20:01
*** XueFeng has quit IRC21:44

Generated by 2.15.3 by Marius Gedminas - find it at!