19:00:41 <catherineD> #startmeeting refstack
19:00:42 <openstack> Meeting started Tue Aug  8 19:00:41 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:46 <openstack> The meeting name has been set to 'refstack'
19:01:43 <hogepodge> o/
19:01:56 <catherineD> #link meeting agenda and notes,  https://etherpad.openstack.org/p/refstack-meeting-17-08-08
19:02:03 <pvaneck> o/
19:02:18 <mguiney> o/
19:03:17 <catherineD> Let's start
19:03:34 <catherineD> #topic Run tool to update the verification field
19:04:54 <catherineD> mguiney: any thing you want to bring up?
19:06:25 <catherineD> if not let's move on ..
19:06:40 <mguiney> nope, not really
19:06:43 <mguiney> (sorry)
19:06:46 <catherineD> #topic subunit result files upload
19:07:52 <catherineD> pvaneck: has done some investigation on the impact to RefStack if we save the subunit data to the RefStack db
19:08:20 <catherineD> #link Please read  Paul's comments in https://review.openstack.org/#/c/487185/
19:08:29 <mguiney> excellent, thank you
19:09:03 <catherineD> IMO Mirgration of RefStack data to new tables is not desirable
19:09:28 <luzC> o/
19:09:46 <hogepodge> catherineD: pvaneck: so your recommendation is to use two databases?
19:10:35 <mguiney> i did add a suggestion to the newest version of the spec about how to handle that
19:12:07 <catherineD> mguiney: the new suggestion is to handle migration of the the data?
19:13:23 <catherineD> pvaneck: if we create the version table ahead of time will this prevent the creation of existing (2nd version)  table on the  future db update if any?
19:13:25 <mguiney> the proposed solution in my spec is to create aspmall tool to migrate existing data if the db already exists
19:13:54 <mguiney> and to have the alternate table name as a flag in conf
19:14:12 <mguiney> (which is a feature that i am testing and shortly planning on pushing to gerrit)
19:14:38 <pvaneck> since the table will be already created, alembic wont try to create it again, and will just pull the current version from there
19:15:05 <pvaneck> id prefer to keep everything in the same db
19:15:22 <catherineD> Personally, if I need to migrate existing RefStack data ... I would prefer to use a separated DB for subunit2sql data
19:15:35 <mguiney> that way people who dont want to set up their db to handle subunit data can do so, but if they decide to change their minds later on, they can run a utility script to migrate the existing data to a differently named table
19:16:54 <catherineD> I would keep everything in the same db if there is a solution that I do not need to migrate the RefStack data
19:17:00 <pvaneck> what data is migrating exactly
19:17:36 <mguiney> just the data in the alembic_version table
19:17:54 <catherineD> if a new version of existing RefStack tables are created we need to migrate the data to those new table .. right?
19:18:16 <mguiney> yes, but the only colliding table is the alembic_version table
19:19:33 <catherineD> mguiney: if I understand pvaneck: 's comment corectly all new version of existing tables will be created not the the alembic_version table
19:20:21 <catherineD> pvaneck: do I understand your comments correctly?
19:20:31 <pvaneck> catherineD: the only new table need is the refstack_alembic_version, once you have that connected with the refstack backend, then we can freely use subunit2sql in the same datbase
19:20:38 <mguiney> ^
19:20:56 <hogepodge> That seems like the solution to pursue
19:21:01 <mguiney> that was the understanding i had as well
19:21:11 <mguiney> apologies for the lack of clear communication
19:21:17 <pvaneck> so i think a tool to handle this is fine
19:21:26 <mguiney> awesome. I will start on that
19:21:38 <catherineD> ok
19:22:45 <luzC> ok, I'm not familiar with the solution at all, so I'll wait for mguiney tool to take a look
19:22:46 <mguiney> it shouldn't be too major. Likewise, i am nearly ready to push the patch which will allow new refstack instances to custom name their alembic version table
19:22:59 <mguiney> (testing testing)
19:23:32 <mguiney> this will be an update the the patch mtreinish pushed that will allow us to use his solution without breaking existing dbs
19:24:17 <catherineD> pvaneck: mguiney: the test should include a sample (minor)  RefStack DB update to make sure that it works on the next RefStack DB update
19:25:03 <mguiney> ahhh that would make sense
19:25:23 <luzC> +1
19:26:09 <catherineD> #agreed Still using RefStack DB for the new subunit2sql tables
19:26:24 <mguiney> excellent, thank you
19:26:43 <catherineD> anything else on this topic?
19:27:05 <mguiney> other than asking y'all to take a look at the spec, not really!
19:27:13 <mguiney> (and review, of course)
19:28:05 <catherineD> mguiney: since we do not exactly which direction we will take ... that is why we have not merged the spec .. i hope it does not prevent you from working on the implementation
19:28:24 <mguiney> of course not, as mentioned, i am working on the flag, which is the first step
19:28:30 <catherineD> via implementation we will have new findings ...
19:28:40 <mguiney> and when i get that pushed, i will be working on the utility script as well
19:28:59 <catherineD> this is not the convetional ways ... but since we are all new to this .. kind of trial and error ..
19:29:34 <mguiney> (apologies for my new-ness, of course :) )
19:29:56 <catherineD> mguiney: np thank you for actively working on this
19:30:04 <catherineD> #topic Pending reviews
19:30:20 <catherineD> #link     Add python35 support  (  https://review.openstack.org/#/c/483999/  )
19:30:43 <catherineD> luzC: thanks for the update ...
19:30:57 <catherineD> everyone please review the new patch
19:31:15 <catherineD> #link     WIP: Set a custom alembic_version for refstack (  https://review.openstack.org/#/c/487185/ )
19:31:39 <mguiney> that one is very much not the version that will be upcoming
19:31:50 <mguiney> the other version is a bit more functional
19:32:31 <catherineD> so waiting for a new version for  https://review.openstack.org/#/c/487185/
19:32:41 * mguiney nods
19:33:45 <catherineD> My thinking is we should not merge this patch until the refstack_alemic_version is crerated in the refstack db in infra
19:34:08 <mguiney> +1
19:34:10 <catherineD> assuming that we will create tools to create the table ahead of time
19:34:46 <catherineD> that means the tools will be created in refstack-puppet?
19:35:51 <mguiney> the alembic_version migration tool, correct?
19:36:27 <catherineD> mguiney: yea
19:36:49 <mguiney> sounds good
19:36:52 <pvaneck> probably only needs to be run once. could just get an infra member to do it manually if need be
19:37:17 <catherineD> 1) create the table 2) migrate the info from the existing table to the newly create table
19:37:55 <mguiney> yeah, it should only need a single run
19:38:04 <catherineD> pvaneck: so that mean create the tool in RefStack and have someone in ifra run it?
19:38:19 <mguiney> and a change in conf to make sure the db remembers what the table is named
19:38:26 <mguiney> sounds good to me
19:40:10 <pvaneck> catherineD: yea, can do that
19:40:18 <catherineD> #agreed Create a tool in refstack to create the refstack_alembic_version table and migrate the data from the current alembic_verstion table to the newly created table
19:40:53 <catherineD> moving on .
19:41:03 <catherineD> #link     Add UI support for interop schema 2.0 (  https://review.openstack.org/#/c/484625/ )
19:41:40 <catherineD> hogepodge: This is the patch to support Interop-WG schema 2.0
19:41:54 <catherineD> everyone please review ..
19:42:09 <luzC> will do
19:42:36 <catherineD> #topic Open discussion
19:42:40 <mguiney> o7
19:42:56 <catherineD> #topic candidacy for RefStack PTL (hogepodge)
19:43:29 <hogepodge> If there aren't any other more qualified candidates, I will run as PTL for RefStack this cycle
19:43:32 <catherineD> I think today is the last day
19:43:40 <catherineD> hogepodge: +++
19:43:47 <catherineD> Thank you!
19:43:48 <mguiney> hogepodge: ++
19:44:21 <hogepodge> With full understanding that I'm not qualified as a core contributor, but will focus on transitioning by building the dev team and looking for new governance models if we need to move into a maintenance mode.
19:44:22 <catherineD> I think you are the best candidate
19:44:45 <hogepodge> I didn't want to submit that without the support of the current team, though.
19:45:06 <hogepodge> Thank you catherineD. You've been a great steward of the project. Thank you for your years of work on it.
19:45:30 <catherineD> hogepodge: please do ... there are only a few porjects that have no candidate and RefStack is one of them
19:45:44 <luzC> hogepodge: ++
19:46:17 <hogepodge> I'll file the candidacy forms today and announce on the mailing list.
19:46:20 <catherineD> I am so happy that you will lead the team on this journey ...
19:47:04 <catherineD> hogepodge: Thanks again!  I know the project is in good hands ...
19:47:11 <hogepodge> Thanks :-)
19:47:40 <hogepodge> I even meet the technical requirements, with a merged patch. :-D
19:47:41 <catherineD> I also want to recommend to add mguiney: as core for RefStack
19:47:47 <hogepodge> +1
19:47:52 <mguiney> :D
19:48:29 <catherineD> mguiney: have been actively contribute to the project ...
19:48:58 <catherineD> I will send out and email after the meeting ...
19:48:59 <luzC> +1
19:49:07 <pvaneck> +1
19:49:38 <catherineD> I guess that is it for today!
19:50:05 <catherineD> any other topic to discuss?
19:51:18 <catherineD> hearing nothing.  I think we can close up for the day
19:51:25 <catherineD> thank you all!
19:51:45 <catherineD> #endmeeting