19:00:17 <catherineD> #startmeeting refstack
19:00:17 <openstack> Meeting started Mon Oct  5 19:00:17 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:20 <openstack> The meeting name has been set to 'refstack'
19:00:37 <catherineD> roll call
19:00:48 <pvaneck> o/
19:01:06 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-10-05
19:03:28 <rockyg> 0/
19:03:38 <sslypushenko__> o/
19:03:50 <catherineD> hi everyone ... let's start ..
19:04:08 <catherineD> #topic Infra hosting
19:04:29 <catherineD> #link Infra hosting https://review.openstack.org/#/c/198869/
19:05:03 <catherineD> latest is we need to parameterize db variable to use Trove
19:05:21 <pvaneck> currently working on modifying puppet-refstack to allow mysql_host paramt to be passed in
19:05:26 <pvaneck> i think that should be it
19:05:48 <rockyg> cool
19:05:53 <catherineD> pvaneck: great ... thank you!
19:06:28 <catherineD> it has been a long journey ... we have been working on this since June ....
19:06:51 <catherineD> #topic High priority bugs
19:06:52 <pvaneck> off and on
19:07:13 <catherineD> #link RefStack sign-in sometimes slow ( https://bugs.launchpad.net/refstack/+bug/1499542 )
19:07:13 <openstack> Launchpad bug 1499542 in refstack "RefStack sign in sometimes slow" [High,Confirmed]
19:07:55 <hogepodge> o/
19:08:07 <dwalleck_> o/ (ack, was in wrong room)
19:08:19 <rockyg> :-)
19:08:20 <catherineD> I have tried it serveral time ... it is intermitten ..
19:08:26 <pvaneck> to recreate this bug, just try logging in and out a bunch of times on refstack.net
19:08:36 <davidlenwell> o/
19:08:43 <rockyg> It might be the service, not our app.
19:09:03 <sslypushenko__> I hited this bug several times
19:09:05 <catherineD> hey davidlenwell:
19:09:10 <davidlenwell> hey everyone
19:09:31 * rockyg waves to davidlenwell
19:09:58 <catherineD> according to pvaneck: it happened during verification ....
19:10:05 <pvaneck> everytime is it slow, it always take ~128 seconds to return, which makes me think it is a delay security measure
19:10:21 <rockyg> or a timeout
19:10:27 <pvaneck> yea
19:11:32 <rockyg> but security to avoid DOS also sounds right
19:11:38 <sslypushenko__> openstackid.org is running on PHP, so I'm not wondered)
19:12:02 <pvaneck> however, I can not recreate this on my local refstack server which also uses the official openstackid service
19:12:33 <sslypushenko__> We can talk with infra about it
19:12:43 <catherineD> sslypushenko__: but I do not have that issue when log into OpenStack ..
19:13:03 <rockyg> Yup.  davidlenwell, which company's hosting service do you use, again?
19:13:11 <sslypushenko__> There is some other kind of auth there
19:13:15 <davidlenwell> its on dreamhost compute right now
19:13:21 <davidlenwell> because its free to me
19:13:56 <rockyg> Ah.  So, maybe we need to talk to one of those guys.  reed is one of them, now.
19:14:05 <pvaneck> how necessary is the verification post request to openstackid?
19:14:12 <sslypushenko__> catherineD Openstack.org don't send verify request I think, I can checked it for sure
19:14:19 <rockyg> And, uh, so are you, davidlenwell
19:14:20 <reed> wazzup rockyg?
19:14:23 <rockyg> I forgot.
19:14:41 <catherineD> sslypushenko__: that is why we think we may be over kill with verification?
19:14:45 <rockyg> reed, question about dreamhost and some timeout issues where seeing.
19:14:49 <sslypushenko__> pvaneck I don't know) I found that storyboard is doing same request
19:14:50 <catherineD> sslypushenko__: thx pls check ...
19:15:16 * reed checks #1499542
19:15:17 <sslypushenko__> to launchpad...
19:15:23 <catherineD> sslypushenko__: I think I used to have same experience with long log in time with storyboard ...
19:15:34 <pvaneck> rockyg, don't think it is a timeout, since openstackid does actually return a valid response
19:16:03 <davidlenwell> I don't think it could be an issue with dream compute
19:16:15 <pvaneck> don't think so either
19:16:55 <rockyg> Yeah, that's why reed is reading the bug....
19:17:52 <davidlenwell> well .. since dream compute is running the akanda stack .. and any network related timeout woult fall into that.. I really don't think thats it..
19:18:05 <reed> i have no idea why that happens
19:18:31 <catherineD> so may be we should look into the necessity of the verification step by first checking with infra?
19:18:34 <rockyg> Wondering if it could be some type of protectionf for DOS.  But, it might be on the verification side.
19:18:38 <davidlenwell> I can run some tests locally.. I have a sort of mirror of the dream compute stack here
19:18:46 <reed> i'd pull in the openstack-web project
19:19:00 <sslypushenko__> catherineD Good idea
19:19:08 <catherineD> davidlenwell: it is intermittent ... on and off
19:19:16 <rockyg> Yeah.  The question is really, where in the pipeline the delay really happens.
19:19:33 * davidlenwell will look at the code today
19:19:40 <davidlenwell> could be lots of things
19:19:58 <rockyg> logs on the vm and hosting service should be able to say whether internal or external to dreamhost
19:20:08 <catherineD> thx davidlenwell: for look at the code ...
19:20:33 <sslypushenko__> catherineD Also we can do kind of workaroud... Run verification in background and revoke sign-in if it fails
19:20:36 <reed> davidlenwell, you can also ask fungi for help to look at openstackid
19:20:52 <fungi> yep
19:21:05 <davidlenwell> rockyg: I use vm's on the same cloud for all my personal hosting and this irc bouncer im using right now.. I really don't think its a problem with the hosting company or configs there
19:21:06 <rockyg> great!
19:21:32 <rockyg> so, off to fungi and openstackid logs
19:21:40 <reed> or try and use the dev server, openstackid-dev.openstack.org to isolate
19:21:52 <davidlenwell> reed: good call
19:21:58 <reed> the dev server should have the same code as openstackid or close enough
19:22:01 <fungi> yeah, sync up with me outside the meeting and i can review logs
19:22:41 <pvaneck> sure
19:22:43 <rockyg> best way it probably to get together with fungi, make it happen, then have the time box to look at logs.
19:23:26 <catherineD> #action Check with Infra on the necessity of the verification step
19:24:06 <catherineD> #action Consider debug with openstackid-dev to isolate issues ..
19:24:11 <catherineD> any other actions?
19:24:52 <rockyg> yeah, sync with infra for a test session
19:25:40 <catherineD> the issue here is it does no happen all the time ....
19:26:04 <davidlenwell> I feel like its a browser thing if it isn't consistant
19:26:38 <pvaneck> it is easily recreatable, just takes a few login attempts
19:27:02 * davidlenwell is trying to stand up a test in a vm now..  might ping pvaneck if I get stuck
19:27:09 <pvaneck> and i've verified it gets hung up on the verification post request in the apache logs
19:27:23 <davidlenwell> ahh ..
19:28:25 <catherineD> anything else?  move on to the next topic ..?
19:28:32 <pvaneck> go ahead
19:28:36 <rockyg> pvaneck, could you add the info about the post request to the bug?
19:28:41 <catherineD> #topic     refstack-client fails to run when using an accounts file for Tempest  ( https://bugs.launchpad.net/refstack/+bug/1501903 )
19:28:43 <openstack> Launchpad bug 1501903 in refstack "refstack-client fails to run when using an accounts file for Tempest" [High,Confirmed] - Assigned to Daryl Walleck (dwalleck)
19:29:08 <pvaneck> rockyg, sure. i'll elaborate more
19:29:37 <dwalleck_> I'm working on adding the requested additional tests. I'm trying to avoid adding any new files to do that
19:29:45 <dwalleck_> Or only one at least
19:29:54 <catherineD> dwalleck_:  thx for submit the bug and provide a patch for fix .
19:30:23 <sslypushenko__> dwalleck_ adding fake_accounts.yaml is ok
19:31:01 <dwalleck_> sslypushenko__: Thanks, I was hoping so. That still leaves the empty file case, but I can try to be creative
19:31:34 <dwalleck_> I'll wrap that up this afternoon
19:32:22 <catherineD> I think we are in good hands on this one ...
19:32:27 <catherineD> moving on ..
19:32:38 <catherineD> #topic Check for RSA key existence before accepting uploading data.( https://review.openstack.org/#/c/228565/ )
19:32:59 <catherineD> To me there are 2 aspects to this spec ...
19:33:21 <rockyg> might need to check for both rsa and dsa if no rsa present
19:34:12 <catherineD> The most important aspect for me at this time is .. currently our data is associated to key ... data will be lost if key not uploaded or deleted ...
19:34:46 <sslypushenko__> catherineD data will be unowned, not lost)
19:35:19 <rockyg> so, do you really need the key for anything but upload?
19:35:23 <catherineD> sslypushenko__: once data is unowned we will not be able to access it ....
19:35:40 <sslypushenko__> I was planning to add general_admin role to RefStack with right to see and manage all unowned results.
19:35:42 <catherineD> At the minimum, we should update to associate data to userid ...
19:35:49 <rockyg> always keep email address associated with the dat once uploaded.
19:36:23 <sslypushenko__> catherineD Agreed
19:36:24 <rockyg> even if email address no longer is an approved user.
19:37:03 <catherineD> sslypushenko__: great!  I think that is the first step we should do .... associate data to userid ...
19:37:03 <sslypushenko__> After results become owned, it should marked in DB some how
19:37:07 <rockyg> makes it easier for both general admin and corporate admin
19:38:05 <catherineD> rockyg: from email we will be able to get userid which is guarantee unique in RefStack
19:38:39 <rockyg> yup.  userid works fine, too.  Just don't need to worry about key after upload is successful.
19:38:49 <catherineD> sslypushenko__: agree on once data is associated with user then we can work on authorization parts ...
19:38:50 <rockyg> Don't need to store key, either.
19:39:29 <catherineD> now the next aspect is Verification of key existence ...
19:40:22 <catherineD> we can keep they way we implemented now .... which is only check for key ... this will imply that user to key is 1 to 1 ... and no 2 users can have the same key ..
19:40:53 <sslypushenko__> catherineD agreed
19:41:01 <rockyg> yup
19:42:02 <davidlenwell> +1
19:42:03 <catherineD> or Option 2: we can add one more parameter (email) to refstack-client to check whether the user has the key ... this lift the 1-1 user to key relationship ...
19:42:32 <rockyg> KISS
19:42:48 <catherineD> so option 1: keep what we implement today which is only check for key which has to be unique?
19:43:18 <catherineD> may be easier by voting ...
19:43:20 <davidlenwell> I don't feel like I fully understand option 2
19:43:50 <rockyg> That's why we should keep it simple ;-)
19:43:53 <davidlenwell> so by adding the email option you are allowing a user to do what ?
19:44:06 <davidlenwell> assosiate themselves with more than one key? why is the email needed to do that?
19:45:08 <catherineD> ok so right now when uploading data with signed the only requriement is the user uploads the data with private key ... at the server side we only check whether the key exists in refstack
19:45:16 <catherineD> we do not check who that key belongs to ...
19:45:22 <catherineD> that is option 1
19:45:44 <davidlenwell> why does it matter who it belongs to?
19:45:45 <catherineD> option 2 is refstack-client will require both user email and key ...
19:45:55 <davidlenwell> I don't like option 2.. it doesn't mean anything
19:46:02 <catherineD> refstack server side wiill check whether that key belong to that user
19:46:14 <davidlenwell> a key can be passed on to another user if you get re-assigned or change jobs
19:46:36 <pvaneck> davidlenwell: option 2 just allows multiple users to have the same key since we have the user via the specified email
19:46:57 <davidlenwell> yeah .. but for what purpose ?
19:47:10 <catherineD> to associate data to user
19:47:25 <davidlenwell> so .. multiple users could be assosiated with the same key
19:47:29 <catherineD> so for me key is like password which is used for authentication ...
19:47:31 <davidlenwell> the client doesn't need to verify it
19:47:36 <catherineD> key or password can change ...
19:47:58 <rockyg> davidlenwell, +1
19:48:09 <catherineD> verification is done at the server side not the client side ...
19:48:23 <davidlenwell> thats not what I mean.. verification is not a nescesarry step
19:48:41 <catherineD> which verification?
19:48:58 <rockyg> davidlenwell, right.  You verify by decrypting the file with the public key stored in Openstack
19:49:04 <davidlenwell> verifying tht the user knows the right email address and has the key is pointless
19:49:04 <catherineD> davidlenwell: the only verification is at the server side
19:49:16 <rockyg> If they file can't be decyrpted, it doesn't go in DB.
19:49:18 <davidlenwell> the key on its own is enough
19:49:32 <catherineD> davidlenwell: that is not what we verify ...
19:49:34 <davidlenwell> I know all of your email addresses
19:49:57 <davidlenwell> just trying to understand what this gains for us
19:50:07 <rockyg> me too
19:50:37 <davidlenwell> I think what it does now is good enough and actually simple and elegant
19:50:40 <rockyg> are we using the key for decrypting the uploaded files?
19:50:55 <davidlenwell> I don't think so
19:51:04 <davidlenwell> its just signing the submission
19:51:11 <catherineD> from security point of view we are all set with key ...
19:51:11 <davidlenwell> so that it can be considered valid
19:51:16 <davidlenwell> okay ..
19:51:34 <catherineD> the issue here is once the data lands in refstack server ... who own it?
19:51:40 <rockyg> That would be the right way to do it.  Not valid if not decryt]ptable
19:51:41 <pvaneck> right now, we want the key to be used as a mechanism for associating test results with a user
19:51:46 <davidlenwell> so it sounds like maybe you are trying to make the system smart enough to accept submission from anyone with the key.. but to also id who used the key by email address
19:52:08 <rockyg> The server owns it, but the userID that goes with the upload is associated with it.
19:52:33 <catherineD> today's implementation ... we accept submission from anyone with the key ...
19:52:46 <davidlenwell> what I am looking for a clearer understanding of the use case this addresses
19:52:58 <davidlenwell> trying to back it up for a second
19:53:09 <davidlenwell> not trying to be difficult.. I know I've been checked out for a little bit..
19:53:13 <rockyg> everybody should have their own keys, shouldn't they?  Especially if private
19:53:25 <rockyg> davidlenwell, me too on this one
19:54:01 <davidlenwell> because it seems to me that we have other use cases that we can spend cycles solving
19:54:04 <catherineD> davidlenwell: yup ...  this is a very important topic ... so let's take a much time to discuss so everyone understand what we are trying to sovle
19:54:23 <davidlenwell> okay
19:54:41 <rockyg> I think the server should work the same way review.openstack.org works.
19:54:45 <davidlenwell> we can chat offline
19:55:03 <catherineD> ok let's chat offline ...
19:55:06 <rockyg> File get encrypted with user's private key and decrypted by o.o
19:55:17 <davidlenwell> rocky.. that isn't how it works
19:55:33 <rockyg> I just figured that out.  That'
19:55:36 <davidlenwell> signing and enqryption are different
19:55:45 <rockyg> s what I had thought the keys were for. :(
19:56:03 <catherineD> #action RefStack team to discuss Verification of key existence in RefStack IRC
19:56:17 <catherineD> 4 minutes left ...
19:56:19 <rockyg> OH, well.  Other online discussion in Refstack
19:56:29 <catherineD> #topic Open discussion
19:56:36 <davidlenwell> how many of you will be at the sumimt?
19:56:46 <catherineD> +1
19:56:47 <dwalleck_> o/
19:57:12 <rockyg> o/
19:57:17 <pvaneck> o/
19:57:18 <davidlenwell> look forward to seeing you all again
19:57:25 <rockyg> :-)
19:57:47 <catherineD> yup ... I will create a agenda for the RefStack sessions ... we have 2 slots
19:58:33 <catherineD> anything else?
19:58:38 <hogepodge> o/
19:59:11 <catherineD> if not we can end this meeting and continue our discussion in RefStack IRC about the key and user topic ...
19:59:36 <catherineD> #endmeeting