19:00:21 <catherineD> #startmeeting refstack 19:00:22 <openstack> Meeting started Mon Oct 12 19:00:21 2015 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:26 <openstack> The meeting name has been set to 'refstack' 19:01:07 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-10-12 19:02:07 <pvaneck> o/ 19:02:08 <dwalleck> o/ 19:02:35 <catherineD> dwalleck: pvaneck: hi 19:02:52 <pvaneck> hello 19:02:59 <dwalleck> howdy 19:04:23 <dwalleck> I'm in two meeting at once but I'm listening :) 19:04:27 <catherineD> #topic Tokyo summit agenda. Please add topics that you think we should discuss. https://etherpad.openstack.org/p/refstack-tokyo-summit 19:04:36 <catherineD> dwalleck: thx ... 19:05:23 <catherineD> #link Tokyo summit agenda. Please add topics that you think we should discuss. https://etherpad.openstack.org/p/refstack-tokyo-summit 19:05:33 <pvaneck> that seems like a good enough agenda 19:05:42 <catherineD> so the RefStack session will be on Thursday ... 19:05:48 <dwalleck> Yeah, that's quite a bit 19:05:59 <catherineD> pls mark your schedule 19:06:50 <catherineD> for me the main goal for the face-to-face is to agree on data models and vendor registration process... 19:07:08 <Rockyg> o/ 19:07:14 <dwalleck> I noticed that Tempest has changed the way they install and run a bit. Are we planning on changing the client to adopt that? I didn't see that on the agend 19:07:28 <catherineD> dwalleck: yes we are ... 19:07:41 <catherineD> we should add that to the agenda 19:08:09 <Rockyg> should we try for a cross project meeting with qa? 19:08:18 <sslypushenko__> o/ 19:08:58 <catherineD> Rockyg: sslypushenko__: https://etherpad.openstack.org/p/refstack-meeting-15-10-12 19:09:09 <sslypushenko__> thx 19:09:40 <catherineD> Rockyg: for cross project meeting with qa ... we need to add our topisc to their agenda right? 19:10:13 <Rockyg> yes. Or try to arrange one at the summit 19:10:51 <catherineD> dwalleck: do you know when will sq deprecate the current method of installation and run? 19:11:27 <catherineD> that will help us set our priority .. 19:11:52 <dwalleck> catherineD: No, I didn't see anything about that. I don't think the new workflow would be too difficult to work in 19:12:14 <dwalleck> I think they just marked the current workflow as deprecated 19:12:26 <dwalleck> err, old workflow 19:13:28 <catherineD> dwalleck: then using new QA installation should be high priorityb for the next cycle 19:14:20 <sslypushenko__> catherineD we can wait while it become stable and move to it 19:14:40 <catherineD> I add the QA topic to our summit agenda ... 19:15:06 <catherineD> sslypushenko__: make sense ... I just add it to our summit agenda so we do not over look it 19:16:28 <catherineD> everyone .. please review the summit agenda .. feel free to edit ... the priority list in there will bethe items that RefStack will execute in the next cycle .. 19:16:56 <dwalleck> will do 19:17:17 <catherineD> anything esle? should we moving to our next exciting topic ... 19:17:39 <catherineD> #topic Infra hosting 19:17:54 <catherineD> pvaneck: could you give an update ... 19:18:10 <pvaneck> sure 19:18:36 <pvaneck> we finally have https://refstack.openstack.org up 19:18:47 <catherineD> yay!!! 19:19:02 <dwalleck> woo 19:19:06 <pvaneck> however there seems to be some issues with authentication sessions that i would like to work out before moving to it 19:19:23 <catherineD> RefStack team should try to access it ... 19:20:04 <catherineD> Rockyg: your test while review david's spec is on refstack.net right? 19:20:06 <pvaneck> one way to recreate the issues with the sessions is to log in and refresh repeatedly, sometimes refstack api will return that you are not logged in 19:20:17 <sslypushenko__> Coool! 19:20:38 <catherineD> pvaneck: all 3 broswers? 19:20:44 <pvaneck> not a browser issue 19:20:54 <Rockyg> Nope. The link you provided. 19:20:55 <catherineD> browsers// 19:21:06 <pvaneck> but have verified with chrome and firefox 19:21:13 <catherineD> refstack.openstack.org Rockyg: ? 19:21:21 <Rockyg> Yup 19:21:34 <catherineD> ok 19:22:13 <Rockyg> Yeah. I used Chrome because FF is wonky on the corporate net. All sorts of certificate issues. 19:22:49 <catherineD> so while we are debugging the authentication issue ... Let's go ahead and work on the migration plan ... 19:22:53 <pvaneck> i think it may have to do with our beaker sessions being stored in memory 19:23:19 <Rockyg> Try going backward and forward between pages, too. 19:23:43 <Rockyg> pvaneck, ^^ 19:24:16 <pvaneck> going between pages is fine for me 19:24:25 <sslypushenko__> me too 19:24:30 <pvaneck> just upon app reload with a refresh where we check if the user is authenticated 19:24:43 <pvaneck> sometimes the api returns that we arent logged in 19:25:33 <pvaneck> beaker documentation suggests not using memory backend in production 19:25:33 <catherineD> pvaneck: that does not happen in refstack.net? 19:25:50 <sslypushenko__> pvaneck You are right 19:25:51 <pvaneck> nope, not sure what is different on the infra-vm 19:26:28 <pvaneck> so im thinking maybe try file or database backend 19:26:34 <sslypushenko__> I think we should move on something like memcashe 19:27:06 <sslypushenko__> *memcached 19:27:11 <catherineD> sslypushenko__: that would take some time to implement? 19:27:21 <Rockyg> I'm a magnet for brokeness. Especially intermittents. If you want to schedule a session with me, infra and you to run through some scenarios while you guys analyze, I can do that. 19:27:47 <sslypushenko__> it supported backend for beaker 19:28:39 <pvaneck> memcached, I think, would require a change to puppet-refstack to get memcached installed 19:29:36 <pvaneck> database or file would just be a few lines addition to our beaker conf in app.py 19:30:15 <catherineD> would ths be a must fix for us to migrate from refstack.net to refstack.openstack.org? 19:30:57 <pvaneck> i believe so, or people might try logging in and they wil get auth failed becauses of a csrf token mismatch 19:31:40 <sslypushenko__> Database is not scalable solution, i think 19:32:27 <sslypushenko__> But for quick fix, it is ok 19:32:51 <pvaneck> memcached would be good for future use, but if we want to quickly get the new site stable, i think database is easiest backend to use for now 19:34:00 <sslypushenko__> If we have no time, lets use database 19:34:03 <pvaneck> then when the site is stable, we can make the switch to memcached which might take a bit more time to get the needed changes merged 19:34:13 <catherineD> agree 19:34:32 <pvaneck> and i also want to see if switching from memory even resolves the issue 19:34:38 <pvaneck> which i hope it does 19:36:13 <catherineD> #agreed To use database for a quick fix for https://bugs.launchpad.net/refstack/+bug/1504674 . Need to revisit with memcached in the future. 19:36:13 <openstack> Launchpad bug 1504674 in refstack "Refreshing on restricted pages can sometimes redirect you home" [Undecided,New] 19:36:19 <pvaneck> so i will submit a patch for db beaker backend. It should automaticaly be picked up the VM when merged 19:36:39 <catherineD> great ... thx 19:37:03 <catherineD> could everyone look at the migration plan in today's agenda 19:37:51 <catherineD> let's look at the next item .. 19:38:07 <catherineD> #info refstack.net data cleanup before migration? Or should we just mirgrate everything and put a time limit to remove data? 19:38:33 <pvaneck> can you elaborate on time limit to remove data 19:38:39 <catherineD> we have not migrated any data over ... do we want to clean up data before migration ? 19:39:24 <sslypushenko__> Removing zero pass data looks reasonable for me 19:39:35 <catherineD> I am thinking of 3 months .... 19:40:22 <Rockyg> I know we have real data in there, so we should either migrate, or resubmit if we have the original files that got parsed. 19:40:53 <pvaneck> can remove the test results with no passed tests and move over the rest 19:40:58 <pvaneck> i think that is fine 19:41:04 <sslypushenko__> +1 19:41:51 <sslypushenko__> Also, maybe we can remove duplications 19:42:10 <catherineD> there are 13 record with no test data at all... I feel like someone is using refstack in their CI test with automate upload 19:42:23 <catherineD> sslypushenko__: that bring me to that topic ... 19:42:35 <catherineD> but before we discuss that 19:42:41 <catherineD> let me log our agreement 19:43:03 <sslypushenko__> I know, I have submitted some dummy test results by mistake) 19:43:10 <catherineD> #agreed Data should be cleaned before moving from refstack.net to refstack.openstack.org 19:43:40 <catherineD> #agreed Clean up zero pass test data record 19:43:57 <sslypushenko__> I vote for removing zero data and total duplications 19:44:11 <catherineD> sslypushenko__: on duplicate data ... I am still do no know the criteria for duplications ... 19:44:29 <sslypushenko__> same test results + same cpid 19:44:31 <catherineD> we talk about data are in the server side 19:44:57 <catherineD> but take the case of pass tests ... they will have same test results ... 19:45:31 <catherineD> sslypushenko__: they can test with different config 19:46:08 <catherineD> and also once we identify the test runs ... do we keep the last run? 19:46:44 <sslypushenko__> Anyway, I don't think that such results have value for owners 19:46:47 <catherineD> so I am not really clear on the criteria we should use .. 19:47:43 <sslypushenko__> My suggestion is: if some test runs have the same test results + same cpid, we should keep only last one 19:47:45 <catherineD> sslypushenko__: I agree with you there ... but I just don't know what criteria to use 19:48:35 <pvaneck> i thought the criteria is same cpid + test results? 19:49:39 <catherineD> take the case where some one is running tests with senario one 1) test with isolation on 2) isolation off ... they may have the smae cpid and test results ... 19:49:57 <catherineD> they may want to tag those information later ... 19:50:02 <catherineD> and we wnat that too .. 19:50:09 <catherineD> time check ... 19:50:14 <catherineD> we only have 10 mins 19:50:37 <catherineD> could we discuss the duplicate data next time ... let's go the next items? 19:50:39 <pvaneck> then don't worry about it and let the user manage it 19:50:52 <pvaneck> sure go to next item 19:51:00 <catherineD> #info Disable anonymous data upload 19:51:02 <Rockyg> ++ 19:51:14 <catherineD> do we want to have that implement before the move? 19:51:39 <pvaneck> that would just delay the move even more 19:52:19 <catherineD> Rockyg: sslypushenko__: dwalleck: your thoughts? 19:52:20 <pvaneck> puppet will pick up the changes so no need to wait 19:52:46 <dwalleck> sorry, bouncing around. reading back for context 19:53:18 <sslypushenko__> I think we should disable anonymous data upload before move 19:53:18 <dwalleck> I'd like to keep as much history as possible 19:53:19 <Rockyg> Would be good to have it before the summit. 19:53:50 <dwalleck> sslypushenko__: That would be a good logical time to make that switchover 19:53:50 <Rockyg> Also, maybe we should have a sandbox for folks to use? Then we could purge if it grows too large. 19:53:52 <catherineD> Rockyg: that is my target to move to refstack.openstack.org before summit ... 19:54:21 <dwalleck> Rockyg: ++. That would be a good idea. Let people still have somewhere to try things out 19:55:08 <sslypushenko__> New site will be good sandbox, I think 19:56:00 <sslypushenko__> If user uploads only signed data, it isolated pretty good 19:56:48 <dwalleck> But if the new site is the official one, wouldn't we not want to treat it like a sandbox? Wouldn't that be the "real" data? 19:56:59 <catherineD> sslypushenko__: I think so ... but my concern is it will delay the move 19:57:39 <Rockyg> dwalleck, ++ 19:58:36 <catherineD> dwalleck: yes the official site should have more "real" data publish to community vs a lot of unsuable data now ... 19:59:04 <catherineD> I think we need to end this meeting soon ... could we discuss in #refstack? 19:59:51 <catherineD> #endmeeting