| *** chenzeng has joined #openstack-smaug | 00:13 | |
| *** chenzeng has quit IRC | 00:14 | |
| chenying | Hi eran, Could you help tag python-smaugclient a inital version? smaug-dashboard need a version of python-smaugclient, and add this to requirements.txt. | 01:45 |
|---|---|---|
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement nova protection plugin https://review.openstack.org/295618 | 02:22 |
| *** g00357909 has joined #openstack-smaug | 02:28 | |
| *** g00357909 is now known as gongxiaowei | 02:28 | |
| openstackgerrit | smile-luobin proposed openstack/smaug: Implement nova protection plugin https://review.openstack.org/295618 | 02:29 |
| openstackgerrit | WeAreFormalGroup proposed openstack/smaug: Implement glance protection plugin https://review.openstack.org/295752 | 03:10 |
| *** huayi has joined #openstack-smaug | 03:46 | |
| *** huayi has quit IRC | 04:09 | |
| *** huayi has joined #openstack-smaug | 04:09 | |
| *** huayi has quit IRC | 04:11 | |
| *** gongxiaowei has quit IRC | 04:41 | |
| *** zhonghua-lee has quit IRC | 04:56 | |
| *** zhonghua-lee has joined #openstack-smaug | 04:57 | |
| *** gongxiaowei has joined #openstack-smaug | 04:59 | |
| *** gongxiaowei has quit IRC | 06:00 | |
| *** huayi has joined #openstack-smaug | 06:09 | |
| *** gongxiaowei has joined #openstack-smaug | 06:10 | |
| *** gampel1 has joined #openstack-smaug | 06:14 | |
| *** yuval has joined #openstack-smaug | 06:16 | |
| gampel1 | yinwei: hi | 06:16 |
| gampel1 | yinwei_computer: ping | 06:21 |
| *** huayi has quit IRC | 06:24 | |
| *** huayi has joined #openstack-smaug | 06:27 | |
| *** huayi has quit IRC | 06:32 | |
| *** gongxiaowei has quit IRC | 06:47 | |
| *** huayi has joined #openstack-smaug | 06:47 | |
| *** c00281451 is now known as chenzeng | 06:51 | |
| chenzeng | gampel:yinwei and wangliuan are in the conference now. they will be back at 16:00pm in Beijing. | 06:52 |
| gampel1 | Ok thx | 07:01 |
| gampel1 | chenzeng:' whats the status of your patches | 07:02 |
| chenzeng | gampel:i think i and yuval have reached an agreements. the timetrigger will be finished asap. | 07:03 |
| chenzeng | gampel:just one question should be verified. | 07:04 |
| chenzeng | yuval:how about the question yesterday? have you verified the relationship between thread of rpc and the thread of timetrigger's greenthread | 07:06 |
| *** huayi is now known as chenhuayi | 07:11 | |
| yuval | chenzeng: the rpc and the timetrigger are on the same thread | 07:12 |
| chenzeng | yuval:how to verify? | 07:15 |
| chenzeng | yuval:if they are on the same thread, we are no need to restart the greenthread, because they will run in serially | 07:17 |
| yuval | chenzeng: correct. we only need to restart the greenthread once the timetrigger recurrence has changed | 07:17 |
| chenzeng | no, i think we no need to restart greenthread even if changing the trigger recurrence. | 07:19 |
| chenzeng | because the rpc and the trigger's greenthread will not run at the same time. | 07:20 |
| yuval | consider the recurrence of the time trigger is once every year. now we want to change it to once every hour | 07:21 |
| yuval | if we don't cancel the greenthread and reschedule, the greenthread will sleep for a year | 07:21 |
| chenzeng | ok, sorry, i forgot this senario. you are right. | 07:22 |
| chenzeng | but how to verify the they are on the same thread. | 07:24 |
| *** huayi_ has joined #openstack-smaug | 07:25 | |
| *** chenhuayi has quit IRC | 07:27 | |
| *** huayi has joined #openstack-smaug | 07:30 | |
| *** huayi_ has quit IRC | 07:31 | |
| yuval | try reading here: | 07:33 |
| yuval | http://eventlet.net/doc/threading.html | 07:33 |
| yuval | and | 07:36 |
| yuval | notice that greenthreads provide thread-like proprties | 07:36 |
| yuval | see eventlet/green/threading.py (_GreenThread) | 07:36 |
| yuval | in threading.py, eventlet patches the threading library | 07:37 |
| yuval | and when you call threading.current_thread() | 07:37 |
| yuval | you actually call greenthread's current_thread, which returns a greenthread, not a real thread | 07:38 |
| chenzeng | ok, i will try to verify. after verifying the problem, i think the timetrigger is finished. what do you think yuval? | 07:40 |
| yuval | sounds great. have you thought about using the DynamicLoopingCall? | 07:56 |
| yuval | chenzeng: if you need anything else, tell me :) | 07:58 |
| chenzeng | yuval:no | 08:01 |
| chenzeng | yuval:why must use DynamicLoopingCall? | 08:01 |
| yuval | it is not a must, but it already implements what we are trying to do | 08:02 |
| chenzeng | but yesterday i told you why not use, and you agreed. | 08:04 |
| chenzeng | i will check once more. if it is ok, i will use. | 08:05 |
| *** gongxiaowei has joined #openstack-smaug | 08:22 | |
| yinwei_computer | ping gampel1 | 08:24 |
| yinwei_computer | ping gampel | 08:24 |
| gampel1 | I am in a weekly IRC meeting for dragonflow can talk after the meeting | 08:26 |
| yinwei_computer | ok | 08:29 |
| yinwei_computer | I suppose you will end 30 minutes later, right? | 08:29 |
| *** wangliuan has joined #openstack-smaug | 08:31 | |
| gampel1 | yes | 08:38 |
| openstackgerrit | zengchen proposed openstack/smaug: Implement time trigger with Eventlet https://review.openstack.org/296880 | 08:42 |
| yinwei_computer | ping gample1 | 09:01 |
| gampel1 | hi | 09:01 |
| yinwei_computer | gampel1: available now? | 09:01 |
| gampel1 | yes | 09:01 |
| yinwei_computer | we could start, liu an will join soon | 09:02 |
| gampel1 | ok | 09:02 |
| yinwei_computer | we saw your comment, yuval and you | 09:02 |
| yinwei_computer | maybe I have some misunderstanding here | 09:02 |
| gampel1 | on the neutron plugins | 09:02 |
| yinwei_computer | could you pls. elaborate your idea? | 09:02 |
| yinwei_computer | yes, neutron plugins | 09:02 |
| gampel1 | from the user perspective we do not what him to chose different sub resources of Neutron we want him to select | 09:03 |
| yinwei_computer | yes, I understand this point | 09:04 |
| gampel1 | if he like to protect the networking conflagration of its project | 09:04 |
| yinwei_computer | any other point to make whole neutron sub resources as one? | 09:04 |
| gampel1 | yes they are interconnected in teh Neutron Data module | 09:05 |
| gampel1 | the only resources that are not are the aaS VPN , FW ... | 09:05 |
| gampel1 | for the core resources it does not make sense to separate them | 09:06 |
| yinwei_computer | hmm, so the point here is we don't want to make network, port, security group, router, to be separate plugins, since they are integrate and couldn't be composed | 09:07 |
| yinwei_computer | there's only one combination | 09:07 |
| yinwei_computer | I see | 09:07 |
| gampel1 | what to you gain from this | 09:07 |
| yinwei_computer | yes, that's what I want to tell the dilemma of the implementation | 09:07 |
| gampel1 | I am not sure i understand the dilma | 09:08 |
| yinwei_computer | if the user chooses a plan as a project, and in this project, we have dangling port/subnet/security group/router | 09:08 |
| yinwei_computer | because I haven't printed it all :) | 09:08 |
| yinwei_computer | continue, shall we or shall not we protect those dangling network sub resources? | 09:09 |
| gampel1 | worts case you have backed up extra metadata , in later phase we can optimize it to give the subset used by the selected resources | 09:09 |
| gampel1 | in DF we have the same problem | 09:10 |
| gampel1 | we want to push to CN only the updates that are relevant to him | 09:10 |
| gampel1 | But in the first phase we are doing selective distribution by the Tenant ID | 09:11 |
| gampel1 | I think it will be a good starting point for us as well , backup all the projcet networking resources | 09:11 |
| yinwei_computer | so, get back to protection service implementation, let me check: | 09:13 |
| gampel1 | I think because this is metadata it will be very small amount of data | 09:13 |
| gampel1 | I think it make sense latter to open the aaS router , fw, vpn etc to diffrent plugin but not in the first pahse | 09:13 |
| yinwei_computer | for those network sub resources connected to server, their parent resource is server. | 09:13 |
| yinwei_computer | yes, I understand | 09:14 |
| gampel1 | This is some think me and saggi had allot of discussion about | 09:14 |
| yinwei_computer | first phase we only check basic sub resources:port, network, security group, fixed ip | 09:14 |
| yinwei_computer | router | 09:14 |
| gampel1 | currently network is defined as child of projcet | 09:15 |
| yinwei_computer | but server could depend on it, right? | 09:15 |
| gampel1 | but it might need to be dependent on server | 09:15 |
| yinwei_computer | yes, that' what I want to double confirm with you | 09:15 |
| yinwei_computer | there are two cases: | 09:16 |
| yinwei_computer | 1. dangling network sub resources, the parent is project | 09:16 |
| yinwei_computer | 2. network sub resources connected with server, the parent is server | 09:16 |
| gampel1 | Currently we have the network as dependent on projcet we can not in our module have tow possible parents | 09:17 |
| yinwei_computer | why | 09:17 |
| gampel1 | and in the first phase we want to protect all the projcet networking into one blob | 09:17 |
| yinwei_computer | if the parent is project only, during server restoration, how to build server with network? | 09:18 |
| gampel1 | because the protactabole are defining the dependency | 09:18 |
| yinwei_computer | if we have that limitation, does it mean we have problem in our resource graph building? | 09:19 |
| gampel1 | you are talking about how to connect them | 09:19 |
| yinwei_computer | no, I'm talking about the dependency | 09:19 |
| gampel1 | no this is the data module of our resources Volume will all ways be child of VM | 09:19 |
| yinwei_computer | not necessarily | 09:20 |
| gampel1 | how not | 09:20 |
| yinwei_computer | volume could be dangling, not attached to vm but only existed in project, right? | 09:20 |
| gampel1 | yes but it will not be child of the Project | 09:20 |
| yinwei_computer | what if user chooses a project with dangling volumes? will those volumes be included into our resource graph? | 09:22 |
| yinwei_computer | or in first phase, we don't take care of dangling resources? | 09:23 |
| gampel1 | will you want to backup into the same paln any new volume created on that projcet ? | 09:23 |
| gampel1 | I think that you can all ways select just that volume with as the root of your plan | 09:24 |
| yinwei_computer | yes, if the user has chosen the project in the plan, whatever created in the project we need take care. Isn't it? | 09:24 |
| yinwei_computer | per my understanding, automatically discover resources is a feature of smaug | 09:25 |
| gampel1 | yes | 09:25 |
| yinwei_computer | we allow user to choose plan on different layers of resources | 09:25 |
| yinwei_computer | it will be fancy if use only need choose a project and say, hey, smaug, protect it all | 09:26 |
| yinwei_computer | maybe I have some misunderstanding here | 09:26 |
| gampel1 | Currently the networking is defined as dependent on project and not on VM | 09:26 |
| gampel1 | it can not be dependent on both | 09:27 |
| yinwei_computer | hmm, without network, even if we restore a vm with same data, how could people touch it? | 09:27 |
| gampel1 | so you will need the projcet with the network | 09:27 |
| yinwei_computer | from saggi's resource graph design, one node could be child of multiple parents | 09:27 |
| yinwei_computer | am I wrong? | 09:28 |
| yinwei_computer | ot | 09:28 |
| yinwei_computer | it's a graph not a tree | 09:28 |
| gampel1 | Yes but in the resource protecactabole you define who could be you possible parents | 09:28 |
| gampel1 | Currently networking is defined as child of projcet | 09:29 |
| yinwei_computer | yes, the resource itself should know who is his parent | 09:29 |
| yinwei_computer | server or network | 09:29 |
| gampel1 | we had allot of discussion on this point if net should be under project or server | 09:29 |
| yinwei_computer | if we don't make network attached with servers as child of server | 09:30 |
| yinwei_computer | how to solve the restoration dependency? | 09:30 |
| yinwei_computer | we need first build network then server with reference to those network | 09:30 |
| gampel1 | what we discussed about that is to consider networking as part projcet | 09:31 |
| yinwei_computer | maybe I have missed this part of discussion' | 09:31 |
| yinwei_computer | now my question is, with your discussion result, how to solve the restoration dependency issue | 09:32 |
| gampel1 | VM restore does not have to happen in the protection plugin right ? | 09:32 |
| gampel1 | it is not like Volume data it is mostly meta data unless you want to restore to running VM | 09:32 |
| yinwei_computer | yes, we need restore to running VM, no matter in plugin or in heat | 09:33 |
| yinwei_computer | even with heat, to build the template resource, we need server resource to refer network resource | 09:33 |
| yinwei_computer | if network resource doesn't exist, I have no idea how to describe the server resource network properites | 09:34 |
| gampel1 | So if you are just Restoring one VM you do not care what network it will get , you only care whan it is part of a project with muti Vms | 09:34 |
| yinwei_computer | sorry I don't get your point | 09:35 |
| yinwei_computer | take heat resource template as example | 09:35 |
| gampel1 | What does it mean to restore one VM | 09:35 |
| gampel1 | it is to create VM with the volumes that were attached to it and the KVM properties he run with | 09:36 |
| gampel1 | the Ip that he will get will not matter unless he is part of a project backup | 09:36 |
| gampel1 | and SG rules are only relevant to other ports in the projcet | 09:37 |
| gampel1 | so you need to my understanding "networking" only when you are backup and restore more then one connected VMs | 09:38 |
| yinwei_computer | Let me confirm | 09:38 |
| yinwei_computer | do you mean we only restore vm with volume attached and kvm properties, but no any network properties | 09:38 |
| gampel1 | No | 09:39 |
| *** wangliuan has quit IRC | 09:39 | |
| yinwei_computer | and we create network resources independently | 09:39 |
| gampel1 | this is tru in my mind if you backup one VM | 09:39 |
| yinwei_computer | then we attach those servers to the network at last | 09:39 |
| gampel1 | if you backup a Project with few VM you then care about the newtork | 09:40 |
| gampel1 | I agree with you that it is not clear where in the dependency the Networking should go | 09:40 |
| gampel1 | But I think that we should think from the user perspective what will be the simplest way | 09:41 |
| yinwei_computer | the trouble here is, I'm not sure whether it's possible to create a server without port | 09:41 |
| gampel1 | CreateVM cerates the Port | 09:41 |
| yinwei_computer | and then we create network independently, and at last we associate the port created in network with the server | 09:41 |
| gampel1 | when you call Create server you give it a name and a subnet | 09:41 |
| yinwei_computer | but the subnet hasn't created yet | 09:42 |
| yinwei_computer | create one server will spawn the server at the same time, right? | 09:42 |
| yinwei_computer | what if the server spawn up but with a port connected to an un-existed subnet? | 09:43 |
| gampel1 | Yes so in my mind the generate Heat if we have the newtorking will take care of that and if we do only one VM restore it can be auto generated | 09:43 |
| yinwei_computer | no | 09:43 |
| *** wangliuan has joined #openstack-smaug | 09:44 | |
| *** huayi has quit IRC | 09:44 | |
| gampel1 | A networks object. Required parameter when there are mulitple networks defined for the tenant. When you do not specify the networks parameter, the server attaches to the only network created for the current tenant. | 09:44 |
| gampel1 | /v2.1/{tenant_id}/serversCreate server | 09:45 |
| gampel1 | this is from Nova API | 09:45 |
| gampel1 | Let me just get the resource dependencies we define one sec | 09:45 |
| yinwei_computer | do you mean by default the tenant has one network? what if the tenant doesn't have any network? | 09:46 |
| gampel1 | it is an Optional parameter for nova create server | 09:47 |
| gampel1 | one sec | 09:47 |
| gampel1 | link:https://github.com/openstack/smaug/blob/master/doc/source/specs/available_protectables.pu | 09:49 |
| *** huayi has joined #openstack-smaug | 09:50 | |
| gampel1 | that's the way we defined the dependency , I agree that with Networking we might consider changing that | 09:50 |
| yinwei_computer | I don't think there's any conflict, since by design, they are graph | 09:51 |
| gampel1 | netrworking have allot of properties that are not dependent on Server | 09:51 |
| gampel1 | in this link Net is not dependent on Server | 09:51 |
| gampel1 | only on the project | 09:52 |
| *** wangliuan has quit IRC | 09:52 | |
| gampel1 | if we deep dive into the data module of Neutron VM is dependent on Port | 09:53 |
| *** wangliuan has joined #openstack-smaug | 09:53 | |
| yinwei_computer | yes | 09:53 |
| gampel1 | but all the other networking resources are not related to teh VM | 09:53 |
| yinwei_computer | the problem here is you couldn't build a server without port and attach them later | 09:53 |
| gampel1 | when you cann nova Create server it will call Neutron create port internally | 09:54 |
| yinwei_computer | if we can build them independently, we could certainly make network with unique parent as project | 09:54 |
| yinwei_computer | yes | 09:54 |
| yinwei_computer | that's the problem | 09:54 |
| gampel1 | so thats why we choose to have the net dependent on projcet , but again this is open to discussion | 09:55 |
| gampel1 | We had allot of discussion about that but now if we see theres a problem in this for the restore desgin in could be cahnged | 09:56 |
| yinwei_computer | the fact is we couldn't build a vm without network, and attach the vm to the network later, right? | 09:56 |
| gampel1 | yes | 09:56 |
| gampel1 | I think that we do not need to cerate the VM just create the Heat template | 09:56 |
| yinwei_computer | the issue in heat template is the same | 09:57 |
| gampel1 | and update the networking info into the heat Template from the Networking protection plugin | 09:57 |
| yinwei_computer | you couldn't refer a resource doesn't exist | 09:57 |
| gampel1 | I think that in heat I can cerate a network and then create a VM on that network | 09:58 |
| yinwei_computer | you need first build the network resource template, then have vm resource template to refer it | 09:58 |
| yinwei_computer | it's your lunch time and our dinner time | 09:58 |
| yinwei_computer | shall I catch you later, and let's think over it more? | 09:58 |
| yinwei_computer | chenzeng will leave shenzhen tommorrow, so we will have dinner together tonight | 09:59 |
| gampel1 | Ok lets cont tomorrow if we need to to change the dependencies i am opend for that | 09:59 |
| gampel1 | making the net dependent on VM | 09:59 |
| yinwei_computer | sure, if saggi's here we could chat together | 09:59 |
| gampel1 | Ok sure | 09:59 |
| yinwei_computer | thanks, bye | 09:59 |
| gampel1 | but net should bve considerd one blob in theis pahse ok ? | 09:59 |
| *** gongxiaowei has quit IRC | 10:11 | |
| *** huayi has quit IRC | 10:11 | |
| *** huayi_ has joined #openstack-smaug | 10:12 | |
| *** huayi_ has quit IRC | 10:16 | |
| *** gongxiaowei has joined #openstack-smaug | 10:21 | |
| *** huayi_ has joined #openstack-smaug | 10:48 | |
| *** gongxiaowei has quit IRC | 10:57 | |
| *** huayi_ has quit IRC | 11:16 | |
| gampel1 | dd | 11:44 |
| *** x00350071 has quit IRC | 12:30 | |
| *** x00350071 has joined #openstack-smaug | 12:31 | |
| *** huayi_ has joined #openstack-smaug | 12:42 | |
| *** huayi_ has quit IRC | 12:45 | |
| *** huayi_ has joined #openstack-smaug | 12:46 | |
| *** huayi_ has quit IRC | 13:01 | |
| *** huayi_ has joined #openstack-smaug | 13:01 | |
| *** huayi_ has quit IRC | 13:31 | |
| *** openstackgerrit has quit IRC | 13:48 | |
| *** openstackgerrit has joined #openstack-smaug | 13:48 | |
| *** yuval has quit IRC | 15:24 | |
| *** gampel1 has quit IRC | 20:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!