19:00:06 <catherineD> #startmeeting refstack 19:00:07 <openstack> Meeting started Tue Jul 25 19:00:06 2017 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:11 <openstack> The meeting name has been set to 'refstack' 19:02:17 <pvaneck> o/ 19:02:31 <chandankumar> \o/ 19:03:18 <catherineD> chandankumar: thank you for staying up for this meeting ... is it mid night for you? 19:03:40 <mguiney> o/ 19:04:04 <chandankumar> yes 19:04:23 <catherineD> chandankumar: :-( 19:04:30 <catherineD> hi everyone .. 19:04:42 <catherineD> #link meeting agenda and notes, https://etherpad.openstack.org/p/refstack-meeting-17-07-25 19:04:51 <mguiney> hello! 19:05:01 <catherineD> #topic Run tool to update the verification field 19:06:02 <catherineD> mguiney: anything you want to add? 19:08:21 <catherineD> if not, we can move on ... 19:08:42 <mguiney> still testing, ran into a possible bug with json token auth 19:08:42 <mguiney> was planning on dealing with/looking into that shortly, but spent yesterday putting out fires instead 19:08:43 <mguiney> i think that the necessary jwt package may not be installing when you set up refstack 19:08:43 <mguiney> i had to install it manually 19:08:43 <mguiney> but i need to recheck 19:08:43 <mguiney> and make sure i didnt miss anything 19:11:16 <catherineD> checking .. 19:12:05 <catherineD> jwt is installed in the server side https://github.com/openstack/refstack/blob/master/requirements.txt#L16 19:13:08 <mguiney> ok, i'll take a peek, probably did just derp 19:13:16 <mguiney> and miss a step 19:13:22 <catherineD> on the client side .. it does not include in refstack-client because the token was create prior to calling refstack-client 19:13:40 <catherineD> refstack-client just consume the token 19:14:36 <mguiney> ok i must have missed a step then in installation 19:14:49 <catherineD> for client side you have to install that manually although those instrcution should be added in the refstack-client readme if they are not there already 19:15:15 <mguiney> i can push a patch to do that after the meeting 19:15:17 <catherineD> chandankumar: I believe you look at the refstack-client readme lately 19:15:30 <chandankumar> catherineD: yes, 19:15:38 <catherineD> did you see step calling for installation or creation of the jwt token> 19:15:40 <catherineD> ? 19:16:32 <catherineD> alright we will take a look after the meeting ... 19:16:41 <luzC> o/ 19:17:33 * catherineD waves at luzC: 19:17:59 <chandankumar> catherineD: but i have not tried refstack api server but played with client there i have not found jwt usage 19:18:41 <catherineD> chandankumar: mguiney: thanks ... I think we may need to update the refstack-client readme 19:19:02 <catherineD> let's move on ... we have a lot to discuss today 19:19:19 <catherineD> #topic subunit result files upload 19:19:21 * chandankumar will take a look in the morning. 19:19:40 <mguiney> cool, i can deal with that if that would be more convenient 19:20:00 <catherineD> last week we agreed that the subunit data will be saved in a different database ... 19:20:40 <catherineD> on second thoughts I think that we can use current refstack database if there is not table name conflict 19:21:16 <mguiney> i think both are alembic managed though, yes? 19:21:37 <catherineD> mguiney: yup ... 19:21:56 <catherineD> so I think we can explore the option of using the same database ... 19:22:03 <mguiney> mtreinish brought up that the version table will collide because of that 19:22:51 <mguiney> but perhaps we could add a few of the tables into the refstack schema, rather than just pointing the db setupscript from subunit2sql at the refstack db? 19:23:00 <catherineD> to know for sure ... I think we can quickly test and confirm that before we make the final decision 19:23:11 <mguiney> makes sense 19:23:42 <catherineD> mguiney: exactly ,,, check the table name on 2,1,2,1,1 and 2.1.2.1.2 in the agenda https://etherpad.openstack.org/p/refstack-meeting-17-07-25 19:23:55 <catherineD> the table names are listed there 19:24:22 <mguiney> i can take a look at that today 19:24:49 <mguiney> testing to see if a collision occurs, that is, given that i've already been poking at subunit2sql 19:24:52 <catherineD> the only confusion may due to there is a table name "test" in refstack and "tests" in subunit2sql created table 19:25:03 <luzC> ok, so if I understand correctly, the idea would be to have a single DB (kind of merge refstack and subunit2sql db)? 19:25:09 <catherineD> mguiney: great 19:25:13 <mguiney> true. though they appear to have very distinct semantic meanings 19:25:37 <catherineD> luzC: not merging because subunit2sql will create new tables 19:26:01 <catherineD> practically we just create more talbes in the existing refstack database 19:26:12 <luzC> ahh ok, I see 19:26:47 <mtreinish> mguiney: by default the alembic version table name will conflict. It defaults to alembic_version 19:27:10 <mtreinish> although iirc it's configurable in alembic 19:27:54 <catherineD> mtreinish: good point and good that it is configurable ... 19:28:01 <catherineD> but we will do some test first ... 19:28:19 <mguiney> thank you mtreinish 19:28:49 <mtreinish> catherineD: it's configurable in alembic, but I know that subunit2sql doesn't expose that option. The alembic config is part of the repo 19:28:50 <catherineD> having all tables in the same database may be easier in the future for a complete migration to use subunit2sql for test data 19:30:51 <mguiney> so... could we perhaps add the tables into refstack itself? 19:31:15 <mguiney> that way we don't end up using the setup functionality from subunit2sql? 19:31:31 <mguiney> it would be a bit of redundancy, but that might allow us to do what we need 19:32:10 <mtreinish> mguiney: I would strongly recommend against that, it's very tricky to keep the schema in sync with subunit2sql if you do it all by hand 19:32:34 <mtreinish> we use the migrations to enable evolving things over time in subunit2sql, and the schema does change 19:32:56 * mguiney nods 19:33:07 <mguiney> i can see how that would be problematic 19:33:26 <catherineD> mtreinish: ic we will take a look and see how it should be done .. preferably, we do not want to customize the tool's code (subunit2sql ) except for conmfiguration 19:34:07 <catherineD> the point to use existing tools is for minimizing maintenance 19:34:46 <catherineD> let do some testing before we decide on whether using the same or separated db 19:35:22 <catherineD> moving on .. 19:35:29 <catherineD> #topic High level tasks in priority order 19:36:10 <catherineD> tasks are listed on : 2.3.1 --> 2.3.6 19:38:44 <catherineD> so our first priority should be getting the subunit2sql running assuning that the subunitfile has already been upload to the server side ... 19:39:32 <catherineD> that should be the first priority .. 19:41:12 <catherineD> #topic Link subunit data to RefStack options 19:41:54 <catherineD> mguiney: I discuss to use a key-value pair to link the subunit data to refstack for the time being ... 19:42:56 <catherineD> mguiney: I have not checked your latest patch ... do you still suggest us to add a new field to the existing refstack table? 19:44:38 <catherineD> mguiney: just check I see that you mention using meta data .. 19:45:21 <mguiney> sorry 19:45:27 <mguiney> was offline for a sec 19:45:51 <catherineD> mguiney: np ... 19:45:51 <mguiney> i updated the spec to talk about using the keypair rather than an additional field 19:46:17 <catherineD> mguiney: yea just see that ... thanks 19:46:36 <mguiney> although it looks like i need to remove adding the field from the work items. 19:46:42 <mguiney> i missed that instance 19:47:00 <catherineD> yea .. 19:47:07 <catherineD> anything else on this topic? 19:47:18 <mguiney> nope, that is about it for now 19:47:45 <catherineD> yea I am sure we will be discussing this topic for the next few weeks :-) 19:48:45 <mguiney> it seems that way, yes 19:49:13 <catherineD> mguiney: we guess we can do the subunit2sql evaluation/test parallelly 19:49:21 <mguiney> but i'd definitely rather get the details nailed down as well as possible 19:49:25 <catherineD> with the spec review 19:49:31 <catherineD> mguiney: ++ 19:49:50 <mguiney> absolutely, can do 19:50:01 <catherineD> #link everyone please review https://review.openstack.org/#/c/480298/ 19:50:23 <catherineD> #topic Pending reviews 19:50:37 <catherineD> #link Add python35 support ( https://review.openstack.org/#/c/483999/ ) 19:51:15 <catherineD> luzC: I am sorry for the delay in reviewing this patch ... I need to get my test env up for testing 19:51:47 <catherineD> should be able to run the test shortly .. 19:53:05 <catherineD> next ... 19:53:42 <catherineD> #link Everyone please review --> Switch to refstack-client binary and some cleanup ( https://review.openstack.org/#/c/486910/ ) 19:54:30 <catherineD> pvaneck: anything to add on 19:54:42 <catherineD> #link Add UI support for interop schema 2.0 ( https://review.openstack.org/#/c/484625/ ) 19:55:24 <pvaneck> yea, just some test coverage 19:55:34 <pvaneck> I will add some soon 19:55:40 <catherineD> pvaneck: great thanks 19:55:59 <catherineD> moving on .. 19:56:06 <catherineD> #topic Open discussion 19:56:33 <catherineD> #topic PTL election 19:57:15 <catherineD> As I had mentioned a couple weeks ago, I will not be running for PTL for the next cycle ... 19:58:06 <catherineD> Please consider to run for PTL, we need new leadership to carry on the project .. 19:59:33 <catherineD> we are at the top of the hour ... 19:59:47 <catherineD> thank you all for attending ... 19:59:51 <catherineD> bye 20:00:01 <catherineD> #endmeeting