19:00:18 <catherineD> #startmeeting refstack 19:00:19 <openstack> Meeting started Tue Aug 15 19:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:23 <openstack> The meeting name has been set to 'refstack' 19:01:41 <pvaneck> o/ 19:02:06 <hogepodge> o/ 19:02:44 <catherineD> #link meeting agenda and notes, https://etherpad.openstack.org/p/refstack-meeting-17-08-15 19:05:42 <catherineD> Let's start ... 19:05:42 <hogepodge> mguiney will be late today 19:06:07 <catherineD> #topic Welcome Megan as core reviewer for RefStack 19:06:20 <hogepodge> \o/ 19:06:33 <catherineD> I have added mguiney as the core ... 19:06:43 <catherineD> hogepodge: I guess I need to add you too? 19:06:49 <hogepodge> catherineD: yes 19:07:07 <luzC> o/ 19:07:53 <catherineD> I will do that after the meeting ... you definitely need that as our new PTL 19:08:16 <luzC> when is the PTL transition happening? 19:08:20 <catherineD> Everyone, please welcome hogepodge: as our PTL for the next cycle 19:08:51 <hogepodge> Thank you! 19:08:56 <pvaneck> Welcome new PTL! 19:09:03 <luzC> :-) welcome 19:09:11 <catherineD> luzC: I think voting ends tomorrow ... we do not have any other candidate ... so hogepodge: is our PTL 19:09:19 <hogepodge> I have big shoes to fill, and understand the unique circumstances in this transition. 19:09:32 <hogepodge> thank you catherineD for being such an amazing project lead 19:09:47 <catherineD> hogepodge: Thanks ! 19:10:36 * luzC totally agree, big thanks! 19:10:54 <catherineD> so I know adding hogepodge: to https://review.openstack.org/#/admin/groups/281,members is the first step 19:11:16 <catherineD> hogepodge: I guess you will run the meeting starting next week ? 19:11:22 <hogepodge> catherineD: yes 19:11:37 <catherineD> hogepodge: great! Thanks! 19:12:33 <mguiney> o/ 19:12:37 <catherineD> hogepodge: I guess you and I can discuss more on what to do 19:12:56 <catherineD> mguiney: welcome our core reviewer!!! 19:13:05 <mguiney> (also yay! so exited to get started as a core!) 19:13:14 <catherineD> mguiney: please check to see whether you can +2 .. 19:13:23 <hogepodge> congratulations mguiney! 19:13:42 <hogepodge> catherineD: yes, we can connect later. I have a lot to learn 19:14:23 <catherineD> will do 19:14:37 <catherineD> anything else? 19:15:56 <catherineD> alright moving on ... 19:15:58 <mguiney> It looks like I do, in fact, have +2 19:16:29 <catherineD> mguiney: great 19:16:49 <catherineD> ok moving on .. 19:16:55 <catherineD> #topic Run tool to update the verification field 19:17:12 <catherineD> any update? 19:18:20 <mguiney> no, apologies 19:18:37 <catherineD> mguiney: np .. I know it is a long process 19:18:43 <mguiney> was working on some other tasks and did not get to it, i will put that high on my list this week 19:18:50 <mguiney> it's been stalled too long >.< 19:19:10 <catherineD> mguiney: np 19:19:32 <catherineD> #topic subunit result files upload 19:19:56 <catherineD> #link Set a custom alembic_version for refstack ( https://review.openstack.org/#/c/487185/ ) 19:20:07 <mguiney> yes! so there has been some forward movement on this front 19:20:17 <mguiney> of course 19:21:17 <catherineD> hogepodge: you should be able to +2 now 19:21:19 <mguiney> I had to make some tweaks to the alembic conf patch, and after deep diving into how do alembic, it has brought up an interesting possibility 19:22:47 <mguiney> namely, that a migration script may not even be necessary, given that it is entirely possible to get alembic to recheck conf and modify the EnvironmentContext object it uses to manage the database based on that 19:23:45 <hogepodge> mguiney: that sounds fantastic. Do you have a dataset you can test against? 19:24:22 <luzC> also for this patch there is a pending item to test the migration a populated DB 19:24:28 <luzC> rigth? 19:24:33 <mguiney> i've been working with a fresh db but populating the db is just a matter of running and uploading some smoke tests 19:24:46 <mguiney> and then making sure it doesnt break when i make changes to conf 19:25:36 <mguiney> luzC: as mentioned, I've been planning on running the testing on the upcoming version of the test with a populated database 19:25:37 <catherineD> The most important scenario to test is testing on an existing environment with the old version table name .. 19:25:46 * mguiney nods 19:26:03 <mguiney> because that's where trouble is most likely to occur 19:26:13 <catherineD> mguiney: ++ 19:26:34 <mguiney> *of the patch 19:26:49 <catherineD> so we will wait for those testing before we can merge https://review.openstack.org/#/c/487185/ ? 19:28:20 * mguiney nods 19:28:42 <catherineD> alright .. 19:28:56 <mguiney> the minor change to conf, i think, is small enough and related enough, contextually that it likely doesnt merit its own patch 19:29:10 <mguiney> to the code, not to conf 19:30:41 <catherineD> mguiney: it is a good change ... maybe we just put a note in there that special handlings are needed if the version table name is changed on an existing environment 19:31:25 <catherineD> and the default is what we have today .. then we can merge the patch ... 19:31:27 <mguiney> can do. 19:31:45 <mguiney> That said, I did want to get some opinions on things I mentioned re: patch comments 19:32:04 <mguiney> (If we have time) 19:32:16 <mguiney> Specifically about usage/documentation 19:33:34 <catherineD> mguiney: we have time 19:33:36 <mguiney> my thought was to mention the configuration/subunit data upload case conf modifications, setup and implications in the actual documentation, rather than doing so more verbosely in the CONF description 19:35:01 <catherineD> regarding the setup of alembic_version variable? 19:35:17 <mguiney> That way it would be easier to find, for someone who is considering how to set up a refstack server instance, as well as being fairly well in line with the current (optional) sections we have in setup docs as is 19:36:32 <mguiney> and the implications of subunit data. Admittedly this was a more important thing to have a docs section for when migration was still the plan, but I thought I might get opinions regardless 19:39:01 <pvaneck> yea, i think it is fine in the docs 19:39:24 <catherineD> so in the past we hard code verstion table name as alembic_version ... now we allow user to customize this table name by surface the variable version_table (default to alembic_version) in the config file 19:40:18 <catherineD> we just need to make a note that if the variable is changed on an existing environment then there are additional tasks that need to be performed before the name change 19:40:27 <mguiney> can do 19:40:38 <mguiney> cool, thank you for that clarification 19:41:06 <catherineD> ok moving on 19:41:22 <catherineD> #link Create spec for optional subunit data import ( https://review.openstack.org/#/c/480298/ ) 19:42:54 <pvaneck> looks fine to me 19:42:56 <luzC> I'll take a look... 19:43:12 <luzC> from what I recall it was good too 19:43:21 <luzC> but haven't check the latest changes 19:44:36 <catherineD> My only concern is we still investigating on the database stuff ... if we merge the spec as is ... that means that we will save the new table in the refstack db which we still investigate 19:45:05 <luzC> I think we can wait... 19:45:10 <mguiney> the only change was a tweak to make the wording a bit, er... kinder 19:45:51 <catherineD> I feel more confortable to merge this spec we we isolate the backend db task out by stating that the subunit data will be save a a db and make this db a configurable parameter 19:46:18 * mguiney nods 19:46:28 <catherineD> that way we have the option of saving it in the refstack db or its own db by just initializing the db name 19:46:53 <mguiney> that makes sense, and it would just mean another conf check on refstack's end 19:47:19 <mguiney> well, and perhaps the overhead of another db 19:47:51 <catherineD> yea that way we have choices and do not need to change the spec if (for whatever reason) we do not want to use refstack db 19:47:51 <mguiney> but to be fair, it also appears as though we will be able to store the results within the db even if we do have to use a small script to convert 19:48:48 <mguiney> fair. Leaving the task a bit more flexible, in case of problematic dependencies or non configurable tooling, just in case 19:49:01 <catherineD> so instead of spend time on db issue .. we work on the subunit issue first and then decide later when we learn more 19:49:33 <mguiney> makes sense. I will get those changes made and push a new version a bit later today 19:50:23 <catherineD> mguiney: thanks .. 19:50:39 <catherineD> #topic Pending reviews 19:50:54 <catherineD> #link Add python35 support ( https://review.openstack.org/#/c/483999/ ) 19:51:16 <catherineD> luzC: thank you for the patch ... it is merged !!! 19:51:23 <luzC> just merged... thanks for the comments and reviews 19:51:25 <mguiney> \o/ 19:51:38 <catherineD> #link Add UI support for interop schema 2.0 ( https://review.openstack.org/#/c/484625/ ) 19:52:04 <luzC> still on my todo list 19:52:15 <luzC> will try to review later today 19:52:18 <catherineD> pvaneck:'s patch is absolutely needed for schema 2.0 19:52:27 <catherineD> luzC: thanks 19:52:43 <catherineD> #link Update default Tempest version to tag 16.1.0 (July 10, 2017) ( https://review.openstack.org/#/c/491936/ ) 19:53:27 <catherineD> this patch is to update refstack-client default tempest to 16.1.0 19:53:43 <catherineD> please review 19:54:05 <luzC> it is in merge conflict after https://review.openstack.org/#/c/483999/ 19:54:34 <catherineD> luzC: will fix it ... thanks 19:54:49 <catherineD> #topic Open discussion 19:55:03 <catherineD> anything else you want to discuss? 19:57:28 <catherineD> alright ... thank you everyone for your contribution and commitment to the RefStack project ... we have worked hard on it ... and we can see our accomplisement today .. 19:57:59 <catherineD> hogepodge: will host the next RefStack IRC meeting ... 19:58:37 <catherineD> bye now! 19:58:49 <mguiney> have a good week, y'all! 19:58:58 <catherineD> #endmeeting