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