08:01:35 <morgan_orange> #startmeeting Functest weekly meeting December 13th 08:01:35 <collabot> Meeting started Tue Dec 13 08:01:35 2016 UTC. The chair is morgan_orange. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:35 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic. 08:01:35 <collabot> The meeting name has been set to 'functest_weekly_meeting_december_13th' 08:01:42 <morgan_orange> #topic call role 08:01:46 <morgan_orange> #info Morgan Richomme 08:01:52 <HelenYao> #info Helen Yao 08:02:01 <juhak> #info Juha Kosonen 08:02:38 <morgan_orange> #info agenda https://wiki.opnfv.org/display/functest/Functest+Meeting 08:03:21 <morgan_orange> Jose was not sure to attend (he was still in transit in London yesterday and needs to sleep a little bit...) 08:03:23 <SerenaFeng> #info SerenaFeng 08:03:43 <morgan_orange> #topic action point follow_up 08:03:52 <morgan_orange> #link http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2016/opnfv-functest.2016-12-06-08.10.html 08:04:06 <morgan_orange> #info AP1 morgan_orange ask ray on the LF expected feedback for the internship 08:04:35 <morgan_orange> #info discussion with Jose who had a discussion with Ray: nothing formal expected 08:04:54 <morgan_orange> #info LF will not ask for a specific documentation 08:05:10 <morgan_orange> #info AP2 HelenYao prepare a topic on openstack_utils status for next weekly meeting (refactoring/SNAPS/..) 08:05:21 <HelenYao> currently, the openstack_utils is able to support both Mitaka and Newton once patch https://gerrit.opnfv.org/gerrit/#/c/25725/ is merged 08:05:22 <morgan_orange> #info topic for today 08:05:27 <HelenYao> After the patch is merged, we can notify the installer teams to run functest on Newton as they are pending on us 08:05:36 <HelenYao> the patch is leveraging keystoneauth1.session for each client and it will take care of different version of openstack 08:05:43 <HelenYao> it's easy to use it and it provides way to query endpoint and token info for different service client 08:05:47 <HelenYao> http://docs.openstack.org/developer/keystoneauth/using-sessions.html 08:05:58 <HelenYao> To take Newton support further, we were talking about a shared module that can be shared among testing projects including Yardstick, Storperf, etc 08:06:07 <HelenYao> SNAPS can be a good candidate after it finishes the support for Newton 08:06:14 <HelenYao> I took a look at SNAPS code and it is bound strictly with the client version just as Functest did before 08:06:37 <morgan_orange> ok let me info that 08:06:42 <HelenYao> sure 08:07:17 <morgan_orange> #info HelenYao submited a new patch for Newton support (blocking for installers) https://gerrit.opnfv.org/gerrit/#/c/25725/ is merged 08:07:32 <morgan_orange> #info patch to be validated and merged (support also Mitaka) 08:07:47 <morgan_orange> #info patch is leveraging keystoneauth1.session for each client and it will take care of different version of openstack 08:07:55 <morgan_orange> #info easy to use it and it provides way to query endpoint and token info for different service client 08:08:02 <morgan_orange> #link http://docs.openstack.org/developer/keystoneauth/using-sessions.html 08:08:32 <morgan_orange> #info SNAPS good candidate after it finishes the support for Newton (currently same than Functets util function linked to client version) 08:08:38 <morgan_orange> thanks HelenYao 08:08:56 <HelenYao> my pleasure 08:09:01 <morgan_orange> #action all review https://gerrit.opnfv.org/gerrit/#/c/25725/ asap to unblock newton integration 08:09:23 <morgan_orange> #topic Feedback on the plugfest 08:09:46 <morgan_orange> juhak: can you make a quicj update on what happened in UNH 08:10:22 <juhak> at first, it was an interesting event - for a first timer 08:10:45 <juhak> there were several interesting meetings 08:11:09 <juhak> such as dovetail, StorPerf demo 08:11:31 <juhak> and of course great functest demo by Jose 08:11:57 <morgan_orange> #info interesting event , lots of demos/concrete meetings: dovetail, storPerf, and of course Functest by Jose 08:11:58 <juhak> most of the time I was working with our on site HW 08:12:22 <morgan_orange> #info feedback from Jose: A lot of interest from Open-O community (Opera in OPNFV). They will be adding a Clearwater vIMS deployment using Open-O as a test case. They have also interest about using Functest in Open-O standalone, possibly doing some changes to make Functest VIM aware (needs further discussions) 08:12:27 <juhak> and miss completely MANO track 08:12:35 <morgan_orange> #info The testing community gathered together to discuss topics like common documentation for the test cases. Common Dashboard (functest+yardstick), … 08:12:43 <morgan_orange> #info Doctor team wants to run more than 1 test case. I suggested to follow the same approach as SFC, SDNVPN. Create a runner script in their repo and call it from Functest. This way, all the logic is kept in Doctor and Functest is a dummy that just runs it and expects a result to report to the DB. Idea suggested for the Functest dashboard: show the overall result for Doctor and click on the icon for more information (e.g. pop-up wi 08:13:06 <morgan_orange> #info Functest ran on 3 different HW, with different installers and collected the results in the DB. Good results in general, but not extense test have been run, only smoke testing. Dovetail was also target of testing in some cases. 08:13:21 <morgan_orange> #info ABOT proposal under consideration. (see next topic) 08:13:32 <morgan_orange> #info I talked a bit about the test promotion proposal from you. That it could work together with the CI evolution, but maybe we can’t make it for Danube, since the CI evolution that does promotions won’t apply until E-release. 08:14:11 <morgan_orange> #info Same issues as CI found in a WindRiver deployment with v3 endpoints. I managed to get the Functest apis working, but Rally failed. No time to provide a fix in the plugfest, but HelenYao is working on that. (see previous topic) 08:14:22 <morgan_orange> ok it sounds good 08:14:42 <morgan_orange> Jose could tell us more next week and/or if you have question feel free to send a mail 08:15:04 <morgan_orange> #topic Status on openstack_utils (refacting/SNAPS/..) 08:15:10 <morgan_orange> #info done in action point follow up 08:15:18 <morgan_orange> or you want to add something HelenYao? 08:15:34 <HelenYao> After the patch is merged, I would see windriver deployment be working 08:15:54 <morgan_orange> #topic Exit status code (TEST_EX_OK, TEST_OK,..) 08:16:02 <HelenYao> i would like to be envolved with any Newton support item 08:16:12 <morgan_orange> ok 08:16:49 <morgan_orange> regarding exit status, for the moment with testcaseBase with exit when something went wrong during test execution or when we upload the results to DB 08:16:58 <HelenYao> envolved = involved 08:17:32 <morgan_orange> question sent to Rally to support another state to distinguish execution FAIL from execution PASS but tests FAIL 08:18:21 <morgan_orange> we need to distinguish at the moment the exit = exution (whatever the results) and the results are sent to the DB with the right status (PASS or FAIL) 08:18:31 <morgan_orange> but the jenkins exit is base on the first one not the second one 08:18:45 <morgan_orange> so even if there are failure we report execution OK 08:19:17 <morgan_orange> we have another issue: the lack of control of what feature project can use to exit...(if we just run a command) 08:19:53 <morgan_orange> Cedric mentioned he will patch testcasebase (which is the base of all the new base classes) to take that into account 08:20:12 <morgan_orange> I think he is back from Innovation week, I hope he will have time this week 08:21:10 <morgan_orange> #action morgan_orange ask fdegir if any progress on the capability to jenkins to create a new status (blue/red + orange? balls) 08:21:23 <morgan_orange> #action morgan_orange see with Cedric on the improvement of the testcaseBase class 08:21:31 <morgan_orange> any comment/question on this topic? 08:21:56 <HelenYao> We can wait for the response from Cedric 08:22:29 <morgan_orange> what is strange is recently on jenkins I think teh reporting is correct (blue/red balls reflect well if a test fails or not) 08:22:34 <morgan_orange> to be checked 08:22:46 <morgan_orange> #topic Proposal for integration of ABOT (Automated Behaviour Oriented Testing) - Debayan Chaudhuri 08:22:54 <morgan_orange> anyone from ABOT on the chan? 08:23:24 <SerenaFeng> I think it is because not all the testcases are using the new feature 08:23:36 <morgan_orange> SerenaFeng: yep probably it should depend where it fails 08:23:48 <morgan_orange> if testcase with new feature = issue, if not old behavior = no issue 08:24:10 <SerenaFeng> only a few has been adapted to the new framework, like vping/parser/sfc/odl 08:24:18 <morgan_orange> regarding ABOT as far as I understand they attended the plugfest and discussed with Jose. It is a new framework. 08:24:22 <SerenaFeng> yes, I think so 08:24:37 <SerenaFeng> ABOT stands for what? 08:24:38 <morgan_orange> but if noone is on the chan, let discuss it later and why not inviting them to teh weekly testing meeting 08:24:43 <morgan_orange> SerenaFeng: no idea... 08:24:56 <morgan_orange> Automated behavior Oriented testing 08:25:02 <morgan_orange> it was in the title.. :) 08:25:22 <HelenYao> who provides ABOT? 08:25:24 <HelenYao> any link? 08:25:39 <morgan_orange> #action morgan_orange see with Jose to suggest a presentation of ABOty during weekly meeting (possible that they are US based..so 8 UTC is a bit hard) 08:25:45 <morgan_orange> HelenYao: no idea 08:26:00 <morgan_orange> any way it is more propective for E release, not possible to do anything for Danube 08:26:13 <HelenYao> see 08:26:13 <morgan_orange> ok next topic then 08:26:36 <morgan_orange> SerenaFeng: there were no topic on your proposal but it makes sense to speak about it 08:26:44 <morgan_orange> are you OK if we create a topic? 08:26:54 <SerenaFeng> ok 08:27:07 <SerenaFeng> I think we used to have a topic before 08:27:08 <morgan_orange> #topic Unified way to provide conf and env variables 08:27:27 <morgan_orange> #info SerenaFeng submitted to proposal patch to address the problem 08:27:35 <SerenaFeng> Unified way to provide constants and env variables 08:27:36 <morgan_orange> #link https://gerrit.opnfv.org/gerrit/25709 08:27:37 <SerenaFeng> this one 08:27:44 <morgan_orange> #link https://gerrit.opnfv.org/gerrit/25719 08:28:04 <SerenaFeng> I submit two proposals 08:28:23 <HelenYao> I left some comments :) 08:29:02 <SerenaFeng> for the first one, we need to restrict the naming in config_functest.yaml 08:29:22 <SerenaFeng> or else the name of the configurations will be too long 08:29:48 <OPNFV-Gerrit-Bot> Romanos Skiadas proposed functest: Rename add_floating_ip arg to floatingip_addr https://gerrit.opnfv.org/gerrit/25833 08:29:53 <SerenaFeng> I am afraid that someone will not like it (Personally I like to do it in this way although) 08:30:28 <SerenaFeng> so I made another proposal, the naming in yaml file can be arbitrary, we will give it a name in config.py 08:30:41 <morgan_orange> #action HelenYao morgan_orange juhak Cedric Jose Steve: review this patch => target choice before end of the week if possible (to avoid same issues than on previous attempt) 08:30:56 <SerenaFeng> but when something in config_functest.yaml changed, config.py need to change as well 08:31:17 <morgan_orange> thanks SerenaFeng 08:31:25 <SerenaFeng> HelenYao I saw your comments 08:31:38 <SerenaFeng> I will look into it and reply you 08:31:52 <HelenYao> great 08:31:56 <SerenaFeng> As a CRUD, I think we need to discuss about it 08:32:07 <HelenYao> sure 08:32:21 <SerenaFeng> I don't think it is necessary to do it 08:32:34 <SerenaFeng> or else it wouldn't be called constants 08:32:41 <HelenYao> how to handle the case I described 08:32:48 <SerenaFeng> it is variable not constant 08:32:56 <HelenYao> once the RC is sourced, the env variables are changed 08:33:15 <HelenYao> how to refresh the env() 08:33:21 <SerenaFeng> which RC file? 08:33:39 <HelenYao> here is the scenario 08:34:21 <SerenaFeng> I think once testcase executed, the env is already stable 08:34:32 <HelenYao> the contants.py will be loaded firstly before any execution. beforing running test, the openstack RC file will be sourced and all of the envs are included in constants 08:34:47 <HelenYao> there will be out of sync for those env variables 08:35:24 <SerenaFeng> we can make it not firstly loaded 08:35:30 <HelenYao> per the loading of python module, once it is loaded, it will not be reloaded again 08:35:58 <HelenYao> the contants.py will be put on the top of each module and the openstack RC file will be sourced later 08:35:59 <SerenaFeng> each testcase is a new start 08:36:48 <SerenaFeng> ok, I will think about this case offline 08:36:57 <SerenaFeng> we can talk about it then 08:37:03 <SerenaFeng> is that ok? 08:37:15 <HelenYao> sounds good 08:37:57 <HelenYao> I just meant to bring this up and make sure the case is covered. we can discuss how to implement it offline 08:38:39 <SerenaFeng> we can borrow cache machnism as openstack did 08:38:45 <SerenaFeng> if it is necessary 08:39:05 <HelenYao> cache is one solution and we need to maintain it to keep it up to date 08:39:13 <morgan_orange> ok so please review and comment Serena's patch 08:39:22 <SerenaFeng> I just need to make sure if it is necessary 08:39:28 <morgan_orange> #topic AoB 08:39:38 <HelenYao> we may divide the variables into real constants and variables that will be refreshed 08:39:47 <morgan_orange> #info I merged the patch on the DB testcase collection model and started the update 08:39:47 <SerenaFeng> morgan_orange 08:40:07 <morgan_orange> #link http://testresults.opnfv.org/test/api/v1/projects/functest/cases 08:40:09 <morgan_orange> SerenaFeng: 08:40:25 <SerenaFeng> let's continue with yours first 08:40:49 <morgan_orange> It is just for sharing, I will finish the update of the DB today (some feature project missing) 08:41:06 <morgan_orange> I was wondering which domain I should attribute to vPing... 08:41:25 <morgan_orange> for the moment I use the domains: networking, vim, nfvi, mano 08:41:49 <SerenaFeng> vim? 08:41:53 <morgan_orange> = openstack 08:42:33 <morgan_orange> I put also some tags, it could be probably improved 08:42:49 <morgan_orange> #info sceanrio collection + associated API to be planned 08:43:13 <MatthewLi> #info Jun Li 08:43:20 <morgan_orange> there was also a discussion with jack on the capability of the API to build custom list for scenario owner based on the list of test cases 08:43:30 <morgan_orange> will be hard to be done before the end of the year 08:43:37 <morgan_orange> but still on track for Danube 08:43:49 <morgan_orange> SerenaFeng: a topic for AoB 08:43:56 <SerenaFeng> I I have a suggestion about deployment of functest ecosystem 08:44:21 <SerenaFeng> during the plugfest, we need to install functest/testapi/mongo 08:44:35 <SerenaFeng> and change test_db_url in config_functest.yaml 08:45:06 <SerenaFeng> I am think of providing an automatic deployment of Functest ecosystem 08:45:21 <morgan_orange> including the DB + the test APi + the reporting? 08:45:32 <SerenaFeng> which will deploy functest/testapi/mongo in a single cli/script 08:45:51 <SerenaFeng> yes 08:46:06 <morgan_orange> the reporting has been also dockerized (based on your testapi best practice) 08:46:20 <morgan_orange> today the mongo DB is missing and the glue to deploy everything 08:46:22 <SerenaFeng> that's good, then it will be easy to do it 08:46:35 <morgan_orange> initially we believed that testapi/DB/reporting were only for CI 08:46:50 <morgan_orange> but we can see that it is relatively flexible and can bring add value to the global functest ecosystem 08:46:59 <HelenYao> we may use docker-compose to deply the whole set 08:47:00 <morgan_orange> so +1 to this idea 08:47:23 <SerenaFeng> I am trying us docker-compose to deploy a testapi ecosystem 08:47:35 <HelenYao> +1 to deploy the the whole set 08:47:51 <morgan_orange> #info SerenaFeng suggest we could create script/docker-compose to offer a complete functest ecosystem including functest + test DB + testapi + reporting 08:48:20 <morgan_orange> #agreed 08:48:27 <HelenYao> #agreed 08:48:30 <morgan_orange> ok another task for Danube... :) 08:48:36 <SerenaFeng> #agreed 08:48:39 <zhihui> #info zhihui 08:48:47 <SerenaFeng> and that comes with a question 08:48:59 <SerenaFeng> test_db_url now is settled in config_functest.yaml 08:49:05 <MatthewLi> morgan_orange: can I have a question? 08:49:13 <morgan_orange> sure MatthewLi 08:49:34 <morgan_orange> SerenaFeng: we coudl move that to releng 08:49:39 <HelenYao> test_db_url can be passes as env variable 08:49:48 <HelenYao> passes = passed 08:49:50 <MatthewLi> #info since dovetail will use some testcases from functest for compliance and certification 08:50:37 <SerenaFeng> I agree that we can pass test_db_url as an env 08:50:40 <MatthewLi> #info need the local logs of these testcases, then our crawer can catch that 08:51:09 <morgan_orange> MatthewLi: usually we pushed the local logs of the tests to artifacts at the end of CI 08:51:17 <morgan_orange> you probably can retrieve them here 08:51:37 <morgan_orange> the only issue is to push logs in artifact, the pod where tests have been executed must be declared 08:52:13 <morgan_orange> but I assume it is possible to declare certification POD in the list and/or create a new one dedicated to artifact and modify functest to push the results in a dedicated certification artifact 08:52:44 <MatthewLi> morgan_orange: as known, c&C has some special requirements, the end users need the original test logs, not transfer to DB and then out, they will question if some amends during the DB transfering 08:52:59 <SerenaFeng> as to dovetail, I think what they need is test result 08:53:13 <morgan_orange> MatthewLi: the artifact is just a place where we push the original logs 08:53:39 <morgan_orange> e.g. https://build.opnfv.org/ci/view/functest/job/functest-fuel-virtual-daily-colorado/934/console 08:53:57 <morgan_orange> => see end of the file, you have the list of original files pushed to artifacts 08:54:03 <morgan_orange> DB is managed in // 08:54:07 <MatthewLi> morgan_orange: it related to community CI, while C&C is isolated with CI, 08:54:09 <morgan_orange> here tehre are only the ligs 08:54:29 <morgan_orange> yes but we may have the same mechansim couldn't we 08:55:01 <MatthewLi> so my idea is just add a parameter such as "-l" to locally store the logs 08:55:02 <morgan_orange> instead of pushing to CI artifact, create your C&C artifacts and if reporting flag is on push them 08:55:26 <MatthewLi> if not "-l" it will not do anything 08:55:26 <morgan_orange> in Functest all the logs are stored in the container in a directory 08:55:43 <morgan_orange> at the end of CI we just pushed all of them into the artifacts 08:55:59 <morgan_orange> but by default they are all there, the,n it is up to you to do whatever you want with them 08:56:33 <morgan_orange> we have a flag for reporting 08:56:35 <morgan_orange> -r 08:56:46 <HelenYao> what MatthewLi is needed is the same format as what is pushed to DB. what we have now in results does not meet their needs 08:57:06 <MatthewLi> morgan_orange: not reporting to DB 08:57:13 <MatthewLi> we need logs locally 08:57:43 <morgan_orange> ok so maybe another flag to distinguish DB / log 08:57:44 <MatthewLi> HelenYao: yep , 08:57:49 <morgan_orange> but as said logs are in the container 08:57:51 <HelenYao> MatthewLi is suggesting to add a new argument like -l to store the JSON data locally instead of pushing to DB 08:58:02 <SerenaFeng> we already have db and log 08:58:08 <HelenYao> the logs is not the JSON data 08:58:42 <morgan_orange> testapi is fully dockerized, as for the plugfest, it is esy to create your own certification DB and deploy associated API 08:59:16 <morgan_orange> you need to change the DB path for your own DB but then you will fully master the json for your own need 08:59:34 <MatthewLi> HelenYao: yep, that's what needed 08:59:42 <morgan_orange> it can be deployed in a private env 08:59:53 <morgan_orange> OK so that is what we did for the plugfest 09:00:01 <morgan_orange> and it is connected to what SerenaFeng mentioned 09:00:15 <MatthewLi> morgan_orange: not related to any DB, end users don't want see result transfering 09:00:23 <morgan_orange> today you have to cretae the mongo, deploy the test api docker and make some config 09:01:03 <HelenYao> morgan_orange: I think what MatthewLi is a valid requirement, what if user does not want to deploy the DB, writing the data to file is an option 09:01:07 <SerenaFeng> dovetail need the result, and need functest to push the result to a file in json format, but from functest's point of view, I don't see it necessary to do it 09:01:57 <SerenaFeng> since we already provide log and testdb to store the results 09:02:24 <MatthewLi> SerenaFeng: we need that. so use the option such as "-l" 09:02:26 <morgan_orange> hmm maybe some figures will be needed, but as far as I understand, you would like that the json we produced could be stored locally in the Functest docker on the jumphost instead of being pushed in a DB even if this DB is internal 09:02:49 <MatthewLi> morgan_orange: yep 09:03:24 <morgan_orange> ok so a little dev is needed to offer that but it is not difficult 09:03:34 <MatthewLi> morgan_orange: yep 09:03:39 <SerenaFeng> no -l 09:03:47 <morgan_orange> we can do it systematically 09:03:47 <SerenaFeng> just -r is enough 09:04:15 <SerenaFeng> we can see if arg or -r is begin with 'file:///' 09:04:25 <SerenaFeng> we output the result to file 09:04:26 <morgan_orange> push the json systematically locally 09:04:42 <SerenaFeng> if it is starts with http://, push to testdb 09:04:59 <morgan_orange> SerenaFeng: yep also an option 09:05:03 <SerenaFeng> we already have too many argument 09:05:10 <HelenYao> currently, -r does not receive argument 09:05:21 <SerenaFeng> we are discussing about it 09:05:40 <SerenaFeng> we need it anyway in whole set topic 09:05:42 <morgan_orange> MatthewLi: can you create a JIRA for that 09:05:49 <MatthewLi> morgan_orange: sure 09:05:53 <morgan_orange> we will continue offline but I think we got your need :) 09:06:03 <morgan_orange> BTW, we started refactoring the testcase collection 09:06:33 <morgan_orange> I was thinking using the tags to indicate if the testcase is part of C&C 09:06:41 <MatthewLi> SerenaFeng, morgan_orange, HelenYao: as for the technical details you can talk more to achieve the storing logs locally 09:06:59 <HelenYao> SerenaFeng: agreed. we need to pay attention to introducing more arguments. what you proposed about -r can be a candidate 09:07:02 <morgan_orange> #action morgan_orange create a wiki page to indicate the story of the logs in functest 09:07:23 <MatthewLi> morgan_orange: good idea, we need your recommendation of testcases 09:07:42 <morgan_orange> MatthewLi: http://testresults.opnfv.org/test/api/v1/projects/functest/cases 09:08:00 <morgan_orange> I can imagine adding a dovetail tags 09:08:17 <MatthewLi> morgan_orange: #link https://wiki.opnfv.org/display/dovetail/Dovetail+Test+Areas+and+Test+Cases 09:08:19 <morgan_orange> the issue is for Tempest for instance you soemtimes just need a subset of the case not all of them 09:08:38 <MatthewLi> #link https://wiki.opnfv.org/display/dovetail/Dovetail+Test+Case+Requirements 09:09:10 <morgan_orange> ok 09:09:14 <MatthewLi> morgan_orange: not me need, the community need or the C&C need :) 09:09:25 <morgan_orange> we are already 10 minutes late 09:09:37 <morgan_orange> last AoB before we close the meeting 09:09:38 <MatthewLi> thanks for your time 09:10:02 <morgan_orange> #info internship allocation of VNF catalog epic to Kumar 09:10:42 <morgan_orange> #info VnfOnBoard abastract class to be submitted this week (not tested yet..) but the idea is to indicate to projects dealing with VNF to follow the template (as we have for feature) 09:11:08 <morgan_orange> #info Umbrella feature class merged, people with allocation of existing feature projects => use this class to simplify integration 09:11:13 <morgan_orange> any other topic before we close? 09:11:20 <HelenYao> np 09:11:26 <SerenaFeng> np 09:11:27 <morgan_orange> MatthewLi: no problem...convergence is a long way... 09:11:57 <morgan_orange> there is a French philosopher who wrote 'Hell is the others..." 09:12:15 <morgan_orange> it is always a bit difficult to initiate the synergies but it creates real added values 09:12:48 <morgan_orange> work done in yardstick/functest/qtip/dovetail is a good example of such added values...even it is not always easy... :) 09:12:56 <MatthewLi> morgan_orange: :) 09:13:00 <morgan_orange> ok thanks for joing 09:13:05 <HelenYao> it's not easy but worthwhile 09:13:17 <morgan_orange> HelenYao: exactly.. 09:13:26 <HelenYao> so long as we are on the way to achieve the goal 09:13:34 <morgan_orange> #endmeeting