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