08:04:52 <jose_lausuch> #startmeeting Functest weekly meeting December 20th
08:04:52 <collabot> Meeting started Tue Dec 20 08:04:52 2016 UTC.  The chair is jose_lausuch. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:52 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:04:52 <collabot> The meeting name has been set to 'functest_weekly_meeting_december_20th'
08:05:05 <jose_lausuch> pound in your name
08:05:09 <jose_lausuch> #info Jose Lausuch
08:05:28 <juhak> #info Juha Kosonen
08:05:47 <HelenYao> #info Helen Yao
08:05:49 <hideyasu> #info Hideyasu Hayashi
08:05:53 <rohitsakala> #info Rohit Svk
08:06:31 <jose_lausuch> #topic sharing session (no agenda)
08:06:44 <jose_lausuch> rohitsakala: go ahead
08:06:55 <rohitsakala> Link - https://gerrit.opnfv.org/gerrit/#/c/26045/14/jjb/releng/testapi-automate.yml
08:07:17 <rohitsakala> I created a jenkins job for creating a html documentation from swagger spec
08:07:39 <rohitsakala> But My doubt is how do I push it into functest/docs/ folder from inside jenkins job .?
08:07:58 <rohitsakala> Refer to the comment in the link.
08:08:39 <jose_lausuch> mmm
08:08:50 <jose_lausuch> how is the docs generated?
08:09:09 <jose_lausuch> pdf format?
08:09:13 <rohitsakala> .html
08:09:25 <rohitsakala> and we can add for .pdf also
08:09:29 <jose_lausuch> SerenaFeng: there?
08:09:37 <SerenaFeng> HI
08:09:56 <jose_lausuch> we are discussion the automatic doc from rohitsakala
08:10:06 <HelenYao> rohitsakala: is there any limitation about where the file should put? I mean, is it required to put under Functest repo?
08:10:12 <jose_lausuch> I agree with you, the docs cannot be published just by puttin it in the local repo
08:10:29 <rohitsakala> HelenYao: no.
08:10:48 <jose_lausuch> is there a way we can publish that info?
08:10:52 <SerenaFeng> I am think about putting our documents to artifact
08:10:57 <jose_lausuch> yes
08:11:04 <SerenaFeng> it is where we manage all our documents
08:11:40 <jose_lausuch> artifact repository is where all builds/results/docs end up
08:11:50 <jose_lausuch> http://artifacts.opnfv.org/
08:12:01 <jose_lausuch> example http://artifacts.opnfv.org/logs_functest_huawei-pod1.html
08:12:32 <SerenaFeng> but the question is opnfv-docs read all the docs in each project repo, publish it automatically
08:12:32 <rohitsakala> ok.
08:13:04 <SerenaFeng> since our result will not be put to any repo, how will we publish it?
08:13:07 <jose_lausuch> https://git.opnfv.org/releng/tree/utils/push-test-logs.sh
08:13:17 <jose_lausuch> this is an example about how to publish things to artifacts
08:13:34 <jose_lausuch> SerenaFeng: we have to reference it in the release day
08:13:37 <jose_lausuch> or
08:13:42 <jose_lausuch> we manually add it to our repo
08:14:20 <SerenaFeng> but in that way we need to submit it manually everytime we made some changes
08:14:40 <jose_lausuch> let's keep the first option
08:14:49 <jose_lausuch> pushing to artifacts can be done automatically
08:15:04 <SerenaFeng> that's good
08:15:21 <CristinaPauna> #info Cristina Pauna (Enea)
08:15:33 <SerenaFeng> ' we have to reference it in the release day' what do you mean by that?
08:15:52 <jose_lausuch> we have to give the link to our documentation
08:16:04 <jose_lausuch> wherever it is
08:16:42 <SerenaFeng> can we just give the website link, not the whole content?
08:17:02 <jose_lausuch> sure
08:17:08 <jose_lausuch> or we can reference it in our docs as well
08:17:38 <SerenaFeng> yes, that's a good idea, I see lots of hardcoded Restful description in our *.rst
08:18:18 <SerenaFeng> I think after automatic publish is done, we can use a link to represent them
08:18:24 <jose_lausuch> ok
08:18:55 <jose_lausuch> #info agree on publishing the resulting resp-api document to artifact repo
08:19:09 <jose_lausuch> rohitsakala: can you add that?
08:19:17 <SerenaFeng> rohitsakala jose_lausuch had given some examples as to how to publish it, can you do a research and finish the next step?
08:19:44 <rohitsakala> SerenaFeng: Sure
08:19:50 <SerenaFeng> ok, thank you
08:19:50 <rohitsakala> jose_lausuch: Sure
08:20:05 <jose_lausuch> rohitsakala: you can create a simple bash script that pushes the resulting files to artifacts the same way as we push the logs
08:20:30 <rohitsakala> jose_lausuch: like this one https://git.opnfv.org/releng/tree/utils/push-test-logs.sh
08:20:31 <rohitsakala> right ?
08:21:29 <jose_lausuch> yes
08:22:10 <rohitsakala> ok Cool. I will do it and ping you if I have any doubt.
08:22:13 <rohitsakala> Thanks for the help.
08:23:00 <jose_lausuch> no problem
08:23:06 <jose_lausuch> anything else?
08:23:21 <HelenYao> about the CI notification
08:23:45 <jose_lausuch> ci notification?
08:23:54 <HelenYao> Is it ok to enable CI notification for image-build and verifcation job(nofeature-noha) for each installer?
08:24:03 <HelenYao> to notify the failure
08:24:26 <jose_lausuch> you mean email notification?
08:24:39 <HelenYao> at least the image-build notification if we want to avoid mail flood
08:24:42 <HelenYao> jose_lausuch: yes
08:24:47 <jose_lausuch> I tried once
08:24:52 <jose_lausuch> I think it is for sure possible
08:25:00 <jose_lausuch> there is a field in the jenkins job for that
08:25:17 <HelenYao> yes, there is a email-notification configuration of jenkins job
08:25:21 <jose_lausuch> #info interesting to enable notification by email if a docker build fails
08:26:04 <SerenaFeng> about my two pathes
08:26:04 <SerenaFeng> https://gerrit.opnfv.org/gerrit/#/c/25709/
08:26:04 <HelenYao> ok. I will try to enable notification for image-build job for the first step
08:26:19 <SerenaFeng> https://gerrit.opnfv.org/gerrit/#/c/25719/
08:26:39 <SerenaFeng> I hope we can make a choice ASAP
08:26:53 <jose_lausuch> https://git.opnfv.org/releng/tree/jjb/fuel/fuel-project-jobs.yml#n81
08:27:03 <SerenaFeng> so I can go to next step
08:27:37 <jose_lausuch> SerenaFeng: I will review that in the next hours
08:27:47 <SerenaFeng> thanks
08:27:51 <jose_lausuch> sorry if I'm not looking at everything what happens in the pipeline :)
08:27:59 <jose_lausuch> I have too many things in my review list
08:28:06 <jose_lausuch> just bug me and tell me what to look at
08:28:12 <SerenaFeng> Ok
08:28:18 <jose_lausuch> can you explain both proposals briefly?
08:28:45 <SerenaFeng> oke
08:28:47 <SerenaFeng> let me see
08:29:09 <SerenaFeng> for the first proposal
08:30:22 <SerenaFeng> the naming of each configuration will join each level we defined in config_functest.yaml
08:30:44 <SerenaFeng> except for 'general' word
08:30:50 <SerenaFeng> for example
08:31:14 <SerenaFeng> when we configure the following things:
08:31:14 <SerenaFeng> general:
08:31:15 <SerenaFeng> dir:
08:31:15 <SerenaFeng> repo_functest:
08:31:39 <SerenaFeng> it will set attrbute dir_repo_functest in conf
08:31:52 <SerenaFeng> so we can access conf.dir_repo_functest in our code
08:33:03 <jose_lausuch> ok
08:33:04 <SerenaFeng> for the second proposal;
08:33:16 <SerenaFeng> the config_functest.yaml can stay the same as it is now
08:33:28 <SerenaFeng> because we will define each attribute there
08:34:04 <SerenaFeng> in this way it is clearer in which attribute we have now
08:34:12 <SerenaFeng> but the scalability is not very good
08:34:24 <jose_lausuch> aha
08:34:34 <jose_lausuch> and these 2 proposals are to be chosen?
08:34:34 <SerenaFeng> and when we change something in config_functest.yml, we need to change config.py
08:34:35 <jose_lausuch> I mean
08:34:39 <jose_lausuch> do we have to select 1?
08:35:04 <SerenaFeng> nope, if you have other better idea, feel free to tell me
08:35:15 <jose_lausuch> no no
08:35:21 <jose_lausuch> what I mean is if they can work together
08:35:32 <jose_lausuch> or it's your 2 proposals where 1 will be definitive :)
08:35:55 <SerenaFeng> from my side, I think we can choose one from them
08:36:04 <SerenaFeng> they don't need to work together
08:36:08 <jose_lausuch> just looking at the description
08:36:20 <SerenaFeng> sorry, my description is not very good
08:36:25 <SerenaFeng> English :(
08:36:27 <jose_lausuch> I don't think its a good idea to add something to config_functest.yaml and also .py
08:36:39 <SerenaFeng> yeah, I agree
08:36:47 <SerenaFeng> that's how my proposal 1 comes up
08:36:54 <jose_lausuch> it was perfect :)
08:36:57 <jose_lausuch> ok
08:37:04 <SerenaFeng> simple to manage
08:37:04 <jose_lausuch> let me go though the code and think about it
08:37:05 <SerenaFeng> and as to env
08:37:08 <jose_lausuch> same to the others :)
08:37:32 <SerenaFeng> I just add every attibutes in env to ENVS
08:37:50 <SerenaFeng> because we cannot specify which ones are our needed
08:38:05 <jose_lausuch> ya
08:38:05 <SerenaFeng> and each feature may have different requirements
08:38:26 <SerenaFeng> and Helen Yao propose to have CURD,
08:38:40 <jose_lausuch> #action all review SerenaFeng proposals and provide comments/suggestions. The idea is to select one: https://gerrit.opnfv.org/gerrit/#/c/25709/    https://gerrit.opnfv.org/gerrit/#/c/25719/
08:38:50 <jose_lausuch> CURD?
08:38:54 <jose_lausuch> oh I forgot
08:39:06 <jose_lausuch> #action HelenYao add mail notification to the docker build if failures
08:39:44 <SerenaFeng> after I study it, it is already satisifyed
08:40:16 <HelenYao> jose_lausuch: CRUD for env variables is needed when RC file is sourced
08:40:44 <jose_lausuch> what is satisfied?
08:40:49 <SerenaFeng> yes
08:40:50 <SerenaFeng> there are some env varibles need to be changed and added in the code
08:40:51 <SerenaFeng> run_tests.py
08:40:55 <SerenaFeng> if re.search("OS_", key):
08:40:56 <SerenaFeng> if key == 'OS_AUTH_URL':
08:40:56 <SerenaFeng> ft_constants.OS_AUTH_URL = value
08:40:57 <SerenaFeng> CONSTS.OS_AUTH_URL = value
08:40:57 <SerenaFeng> 
08:40:58 <SerenaFeng> these ones
08:41:03 <jose_lausuch> ah ok
08:41:19 <SerenaFeng> originally ft_constants.OS_AUTH_URL = value is provided
08:41:29 <SerenaFeng> now CONSTS.OS_AUTH_URL = value can do that
08:42:21 <SerenaFeng> because our lab is under migrating, I don't have resources to take a testcase to test it
08:42:35 <SerenaFeng> and I don't know when will the migration ends
08:42:39 <jose_lausuch> ok
08:42:41 <jose_lausuch> fair enough
08:42:46 <SerenaFeng> so that's all I can do for now
08:42:46 <jose_lausuch> I can probably test it
08:42:56 <jose_lausuch> and well done
08:42:58 <jose_lausuch> thanks
08:43:31 <SerenaFeng> and thanks for your approval
08:44:43 <jose_lausuch> you dont need my approval
08:44:46 <jose_lausuch> :D
08:44:47 <jose_lausuch> by the way
08:44:48 <jose_lausuch> HelenYao:
08:44:54 <jose_lausuch> did you get already commit rights?
08:45:13 <HelenYao> yes.
08:45:19 <HelenYao> it is working now
08:45:25 <jose_lausuch> congratulations to our new committer !
08:45:41 <SerenaFeng> congrat
08:45:42 <HelenYao> thank you everyone for recognizing my work
08:46:06 <jose_lausuch> and as I use to say
08:46:14 <HelenYao> I am so honored and thrilled
08:46:28 <jose_lausuch> With great power comes great responsibility :)
08:46:48 <HelenYao> yes. I totally agree with it
08:47:04 <HelenYao> I always say it to my friends... in Chinese
08:47:12 <jose_lausuch> I have a question/doubts about return values
08:47:58 <jose_lausuch> in my tempest patch I tried to use releng constants
08:48:01 <jose_lausuch> for return values
08:48:06 <jose_lausuch> but I don't know when to use
08:48:08 <jose_lausuch> for example
08:48:22 <jose_lausuch> should run() return EX_OK/EX_TESTCASE_FAIL ?
08:48:46 <jose_lausuch> https://git.opnfv.org/releng/tree/modules/opnfv/utils/constants.py
08:49:04 <jose_lausuch> we dont have testcase_fail in releng
08:49:09 <jose_lausuch> I was a bit confused
08:49:26 <SerenaFeng> I think the file is not releng-oriented
08:49:49 <SerenaFeng> it is test project oriented, such as Functest/yardstick...
08:50:18 <HelenYao> I think the constants.py was developed to store all the return value and EX_TESTCASE_FAIL should be added to it
08:50:20 <SerenaFeng> it will be used in test projects not releng
08:50:54 <SerenaFeng> I am not very sure, I just guess Morgan means to use it in this way
08:51:10 <HelenYao> We might to updated our code to use return_code within opnfv.utils.constants instead of defining it in Functest
08:51:26 <jose_lausuch> yes
08:51:31 <jose_lausuch> we need a consistent way
08:51:35 <jose_lausuch> one central place
08:51:37 <jose_lausuch> not different ones
08:51:41 <jose_lausuch> otherwise, it's a confusion
08:51:47 <jose_lausuch> what have been we using so far?
08:51:53 <jose_lausuch> constants in functest?
08:51:58 <SerenaFeng> no
08:51:58 <jose_lausuch> I can change tempest to use that
08:52:02 <HelenYao> yeah, a centrolized way instead of spreading it everywhere
08:52:04 <SerenaFeng> TestcaseBase
08:52:13 <jose_lausuch> sorry, yes, TestcaseBase
08:52:18 <jose_lausuch> shall I change tempest to use those?
08:53:15 <HelenYao> I would say, define the return_code in TestcaseBase to read from releng and all the child test case will inherit from TestcaseBase
08:53:35 <HelenYao> in this way, we will not need to import releng in the child test case
08:53:36 <jose_lausuch> so we need to expand the constants in releng
08:53:51 <jose_lausuch> ok, that makes sense
08:54:16 <SerenaFeng> can we make a class in releng
08:54:25 <SerenaFeng> let TestcaseBase inherit it?
08:54:36 <jose_lausuch> a class for constants?
08:54:41 <SerenaFeng> I think in this way it is much more easy to manage
08:54:42 <SerenaFeng> yes
08:54:56 <jose_lausuch> also an idea
08:55:01 <jose_lausuch> would you like to propose it?
08:55:16 <SerenaFeng> sure, I will do it
08:55:32 <SerenaFeng> btw, have we installed releng in functest?
08:55:44 <HelenYao> if we agree with putting reading releng code at TestcaseBase, the patch about tempest needs a change
08:55:46 <HelenYao> SerenaFeng: Yes
08:56:01 <jose_lausuch> yes
08:56:21 <SerenaFeng> I remember we just git clone it, without install it
08:56:43 <SerenaFeng> only git clone can not work directly
08:56:43 <HelenYao> there was a patch the other day to install releng as opnfv
08:56:45 <jose_lausuch> we added it for sfc i think
08:57:12 <SerenaFeng> we need to install it first, then we can import modules within it
08:57:13 <SerenaFeng> which one?
08:57:15 <jose_lausuch> https://git.opnfv.org/functest/tree/docker/Dockerfile#n121
08:57:34 <jose_lausuch> so it's done
08:58:14 <jose_lausuch> https://gerrit.opnfv.org/gerrit/#/c/25789/\
08:58:16 <jose_lausuch> https://gerrit.opnfv.org/gerrit/#/c/25789/
08:58:23 <SerenaFeng> ok
08:58:52 <jose_lausuch> #action SerenaFeng propose a class in releng for constants (return values, installer names, ...)
08:58:58 <jose_lausuch> ok
08:59:00 <jose_lausuch> anything else?
08:59:02 <jose_lausuch> 1 minute :)
08:59:37 <SerenaFeng> I made some changes in TestAPI model process
08:59:49 <SerenaFeng> https://gerrit.opnfv.org/gerrit/#/c/26277/
09:00:13 <SerenaFeng> the original process method is too hardcoded
09:01:45 <SerenaFeng> in this way it will be easier to add/delete/change field in pods/projects,....
09:02:29 <jose_lausuch> ok
09:02:32 <jose_lausuch> I will review it
09:02:46 <SerenaFeng> ok, that's all from my side
09:02:56 <jose_lausuch> rohitsakala: take a look as well
09:03:10 <jose_lausuch> ok
09:03:12 <rohitsakala> jose_lausuch: Sure, I will.
09:03:12 <jose_lausuch> anything else?
09:03:44 <HelenYao> no
09:03:52 <rohitsakala> nope.
09:04:10 <jose_lausuch> and if I forget about some patch, please let me know by email or here
09:04:17 <jose_lausuch> I am also now responsible for the Ericsson lab
09:04:22 <jose_lausuch> so, many things in parallel :)
09:04:31 <SerenaFeng> wow, lab work
09:04:41 <jose_lausuch> ya, but I'm not an IT guy
09:04:42 <HelenYao> jose_lausuch: congrats on ur new power
09:04:48 <jose_lausuch> have to learn a lot of things:)
09:05:13 <SerenaFeng> lab work is too difficult and trivial
09:05:15 <jose_lausuch> hehe thanks
09:05:31 <jose_lausuch> so I'll get JIRa tickets from INFRA
09:05:36 <jose_lausuch> to set up labs for people
09:05:44 <jose_lausuch> and have already 4 labs to setup
09:05:54 <jose_lausuch> anyway
09:05:58 <jose_lausuch> juhak: anything you wanna share?
09:06:00 <HelenYao> will u work on all of it alone?
09:06:02 <jose_lausuch> otherwise we can close
09:06:14 <jose_lausuch> no, I have a colleague, but he is on vacation now :)
09:06:21 <juhak> jose_lausuch: nope :)
09:06:30 <jose_lausuch> ok
09:06:37 <jose_lausuch> #endmeeting