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