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