| *** markvoelker has quit IRC | 00:01 | |
| *** markvoelker has joined #refstack | 00:02 | |
| *** markvoelker has quit IRC | 00:02 | |
| *** markvoelker has joined #refstack | 00:02 | |
| *** edmondsw has quit IRC | 00:19 | |
| *** pvaneck has quit IRC | 01:12 | |
| *** openstack has joined #refstack | 01:25 | |
| *** dwalleck has quit IRC | 02:20 | |
| *** dwalleck has joined #refstack | 03:48 | |
| *** dwalleck has quit IRC | 03:53 | |
| *** dwalleck has joined #refstack | 04:03 | |
| *** markvoelker has quit IRC | 04:31 | |
| *** markvoelker has joined #refstack | 05:32 | |
| *** markvoelker has quit IRC | 05:37 | |
| *** markvoelker has joined #refstack | 06:33 | |
| *** markvoelker has quit IRC | 06:37 | |
| *** markvoelker has joined #refstack | 07:34 | |
| *** markvoelker has quit IRC | 07:38 | |
| *** dwalleck has quit IRC | 07:45 | |
| *** dwalleck has joined #refstack | 07:49 | |
| *** dwalleck has quit IRC | 08:01 | |
| *** markvoelker has joined #refstack | 08:34 | |
| *** markvoelker has quit IRC | 08:38 | |
| *** nijaba has quit IRC | 09:06 | |
| *** nijaba has joined #refstack | 09:07 | |
| *** nijaba has quit IRC | 09:07 | |
| *** nijaba has joined #refstack | 09:07 | |
| *** markvoelker has joined #refstack | 10:36 | |
| *** markvoelker has quit IRC | 10:40 | |
| *** andrey-mp4 has joined #refstack | 11:29 | |
| *** andrey-mp4 is now known as andrey-mp | 11:30 | |
| *** markvoelker has joined #refstack | 11:37 | |
| *** andrey-mp has quit IRC | 11:37 | |
| *** markvoelker has quit IRC | 11:41 | |
| *** andrey-mp has joined #refstack | 11:44 | |
| *** markvoelker has joined #refstack | 12:08 | |
| *** edmondsw has joined #refstack | 12:48 | |
| *** cjvolzka has joined #refstack | 12:58 | |
| *** designbybeck has joined #refstack | 13:16 | |
| *** pilgrimstack1 has joined #refstack | 15:02 | |
| *** pilgrimstack has quit IRC | 15:02 | |
| *** Rockyg has joined #refstack | 15:58 | |
| *** pilgrimstack has joined #refstack | 16:32 | |
| *** pilgrimstack1 has quit IRC | 16:33 | |
| *** andrey-mp has quit IRC | 16:35 | |
| *** krotscheck is now known as krotscheck_vaca | 17:01 | |
| *** krotscheck_vaca is now known as krot_vaca_jul19 | 17:01 | |
| *** pilgrimstack has quit IRC | 17:11 | |
| *** pvaneck has joined #refstack | 17:21 | |
| *** andrey-mp has joined #refstack | 17:51 | |
| *** alevine_ has joined #refstack | 17:54 | |
| *** pilgrimstack has joined #refstack | 17:57 | |
| catherineD | hi everyone, please let me know if you are here for the RefStack Test Results Ownership Discussion | 18:04 |
|---|---|---|
| markvoelker | o/ | 18:05 |
| alevine_ | catherineD: I'm half here - I have a call with CloudFoundry right this moment | 18:05 |
| pvaneck | o/ | 18:05 |
| sslypushenko | o/ | 18:05 |
| catherineD | alevine_: thx | 18:05 |
| catherineD | thank you all for your time ... I really appreciate it | 18:06 |
| hogepodge | o/ | 18:07 |
| catherineD | I add the discussion topics to the bottom of https://etherpad.openstack.org/p/refstack-meeting-16-06-28 | 18:07 |
| andrey-mp | o/ | 18:08 |
| catherineD | do you have a chance to revoew https://blueprints.launchpad.net/refstack/+spec/test-results-ownership ? | 18:08 |
| catherineD | any question before we proceed to discuss the first topic? | 18:09 |
| alevine_ | catherineD: I believe from my side I posted enough concerns in your review :) | 18:09 |
| andrey-mp | yeah | 18:09 |
| alevine_ | catherineD: So I just don't understand this blueprint at all at the moment. I mean what leads to it. | 18:10 |
| andrey-mp | 'It is now possible to associate test results to vendor products or RefStack site owner' - is it? | 18:10 |
| catherineD | alevine_: thank you for your review ...I would like to hear from others .. | 18:10 |
| hogepodge | alevine_: did you mean to make comments against the first draft of that spec? | 18:10 |
| alevine_ | hogepodge: I don't quite understand your question. I mean this review: https://review.openstack.org/#/c/332260/1/specs/newton/approved/associate-test-result-to-product.rst | 18:11 |
| catherineD | hogepodge: I think before we go to the specific implementation (which is the review) .. from alevine_: feedback ... we need some fundation direction | 18:11 |
| hogepodge | alevine_: that's the one I'm taking about. All of your comments are against revision 1, not 4 | 18:12 |
| alevine_ | hogepodge: My bad then. | 18:12 |
| alevine_ | hogepodge: I just kept answering Catherine's answers :) | 18:12 |
| alevine_ | hogepodge: I'll take a look. | 18:12 |
| catherineD | hogepodge: yea on version 1 .. version 4 is just to add blueprint URL etc.. | 18:13 |
| catherineD | before we dive into the details ... I would like us to discuss | 18:13 |
| alevine_ | hogepodge: Took a look. Don't see much diff | 18:14 |
| catherineD | #topic 1: Is there a need for data ownership transfer from users to vendor (via product) or OpenStack Foundation ? | 18:14 |
| Rockyg | o/ | 18:14 |
| catherineD | Rockyg: see the agenda at the bottom of https://etherpad.openstack.org/p/refstack-meeting-16-06-28 | 18:14 |
| hogepodge | I'm using refstack as a data repository, but if results can be deleted, that breaks the use case for me. | 18:15 |
| catherineD | from alevine_: 's comments I believe alevine_: is questioning whether there is a need to transfer ownership of data from the creator to vendor? | 18:15 |
| hogepodge | I'm going to start archiving them privately at the Foundation for reference, along with additional data. | 18:16 |
| alevine_ | catherineD: I'm not questioning it. There might be such a necessity. I just don't see where it comes from. | 18:16 |
| hogepodge | If I can't trust something to be there I have to keep a canonical copy | 18:16 |
| catherineD | hogepodge: adding the cerfification flag will help that since it transfer the data ownership to the foundation | 18:16 |
| hogepodge | ok | 18:17 |
| Rockyg | ++ | 18:17 |
| catherineD | that is the use case to transfer data ownership from data creator to foundation in the blueprint .. the spec just describes implementation details | 18:18 |
| sslypushenko | my opinion on #topic 1 - Ownership of public associated test result should transferred to Foundation if it is used for certification | 18:18 |
| pvaneck | this 'certification' field is essentially just used as a 'can_delete' field? | 18:18 |
| alevine_ | catherineD: This is not a high-level business use-case, right? | 18:18 |
| hogepodge | alevine_: this is a fundamental use case for the mission of refstack | 18:19 |
| sslypushenko | hogepodge: +1 | 18:19 |
| alevine_ | hogepodge: I'm sorry I might've missed something. Transferring ownership? | 18:19 |
| hogepodge | if I can't rely on the results being there permanently then I can't use refstack for defcore, which is what the mission statement for the project is | 18:19 |
| catherineD | pvaneck: yes and no because foundation can delete it | 18:19 |
| alevine_ | hogepodge: Or you meant certification use-case? | 18:19 |
| alevine_ | hogepodge: So the actual business use-case is to ensure data availability for infinite timeframe? | 18:20 |
| hogepodge | The implementation detail is that if a vendor wants to use a result for certification, they no longer own that data. It becomes a community resource managed by the OSF. | 18:21 |
| catherineD | alevine_: no data owned by foundation and foundation can decide whther it should be infinite or not | 18:21 |
| hogepodge | It's a voluntary part of the trademark program. | 18:21 |
| catherineD | hogepodge: ++ | 18:21 |
| alevine_ | hogepodge: Ok. Have you had a chance to see my questions in the spec? | 18:22 |
| hogepodge | I can see other business cases being changing ownership if employees change employers, but I don't know enough about the server implementation details to say much more about that. | 18:22 |
| sslypushenko | Folks! I guess we have just a kind of misunderstanding here. I hope, it is obvious of everyone, that test runs are used for certification can be only owned by OSF | 18:23 |
| alevine_ | hogepodge: I understand the direction but I don't understand lots of answers and without them I don't see connection between certification, storing results and ownership transfer. Maybe I'm just too dumb, sorry. | 18:23 |
| catherineD | sslypushenko: ++ | 18:23 |
| Rockyg | Another case could be a test group in one product line runs tests that get into Refstack, but they are not "official" unless the productline the test is run against approves and tells admin to take ownership | 18:24 |
| sslypushenko | alevine_: certification requires ownership transfer mechanism. At least form anyone to OSF | 18:24 |
| alevine_ | sslypushenko: There are still remaining questions which I don't understand even in this "obvious" fact. | 18:24 |
| alevine_ | sslypushenko: What is certification process applied to RefStack? It's not defined anywhere. | 18:25 |
| hogepodge | alevine_: can you please use language that is less inflammatory? Saying things like "Maybe I'm just too dumb, sorry" isn't a way to foster productive conversation. | 18:25 |
| alevine_ | sslypushenko: Have you had a chance to read my questions? | 18:25 |
| sslypushenko | yeap | 18:25 |
| alevine_ | hogepodge: Sorry. My fault. I'll try. | 18:25 |
| hogepodge | alevine_: to answer your question, the way things work now is a vendor sends me a link to a refstack result, I check the site to see if they pass the guideline they're requesting, then make changes to my internal database and update their marketplace listing | 18:26 |
| hogepodge | alevine_: there's also a contract we send to them that they need to sign. | 18:26 |
| hogepodge | alevine_: the refstack result is a first step in a process for granting the OpenStack Powered license | 18:26 |
| alevine_ | hogepodge: Good. This I understand. What would you expect RefStack to have to help you with this process in terms of the UI and flow? | 18:26 |
| catherineD | And this blueprint and spec wants to protect those data by transfer the ownerhship to the OSF | 18:27 |
| hogepodge | alevine_: one thing I do is store a link to the refstack result, as part of a requirement for making results public. I internally associate the result with the product | 18:27 |
| hogepodge | alevine_: but if the result disappears, that audit trail becomes broken | 18:27 |
| hogepodge | Does that help? I'm sorry I didn't respond inline to the review and outline the process. My sincere apologies. | 18:28 |
| alevine_ | hogepodge: I start to understand. So the real use-case we try to implement here is for you to be able to "mark" some set of test results in the RefStack in such a way that owner/creator cannot delete them. Right? | 18:28 |
| *** pilgrimstack has quit IRC | 18:29 | |
| Rockyg | Right. | 18:29 |
| sslypushenko | alevine_: Your questions in review are mostly addressed to certification flow. I guess it is a bit of scope for RefStack now. | 18:29 |
| Rockyg | So, really, ownership transfers when a vendor requests the cert. | 18:29 |
| alevine_ | hogepodge: I don't see how ownership transfer is required here. Test results should just be marked as "used for certification" and we'll never allow them to be deleted even by owners. | 18:29 |
| hogepodge | alevine_: correct. As proposed, this implementation regards test results as a special case. Since the vendor is participating in a board approved trademark program with reporting requirements, this model posits that these test results are no longer owned by the vendor, rather they are owned by the community. | 18:29 |
| alevine_ | hogepodge: So would such "marking" be enough for your goals? | 18:30 |
| sslypushenko | alevine_: hogepodge : we are really talking about the same thing just in different ways | 18:31 |
| alevine_ | sslypushenko: Ownership transfer is much more complicated and poses much more unresolved questions than what is actually asked. | 18:31 |
| Rockyg | So, the *management* of the test result transfers. | 18:31 |
| hogepodge | alevine_: I see advantages to both. If there are other administrative reasons to clean up data (say from a bad or falsified test run), Foundation being an owner that can operate on the data makes sense | 18:31 |
| catherineD | hogepodge: ++ | 18:32 |
| alevine_ | hogepodge: Foundation can do everything in RefStack with every object at any times. | 18:32 |
| sslypushenko | RefStack should guaranty that test results are used for certs should be untouched. That is mainly it | 18:32 |
| alevine_ | hogepodge: So that's not an issue. | 18:32 |
| Rockyg | Also, the responsibility. Which is why the term "ownership" is used here. | 18:32 |
| sslypushenko | alevine_: it is not true, I guess | 18:32 |
| alevine_ | hogepodge: Foundation admin is a superuser. | 18:32 |
| catherineD | alevine_: the issue is we clearly indicate that the creator or vendor no longer can manage the data | 18:33 |
| alevine_ | ssplushenko: It's stated in the design doc. And that's how we implement the code. | 18:33 |
| hogepodge | alevine_: for example, we had one vendor who modified tempest and sent in strange results. We were able to clear up the issue, but we would want to report the correctly run results rather than the questionable ones. | 18:33 |
| sslypushenko | superuser can not manage vendors private data | 18:33 |
| alevine_ | hogepodge: That would be another use case which we'd also need to clarify. I don't quite understand it yet :) | 18:33 |
| catherineD | sslypushenko: they can at the moment ... but it is a different discussion | 18:33 |
| sslypushenko | catherineD: can not - should not be able) | 18:34 |
| alevine_ | hogepodge: Can't we pursue clear and the most vital goals like the use-case with test results preservation? It's very easy to implement and it doesn't pose any questions. | 18:34 |
| Rockyg | alevine_, this is why we really need to define the roles beyond just the traditional user/superuser roles | 18:35 |
| alevine_ | sslypushenko: Have you had a chance to read the design doc? :) | 18:35 |
| catherineD | sslypushenko: we need to discuss that and take action but not in this meeting | 18:35 |
| alevine_ | rockyg: Why? | 18:35 |
| pvaneck | In any case, I think adding a field to prevent deletion of a test result by general users is pretty innocuous | 18:35 |
| alevine_ | pvaneck: And it's in Catherine's spec - it's called "certification" or something. I'm totally pro this. | 18:36 |
| alevine_ | Let's add it and forbid deletion of such test results by anyone except Foundation. That would be it. | 18:36 |
| Rockyg | alevine_, because ACLs are role based and can be more finegrained than linux defined uder/superuser | 18:37 |
| Rockyg | It's for policy enforcement | 18:37 |
| hogepodge | alevine_: There is another goal in this, though. In the early days of the program a number of vendors submitted results as subunit files or anonymous refstack results. I've converted many of the subunit runs to refstack, but as anonymous results. I need a way to capture those (and some assistance in setting up the Foundation account) | 18:37 |
| alevine_ | Rockyg: It's also a nightmare in development and management so let's not rush this way. | 18:37 |
| alevine_ | hogepodge: Would it be useful for you if we created a special Admin interface in UI to set owner for anonymous results? | 18:38 |
| catherineD | alevine_: the spec did say so in diff ways "Once a test record is marked as certified, only interop admins can remove/delete | 18:38 |
| catherineD | the test record" | 18:38 |
| sslypushenko | Rockyg: implement role based ACL system is not a piece of cake | 18:38 |
| hogepodge | alevine_: so at a minimum, for the anonymous submission case I want a way to own it. Let's call it a consequence of growing pains. | 18:38 |
| catherineD | I am willing to make update to the language if it helps | 18:38 |
| alevine_ | catherineD: That's a perfect sentence. I don't have anything against it. But it also doesn't require ownership transfer. | 18:38 |
| alevine_ | hogepodge: Even better - we can protect all of the anonymous results currently in RefStack and only Foundation will be able to deal with them. | 18:39 |
| Rockyg | roles are not easy, but knowing what they are and where you want to head makes for informed coding and less rework | 18:39 |
| alevine_ | hogepodge: No special interface in UI required. | 18:39 |
| catherineD | hogepodge: sure .. we will add anonymous data handling next | 18:40 |
| hogepodge | alevine_: no, I'd like to explicitly own them | 18:40 |
| alevine_ | Rockyg: That's a completely different and very broad conversation. | 18:40 |
| hogepodge | alevine_: more specifially, state exactly which ones I want to own | 18:40 |
| sslypushenko | Rockyg: unfortunately it is not 100% true. | 18:40 |
| alevine_ | hogepodge: Ok. We can run a script through the DB and change creator to Foundation for all anonymous results. Would that work? | 18:40 |
| alevine_ | hogepodge: Ok then special interface in UI would be needed. Would that work? | 18:41 |
| Rockyg | alevine_, ++ | 18:41 |
| catherineD | so am I correct that we have reached agreement about this certification column? | 18:41 |
| Rockyg | exactly how to handle one offs like the early data | 18:41 |
| alevine_ | catherineD: From my side yes. | 18:41 |
| catherineD | alevine_: thx | 18:42 |
| catherineD | how about others? | 18:42 |
| alevine_ | catherineD: However we don't know yet about the mechanism of "marking". Probably the same admin interface now. | 18:42 |
| hogepodge | catherineD: sure | 18:43 |
| catherineD | that would come next ... I want us to get the foundation layer so that we can build the UI and show it to DefCore on midcyle (August 1) for feedback | 18:43 |
| sslypushenko | I'm +1 for transferring community results ownership to OSF | 18:43 |
| Rockyg | need to modify test deletion to check for the cert field | 18:43 |
| hogepodge | alevine_: I'm going to stand by Foundation owing anonymous data that was used for licenses. There are privacy and legal reasons for this. | 18:43 |
| catherineD | 15 mins left ... next I want to discuss transfering of ownership from data creator to vendor | 18:44 |
| alevine_ | hogepodge: So I suggest to add a couple of actions available for Foundation admin in test results screens somewhere. Namely - "mark" as used for certification; set Foundation ownership. | 18:44 |
| hogepodge | alevine_: We have a privacy policy where data used for reporting needs to have access control, and clear statement of who can see and do what with it | 18:44 |
| alevine_ | hogepodge: As for the setting Foundation ownership - do I understand correctly that it'll be applied to anonymous results only? | 18:46 |
| catherineD | first of all test data is associate to a cloud which is associated to a product belongs to a vendor | 18:46 |
| catherineD | alevine_: no | 18:46 |
| hogepodge | alevine_: and part of that means the party that controls the data needs to have signed a confidentiality agreement. For this same reason, at some point we're going to have to move the trove database out of infra control and into foundation control | 18:46 |
| catherineD | hogepodge: ++ | 18:46 |
| alevine_ | catherineD: That's what hogepodge said above. | 18:46 |
| hogepodge | because many devs haven't signed the privacy agreement | 18:47 |
| catherineD | the reason I say no is we may disallow anonymous data upload in the future | 18:47 |
| alevine_ | catherineD: I'd disallow it right now :) | 18:47 |
| catherineD | at that point data have to be owned by someone and thus need transfering of owership | 18:47 |
| sslypushenko | alevine_: +100 | 18:47 |
| catherineD | alevine_: yea that is our goal | 18:47 |
| alevine_ | catherineD: But that doesn't change the use-case which hogepodge explained | 18:47 |
| catherineD | once we have all of this fundation layer in place to protect the data that should be protected | 18:48 |
| alevine_ | hogepodge: So did I hear correctly that you wanted to deal with the anonymous test results only in terms of setting Foundation ownership to ghem? | 18:48 |
| Rockyg | alevine_, ++ Been working towards that for a while | 18:48 |
| catherineD | alevine_: anoymous and non-anonyous since some data links sent to Chris can be both | 18:49 |
| hogepodge | alevine_: test results I want to to be owned by the foundation | 18:49 |
| hogepodge | I see value in stating that if a result is used for trademark testing, that it become a community asset. This means all results fall under umbrella of one ownership and management. | 18:50 |
| alevine_ | hogepodge: So any test results? Even owned by someone else, non-anonymous ones? This wouldn't be for the certification test results preservation use-case right if we protect them by the certification flag? | 18:50 |
| hogepodge | I have a hard stop at the top of the hour | 18:51 |
| alevine_ | hogepodge: "tradmark testing" is not certification? It's something else? | 18:51 |
| catherineD | could we discuss vendor ownership? | 18:51 |
| hogepodge | alevine_: I'm trying to be careful in my language. I know that I'm now supposed to use either the word 'certification' or 'validation', but I've forgotten which is the one that's off limits | 18:52 |
| hogepodge | alevine_: so I'm speaking out of caution, but yes, same thing | 18:52 |
| alevine_ | hogepodge: So you want to preserve all of the results which are used for any "validation/certification"? | 18:52 |
| hogepodge | we don't have consensus yet, so let's move on. | 18:52 |
| hogepodge | alevine_: yes | 18:52 |
| alevine_ | hogepodge: Then we'll mark them as "used for validation" in DB instead of "used for certification" and they'll be as protected. Would that be ok? | 18:53 |
| catherineD | so I got a lot of feedback from Austine wanting to see data associate to a vendor displace (of course with vendor approval) | 18:53 |
| alevine_ | catherineD: Can I see the details of the request so that business use-case can be created? | 18:54 |
| catherineD | the first step to do this is to protect the vendor from being associate to data that are not intended to | 18:54 |
| hogepodge | alevine_: I understand your point, but I also feel strongly about the ownership issue. ok? So yes, marking data as being used for 'certification' is part of the solution. I prefer it not be the only part of the solution. | 18:54 |
| alevine_ | hogepodge: I suggested two tools: marking as used for validation, and setting Foundation ownership for anonymous data. | 18:55 |
| alevine_ | hogepodge: At least that's what I heard from your use-cases is required. | 18:55 |
| hogepodge | alevine_: yes, we disagree on the complete solution | 18:55 |
| alevine_ | hogepodge: What complete solution do you suggest? | 18:56 |
| alevine_ | hogepodge: And how it'll look in the UI? | 18:56 |
| Rockyg | I think we'll need another meeting for vendor supplied data vs third party supplied against vendor | 18:56 |
| catherineD | I hope hogepodge: markvoelker: Rockyg: can attend | 18:57 |
| catherineD | the next meeting | 18:57 |
| hogepodge | alevine_: that upon successfully submitting a result for 'certification' ownership be transferred to foundation and certification flag set to true. As described in the spec | 18:57 |
| catherineD | I just want to avoid using too much of your time | 18:57 |
| * markvoelker will do his best and will hopefully not have overlapping meetings next time around | 18:57 | |
| alevine_ | hogepodge: I mean from the usage point of view. Not from the implementation point of view. | 18:58 |
| hogepodge | alevine_: I don't have an answer that I can design up on the spot. I can give it thought. | 18:59 |
| alevine_ | hogepodge: That would be perfect. | 18:59 |
| alevine_ | hogepodge: UI flow as well if possible. | 18:59 |
| catherineD | one minute ... | 18:59 |
| alevine_ | hogepodge: Which one would be convenient for you. | 18:59 |
| catherineD | I want to thank everyone so much for this addtional meeting ... hopefully we do not have to do it very often .. | 19:00 |
| catherineD | I have a hard stop too ... | 19:00 |
| hogepodge | catherineD: sorry we didn't cover more ground | 19:00 |
| catherineD | thank you all again!! bye! | 19:00 |
| alevine_ | thank you. | 19:00 |
| hogepodge | catherineD: alevine_: et al, thanks | 19:01 |
| *** alevine_ has quit IRC | 19:01 | |
| catherineD | hogepodge: no this help a lot !!! Thanks!! | 19:01 |
| Rockyg | Thanks all! | 19:01 |
| andrey-mp | i think that is better to cover one by 100% than several by 10%... | 19:02 |
| Rockyg | andrey-mp, ++ | 19:02 |
| *** Guest20454 is now known as mgagne | 19:58 | |
| *** mgagne has joined #refstack | 19:58 | |
| *** Rockyg has quit IRC | 20:40 | |
| *** andrey-mp has quit IRC | 20:58 | |
| *** cjvolzka has left #refstack | 21:11 | |
| *** designbybeck has quit IRC | 22:00 | |
| *** edmondsw has quit IRC | 22:46 | |
| catherineD | clee: We have updated refstack-client default Tempest version to include the "Add IPv6 rule creation to validation resources" Tempest patch ( https://review.openstack.org/#/c/330790/ ). Thanks ! | 23:27 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!