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