19:00:33 <catherineD> #startmeeting refstack 19:00:34 <openstack> Meeting started Mon Sep 21 19:00:33 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:37 <openstack> The meeting name has been set to 'refstack' 19:00:44 <hogepodge> o/ 19:00:45 <Rockyg> o/ 19:00:46 <catherineD> roll call 19:01:08 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-09-21 19:01:10 <pvaneck> o/ 19:01:30 <catherineD> hi hogepodge: Rockyg: pvaneck: .. 19:01:57 <dwalleck> o/ 19:03:00 <catherineD> #topic Welcome Rackspace team to join RefStack 19:03:03 <Rockyg> hey! 19:03:12 <dwalleck> woo! 19:03:12 <catherineD> dwalleck: Welcome 19:03:26 <dwalleck> Thanks for having us :) 19:04:06 <catherineD> We are glad to have you joinning us ... 19:04:24 <catherineD> #topic Infra hosting 19:04:51 <catherineD> pvaneck: pls update ... 19:05:08 <Rockyg> hey, it's really important we have a PCP working on this. It helps us get it right. 19:05:31 <pvaneck> right 19:05:40 <pvaneck> so the patch in question is https://review.openstack.org/#/c/198869/ 19:06:05 <pvaneck> i just submitted an update on that patch which will hopefully be all we need 19:06:36 <catherineD> Rockyg: PCP? 19:06:52 <Rockyg> ?? 19:07:09 <Rockyg> Oh. Public cloud provider 19:07:20 <catherineD> Rockyg: ha.. 19:07:55 <catherineD> Rockyg: ++ 19:08:06 <pvaneck> in any case, just waiting to see if it passes jenkins 19:08:30 <catherineD> pvaneck: thanks for the update .... Let see how it goes from here ... 19:09:04 <catherineD> #topic CPID (Cloud Provider ID) 19:09:27 <catherineD> #info Admin credential is no longr required to fetch CPID for RefStack !!! 19:10:47 <catherineD> I am able to run RefStack now with no admin credential specified ... 19:11:21 <catherineD> #topic Enable RefStack for Non-tempest test 19:12:53 <catherineD> I believe for this, we will leverage Tempest plug-in to bringin in-tree tests ... RefStack will not develop own plugin .... 19:13:23 <dwalleck> As long as the tempest plugin system is flexible enough, it shouldn't be a problem 19:13:36 <sslypushenko__> o/ Hi, all! 19:13:49 <catherineD> hi sslypushenko__: ... 19:13:53 <pvaneck> hey sergey 19:15:01 <catherineD> dwalleck: right ... so we may need to participate in Tempest plugin development if we find out that it is not flexible for RefStack ... 19:16:01 <sslypushenko__> catherineD It is already functional enough 19:16:03 <catherineD> Rockyg: with that I am not sure how we would be able to bring in the EC2 test ... It just meant that the EC2 needs to be able to operate with Tempest plugin 19:16:24 <dwalleck> I'm going to start catching up on whatever work has been done so far for the Tempest plugin system. I'm interested to see what the actual implementation is 19:16:40 <sslypushenko__> Basically, it is just discovery for non-tempest test + config injection 19:17:34 <Rockyg> catherineD, Right. The EC2 folks will need to get work with the plugin 19:17:46 <sslypushenko__> dwalleck You can look here https://review.openstack.org/#/c/214571/ 19:18:21 <sslypushenko__> It is reaaly simple if you experienced in python packaging 19:18:40 <dwalleck> sslypushenko__: Thanks, will do 19:19:17 <catherineD> sslypushenko__: so config is automated with no user intertions? we all know that config is a big deal when testsing with Tempest 19:19:48 <sslypushenko__> Also, mtreinish is on top tempest plugins from tempest side 19:20:06 <sslypushenko__> catherineD Heh) No) 19:20:41 <sslypushenko__> But plugins allow to store config fot non-tempest tests in tempest.conf) 19:21:14 <sslypushenko__> So tempest.conf becomes a bigger deal 19:21:31 <catherineD> sslypushenko__: interesting ... 19:22:15 <sslypushenko__> To make it possible, in-tree tests should support configuration through oslo-config 19:22:47 <catherineD> dwalleck: you join us in time for this very important milestone for RefStack ... 19:23:02 <Rockyg> We should add that bit of info to our docs 19:23:11 <Rockyg> the use of oslo-config 19:23:53 <catherineD> Rockyg: +1 19:23:55 <dwalleck> Yeah, if folks standardize on oslo-config, it should make the process more straightforward I'd think 19:25:48 <catherineD> I will keep non-tempest testing in the weekly agenda so we can discuss more ... meanwhile, let's give dwalleck: sometime to understand more on Tempest plugin 19:26:04 <catherineD> ready for the next topic? 19:26:12 <dwalleck> sounds good 19:26:17 <sslypushenko__> ec2-api project uses oslo-config, so it should be a problem 19:26:32 <sslypushenko__> go next 19:26:45 <catherineD> #topic Brainstorm on data models among vendor, user, key and result data 19:27:26 <catherineD> I feel like this is a topic that is best to be discussed with f-2-f ... but we can trial ... 19:27:45 <sslypushenko__> +1 for f-2-f 19:28:08 <dwalleck> sslypushenko__: ++ 19:28:10 <sslypushenko__> we will just waste a time now 19:28:16 <Rockyg> ++ f2f 19:28:32 <catherineD> so should I schedule a f2f before summit? 19:28:56 <pvaneck> or save it for summit design sessions 19:29:02 <catherineD> sslypushenko__: is not attending summit ... 19:29:16 <catherineD> how about dwalleck: ? will you be attending the summit? 19:29:27 <dwalleck> catherineD: Sam and I will be there 19:29:35 <catherineD> dwalleck: that is great .... 19:29:39 <sslypushenko__> We can do fist try this or maybe next week 19:29:50 <catherineD> sslypushenko__: +1 19:30:16 <catherineD> we have 1/2 hour left for today ... 19:30:43 <catherineD> even that we are not efficient ... I think at least we can raise the areas of concern ... 19:31:55 <catherineD> so final Data model discuss should be at the summit but we can start preping for it now .... at the summit we just finalize the agreement ... 19:31:59 <sslypushenko__> I think it should be a really big problem, maybe 1-hour talk will be enough 19:32:13 <sslypushenko__> catherineD +1 19:33:14 <catherineD> Here is what we will do ... discuss now for 1/2 hour ... I will schedule a one hour call next week ... and more if needed ... finalize design decision at the summit .. 19:33:21 <catherineD> sound alright to everyone? 19:33:43 <dwalleck> Sure 19:33:45 <pvaneck> sure. what are the current areas of concern 19:33:51 <catherineD> sslypushenko__: and this time It will be hangout call :-) 19:33:59 <sslypushenko__> If we don't have anything else for discussion for today 19:34:43 <catherineD> on the agenda ... this brainstorm and open discussion ... 19:35:03 <sslypushenko__> ok... lets go) 19:35:12 <catherineD> do any one have any open discussion that we should do before we dive into the data model discussion? 19:35:18 <catherineD> ok ... 19:36:05 <catherineD> the #1 concern I have now is .. with anonymois data uploading .. junk data are being send to refstack.net ... and we can not clean up that data ... 19:36:55 <catherineD> #link Empty test data uploaded to refstack.net https://bugs.launchpad.net/refstack/+bug/1498112 19:36:56 <openstack> Launchpad bug 1498112 in refstack "RefStack should check for empty test results " [Undecided,New] 19:37:06 <sslypushenko__> And that is why it should be prohibited 19:37:22 <dwalleck> Is a primary concern to still allow the uploading of anonymous data? 19:37:24 <catherineD> sslypushenko__: +1 19:38:27 <catherineD> dwalleck: the primary concern is malicious attack to refstack.net (so far it is not) if we keep allowing anonymous data updalod .... 19:39:05 <dwalleck> Or I guess the question is, would it give some people hesitation to upload their results if they had to be registered? 19:39:09 <hogepodge> catherineD: can rate-limiting stop that? 19:39:20 <hogepodge> dwalleck: I think it could be a barrier 19:39:41 <catherineD> but there is contradicted interests that with anaonymous data upload we could enable more participation to upload data ... 19:39:48 <dwalleck> Hmm, I see. Maybe a policy of keeping the last x days or numbers of anonymous results and a background process to keep things tidy? 19:40:59 <hogepodge> some vendors have reported test results with refstack, so those uploads need to stick around 19:41:00 <catherineD> dwalleck: actually the more data we have the better it is for statistical analysis ... 19:41:14 <hogepodge> I could provide a list of which ones 19:41:16 <pvaneck> we need an administrative panel so at least admin users can perform cleanup. I believe this has been brought up before. 19:41:45 <catherineD> hogepodge: +1 that is why once the data is uploaded anonymously we have no ways to know which data shoudl be removed ... 19:42:13 <catherineD> hogepodge: I am thinking if we have the data model clean up ... 19:42:31 <sslypushenko__> hogepodge These vendors can upload signed data 19:42:45 <catherineD> user shoud upload data with authorization ... they still can decide which data to share to the communicty 19:43:15 <sslypushenko__> Signing results don't require to have an account 19:43:22 <dwalleck> catherineD: That's a very reasonable point 19:43:31 <hogepodge> sslypushenko__: we've tracked those results through their ids. if we want them to reupload refstack-client needs an offline option where previously run results can be sent again 19:43:46 <hogepodge> sslypushenko__: which is a needed feature anyway 19:43:49 <catherineD> The concern with signed data right now is it is tight to the key ... we need to resolve key to user to vendor relationship 19:44:27 <sslypushenko__> hogepodge agreed 19:44:38 <Rockyg> ++ 19:44:39 <catherineD> hogepodge: being able to upload earlier data could be something that we can provide 19:45:18 <sslypushenko__> catherineD Why not? 19:46:26 <catherineD> sslypushenko__: I agee that refstack-client can provide option to upload previous data ... is the the question? 19:46:34 <sslypushenko__> I agreed with hogepodge that anonymous results can be reuploaded with signature 19:46:54 <catherineD> sslypushenko__: I also agree ... 19:47:25 <catherineD> does that mean that disable anonymous upload would be something that we can consider? 19:48:05 <Rockyg> Please? 19:48:40 <dwalleck> If anyone could register, then I don't see a need for anonymous upload 19:49:04 <catherineD> does everyone agree that RefStack should disable anonymous upload? 19:49:41 <pvaneck> so you want every results set to be tied to an openstackid account going forward? 19:49:44 <Rockyg> Vote 19:49:55 <Rockyg> and +1 19:50:47 <sslypushenko__> catherineD +1 19:51:08 <catherineD> #startvore RefStack to disable anonymous data upload? yes, no 19:51:35 <catherineD> #startvote Refstack to disable anonymous data upload? yes, no 19:51:36 <openstack> Begin voting on: Refstack to disable anonymous data upload? Valid vote options are yes, no. 19:51:37 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 19:51:48 <catherineD> #vote yes 19:51:51 <dwalleck> #vote yes 19:52:00 <Rockyg> #vote yes 19:52:30 <pvaneck> #vote yes 19:52:54 <catherineD> hogepodge: sslypushenko__: pls vote 19:53:15 <sslypushenko__> #vote yes 19:54:47 <pvaneck> majority yes in any case 19:54:59 <catherineD> #endvote 19:55:00 <openstack> Voted on "Refstack to disable anonymous data upload?" Results are 19:55:01 <openstack> yes (5): Rockyg, catherineD, sslypushenko__, pvaneck, dwalleck 19:55:33 <catherineD> #agreed RefStack to work on plane to disable anonymous data upload 19:56:15 <catherineD> thank you everyone! I think we could protect our site better this way ... 19:56:44 <Rockyg> agreed 19:56:46 <pvaneck> so for implementation, all results uploaded need to be passed in with a private key, with the corresponding public key already on the refstack server 19:56:51 <catherineD> a few more things we need to consider before disable the anonymous upload ... that is why we need a plan 19:57:08 <catherineD> perhaps we need an one hour call after all ... 19:57:22 <catherineD> pls tell me on #refstack the best time for you .... 19:57:58 <catherineD> pvaneck: yea we need to carefully design and plan the implementation 19:58:15 <catherineD> let me end this meeting ... thank you all!!!! 19:58:24 <catherineD> #endmeeting