08:00:16 <jose_lausuch> #startmeeting Functest weekly meeting June 20th 2017
08:00:16 <collabot`> Meeting started Tue Jun 20 08:00:16 2017 UTC.  The chair is jose_lausuch. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:16 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:16 <collabot`> The meeting name has been set to 'functest_weekly_meeting_june_20th_2017'
08:00:20 <jose_lausuch> #topic role call
08:00:38 <jose_lausuch> #info Jose Lausuch
08:00:45 <HelenYao> #info Helen Yao
08:00:56 <SerenaFeng> #info SerenaFeng
08:01:17 <LindaWang> #info Linda Wang
08:01:35 <jose_lausuch> where are the orange guys?
08:02:14 <CristinaPauna> #info Cristina Pauna (Enea)
08:02:22 <SerenaFeng> breakfast-ing? :)
08:02:35 <morgan_orange> #info Morgan Richomme
08:02:37 <jose_lausuch> there we go
08:02:47 <jose_lausuch> we were wondering about oranges :)
08:03:03 <morgan_orange> #info Cedric Ollivier
08:03:23 <jose_lausuch> you are in the same room?
08:03:53 <jose_lausuch> #topic Recap from Summit.
08:04:02 <morgan_orange> jose_lausuch: yes
08:04:21 <jose_lausuch> #info 2 breakout sessions where we discussed about different topics: VNF refactor, REST API, logging, ...
08:04:47 <jose_lausuch> #info we covered most of the things, but there are some questions about REST API (topic for today)
08:05:13 <jose_lausuch> #info different presentations during design summit and summit from Functest team
08:05:26 <jose_lausuch> #info slides will be available soon in the web
08:05:51 <morgan_orange> for the Rest API I planned to involved benoit (the guy who wrote the APi for Energy) he is my Rest APi referent...
08:05:52 <jose_lausuch> it would be cool to upload all our slides to our wiki in a zip format or something
08:05:56 <morgan_orange> but did not do it yet
08:06:20 <jose_lausuch> morgan_orange:  ok
08:06:33 <jose_lausuch> it's good to have opinion from experts
08:06:38 <jose_lausuch> I'm not one myself
08:06:53 <jose_lausuch> anything else to higlight from the summit?
08:07:14 <SerenaFeng> yes, great to have a referent!
08:07:16 <jose_lausuch> #info good participation and interest in the Test API and Functest next steps in the idea nest
08:07:53 <SerenaFeng> Authentication in TestAPI is not discussed
08:07:56 <ollivier> LindaWang: Could we simply simply remove self.repo? This is now a kind of non sens
08:08:16 <jose_lausuch> ollivier: please wait until topic :)
08:08:30 <SerenaFeng> morgan_orange arrange a slot in testperf meeting, will we discuss it there?
08:08:51 <jose_lausuch> SerenaFeng: yes, let's have a chat before
08:08:58 <jose_lausuch> we didn't have the time during the summit
08:09:07 <morgan_orange> #info slot on Test API/Bitergia planned for next week Testing group meeting
08:09:09 <jose_lausuch> #info still to be discussed Authentication in TestAPI
08:09:39 <jose_lausuch> #action SerenaFeng jose_lausuch align in TestAPI authentication, next steps
08:10:22 <jose_lausuch> ok, anything else from the summit ?
08:10:31 <jose_lausuch> otherwise, we can switch to rest api
08:10:34 <morgan_orange> looking for the page you created on the wiki
08:10:38 <morgan_orange> maybe we can reference the pres there
08:10:45 <jose_lausuch> which page?
08:11:02 <morgan_orange> you created a table before the summit to indicate the different sessions of the contributors
08:11:07 <jose_lausuch> ah yes
08:11:13 <morgan_orange> but cannot find it anymore
08:11:14 <jose_lausuch> we can include the slides in that page
08:11:14 <SerenaFeng> I think we can make a reference in the summit wiki page
08:11:20 <morgan_orange> should be reference from Euphrates or admin
08:11:26 <jose_lausuch> morgan_orange: https://wiki.opnfv.org/display/functest/2017+Beijing
08:11:39 <SerenaFeng> as the community done in Design summit session
08:11:57 <jose_lausuch> yes, I can add a link there
08:12:08 <morgan_orange> Ok I do it right now, we can proceed
08:12:21 <jose_lausuch> #topic REST API
08:12:27 <jose_lausuch> #link https://wiki.opnfv.org/display/functest/Functest+REST+API
08:12:45 <jose_lausuch> HelenYao: you did some modifications in that page, right?
08:12:50 <HelenYao> yes
08:13:07 <HelenYao> I removed the snapshots and adopted some suggestions
08:13:33 <jose_lausuch> what do we do for /action where there is only 1 action possible?
08:13:35 <jose_lausuch> like prepare env?
08:13:41 <jose_lausuch> we didn't decide on that
08:14:07 <HelenYao> I think we can think about this matter in a general point of view
08:14:26 <HelenYao> no need to decide whether there is only one action against a resource or not
08:14:43 <HelenYao> we have to keep the url pattern consistent
08:15:01 <HelenYao> which is essential from user's point of view
08:15:03 <jose_lausuch> because for show environment, we can also think of
08:15:12 <jose_lausuch> http://<hostname>/api/v1/functest/env/action    where action:show
08:15:56 <HelenYao> it's just get
08:15:58 <SerenaFeng> I think the conflict is not about how many actions, it is about whether actions are needed
08:16:04 <HelenYao> GET http://<hostname>/api/v1/functest/env
08:16:12 <HelenYao> is to show the env
08:16:31 <SerenaFeng> morgan_orange what is the referent suggesting?
08:16:40 <HelenYao> I removed the http://<hostname>/api/v1/functest/env/status per Serena's suggestion
08:17:12 <jose_lausuch> SerenaFeng: can you explain "whether actions are needed"?
08:17:16 <jose_lausuch> what do you mean?
08:17:35 <HelenYao> POST/PUT is about create/update a resource. /action is about operating the resource
08:17:42 <HelenYao> e.g. /server
08:17:52 <HelenYao> POST /server is to create a server
08:18:10 <SerenaFeng> I remembered when comes to 'POST	http://<hostname>/api/v1/functest/testcases/action', we began to have different opinions
08:18:20 <HelenYao> server/action can be fired to operate the server
08:18:26 <SerenaFeng> some think we can use action: 'run/stop'
08:18:39 <SerenaFeng> some think run/stop can be specified in the url directly
08:19:08 <SerenaFeng> so we don't need to check what kind of action is requesting
08:19:14 <SerenaFeng> one url one specific thing
08:19:40 <jose_lausuch> SerenaFeng: so, you are suggesting to get rid of the request json?
08:19:57 <SerenaFeng> requestion json is needed
08:20:07 <SerenaFeng> just action field can be covered in url
08:20:10 <HelenYao> we can use reflection to map the specific operation
08:20:23 <HelenYao> i vote for - some think we can use action: 'run/stop'
08:20:59 <SerenaFeng> for example we can use 'http://<hostname>/api/v1/functest/testcases/action/run'
08:21:03 <jose_lausuch> for example, SerenaFeng what would you change from test case run?
08:21:14 <jose_lausuch> aha ok
08:21:41 <SerenaFeng> just a proposal, I am not an expert either, so hope morgan_orange can give us some advice
08:21:43 <HelenYao> this will group the url by resource. if we have tons of url(some think run/stop can be specified in the url directly), it is not easy to maintain
08:22:10 <SerenaFeng> more friendly than process it in coding
08:22:33 <jose_lausuch> what do the others say? silent? or no clue (like me)?
08:22:58 <SerenaFeng> either process it in url or in coding, it is a must thing, the problem is where
08:23:40 <HelenYao> one thing about the url, it should be better to include noun instead of verb
08:24:01 <HelenYao> i did not see url like 'http://<hostname>/api/v1/functest/testcases/action/run'
08:24:02 <jose_lausuch> why does it matter?
08:24:49 <HelenYao> it's more about best practice
08:25:25 <jose_lausuch> I can ask another expert on my side
08:25:37 <morgan_orange> SerenaFeng: LindaWang I will ask Benoit for an external view
08:26:08 <jose_lausuch> http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful
08:26:11 <jose_lausuch> interesting reading
08:26:55 <jose_lausuch> https://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/
08:27:01 <jose_lausuch> first rule: 1. Use nouns but no verbs
08:27:52 <HelenYao> I came across the 1st article the other day
08:28:01 <jose_lausuch> ok
08:28:15 <jose_lausuch> I think we can also add some comments in the wiki as such
08:28:27 <jose_lausuch> but it seems we don't have consensus
08:28:38 <HelenYao> Jack is here
08:28:41 <SerenaFeng> I try to ask an expert
08:28:47 <SerenaFeng> he don't remember it :(
08:28:48 <HelenYao> we may refer to Yardstick
08:28:56 <jose_lausuch> hi JackChan
08:28:56 <JackChan> Hi
08:29:04 <SerenaFeng> but he said one url one thing
08:30:10 <morgan_orange> let me ask Benoit to join
08:30:19 <benoit_orange> hi all
08:30:23 <JackChan> We use action for the follow reason:
08:30:27 <morgan_orange> ah he is here , hello benoit_orange
08:30:41 <jose_lausuch> so we have all the experts in the room
08:30:43 <jose_lausuch> :)
08:31:24 <benoit_orange> If I can help....
08:31:27 <JackChan> 1. OpenStack uses the pattern /action
08:31:46 <jose_lausuch> benoit_orange: JackChan: this is our rest api proposal for Functest https://wiki.opnfv.org/display/functest/Functest+REST+API
08:31:55 <jose_lausuch> we are wondering about the URL composition
08:32:10 <JackChan> 2. we can leverage the url reflection for better scalability
08:34:05 <jose_lausuch> ok
08:34:16 <SerenaFeng> after some discussion, I agree there's no one can say his/her is standard, so I accept both :) sorry for my insist before
08:34:20 <jose_lausuch> so, looks like /action and using run in the arguments make sense
08:34:21 <JackChan> 3. we are putting operations against each resource under /<resource>/action, it make the url more organized
08:34:44 <SerenaFeng> different people have different preference
08:35:15 <HelenYao> it's great that we have a hot discussion
08:36:03 <benoit_orange> well, on pure "state of the art" point of view, as u know, the "R" in REST stand for Resources. So, the /action sounds strange like an action is not exactly a resource.....
08:36:54 <HelenYao> this is an action against a resource
08:36:55 <SerenaFeng> yes, action is strange, so difficult to organize it
08:37:05 <JackChan> I think the resource is before action
08:37:08 <SerenaFeng> url reference to a resources
08:38:03 <JackChan> But if we want to do a action, like run a test case, what noun we should use?
08:38:04 <benoit_orange> generaly, and action change the status of smth.... so it's also possible to have a POST on /resources/id/status. f.e POST "run" state of a scenario
08:39:03 <benoit_orange> againt, in "pure REST conception" action is not a part of the public URL model. It more an HTTP verb on a partiular resource
08:39:46 <HelenYao> there is a problem with the url proposal, POST http://<hostname>/api/v1/functest/testcases/<id>/action
08:39:48 <benoit_orange> POST "run" on http://<hostname>/api/v1/functest/testcases/state  ?
08:40:59 <benoit_orange> or POST "run" on http://<hostname>/api/v1/functest/testcases/scheduler
08:41:25 <JackChan> Actually 'state' is a little strange to me.
08:42:21 <benoit_orange> ok.
08:42:22 <benoit_orange> just to illustrate I'll give you a typical telco example (same problem): "how to send an SMS?"
08:42:47 <jose_lausuch> in the other hand, it would be also nice to have something similar to yardstick's api, to be kind of opnfv consistent
08:42:50 <benoit_orange> the answer may me by posting it to the "inbox" resource of the receipient
08:44:00 <benoit_orange> here we can imagine to post  run request not to the testcase itself but to the resource in charge or running testcases (f.e scheduler)
08:44:19 <jose_lausuch> benoit_orange: but we don't have a scheduler as such...
08:45:01 <HelenYao> i would say, if we want to get rid of /action, we have to think about sub-resources
08:45:18 <benoit_orange> I agree
08:45:45 <HelenYao> e.g /testcases/<id>/action -> /testcases/<id>/scheduler
08:46:05 <benoit_orange> or think about the result of the action
08:46:09 <jose_lausuch> what would be scheduler in our case?
08:46:38 <HelenYao> scheduler is just one example, we may have to come up with a noun list to map the operation
08:47:04 <HelenYao> e.g. run a testcase, we have to think about a name for the sub-resource
08:47:12 <benoit_orange> may be the term is not correct, but the concept may be:
08:47:13 <benoit_orange> /testcase(s) : testcases definition by themself
08:47:13 <benoit_orange> /scheduler: engine in charge of running testcases
08:48:01 <jose_lausuch> scheduler could be our "run_tests.py" script
08:48:18 <SerenaFeng> I think scheduler means runner in our case
08:48:32 <jose_lausuch> yes
08:48:52 <jose_lausuch> so, conclussions?
08:48:56 <benoit_orange> yeap.
08:48:56 <benoit_orange> this is creating a new resource.
08:48:56 <benoit_orange> the other proposal is ton think about the "change" on the testcase when it runs. f.e example it status switch to running
08:49:12 * HelenYao will save us trouble from coming up with names for sub-resources
08:49:26 <JackChan> So we are now find a noun to replace 'action",right?
08:49:30 <HelenYao> i would say /action will save us trouble from coming up with names for sub-resources
08:49:53 <HelenYao> if we still want to get rid of /action, we may discuss about the name list
08:50:54 <HelenYao> if /testcases/<id>/action, we need to think CRUD against /testcases/<id>/<???>
08:51:01 <SerenaFeng> in this case I think we don't need to come up with another noun
08:51:21 <jose_lausuch> I would be fine with action
08:51:24 <jose_lausuch> and in line with yardstick
08:51:31 <SerenaFeng> if action means to be put in body, the current impl is also ok, I accept that
08:51:45 <SerenaFeng> agree
08:52:07 <jose_lausuch> maybe it's not following the best practices with resources and so on, but for our framework it would make sense
08:52:08 <jose_lausuch> not sure
08:52:17 <jose_lausuch> anyway
08:52:22 <SerenaFeng> I think so
08:52:24 <jose_lausuch> thanks a lot for your thoughts and your ideas
08:52:29 <jose_lausuch> appreciated
08:52:44 <HelenYao> ok, so we will use /action?
08:52:46 <jose_lausuch> JackChan: do you have the rest api explained somewhere in the wiki?
08:52:53 <SerenaFeng> btw, shouldn't it be http://<hostname>/api/v1/functest/testcases/<testcase>/action, if we want to keep consistent with openstack
08:53:05 <SerenaFeng> I think <testcase> is missing in the wiki page
08:54:16 <JackChan> yes, currently is missing, it is for some historical reason. We will put it next version.
08:54:50 <JackChan> For example: http://<hostname>/api/v1/functest/testcases/<testcase_id>( or <testcase_name> )/action
08:54:50 <HelenYao> SerenaFeng: you are right, I mentioned it earlier.POST http://<hostname>/api/v1/functest/testcases/<id>/action
08:55:12 <SerenaFeng> I would suggest to substitute id with testcase name
08:55:37 <HelenYao> i would suggest to use id
08:55:40 <SerenaFeng> there's no id
08:55:52 <jose_lausuch> we don't have ids for the test cases
08:56:01 <SerenaFeng> which id will you use to reference vping_ssh or tempest
08:56:06 <jose_lausuch> I Think test case name is clearer
08:56:08 <JackChan> since now there no mapping of name and id, so it is hard to use id.
08:56:12 <HelenYao> name is given by user and it will require much operation such as replacing special characters
08:56:27 <benoit_orange> if the testcase name is used as an identifier, it's an id... don't u think?
08:56:31 <jose_lausuch> our test cases names are a single word, no spaces
08:56:41 <JackChan> But maybe next version, we can set a mapping of name and id. And then we can use id.
08:56:48 <jose_lausuch> the way we run the CLI is with test case name
08:56:53 <JackChan> jose_lausuch: yes
08:57:01 <SerenaFeng> benoit_organge agree, but it is not what they references
08:57:02 <jose_lausuch> but yes, maybe next version we could also add IDs for test cases and change that
08:57:18 <SerenaFeng> I disagree with id
08:57:23 <SerenaFeng> name is more clear
08:57:27 <jose_lausuch> yep
08:57:39 <HelenYao> so long the testcase name is unique and does not include special charater, i agree with testcase name
08:57:52 <SerenaFeng> since id can not be retrieved easily. name is clearer in our case
08:57:53 <JackChan> jose_lausuch: yes, maybe next version. we need a mapping in database.
08:58:19 <jose_lausuch> we made sure of that already https://hastebin.com/reqirerihu.rb
08:58:20 <benoit_orange> yeap. The only thing is to keep in mind that's just an information for humans but it shouldn't have any sens for a machine
08:58:22 <HelenYao> how url for env?
08:58:25 <jose_lausuch> all of our test cases are lowercase without spaces
08:58:27 <HelenYao> how about url for env?
08:58:33 <HelenYao> there is no name for env
08:58:51 <SerenaFeng> env is ok
08:59:00 <jose_lausuch> yes, env is ok
08:59:05 <SerenaFeng> we don't need specify id/name for every url
08:59:09 <HelenYao> http://<hostname>/api/v1/functest/envs/<env_name>/action
08:59:15 <HelenYao> this is the correct url
08:59:18 <jose_lausuch> #info agreed: POST http://<hostname>/api/v1/functest/testcases/<id>/action
08:59:20 <SerenaFeng> as long as it reference to a single resource, it is ok
08:59:24 <morgan_orange> and in theory we create only case name with [a-z0-9_]
08:59:25 <jose_lausuch> #undo
08:59:25 <collabot`> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2357610>
08:59:32 <jose_lausuch> #info agreed POST http://<hostname>/api/v1/functest/testcases/testcase/action
08:59:52 <HelenYao> POST http://<hostname>/api/v1/functest/testcases/<testcase_name>/action
09:00:00 <jose_lausuch> #undo
09:00:00 <collabot`> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2357610>
09:00:04 <JackChan> In yardstick gui, we use http://<hostname>/api/v1/functest/envs/openrc/<openrc_id>/action
09:00:05 <jose_lausuch> #info agreed POST http://<hostname>/api/v1/functest/testcases/<testcase_name>/action
09:00:14 <HelenYao> how about env?
09:00:24 <HelenYao> http://<hostname>/api/v1/functest/envs/<env_name>/action?
09:00:29 <jose_lausuch> I'm fine with http://<hostname>/api/v1/functest/env/action
09:00:31 <SerenaFeng> that's because you specified a id for openrc
09:00:34 <jose_lausuch> there is no env names
09:00:41 <SerenaFeng> but here in Functest we don't
09:01:02 <SerenaFeng> if we want to support multiple envs, it's ok to use env_id
09:01:08 <SerenaFeng> because env is dynamic created
09:01:09 <JackChan> yes, since we have database with api. We will record the mapping of openrc and its id.
09:01:09 <jose_lausuch> not currently
09:01:12 <jose_lausuch> maybe for the future
09:01:15 <SerenaFeng> testcase is static configured
09:01:34 <SerenaFeng> we don't have database now
09:01:53 <jose_lausuch> we are out of time
09:01:53 <SerenaFeng> our testcase is defined statically in testcase.yml
09:02:02 <jose_lausuch> can't discuss framework, but I think it's in gerrit all
09:02:13 <jose_lausuch> let's continue with reviewing Cedric's patches
09:02:20 <jose_lausuch> JackChan: benoit_orange: thanks a lot!
09:02:47 <JackChan> Thank you all~
09:02:53 <SerenaFeng> also thanks a lot
09:02:56 <SerenaFeng> learned a lot
09:03:06 <HelenYao> I updated the wiki. could you help to have a check?
09:03:11 <HelenYao> https://wiki.opnfv.org/display/functest/Functest+REST+API
09:03:31 <HelenYao> thanks, guys
09:03:52 <jose_lausuch> HelenYao: yes
09:03:56 <jose_lausuch> we need to close
09:03:58 <jose_lausuch> anything else?
09:04:45 <SerenaFeng> nope from my side
09:04:51 <HelenYao> no from me
09:04:57 <jose_lausuch> ok
09:05:03 <jose_lausuch> let's continue offline then
09:05:07 <jose_lausuch> #endmeeting