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